http://windowsteamblog.com/windows/b/business/archive/2011/08/01/mdop-2011-r2-now-available-for-download.aspx

Available for download from your VL site, MSDN/Technet, and supposedly to Intune Subscribers (not sure how that works yet, but I’m looking into Intune).

Installing the tools

Before gathering any data, you will first need to download the installation packages necessary to install the Windows Performance Toolkit on your Windows 7 machine.  The Windows Performance Toolkit is a part of the Windows 7 SDK, but you won’t need to install the entire SDK to get the WPT installation files if you follow this guide.  First, you need to download the Windows 7 SDK, which is a 500K web installer (click the “Install Now” link).  Once you start the installation, you only need to check the “Windows Performance Toolkit” checkbox under the “Redistributable Packages” section – uncheck EVERYTHING else:

After you click next, it will download (only) the installation .MSI packages needed to actually install the WPT. Once the download of the files is complete and you exit the SDK installer, you will need to actually install the version of the WPT that matches the architecture of your OS (the x86 MSI on a 32bit Windows 7 machine, the x64 MSI on a 64bit Windows 7 machine). The downloaded .MSI files will be located (by default) in C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Windows Performance Toolkit:

Install the correct .MSI that matches the architecture (32bit or 64bit) of your Windows 7 install, taking all the default options and performing a “Complete” installation.

Last, you will need to open an ELEVATED CMD PROMPT to execute any of the trace options described in this guide.

Creating a BOOT trace:

First, you will need have that elevated CMD prompt open.  Second, to generate a boot trace, you will need to type the following command into the CMD prompt, and press the ENTER key to execute it – note that this command is ALL ONE LINE

xbootmgr –trace boot -traceFlags BASE+LATENCY+DISK_IO_INIT+DISPATCHER+DRIVERS+FILE_IO+FILE_IO_INIT+NETWORKTRACE+PERF_COUNTER+POWER+PRIORITY+REGISTRY -postBootDelay 300 -resultPath C:\Boot_Trace

This command will cause your machine to shut down and reboot automatically.  Once the system restarts, please log back in (as necessary) as soon as possible to minimize the size of the resulting trace file.  Once logged in, the system will present a dialog box letting you know that it is waiting 120 seconds (it will count down) before finishing the trace.  DO NOT use your computer to do anything during this time – let the countdown finish and trace files generate:

Once the trace is complete, you will find a (large) .ETL file and a log file in C:\Boot_Trace.  This .ETL file can then be analyzed either by yourself or by other support personnel.

Creating a Shutdown trace:

First, you will need have that elevated CMD prompt open. Second, to generate a boot trace, you will need to type the following command into the CMD prompt, and press the ENTER key to execute it – note that this command is ALL ONE LINE:

xbootmgr –trace shutdown -traceFlags BASE+LATENCY+DISK_IO_INIT+DISPATCHER+DRIVERS+FILE_IO+FILE_IO_INIT+NETWORKTRACE+PERF_COUNTER+POWER+PRIORITY+REGISTRY -resultPath C:\Shutdown_Trace

This command will cause your machine to shut down and reboot automatically. Once the system restarts, please log back in (as necessary) as soon as possible.  Once logged in, the system will present a dialog box letting you know that it is waiting 120 seconds (it will count down) before rebooting your machine A SECOND TIME.  DO NOT click the countdown dialog, or in any other way utilize your computer to do anything during this time – let the countdown finish and the system restart:

Again, once the system restarts a second time, please log back in (as necessary) as soon as possible.  This time, the trace will finalize:

Once the trace is complete, you will find a (large) .ETL file and a log file in C:\Boot_Trace. This .ETL file can then be analyzed either by yourself or by other support personnel.

Creating a REBOOT trace:

First, you will need have that elevated CMD prompt open. Second, to generate a boot trace, you will need to type the following command into the CMD prompt, and press the ENTER key to execute it – note that this command is ALL ONE LINE:

xbootmgr –trace rebootCycle -traceFlags BASE+LATENCY+DISK_IO_INIT+DISPATCHER+DRIVERS+FILE_IO+FILE_IO_INIT+NETWORKTRACE+PERF_COUNTER+POWER+PRIORITY+REGISTRY -resultPath C:\reboot_Trace

