Wow – I’ve been absent!
Sorry about that. Once MDT 2012 and ConfigMgr 2012 are RTM, I’ll have more content. For now, hopefully what’s here will satiate you until then!
Sorry about that. Once MDT 2012 and ConfigMgr 2012 are RTM, I’ll have more content. For now, hopefully what’s here will satiate you until then!
Probably one of the best things to come out of Microsoft in the client space, MDOP has now hit R2 in 2011. This release gives us RTM code for the bitlocker administration console (MBAM), as well as bringing the diagnostic PE environment (DaRT) up to v7.0 (which includes being able to RDP into the PE image). Also included is AIS 2.0, which is supposed to make it easier to get the big picture of your software inventory in the UI:
Available for download from your VL site, MSDN/Technet, and supposedly to Intune Subscribers (not sure how that works yet, but I’m looking into Intune).
Microsoft has created a toolset called the Windows Performance Toolkit, or WPT, to help developers and users visualize and troubleshoot performance issues. One of the tools in this toolset is specifically designed to assist with capturing traces of boot, shutdown, or reboot cycles, and can provide insight into drivers, services, winlogon, explorer, disk and CPU utilization, and even help with seeing things like disk fragmentation and driver load order.
Before gathering any data, you will first need to download the installation packages necessary to install the Windows Performance Toolkit on your Windows 7 machine. The Windows Performance Toolkit is a part of the Windows 7 SDK, but you won’t need to install the entire SDK to get the WPT installation files if you follow this guide. First, you need to download the Windows 7 SDK, which is a 500K web installer (click the “Install Now” link). Once you start the installation, you only need to check the “Windows Performance Toolkit” checkbox under the “Redistributable Packages” section – uncheck EVERYTHING else:

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.
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.
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.
The blog has looked the same since August 2009, so I thought it was time to change the way the site looks and is laid out a bit. There’s a bit more color here and the right-hand panes for navigation have been moved around a bit, but that should be it for now.
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) & “‘”
I’ve been working on updating my lab hardware – finally got a nice box to run 2008 R2 and Hyper-v, so I’m installing SP1 and my VMs so I can try to crank the next post out. I haven’t forgotten, but sickness and the job keep me busy. The next “real” post is indeed coming soon, hopefully in the next few days.
Bad Behavior has blocked 64 access attempts in the last 7 days.