One part of the business continuity plan that lays solely on the shoulders of any IT organization is the Disaster Recovery Plan. It’s the framework that gets enacted when a disruption of service occurs. It could be a security intrusion, network outage, or a failing database that raises alerts. Anything that may cause a disruption of service will enact the continuity plan to keep your business running or restore services as soon as possible.
The experiences that I had while being involved in a global IT operations showed me how important, and often times convoluted, these “plans of action” can be. So how do we make a plan for our use that is simple and effective? By boiling down the necessary steps into a short action plan that you can leverage later when needed. You may be using the DX4000 at a remote office as a branch cache solution, or in your SOHO… whatever the case is, we will break this thing down to make a backup solution that works. Your plan will be different depending on what your needs are, but hopefully this article will provide some tips on how to setup a recovery solution for the DX4000 when being used with Windows Server 2012 R2 Standard or Essentials.
The recent editions of Windows has introduce some really cool features that allows a technician or end user to do some quick and easy system restorations. On Windows 8, they integrated some advanced recovery capability that will allows one to do a complete zero state or even a roll-back using restore points. The same applies to Windows Server, you can force a recovery mode by shift-clicking “restart” from the Power icon in the charm settings option bar and selecting “Operating System: Recovery.” This is great if you have a monitor, mouse, and keyboard attached. But what if the system is remote or like in our case, is headless? We got a problem, the machine might as well be on Mars. The solution is actually quite simple. Integrate TightVNC into your recovery image with networking.
At first this may sound like a no-brainer. Just go through the steps to include the bits for TightVNC into the recovery WIM, add your drivers and give it a test. But there’s a problem, Windows Recovery boots slightly differently than just plain ‘ole Windows PE. If you do those necessary steps, they never actually get processed because of a little file added into the image that launches the emergency mode environment and waits for input. It never launches the startup.cmd file we’ve previously used to processes the unattend.xml file which includes the code to launch TightVNC services. Let’s examine this from the point where I left off in my previous article on how to get Windows Server 2012 R2 Essentials installed on the DX4000 and after canceling the Configuration Wizard.
Grab the RE Image:
I’ll be using the system I setup in my previous article on installing Essentials on the DX4000 to show how to capture the recovery image and make a few modifications to create a recovery mode that can be accessed via the network. I will also provide some steps that you can use to create a new bootable USB that can be used for doing a Bare Metal Recovery.
After canceling the Essential Configuration Wizard, open a command prompt and launch DISKPART and list the volumes. You will notice that the autounattend.xml script created a R: partition, and while it should be hidden without a drive letter assigned, we are first going to copy the WINRE.WIM file from it to our technician computer and make a few modifications.
[edit, 10/31/2014] Note: I corrected the unattend.xml file from the previous article to not assign a default drive letter (R:) to the Windows RE partition. You should call “assign letter=R” in diskpart to the partition to make it accessible via the command prompt. (make sure you “select partition” with the correct volume number first before assigning the letter)
Figure 1: Windows Recovery Partition
In Figure 1, I’ve already mounted a remote share to the Z: point and changed paths to the location of the WIM file located in the ..\Recovery\WindowsRE\ path. Modify the file attributes by removing the SYSTEM and HIDDEN properties, and copy the file to your workstation. Most of the contents of the recovery partition are hidden, so to view them you’ll need to execute DIR with the /AS switch.
There are a couple things needed to make our DX4000 remotabootable in recovery mode.
[riˈmōt ā ˈbo͞otəbəl]
a new-fashioned name for booting a computer.
[riˈmōt ā ˈbo͞otə ]
On your technician computer, open the Deployment and Imaging Tools Environment with elevated permissions and mount WINRE.WIM for editing. Add your Intel 82574L NIC and RST drivers (you can use the 12.9 RST drivers for this mode, it is compatible and works well with the CLI toolkit). I cover these tools in more detail in a previous article. Copy the bits for the TightVNC services as you have done before (also covered earlier) and add the unattend.xml to the root of the mount point and include the startnet.cmd file into the System32 directory which launches it.
One final thing to modify, a file called WINPESHL.INI in your mount point ..\Windows\System32, just delete it. This gets examined during the boot up phase, and if it exists and has contents, it will pre-empt any code added via the startup.cmd file. It is what launches the recovery environment and waits for you to interact with it. The TightVNC services will never be launched if this file exists. That would be a bummer.
Close any directory explorers or editors to prevent open file handles to the mount point, and commit changes to the WIM using DISM.
Replace the BOOT.WIM file located on your bootable USB that you made with a copy of the WINRE.WIM image that you just modified. Be sure to rename it to BOOT.WIM or the system will just shut down. Plug it into your DX4000, and with the magic button… boot the system into WINPE mode. Let’s make sure that this thing is going to play well before we replace the version on our system.
Launch Recovery from WINPE:
If everything turned out as planned, you should now be at the familiar shell prompt via TightVNC. Change directories to the root of X: and enter the ..\Sources\Recovery path. Execute the program RECENV.EXE, and raise your arms in glory to celebrate our nerdiness.
Figure 2: Recovery Mode
Choose your favorite language, unless you forgot to add all the language packs; otherwise, choose anything and I think English gets used. After this, things should become somewhat familiar, by choosing “Troubleshoot” you can now launch your various recovery options such as “Refresh” or “Reset”. However, under advanced options, you are able to do restore points as well as system image recovery, which is used to do Bare Metal Restorations and other things created from the Windows Server Backup tool.
Choosing “System Image Recovery” may prompt you for your target operating system, and will then launch the Windows Server Backup and Restoration tool. It actually runs just the restoration part, I don’t believe you can do any back up with this. Give it just a few seconds and the tool will launch…
Figure 3: Restoration Tool
Congratulations, you have now made a useful WINPE/RE recovery tool for yourself in the event a BMR is needed. The next thing to do is to shut down the server, remove that USB, and boot the system like normal.
Replace Windows Recovery:
After confirming that our Recovery USB is working, reconnect to the server with Remote Desktop Connection. If, like me, you’ll get presented with the Essential Configuration Wizard again… just close it. Open a command prompt and change directories back to the R: partition and enter the ..\Recovery\WindowsRE folder. Delete the original WINRE.WIM we copied a while ago, and either copy the new one from your technician computer over the network or the BOOT.WIM from the USB you made into that folder. Make sure it is named WINRE.WIM though, and re-apply the SYSTEM and HIDDEN attributes to the file:
R:\Recovery\WindowsRE\ATTRIB WINRE.WIM +S +H
Fix Partition Visibility:
Change back to the C:\ partition and execute DISKPART, select the volume for partition R: and issue the following commands:
SET ID=ebd0a0a2-b9e5-4433-87c0-68b6b72699c7 OVERRIDE
SET id=de94bba4-06d1-4d40-a16a-bfd50179d6ac OVERRIDE
That should stick, and now your recovery partition is hidden from the OS. (I tested, it just works) You can still see it in Disk Management, but it will no longer get a drive letter assigned and since this is a critical partition, it will not be easily removed. After doing this I generally reboot the system to make certain things are refreshed.
Enable Windows Recovery:
We are now able to assign a letter to the recovery partition without it “sticking” after every reboot and don’t need to mess with it unless we need to. Open a command prompt and verify that Windows Recovery Environment is enabled by executing the following:
Figure 4: Houston, we have a problem.
Unfortunately, something is not working correctly. If we attempt to execute a manual “shutdown /r /o” command to force entry to the recovery environment we get an error message. I’m not sure what the cause of this is, but we can work around it fairly quickly. Even though the status is enabled, we need to set a flag to activate the enabled state:
SHUTDOWN /r /t: 1
Now, the system reboots into recovery mode with remote capabilities without the use of a USB. This could be helpful for remote management in a pinch. However, ideally something still is not quite right as I should be able to execute “shutdown /r /o” or using the Shift-Click trick on the restart button to launch the recovery environment. Perhaps it’s a bug, or the BCD is not configured correctly. Either way, issuing the “boottore” switch with reagentc.exe does activate the flag and force recovery mode.
The Rest of the Story:
Well, this part needs to be written by you as that’s about all I’m going to do for this post today. To complete your backup and restoration plans, make a full backup (BMR) using Windows Server Backup, and use your newly found remote capability to kick off your restoration. Do some tests, make sure things are working as planned.
UPDATE: If this subject is of interest, and you find you are having some troubles… be sure to take a look at my article “Virtualize: Native VHD & Custom RE“. In the “Setting up the system” section, I introduce a Powershell script that can correct the BCD automagically for systems using Native VHD. This same script can be adopted for standard installations.