This command will cause your machine to shut down and reboot automatically. Once the system restarts, please log back in (as necessary) as soon as possible. Once logged in, the system will present a dialog box letting you know that it is waiting 120 seconds (it will count down) before rebooting your machine A SECOND TIME. DO NOT click the countdown dialog, or in any other way utilize your computer to do anything during this time – let the countdown finish and the system restart:

Again, once the system restarts a second time, please log back in (as necessary) as soon as possible. This will start another 120 second countdown, and reboot your machine A THIRD TIME.  As before, DO NOT utilize your computer during this time – let the countdown finish (again) and the system restart (again):

Once the system restarts a third time, please log back in (as necessary) as soon as possible. This time, the trace will finalize:

Once the trace is complete, you will find a (large) .ETL file and a log file in C:\Boot_Trace. This .ETL file can then be analyzed either by yourself or by other support personnel.

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:

[Settings]
Priority=ByLaptopType,ByDesktopType,ByServerType,TaskSequenceID,Default
Properties=MyCustomProperty

[Default]
OSInstall=Y

UserID=Administrator
UserDomain=DEMO
UserPassword=Password1

OrgName=Org
FullName=User
AdminPassword=Password1

JoinWorkgroup=WORKGROUP
;JoinDomain=DEMO
;DomainAdmin=Administrator
;DomainAdminDomain=DEMO
;DomainAdminPassword=Password1

_SMSTSORGNAME=Demo Build

;WSUSServer=http://MDT
;SLShare=\\MDT\Build$\Logs

BDEInstallSupporess=YES
;BDEInstallSuppress=NO
;BDEInstall=TPMPin
;BDEKeyLocation=C:
;BDEPin=12345678
;BDERecoveryKey=AD
;BDEWaitForEncryption=FALSE

UILanguage=en-us
UserLocale=en-us
KeyboardLocale=en-us;0409:00000409
TimeZone=035
TimeZoneName=Eastern Standard Time

SkipAdminPassword=YES
SkipApplications=NO
SkipAppsOnUpgrade=NO
SkipBDDWelcome=YES
SkipBitLocker=YES
SkipBitLockerDetails=YES
SkipCapture=YES
SkipComputerName=NO
SkipDomainMembership=YES
SkipFinalSummary=YES
SkipLocaleSelection=YES
SkipPackageDisplay=YES
SkipProductKey=YES
SkipSummary=YES
SkipTaskSequence=NO
SkipTimeZone=YES
SkipUserData=YES

UserDataLocation=NONE
FinishAction=RESTART

[ByLaptopType]
Subsection=Laptop-%IsLaptop%

[Laptop-True]
OSDComputerName=LAPTOPCHANGEME

[ByDesktopType]
Subsection=Desktop-%IsDesktop%

[Desktop-True]
OSDComputerName=DESKTOPCHANGEME

[ByServerType]
Subsection=Server-%IsServer%

[Laptop-True]
OSDComputerName=SERVERCHANGEME

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):

SkipBDDWelcome=YES

UserID=Administrator
UserDomain=DEMO
UserPassword=Password1

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.

Create a Virtual Machine for your MDT server

In the Hyper-V Manager, click Action > New > New Virtual Machine to bring up the New Virtual Machine wizard.  On the first page, give the new VM a name that will show up in the Hyper-V console (I chose “MDT”), and click the “Next” button:

Next, give the virtual machine some RAM – I chose 2GB – then click the “Next” button:

Attach the VM to the network you created earlier from the drop-down list (you can see my “Internal” network chosen here), and then click the “Next” button:

Choose to “Attach a virtual hard disk later”, and click the “Finish” button (clicking “Next” will give you a summary, where you will then click “Finish”):

You should now see your newly-created virtual machine in the Hyper-V Manager:

With your VM highlighted, click Action > Settings to bring up the VM settings window. Click “Processor” and change the number of logical processors to “2”, and then click “IDE Controller 0”:

Select “Hard Drive” in the right-hand pane, and click the “Add” button to bring up the New hard drive window:

Click the “New” button, select “Differencing”, and click the “Next” button:

Give the new VHD a file name (I called it “MDT.vhd” here), and click the “Next” button:

Point the wizard at your “parent” VHD (either the 2008 R2 trial VHD you downloaded and extracted from the hyperlink I gave in Part 1, or another sysprep-ed 2008 R2 VHD you already had) and click the “Finish” button:

You should now have your MDT virtual machine configured with a new hard disk and 2 processors, as seen below. Click the “OK” button to finish and return to the Hyper-V Manager:

Configure the Virtual Machine to be your MDT server

Double-click the new MDT virtual machine you see in Hyper-V Manager to open it in the Virtual Machine Connection viewer, and click the green “Start button” (or Action > Start) to start the virtual machine. If everything went well, it should boot up and complete the end of setup (installing devices, etc). During this setup phase, you may be asked to enter a product key (don’t, just click the “Skip” button) and agree to a EULA license (do):

If something is wrong here, go back and retrace your steps to make sure you haven’t missed anything. If you are using the downloaded VHD from Microsoft, this step may not be necessary. This is normal if it boots directly into Windows.

Once the machine does finish setup and boots for the first time (if you have downloaded and are using the trial VHD from Microsoft, the administrator password is Pass@word1), you can login with the Administrator account and begin readying it to handle MDT and deployment duties:

In the Initial Configuration Tasks window that will open once you log in, click the “Provide computer name and domain” link, and then click the “Change” button.  Enter a computer name for your domain controller in the “Computer name” box (again, I used “MDT”), and click the “OK” button:

Click “OK” again when prompted that you will need to reboot, and then click the “Close” button.  Click the “Restart now” button when prompted to restart the virtual machine.

At this point, you will probably want to reserve the MDT server an IP address, and you will need to install the WDS role.

To configure a reservation in DHCP for the MDT server, open your DC virtual machine, log in if necessary, and open the DHCP console from Start > All Programs > Administrative Tools.  Expand the IPv4 node, expand the scope, and click on the Address Leases item:

