Custom Win PE Boot Disk Building: Start me Up!

With deference to The Stones…

This is the second part of failure related to getting my custom Win PE 2.0 boot disk finally up and running.  It actually provided the material needed to make my Eureka moment.

Summary

The purpose of this ongoing project is to build a Win PE 2.0 based boot-disk, that has a great VistaPE GUI interface (instead of the standard CLI shell) and the PGP WDE drivers injected so we can “liveCD-boot” a PGP WDE system (assuming we have the user’s passphrase).  Oh yes, and it has to handle the Dell GX 7xx series USB keyboard drivers.

If you are just joining us, please go back and review the following posts to get up to speed:

• Custom Win PE Boot Disk Building Saga: Introduction
• Custom Win PE Boot Disk Building: Step One – WAIK up
• Custom Win PE Boot Disk Building: Step Two – PGP Injection
• Custom Win PE Boot Disk Building: Step Three – VistaPE 12 RC1 Walkthrough
• Custom Win PE Boot Disk Building: Dead Ends Ahead!
• Custom Win PE Boot Disk Building: Driver Dead Ends

OK. Now on to the second failure.

Run it Baby!

As frequent readers of the GSD blog may have identified.  I have a love of both Windows utilities and portable applications.

I have long-ago superseded the space a common CD-ROM offers for holding all the portable tools and utilities I have collected and use.  As it currently holds, my home “standalone apps” folder contains 2.5 GB worth of programs that work just fine off a USB drive.  The majority of those work fine off a CD/DVD-ROM disk, and a significant portion will also run without fail in the WinPE/VistaPE LiveCD environment.

I also build a custom version to hand out to our technicians at work.  It has the LiveCD system boot side of things (PE 2.0) and if you put it in a running Windows system, it kicks off an auto-play feature that launches PStart with links and all kinds of structured goodness to the portable utilities I have placed on it.  The techies love it.

Some day I will have to take a week off from work and update my Portable SysAdmin Tools post with the current holdings that it represents.

So since I had been failing miserably at getting my sexy VistaPE boot Cd working (with PGP WDE drivers) and the stupid Dell USB hub drivers/keyboard, I felt I had only one avenue left; to just go back to the stripped down WinPE 2.0 CLI base build, inject PGP WDE drivers as we have seen how to do, and tell the guys and gals to be grateful for it.

Rationalizations

However, after a lunch break that day, I took off my analyst hat and put on my techie beanie to think about this from a different perspective.

The VistaPE interface delivers a wicked-naughty GUI interface for the Win PE 2.0 OS environment, and it delivers a cornucopia of custom tools, utilities, system hax0r helps, and other things that make a sysadmin flush.  I use the majority of these included tools and then many of the portable ones I bundle along on the CD for the ride.

However it is my observation that our techies generally only use it boot a system “off-line”, recover user data from it to a USB drive, and then move on to reimage the system and restore the user’s data.  The only tool they really interface with is a “windows explorer” clone (A43 or CubicExplorer).  With the exception of CLI work with ImageX and DiskPart, that’s really it.

So, maybe….just maybe…I could hack out a way to get the PStart launcher on the “Live” side of the disk feature to kick off once the WinPE 2.0 system initializes and then they could just pick the apps they want to work with.

Yes, it’s like dropping Angelina Jolie as Lara Croft for a pale substitute, but it could be serviceable if done right.

Now how can I do that?

The Registry?

I already knew I could hack the registry of a mounted WIM file, make changes and repack.

• Windows Registry Tricks and some Processing Treats – Grand Stream Dreams blog

Maybe I could add a key for an auto-start group to kick off the PStart executable?

Long story short, this technique might work…but there are some barriers.  Aside from the technical ones with the way the Win PE handles startup items (we are getting there), the bigger issue is how do I ensure that the Win PE system is always going to find the correct CD ROM drive letter I’m running on?  I mean, some systems might have multiple drives/partitions and I have no guarantee I’m always going to end up running with the CD/DVD drive as the D:.

Nope.  This Registry launching pad ended up being a dead-end.

Off to the Googles

Now, I have always said up-front to my dear readers that I have not ever had any formal training in Windows systems administration, Microsoft Certifications, or other things that would be deeply useful and beneficial in my job assignment.  Nope.  It all due to years of collegiate honing of my brain, growing up with an ex-army officer dad, and an inordinate curiosity about trying to figure out how things work, and remembering (generally) everything I encounter technically.

