Or how to "sandbox" your Windows 2008 production environment for free.
Easy steps (Google if you need help):
- Take a bare-metal backup of your AD server(s) using Windows Server Backup to an external drive.
- Download XenServer from xenserver.org and install it on your Sandbox host machine.
- Download XenCenter from xenserver.org and install it on your Sandbox management PC.
- This is important: Make sure the Sandbox is on a separate network from the production environment. Sandbox network traffic should have no pathway to the production environment.
- Instantiate the virtual machine(s) on the Sandbox host machine.
- Restore backup image(s) to virtual machine(s). Now the restored, P2V server(s) will boot to the BSOD.
- Use this guide to tell Windows to load the driver for the (intelide) virtual hard disk. This will resolve the BSOD you were getting when starting the VM(s).
- Install XenServer Tools on the VM(s). Install XenServer Tools before you activate Windows, otherwise you will have to activate again after installing XenServer Tools.
- Activate Windows VM(s).
- Take the VM(s) off the Internet and set change the properties of the VM’s network adapter. Give it the static LAN IP, DNS, etc. of the physical machine. NB, the DNS of the VM should point at itself.
To fix the problems and get AD and Group Policies working (mostly), here's what you need to do:
- Click Start, and then click Run.
- In the Open box, type cmd and then press ENTER.
- In the Command box, type "net stop ntfrs", without quotes.
- Click Start, and then click Run.
- In the Open box, type regedit and then press ENTER.
- Locate the following subkey in the registry: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
- In the right pane, double click BurFlags.
- In the Edit DWORD Value dialog box, type D4 and then click OK.
- Quit Registry Editor, and then switch to the Command box.
- In the Command box, type "net start ntfrs", without quotes.
- Quit the Command box.
Some of you may not be content with just the hows; you also want to know the whys. Here's some smoke and mirrors that might satisfy you - it satisfied my curiosity.
- Any Active Directory domain that was created using domain controllers running Windows Server 2003 or earlier will use the File Replication Service (FRS) for SYSVOL replication until it is migrated to Distributed File System Replication (DFS-R). This is true even if there are no longer any Windows Server 2003 DCs in the domain and the domain functional level is at Windows Server 2008 or above.
- Various issues can cause FRS replica sets to stop replicating between DCs. The most common symptom of this is the lack of a SYSVOL share on one or more DCs in a domain.
- SYSVOL replication and Active Directory replication use two separate mechanisms, and it is possible for one to work perfectly and the other to fail.
- To determine whether DFSR or FRS is being used on a domain controller that is running Windows Server 2008, check the value of theHKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState registry subkey. If this registry subkey exists and its value is set to 3 (ELIMINATED), DFSR is being used. If the subkey does not exist, or if it has a different value, FRS is being used.
- System state backups for Windows domain controllers do not include the FRS database that maintains state information for the FRS service pertaining to the files within the SYSVOL folder and other content sets. The FRS database, debug logs, staging area files, and files in the pre-existing data folder are excluded from a system state backup.
- An "authoritative restore" of FRS is necessary for SYSVOL and AD to work on a P2V Domain Controller (DC). A"non-authoritative restore" of FRS on a P2V DC works if there are other working DCs on the LAN/Sandbox.