This will be the first of a series of posts that I really have wanted to compose so badly I’ve been avoiding it like The Plague.
It’s not that I don’t want to share the information and tips/tricks I have learned by myself and from others.
It’s that I’m still having a very difficult time deciding how to organize the material. I think I have a sufficiently semi-logical outline developed and will be now starting an extended series of posts.
Hopefully some folks will find the information useful.
I’ve been building “LiveCD” boot disks for many years now once I figured out the benefit it could have for our IT team. D-Man and Mr. No at work paved the way before my joining the crew with some early bat.file DOS boot floppy work.
Not to be outdone and to show these god-like analysts I could bring-it, I soon had put together a CD that had an auto-run menu which would allow technicians (as I was at the time) to pick from various Windows utilities and setup programs. It was cool and an instant classic. It did not, however, contain system-boot support.
This was back before USB drives were common place, so to copy user data from a OS-dead system either meant removing the hard-drive and placing it in working system, or booting with a DOS boot disk and copying data to 1.44 MB floppies. Not cool, even in old-school times.
In the Beginning there was Novell…
Since we were on a Novell network, I began building and implementing with Erwin Veermans NwDsk: NetWare Boot Disk (IP/IPX). With some fairly easy Cd-Fu building I had quickly created a CD that could be used to boot a system from and connect to a Novell server volume. Then data could be copied up bypassing the need for floppies. Meanwhile the autorun menu/utility side still worked if the CD was put in a normally running Windows system.
That worked great. However there was one little problem. Most all of the technicians didn’t really know or like working in command-line.
Give me a break.
DSL Build Period
So from there I gradually moved from the NW boot disk to Damn Small Linux (DSL) as the boot tool. This provided a more usable GUI interface that I was able to customize while still being small enough for me to keep my Windows auto-play side intact. I really had a blast learning all the Linux stuff to build and customize a booting ISO file. Local off-line system files could be FTP’ed to the Novell volumes. Perfect!
That worked even better and was very pretty. However there was one little problem. Most all of the technicians didn’t really know or like working in Linux.
BartPE Build Period
So I then found and started building Win PE 1.0 based Bart’s Preinstalled Environment (BartPE) boot disks. This was way-cool. Now I could build boot CD’s with a GUI based on XP. Still preserving the Windows auto-play menu side. Perfect right?
We were still a Windows 2000 shop and the Win PE 1.0 licensing requirements are very stringent. I had to have sufficient XP licenses to cover them, which we only had a handful. So I could only build and distribute a few. Eventually we upgraded from W2K to XP so I was freed up. Still had to FTP local files to the servers, but still it was a solution.
Now it was near perfect. The technicians were happy and I was happy.
The Dawn of a New Era: Win PE 2.0
Then came Win PE 2.0. It was based on Vista, supported ImageX, and could do tons of really cool things and effectively had none of the onerous licensing that Win PE 1.0 carried. I saw stars in my eyes and quickly worked out building a custom CD that still let the Windows auto-play menu work on a live system.
Only it was command-line based and again, despite all attempts, no one except D-Man and Mr. No thought it was worthwhile. It languished and BartsPE ruled.
That was until I found VistaPE. It is very similar (in theory) to BartPE but provides a wicked cool GUI to the Win PE 2.0 base. For a sample, check out these GSD posts VistaPE Builder Tutorial - Highly Advanced (and Fun!) and VistaPE WinBuilder 011 - Basic Walkthrough. Now we are at awesome-cool.
Away I went and everyone was amazed. Vista LiveCD boot goodness and sophistication along with my now ingrained Window live auto-play utility menu. Happiness. And not only could technicians still FTP files up to the server if needed, Win 2.0 would flawlessly auto-detect and mount USB storage devices (which had by now become the defacto standard for file-recovery and transfer). FTP became a rare activity. Just copy/paste. Done.
Storm-clouds on the horizon…
With the OS march from Win95/98 to Win2K/XP, the auto-run menu launcher I had been using on the Windows side of the CD was showing its age. It was based on 16-bit programming and now took too long to launch under 32-bit OS systems. It would eventually, but not snappy like it did under Win95/98 when I had started using it. I tried various replacements and eventually changed over to Pegtop PStart . So while it wasn’t as nice a GUI for the menu structure I had been using, making updates was a snap and it could do a lot more tricks. It was back to snappy menu loading again.
The real storm came when we began the conversion of our desktop systems to Dell Optiplex systems (745/755/etc). These models dropped PS2 connector support and were now all USB driven. The standard keyboards were also USB devices with USB ports on the back.
Suddenly the VistaPE disks showed a serious problem. Turns out that the VistaPE driver-loading process they use would render the Dell USB keyboards dead when the boot-disk side was used. Yes, the mouse still worked, but it was of little use. I hacked a temporary solution of installing and auto-launching On-Screen Keyboard Portable but while this worked, it was not sexy or convenient.
So I never distributed it and have spent the last many months trying to hack-out a working fix for that Dell 755/745 USB keyboard driver loading problem under VistaPE with little success.
The keyboard would work fine under the plain “original” WinPE 2.0 disk build, it would work fine under a VistaPE (Vista RTM setup disk source) build. It would not work under the VistaPE (WAIK source) build.
Since the D-man had provided me a legit copy of a Vista RTM setup disk I thought I was in good shape again. The Dell USB drivers would load and the keyboard worked again under that build strategy.
Then the ceiling came down…
Recently a decision was made higher up to deploy PGP whole disk encryption across all our desktop/laptop drives, enterprise-wide.
That is a Very GoodThing™.
Only here’s the new problem. If the entire drive is encrypted, what use will a Live Boot CD be? The system and user files were now securely tucked away out of sight! PGP does provide their own PGP off-line recovery disk but I didn’t care for either the interface or the nature of the tool in general. No offense to PGP but it wasn’t what I was interested in.
Leave it to clever Claus. I wasn’t about to abandon all this work and investment, just yet at least.
PGP, PE 2.0, and VistaPE building: Let the migraines begin
Turns out, PGP does provide a way to inject their WDE drivers into a PE 2.0 disk build.
- Windows Preinstallation Environment & BartPE Tools – PGP Knowledgebase Answer ID 807
After some initial joy and effort working out frustrating typos in the document, I was successfully able to build a merged PGP/WinPE 2.0 boot disk.
Then a dead-end as I didn’t want to go back to giving a CLI WinPE 2.0 disk out to the technicians again. I knew from experience that they would never use it.
See this works for the pure Win PE 1.0 / PE 2.0 disk builds (and some BartPE stuff), but was not at all designed to support VistaPE builds.
However I knew the VistaPE was based on WinPE 2.0 so it “should” work, somehow. More clever hacking and experimenting and I actually worked out a way to inject them into a VistaPE build!
Only (yep) it would only work under the VistaPE WAIK-based builds, which as you will remember has that awful Dell USB keyboard driver killer problem. No good unless I reverted again to the on-screen keyboard solution which as a non-starter to me.
D-Man tipped me off on a technique to try and while initial efforts looked positive, I eventually had to mostly abandon that path. I did learn a lot of extra stuff in that process regarding WIM driver injections, off-line registry editing, WIM mounting and manipulation, and VistaPE driver supplementing, and untold other really cool things. Heady stuff! But it didn’t get me anywhere...so I thought.
Using the techniques under a VistaPE RTM-Vista disk build rendered a BSOD during the driver-load process due to a driver conflict between something and the PGP encryption system drivers.
Unfortunately I was back to square one.
A New Era Arrives!
Then in the very busy days leading up to the Thanksgiving holidays, somehow in all the ongoing work crossing my desk, I found time to pick at this whole thing from a fresh perspective.
All those disconnected facts and bits must have reached critical-mass.
I managed to re-evaluate all that I knew, what I didn’t know, and make one last attempt at it, shedding all my previous building techniques and taking a fresh approach that would make Victor Frankenstein proud and VistaPE’s NightMan developer cringe from my non-script-based hacking of VistaPE, the WinBuilder platform, Win 2.0, and the WAIK tools.
When I left work for the holidays that Wednesday night, I had on my desk a VistaPE-based boot disk CD, based on a WAIK build, with a custom desktop wallpaper of my own choosing, that worked on Dell Optiplex 755 and 745 (in fact all our desktop/laptop system models as yet tried) with full working keyboard support, Imagex drive capture and reimaging support, and PGP whole drive encryption support to allow decryption of the system drive(s) with the user’s passphrase.
Oh yeah, I forgot to mention that when the CD is used on a live Windows system, my utility auto-run menu picker still works.
So in the coming weeks I will begin to share specific bits learned from this process and at the conclusion, provide Claus’s Frankenstein-ish method for you to hopefully have the same successes I did.
And if we are lucky, maybe the VistaPE building pros will help us along the way to make it even prettier.