TechNet Magazine > Home > Issues > 2007 > September >  The Desktop Files: PC Recovery with Windows PE
The Desktop Files PC Recovery with Windows PE
Wes Miller


In previous columns, I've mentioned that our initial vision for Windows PE was for it to be a deployment environment. As with all good products, Windows PE evolved beyond being just that. Customers (OEMs, initially) were eager to build one solution for manufacturing and user self-recovery, and several companies produced
Windows® PE solutions that worked for both.
Most recovery tools that exist today are based on the premise of returning a system to a known good state by mirroring the deployment process. Windows Vista® makes recovery quite a bit easier than Windows XP and provides in-box imaging support (see the article on Windows Vista backup technologies by Christine Fok in this issue of TechNet Magazine).
In this month's column, I will discuss building your own recovery solution based upon Windows PE. Windows PE 2.0 is available for free as a component of the Windows Automated Installation Kit (AIK) to all Windows licensees. This license not only applies to deployment, but also to the use of Windows PE for recovery and troubleshooting purposes.
Obviously you'll have to take into account your own customizations and tweaks, but here I will cover the general points you need to remember, whether you're deploying Windows XP or Windows Vista. If you're familiar with imaging, you'll already know much of this.
The key components of any Windows PE recovery solution are:
  • Windows PE
  • An imaging utility
  • Scripting glue (or a formal application) to hold it together
Optionally, you may want to include SQL support and Active Directory® Service Interfaces (ADSI) support. With SQL connectivity you can indirectly build a solution that allows your systems to have a "bill of materials" of sorts that defines what they need in order to install. Similarly, connecting to Active Directory is convenient for handling per-machine account object (MAO) properties.
Note that the inclusion of ADSI in Windows PE isn't supported by Microsoft, but there are quite a few articles online that explain how to do this—and when done correctly, it works quite well. If you don't feel like hacking it, you can add in the SQL support and build in the workflow for your Windows PE recovery tool there. If you need any ADSI properties, you can have a server system with a Scheduled Task to query that same SQL Server™ and then query Active Directory via ADSI—in essence, working as a pass-through.
It's not a perfect solution, and it will require some scripting or other automation, but this design will allow you to interact with Active Directory from Windows PE.
Note that you can also use the LDIFDE utility to read Active Direc-tory information from within Windows PE (see the Knowledge Base article on this topic at support.microsoft.com/kb/237677 for more information). For example, you can use the following command:
ldifde -m -f x:\output.ldf -b <username> <domain netbiosname> <accountPassword> -s 
<DC or domain name> -d "DC=contoso,DC=com" -r "(&(objectclass=<computerclassname>)
(netbuisname=<mycomputername>))" - l "<attributename>"
Entering this command will retrieve an attribute from the specified computer object to x:\output.ldf, where the output can then be parsed.

SKUs, Bits, and Languages
You need to consider the versions, architectures, and languages of Windows that you need to deploy. In a small, locale-specific organization, you are likely to be deploying just one OS—Windows XP or Windows Vista—or using whatever comes already installed on your new PCs. You probably aren't deploying many, if any, x64 Windows systems just yet. And odds are you need to support just one language. However, the larger, more global your organization, the more architectures, versions, and configurations you are likely to be dealing with.
I mentioned in an earlier column that you can store x64 and x86 volume images in the same Windows Imaging Format (WIM) file—but you will not save space. If you're building a recovery solution and need to account for both architectures, you should store each in a separate WIM. Similarly, if you are deploying and supporting both Windows XP and Windows Vista, you won't realize savings by storing both operating systems in the same image. The only savings you will see are if you are including many instances of the same applications (for instance, the 2007 Microsoft® Office system) in both deployments. Then the application files don't have to be stored multiple times, but this is still unlikely to lead to significant space savings.
Windows PE Boot Methods
Windows PE 1.6
PXE boot from Remote Installation
Service (RIS) (no RAMDisk)
Hard Disk Drive
USB Flash Drive
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB Flash Drive
RAMDisk Hard Disk Drive

Windows PE 2.0
RAMDisk PXE
RAMDisk CD/DVD
RAMDisk USB Flash Drive
RAMDisk Hard Disk Drive

