This low-res screen cap of the Recovery Environment describes your Vista Repair options:
here, you want to pick Windows Complete PC Restore.

On most of my Vista machines, it takes in excess of three minutes to get from the Vista install DVD to the System Recovery Options menu shown in the preceding screen capture, and it can sometimes take more than 10 minutes to pop up (as when finding and fixing boot-up issues, as it sometimes must). If you follow the instructions I provide in a recent story for Tom’s Guide “How to Make and Use a Bootable WinPE Drive” you will learn how to use the install media and the Windows Automated Instllation Kit (WAIK) to create a bootable UFD with the Vista Recovery Environment at your disposal. Unlike its DVD-based counterpart, however, this little gem usually presents itself on-screen in under two minutes, which lets you get to work far faster (on the notebook in question, the screen popped up in 1:07).

I was forcibly reminded of this yesterday, when I installed a new driver on one of my test notebook PCs, only to discover that the device went missing upon reboot, and that System Restore was also unable to roll back to the preceding restore point (I later learned this comes from a side effect of Norton security products, as documented in this Symantec page on the “Restoration Incomplete” error also produced during this process). What to do when restore points won’t work (and you don’t yet know how to fix that problem): use the Recovery Environment and a recent backup to restore your system to a pristine state. Luckily for me, I had just backed up my system the night before so I was back up and running in under 15 minutes, restore and all. This time, I skipped the IDT HD Audio driver update that started all my problems, and then went off to research exactly what happened, and why. In a roundabout way, all this led to today’s blog post.

Nevertheless, I was glad to have had this handy little tool at my disposal, which I’ve already used to repair Vista on a couple of machines since building the WinRE UFD in late January. You might want to add one of these to your toolkit. Any old UFD larger than 256MB will do: my WinRE UFD weighs in at 330 MB in all. Thus, a freebie or cheapie 1 GB UFD will work just fine for this purpose.

Let me explain what makes VistaPE tick first and foremost, then explain what VistaPE has to offer. The foundation for VistaPE is a scripting and Windows build tool called WinBuilder. It works from either Windows XP or Vista to create boot disks (and in fact, incorporates WinPE 2.0 for Vista into the Vista side of that equation), but it goes way beyond what the basic Microsoft toolkit provides via imagex.exe and the other basic elements in their toolbox. VistaPE builds on this foundation to add significant applications and capabilities on top of the WinPE 2.0 kernel to support a more-or-less complete graphical user interface (GUI) environment. Thus, the VistaPE runtime environment–which is incredibly user-configurable and flexible, and continuously extended and expanded upon through a growing script library–is more like a “real Windows” than a basic command line interpreter (CLI) environment.

Here’s how I found VistaPE: In seeking to extend my WinPE skills and abilities, I’d started trying to research methods to include Windows Explorer in the WinPE environment after reading several postings online that (a) mentioned this could be done and (b) finding no concrete details on exactly how to do so. My basic computer science training told me that it would require mapping out the code dependencies from within Explorer to determine what other DLLs and executable elements were required to make the program run. I quickly discovered thereafter that some DLLs must be registered with Windows as well as present in the runtime environment to work properly, after a simple analysis with Mark Russinovich’s dllist utility failed to produce the desired results. That’s what led me back on the research trail and, ultimately, to the VistaPE Web site.

I knew I’d struck paydirt when, after downloading and installing WinBuilder and the VistaPE script library, I was able to produce this screenshot:

The VistaPE scripts in WinBuilder make adding Explorer a piece of cake

As it turns out, adding Explorer just barely begins to describe what VistPE can do within WinBuilder. It also provides an alternate and somewhat more functional graphic file system interface tool called BS Explorer 2, and even supports the Linux-inspired Grub4DOS boot management toolset.

But beyond the VistaPE Base toolset shown in the preceding screenshot, please note the other major checkbox elements in WinBuilder’s left-column pane:

• Addons: scripts and settings for common WinPE components (WSH, MDAC, HTA, WMI, and XML), plus a GUI for diskpart.exe, common dll-based libraries for Visual Basic and more, Internet Explorer 7, PE’s network configuration tool (PENetCfg), and lots more.
• Drivers: drivers required for chipsets, LAN interfaces, storage devices, and standard VGA graphics.
• Tweaks: elements to enhance the user interface, control various applications, manage graphic shells,…
• App: add-ins for a huge library of basic applications from antivirus, to file compression, to data recovery, and a great deal more.
• OtherOS: access to other OS tools and environments for multi-boot setups.
• Finalize: tools use to complete the construction of a Windows image (.wim) file from all the preceding VistaPE scripts (which include binary code as well as assembly instructions, so you can add executables right into the boot.wim base image)
• Virtual Test: lets you load and run your Windows image file in a virtual machine to see how (and if) it works as you want it to.
• Debug: used to mount and inspect .wim files and edit Registry hives to check and fix problems.

