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

After some fiddling, I figured out that Disk2VHD added the /HAL=halacpi.dll string to boot.ini for the default boot option, whereas the Integration Components setup was trying to upgrade the HAL to an APIC hal (halaacpi.dll).  I changed the boot option in boot.ini to remove the /KERNEL=ntkrpuni.exe string, changed the /HAL=halacpi.dll string to /HAL=halaacpi.dll, and copied halaacpi.dll from sp3.cab on my XP SP3 media to %windir%\system32.  Once I rebooted, the IC’s installed successfully.  I then went back and removed the /HAL switch from boot.ini entirely and rebooted, and all is well.

Took me 2 hours to figure out, so I figured I’d post this as usual to hopefully save someone else the time I wasted.

I don’t know if a 2008 R2 CA is technically supported for use with 2007 SCCM certificates, but for those of you who are doing this, be aware that how you set up your CA on it’s initial install will determine if your client certificates work properly or not.  There are workarounds, of course, for those few of you who are already running 2008 R2 CAs from a default installation - in the Site Mode tab of the Site properties, you can change the “If multiple certificates match criteria:” from “Fail selection and send error message” to “Select any certificate that matches”, and set “Certificate criteria:” to “Check only certificate purpose”.  Doing this allows the MP communications to start up again, although I’m not sure of the potential risks (if any) that are taken if you allow this.

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.

Adding the DaRT files

First, you will need to copy the files from the MS DaRT WinPE ISO image to your “Content” folder that was created when you used MDT 2010 as per my previous post.  The content folder should look something like this:

And the contents of the MS DaRT ISO image, once extracted to the hard disk, will look something like this:

You will need to go through this folder structure (boot, EFI, and sources) and copy to your “Content” folder anything from the MS DaRT contents that does not already exist as a file or folder in your “Content” folder.  For example, the MS DaRT media is on the left, and the “Content” media is on the right:
 

And the “Content” folder looks like this afterwards:

The same with the EFI and sources folders from the MS DaRT media:

And the “Content” folder looks like this afterwards:
 

Since most WinPE distributions use a “boot.wim” file in the “sources” folder, and we’re going to have multiples, you’ll want to rename any boot.wim files you copy here to something else, preferably something descriptive.  For example, I’ve renamed the boot.wim file from the x64 MS DaRT media I just copied over to “msdart64.wim” – this will be important later, when we create our boot entries:

I’ve repeated the above process for the x86 MS DaRT media as well, and renamed the boot.wim from that media to “msdart86.wim”:

Once you’re done with all of this, the last bit needed is to use bcdedit to add the new .wim files to your boot menu, and copy the updated “Content” folder to your USB key.

Using bcdedit to modify the boot menu

You’ll need to open a command prompt into the \boot folder of your “Content” media folder, and execute some bcdedit commands to modify the boot menu.  To make sure you’re in the right folder, the dir listing output should look something like this:

What you will need to do is use bcdedit to edit the “bcd” file you see here – that file actually contains the boot configuration data used during boot, and we’re going to modify it to add the new .wim files we just copied over.

First, let’s look at the current boot configuration stored in this file.  Run the command “bcdedit /store bcd /enum” to show the current boot manager configuration stored in the bcd file.  You’ll note that we already have 2 entries here – one labeled “Litetouch Boot [MEDIA001] (x86)” and another labeled “Litetouch Boot [MEDIA001] (x64)” – also make a quick note of the default GUID in the {default} entry at the end of the device and osdevice lines, because you’re going to need this later:

To create a new entry, you just need to create a copy of the {default} boot entry, and give it a name.  Use the command “bcdedit /store bcd /copy {default} /d “<name>” to create a new entry called “<name>”.  I’ve created a new entry called “Diagnostics and Recovery x64” by using the command “bcdedit /store bcd /copy {default} /d “Diagnostics and Recovery x64” – please note very carefully the GUID that the entry was copied to – you will need this to further modify the entry in the next steps:

