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 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) & “‘”

http://www.microsoft.com/downloads/details.aspx?FamilyID=3bd8561f-77ac-4400-a0c1-fe871c461a89

Adding the application(s)

To create an application bundle that will show up in the list of applications to install (or be available to configure via a task sequence), you first need to add all of the applications to MDT that will make up the bundle.  This is done similar to adding Office 2007 as I documented in my post on creating an MDT deployment point – you must create a New Application and add it’s source files to the deployment share.  I’ll document quickly how to add the Windows Live Essentials components to your deployment share and “bundle” them (instructions on getting the .msi packages you’ll need from the Windows Live Essentials downloadable package can be found here, if you do actually want to try this).

First, right-click on the Applications folder in the deployment share (in this example I’ve created a folder underneath applications to hold all of the Windows Live installation apps – this is purely for cosmetic reasons) and select “New Application” from the drop-down list:

Select “Application with source files” from the first wizard page, click “Next”, and then fill out the information about the application and click “Next” again – in this example, I’m adding the x86 package for the Application Error Reporting component of Windows Live:

Point the wizard to the local path that contains the setup package, and click “Next”:

You will need to provide the actual installation command used to run the setup – in this case, the command is “msiexec /i dw20shared.msi /qn”, so I’ve entered that into the “Command line” field:

Once that’s done, click “Next” a few times and the application will be added to your Applications in your deployment share.  Next, right-click the new Application and select “Properties” from the drop-down list:

Make sure to *check* the box labeled “Hide this application in the Deployment Wizard” – this will keep the individual installers from showing up in the list of applications to be installed during deployment, ensuring only the bundle will be used to install the apps, in the correct order – click “OK” to save the changes:

Creating the bundle

Once you’ve added all the other components necessary (repeating the above steps for each application that will make up your bundle), the bundle itself needs to be created.  To do this, right-click on the Applications folder (or any subfolder, as in my example) in the deployment share, and select “New Application”:

This time, select the “Application bundle” option from the list of application types, and click “Next”:

Fill out the details of the application as you would any other application, and click “Next” a few times until the new bundle is added to your Applications list:

Next, right-click on the new Application bundle in the Applications list, and select “Properties” from the drop-down list:

Go to the “Dependencies” tab, and click the “Add” button:

In the “Select an item” window that pops up, select the application installers from the list, one at a time (clicking “OK” after selecting each to add to the list), until you’ve got all of the applications that will make up this “bundle” in your list, in the order you want or need.  Note that you can use the “Up” and “Down” buttons to move applications up and down the list in this window if you didn’t add them from the Applications list in the order required:

Lastly, right-click your deployment share and choose “Update Deployment Share” to update it, and also right click on your Media and select “Update Media Content” (again, as per previous posts on this subject).  Once these complete, you can copy the updated media to your USB key, or burn the .ISO.  The new “bundle” will show up in the applications list during deployment, and will install each application, in the order it is listed in the “Dependencies” tab during deployment if it’s selected to be installed.

If you’ve got lots of applications that you deploy to each and every build you do, this is a great way to cut down on the clicking in the deployment wizard – or makes for fewer entries in your task sequences for applications.

Have you ever wanted to put every version of Vista, Server 2008, Windows 7, Server 2008 R2, and perhaps a version of XP or two on a single USB key?  No?  Then you’re probably normal.  If you’re like me, however, the thought has crossed your mind.  However, the daunting task of configuring said USB key to boot to some multiboot Linux distro or hacking a bit at bcdedit to boot a WinPE to handle it also made it something to avoid, at least for me, because, well, I tend to be lazy about these things.

However, after playing with the Microsoft Deployment Toolkit for a bit, I realized I could probably make my USB key bend to my will and be said multi-bootable Windows OS installer, without a whole lot of work.  I set about to put all of those versions of Windows one one key, along with some unattended applications (for this blog post, I’m just adding Office 2007 to keep it short).

You’re going to need a few things to start, most notably you’ll need a Windows machine that can install the latest Windows Automated Installation Kit (WAIK) for Windows 7 (that’d be Server 2003 SP1 or newer, Vista SP1 / Server 2008 or newer, or Win7 / Server 2008 R2 – sorry, no XP support, it seems).  You’ll also need the MDT 2010 bits and the version(s) of Windows and any applications you would like to install from MDT.

Adding Operating Systems

Once you’ve got a machine with the WAIK and MDT 2010 installed, the first thing to do is open the Deployment Workbench from the Microsoft Deployment Toolkit folder in your start menu.  Since you’ve already got the prerequisites needed to do a basic MDT deployment (namely, the WAIK), just right-click on the “Deployment Shares” folder and select “New Deployment Share” from the drop-down:

This will open a wizard that will help you create the Deployment folder and share – note that you will have to create this folder, as the current version (beta2) does not do this.  The wizard will look like the following:

Again, use the “Browse” button to create the folder as necessary, and make sure this is on a drive with ample space, as all of your OS files and applications will be stored here.

Once you’ve gotten yourself a deployment share, it will show up as a subfolder of the “Deployment Shares” tree, and the first thing you’ll want to do is add the version(s) of Windows you want to use MDT to install.  To do this, right-click on the “Operating Systems” subfolder in your deployment share, and select “Import Operating System”:

This will bring up the “Import Operating System” wizard.  For this example, I’m going to be using the full Windows installations as my source, and since I’ve copied the contents of the Windows DVDs / CDs to the hard disk on this machine already, I select “Full set of source files” and point the wizard to the folder that contains the Windows source that I’m using (in this example, I’ve extracted the Windows 7 RTM to a folder on the D: drive):

The wizard will go through copying the files from the source directory into the distribution share, and add each OS choice to the Operating Systems list in the Deployment Workbench – after adding Vista, Server 2008, Win7, and Server 2008 R2 via this method, my Operating Systems list looks like this:

Adding Applications (optional)

If you want to have your installation media install applications along with Windows, you’ll need to add them to the deployment share and the task sequence – in this example, I’m adding Office 2007.  To add an application, you’ll need to right-click the “Applications” subfolder in your deployment share, and select “New Application” from the drop-down:

Once the wizard comes up, you’ll have to enter the Application Name – the Publisher, Version, and Language are optional (but recommended):

Again, I’ve copied the contents of the Office 2007 DVD to the hard disk, so I’m going to point the wizard to this source, but if you have the files you need for the application you’re adding to the deployment share in another location (say, on a DVD or a network share), point the wizard to that source directory, and click “Next”:

This will place the Office 2007 entry into the “Applications” list in the deployment share, and you will need to edit the properties of the application before the application will install properly.  To do so, right-click the application from the Applications list and select “Properties”:

From here, you will need to click the “Details” tab and configure the installation command (the Working directory will already be configured) to run the application’s setup, including any switches required by the application.  You can also enable or disable the application from the deployment share, cause the application to reboot the computer it’s being installed onto once it has completed installation, as well as a host of other options that may be of interest to you.  You may also note that MDT recognizes that this is an Office application, and adds an “Office Products” tab where you can configure the unattended parameters of Office (if your version supports it – for example, Office 2007 Enterprise):

Once you’re comfortable with the application settings, click “OK” to complete adding the application.

Adding Drivers (optional)

If you want to inject drivers into your installation, you will need to use the “Out-of-Box Drivers” subfolder in your distribution share.  Note that there is a requirement here – you will need to have the driver package extracted that you want to use, and it must not be a driver package that requires an .exe to install.  For this portion of the deployment, you will have to direct the MDT wizard to the folder that contains the .inf, .sys, and any .cat files the driver requires, hence why .exe driver installers will not work.  You may be able to add these types of drivers as application packages, however, but that’s a bit outside my scope here.

For this example, I’m adding the drivers for a 3ware 9550SX controller that I’ve already extracted:

To add the driver to the deployment share, simply right-click on the “Out-of-Box Drivers” folder and select “Import Drivers” from the drop-down:

Point the wizard to the folder that contains the drivers you want to import, and click “Next” (in my example, I’m going to import both x64 and x86 drivers, so I’m running the wizard twice) – note that if you do import the x86 and x64 versions of the same driver, make certain that the “Import drivers even if they are duplicates of an existing driver” box is checked before clicking “Next”:

If you have imported both x64 and x86 versions of the same driver, make sure to right-click on each driver in the listing of Out-of-Box drivers and select the proper architecture – the wizard will add a number at the end of the driver’s name for each iteration of the same driver you import (in this case, (1) was added to the x86 driver I imported), and the wizard will tell you at the end what display name it gave to the driver added.  In this case, I’ll make sure that the “AMCC System 3wManage.inf” is configured to be used only for x64 platforms:

Make certain to do this for each x64 and x86 driver you add, if you do add multiple architecture versions of the same driver.

Creating the Task Sequence

