The Joys of Vista Unattend Setup

  • Article

Lately, I have been fussing around with automation related to the unattend file format for Windows Vista. The reason that I am fussing around with this automation is a whole other ball of wax that I will rant about at some future time. Oh what the heck, let me rant about it right now.

<soapbox>

Pretend for a moment that you are trying to write a commandline tool which abstracts away the details of installing MS internal builds of Windows Vista into a series of commandline parameters (with suitable defaults) such that you simply tell it "install the Ultimate SKU of the latest Vista build from WinMain onto D:" and 30 minutes later, you are booted into D: drive with Vista on it.

Do you write the commandline tool:

  1. In managed code and require .Net Framework 2.0 to be installed successfully, ADO.Net access to some SQL database, and ability to write a log file before allowing the user to install Windows Vista
  2. With native/script code which runs on whatever origin Windows OS that is valid for upgrade/clean installing Windows Vista

You would *think* that approach #2 is the obvious choice. After all, you want people to adopt this tool widely within Microsoft as *the* way to automate Windows installation, so you want your tool to have minimal dependencies to fit into all possible environments. But apparently, this fact was not so obvious to the Base OS test team as they chose approach #1 to implement their tool, and now years after that fateful choice, we are still paying the price in various random ways.

Well, the IIS team is no longer paying that price. Since the Windows 2000 days I have owned the OS installation tool/framework for the IIS team, and I pretty much wrote my tool in the style of approach #2. Last Friday, after Windows Unattend setup format went through some late-breaking changes, I got fed up and finally removed its dependency on the Base test OS installation tool. And with this move, I finally regained the freedom to allow any person to install Windows Vista with the same semantic of "install the Ultimate SKU of the latest Vista build from WinMain onto D:"... except I can do this from any un-modified Windows OS from NT4SP6a on up, including WINPE.

Yeah, *that* is real componentization and taking care of dependencies. There is no need to push customized WINPE CDs with the .Net Framework and WMI hacked onto it. It just works with whatever Windows OS platform is out there in Microsoft.

Meta Rant

<soapbox>

I deem it critical for the IIS test framework to remain nimble, internally componentized, and un-attached to any particular automation system within Microsoft but ready to interoperate with any particular automation system. Why is this important?

Well, historically the IIS team has bounced between divisions every once in a while - after all, is IIS a server, a platform, a developer framework, or ??? This quandry has apparently mystified "Senior Management" since the beginning of time, and they keep changing their minds... so major reorg shuffles that pluck IIS from one division into another division happen frequently. Personally, I have seen IIS shuffled between four divisions the past six years, so I deem it likely that it will continue.

And when the earth shakes from a reorg, IIS test team should not need to re-write their test automation simply because one division's "automation" framework does not work with the other's. To do otherwise would be a waste of time. This is why my "IIS Internal" OS installation tool/framework exists - to buffer the IIS team from the chaos that is all-around. Incidentally, all IIS partners end up using it as well because it is just simpler to use, interoperates well within their diverse environments, and provide a simple way to "get IIS7 onto the box."

Of course, my pragmatic opinion is in contrast with the views of the test architects who are pushing for ONE single automation system across all of Microsoft as the end-all solution. And to that, I simply wish them good luck. In general, I am not in favor of changing for change's sake - by changing, I better get something worthwhile that I do not otherwise have - and extrapolating that out suggests that this ONE system better do it all for everyone or else it is a waste of effort to migrate. And I think that when you have a system whose goal is to be everything for anyone, it ends up being nothing for everyone.

</soapbox>

Anyways, my point is not to berate the test organizations. I simply think that they cannot help themselves but be helpless victims to reflect the same microcosm of MS product groups and customers, just internally at Microsoft. After all, who doesn't want to be the "Windows" of testing at Microsoft? ;-)

</soapbox>

Ok, where was I? Oh, yes, I was just talking about the unattend file format.

Now, one of the improvements made in Vista setup is the correct identification and lettering of the drive partition to install to.

  • With the old WINNT32.EXE, you can only use /tempdrive to specify the drive letter of the partition to install to, and the drive letter remained the same after the OS installation (well, unless you give /syspart on the commandline or use OemInstallPath in the unattend file to install drivers and cause the drive letters to re-enumerate, at which point you have NO idea what drive letter is assigned to your target OS partition).
  • With the new SETUP.EXE, your unattend file merely specifies the Disk and Partition ID (via a new scheme, of course) to identify which partition to install to and the drive letter to assign to that partition after OS installation, so you always know what drive letter your target OS will be on, and you can always unambiguously determine the right partition.

This is generally goodness... except if you are the author of an OS installation tool that must provide the semantic of "install the Ultimate SKU of the latest Vista build from WinMain onto D:". What is the trouble?

  • Well, with WINNT32.EXE, the job is easy. Just specify:  /tempdrive:D  and be done with it.
  • However, with SETUP.EXE, you only know that "D" is the drive letter of the target partition. You now have to figure out the Disk and Partition ID (via new scheme) of "D" relative to the origin OS and provide that in the unattend file. This is completely new code that has never existed.

Well, the code to do this calculation WAS only in the Base OS Test team's tool, locked with a managed code dependency, but no longer. With the help of some Base OS setup developers, I wrote a little commandline utility to calculate the Vista-compliant Disk and Partition ID given a drive letter (all native code, of course), so now, any automation developer can use it to provide the nice user semantic.

Of course, it begs the question why shouldn't the Vista unattend file format just take another parameter, "source drive letter", as alternative to Disk/Partition ID, to make this job easier for folks like me. After all, I just took code in SETUP.EXE, refactored and revised some of it, and turned it into the commandline utility...

Oh, and don't ask me how you are going to get this utility. I haven't thought of how that is going to happen yet. It is just way too logical. ;-)

//David