A fitted board is the halfway point, not the finish. This checklist closes out the swap properly: RAID mode confirmed before the OS loads, forgotten settings restored, MAC and activation changes fixed, firmware aligned without gambling, and the power protection that stops the sequel.
The server boots, the office cheers, and the technician leaves — and three days later the backups are failing on a wrong clock, the reservation points at a ghost, and the new board is drinking the same dirty power that killed the old one. Board swaps fail in the follow-through, not the fitting. This page is the follow-through: a first-boot order that protects the array, the settings and identity changes every swap creates, an honest firmware policy for elderly hardware, and the power protection that makes the repair a one-time event.
👆 A board swap is not finished when Windows appears. It is finished when the settings, versions and power protection around the new board have all been closed out.
The replacement board is in, the drives are back in their labelled positions, and the power button is waiting. Spend the first boot in BIOS setup (F1 on Lenovo servers), not in the operating system:
Your old board carried years of small decisions; the new one carries factory defaults. Restore the ones that mattered: fan and acoustic profile if you changed it, power behaviour after an outage (auto power-on is what most small offices want from a server), Wake-on-LAN if anything depends on it, and any boot security you had configured. Then fix the identity changes outside the box: the new board's different network MAC address means the router's DHCP reservation now points at a ghost — update it — and Windows may need reactivation, which is routine with the same licence. Note the new board's serial and part numbers in your records while the case is still open in your mind.
Check the replacement board's BIOS version and write it down, along with the storage controller behaviour you observe in the first days. The honest firmware rule for a just-revived server is align, do not chase: update firmware when a published fix matches a problem you actually have, or when the version is dangerously old — not simply because a newer number exists. Every firmware flash on elderly hardware carries a small risk, and the week a server returns from the dead is the wrong week to gamble. If you do update, do it on stable power (see the next section), one component at a time, with the current version recorded so you can describe exactly where you started.
Ask the uncomfortable question while the invoice is still warm: what killed the first board? If the answer might be electrical — the death followed a storm, a power cut, or a flickering supply — then fitting a fresh board into the same power conditions is scheduling a repeat. The fixes are unglamorous and cheap relative to a second board:
Close the job with a week of light attention: glance at the event logs and array status daily, confirm backups ran on the revived machine itself (not just that they used to), and keep the old board — or its repair — as a documented spare rather than scrap. A platform this old rewards owners who keep one of everything. After a clean week, declare the server properly back: board fitted, settings restored, firmware noted, power protected, and the paperwork — versions, serials, dates — filed where the next technician, who may be you in three years, will thank you for it.
See the ST150 repair in the video, then run this checklist on your own revived server.
▶️ Watch Full VideoEnter BIOS setup before the operating system loads: set storage mode to RAID as before, confirm every disk and a healthy array, set the boot order, and check fans and system time. Only then boot normally. Most post-swap problems are settings, not hardware.
Not automatically. Record the fitted version first, and update only if a published fix matches a real problem or the version is seriously old — and then only on stable, UPS-protected power. Align the system; do not chase version numbers in the week the server comes back to life.
The replacement board has different network MAC addresses, so the router gave it a fresh DHCP lease and your old reservation points at the old, gone MAC. Update the reservation to the new MAC address shown in the operating system or BIOS, and the server keeps its proper address from then on.