You should see a lease listed for the MDT server (in my case, “MDT.demo.local”.  Right-click on this lease item, and select “Add to Reservation”:

Click the “OK” button when receiving a prompt that the lease has been converted to a reservation successfully:

You should now see a new reservation for the MDT server in the DHCP console:

Now that your MDT server has a DHCP lease, go back to the MDT virtual machine and log on as Administrator.  Once logged on and the Initial Configuration Tasks window appears, click the “Provide computer name and domain” link, and then click the “Change” button.  Select the “Domain” radio button, and enter the domain name (in my example, demo.local), and click the “OK” button:

Enter the domain Administrator account and password information in the boxes provided, and click the “OK” button to join the MDT server to the domain:

Click the “OK” button when prompted that the server has joined the domain successfully:

Click the “OK” button, then the “Close” button, and restart the computer when prompted to finish the domain join process.

Once the virtual machine reboots, click the “Switch User” button, then click “Other User”:

Enter the domain Administrator user account and password in the boxes provided (the user account should be entered in the form of DOMAIN\Administrator – in my lab, this equates to DEMO\Administrator as seen in the screenshot below), and press ENTER or click the blue arrow to log into the domain as the domain Administrator:

Once logged in and after the Initial Configuration Tasks window appears, click the “Add roles” link to bring up the Add Roles Wizard:

Click the “Next” button, select the “Windows Deployment Services” role, and click the “Next” button:

Click “Next”, accept the default options that has the “Deployment Server” and “Transport Server” role services selected, click the “Next” button, and then click the “Install” button to begin installation of WDS:

If everything went well, you should see the installation report as successful – click the “Close” button to finish:

Next, you need to actually install the Windows 7 Automated Installation Kit (WAIK) and MDT 2010 Update 1.  You can download the WAIK and MDT 2010 Update 1 from the links below:
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5753
http://www.microsoft.com/download/en/details.aspx?displayLang=en&id=25175

The WAIK is a (very large) ISO download, so be prepared for a long download, even on a fast connection.  As to the MDT 2010 download, you will need the x64 installation MSI package.

Install the WAIK and MDT

Once the download of both files is complete, mount the WAIK ISO to your MDT virtual machine by clicking Media > DVD Drive > Insert Disk… in the virtual machine connection window for the MDT virtual machine.  Browse to and select the ISO you downloaded, and click the “Open” button.  This will mount the ISO to the VM.  Autoplay should come up, and present you with a menu that looks like this:

Select the “Run StartCD item”, and the Windows 7 Automated Installation Kit wizard should appear.  Click the “Windows AIK Setup” link to begin setup of the WAIK:

Click the “Next” button, click the “I Agree” radio button and click the “Next’” button (three times) to begin the installation:

Click the “Close’ button to finish the installation.

Next, you will need to install MDT, which means getting the installation MSI package into the VM.  I use ISO Creator 3.1 (64-bit version) on my Hyper-V machines to turn folders into ISOs (which can then be mounted into Hyper-V VMs) – after you install ISO Recorder to your Hyper-V server, you can place the MDT installation MSI file into a folder, right-click on that folder, and select “Create ISO image file”.  This will bring up the ISO Recorder wizard:

Select “CD” from the “Image format” drop-down box, and click the “Next” button to create the ISO.  Click the “Finish” button when complete.

At this point, you should now have an ISO file that you can mount to the MDT virtual machine via Media > DVD Drive > Insert Disk… from the virtual machine connection window.  Once the ISO file is mounted, browse into the mounted CD in the MDT VM, and run the x64 MSI file to start the MDT installation:

Click the “Next” button, click the “I accept the terms…” checkbox, click the “Next” button (twice), and click the “Install” button to begin the installation:

Click the “Finish” button to complete the installation.

At this point, you should now have both a domain controller and a server in your lab running MDT and WDS.  Part 3 of this series covers adding the necessary operating system and application files, drivers, and the task sequences to deploy these.

In this part, I am going to (very quickly) review installation of the servers and the Windows Active Directory domain services required to follow the rest of this guide.  This is not really the gist of this series, but given that it is required to follow the rest of the guide, I thought it might be important to have a quick review of my (admittedly small) lab environment just in case some of the readers of this guide need help with this particular part of the setup.  If you already know how to build (or already have at your disposal) a Windows domain and a second server to handle the other roles, you can skip Part 1 and go to Part 2, where we actually install MDT, the WAIK, and WDS.

Suffice to say, you will need a Windows domain to follow this guide, meaning you will need at least a domain controller.  This guide will be done in a Hyper-V environment, with two virtual servers – one domain controller running DHCP, DNS, and Active Directory, and one server (joined to this domain) running Windows Deployment Services and Windows Server Update Services (WSUS) that we will use to install MDT and the WAIK, and use as our “build” machine.  This part covers the first half of that equation, installing Active Directory domain services, DHCP, and DNS into a Hyper-V server running on Windows Server 2008 R2 and Hyper-V – note that you could also do this in VMWare, or VirtualBox, or VirtualPC, or any other such virtual environment.  I’m using Hyper-V because that’s what I use in my lab, it’s fast, and Windows 7 and 2008 R2 already include all of the drivers and files necessary to run properly in this environment without installing any additional extensions or additions.  To each his or her own, I use Hyper-V.

I am not going to go over installing Server 2008 R2 or Hyper-V on the server itself, as if you aren’t capable of downloading the trial ISO from Microsoft, or from MSDN, or your Volume Licensing site (etc) and installing Windows Server 2008 R2 from one of these, this guide is probably already going to be touching on concepts that may be a little more complicated than you are ready to tackle just quite yet.  Going forward, I am assuming you have a server (or workstation PC) that you have installed Windows Server 2008 R2 on, and have enabled the Hyper-V role from Server Manager – if you’re using another virtualization solution (or real hardware), modify / ignore / change the instructions below to match your environment as necessary.  I am also assuming you have downloaded the trial VHD for Windows Server 2008 R2 (full edition) from here, and have copied it to the hard disk of the Hyper-V server (you will be using this VHD later as the parent disk for your VMs).

Create a Virtual Network

First, you need to create the virtual network your VMs will use to talk to each other.  Open the Hyper-V Manager console from the Administrative Tools folder in your server’s start menu, and once it is open, click Action > Virtual Network Manager… to bring up the Virtual Network Manager.  Select “New virtual network”, select “Internal”, and click the “Add” button:

Next, give the network a name (I called mine “Internal” as per the screenshot), and click “OK” to create the new network:

Create a Virtual Machine for your Domain Controller

Now, you need to create a virtual machine for your domain controller.  Click Action > New > New Virtual Machine to bring up the New Virtual Machine wizard.  On the first page, give the new VM a name that will show up in the Hyper-V console (I chose “DC”), and click the “Next” button:

Next, give the virtual machine some RAM – I chose 2GB – then click the “Next” button:

Attach the VM to the network you created earlier from the drop-down list (you can see my “Internal” network chosen here), and then click the “Next” button:

Choose to “Attach a virtual hard disk later”, and click the “Finish” button (clicking “Next” will give you a summary, where you will then click “Finish”):

You should now see your newly-created virtual machine in the Hyper-V Manager:

With your VM highlighted, click Action > Settings to bring up the VM settings window.  Click “Processor” and change the number of logical processors to “2”, and then click “IDE Controller 0”.

Select “Hard Drive” in the right-hand pane, and click the “Add” button to bring up the New hard drive window:

Click the “New” button, select “Differencing”, and click the “Next” button:

Give the new VHD a file name (I called it “DC.vhd” here), and click the “Next” button:

Point the wizard at your “parent” VHD (either the 2008 R2 trial VHD you downloaded and extracted from the hyperlink I gave above, or another sysprep-ed 2008 R2 VHD you already had) and click the “Finish” button:

You should now have your domain controller virtual machine configured with a new hard disk and 2 processors, as seen below.  Click the “OK” button to finish and return to the Hyper-V Manager:

Configure the Virtual Machine to actually BE a Domain Controller

Double-click the new virtual machine you see in Hyper-V Manager to open it in the Virtual Machine Connection viewer, and click the green “Start button” (or Action > Start) to start the virtual machine.  If everything went well, it should boot up and complete the end of setup (installing devices, etc).  During this setup phase, you may be asked to enter a product key (don’t, just click the “Skip” button) and agree to a EULA license (do):

If something is wrong here, go back and retrace your steps to make sure you haven’t missed anything.  If you are using the downloaded VHD from Microsoft, this step may not be necessary.  This is normal if it boots directly into Windows.

Once the machine does finish setup and boots for the first time (if you have downloaded and are using the trial VHD from Microsoft, the administrator password is Pass@word1), you can login with the Administrator account and begin configuring it to service your domain:

In the Initial Configuration Tasks window that will open once you log in, click the “Provide computer name and domain” link, and then click the “Change” button.  Enter a computer name for your domain controller in the “Computer name” box (again, I used “DC”), and click the “OK” button:

Click “OK” again when prompted that you will need to reboot, and then click the “Close” button.  Click the “Restart now” button when prompted to restart the virtual machine.

Once the virtual machine reboots and you log in as Administrator, you will need to configure a static IP address, install the DHCP and DNS roles, and then install the Active Directory Domain Services role afterwards.

Once logged in, the Initial Configuration Tasks window should open again.  To configure a static IP address from here, click the “Configure networking” link, right-click the “Local Area Connection” network item, and select “Properties” from the list to open the Connection Properties window:

Click the “Internet Protocol version 4” item, and click the “Properties” button.  Select the “Use the following IP address” radio button, and enter an IP address for this machine.  Use a non-routable IP address range for this – I prefer something in the 172.16.0.0/16 range, but you can always use something in the 10.0.0.0/8 or 192.168.0.0/24 ranges as well – for the sake of this guide, I’m using 172.31.31.0/24:
IP Address:          172.31.31.10
Subnet Mask:       255.255.255.0
Default Gateway: (blank)

Once your IP address and subnet mask are entered, click the “OK” button, then click the “Close” button:

Back to the Initial Configuration Tasks window, click the “Add roles” link to bring up the Add Roles Wizard:

Click the “Next” button, then select the “DHCP Server” and “DNS Server” roles:

Click the “Next” button (three times), make sure your network connection is checked, and click the “Next” button again:

Enter a parent domain name for the DHCP server to use (I chose “demo.local”), and enter the static IP address into the “Preferred DNS Server” box that you gave to this virtual machine a few steps earlier, and click the “Next” button:

Make sure that “WINS is not required…” is selected, and click the “Next” button again – this will take you to the Add or Edit DHCP Scopes page.  Click the “Add” button, and then enter the Scope name, the IP range, the lease type, and subnet mask, click the “OK” button to save the changes, and then click the “Next” button:
Scope name:              demo.local
Starting IP Address:  172.31.31.100
Ending IP Address:    172.31.31.109
Subnet type:              Wireless (lease duration will be 8 hours)
Subnet mask:             255.255.255.0
Default Gateway:       (blank)

Select the “Disable DHCPv6 stateless mode…” radio button, and click the “Next” button.  Then, click the “Install” button to install the roles with the values and configuration you have entered:

If everything went well, you should see the installation report as successful – click the “Close” button to finish:

Now, you need to add the “Active Directory Domain Services” role.  From the Initial Configuration Tasks window, click the “Add roles” link to open the Add Roles Wizard.  Click the “Next” button, then select the “Active Directory Domain Services” role, and click the “Add Required Features” button when prompted:

Click the “Next” button (twice), then click the “Install” button to install the role:

Again, if everything went well, you should see the installation report as successful – click the “Close” button to finish:

Note that successful installation of the ADDS role does not actually make the server a domain controller – you must now run dcpromo to finish the setup of the server as a domain controller.  To do so, click start, type dcpromo, and press ENTER to start the dcpromo wizard:

Click the “Next” button (twice), then select the “Create a new domain in a new forest” radio button, and click the “Next” button:

Enter the fully-qualified domain name (FQDN) of the forest root domain (again, the same domain name you’ve been using, demo.local, if you’re following my guide), and click the “Next” button:

Select a Forest functional level of Windows Server 2008 R2 from the drop-down list, and click the “Next” button (twice):

When prompted “A delegation for this DNS server…” appears, click the “Yes” button, then click the “Next” button:

Enter a restore mode password, and click the “Next” button:

Click the “Next” button again to begin configuration of the server as a domain controller – click the “Reboot on completion” checkbox to reboot the server when the configuration is complete:

Once the server reboots and you log in with the Administrator account (this first reboot after configuration as a domain controller can potentially take some time, so be prepared to wait at the “Applying computer settings” message for a bit if this happens – this is normal), the last step necessary is to Authorize the DHCP server to start giving out DHCP addresses to clients on the network.  To do this, open the DHCP console from the Administrative Tools folder from the All Programs menu in the Start menu.  Once the DHCP console opens, right-click the server object in the left-hand pane, and select “Authorize” from the menu:

Wait approximately 5 – 10 seconds, and then press the F5 key to refresh the view.  You should now see that both the IPv4 and IPv6 nodes are now “green”:

At this point, you now have a domain controller in your lab that is capable of handling DNS and DHCP duties going forward.  The next step is to build a virtual machine for your MDT/WDS/WSUS needs, which I will go over in part 2 of this series.

I still have no idea why this happens or why it’s so reproducible, but I thought I’d share.  Oh, if you want to do debugging during setup, simply press F8 before the splash screen and select the debugging option from the Advanced Boot Options menu, similar to what you can do in a full Win7 install.

I found this while searching TechNet, here:
http://social.technet.microsoft.com/Forums/en-US/mdt/thread/5253b2e3-a60e-43a5-921d-a9acc6485d35

The change should have line 1101 looking like this when you’re done:
LPQuery = “PackageType = ‘LanguagePack’ and (ProductName = ‘Microsoft-Windows-Client-LanguagePack-Package’ or ProductName = ‘Microsoft-Windows-Client-Refresh-LanguagePack-Package’) and substring(ProductVersion,1,7) = ‘” & left(ImgBuild,7) & “‘ and substring(ProductVersion,5,4) >= ‘” & mid(ImgBuild,5,4) & “‘”