Jun 28

Print this Post

MDT for the small(er) guys – Part 3

In part 3 of this series, you’ll be configuring MDT – specifically, you will go about adding Windows 7 SP1 and XP SP3.  You’ll also be adding Office 2010 (with SP1), and handling drivers for both Win7 and XP.


Create and Configure Your Distribution Point

The first thing you need to do, of course, is to create a distribution point.  This is the main structure for deploying, so you need to do this first.  To begin, open the Deployment Workbench from the start menu on your MDT virtual machine:

Once the workbench is open, right-click the Deployment Shares folder and select “New Deployment Share” from the menu:

The New Deployment Share Wizard will open – you will need to select a local folder to store your deployment files, the folder name, the share to expose from the server, and a few other options.  Here you can see what I’ve chosen for my particular build share (C:\MDT\Build, Build, and Build$ – took the defaults for other options):

Clicking the “Next” and then “Finish” buttons will copy files to your deployment share, and will add your share and it’s contents to the workbench:

Right-click the new deployment share folder (in my example, “Build”) and select “Properties”:

Next, you will configure the options in the 4 Windows PE tabs to look like the following:

These options configure MDT to not add any drivers (yet) to any WinPE images you build to deploy and sets the driver scratch space to 128MB (rather than 32MB) for both the x86 and x64 PE images created with MDT.  Scratch space is the writeable memory that the PE environment can use, and with MDT this is mostly used when dealing with drivers.  Unless you absolutely can’t spare the additional 128MB of RAM on machines you run a PE image on when deploying Windows, set this to 128MB to be safe.

Once you’ve configured the above settings and clicked the “Apply” button, you will want to modify the rules to automate a lot of the build settings that you would otherwise be prompted for.  Since we are assuming (at least for this series of MDT posts) that these builds will be for new Windows installs, there should be no issues with these settings.  As always, feel free to change these as you get comfortable with MDT, and all of the settings in the “Rules” tab (technically, this is just an interface to \Control\CustomSettings.ini in your deployment share) are documented in the MDT 2010 help installed when you installed MDT.  Here is a listing of what I have in my rules tab – feel free to remove what you have in your “Rules” tab and replace with the information listed below:









TimeZoneName=Eastern Standard Time









Next, click the “Bootstrap.ini” button, and add the following lines below the “Deployroot” line (unlike the “Rules” tab where you replaced, in bootstrap.ini you need to add to what already exists – otherwise, deployment will behave…. oddly):



Once you’ve made these changes, save and close the Bootstrap.ini file, then click the “Apply” button.  Once you’ve made these changes, your “Rules” tab and Bootstrap.ini files should look like this:



The above settings will automate most everything, including setting the time zone, keyboard locale for EN-US, setting the computer’s Administrator account password, and a few other things.  You should only be prompted for a computer name and which applications to install when this is finished using these settings.  Click the “OK” button to close the Build Properties window, making sure to also save the Bootstrap.ini file.


Add Applications

The next thing to do, once this portion is completed, is to actually add some applications to the workbench.  To do this, click on the “Applications” folder in your deployment share, and select “New Application”.  It will bring up the New Application Wizard, which prompts you to select application type:


Select “Application with source files”, and click the “Next” button.  Enter details about the application, and click the “Next” button again:

Point the wizard at your Office 2010 DVD or ISO (you will need to acquire this from your VL site, MSDN/Technet subscription, or your retail DVD set you got from the store) when prompted for the source, enter the name (you will see this name during installation in the progress dialog), and enter the command line used to install the application (in this case, for Office 2010, it is simply “setup.exe” minus the quotes).  Click the “Next” button twice at this point to begin the file copy from the Office 2010 installation source to the deployment share, and then click the “Finish” button when that completes.  Your Applications folder should now look something like this:

Double-click the new Office 2010 Application item, and click the “Office Products” tab.  Select the version of Office from the “Office product to install” box, check the “Customer Name” box (and enter a value), check the “Display Level” box (and select a value – I choose “Basic”), and click the “Accept EULA” box:

Click the “OK” button to save the data.  If you look on the “Details” tab at this point, the command line should now read “setup.exe /config <Version.WW>\config.xml”:

Repeat the import of all other applications you want to be available in your deployments.  Once you’ve added the applications you want to add (the more unattended/silent installations you can use here, rather than attended installations, the better), move along.


Add Operating Systems

Now, you will add our Windows 7 SP1 and XP SP3 installation sources.  To do so (again, you will need your Windows 7 SP1 and Windows XP SP3 installation DVD or sources available for this), right-click on the “Operating Systems” folder in the deployment share, and select “New Folder”.  Create a Windows 7 folder, and then repeat and create a Windows XP folder – you may also want to create x86 and x64 subfolders for any operating systems you deploy both of (I’ve done this for Windows 7 in my share, but I only deploy XP x86, so I did not do this for XP).  You should end up with something like this:

