Follow me on Twitter: http://twitter.com/panosmacheras
Update (07/July/2011): This solution is now deprecated. To get a vastly-improved Windows 7 SteadyState solution please visit this page: http://blogs.technet.com/b/panosm/archive/2011/07/07/windows-7-steadystate-solution-simplified.aspx
Windows SteadyState was a tool that allowed administrators to revert a workstation running XP or Vista to a previously stored state every time it reboots, or on administrator’s request. This feature was extremely useful in scenarios where workstation consistency at the OS and application level is required and the User State (user profile, user files, application settings) is not stored locally. Typical implementations of Windows SteadyState were workstation installations at schools, libraries or internet cafes. However, a recent trend that has been steadily increasing on the enterprise space is the need to deploy stable, rarely-updated machines that maintain their consistency across user sessions (boots) while improving manageability by utilizing Application Virtualization technologies as well as Group Policy. The end result is an Enterprise Workstation that is consistent, requires minimum management and costs less to maintain. You can find more info about Windows SteadyState at Wikipedia: http://en.wikipedia.org/wiki/Windows_SteadyState.
Windows SteadyState is now discontinued. The last supported operating system was Windows Vista and the version released for that OS (version 2.5) is incompatible with Windows 7. In it’s place Microsoft has released guidance on how to achieve a “SteadyState-like” functionality by using Group Policy (to restrict the level of changes that can be made to the OS by the end user) and MDT 2010 (to revert to a well-known initial condition). You can find more info here: http://technet.microsoft.com/en-us/library/gg176676(WS.10).aspx. Unfortunately using MDT 2010 to restore the OS to a well known initial state is sometimes not practical and can be time consuming.
A proposed alternative is the use of the a new Windows 7 feature called “Boot from VHD” or “Native VHD Boot”. This feature allows the usage of a VHD file (Virtual Hard Disk) to run the operating system instead of using a hard disk partition. It should not be confused with virtualization technologies like Hyper-V or Virtual PC. This feature does not use a hypervisor or virtual hardware. You should think of it as running your C: partition on a VHD file instead of a real hard disk partition. You can find more info about this feature here: http://technet.microsoft.com/en-us/library/dd440865(WS.10).aspx.
What is interesting about this feature is that it can work with a differencing VHD file. What is a differencing VHD file? A differencing VHD file is linked on a regular VHD file (called parent VHD) and only stores modified blocks of data in relation to its parent VHD. The result is that we can easily roll back changes by simply resetting this differencing VHD to its initial (empty) condition. This is a technique that is commonly used in Lab deployments where several virtual machines use differencing VHDs in order to test scenarios and then rollback changes. We can also use differencing disks to achieve the same result in a physical Windows 7 installation.
In this blog post we are going to describe a “step-by-step” guide on how to use this technique. In a second blog post we will describe how to automate the installation by using MDT 2010 so that we can leverage this capability at the enterprise level.
WinPE is the Windows Preinstallation Environment used during the installation of Windows. It is also used for common maintenance tasks or for troubleshooting broken installations. It is included in Windows Automated Installation Kit for Windows 7 (Download). We will install and use WinPE in order to manage the differencing VHD of the Operating System either by discarding changes (to revert to our initial Steady State) or by committing the changes (by merging the differencing VHD to its parent VHD).
On Step 2 we are going to use the diskpart command line utility to format the physical hard disk and create 3 VHD files:
The command below will create a parent VHD file of approximately 30 GB size and of type “expandable” (meaning that it will start from zero size and expand up to the 30 GB limit). Feel free to change the size according to your specifications. You can also use a type “fixed” vhd file which will pre-allocate the whole size of the VHD (by creating a big VHD file of the maximum size you specify). Using a “fixed” VHD file will give you a small performance improvement vs. using an “expandable” one. The last step will create a copy of the differencing VHD which we will use to quick revert our VHD to an initial “empty” state.
The next step is to use the win7.vhd file we created, to install Windows 7:
On your new Windows 7 installation perform the following to install WinPE on the winpe.vhd file.
We have created all the necessary VHD files. In the next step we need to provide the logic behind “discarding” and “committing” changes we have made in each session. As previously explained this is done by either resetting or merging the differencing VHD file temp.vhd. This procedure is done by booting into WinPE (through winpe.vhd which we created in Step 4), doing the change, and then rebooting to the differencing VHD. There are two options that we will configure:
Additionally we will also configure a startup command to change the default booting partition to WinPE (winpe.vhd).
Here are the detailed steps on how to configure this:
That’s it! You can proceed to configure Windows 7 exactly the way you want to appear in your initial “SteadyState” (even Windows Activation will work between sessions). Each time you restart WinPE will run and discard all the changes by resetting the differencing VHD and then reboot to Windows 7.
If you want to commit the changes you have made then you need to run: c:\windows\system32\commit.bat (of course as a local administrator!) and the changes will stay as WinPE will merge the differencing VHD to its parent after the first reboot.
Below is a flow chart detailing the procedure:
In a next blog post I will outline how you can automate this procedure by using MDT 2010 (Microsoft Deployment Toolkit) and AutoIT scripts.
Feel free to provide feedback on ways to improve this implementation either by contacting me or by commenting below.
Thanks,
Panos Macheras Infrastructure Consultant