The next thing you need to do is add the DEVICE that this boot entry is going to use – this is the .wim file that the entry is going to point to, and you do this via the “bcdedit /store bcd /set <GUID for the new entry> DEVICE ramdisk=[boot]\<path to .wim file>,<GUID of default entry>”.  I’ve edited the new entry to point to the msdart64.wim file via the command “bcdedit /store bcd /set {c77ebc03-8748-11de-8cb4-00137228d4cf} DEVICE ramdisk=[boot]\sources\msdart64.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}” (remember I told you you’d need the GUID for the new entry, as well as the GUID from the default entry? – here is where you use them):”

You will next need to add the OSDEVICE that this boot entry is going to use.  This command is basically identical to the previous, except that “DEVICE” in the previous command is replaced with “OSDEVICE” – “bcdedit /store bcd /set <GUID for the new entry> OSDEVICE ramdisk=[boot]\<path to .wim file>,<GUID of default entry>”.  I’ve edited the new entry to point to the msdart64.wim file via the command “bcdedit /store bcd /set {c77ebc03-8748-11de-8cb4-00137228d4cf} DEVICE ramdisk=[boot]\sources\msdart64.wim,{7619dcc8-fafe-11d9-b411-000476eba25f}”:

If everything was successful, you should be able to run “bcdedit /store bcd /enum” and see your new entry at the end of the list:

If you want to add another (for example, I’m adding the x86 version of MS DaRT as well), just do the same steps over again for the new .wim file:

Once you’re done, you can replace what’s on your USB key with the new contents of the “Content” media folder.  If you want to create an ISO image (for burning to DVD, or testing in a VM), you can open the Deployment Tools command prompt from the Windows AIK start menu folder, and run oscdimg on the “Content” folder.  The command is “oscdimg –b”<path to etfsboot.com>” –h –u2 –m -l<Volume Name> “<path containing content to be copied to ISO>” “<path and name of resulting ISO image>” (note that –l in the command is a lower-case “L”, not an “I”).  I’ve created my image via the command “oscdimg –b”C:\Program Files\Windows AIK\Tools\PETools\amd64\boot\etfsboot.com” –h –u2 –m –lINSTALLER D:\Hybrid_Media\Content D:\Hybrid_Media\installer.iso”:

Seeing it in action

If you boot your new USB key (or ISO image), you should now see the new boot entries:

That’s it – and you could theoretically do this with any Windows PE-based .wim file.  I used MS DaRT for this example, but you could use something like BartPE or any other Windows PE image.

Here’s the list:

Windows Vista:

• Ultimate  -  VMCB9-FDRV6-6CDQM-RV23K-RP8F7
• Business  -  4D2XH-PRBMM-8Q22B-K8BM3-MRW4W
• Home Premium  -  X9HTF-MKJQQ-XK376-TJ7T4-76PKF
• Home Basic  -  RCG7P-TX42D-HM8FM-TCFCW-3V4VD
• Starter  -  X9PYV-YBQRV-9BXWV-TQDMK-QDWK4

Windows 7:

• Ultimate  -  D4F6K-QK3RD-TMVMJ-BBMRX-3MBMV
• Professional  -  HYF8J-CVRMY-CM74G-RPHKF-PW487
• Home Premium  -  RHPQ2-RMFJH-74XYM-BH4JX-XM76F
• Home Basic  -  YGFVB-QTFXQ-3H233-PTWTJ-YRYRV
• Starter  -  7Q28W-FT9PC-CMMYT-WHMY2-89M6G

Note that these were easy to acquire, as they are stored in a file called product.ini in the \sources folder for Vista, Server 2008, Win7, and Server 2008 R2.  To verify, I installed Windows Vista and Windows 7 without a product key, and then ran a utility in the OS to display the current product key – I used GetKey written by GunSmokingMan on the MSFN forums, but anything that’ll run in Vista or Windows 7 will work.