To me, VistaPE is an entirely new and wonderful world of capability and functionality that cries out for more study and improved understanding. I’ve already been able to use it to build much more powerful and capable boot images than I had been able to hand-craft on my own. But I can also see that there’s a great deal more going on here than immediately meets the eye, or falls readily into my grasp. If you dig into this environment, you’ll come to the same realizations equally quickly yourself. Please check it out soon!

It turns out, you can also follow my instructions on building a bootable WinPE UFD, and then use the imagex utility from the Windows Automated Installation Kit to capture the recovery environment Windows Image (.wim) file from your installation media. All you have to do then is swap the boot.wim file that my process creates in your ISO\sources directory with the boot.wim file that you export from your install media, and presto! you’ve got a WinRE console that boots in under two minutes, instead of having to wait three to five minutes for the same functionality to become available from the Vista installation DVDs.

Because I’m always messing with various Vista installs, I have to resort to the recovery environment at least once a week where I work. I’m guessing that busy system admins with any number of Vista machines to care for can beat that frequency with ease. In such cases, a bootable UFD with the WinRE console ready to hand can help save lots of wait time, and enable more “work time” on affected Vista systems.

Another, perhaps more esoteric use, might be on netbook PCs where disk space can be at a premium. I’m learning how to extend the WinPE environment to run other programs, including Windows Explorer (and some claim, even IE) from within the WinPE context. Because most simple Windows GUI apps (think items in the Accessories folder, as good examples of what this means) will already run in WinPE, it’s not hard to conceive that a somewhat extended WinPE environment could be workable for netbook users seeking to slim runtime system size to 0.5GB or smaller (by itself, the WinPE I describe how to build in my previous blog is about 367 MB in size; WinRE is less than 250 MB, but lacks network drivers and access).

As time goes by, I’m sure I’ll figure out some other cool uses for WinPE as well. If you know of any, please share them with me in the meantime!

But during my troubles with the WHS connector, I downloaded and read Microsoft’s Troubleshooting WHS Connector Installation document and also grabbed its Windows Home Server Toolkit at the same time (note: this link points to the 32-bit version; a separate download is available for the 64-bit version). The only error this collection of tools and information couldn’t address was a claim of a version mismatch between my client machine and the WHS box itself; because the client actually copies that software from the server, I was mystified as to how this could be the case.

As it turns out, my client is running AVG AntiVirus 8.0 Free edition, and there’s something about this software that prevents the WHS connector from running properly on that machine and talking to the WHS box itself. I could remote desktop to the WHS server from the client, but the connector would hang as soon as it got past the login screen where I provided the administrative password that normally gives me access to the WHS console. As it turns out, something about AVG blocks IP name resolution for the server, because once the HP guy helped me pinpoint the package as the source of trouble–I disabled it, and presto! the console login completed without a hitch–a little further research showed me that adding a line into the hosts file to equate the server name with its IP address would fix the problem. And sure enough, with AVG re-enabled and the host patch in place, everything is now working as it should be.

I hope you’re asking yourself by now: what the heck does this have to do with the WinPE Boot UFD in the title of this blog? As it turns out, the help instructions for cleaning up the mismatch error that the connector troubleshooter was reporting for my notebook PC includes these instructions “On your home computer, delete the %ProgramFiles%\Windows Home Server folder if it exists. Well, it existed all right, but when I tried to delete the directory or its contents, even when using “run as Administrator,” those files stubbornly resisted deletion.

WinPE Boot UFD to the test, and ultimately, to the rescue! First, I had to change the boot device order on my notebook to hit “USB Storage Device” first. With that handled, the laptop opened a standard black-and-white progress bar at the bottom of the display, and indicated “Windows is loading files. . .”.  After a wait of about a minue, a standard “copyright Microsoft” light green progress bar flashed up for about 15 seconds, followed by a command window labeled Administrator: X:\Windows\system32\cmd.exe. To delete my resistant files I typed the following commands:

