Mark Berry March 23, 2017
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.
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.
- 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. 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)
sel disk 0 (choose the drive you want to clear, not the backup source drive!)
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.
Start the restore. This time, it took about 16 minutes for C: and 25 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:
1. Shut down the live server.
2. On the router, change the server’s IP reservation to a temporary IP, e.g. one ending in .99. Change the desktop’s IP reservation to the server’s, in this case ending in .2.
3. 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.
The first boot takes a while—almost half an hour this year—as Windows re-assigns hardware etc.
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.
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. Then go back in and make sure that a gateway is defined, pointing to the router. I think removing the static IP of the absent adapter somehow removes the gateway. 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 to the other.
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.
Note I had problems this year with the Start screen getting stuck on top of other screens. I couldn’t get back to the desktop. Finally, after setting the IP address as described above, I used Ctrl-Alt-Del to Sign out, then opened an administrative command prompt and used a
shutdown /r command to reboot the server. After the reboot, the Start menu worked fine.
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. Under Health Monitoring Tasks, choose Refresh. 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. Shut down the test server running on the desktop.
2. 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. 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).
3. Turn on the live server.
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.)