WinPE Bootable UFD

Secunia Flags Flash10a.ocx as threat, but clean-up requires some contortions

Now that I’ve been running Secunia Personal Software Inspector (PSI) on my Vista machines for about three months I’m starting to learn a little about this program’s behavior. Last Friday, Secunia notified users about an important update to Adobe Flash, part of which involved replacing an older version of its ActiveX control for Explorer with a newer version. This involved installing a package that included a file named Flash10b.ocx, which replaces Flash10a.ocx.

Apparently the installer is not only supposed to add Flash10b.ocx to the %windir%\System32\Macromed\Flash directory, it’s also supposed to delete the previous version, Flash10a.ocx as well. The problem is, deleting ActiveX components you use requires that they be unregistered first. To do this for the aforementioned file, enter this string at the command line:

regsvr32 “C:\Windows\SYSTEM32\Macromed\Flash\Flash10a.ocx” /u

On the other hand, you could use your handy-dandy WinPE boot UFD to reboot the machine and delete this file without having to unregister, because you’re then running inside a different Vista runtime that isn’t using that ActiveX control. However, a double reboot takes at least 5 minutes on my Vista machines: once to boot into WinPE, and again to return to a normal Vista runtime environment after deleting the file. On the other hand, unregistering this ActiveX control takes less than ten seconds. Thus, it’s easier and faster to unregister the file first, then delete it without resorting to the UFD. You can even write a short batch file to automate the entire process, and deploy it around your network to Vista desktops.One more thing: before you attempt to delete this file, please close Secunia PSI as well. If you leave it open, it will hang onto a handle to this file. And of course, that too will prevent you from deleting it.

Those readers who’ve followed my advice and have installed PSI or CSI (the newly-renamed “Corporate Software Inspector” or CSI, that replaces the older NSI for Network Software Inspector) may benefit from this tidbit of information, if they haven’t figured it out already for themselves. As foibles go, however, this one’s pretty minor, and would only require Secunia to add a short note to this effect in their clean-up instructions. I’m still glad to have Secunia in my corner, though, and since I’ve started using their software inspectors my machines have kept up with patches, fixes, and updates on a more-or-less a same-day basis, except for occasional weekends or holidays when I choose not to check on my growing collection of PCs.

A Fabulous WinPE Resource: VistaPE

As I’ve learned to build various types of bootable CDs and UFDs with the Vista-based WinPE environment, I’ve also been working to learn more about its inner workings and capabilities. As I struggled to figure out how to add Windows Explorer and some kind of Web browser to a runtime WinPE image (which usually takes the form of a Windows image file named boot.wim or something similar) I discovered what might not unfairly be called the “ultimate Windows PE resource.” It’s a Web site that serves a very active and capable developer and user community called VistaPE.

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!

Using the WinPE Boot UFD, Part 1

This weekend, I was fooling around with my Windows Home Server machine (a very nice HP EX475 MediaSmart Server) and found myself forced to repeatedly reinstall the Windows Home Connector software on one of my client machines. As I would learn from HP Tech Support, I was as much a victim of my own stupidity or lack of careful consideration of my install environment–I’ll tell you what happened to me in a minute, and you can make that call–as I was a victim of limitations in the software itself.

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.

Create a bootable WinPE UFD

Everybody knows what a UFO is, but let me remind readers that Microsoft interprets UFD as “USB Flash Drive.” Thus, what I’m about to describe is best understood as how to create a bootable Flash drive that includes the Windows Vista SP1 Pre-boot Environment (aka Window PE or even WinPE). Interestingly, if you simply troll TechNet or the Microsoft Download Center, you’ll be directed to Windows Automated Installation Kit version 1.0. But if you’re working from post-SP1 Vista (as most readers of this blog probably are), you really want Version 2.1, which is designed to support that environment. You’ll find that on the download page entitled “Automation Installation Kit (AIK) for Windows Vista SP1 and Windows Server 2008” instead.

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.