PXE Boot from RIS is optimal if you need PXE, but it's worth noting that this method takes longer to boot and consumes more network resources than a PXE RAMDisk.
Hard Disk Drive uses minimal memory but locks the drive. This method is ideal if you are using a dual-partition flip-flop recovery scenario.
USB Flash Drive makes booting convenient; however, UFD (for both RAMDisk and non-RAMDisk scenarios) is haphazard if booting systems have not been verified by the OEM as UFD bootable and don't have a Windows Vista Capable logo (which ensures UFD boot support as a logo requirement). UFD boot requires a high-performance flash drive (for both read and write) as well as Hi-Speed USB support from the USB controller and the BIOS.
RAMDisk Boot (in all its flavors) requires more memory, but delivers optimal performance and gets Windows PE out of the way by putting it into a RAMDisk in memory. RAMDisk boot of Windows PE 1.6 should generally only be used on systems with at least 256MB of RAM. Windows PE 2.0 (which is always a RAMDisk WIM boot) should in general only be performed with systems that have at least 384MB of RAM.

Note, though, that there are significant space savings when you store multiple SKUs of a particular version of Windows in the same WIM. For instance, suppose you combine Windows XP Professional with Windows XP Tablet PC Edition or Windows Vista Business Edition with Windows Vista Ultimate Edition—these combinations make efficient use of space since two SKUs from the same release and service pack level share much of the same code and files.
Finally, language comes into play. The larger an organization, the more languages it will need to take into account. With Windows XP, you can choose to use localized builds or Multilingual User Interface (MUI). With fully localized builds of Windows XP, almost every little string has been localized into the destination language. With MUI, on the other hand, the base language is English while MUI language packs (and later, Language Interface Packs) have changed as many language strings as possible. (MUI had fair results in Windows 2000 and much better results in Windows XP and Windows Server 2003.)
If your organization uses MUI, you get quite a good return when combining various language versions in the same WIM. This is because they all use English binaries at the core. This is not the case, however, for localized versions that came prior to Windows Vista. Since the binaries themselves are localized, the same binary won't match across languages, meaning you have to store almost the entire operating system (and any localized applications) for each language.
With Windows Vista, you can think of localized versions (localized as a part of a single binary with resources inside it) as deprecated. Windows Vista uses .mui resource files for each language—including English. Essentially, Windows Vista is language-free while almost all language information lives in MUI files. Thus storing more than one language version of Windows Vista in the same WIM will result in significant space savings. Storing two, four, or more languages as one WIM means that you do not need the image to grow dramatically—and you can switch or add languages later as your requirements change.
In short, when building your solution, you should take into account which versions of Windows, as well as which versions of other applications, share identical binaries, allowing for single instance storage of files. This will help you to determine how many WIM files you need across your entire organization.

User Scenarios
Generally, the larger an organization becomes, the more complicated it becomes. This is not simply due to sheer size, but because of all the variables that are introduced—you have more users and more business units, with more specific needs.
I recall a specific multinational organization—it had tens of thousands of users and had a deployment process that was all managed from one location, geographically and organizationally. The person who ran this organization always presented some very challenging questions. For instance, he was concerned about some of his remote users in certain parts of Africa who often didn't have a good network connection—in fact, many of them were hundreds of miles from a telephone line. He needed to know how these users could recover their own systems without being down for days and without having to travel great distances.
When you develop a product—and in this sense, you should think of your recovery solution as a product—you need to think about your users. Think about specific business needs, but also think about the various complexities associated with the different categories of users. You should incorporate use cases, using short descriptions, to describe each type of end user you need to support. These can help you recognize any users accidentally left out of your recovery solution and ensure that you take the needs of each type of user into account.

The Right Version of Windows PE
Another important decision is determining which version of Windows PE is right for your needs. Previous installments of this column may help, but I'll try to make the decision a bit clearer here. If any of the following are true, you should use Windows PE 1.6:
  • You are only recovering Windows XP (or Windows Server 2003)
  • You are recovering any systems that are not Advanced Configuration and Power Interface (ACPI) compliant
  • You are recovering any systems that do not have at least 512MB of RAM
  • You are recovering any systems that need to Pre-Boot eXecution (PXE) boot with less than 256MB of RAM