Next, import each operating system’s source files into the appropriate folders.  To do so, you would right-click on the folder you wish to store the Windows sources in and select “Import Operating System” (again, for Windows 7 in my example, I’m right-clicking on the \Windows 7\x86 or \x64 folder depending on whether the Win7 Enterprise source is x86 or x64):

When the Import Operating System Wizard appears, select the “Full set of source files” option, and click the “Next” button.  Browse to the location of your Windows 7 installation source (again, in my example, the Windows 7 Enterprise x86 ISO mounted to the virtual machine’s DVD drive), and click the “Next” button.  Give the destination directory a name when prompted – I prefer the format “<architecture> <Windows Version> <SKU> <Service Pack>”.  So, for this import of x86 Win7 Enterprise SP1, I used the folder name “x86 Windows 7 Enterprise SP1”:

Click the “Next” button twice to begin the file copy of the Windows source to your distribution share, and then click the “Finish” button when the process completes.  Repeat the steps above for each version of Windows 7, Vista, XP, Server 2003, Server 2008, or Server 2008 R2 you want – it’s up to you what’s in here, and what’s not.  Again, for this example I’m just doing Windows 7 Enterprise and XP Professional SP3, but you are by no means limited to these.  Once your OSes are imported, move along.


Driver Management / Add Drivers

