August, 2009

In Windows Vista, the first time the operating system booted up it would run through a series of performance tests to calculate the machine’s Windows Experience Index score, and it would use these numbers to determine what operating system features such as Windows Aero should be enabled.  This process could take a while.

Fortunately, Windows 7 improves this: the initial boot-up still runs the video performance test to determine whether to enable Aero, but the rest of the tests are deferred and will run in the background at a later time.

But for those of you who are deploying identical hardware (e.g. thousands of new laptops, all with the same specs), you might want to optimize this even more.  With Windows Vista, I mentioned in http://blogs.technet.com/mniehaus/archive/2008/11/06/want-to-save-some-time-when-deploying-windows-vista.aspx that there was a process to do this involving a hotfix that added some additional unattend.xml parameters.  I started to write a much longer blog article explaining the detailed implementation steps, but never got around to verifying that the instructions worked – the process really was rather cumbersome.

Fortunately with Windows 7 the process is much easier.  See the Windows AIK documentation at http://technet.microsoft.com/en-us/library/dd744241(WS.10).aspx for all the details.  To add this into your reference computer image creation task sequence (using MDT 2010 Lite Touch or ConfigMgr 2007 SP2), you just need to add one additional command after Windows 7 is installed and before the step that runs Sysprep.  This step needs to have the following command line:

WinSAT.exe -prepop

That’s all you need.  As the Windows AIK documentation explains, this will create a set of WinSAT XML files containing the performance details, and Sysprep won’t remove them.  When the image is deployed, WinSAT will verify that the hardware is truly the same and ignore the XML files if there are changes.

I’ll be speaking at TechEd Australia (September 8-11 in Gold Coast) and TechEd New Zealand (September 14-16 in Auckland) on the usual deployment-related topics.  For those of you in the area, please seek me out and say hi.  (I might be a little flustered on the 10th with three sessions on one day…)

TechEd Australia has already sold out, but you can put your name on a waiting list.  Registration for TechEd New Zealand is still open as of today, so register before it’s too late.

Many of you have been “challenged” by this driver: when you import it into the MDT Deployment Workbench, it says that it supports both “x86” and “x64” platforms, when really each download supports one or the other.  With the latest release that Intel made available on their download site (and which should be showing up on other vendor’s sites soon if it hasn’t already), that’s no longer an issue.

I downloaded version 8.9.0.1023 (the “allOS” version) from here.  It’s a full installer, but that worked fine for me since my laptop uses the driver anyway.  When the installer finished, it left the drivers in “C:\Program Files\Intel\Intel Matrix Storage Manager\driver” (x86 version) and “C:\Program Files\Intel\Intel Matrix Storage Manager\driver64” (x64 version).  Importing those into MDT 2010 Deployment Workbench resulted in this:

Notice that each one has the right platform assigned with no manual steps needed by me to fix them.  Also note that MDT 2010 properly determined that these were different drivers even though the INF file and version were the same, because the calculated hash value was different – that’s where the “(1)” suffix came from on the x64 driver names, automatically added for the second driver.  MDT 2008 isn’t quite that smart, so you would need to import each driver directory separately with that version, specifying to import duplicates when you imported the second one.

Grab it from the download center via http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=696dd665-9f76-4177-a811-39c26d3b3b34.  (Remember that the new USMT 4.0 bits are included in Windows AIK too.)