If any of the following are true, you should use Windows PE 2.0:
  • You are only recovering Windows Vista (or Windows Server 2008)
  • You are recovering Windows Vista as well as Windows XP
  • You are utilizing BitLocker™
Note that ImageX (see the section "Create, Update, and Store") and most third-party imaging solutions will work fine with either version of Windows PE.

Booting Windows PE
The next thing you should take into account is how Windows PE will boot. User scenarios play a key role here. Is it realistic for your users to tote around CDs or DVDs for recovery? Will they be able to throw them onto a laptop while traveling? And how will you keep this recovery media up to date? Recovery images on removable media can get stale very quickly.
Far and away the most common scenario I've seen is the secondary hard disk partition. Another option is PXE booting. Or you could look at using external USB drives or even USB Flash Drives (UFDs)—but beware that the hardware in question must explicitly support booting from a UFD device.
The "Windows PE Boot Methods" sidebar outlines the supported methods for booting each version of Windows PE and provides some important considerations about each method.
Your goal for booting Windows PE should be getting the recovery process started while meeting certain criteria:
  • With minimal user interaction
  • With minimal moving parts (removable media or removable devices)
  • While the PC may not have network connectivity
  • While the PC may not be able to boot locally (Windows is failing to boot)
Admins often consider putting Windows PE (flat or in a RAMDisk) on the hard disk as a non-viable option due to concerns about drive failure. But the reality is that this is viable given the reliability of disks today and the fact that if the physical drive actually fails, the user will not be able to recover their system themselves anyway.
My preference is to create a secondary partition and store the recovery image there. I'm not a big believer in making the partition hidden—that just mystifies users. Using an access control list (ACL) on it isn't viable, either—unless your users are not local admins.
By shrinking the partition used for Windows (see the sidebar "Making a Recovery Partition"), you may be able to create enough space to store Windows PE and your recovery image. To place Windows PE on the secondary partition, you simply create the appropriate boot sector on the recovery partition and place Windows PE on that partition (the documents included in the Windows AIK and earlier versions of Windows PE explain this process, so I won't drill into it here). The key thing to remember is that the partition used to boot is determined by which partition is marked active. Diskpart features an active flag and an equally important inactive flag. To boot the recovery partition from within Windows (or from within a copy of Windows PE), use diskpart to switch active partitions (see Figure 1). The following is an example of a diskpart script (use diskpart /s nameofscript.txt) used to switch a single disk, dual partition system:
SEL DIS 0 
SEL PAR 1 
INACTIVE
SEL PAR 2
ACTIVE
EXIT 
Figure 1 Diskpart changing the active partition (Click the image for a larger view)
This is the process that many consumer recovery tools use to flip-flop partitions—something that can only be done from within Windows PE for certain partition types, such as hidden OEM partitions. Sometimes these tools will also unhide a hidden OEM partition type.

Create, Update, and Store
Making a Recovery Partition
The process of making a recovery partition while leaving Windows intact is not difficult, once you know the steps involved. Here's a quick run-through of what you need to do. Note that this process requires Windows PE 2.0. While you may not be using Windows PE 2.0 for deployment or recovery, you must use version 2.0 for this task. This process can also be used when deploying Windows Vista and to create a boot partition to be used for the BitLocker boot files, as BitLocker requires at least two partitions (one for boot files and one for the remainder of the Windows system).
  1. Defragment your disk (this can help speed up the shrink process, which takes a considerable amount of time)
  2. Boot to Windows PE 2.0
  3. Run diskpart (if you want, you can create a script for steps 4 through 9 and pass diskpart the following argument: /s name_of_your_script
  4. SEL VOL 1 (or the volume you want to shrink)
  5. SHRINK DESIRED=N MIN=N (specified in megabytes, DESIRED is the goal and MIN is the absolute minimum you need)
  6. When shrink has completed, run SEL DIS 0
  7. CRE PAR PRI (you can specify SIZE=N if you want to specify a size other than the disk remainder)
  8. ASSIGN LETTER=N: (this letter is just for use under Windows PE)
  9. Exit diskpart
  10. FORMAT N: /Q /Y /FS:NTFS (NTFS formats the new partition)
  11. Run bootsect N: /nt60 for 2.0, /nt52 for 1.x)
  12. Copy your desired Windows PE files to the recovery partition
  13. Shut down system

While ImageX is a freely available solution, you may already have an imaging tool you've been using for a while. You can use whichever tool you are most comfortable with. If you are considering ImageX, there are a few things worth noting about it that I like (besides the great price). In particular, ImageX is aggressive about compression. Also nice, an image can be appended to and edited relatively easily.
I also like that ImageX allows you to non-destructively image one or more volumes, letting you preserve user data by simply moving it out of the way. In other words, when recovering Windows, you don't have to obliterate the entire volume.
Then, of course, you need to decide where to store the image. Assuming your solution uses a recovery partition, you can store a WIM or other imaging file there. You may even consider using Windows Deployment Services (WDS), creating a standard OS image and storing it up on the network. This allows for a common recovery solution that is available across your entire infrastructure. Of course, if you have users in the field (such as the workers mentioned earlier in remote parts of the world), you'll need to ensure they have their own solution available when they can't get to the network.
I mentioned before that you can use media, such as DVDs, but there are a number of reasons I personally don't like this option for general use. For instance, the size of an image can quickly grow beyond the size of a DVD, and disks like this can't be easily updated. That isn't to say optical media doesn't have a place; you just need to consider which scenario is best for which types of users. My preference, if you haven't figured out by now, is to store the image either on a recovery partition, on a USB hard disk or flash drive, or, when viable, on the network using WDS.
One aspect that makes WDS an attractive choice is that a centralized image can easily be updated. You should all know by now that Windows Updates come out every month and the updates are usually critical. Engineer your solution in such a manner that the recovery image is as up-to-date as possible. With WDS, you can update the image on each server and it is complete.

Concerns about User Data and Settings
There are a few issues you should bear in mind when engineering a recovery solution. A key aspect of planning any recovery solution is ensuring that your user data is also safe. You don't want a user in the field performing a recovery just to discover that she lost all her important data in the process. Ideally, you'll want user data stored somewhere other than on the C: partition, unless you are careful about how the system recovery is handled.
I mentioned earlier that ImageX lets you non-destructively restore a disk. For example, it will move the existing Documents and Settings (or Users) directory tree to another directory so a user or a script can manually recover files after the recovery is complete. Users who store all of their files under their profile or who use Roaming Profiles should, in most cases, be able to recover a system without losing user data. But it is important to remember that unless you very carefully craft your recovery solution or you have a perfect backup solution, you may still lose some amount of user data.
Remember that despite all your planning, some users will store information in locations other than their profile. You should ensure that your solution takes into account that it may blow away user data by accident and warn users before doing so.
If you use Encrypting File System (EFS), make sure you have your key recovery plan executed—you don't want to lose data due to unrecoverable encryption. Similarly with BitLocker, be sure you are prepared to recover volumes encrypted with it. This means using Windows PE 2.0 (1.x cannot interact with BitLocker). For more information on BitLocker recovery, see blogs.msdn.com/si_team.
Finally, be prepared for the fact that some users will be upset when some of their customizations or applications have disappeared. Customizations (for applications and Windows itself) are stored in some random places, not just in the user profile. When restoring the entire OS partition, some users will call to ask "where has x gone?" or "Why doesn't Word show y anymore?" Set expectations among users so they know the environment might not be exactly the same as what they had the day before.
Creating your own recovery solution with Windows PE takes time, and you need to think about your users as you plan and engineer the solution. A recovery solution doesn't need to be overly complex—it just needs to be something that gets your user back up and running in a minimal amount of time with limited technical support.

Wes Miller is a Development Manager at Pluck (www.pluck.com) in Austin, Texas. Previously, he worked at Winternals Software in Austin and at Microsoft as a Program Manager and Product Manager for Windows. Wes can be reached at technet@getwired.com.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
Page view tracker