Configuration Manager SP2 updates all of the executables that ConfigMgr uses for an OS Deployment.  One of the files that is used during a USMT migration is called OSDMigrateUserState.exe.  During an OS Deployment this file will be in one of two places.  For a New Computer deployment the file will be on Windows PE.  If you are doing a Refresh from an existing operating system the file will reside in the client’s local CCM directory.  If you just upgraded your site servers to SP2 the client machines won’t have the upgrade OSDMigrateUserState executable.  Prior to SP2, that executable had no knowledge of USMT 4 and the directory structure change of USMT.  So if you want to use USMT 4 in your ConfigMgr deployments you are going to need to upgrade all of your clients to ConfigMgr Sp2 as well!

This is just one example where mismatched SP1 and SP2 versions on your client machines will cause issues with Windows 7 deployments.  As a best practice always make sure you have SP2 fully deployed to all of your site systems AND all of your client computers before starting a Windows 7 deployment.

-Tim Mintner

Dynamic Deployment

The entire purpose of the MDT Configuration Database is make your deployments dynamic.  Now dynamic means many different things to many different people so lets define that a bit.  MDT’s goal is to reduce administrative overhead as much as possible.  There has been a lot of advancements in the past few years to allow you to reduce the number of images in your environment in many cases down to two images, one for X86 and one for X64, for your client and server operating systems.  Reducing the number of images of just one aspect to reducing the overall administrative overhead with a deployment.  With both MDT Lite Touch and System Center Configuration Manager OSD, the number of task sequences in many environments have expanded or the number of steps in the task sequence have increased as administrators add conditional statements in the task sequence for installing specific applications or installing drivers.  The MDT Configuration Database is meant to not only reduce the number of images but allow you to use a single task sequence and have that task sequence change dynamically during the deployment based on information retrieved from the database.

Understanding MDT Variables

Before we delve too deeply into the details of the database, we first need to understand how variables work inside of MDT.  Everything that is configured inside of the task sequence in MDT matches a variable that can be configured with a value.  Let’s take a look at the Validate step in the task sequence:

In this step you can see that you can configure the minimum memory, minimum processor speed, the minimum hard drive space required, and whether or not to deploy the image based on if the existing system is running a Client or Server Operating System.  Each one of these configuration items can be configured as variables.  Respectively for these items the variables are:

• ImageMemory
• ImageProcessorSpeed
• ImageSize
• VerifyOS

So how was I able to determine which variable to use?  The MDT documentation does good job of listing all of the variables that can be set as well as limited descriptions of each of the variables.  However if you just want to get a quick list of a specific step in the task sequence you can open up your configured task sequence XML file and look at that specific step.  For example the validate step looks like the following in the XML file:

<step type=”BDD_Validate” name=”Validate” successCodeList=”0 3010″ description=”" startIn=”" disable=”false” continueOnError=”false”>
  <defaultVarList>
    <variable name=”ImageSize” property=”ImageSize”>0</variable>
    <variable name=”ImageProcessorSpeed” property=”ImageProcessorSpeed”>800</variable>
    <variable name=”ImageMemory” property=”ImageMemory”>512</variable>
    <variable name=”VerifyOS” property=”VerifyOS”>CLIENT</variable>
  </defaultVarList>
  <action>cscript.exe “%SCRIPTROOT%\ZTIValidate.wsf”</action>
</step>

Here you can see in the XML file all of the variables that are associated with the Validate Step.

So now that you have the variables how would you use them?  One possible way of using the variables would be to set them in the customsettings.ini file.  This is configured by going to the Rules tab in the properties of the Deployment Share or you can just edit the file using notepad by going to the Control directory in the DeploymentShare.

Let’s say that you wanted to set the minimum memory to 1 GB instead of 512 MB.  To do that you could edit the task sequence or you could add the following line to the customettings.ini file:

Properties = ImageMemory

ImageMemory = 1024

“Note – to see a full list of variables that MDT can configure open up the ztigather.xml file in the DeploymentShare\Scripts folder.  In this case ImageMemory is not defined in ztigather.xml so you can add it by adding ImageMemory to the Properties line in the customsettings.ini”

Now when the validate step runs it will use the value specified in the customsettings.ini instead of the value in the task sequence.  In most cases the first value for a variable that gets set will take precedence over any other value. 

