Sometimes things are just too automated–a cautionary tale

It’s been a very long time since I’ve written anything on this blog, as the very observant of you are likely to notice.  I’ve been involved in some pretty amazing projects here in Windows, and I haven’t had much time for anything other than those projects – which I hope to be able to talk about very soon.

However, my lack of blogging isn’t the focus of this post.

I’m writing this post on my newly rebuilt system, with a fresh, new copy of Windows installed to tell you why I’m writing this post on my newly rebuilt system with a fresh, new copy of Windows installed.

Those of you who have read some of my Hyper-V Setup-related articles in the past probably recall that I’m very fond of the Windows Automated Installation Kit (WAIK for short) for all things deployment.  It’s filled with tools and documentation which are absolutely priceless (literally… they’re free…) if you’re doing any sort of Windows deployment, whether on physical machines or in VMs.

As I said in my very first post on this blog, I’m a former Microsoft MVP for Windows Setup and Deployment, so I’ve become addicted to automating Windows Setup.  It’s what I do.  For every machine I own, at home or in my office, I have an unattend file created that will put a brand new copy of Windows on it, and configure it exactly how I want; and the only thing I have to do is put in a USB stick.

And that’s where the trouble started.  Some of you can see where this is going, I think.

Earlier this morning, I created a new VHD with WIM2VHD and configured it for native boot because I needed to test some things in that particular OS.  After closing my programs, I clicked restart and started reading some e-mail on my laptop while my system rebooted into the new OS.  I was half-way through an e-mail when, out of the corner of my eye, I noticed something odd on my monitor.   I noticed Windows Setup was running.  From the very start – not from the “detecting your hardware” phase. 

Dumbly, I sat and started at the monitor for a minute.  The caffeine from the tea I was drinking had not yet reached my brain, and although thinking was hard, I managed to force a bit of internal dialog:

“Why in the world is it showing me that screen?”  A few seconds passed.
”I shouldn’t be seeing this.  Is this a bug?”  A few more seconds passed.  Windows Setup began expanding files, and the word “USB” floated through my mind, searching for something to connect with.
”Yeah, I should probably file a bug on this.  This shouldn’t happen unless I …”

My eyes widened as my brain finally compensated for a complete lack of caffeine, and began madly pumping gratuitous amounts of information.  

I had left one of my bootable USB sticks plugged in.  And that USB stick contained an autounattend.xml file.  And that autounattend.xml file contained a section instructing Windows Setup to wipe my disk and set up new partitions.  I’m not entirely sure why I did what I did next.  I lunged towards my computer, ripped the USB key from the socket, and threw it across the room.  Perhaps on some primal level my brain reasoned that I should put as much distance between the thing I wanted to protect and the thing that was hurting it.

Unfortunately, that didn’t help too much, though I did find a Bluetooth adapter that I’d lost a few months ago when I went to retrieve the USB stick.  The Bluetooth adapter was not as comforting as you might think.

And so it came to be – I was bitten by my own drive for the perfect non-interactive Setup automation.  I wanted to share this story with everyone because this really is the sort of thing that just happens sometimes (that’s what I keep telling myself, anyway).  Automating common processes is great, and everyone should do it if they can.  But sometimes, it comes back to bite you.  Just be careful.  That’s all I’m saying.

Oh, and I now have a new rule.

• From this day forth, autounattend.xml files will live on a different USB stick than the bootable Setup media.  Hopefully I’ll remember to unplug one of them, at least