After you’ve imported your operating systems, the next thing to tackle is drivers.  Given that most deployment issues seem to come down to drivers, making sure that only the drivers you need get added to the system as it is deployed is important.  By default, most new MDT users tend to simply add all drivers to the Out Of Box Drivers folder and pray that Windows does a good job of PnP detection and device matching on the drivers in this store (which it usually does, thankfully).  However, this is not a very good method of driver management, and can slow down deployment time as PnP detection runs against a long list of drivers, most of which it isn’t likely to apply.  There are better ways, and Microsoft’s official stance suggests using something called a “Selection Profile”.  While I like this approach for drivers that you want to add to Windows PE, it makes less sense for regular OS installs via task sequences, especially if you start adding a lot of drivers for a lot of different computer hardware.  Instead, I (strongly) recommend using “Make\Model” driver management as espoused by many deployment gurus out there, including Johan Arwidmark in his blog (see Scenario #3, “Total Control”).


Basically, you would create a folder structure following the Make and Model of the hardware you’re deploying Windows to, with subfolders under this Make\Model path for differing Windows versions and architectures.  For example, for an HP EliteBook 8540w, you would have a folder under the Out-of-Box Drivers folder called “Hewlett-Packard” (the “Make”).  Then, under that folder you would have another called “EliteBook 8540w” (the “Model”).  There is a rhyme and reason to this folder structure – it can be gathered from a command prompt with the command wmic csproduct get name,vendor which produces output similar to this:

You will see that the “Vendor” string is used as the “Make” folder, and the “Name” string is used as the “Model” folder.  If you follow this pattern (there’s a trick with Lenovo machines I’ll mention later), this will make it very easy to add new machines to your MDT deployment share without modification to your task sequences (read: make your job easier).

To add drivers for specific hardware to your deployment share, create the appropriate folder structure (again, in this guide I’m using the HP EliteBook 8540w machine as an example) by right-clicking on the Out-of-Box Drivers folder and selecting “New Folder” – name the folder according to the Make and Model nonclemature I’ve just outlined above for the machine / hardware you are adding, so that you end up with something that looks like this:

Next, right-click the “Model” folder (in this example, the “EliteBook 8540w” folder) and select “Import Drivers” to begin the driver import process.  Browse to the location of your downloaded drivers (this can be extracted .inf drivers or .cab file driver archives – this will NOT work on drivers in an .exe package, you will have to find a way to extract these manually, or install these as applications later on during task sequencing) when prompted, and click the “Next” button twice to begin the driver import process:

Note that you may see some “yellow” warning items as the driver import progresses – this is normal, and unless there’s a problem during your testing of these drivers later, can be safely ignored (MDT is trying to determine if a driver actually supports the platform it’s INF file says it does during this import process, and any driver that doesn’t match up will have the architecture it doesn’t actually properly support documented here in a warning line item that is colored yellow).  Once the driver import process completes with no errors (again, warnings OK, but not errors), click the “Finish” button to close the driver import wizard.

If all went OK, you should see something like this in that model’s driver folder:

Repeat this for every hardware make and model you expect to support.  Note that Dell makes this fairly easy, because it provides driver .cab files for System Center Configuration Manager for quite a few of it’s models – these can be downloaded as-is and imported into MDT too.  Simply download the Dell .cab file for your model, create the appropriate folder structure in the Out-of-Box Drivers folder, and import the drivers.


Task Sequencing

Once you’ve imported drivers, you will create the Task Sequences needed to deploy the operating systems, applications, and drivers added to the deployment share.  Think of Task Sequences as the brains of the deployment – a Task Sequence is simply a list of steps that the deployment will take, in order, to do things like format drive(s), install a version of Windows, inject drivers, install applications, etc.  To create a new Task Sequence, right-click the Task Sequences folder in your deployment share and select “New Task Sequence”.  When prompted, provide a Task sequence ID (this string will be used to allow MDT to refer to this Task Sequence internally), and provide a Task sequence name (this string will be what shows up in the wizard to choose as an installation option):

Click the “Next” button, select “Standard Client Task Sequence” for client operating systems you deploy (choose the “Standard Server Task Sequence for server OSes, obviously), browse to and select the version of Windows you are going to deploy via this Task Sequence, choose whether or not you want to specify a product key for the version of Windows that you are installing with this task sequence (I choose not to, for this example), provide a user and organization name for the computers built via this Task Sequence, choose whether or not to specify an Administrator password (since our “Rules” specify a password, I choose not to do so in the task sequence), and then click the “Next” button and “Finish” buttons in that order to finish creation of the Task Sequence.  You should end up with something like this:

Right-click your newly-created Task Sequence, and select “Properties”.  Then, click the “Task Sequence” tab – this tab contains all of the steps that the sequencer will take when installing this operating system to a new computer via this Task Sequence.  Feel free to peruse a bit before continuing if you’ve never seen this before.  Once you are done perusing, we need to make a few changes.  First, we need to modify the “Gather local only” task under the “Initialization” group, making sure to select the “Gather local data and process rules” radio button, and entering the string “customsettings.ini” (minus the quotes, of course) into the box provided:

Next, we need to modify the drivers section of the “Preinstall” group.  First, we need to add a new “Set task sequence variable” step to the “Preinstall” group, right below the “Configure” step.  Click on the “Configure” step under the “Preinstall” group, then click Add > General > Set Task Sequence Variable from the menu bar to add a new item:

Now, you need to fill out the Task Sequence Variable name, as well as the Value you want to assign to it:
Task Sequence Variable:  DriverGroup001
Value:  %MAKE%\%MODEL%\Windows 7

Next, you need to change the existing “Inject Drivers” step so that the “Choose a selection profile” drop-down box is set to “Nothing”:

You now have a Task Sequence to deploy a version of Windows, applications, and apply drivers based on the hardware model and what you have for that hardware in your driver store.  If you want to create task sequences for other operating systems you’ve added to your Operating Systems folder, go back and repeat these steps for each OS.  Once done, move along.


Create Boot Images

The last bit necessary to actually deploy Windows using the Task Sequence(s) you created, you will need to update the deployment share and move the WIM files created when doing so into WDS.  To do this, right-click on the deployment share folder itself, and select “Update Deployment Share”:

From the Update Deployment Share Wizard, select the “Optimize the boot image updating process”, and click the “Next” button (twice) to begin creation of the boot images:

This will build both the x86 and x64 boot images.  Once the process is complete. press the “Finish” button.


Windows Deployment Services Configuration

Now, you need to add the boot images just created to WDS so that clients can boot to the network and build.  To do so, open the Windows Deployment Services console from Start > All Programs > Administrative Tools > Windows Deployment Services.  Once the WDS console starts, expand the Servers node, right-click on the server in the list, and choose “Configure Server” to start the configuration wizard.  Click the “Next” button, select a folder for WDS to store the boot images (do NOT select the same folder as the MDT Deployment Share), select the radio button “Respond to all client computers (known and unknown)”, and click the “Next” button to finish the configuration.  When prompted to add images at the end, uncheck the “Add images to the server now” box and press the “Finish” button.

Now, you will need to add the boot images.  Right-click on the “Boot Images” folder and select “Add Boot Image…”:

Browse to the \Boot folder inside your deployment share, and select the x86 or x64 LiteTouch boot WIM file to add to the WDS Boot Images folder:

Once you’ve clicked the “Open” button to add the selected boot WIM file, click the “Next” button, provide a boot image name (this is what you will see in the WDS boot menu when you PXE boot a client), click the “Next” button twice, and click the “Finish” button once adding the boot WIM file completes.  Repeat these steps to add the other boot image, then continue:


Testing the Deployment

Now, to test your deployment, create a new virtual machine to be used as a client, using the same steps as you used to create virtual machines in Part 1 and Part 2 except for *one setting* – when you get to the “Installation Options” pane of the wizard, you need to select the “Install an operating system from a network-based installation server”:

Once your client virtual machine is built, you can boot it and press F12 when prompted to boot to the network, select a boot image, and start building!


I hope this has been a useful primer for those of you looking to use MDT 2010 to deploy Windows – either from a home user/small business/OEM perspective on upwards to small and medium-sized businesses.  If you have questions or issues, please let me know in the comments.

Permanent link to this article: http://www.cluberti.com/blog/2011/06/28/mdt-for-the-smaller-guys-part-3/

Bad Behavior has blocked 310 access attempts in the last 7 days.