Adding variables directly to the customsettings.ini is a good start to doing dynamic deployments but if you add in all of the variables you need for every scenario directly into the customsettings.ini you will quickly replace the administrative overhead of managing a huge task sequence with lots of conditional steps with the administrative overhead of managing a huge customsettings.ini file.  You also now have to worry about replicating the customsettings.ini out to many different sites, locations, or USB drives.  To simplify both the management of the task sequence and the customsettings.ini file you should use the MDT Configuration Database to store your variables.  So lets now look at how to set up the database.

Creating the MDT Configuration Database

To create the database you need to navigate to the Database node under the Advanced Configuration node in the Deployment Workbench.  Note if you are using ConfigMgr 2007 you will still need to create and manage the database using the Deployment Workbench.  MDT can use any Microsoft SQL Server from SQL Server 2000 – SQL Server 2008 including SQL Server Express.  To create the database right click on the Database and choose New Database.  You will be prompted for the following:

• SQL Server Name – name of your SQL server
• Instance – only needed if you installed SQL without using the default instance or you are using SQL Server Express
• Port – only needed if you are using TCP/IP sockets (not recommended)
• Network Library – Named Pipes or TCP/IP sockets

Let’s talk a little bit about the Network Library.  It is HIGHLY recommended that you use Named Pipes over TCP/IP sockets.  Unfortunately Windows PE does not have the ability to use integrated security with TCP/IP sockets.  That is if you want to use an Active Directory or Windows username and password to connect to the database you must be using Named Pipes.  If you use TCP/IP sockets you would need a SQL user account and password. 

The next item you will need to provide is the SQL Share.  That is a share that MDT uses to authenticate to the server so that integrated security can be used.  The share does not need to contain anything, it just needs to exist on the SQL Server. 

Now that you have created your database by completing the wizard.  You need to configure the CustomSettings.ini to use the database.  To do so again right click on the Database node and choose Configure Database Rules.  This will start another wizard. For right now just click on Next until you have completed the wizard and your customsettings.ini file will be fully configured to query the database during your deployment. Note if you are using ConfigMgr 2007 with MDT integration, you will need to take the customsettings.ini and place it in your settings package.

Add items to the Database

So now that you have created the database and configured the customsettings.ini to query the database.  Expand the Database node and you should see a screen like the following:

MDT allows you to configure settings based on the following:

• Computers – identified by MacAddress, UUID, or Serial Number
• Roles – arbitrary grouping computers (Accounting, Finance, IT, etc.)
• Locations – defined by default gateways
• Make and Model – Computer manufacturer and model specific settings

So lets configure a setting in the database that states for all Dell Latitude E5500 computers the Display Resolution should be 1440 X 900.  To do that we would add an entry under Make and Model.  Right click on Make and Model and choose New.  Enter the following:

• Make – Dell Inc.
• Model – Latitude E5500

Click on the Details Pane and you should see a screen like the following:

Find Xresolution and set the value to 1440.  Also set the Yresolution to 900.  By clicking on Apply the values will be set and now when the deployment occurs all Dell Latitude E5500 laptops will automatically get the display resolution set.  There is nothing to configure in the task sequence or in the customsettings.ini because we already configured the customsettings.ini to query the database earlier.

This is a very simple example of one particular setting.  In future posts I will cover more scenarios such as Make and Model application selection, driver selection and Location, Role, and computer specific settings.

Updating your Boot Image

The only thing left for you to do is verify that your boot image contains ADO (Active-X Data Objects).  ADO is needed to query a database.  In Lite Touch, ADO is configured by default.  To verify this go to the properties of your Deployment Share and click on either Windows PE X86 Components or Windows PE x64 Components and verify that ADO is selected under Feature Packs.  If it is not, select it and Update your Deployment Share.

For ConfigMgr you will need to create a custom boot image using the MDT provided wizard.  Right click on Boot Images and choose Create Boot Image using Microsoft Deployment and walk through the wizard making sure you choose ADO under Feature Packs.

Summary

This post just explained the very basics of why you would want to use the database and how you can set your database up very quickly.  There is a lot more that the MDT Configuration Database can provide and automate to make your deployments truly dynamic.  Make sure you check back for more posts in the future on some intermediate and advanced posts on the MDT Database.

-Tim Mintner