jump to navigation

Understanding the MDT Configuration Database Part 1 November 24, 2009

Posted by tmintner in Database, MDT 2010, System Center Configuration Manager.
Tags: , ,

The MDT Configuration Database has been around since MDT was called Business Desktop Deployment (BDD).  Since that time there have been numerous blog posts and articles on how to customize the database, extend the database, or use the database in specific ways to solve specific problems.  With all of those articles there doesn’t seem to be a single article that explains what the database is or why you would even want to use it.  The MDT documentation even jumps right in and shows you all of the steps that you would do to configure the database and use it to do specific scenarios but the documentation doesn’t cover the basics of what it is or why use it?  This is a first in series of blog posts that I will be writing to cover the details of the MDT Configuration Database.  In this post, I will cover the basics of the database, why you would want to use it, some of the items that you can configure in the database, and how you will initially get the database installed.

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”>
    <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>
  <action>cscript.exe “%SCRIPTROOT%\ZTIValidate.wsf”</action>

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.


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



1. Hands off my gold image – Microsoft Deployment Toolkit details | Aaron Parker - October 30, 2012

[…] could potentially use a Configuration Database instead; however I’ve opted to use CustomSettings.ini so that I can use an approach that is […]

2. Mike Webb - January 11, 2012

Sure would like to see Part 2 of this. I’m new to MDT (~ 3months) and am thinking of using a database for our deployments. But finding articles on the “how” and “why”, as Part 1 is, are about non-existant.

3. Using MDT Queries to Assign Applications to Specific Hardware « Mike's Blog - October 26, 2011

[…] Documentation) so I won’t rehash that information.  One I found particularly good was this one.  After you have configured that database and the rules make sure you update your WinPE boot […]

4. Simon - September 16, 2011

Just to re-iterate what many have said, great article, exactly what I’ve been looking for.

5. Setting up the MDT Web Front End « HardcoreITguy's Blog - January 16, 2011

[…] Setting up the MDT Web Front End January 16, 2011 HardCoreITGuy Leave a comment Go to comments At long last I managed to convince a customer to start using the MDT Database so that we could have more control over the deployment process and build in better automation.  While I’d love to get into that topic at some point, for now just read the article over at Xtreme Deployment: http://deployment.xtremeconsulting.com/2009/11/24/understanding-the-mdt-configuration-database-part-… […]

6. ken - July 1, 2010

Hi there,

i am looking for similar solution. I need to store a group of computer names in the SQL server and these name will be assign during the deployment to different computer. Is it possible by following up on this post?


7. Craig Taylor - April 30, 2010

Hi I have an issue with the client still trying to connect to the MDT database using anonymous logon. Everything is working and I have my database setup to use named pipes and have the sql share on the SQL server. The deployment is working but the SQL logs show the client computer trying to connect directly using anonymous logon (which fails) and then it logs on using the named pipe and specified user and succeeds. So at the end of the deployment I get 12 errors trying to connect anonymously, although the deployment has worked. Anyone know how I stop the anonymous logon?


8. sachin kapoor - April 15, 2010

Hats off to You man, What a nice presentation of the article. Keep it up & help the community

9. MDT Web FrontEnd – How To handle Custom Settings/Properties - Maik Koster at myITforum.com - February 2, 2010

[…] soon as you have changes in the configuration of your Deployment. Please see Tim Minters Post about Undestanding the MDT configuration database for a better introduction on why to use it and how to set it […]

10. Arun - January 17, 2010

Excellent article. Thanks.

11. MDT Web FrontEnd – How To restrict access to the Deployment Database - Maik Koster at myITforum.com - January 17, 2010

[…] is a great utility for your Deployments, no matter if you are using it in LTI or ZTI scenarios. Tim Mintner recently wrote an interesting article about what the Database is and why one should use …. If you use the Deployment console to access the database it has (at least) one major drawback, […]

12. Brian - December 9, 2009

I am having issues installing applications configured via the MDT 2010 database Make/Model entries. I configured my database for Named Pipes and added an entry in the database for a laptop make and model using the exact values captured from a prior WMI
query. On the Applications tab of that same entry, I added two software titles from the list of available Applications, then saved the entry. I verified that the customsettings.ini file is configured for database rules. I then run the task sequence on the laptop and it runs successfully – no errors. However, the two applications are not installed. I then reconfigured the applications in MDT, turning the “Hide this application in Deployment Wizard” option on/off, and retried the task sequence. No dice! Has anyone else encountered
these problems? Can anyone offer some suggestions?


tmintner - December 9, 2009

Hi Brian,

First you should look in the ztigather.log file and make sure those applications are getting set through the database. You should see entries such as Applications001= {GUID} that should match what you have set in the database. If they do show up in gather then investigate the ztiapplications.log file to see if the applications were attempted to install

13. tmintner - December 2, 2009

In the [Default] section in your customsettings.ini you should add:

OSDMigrateAdditionalCaptureOptions = %ScanStateArgs%
OSDMigrateAdditionalRestoreOptions = %LoadStateArgs%

14. tmintner - December 2, 2009

Hi Jesse,

The user state options when using Configuration Manager use slightly different variables than LoadStateArgs and ScanStateArgs. WIth ConfigMgr the variables are OSDMigrateAdditionalCaptureOptions and OSDMigrateAdditionalRestoreOptions. You can still use the LoadstateArgs and ScanStateArgs variables in the database you just need to do a mapping of the variables in the customsettings.ini.

So in your customsettings.ini you need to add the following in the Properties
Properties = OSDMigrateAdditionalCaptureOptions, OSDMigrateAdditionalRestoreOptions

15. Jesse - December 1, 2009

above it should be only domain\* profiles

16. Jesse - December 1, 2009

I have the database up and configured with location based rules, I also have the MDT extentions integrated into SCCM 2007 SP2 and can deploy MDT based images through SCCM. I am now hanging up on how to use USMT 4.0 as it pertains to the MDT DB with SCCM. Specifically I want to use the ScanStateArgs and LoadStateArgs to specifly only \* profiles should be captured and/or restored. The problem is I am having trouble getting USMT to use the settings from the DB, it appears that this should work however it seems to be ignoring the DB settings. Any ideas, I haven’t found anything online relating to USMT, MDT, SCCM all while using the Config DB.

17. Alex - November 25, 2009

Very NICE! Been looking for this kind of article.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: