Once a year, I test restoring a server to a desktop. The server is backed up with standard Windows Backup. The idea is to confirm that if the server went down, I could quickly restore to one of the customer’s desktops as a temporary solution while the server is repaired or replaced. This is also an interesting test of how well Windows Backup handles restoring to different hardware. Previous tests are blogged in 2011, 2012, 2013, 2014, 2015, and 2016.
Update January 31, 2018
Things are close enough this year that I’ll just update this post with a few “2018” notes. Total test time this year was about 2.5 hours, probably the fastest yet!
New This Year
Every year I do this, I think I’ve learned enough to be able to get through the test more quickly. Every year there is a new wrinkle, new hurdles to overcome. This year was no different.
I’ll start by reviewing the new issues, then go through the restore step-by-step. I will assume that your target restore drive can accommodate all of the server’s data. For how to do a split restore of the system and data partitions from the command line, see 2016.
Issue #1: Legacy BIOS
After you unlock the BitLocker drive and go through all the steps to start a restore, you may get this message “Windows cannot restore a system image to a computer that has different firmware”:
The server and the desktop both have a legacy BIOS. My bootable USB showed both legacy and UEFI options. After getting this message, I set the desktop BIOS to “Legacy Only”. At that point, the USB would not boot. Solution: boot from a DVD.
It looks like I figured this out in 2015 (see “Lessons for Next Time”) but missed it this year. Just use a DVD.
Issue #2: Confusing Backup Message
This year, a new message appeared: “At backup time, you had backed up only selected files from volume D:. If you proceed, only those specific files and folders that were backed up would be recovered.”
I do now also have Azure Backup running on this machine, backing up data files on drive D:. But I’m restoring from a physical hard disk that should include C: and the System Partition. Is this message telling me I only have drive D: available?
I used the command line to confirm that all drives are present:
wbadmin get versions -backuptarget:D:
wbadmin get items -version:03/23/2017-06:00 -backuptarget:D:
I also confirmed in the restore wizard that C: and D: were there:
Wait a minute: I recently excluded the WSUS repository from the backup of D:. Now I realize that the message means, “We’ve got all your drives, but the D: drive will be missing the files that you excluded when you did the backup of D:.”
What You’ll Need
Gather these tools before you start:
- Server 2012 R2 DVD. See Issue #1 above about why to avoid USB media.
- An external CD/DVD drive. The internal drives, rarely used, often seem to fail.
- A bare hard drive equal to or greater than the size of the drives backed up from the server.
- Snacks. This always takes longer than you think!
Prepare for Restore
This year we’re again restoring to a Lenovo M93p (model 10A9), except this time, I temporarily installed blank 1TB drive for this test. This should allow automated restore and you won’t have to restore the desktop at the end; you just re-install the desktop’s drive. (In a real disaster scenario, if the reason that the server is dead is due to a hard drive failure, you might be able to use your spare hard drive directly in the server.)
Restore to the Desktop
1. Set the desktop’s BIOS to match the server’s, in this case Legacy Only.
2. Plug in the external backup drive from which you’ll be restoring. Use a USB3 cable. Turn it on. (Yes, obvious, but when you forget, you have to start over!)
3. Insert the bootable Server 2012 R2 DVD. Boot the desktop from the Server 2012 R2 media.
4. Choose Repair your computer > Troubleshoot > Command Prompt. Unlock the external BitLocker drive if prompted, even though you don’t need it right now.
5. Use these commands to clear the temporary internal disk:
diskpart (determine which disk number is the internal drive)
list disk
sel disk 0 (choose the drive you want to clear, not the backup source drive!)
clean
exit
6. Type exit again to exit the command prompt, then go back to Troubleshoot > System Image Recovery. Unlock the BitLocker drive if you haven’t already. Accept the defaults to restore from the main system image on the disk. Allow it to partition the target disk. Restore all drives, not just the system drives. If it complains about only having drive D: on the media, you can probably ignore it—see Issue #2 above. At the end, choose Advanced and uncheck the Reboot when finished option—in case you aren’t there when it finishes, you want the change to turn off the live server before booting the new one.
Start the restore. In 2017, it took about 16 minutes for C: and 25 minutes for D:. In 2018 (with a USB3 cable), it was down to 9 minutes for C and 18 minutes for D.
Prepare to Boot
Before we do, some important preparation tasks to tell the network that the server is now on the desktop.
Note If you’re using a UniFi router and the controller is on the server that you are testing, make these changes before shutting down the live server.
1. On the router, change the server’s IP reservation to a temporary IP, e.g. one ending in .99. (Even though the server has a fixed IP, I set up a DHCP reservation in the router because it also has vPro, which uses DHCP when the server is not on.) Change the desktop’s IP reservation to the server’s, in this case ending in .2.
2. On the router, delete the server’s and desktop’s old DHCP leases. You might want to just restart the router to make sure old routing tables are cleared. In 2018, I have a new router (UniFi USG) that does not allow deleting leases. Fortunately, this was not necessary, and I did not restart the router.
3. Shut down the live server.
The first boot takes a while as Windows re-assigns hardware etc. In 2017, it was almost half an hour. In 2018, it was only 10 minutes, perhaps because the DHCP reservation worked and the desktop automatically received the server’s IP address.
Logon and Fixing the Network Adapter
Once booted, of particular importance is the new network adapter—the OS no longer sees the server’s network adapter, so the static IP assigned there is not active.
Note I had problems in 2017 and 2018 with the Start screen getting stuck on top of other screens. I couldn’t get back to the desktop. Use Ctrl-Alt-Del if you need to Sign out, then sign back in to get back to the desktop. After setting the static IP, below, the Start menu worked fine.
1. Log on, right-click on the network icon in the System Tray, and go to Network and Sharing Center > Change Adapter settings. Assign the same static IPv4 address as was used by the live server. As a domain controller, the sole DNS entry should also be the local static IP. A message appears that another adapter which is no longer present in the computer has that address. Click Yes to remove he static IP configuration for the absent adapter.
Important For some reason, removing the static IP of the absent adapter removes the gateway configuration. Go back in and make sure that a gateway is defined, pointing to the router. You may need to re-check the gateway after a reboot.
2. If you have data that is backed up directly, for example using RoboCopy, restore that data by copying from one external drive. I did not include this in the test but I did get motivated to take screen shots of Disk Management and Windows Explorer so I know what data is stored where.
3. Reboot the system. This should go more quickly as the system is now happy to have all its drives back and its network card properly configured.
You can disconnect the backup drive. In a real disaster recovery scenario, attach another drive to use for backups.
Test the System
1. Check Event Viewer > Administrative Events.
2. Check that the web server works. (May need to test from outside network using a remote connection to another site.)
3. Check that Active directory works, including accepting a logon from a client and updating group policy (gpupdate /force).
4. Check that shared drives are available from a client. Try opening files on a network share.
5. Print a page to a network printer shared via the server.
6. If you’re running the Essentials edition, review the Critical Errors in the Essentials dashboard. You may initially see several errors including licensing errors:
Under Health Monitoring Tasks, choose Refresh. Most of the errors should go away. The remaining errors indicate that some hard drives are not connected and that the Client Computer Backup service is not running. These errors are expected.
7. Also for Essentials, under Home > Health Report, choose Generate a Health Report. Review the report. This also sends an email, testing outbound email flow.
8. In Computer Properties, check that Windows shows as activated.
Testing is now complete. In a true disaster recovery scenario, users could resume work now.
Re-Activate Live Server
1. Reverse the changes you made in the router: set the desktop’s MAC address to point to the desktop’s IP and the server’s MAC to point to the server’s IP. If you can, delete the current DHCP leases for both (if the server has vPro, even though it has been off, it will have pulled an IP address). If you’re using a UniFi router and its controller is on the server that you are testing, make these changes by running the UniFi controller from the test server.
2. Shut down the test server running on the desktop.
3. Turn on the live server.
4. If you’re using a UniFi router, log back in to the controller, now running on the live server, and reverse the server and desktop IPs again.
Reassemble the Desktop
Assuming you did your restore to a temporary drive, just swap back in the desktop’s real drive and you should be good to go. (The temporary drive now contains unencrypted server data. Be sure to do a secure wipe of the drive.)