So I did some searching on the Net and l pulled up a very important bit of info that all Win PE students should probably be familiar with.  From that TechNet article:

Windows PE provides three methods for launching custom scripts: Winpeshl.ini, Startnet.cmd, and Unattend.xml. The Windows PE default interface is a Command Prompt window. However, you can create a customized Winpeshl.ini file to run your own shell application. You can also create your own version of Startnet.cmd to run a specific set of commands, batch files, or scripts. Unattend.xml is a new answer file format for Windows PE 2.0, which replaces Winbom.ini and Winpeoem.sif.

I’m an Idiot

You mean all I have to do to kick off something “custom” from a Win PE startup is either modify an .ini file or write a custom batch-script and save it in the right location/name?

For more than a few hours I felt like this:

(I’m An Idiot – xkcd.com)

After a while of fiddling with and boning up on both the Winpeshl.ini and the Startnet.cmd methods, I ended up concentrating on the startnet.cmd vector.

If you mount a base Win PE 2.0 WAIK wim and take a look in the startnet.cmd file (to be found at the %SYSTEMROOT%\System32 location), you will see it contains a single line:

wpeinit

That’s it.  This ensures plug-n-play/networking support. 

Wpeinit is a command-line tool that initializes Windows PE each time it boots. When Windows PE starts, Winpeshl.exe executes Startnet.cmd, which launches Wpeinit.exe. Wpeinit.exe specifically installs PnP devices, processes Unattend.xml settings, and loads network resources.

I wanted to custom launch PStart, and needed a way to identify which drive letter I was running from in my batch-process so I could call to the correct location to execute PStart.

I found this great tip:

RunOnceEx from CD – by Alanoll at Unattended Windows site

After much coding, wim mounting, changing files, saving wim changes and Virtual PC session testing of the modified WIM I arrived at a realization.

This method works, you can get it work, but it is pretty clunky and once you have seen Angelina Jolie as Lara Croft, substitutes just don’t satisfy.  Sorry.

I searched through various forums and found many great and custom examples of both startnet.cmd and winpeshl.ini files and the more I read, the more I understood.

Wait for it….

Maybe I needed to reconsider my choice of focus on startnet.cmd and use an alternative Windows shell loading under the winpeshl.ini instead.

VistaPE uses BS Explorer. Maybe I could make up my own WInPE 2.0 using that custom one.

There are a number of others to check out if alternative Windows shell replacements are your thing. Most are freeware/OpenSource/shareware products. Some are commercial ($).  I am familiar with many of them, but have not tested any of them for compatibility and support in the Win PE environment.

• Aston Shell
• BB4Win (BlackBox for Windows)
• BBLean website
• Bluebox Win32 alternate shell
• Emerge Desktop
• Hover Desk
• LiteStep
• Secure Desktop 7
• SharpEnviro
• Talisman Desktop 3.0

As I was working this avenue out I decided to load up the resulting VistaPE WAIK build WIM file to take a look at what was going on there.  Maybe I could get some more pointers.

So I mounted the vistape.wim file I had previously created and took a look starting with the critical files I had learned were valid Win PE 2.0 launching points.

By this time I was fairly comfortable looking for and interpreting the structure of these particular files, and I surmised that VistaPE must be using something similar.

It was.

[LaunchApps]
vpeldr.exe
"x:\Program Files\BSExplorer\Explorer.exe"
cmd.exe, /k

This seemed too simple.  I then investigated the vpeldr.exe (VistaPELoadeR perhaps). Next to it was a vistape.cfg (configuration) file.  I opened that up to take a look and…

Eureka!

Instead of re-inventing the wheel, what would happen if I extracted the core elements I needed out of a compiled VistaPE project and “injected” it in the Win PE 2.0 build WIM that was already meeting three of my four critical custom Win PE 2.0 needs?

1. Win PE base to boot a Windows system off line. (check)
2. Injected PGP WDE driver compatibility. (check)
3. Loads Dell Optiplex 7xx USB keyboard drivers natively. (check)
4. Sexy VistaPE shell GUI. (still missing)

The solution to #4?

Next post.

--Claus V.