Share This Post

Windows 7: Maintaining state with differencing VHDs

Edit (7/1/11): I should of posted this sooner as i have know about this for weeks. Resetting state can cause issue if machine password changes. To avoid this problem add the following GPO setting to any computers using this: Computer Config > Windows Settings > Security Settings > Local Policies/Security Options/Domain Member: Disable machine account password changes = Enabled.

If you have systems that are extremely locked down in a public setting you have probably used a product that maintains system state such as Deepfreeze. Due to various reason I have been wanting to move my biggest student lab back to a locked state type of setup. Since I hate Deepfreeze with a passion and steady state no longer exists I decided to see if I could automate something with Windows 7’s boot to VHD feature. This is what I came up with.

Download here: https://webspace.utexas.edu/skeiffer/pub/VHDBoot.zip

Usage

  • To install, copy the VHDFiles folder to C:\. Then run VHDFiles\Scripts\startConvert.bat as admin.
  • To revert back to master, run VHDFiles\Scripts\startRevert.bat as admin.
  • To merge changes into master, run VHDFiles\Scripts\startMerge.bat as admin.

Once installed you have two options. You can revert changes or make changes permanent using the two files above. To automate things you can call these scripts using task scheduler or any other service you wish to use. Be careful when doing this with ConfigMgr as you might run into an infinite loop problem due to the client loosing its state when doing reverts. I personally created scheduled tasks in a GPO to run once a week.

Implementation

While there is nothing complex at all about these scripts at a programming level. It took me quite a few iterations to get things working. In the end in order to get things like junction points working correctly I had to be really expensive in my methods(for install). Hopefully when ConfigMgr&MDT 2012 come out with their new deploy to VHD feature things will be a bit cleaner.

All actions are performed in a WinPE 3.0 image that is included in the zip. Dell’s WinPE drivers have been intergraded (A04 version).

Installation

Due to ConfigMgr not working with VHDs (I tired, ends badly) and the issue of junction points I had to use imagex as swap space so I could preserve those links. Here is a general overview of what happens.

  1. startConvert.bat is run, it creates BCD entries for both wipe and the soon to be child VHD and exports them for easy importing later.
  2. System is booted into WinPE.
  3. Master VHD is created and mounted.
  4. An image of C: is taken and applied to the VHD (with a little drive letter shuffling to make sure junction points are correct).
  5. C: is wiped with the exception of a few folders (VHDFiles, boot, and _SMSTaskSequence)
  6. The registry of the windows install now on the VHD is edited so that when the system comes online the VHD is C: instead of something else.
  7. The child VHD is created.
  8. The boot loader is set to boot into the child VHD and the system reboots.

Here is how things look from a high level on the disk.

bcdBootDiag
Here is what things look like for the user.

driveScreen

Restore/Merge

Both of these actions are quite fast and very simple. The merge action can take a few minutes depending on how much data you are merging.

  1. startRestore.bat/startMerge.bat is run.
  2. The system is booted into WinPE.
  3. [Merge only] The child is merged into the master VHD.
  4. The old child VHD is deleted and a new one is created.
  5. The boot loader is set to boot into the child VHD and the system reboots.

Issues

  • This script is designed for single partition use only. If you use a system/bitlocker partition the scripts will need to be edited due to the fact that in WinPE windows will be on D and not C.
  • Since we are using a differencing setup there is a slight performance overhead. From my tests its around a 5 to 10% performance loss in hdd speed. You will only notice it when the system is booting and before programs are cached into memory for superfetch. The students that used my test machines never seemed to notice the difference.

Share This Post

Leave a Reply