c:                                         :: change to C:\ drive
cd "C:\Program Files\Windows Home Server\" :: change to WHS directory
del *.*                                    :: delete all files
cd ..                                      :: move up one directory level
del "Windows Home Server"                  :: delete WHS directory
exit                                       :: Close WinPE (reboots system)

Everything worked like a charm and when I went back to check to the drive with Vista rebooted, sure enough those files and the directory were gone. I’ve blogged earlier about using the Linux-based TRK environment to solve this same kind of problem; it looks like this is the right Windows tool to address the same difficulty without having to venture beyond the Windows umbrella.

I’ll be working with the WinPE Boot UFD every chance I get, and keep reporting back here. If you know of any other good uses, or have an interesting and related story to tell, post a comment and I’ll put in the hopper for future coverage and inclusion, too.

You’ll download an ISO image of the latest WAIK, which you must then burn to a DVD (it’s 1.2 GB in size and won’t fit on a CD). I used Alex Feinman’s excellent Windows Explorer add-in named ISO Recorder v3 for this (and for all my iso files) but you can use any Vista-compatible DVD burning program you like to do this job. AFter that run the file named startcd.exe on the DVD to launch WAIK. This produces the following screen:

WAIK 2.1 welcome

Click the option that reads Windows AIK Setup to install WAIK on your current computer (it must be running Vista SP1, in case this isn’t completely obvious). By default this installs WAIK in the C:\Program Files\Windows AIK\ directory. Click your way through the installation screens to make the various WAIK tools available on your PC (on my desktop, this took about three minutes, YMMV).

Next, click Start, All Programs, Windows AIK, then finally Windows PE Tools Command Prompt. Inside the command window, type

Copype.cmd x86 C:\winpe_x86:

where x86 indicates a 32-bit environment and x64 a 64-bit environment, and C:\winpe_x86 is where the various WinPE binaries and directories will be created. After that you can copy tools and utilities from the WAIK Tools directory for your architecture (x86 for 32-bit PCs, and so forth) into the ISO subdirectory beneath C:\Winpe_x86. I usually grab Imagex.exe and the Package Manager, using these commands:

copy "c:\program files\Windows AIK\Tools\x86\imagex.exe" c:\winpe_x86\iso\
xcopy "c:\program files\Windows AIK\Tools\x86\Servicing" c:\winpe_x86\iso\Servicing /s

Of course, you’ll have to change the architecture designation for a 64-bit install to x64, and you’ll need to tell the CLI that the xcopy command points to a directory specification, but otherwise things should work for you, if you simply cut and paste these commands into the command window you’ll have open when you create the C:\WinPE_86 environment on your machine.

Next, you must scrub your UFD clean, mark its single partition as active, and format it for FAT32. The following sequence of commands will do the trick (replace n with the actual disk number for your UFD, use the list disk command inside diskpart to get this information:

diskpart
select disk n
clean
create partition primary size=
select partition 1
active
format fs=fat32
assign
exit

After that you need only copy the ISO subdirectory from your C: drive to the drive letter for your UFD to make your bootable image thereupon. The following xcopy command will work (just be sure to correct the drive letter at the end of that command string):

xcopy c:\winpe_x86\iso\*.* /s /e /f i:\

As you work with this boot image, you’ll probably find other tools you want to add to your toolbox. You must copy them into the ISO subdirectory on your C: drive (along with any other supporting files they might need), then reformat the UFD, and repeat the preceding xcopy command to make them available when you boot from that drive.

With a little foreknowledge about Windows PE at your disposal, you can’t help but find these Windows PE Walkthroughs (step-by-step instructions on building and using various Windows PE environments) on TechNet of terrific interest:

• Walkthrough: Create a Bootable Windows PE RAM Disk on CD-ROM
• Walkthrough: Create a Bootable Windows PE RAM Disk on UFD
  (In case this acronym is unfamiliar to you, as it was to me: UFD = USB Flash Drive)
• Walkthrough: Create a Bootable Windows PE RAM Disk on Hard Disk
• Walkthrough: Boot Windows PE from CD-ROM
• Walkthrough: Boot Windows PE from Hard Disk
• Walkthrough: Create a Custom Windows PE Image

By the time you work your way through this material, you’ll be well-prepared to deal with most of the chores related to creating and manipulating the Windows Image (.wim) files that Vista uses for installation and setup. Definitely worth getting to know, and spending some time with. I’m pitching a book on this subject right now myself, with a Web site to go along with it, in fact. WinPE is also great for Vista troubleshooting, low-level system maintenance and repair, and more as well.