To get MDT to actually *do* something with the operating system(s) you’ve imported, you’ll have to create what is called a “Task Sequence”.  In MDT parlance, this is the “logic” that drives MDT – it’ll tell MDT what drives to format, what version of Windows to install, and any applications, hot fixes/updates, and drivers you configure in MDT.  To create your first task sequence, right-click on the “Task Sequences” subfolder in your deployment share, and select “New Task Sequence” from the dropdown:

Once the wizard comes up, you’ll need to give the Task Sequence a unique ID number in the “Task sequence ID” box, as well as a name (this is the name that will show up in the list of operating systems to deploy, so consider using the name of the version of Windows the task sequence will install).  Enter any comments in the comment box, and click “Next”:

Choose the “Standard Client Task Sequence” from the drop-down list (or “Standard Server Task Sequence”, if this is a server OS), and click “Next”:

Select the version of Windows you want the Task Sequence to install from the list, and click “Next”:

At this point in the wizard, you can enter a product key (or not), set the registered Name and Organization, set the IE homepage, and configure the Administrator Password (or not).  Once you’ve done all this and finished the wizard, the task sequence will now show up in the Task Sequence list, but it’s not complete just yet if you want to edit the unattended file and change some of the advanced options (like the default time zone, in my example).  If you want to leave everything as-is, skip to the next section.  However, if you do want to edit the file, you’ll need to right-click the Task Sequence and select “Properties” from the drop-down:

Once the properties of the Task Sequence opens up, click on the “OS Info” tab, and click the “Edit Unattend.xml” button to open the unattended file in the Windows System Image Manager (WSIM) for editing:

Again, for this example, I want to edit the Time Zone.  To do this, once WSIM has the unattend.xml file open, expand the 4 specialize component and select “Microsoft-Windows-Shell-Setup_neutral” from the list (note that this says amd64 at the beginning because this is an x64 image – if you’re editing an x86 image, it will say x86 at the beginning).  From here, you can edit the default (Pacific Standard Time) with the full name of the Time Zone you want (I’ve entered “Eastern Standard Time”):

Once you’re done editing the unattend file, close the WSIM window and save the file when prompted.

Putting it all together

The last steps involve updating the deployment share with the changes made, and building the media we’re going to use to copy to the USB key.  First, you will need to update the deployment share, by right-clicking on the deployment share root folder, and selecting “Update Deployment Share” from the drop-down:

This will cause the deployment share to update, and you will see progress indicated in a wizard window that will look like the image below, and when it’s done, click the “Finish” button:

Next, you’ll need to actually create the media.  To do this, expand the “Advanced Configuration” folder in the deployment share, and right-click the “Media” folder and select “New Media” from the drop-down:

Once the wizard opens, you’ll need to point the Media path to a folder that will contain the exported media – note that you will have to create this folder as well, as the current version (beta2) does not do this.  Also note that it appears (from some comments and my own testing) that the media share path cannot contain spaces (again, this is beta2, so we’ll wait to see if this problem continues in the RCs), or the creation wizard will fail.  I’m currently investigating this to see why this is, although it does seem fairly repeatable.  Use underscores or dashes if you want to name it something that would otherwise contain a space.  The New Media Wizard will look like the following:

Again, use the “Browse” button to create the folder as necessary, and make sure this is also on a drive with ample space, as all of your OS files and applications will be stored here, as well as an .ISO file that can be burned to a DVD (if it’s small enough).  Once you’ve selected a folder, click “Next” to create the share.

Once the creation of the media share is complete, you’ll see it in the list of Media available to be created.  Right-click on the new media and select “Properties”:

Click the “Rules” tab, and add one field at the end, called “_SMSTSORGNAME” and set it equal to what you want the Unattended progress bar to call your deployment (you’ll see later what I mean by this) – I’ve named mine “cluberti’s imaging stick” for this example:

Next, click the “Edit Bootstrap.ini button, and add the same field with the same name.  Once you’re done, save the file, and then click OK:

Lastly, right-click the new media entry and select “Update Media Content” from the drop-down.  This will actually create the content folder and the .ISO in the media share, and it WILL take a long time the first time you do this, so be patient:

Once the wizard completes successfully and you click “Finish”, your media is now ready to be copied to your USB key – just put your USB key into the machine, and use Windows Explorer to copy the contents of the “Content” folder in the media share to your USB key:

Seeing it in action

I’m going to show you what this looks like from my deployment media in a Hyper-V VM, so you can see what the end-product will look like.  Note that basically ALL of this can be automated via entries into the “Rules” tab and Bootstrap.ini of the media share (or even the Deployment Share folder – the same settings can be seen in the properties of this folder) and entries into the Task Sequence (which I’m leaving for another post.

Without further ado, see the task sequence in action: