July, 2009

There are two new Lite Touch task sequence templates provided in MDT 2010:

• Capture only (CaptureOnly.xml).  This task sequence includes only the steps to sysprep the OS, reboot into Windows PE, and capture a WIM file (with the right /FLAGS value).  We would prefer that you use a full task sequence to do the complete build/sysprep/capture process, but if for some reason you can’t do that then you can consider this template to reliably perform those last few steps.
• Post OS Installation Task Sequence (StateRestore.xml).  This task sequence includes all the “State Restore” phase activities: installing applications, enabling BitLocker, restoring the user state, and even the “capture only” steps described above.  This is useful in cases where you have already built the OS (maybe you deployed an already-built VHD to Hyper-V), but now you want to customize it.

This seems to be a frequent question that comes up:

“I am working with PCs from <vendor> that have model strings that frequently change, although the first part is always consistent.  How can I use these models with the MDT database without creating a new entry for each unique string?”

This seems to come up most often with computers from Lenovo, where the first four characters indicate the model and the last three indicate a specific configuration of that model.  It’s also seen with various HP computers, although their pattern tends to be a little more difficult.

The “gather” process that MDT uses doesn’t provide a way to do wildcard or “like” queries, but it does provide extensibility to let you define your own property to use instead of “Model” when querying the database.  Let me give a “real world” example for the Lenovo case.  I can use a CustomSettings.ini like this:

[Settings]
Priority=CalculateCustom, MMSettings
Properties=CustomModel

[CalculateCustom]
CustomModel=#Left("%Model%", 4)#

[MMSettings]
SQLServer=MNiehaus-T61p-7
Instance=SQLExpress
Database=MDTDatabase
Netlib=DBNMPNTW
SQLShare=DeploymentShare$
Table=MakeModelSettings
Parameters=Make, CustomModel
CustomModel=Model

This defines a new property called “CustomModel”.  It includes a rule that has a very simple manipulation: it sets the value to the first four characters of the existing “Model” value, which in the case of my T61p laptop results in a value of “6458”.

I then modified the database query to tell it to use “CustomModel” as a parameter instead of “Model”.  If that’s all I did, the query would fail because it would create a SQL statement that specified “WHERE CustomModel = ‘6458’” but that’s not valid since there isn’t a CustomModel column in the database.  That’s where the next line comes in:

CustomModel=Model

This says that the property “CustomModel” as we know it locally is called “Model” in the database.  As a result, the correct query is generated:

About to issue SQL statement: SELECT * FROM MakeModelSettings WHERE MAKE = 'LENOVO' AND Model = '6458'
Successfully queried the database.

That’s all it takes.  Now, there would typically be more than just the [MMSettings] section that needs the “CustomModel” updates – you would also want to change [MMPackages], [MMApps], [MMAdmins], and [MMRoles] the same way.

If you need to do a calculation that is more complex than the simple substring that I implemented above, you may need to use a user exit to do the calculation.  The end of the exit just needs to set the same “CustomModel” property.  The rest of the logic would be the same.  So you could use something like this for the exit:

Function UserExit(sType, sWhen, sDetail, bSkip)

    If sType = "SECTION" and sWhen = "BEFORE" then

        oLogging.CreateEntry "Calculating custom model string.", LogTypeInfo

        If UCase(oEnvironment.Item("Make")) = "LENOVO" then
            oEnvironment.Item("CustomModel") = Left(oEnvironment.Item("Model"), 4)
        ElseIf Instr(oEnvironment.Item("Model"), "(") > 2 then
            oEnvironment.Item("CustomModel") = Trim(Left(oEnvironment.Item("Model"), Instr(oEnvironment.Item("Model"), "(") - 2))
        Else
            oEnvironment.Item("CustomModel") = oEnvironment.Item("Model")
        End if

    End if

    UserExit = Success

End Function

Save that as “CustomModelExit.vbs” in the same “Scripts” directory with ZTIGather.wsf, then edit the CustomSettings.ini to specify to run it:

[Settings]
Priority=CalculateCustom, MMSettings
Properties=CustomModel

[CalculateCustom]
UserExit=CustomModelExit.vbs

[MMSettings]
SQLServer=MNiehaus-T61p-7
Instance=SQLExpress
Database=MDTDatabase
Netlib=DBNMPNTW
SQLShare=DeploymentShare$
Table=MakeModelSettings
Parameters=Make, CustomModel
CustomModel=Model

The only change from the previous CustomSettings.ini sample is the [CalculateCustom] section.  Now it specifies the run the user exit script.  So what exactly does this script do?  Well, if it’s a Lenovo machine, it takes the first four characters.  If the models string contains a starting parenthesis, “(“, it will chop everything from that point off of the model (e.g. “My Model (Test)” will become “My Model”).  In any other case, the script will assign the current model value to the CustomModel property.  (That simplifies things somewhat.)

You might need to tweak the script some based on your specific requirements, but the basic setup should work for whatever manipulation you would like to do.

I mentioned before that the boot image creation process used by the Deployment Workbench is significantly enhanced in MDT 2010 Beta 2, but didn’t really talk too much about how the process works behind the scenes.  Now, this is template-based, with XML files that specify exactly what should be included in each boot image that we generate:

• LiteTouchPE.xml.  This defines all the components, files, and settings that should be included in any Lite Touch boot images generated by Deployment Workbench.
• Generic.xml.  This defines all the components, files, and settings that should be included in any “generic” boot images generated by Deployment Workbench.

When you perform the “Update Deployment Share” process, the Deployment Workbench will take these XML files (located in C:\Program Files\Microsoft Deployment Toolkit\Templates), add some additional items to them (e.g. settings you specified on the deployment share properties such as optional components to add, settings like RAMdisk size, etc.), and then use that to build the new boot image.  (As mentioned in the previous article, the process is optimized to only do the minimum amount of work – it does this by comparing the new XML file against the one generated the last time the boot image was generated.  It then figures out what needs to be done based on the difference between the two.)

So what if you want to add your own files into our boot images?  Just modify the template to tell us where to get them and where to put them in the image and the “Update Deployment Share” process will take care of it.

That’s fine for simple additions like adding files, but what if you want to do something more substantial?  That’s where exit scripts come in.  (I call this the “Johan feature”.)  You’ll notice that the existing templates specify a sample exit:

<!-- Exits -->
<Exits>
  <Exit>cscript.exe "%INSTALLDIR%\Samples\UpdateExit.vbs"</Exit>
</Exits>

When the “Update Deployment Share” process runs, this exit script will be called multiple times for each phase of the process, allowing you to make customizations to the process.  Variables will be passed along so that you know where everything is located, what is currently going on, etc.  The phases:

• “WIM”.  The exit script is called after the WIM has been mounted and customized, just before the changes are going to be committed.  At this point, you can manipulate the WIM contents (copy files, create folders, mount the registry, add registry keys – anything you would like).
• “ISO”.  The exit script is called just before the boot ISO is being created.  This lets you add files to the boot ISO without sticking them into the RAMdisk.
• “POSTISO”.  The exit script is called one more time after the ISO file has been created and before that ISO has been copied back to the deployment share.  At this point, you might choose to copy it to a public share, automatically burn it to a CD, etc.

In each of the phases, various environment variables are defined:

• INSTALLDIR.  This points to the MDT 2010 installation directory, e.g. “C:\Program Files\Microsoft Deployment Toolkit”.
• DEPLOYROOT.  This points to the deployment share currently being updated, e.g. “\\SERVER\DeploymentShare$”.
• PLATFORM.  This will be set to either “x86” or “x64”, depending on which boot image is being generated.
• ARCHITECTURE.  This will be set to either “x86” or “amd64”, depending on which boot image is being generated.  (Sometime its useful to have the “x64” value and other times “amd64” is more useful, so we report both.)
• TEMPLATE.  This indicates whether a Lite Touch boot image is being generated (LiteTouchPE.xml) or a generic boot image is being generated (Generic.xml).
• CONTENT.  This tells you where to find the content for this phase:
• For the WIM phase, it points to the mount location for the WIM (a temporary folder where you can manipulate the contents of the mounted WIM).
• For the ISO phase, it points to the folder that will be used to create the ISO (again a temporary folder).
• For the POSTISO phase, it will point to the created ISO file (located on the local machine, before it is copied back to the deployment share).
• STAGE.  WIM, ISO, or POSTISO, as described above.

The “C:\Program Files\Microsoft Deployment Toolkit\Samples” directory does contain the UpdateExit.vbs script described above, which demonstrates all the variables I described.

There is one bug in MDT 2010 Beta 2 that I have to point out though: the “STAGE” variable is always set to “WIM”, so it’s kind of hard to figure out which phase you are currently in.  That’s been fixed for the released version of MDT 2010.

When you perform a Lite Touch deployment, the task sequence runs through to completion, and then you will see a summary wizard that shows you any errors or warnings that may have occurred during the process.  That wizard could be skipped by setting “SkipFinalSummary=YES” in CustomSettings.ini.  (One behavior worth pointing out:  With MDT 2010 Beta 2, if the task sequence fails, the SkipFinalSummary setting will be ignored and the wizard will be shown anyway.)

A common request we received was to provide a mechanism for specifying what should be done after the wizard is completed (or if it is skipped).  With MDT 2010 Beta 2, we have provided that through a “FinishAction” variable that you can set in CustomSettings.ini.  Valid values include:

• SHUTDOWN.  When the process is complete, turn off the computer.
• RESTART or REBOOT.  When the process is complete, reboot the computer.
• LOGOFF.  When the process is complete, log off.

If you don’t specify any value, the default is to just exit like was done in MDT 2008.  The shutdown, restart, or logoff activities happen after the Lite Touch scripts have cleaned up the machine (copying logs to the network, removing MININT, removing autologon settings, etc.).  In the case of restart or logoff, the machine will end up at the logon screen, ready for a user to log on.

There were two main database limitations in MDT 2008 Update 1:

1. We didn’t add any new “settings” columns – the list of available settings was still the same as it was originally in BDD 2007.
2. To add new columns to the database and to have them show up in the Deployment Workbench required making code changes to Deployment Workbench, definitely not a trivial exercise.

With MDT 2010 Beta 2, we’ve fixed those limitations:

• We’ve added lots of additional columns, enabling you to configure any setting that could be specified via CustomSettings.ini.
• The upgrade process will modify any existing databases to add the new columns.
• The user interface in the Deployment Workbench will show any new columns without making any code changes, so you can add your own columns to the Settings table fairly easily (some SQL Server knowledge is required, obviously).

If you are looking for the database node in MDT 2010 Beta 2, you can find it under the deployment share’s “Advanced Configuration” node.  That means that each deployment share can have its own database, too.

It seems like an understatement to just say that MDT 2010 now supports PowerShell to automate Deployment Workbench administrative tasks.  Really, Deployment Workbench has been completely re-architected – all operations you perform through the UI are turned into PowerShell commands that are executed by the PowerShell engine, providers, and cmdlets.  As a result, a significant portion of the Deployment Workbench has been rewritten – this is definitely no small change.

Behind the scenes, there are a few pieces to make this work:

• A custom MDT 2010 PowerShell provider.  This exposes all the contents of a deployment share, including all the folders, all the items in those folders, all the properties of those items, etc.  These contents are accessible just like the file system or registry (both of which have their own PowerShell providers).  You use standard built-in cmdlets to access the
• Several custom MDT 2010 PowerShell cmdlets to perform MDT-specific “things”.

All of these are contained in a single PowerShell snap-in, so before you can use the PowerShell provider yourself you need to load this snap-in.  This is pretty easy to do with a single PowerShell command:

Add-PSSnapIn Microsoft.BDD.PSSnapIn

First let’s talk more about the PowerShell provider.  In order to use it, you need to create a “PowerShell drive” (see http://technet.microsoft.com/en-us/library/dd315335.aspx for details).  This is like mapping a network drive: creating a logical “drive” that is used to navigate through the logical contents of a deployment share.  The MDT PowerShell provider doesn’t create any drives by default, so you need to create one or more.  This can be done in one of two ways.  First, the manual way:

New-PSDrive -Name MyDrive -PSProvider MDTProvider -Root \\server\DeploymentShare$

In this case, the logical drive name assigned will be “MyDrive” (you could use whatever value you like), it is created using the MDT PowerShell provider which is called “MDTProvider” (always), and it points to the deployment share at \\server\DeploymentShare$.  Once the drive is created, you can navigate through it and look at the contents.

But first, let’s talk about the second way of creating MDT drives.  The Deployment Workbench keeps track of all deployment shares that you opened through the UI.  To get the same ones through PowerShell, you can execute a single cmdlet:

Restore-MDTPersistentDrive

You’ll see the names and paths for all restored drives, e.g. “DS001” for the first deployment share \\server\DeploymentShare$.

OK, so now let’s assume you have at least one PowerShell drive, “MyDrive”.  To see the top-level folders, try this:

Want to see all the drivers?  Try:

dir 'MyDrive:\Out-of-Box Drivers'

Want to create a new folder?  Try:

mkdir ‘MyDrive:\Out-of-Box Drivers\New Folder’

Want to see all the deployment share properties?  Try:

Get-ItemProperty MyDrive:

Want to update the deployment share (generating boot images)?  Try:

Update-MDTDeploymentShare -Path MyDrive:

You can use pretty much any of the standard PowerShell cmdlets for drive providers:

• Get-Item (to retrieve a specific item or folder, e.g. a driver)
• Copy-Item (to copy an item or folder from one folder to another, or from one deployment share to another)
• Move-Item (to move an item or folder to a different folder or deployment share)
• Remove-Item (to delete an item or folder)
• Rename-Item (to rename an item or folder)
• Get-ChildItem (to retrieve all the items or folders in a particular folder, alias “dir”)
• New-Item (used typically to create a new folder, alias “mkdir”)
• Get-ItemProperty (used to retrieve specific properties of an item or folder)
• Set-ItemProperty (used to set specific properties of an item or folder)

What if you want to create new applications, import drivers, create task sequences, update the deployment share, etc.?  That’s where the other MDT cmdlets come in:

• Import-MDTApplication (to import or create a new application)
• Import-MDTDriver (to import one or more drivers from the specified path)
• Import-MDTPackage (to import one or more packages – security updates, language packs, and other components – from the specified path)
• Import-MDTTaskSequence (to create a new task sequence from one of the MDT templates)
• Update-MDTDeploymentShare (to update the MDT deployment share, including creating boot images)
• Update-MDTMedia (to update a media folder and ISO)
• Update-MDTLinkedDS (to replicate content to another deployment share)
• New-MDTDatabase (to create an MDT database)
• Update-MDTDatabaseSchema (to upgrade an existing database to MDT 2010, adding all the necessary new columns)
• Get-MDTOperatingSystemCatalog (to retrieve or create an operating system catalog for a custom image so that you can edit the unattend.xml using WSIM)
• Get-MDTPersistentDrive (to retrieve the list of persistent drives, those opened in Deployment Workbench)
• Restore-MDTPersistentDrive (to create PowerShell drives for each persistent drive opened in Deployment Workbench)
• Add-MDTPersistentDrive (to add a new PowerShell drive to the persistent drive list)
• Remove-MDTPersistentDrive (to remove an entry from the persistent drive list)

The Deployment Workbench does all of its work using the cmdlets listed above.  In many cases, the wizards will show you these PowerShell commands, so that you can copy and paste them into your own PowerShell scripts.

With any luck, we’ll post more PowerShell script samples in the coming months.

Version 4.0 of the User State Migration Tool will release with Windows 7.  The RC version of it is available in the Windows Automated Installation Kit for Windows 7 RC (http://www.microsoft.com/downloads/details.aspx?FamilyID=60a07e71-0acb-453a-8035-d30ead27ef72&displaylang=en).  This has several new features, including one that MDT 2010 takes advantage of: hard-link migration.  If you are performing a Lite Touch “refresh” deployment (backing up the user state, clearing the old OS, installing a new OS, reinstalling apps, and restoring the user state), this process can be made significantly faster using hard-link migration, taking minutes instead of hours because it doesn’t actually move any of the data.  Instead, it just creates new links to the same existing files in a protected folder (e.g. C:\MININT).  When the old OS cleanup process runs later, it deletes the original links but the files remain because there is still another link in the protected folder.

The “estimate” process that is executed in the task sequence recognizes that USMT 4.0 is present.  When a refresh is being performed, it will skip the estimate because it knows a hard-link migration can be performed.

If you want to see this process in action, check out Jeremy’s video at http://edge.technet.com/Media/User-State-Migration-with-Windows-7/.

This same process works with ConfigMgr 2007 Beta 2 as well, again with the ZTIUserState estimate process automatically setting the right variables to perform a hard-link migration.  (We are investigating some issues with this, so try it out in your lab to make sure you won’t run into these.)

There are lots of other features in USMT 4.0 as well.  See http://technet.microsoft.com/en-us/library/dd560752(WS.10).aspx for the full list.

As mentioned previously, MDT 2010 now allows you to create as many folders as you want, in whatever hierarchy you want.  Once you have all of these folders, you need a convenient way of selecting one or more that you want to use for various activities.  That’s where selection profiles come in: they allow you to select a set of folders to use.

Selection profiles are used for several purposes in the Deployment Workbench and in Lite Touch deployments themselves:

• To control what drivers and packages are injected into the Lite Touch (and generic) boot images.  This is done on the property pages for the deployment share that were explored previously in the http://blogs.technet.com/mniehaus/archive/2009/06/27/mdt-2010-new-feature-7-boot-image-creation-optimized.aspx posting:
  
• To control what drivers are injected during the task sequence.  In the task sequence editor, you can see a new user interface on the “Inject Drivers” step that allows you to select the selection profile:
   
  (The driver enhancements included in MDT 2010 will be explored in a future posting – too much to go into right now.)
  
• To control what is included in any media that you create:
  
  
• To control what is replicated to other deployment shares:
  
  (This was touched on in http://blogs.technet.com/mniehaus/archive/2009/06/27/mdt-2010-new-feature-5-support-for-multiple-deployment-shares.aspx, but will probably be explored in more detail later.)
  
• To filter what task sequences and applications are displayed in the Deployment Wizard.  To do this, you can set the “WizardSelectionProfile” variable in CustomSettings.ini to the name of the selection profile to use.  (Really, this could be new feature #19, but I’ll keep it here and hope everyone reads this.)

There are several built-in selection profiles, all of which are read-only so they can’t be modified or deleted:

• Everything.  This includes all folders (nothing excluded).
• All Drivers.  Not surprisingly, this includes the “Out-of-box Drivers” folder and all its subfolders.
• All Drivers and Packages.  This includes the “Out-of-box Drivers” folder and the “Packages” folder, and all the subfolders of both.
• All Packages.  This includes the “Packages” folder and all its subfolders.
• Nothing.  This includes no folders.  (I use this for testing in Hyper-V where no drivers are required in my boot images.)

You can create as many additional selection profiles as you want.  Just right click on the Selection Profiles node and choose “New Selection Profile”.  The wizard will ask for a name and the folders you want to include.  You can select as many or as few folders as you wish.

It’s worth pointing out a few other behaviors too:

• Any new folders created under an included folder (such as a folder created under “Dell” above) will also be included by default – no editing of the selection profile is required.
• Any new folders created under an excluded folder (such as the “XXX” folder above) will be excluded by default.
• If a folder that had been selected is deleted, it won’t cause any issues – the now-invalid folder listed in the selection profile will be ignored.

This should make it easier for you, as you don’t need to worry about editing selection profiles each time you add a new folder or remove an existing one.