As part of the BDNA “SCCM Guru” webcast series, I will be presenting on November 17th from 11:00am to 12:00pm Pacific time.  The topic of the presentation:

Inside a ConfigMgr 2012 OS Deployment Task Sequence

In this webcast with Michael Niehaus, Microsoft’s “Deployment Guy”, you will learn:

• The inner workings of a task sequence, showing the various steps in the process
• How information is passed to and between each step & what the steps do
• How to troubleshoot when things don’t go as expected

I am planning to do something different for this session – with a week to go for preparation (and being on vacation for most of that time), it will be interesting to see how much of my “vision” I’ll be able to get ready in time.  (As an added complication, I will be presenting while jetlagged – I arrive back in Seattle the evening before, after a twelve-hour time change.  Don’t worry, I’ll have lots of caffeine handy.)

To register for the session, please visit this link:

http://info.bdna.com/20111116-Webcast-SCCM-Guru-Michael-Niehaus-RegistrationPage.html

As I discovered in recent TechEd presentations in Australia and New Zealand, not too many people are familiar with the newest members of the Windows 7 family.  So let’s explore one of those in more detail, called Windows Thin PC. For the full marketing overview, you can review these pages:

http://www.microsoft.com/windows/enterprise/solutions/virtualization/products/thinpc.aspx

http://www.microsoft.com/licensing/software-assurance/windows-thin-pc.aspx

To summarize, Windows Thin PC is a modified version of Windows 7 (built from a Windows Embedded Standard 7 base) that is available as a Software Assurance benefit (for anyone with Software Assurance on their desktop operating systems).  It has a reduced footprint (1.1GB compressed WIM, under 5GB when expanded on disk), and as a result has lighter hardware requirements:

• 1GHz processor
• 1GB RAM
• 16GB hard disk space

So it should come as no surprise that it is designed to be used as a thin client OS, enabling older or lesser hardware to connect to your VDI or terminal services infrastructure to run most applications.

Windows Thin PC has licensing restrictions that allows very few applications to be installed and used locally.  From the Thin PC FAQ:

Can I run applications on WinTPC?

Yes, you can run applications that fall into one of the following categories:

• Security
• Management
• Terminal emulation
• Remote Desktop and similar technologies
• Web browser
• Media player
• Instant messaging client
• Document viewers
• .NET Framework and Java Virtual Machine

However, you cannot run any productivity applications, such as Microsoft Office or similar applications.

Again, this is pretty consistent with what you could do with dedicated thin client hardware,

So what is it like to deploy this operating system?  It deploys just like any other version (SKU) of Windows 7.  MDT 2012 will officially support deploying this OS (since that where we’ve done all of our testing), but it’s not hard to get MDT 2010 Update 1 to deploy it too by removing the <UpgradeData> section from the unattend.xml that you use to deploy Windows Thin PC.

What does it look like once installed?  Just like Windows 7, but with fewer items on the start menu:

So it’s not an operating system for everyone, but it does have its place.

Be sure to read the great new posting on the “Building Windows 8” blog:

http://blogs.msdn.com/b/b8/archive/2011/09/07/bringing-hyper-v-to-windows-8.aspx

(Read through the comments too, which talk about support for sleep and hibernate.)

There is one prominent statement made:

Hyper-V requires a 64-bit system that has Second Level Address Translation (SLAT).

That means you have a great reason to consider using the 64-bit version of Windows 8, and why you should buy only hardware with 64-bit support.  But what about the second part of that, SLAT support?  Well, all you really need to understand is that SLAT is a processor feature that improves virtual machine performance, especially when using higher-end video cards (e.g. those used on client machines).  Read more about the benefits in the Hyper-V R2 announcement:

http://technet.microsoft.com/en-us/library/dd446676(WS.10).aspx

This mentions that Intel and AMD have different implementations of this.  Intel calls theirs “Enhanced Page Tables” (EPT), while AMD refers to it as “Nested Page Tables” (NPT).  Regardless, what you really care about is whether or not a particular processor includes the support.  That’s not always easy to figure out from the vendor’s web sites.  Fortunately, there is a newly-updated tool available on the SysInternals web site called Coreinfo that will tell you all about a processor’s capabilities:

http://technet.microsoft.com/en-us/sysinternals/cc835722

Mark Russinovich updated this utility recently to add the ability to detect both Intel EPT and AMD NPT.  Here’s what the output would look like if your machine has an Intel processor with the needed support:

The AMD output will be slightly different (and not because it’s on a white background instead of a black one):

In both cases, the asterisk (“*”) in the second column indicates that the feature is present.  (A minus, “-“, shows if it isn’t.)  Be careful if running this in a VM or on a machine currently running a hypervisor, as these will mask the real processor capabilities.)

So check out your machines today to see if they are ready for Windows 8 client Hyper-V!

So maybe migrating Angry Birds high scores and settings isn’t terribly useful to you.  Let’s try something a little more practical and self-serving.  Many of you are using Configuration Manager 2007 or testing Configuration Manager 2012.  As part of that, you have installed the ConfigMgr console and connected to one or more ConfigMgr sites.  When you refresh your own machine, you want those connections to be retained, because it’s too much trouble to have to type in a server name again.

So it’s the same basic exercise as before:  Figure out where the ConfigMgr console stores that information (using ProcMon or even Bing searches), then build an XML manifest that says to migrate the data.  Fortunately, I already know where ConfigMgr stores that (we use that information in MDT):  it’s in the user’s registry.  The exact path is different for ConfigMgr 2007 vs. 2012:

ConfigMgr 2012:   HKCU\Software\Microsoft\ConfigMgr10\Admin UI\MRU

ConfigMgr 2007:  HKCU\Software\Microsoft\ConfigMgr\AdminUI\MRU

So the manifest needs to specify that these registry keys (and all values and subkeys) get backed up and restored if they exist.  Simple enough:

A few things to point out with this one:

• There are two components defined in the same XML manifest.  You can put as many components in the file as you want, so whether you want 20 small XML files or one larger one (as you define more application settings to capture) is entirely up to you.
• Since these are user registry entries, the rules will be processed for each user that exists on the machine.

So what happens if the ConfigMgr 2007 console is installed in the old OS but not in the new OS?  Will the settings be restored?  Yes they will, as the detection rules are only used to determine on the source computer whether the component is present. (When it is detected, it will be put into a generated config.xml file too.)

Out of the box, USMT 4.0 migrates settings for Windows, Office, and various other applications (typically current versions as of 2009), mostly consumer-focused.  (See http://technet.microsoft.com/en-us/library/dd560792(WS.10).aspx for the full list.)  So what if you want to migrate settings from additional applications?  Well, then you need to author your own migration XML file.

First though, you need to figure out what application settings need to be migrated.  Does the application store its settings in a file?  In a registry key?  Per user or per system?  There’s no single right way to do this, so you have to do some investigative work to figure this out for each application.  Tools like ProcMon from SysInternals can help with that, by capturing details of all registry and file accesses made by the process.  But there can be lots of data captured, so finding the data can be somewhat time-consuming.

So let’s look at a real example using Angry Birds, which is available for download from http://download.angrybirds.com/.  Install this on a computer, then start ProcMon and tell it to capture details from process name AngryBirds.exe:

Then launch Angry Birds and click on “Play” to see where you left off – at that point, you know it’s read the saved settings, wherever those came from.  At that point, you can stop the capture and begin scanning the captured data.  Usually I start at the bottom (most recent) and work my way up, looking for something “interesting”.  (What is “interesting” can vary by app, but you will begin to notice patterns that applications follow so the more applications you do this with, the better you’ll get at it.)

From scanning the ProcMon output, I can see a few references to my user profile folder:

Those files (“highscores.lua” and “settings.lua”) sound promising, especially since I noticed that the settings are per user (log in as someone else and you have different progress displayed) and I don’t see any relevant HKCU registry access in the trace.

OK, so we know what we want to capture and restore.  Now we have to figure out how.  Using your favorite XML editor (I use Visual Studio), create a new XML file that looks like this:

A few things to point out:

• The “urlid” value on the first line can be any URL – it just needs to be unique among all XML files being used (no duplicates).  Make up whatever value you want, as it’s effectively just a text string, not used for anything beyond identification.
• The component type can be either “Application” or “Documents”, depending on what you are capturing.  It doesn’t really matter what you specify, as it just controls where the component shows up in the config.xml file (if you generate one).  For Angry Birds, I specified “Application”.  (If you specify an invalid value, USMT typically doesn’t complain – it does end up ignoring the component though.)
• The context is very important.  It should be “System” if you are capturing machine-level configuration, or “User” if you are capturing user-specific configuration.  You can also specify “UserAndSystem” if you need to capture both.  In the case of Angry Birds, we’ve already determined that it is using user settings, so that’s what we need to specify.
• The remaining entries generally occur in this type of pattern:
• A role node.  The type can be “Data”, “Binaries”, “Settings” or “Data” – really just labels for you to use, as all values are treated the same.
• One or more detection rules. In this case, we look for the existence of a folder to indicate that this rule should be processed.
• A rules node that specifies whether these are “User” or “System” settings.  (Typically this is the same as the component value, although it can be a subset, e.g. the component specified “UserAndSystem” while the rule specifies “User”.)
• One or more include rules that specify what to migrate.
• Potentially more optional elements, e.g. exclusions.  See http://technet.microsoft.com/en-us/library/dd560769(WS.10).aspx for a description of all the possible XML elements.

So then lets look at the condition:

MigXmlHelper.DoesObjectExist("File","%CSIDL_APPDATA%\Rovio\Angry Birds")

This uses a helper function to determine if the specified directory exists.  The “%CSIDL_APPDATA%” text is a reference to one of the many “environment variables” (listed at http://technet.microsoft.com/en-us/library/dd560744(WS.10).aspx) that can be used; the value will be substituted when evaluating the condition.  Because this is a per-user rule, the condition will be checked for each user, with “%CSIDL_APPDATA%” pointing to the user profile’s roaming data folder (e.g. C:\Users\<userID>\AppData\Roaming on Windows 7).

The "include" rule specifies to capture all files and subfolders under the detected path.  By default, these will be put back into the same location they were captured from, doing any necessarily translation for changes in %CSIDL_APPDATA% (e.g. drive letter changes).

That’s all there is to it – just tell Scanstate and Loadstate to use this new XML file and all of your Angry Birds progress will be preserved even through an OS refresh or replacement process.

One of the questions that came up after my TechEd New Zealand session on USMT 4.0 was whether USMT migrated the contents of the client-side cache (CSC) used for offline files.  Well, it sounds like it “sort of” does – but by default, it only moves the “dirty” files (those not yet sync’d to the network location).  That’s a decent default I suppose, as the remaining files can be pulled back from the network after the state is restored, and the modified files won’t be overwritten.  So there’s no data loss (always a good thing), but there will be extra network traffic to pull the content down to the cache again.

The actual cache migration is performed by a plug-in to USMT, so the question is whether that plug-in can be influenced to capture everything, instead of just the “dirty” files.  From http://support.microsoft.com/kb/942960, you can adjust the behavior by telling CSC you want to migrate everything.  (While this article talks about MigWiz.exe, the Windows Easy Transfer Wizard, the underlying engine being used is basically the same as that used by USMT.  So the end result of setting “MigrationParameters” should be the same.)

But before you say “great, let’s do it” you need to understand what’s going on behind the scenes.  First, this CSC migration plug-in is called automatically by USMT as part of the Windows manifest processing.  If you search through the Scanstate log you’ll see lots of references to it, with “CscMig” in the log entries.  For example, here is an entry I saw on my computer for a “dirty” file (one that was created while the folder was offline, so USMT needs to capture it):

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item Created while offline (dirty).txt continueCtx = 00000000003DC480

But the rest of the files in that folder were skipped, as I didn’t have the MigrationParameters registry key set:

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractFile(653):Skipping item File1.txt because it is in sync with remote location. ItemStatus = 00050020

OK, great, we see what’s happening.  But it’s also worth digging a little deeper and seeing what it did with that original file (something you can see from specify verbose logging, /v:5):

2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigGetWorkingDirectory(837):exit: workingDir = <\??\C:\Users\mniehaus\AppData\Local\Temp\tmp6865.tmp\Working\agentmgr\CCSIAgent\CSC>, status = 0x00000000 ( EE = 0 )
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item \\ continueCtx = 00000000003DAF00
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item bdddev continueCtx = 00000000003DB9A0
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item data$ continueCtx = 00000000003DC480
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item Created while offline (dirty).txt continueCtx = 00000000003DC480
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigWrite(446):exit: bytesWritten (743) at offset (0)
2011-08-24 22:53:43, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractFile(974):Backup API file content till offset 743

So it used the Windows Backup API to make a backup of the “dirty” file in the CSC cache and placed that backup into a folder in my %TEMP% directory named “tmp6865.tmp\Working\agentmgr\CCSIAgent\CSC”.  So even though I’ve specified to use hardlinks, there is data copying going on.  In the end, this temporary folder created by CscMig is included in the hardlinked state store, but because these are different files (the backups) you will see twice the disk space consumed, so if you have lots of cached data you better have lots of free disk space to store the data.  This isn’t so bad in the default configuration where it is only grabbing “dirty” files, but if you tell it to backup all files, then what happens?

No better way to find out what will happen than to try it.  I made the MigrationParameters registry entry as described in the KB article mentioned above and repeated the Scanstate execution.  (No service restart was required.)  Upon checking the log, I can see now that each file in the CSC was backed up into the temporary folder.  Where before it said “skipping item File1.txt”, now it says it’s backing it up:

2011-08-24 23:07:54, Info                  [0x0808fe] Plugin {0db12ccb-7cfd-46b6-b4d1-daa6ff0fbcf7}: CscMig: CscMigpExtractItem(1124):enter: Processing item File1.txt continueCtx = 000000000045C480

And like before all of these items get backed up into a temporary folder, then that temporary folder is hardlinked into the state store folder.  So hardlinks or not, if you had 2GB worth of cached files, you’ll end up with those being doubled (temporarily, until the process is complete and the temporary folder and state store are cleaned up).  It’s actually going to be tripled if you aren’t using hardlinks:  first copy is the original file, second copy is the backup, third copy is contained in the compressed state store.

So that definitively answers the question of whether you can get USMT to migrate the complete contents of the client-side cache.  It may not answer the question of whether you should do that, but hopefully the information is useful to help you make that determination yourself.

I gave a presentation today at the TechEd New Zealand conference on “Customizing the User State Migration Tool 4.0” – something I’ve talked with customers about back from my consulting days (way back when, probably with USMT 2.6 at that point – remember that one and its INF-style configuration files?), but haven’t presented in public for a very long time.  Needless to say, it was somewhat nerve-wracking.  For those in attendance, I hope it was worth your time.  (I thought it was only OK.  I’ll do better the next time.)

The next few blog postings will likely be related to USMT 4.0 – it’s always good to write about things that are freshly in your mind.

First off, I wanted to take the opportunity to pass along some of the troubleshooting items that I mentioned in the slide deck, consolidating various issues that you might run into while using USMT 4.0.  Here they are:

• USMT 4.0 isn’t migrating Office 2010 settings
• Make sure you install the USMT 4.0 update that adds Office 2010 support.  See http://blogs.technet.com/b/mniehaus/archive/2011/02/02/usmt-4-0-support-for-office-2010.aspx for more information.
• http://support.microsoft.com/kb/2023591
• USMT fails with some half-hour time zones
• Install the USMT update for Office 2010 (see above), as it fixes this too.
• Bad user profiles (usually a ProfileList registry entry that points to a non-existent folder) can cause state capture issues (delays, failures)
• Clean them up or tell USMT to ignore them with MIG_IGNORE_PROFILE_MISSING=1
• See http://blogs.technet.com/b/deploymentguys/archive/2010/03/28/usmt-failures-due-to-bad-profile-list-entries.aspx for a script that can help identify these and clean them up so that they don’t cause any issues.
• See http://blogs.technet.com/b/askds/archive/2011/04/14/usmt-pauses-at-quot-starting-the-migration-process-quot-for-many-minutes-then-works.aspx for more details about the problem.
• Setting MIG_IGNORE_PROFILE_MISSING is rather challenging in ConfigMgr (you can’t set it as a process environment variable because it goes away before the “Capture User State” step runs, so you need to set it as a system variable, reboot, and then capture state).  See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2011/08/03/setting-environment-variables-in-a-task-sequence.aspx for details on how to do this.  (You could do a shorter way with MDT Lite Touch by modifying ZTIUserState.wsf to set the variable.)
• OS settings don’t migrate with ConfigMgr
• This happens because USMT can only find the “DLManifests” folder necessary to do OS setting migration in the working directory, and ConfigMgr doesn’t set the working directory to the location that contains this.  See http://support.microsoft.com/kb/2018593 for more information.
• MDT 2010 Update 1 includes a workaround for this problem, although the USMT 4.0 fix for Office 2010 (see above) breaks the workaround, requiring a script change (also described in the blog above).
• USMT migrates user data from removable drives even with /localonly
• It migrates USB disks even with /localonly, use an unconditional exclude to exclude undesired USB disks.
• See Michael Murgolo’s blog posting at http://blogs.technet.com/b/deploymentguys/archive/2009/04/29/excluding-usb-firewire-and-other-drives-from-usmt-capture.aspx for a scripted approach of doing this (taking into account that the drive letters can be different on each system, so you might need a different exclude list for each PC).
• Shortcuts to files on network drives don’t migrate
• Known issue, you can modify MigUser.xml to remove section with IgnoreIrrelevantLinks (but then all links are retained, even invalid ones).
• USMT doesn’t exclude the users that I want when I specify /UE and /UEL
• These two parameters don’t work together the way you would expect them to, acting like an “or” instead of an “and”.  See http://blogs.technet.com/b/askds/archive/2009/11/30/understanding-usmt-4-0-behavior-with-uel-and-ue.aspx for more information.

Any other good troubleshooting tips for USMT 4.0?

The new application model in Configuration Manager 2012 will require administrators to study up on how best to deploy software – this isn’t anything like traditional software distribution like you would find in ConfigMgr 2007.

I recently set up Office 2010 as an application in ConfigMgr 2012 Beta 2.  Here are the steps I used – not necessarily the only way to do it, but it worked for me.

Create the application

First you need to create a new application.  If this were a simple MSI, you could just choose the MSI file and the whole process would be simpler.  But Office 2010 is a little different than your typical application, so we need to manually define the information.

Specify general information

Now you need to specify some general identification and ownership information.  This information is primarily for the ConfigMgr administrator’s use, as the end user can see different information in the software catalog.

Notice the “Allow this application to be installed from the Install Application Task Sequence Action without being manually deployment” checkbox.  If you are planning to have MDT install this application dynamically in a task sequence (by specifying the application name in CustomSettings.ini, e.g. Applications001=Office 2010), you will need to check this box.

Specify how it should appear in the software catalog

ConfigMgr provides a software catalog, the Software Center, where end users can choose from optional applications (deployed as “available”, i.e. non-mandatory).  You need to specify how the application should show up in the catalog – you can even specify different languages.

Add a new deployment type

The high-level “application” doesn’t say how to actually install the application.  That’s done by one or more deployment types (similar in concept to the old package/program concept, where one package can have multiple programs, but in this case each deployment type can have different content – maybe one deployment type is an MSI install and another uses App-V).

Again, because Office 2010 isn’t a typical application, you need to manually specify the deployment type details.

Specify the deployment type details

You need to give the deployment type a name.

Specify install and uninstall details

Now you need to specify the source files, the installation command line, and the uninstall command line.

Since we are deploying Office, the install command line is pretty simple, just specify SETUP.EXE.  This assumes that the package source contains an “Updates” folder with an MSP patch file that is configured to install Office without any user intervention.

The uninstall command line is a little harder to come up with – I just copied the command that Office placed in the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Office14.PROPLUS on a 64-bit computer).  It isn’t very complicated, just specifying “SETUP.EXE /uninstall PROPLUS”.  (I haven’t actually confirmed that this command line works, so test appropriately.)

Add a new detection rule

ConfigMgr 2012 will automatically reinstall an application targeted to a computer if it detects that it is no longer present.  In order for this to work, you need to specify a detection rule so that ConfigMgr can figure out if it is still installed.

First add a new detection MSI detection rule.  In the case of Office 2010, you can check for the present of any of the MSIs that are installed by the Office Setup program. I usually pick the one for the main product, Office Professional Plus, as that uniquely identifies the specific Office SKU that is installed. You browse to the “proplusww.msi” file in the “ProPlus.WW” folder so that you don’t need to type in the MSI product GUID.

Specify user experience settings

Typically you want to install Office in the system content and whether or not a user is logged on (both are mandatory settings for the task sequence to install the application).  Neither of these settings are defaults, so be sure to change them:

There are a few more screens, but you can take the defaults for each of them.

Now you have successfully created the application, but you aren’t done yet.

Distribute content

The source files specified on the deployment type still need to be distributed to your distribution points.  (You don’t need to do each deployment type separately, just once for the application.)  There are different options you can choose for distributing the content.  In my case, I’ll just keep it simple and distribute it to every one of my distribution points (one of them):

Deploy

At this point, you are ready to deploy.  You don’t choose to deploy a specific deployment type.  Instead, you deploy the application itself.  It’s pretty simple in this case, with only one deployment type, as it’s fairly obvious which one will be installed.  But if you had multiple deployment types, you would need to specify rules to determine which one is used.

There’s no doubt that this will take ConfigMgr administrators some time to get used to – just one of the big changes coming in ConfigMgr 2012.g

Those of you who deploy both x86 and x64 versions of Windows 7 using MDT 2010 Lite Touch probably know that you have to use two different boot images to do it:  When booted from a Lite Touch x86 boot image, you only see task sequences associated with x86 operating systems; when booted from a Lite Touch x64 boot image, you only see task sequences associated with x64 operating systems.

With MDT 2012 Beta 1, that’s been changed.  Now, if you boot from a Lite Touch x86 boot image you will see all task sequences, whether x86 or x64. 

But there is one “gotcha”:  If you choose a task sequence that deploys an x64 OS, MDT will need to find a copy of the corresponding x86 setup files and it will then use those to install the x64 OS.  So you need to make sure that you have x86 setup files in the deployment share (with one of the operating systems), even if you aren’t deploying that operating system.  It needs to match the version (e.g. 6.1.7601.17514) of the x64 OS that you are deploying.  (This is the really the same as if you were deploying a custom image.  Now, we just make sure we pick a copy of setup files that match the Windows PE platform being used, ignoring those that don’t, even if they are provided with the OS being deployed.)

The other combination, booting from an x64 boot image and deploying an x86 OS, isn’t supported by Windows Setup, so we still hide x86 task sequences when you have booted into an x64 boot image.

One of the new features that has been added to Lite Touch Installation in MDT 2012 Beta 1 is support for deploying 64-bit Windows to machines configured to use UEFI.  So what exactly does that mean?  That’s no simple question.

What is UEFI?

The “Unified Extensible Firmware Interface” (UEFI) specification, created by an industry consortium that includes many influential companies from the PC industry, including Intel, AMD, Apple, Microsoft, Lenovo, Hewlett-Packard, Dell, IBM, American Megatrends, Phoenix Technologies, and Insyde.  What common interest do those companies have?  They either make firmware for PCs, create operating systems for PCs, or use firmware and operating systems on PCs.

Today, most computers use firmware called the BIOS, the “basic input output system”.  This has been around since the original IBM PC.  Although hardware has advanced quite a bit, today’s BIOSes still have some serious limitations, including:

• 16-bit code (where most OSes are now 32-bit or 64-bit)
• 1MB of addressable memory (regardless of how much the computer actually has)
• Slower option ROM initialization
• 2.2TB boot disk limitation (an MBR limitation)

UEFI addresses all of these, so it’s only a matter of time before these “legacy BIOSes” make way for UEFI replacements.  In fact, many computers have already move to UEFI, including all the latest laptops from Dell, HP, and Lenovo, most Dell and IBM servers, etc.  But if these computers (which many of you are probably using today) already have moved to UEFI, how are they still working?  Simple, they include a “compatibility support module” (CSM) that enables UEFI firmware to emulate a “legacy BIOS”.  With this in place, the operating system can’t even tell the computer supports UEFI.

On most of the UEFI-enabled computers shipping today, “native” UEFI (running without the CSM) is disabled through the configuration of the machine, so you typically need to turn it on in order to get the choice to install using “native” UEFI or “legacy” BIOS emulation.

To make matters a little more confusing, you’ll see references to “UEFI BIOSes” and “BIOS configuration” even with UEFI-enabled computers.  It’s not really a “BIOS” any more, but since everyone is used to calling it that, it is bound to happen.

What benefits do you get from UEFI?

As you can probably gather from the list of limitations above, UEFI is designed to eliminate the limitations of today’s “legacy” BIOS.  It provides:

• Full memory access (32-bit or 64-bit)
• CPU independence (enabling UEFI on x86, x64, ia64, and even ARM computers)
• Faster initialization
• Support for larger boot disks (larger than 2.2TB)

From a Windows perspective, there are some specific benefits that result:

• Faster initial boot times, because the operating system can use large IOs to read the operating system files (instead of using the 16-bit Int13 interrupts)
• Faster resume from hibernate (since it can read data faster from the hibernation file, again because of large IOs instead of Int13 calls)
• Multicast boot, because WDS can send down processor-independent UEFI bytecode to be executed to perform the multicast receiving (although this does require that the UEFI implementation in the PCs supports PXE for the NICs, many don’t currently support this)

As we move forward, you will likely see more UEFI-only Windows features.  Also, don’t be surprised if some future PCs are UEFI-only, providing no BIOS compatibility model at all – once that happens, you must use “native” UEFI.

One additional note:  Today, Windows only supports UEFI for 64-bit installations of Windows Vista SP1, Windows 7, Windows Server 2008, and Windows Server 2008 R2.  32-bit installs, and older OSes, must continue to use the “legacy” BIOS support.

What is different about the UEFI deployment process?

There are a few differences that need to be taken into account to deploy Windows to a computer running “native” UEFI.  First, there is a different disk layout, shifting from the master boot record (MBR) structure to the new GUID partition table (GPT) structure.  GPT supports much larger boot volumes (up to 9.4 zettabytes, or 9.4 billion terabytes) and up to 128 partitions (whereas MBR had a limit of 4).

Next, there is also a different recommended disk layout, as described at http://technet.microsoft.com/en-us/library/dd744301(WS.10).aspx, that involves three partitions:

The “EFI System Partition” (ESP) is roughly equivalent to the small boot partition typically used with Windows 7 today, holding the boot files needed to “bootstrap” the loading of the operating system.  Interestingly enough, this partition is formatted as a FAT32 volume because that’s required by UEFI – it can’t read NTFS-formatted volumes.  What would you expect to find on this partition?  Think of it like the old OEM partitions:  It can contain boot loaders (like the ones used to load Windows), OEM firmware utilities, etc.  But instead of each OEM using a different setup, all can share this volume.  (There are even specific subdirectories that each vendor has agreed to use, see http://www.uefi.org/specs/esp_registry.)  There are even “EFI shells” that can be loaded onto this partition (for configuration, browsing, or whatever other creative uses you might find).

There is one thing that you won’t find on the EFI System Partition:  a BCD file.  When booting from a “legacy” BIOS, the Windows boot loader (bootldr) reads the boot configuration data from the \BOOT\BCD file on the active partition, but with UEFI that information is stored in and read from non-volatile RAM (NVRAM) on the motherboard.  The same BCDEDIT.EXE utility that is used to manipulate the BCD file also knows how to manipulate the NVRAM – not surprisingly as the BCD structure was built in anticipation of UEFI.

The next partition, the Microsoft Reserved (MSR) partition, reserves some disk space for Windows to use for certain operations (e.g. converting a basic disk to a dynamic disk).

Overall, these partitions are fairly small, with the ESP at 100MB and the MSR partition at 128MB, so there isn’t much overhead here.

The next challenge then involves bootable CDs and DVDs.  Today, you would typically set up an ISO using the El Torito specification, specifying the ETFSBOOT.COM boot sector for the “legacy” BIOS to call to initiate the CD/DVD boot process.  With UEFI, there is a new boot sector called EFISYS.BIN.  This isn’t an “either-or” proposition though, as you can actually configure a bootable CD or DVD to have both ETFSBOOT.COM and EFISYS.BIN at the same time.  (See http://support.microsoft.com/kb/947024 for an example of the OSCDIMG command line syntax to do that.)  If the computer supports UEFI and “native” UEFI is enabled, then it will typically choose the UEFI boot sector by default (or prompt and ask which one you want to use), while computers that don’t support UEFI or those that don’t have “native” UEFI enabled will revert to the ETFSBOOT.COM “legacy” boot sector.

The final challenge then is USB media.  As with CDs and DVDs, you probably want them to support both “legacy” BIOS and UEFI booting.  This is pretty simple to do, formatting the USB media using FAT32 (so it can be read by UEFI) and setting up both “legacy” BIOS and UEFI boot files.

One other complication to mention:  What if you have a computer that supports UEFI, but it is currently running an operating system (e.g. Windows XP or Windows 7) through the legacy BIOS compatibility module (CSM), and you want to move it to UEFI.  Can you perform a typical “refresh” operation?  No, because the “refresh” process can’t even see that the machine supports UEFI when running in compatibility mode, plus there is no way to convert an MBR disk to a GPT disk while preserving the data.  So in order to do this type of migration, you need to move the user data off of the disk, then boot from UEFI-enabled media, reformat the disk as GPT, install the new OS, and then restore the user data.

It’s also worth noting that you may need to upgrade any imaging or disk partitioning tools that you are using today to versions that understand GPT disk structures.  (This isn’t an issue with Windows AIK and ImageX, as ImageX uses file-based images that don’t care about MBR vs. GPT.)

What about MDT 2012?

All of that background information and we still haven’t really talked about what MDT 2012 does in regards to UEFI.  So let’s quickly review what MDT 2012 does to enable UEFI support:

• MDT will build all ISOs and media folders with both “legacy” BIOS and UEFI boot files.  (It’s up to you to make sure you copy the media content to USB devices that are formatted as FAT32, if you expected UEFI to be able to read them.)
• MDT will build all ISOs with dual “legacy” BIOS and UEFI boot sectors.
• MDT is able to detect when a computer is running in “native” UEFI mode (see the “IsUEFI” property – it’s set to false when running in “legacy” BIOS compatibility mode, true if in “native” UEFI mode).
• MDT will automatically format the boot disk using GPT (even if the task sequence says MBR) so that you can use the same task sequences with both “legacy” BIOS and UEFI computers.
• MDT will automatically create the needed ESP and MSR partitions when running in “native” UEFI mode.
• MDT can refresh a computer running an OS in “native” UEFI mode to a new OS in “native UEFI” mode (but not “legacy” to “native” or “native” to “legacy”).

In the end, that means that this becomes sort of a “ho-hum” exercise:  It should just work, as soon as you figure out how to enable UEFI “native” mode in the firmware (BIOS) settings and then boot in “native” mode.  That’s not always as simple as it seems, as the UEFI firmware available today isn’t terribly obvious.  (I’ve tried it with Dell and HP laptops.  The Dell machine isn’t too hard to figure out, but getting the HP to boot in “native” mode is a little more challenging.  See below for more details.)

Can you really tell the difference?

Some computers will benefit more from UEFI than others, due to the specific hardware, the UEFI firmware being used, etc.  So I’ve run a few timings with an HP EliteBook 8440p laptop to illustrate the differences on a typical machine.  First, let’s compare the Windows PE boot time, reading the same boot image from a USB key using “legacy” and “native” boot options (stopping the timer once the initial MDT wizard is displayed):

• Legacy boot:  50 seconds (to initial MDT wizard)
• Native boot:  40 seconds (to initial MDT wizard)

The next test then is operating system installation (measuring how long from finishing the MDT deployment wizard until the summary wizard appears in Windows 7 SP1 x64):

• Legacy boot:  14 minutes, 40 seconds
• Native boot:  13 minutes, 55 seconds

(Note that both of these times should be one minute shorter, but due to a bug in the task sequencing engine there is an extra minute of “nothing going on” added to the end of the deployment process, before the summary wizard is displayed.  We’re still working to get that fixed.)

Now let’s compare the “cold boot” time (from powered off to the logon prompt appearing):

• Legacy boot:  30 seconds
• Native Boot:  27 seconds

And finally, time to resume from hibernate (with no applications running, from powered off to the lock screen appearing):

• Legacy boot: 17 seconds
• Native boot:  14 seconds

So it’s not a huge difference, at least with the current UEFI revision on this machine, the USB key performance, and the SATA (non-SSD) hard drive in the system.  Imagine though if you were using an SSD…

Caveat Lector

It was interesting using UEFI on the HP EliteBook 8440p, not nearly as “refined” as I would have expected.  First, when you enable UEFI in the BIOS, you get an interesting warning:

The “UEFI Boot” option on this system is provided for development purposes only and is currently NOT fully supported or warranted by HP.  Preboot Authentication and Drive Lock are currently NOT supported under UEFI Boot mode.  HP strongly recommends disabling Preboot Authentication and Drive Lock before enabling UEFI boot on this system.

Then (ignoring the warning), the UEFI firmware doesn’t seem to be able to detect UEFI-bootable USB keys, so you have to browse to the “bootx64.efi” file on the USB key and explicitly tell the machine to boot from that.

You would think that this “temporary boot choice” would only apply for this single boot (so that when the computer reboots after Windows is installed it will boot from the hard drive), but that’s not the case:  It keeps booting from the USB key if you leave it inserted.  So I’ve gotten used to pulling the USB key every time the computer reboots, then reinserting it before MDT wants it back so it doesn’t pause and prompt.

And as mentioned previously, there is no UEFI PXE support provided on this computer.  (I hope it will work as expected with a dual-boot CD/DVD, offering a choice, but I didn’t have one handy to try.)

I have previously tried this on a Dell Latitude E6410 laptop, which seems to be a little better behaved (although it doesn’t seem to support UEFI PXE boot either).  Your mileage may vary, based on computer manufacturer and model, UEFI firmware version, etc.