cluberti.com

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

Create and Configure Your Distribution Point

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

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

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

In part 2 of this series, you will be creating a second virtual machine which will be used to install and configure MDT for deploying Windows and applications.  I’ll dive right into creating a virtual machine for your MDT server, which will be very much the same as creating the virtual machine for your domain controller in part 1.

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:

After writing a piece about MDT and installation from a USB key, I’ve gotten a steady stream of requests for a more in-depth piece on the actual installation of MDT, how I recommend it be configured, and some tips and tricks about managing it for a smaller organization, or a small (non-royalty) OEM, or even how it can be used in an environment for building machines for friends or relatives in machines someone might be stuck supporting.  With that in mind, I’ve gone ahead and rebuild my lab (as promised earlier this year), and taken some screenshots to go along with this post.  I will cover the installation of the WAIK, MDT 2010 Update 1, and DHCP and Windows Deployment Services (for those with a domain, as WDS requires a domain to work properly).  I think it’s worth noting that nothing I post here is specifically exclusive to this site, and most of what I’m putting together here has probably been posted on and/or discussed at length all over the internet.  I’m just putting together a beginning to end document for those who are looking for a one-stop shop to at least get started, and are willing to try some of the more advanced stuff on their own.

I’ve been troubleshooting an issue with Windows 7 setup on a specific hardware model in MDT with a hodge-podge of a particular vendor’s drivers in the driver store, and I ran into a little issue with Windows 7 setup debugging that I thought I’d share – it doesn’t seem to work right on the first try.  It will connect, then almost immediately disconnect the remote debugger.  If you simply leave the debugger running and attached (in my case, to COM1) and restart the debuggee, it reconnects properly the second time.

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.

Seems like Microsoft changed the name of the Language Packs from “Microsoft-Windows-Client-LanguagePack-Package” to “Microsoft-Windows-Client-Refresh-LanguagePack-Package”.  A small distinction, but huge when MDT or SCCM can’t find the language pack name!  In MDT, go to the DeploymentShare’s \Scripts folder, edit “Deploywiz_Initialization.vbs”, and go down to line 1101 – you’ll see that LPQuery is set to look for only the old Language Pack package name.  Add the new package name, and things will work again (you will have to update any media you’ve created, of course).

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 taking a Disk2VHD image of an XP SP3 machine, I noticed that I could not install the Integration Components after copying the VHD to my Hyper-V machine and running the Integration Components setup off vmguest.iso.  It would attempt to upgrade the HAL, tell me I needed to reboot to upgrade the HAL, and then reboot and get to the same place.  If I clicked “OK” again to upgrade the HAL, it would reboot – if I hit “cancel”, the installation would fail.

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.

Microsoft supports running SCCM 2007 SP2 on a 2008 R2 server, but I’m doubting whether or not running SCCM 2007 SP2 in Native mode in an environment using a 2008 R2 CA is supported (and if so, there’s an issue to be aware of).  Specifically, it seems like client certificates created with a 2008 R2 CA (following the instructions on Technet for a 2008 CA) do not work by default in SCCM 2007 when running a site in Native mode (you’ll get MP errors stating that it cannot connect via HTTP, and mpcontrol.log will contain errors that the SAN2 fields have errors).  It seems if you create your 2008 R2 CA with the default Key store provider, the client certificates just do not work.  However, if you create your 2008 R2 CA with the Microsoft Strong cryptography provider (which is the default for 2003 and 2008 CAs), magically the certs created work fine.  If you look at the contents of the certs created between a 2008 and 2008 R2 CA, they “look” identical, but something else must be happening I haven’t dug into yet.

One of the more interesting things in MDT is the “Application bundle” application install option.  What an application bundle allows is the ability to install multiple applications, in order, as dependencies.  Think of it more as a logical container for applications that need to be installed, perhaps in a specific order, or as prerequisites for another application (like, for instance, installing Visual Studio 2008 prerequisites, Visual Studio itself, and then the latest service pack).

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

Having a USB key that will install multiple versions of Windows is great, but what if you want to add other Windows PE images to it, above and beyond the installers?  For example, what if you wanted to add a recovery environment, like the Microsoft Diagnostics and Recovery Toolset (DaRT), or a BartPE environment, or any other Windows PE-based environments?  Well, it’s not that hard to do, and I’ll document how to do it with the Microsoft DaRT x86 and x64 recovery ISOs that it creates in this example.

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:

To go along with my previous post on deploying Windows via MDT 2010, here is a list of the “default” keys that Windows uses when you choose not to enter a product key during setup.  These keys of course will not activate, but you can enter them into your task sequences when you are prompted for a product key to use.  This will make your setup more unattended.

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