MDT & Intel Arrrrrgggghhhh!

Last year I spent a great deal of time learning how to use MDT. And it seemed like a good system. It worked well and there were only a few hiccups with it.

Suddenly this year it is proving to be a great deal of trouble and I’m wondering why I bothered with it.

Firstly, I made an effort to get a capture done from a VM image. There were no problems getting that capture done before. But now, for no apparent reason, MDT starts refusing the capture, and when it’s MDT, the reasons won’t be that obvious; the error messages you get will be meaningless like “CloneTag” or something, and you won’t be able to work out just what is going on without a lot more work.

The second instance is this year when I have started to work on laptops, and for good measure I loaded the carefully crafted and fully tested laptop image onto three new laptops. These types of laptops never gave us any trouble before loading this MDT image. But now, all three of them have inexplicably crashed during the MDT deployment process, leaving me with a pile of work to get them completed because half the task sequence hasn’t been completed.

At the moment I am not in a place where I have got time to poke around trying to find out why MDT has failed. I expected this deployment to go smoothly. It hasn’t. It is very time sensitive and it will have to be completed manually with a lot of extra work involved.

With all the amount of trouble that it can be with MDT at times like this I am really seriously considering just going over to native VHD deployment for all of our Windows 7 computers. Then we will only need MDT to simplify some of the management and I won’t be doing captures or deployments with it.

The second MDT (and AIK for that matter) annoyance is the design limitations that means a 64 bit installation (which is made on a 64 bit platform i.e. Windows 7 or Windows Server 64 bit edition) can only service installations that are for 64 bit target platforms. To be able to service both 64 bit and 32 bit installations, the 32 bit version of MDT (which can only be installed on a 32 bit edition of Windows) has to be installed. So this means that the computer that MDT and AIK is installed on has to be running a 32 bit edition of Windows. And since 2008R2 came out it is 64 bit only. Now the importance of this is that I wanted to have my Setup share a local drive letter on the MDT/AIK VM. This means it can only be running a Desktop edition of Windows and thus there is the infamous 10 connection limit. So in reality this would limit access to that share to 10 connections. Sometimes when you see these limitations you wonder if MS really has a clue what people use these packages for or they just must think people are made of money so they can fork out for another license for a machine that runs that specific edition of Windows (and another hardware box if that is what is needed). For me I have a Enterprise server license that will let me run this VM as part of the license but it still ends up with that 10 connection license to run a desktop edition of Windows.

The other annoyance is the server rail kit for Intel 5295 chassis. We ordered a rack that is 700 mm deep, thinking this would be plenty, after all the chassis is about 500 mm deep. But this very poorly designed Intel product will not fit in a chassis that is less than that size, even though it allows a huge gap at the back of the server, the rails require minimum of 700 mm depth in the chassis to fit in, and even at that you should really be looking at 800 mm chassis depth because the front door of your cabinet will not close. But of course in the minimum size 12RU chassis that we purchased, it is not available in more than 700 mm depth. Not until you go to 22RU and that is much too big and expensive.

So while the rack manufacturer’s product is good, Intel has really let us down with this silly very poor design. I went all over Intel’s website and looking at other websites to see what information is there about this design limitation (the product is called APP3RACKIT) and there is NO information. Absolutely NONE at all. If we can’t get the kit returned we are going to end up having to try to resell it, and we’ll end up losing money on it.

Deploying Native Boot VHDs [5]

The steps for deploying a native VHD boot are the same as if you are using a third party imaging solution, such as Ghost. Effectively, copying a VHD is a kind of third party imaging solution, in that it is not a directly supported deployment scenario for the Microsoft Deployment Toolkit, its predecessor Business Desktop Deployment, Windows Deployment Services, or System Center Config Manager. Ideally at least MDT would have task sequences added to automate the required steps, namely Sysprep and DISM.

Hence having used a third party imaging  scheme before, it took me little effort to get going with Native VHD deployment as we originally developed a Vista image using Ghost along with WSIM and Sysprep. The stage I didn’t get around to at that time was DISM, or possibly it was different under Vista. This time I have to use it because the network card driver for our particular target platform is one of those which is not included with Windows 7, and thus, out of the box, Windows 7 will not be able to search for drivers for the other hardware.

When we developed our first Vista image I had a buck both ways and also ImageX’d the PC so that I had this image available in case Ghost didn’t work out. As it happens, Native VHD deployment is like ImageX except that the stage of physically imaging the hard disk and reloading that image to target PCs is replaced by copying the VHD file to target PCs. ImageX has the advantage over Ghost of being file-based rather than disk-based, and various other things it can do like having multiple images stored efficiently in one WIM file due to single instanced storage. Native VHD on the other hand is like a partition, due to the fact that a VHD file is a virtual hard disk. When you deploy it, multiple VHDs can represent multiple partitions on the target system. Its strength lies in the fact that you don’t have to physically define and maintain partitions on the target computer’s hard disk, especially if you have more than one. Re imaging the target is as easy as booting up to a Windows PE command prompt and copying the new VHD file over the old.

Once you have sysprepped your VM with your deployment VHD attached to it (as this is an online step), the final step before deployment to target platforms is to perform offline servicing. This is what DISM does. Its name stands for Deployment Image Servicing and Management, and like other tools that you use in a Windows PE command prompt, such as Diskpart, it has been extended for Windows 7 to work with native boot VHD files as well as WIMs. Supposedly you can pass Dism an unattend.xml file that you set up with WSIM that has a driver path specified in the [2 offlineServicing] section. I wasn’t able to make this work, so I just copied the drivers to the local HDD and used the Add-Driver option instead. The use of DISM is pretty straightforward, although since it cannot work over network paths, you may need to copy your image file somewhere locally first (I recommend you also copy your unattend.xml file to the same directory):

• Start the Deployment Tools Command Prompt by right clicking it and choosing “Run as administrator”.
• Browse to the directory which contains the image you are performing offline servicing on.
• You will need to use Diskpart first in order to map the  VHD to a drive letter.
  • Start Diskpart
  • At the Diskpart prompt, enter select vdisk file=<path_to_vhd>
  • Enter attach vdisk
  • Enter list vol to see if diskpart has assigned a drive letter to the file. If not, use the assign command to assign a drive letter. In this case drive letter F has been assigned. Typically you will find two extra drive letters automatically assigned: one for the boot drive partition, and one for the system partition.
  • Enter exit to quit Diskpart
• Type in a command which starts with dism /image:<drive_path> followed by a servicing command.
  • For example: dism /image:F:\ /get-drivers will list the drivers already present.
  • To add drivers off a local path such as C:\dism, enter a command like dism /image:F:\ /Add-Driver /Driver:C:\dism\Intel /recurse (Intel is where I have copied the driver files to).
  • After doing this you can use something like dism /image:F:\ /get-drivers to see what was installed.
  • The first time I tried this 198 driver packages were added to the image. YMMV – You may wish to trim down your driver folders (These were only four devices in total). This number of drivers added 1.2 gigabytes (!) to the image size.
• After using DISM, detach your VHD using more Diskpart commands before you copy it to the target platform.
  • Start Diskpart
  • Enter select vdisk file=<path_to_vhd> (or press the up and down arrows to recall the command that you entered when you used Diskpart earlier in the session)
  • Enter detach vdisk
  • Enter exit to quit Diskpart
• Deploy and test. (I copied the VHD straight over the network from C:\Dism on my MDT VM)

Eventually AIK is going to get installed on my tech server VM where all the setup files are local so that I don’t have to copy the files around each time I’m using DISM.

We have more or less finalised the process of imaging for our computers now. There is just a bit more tweaking and customising the image to get it all working properly before we deploy soon.

Deploying Native Boot VHDs [4]

The first time startup with the sysprepped VHD went reasonably well until an error message was displayed:

After that the system was stuck in an endless loop of displaying messages which basically said “Windows could not complete the installation. To install Windows on this computer, restart the installation”. Then the system would restart and, you guessed it, the same message was displayed again.

Now our first thought might be that that isn’t where we originally put our unattend.xml file and that is probably true, however it does get copied here. So we need to get the log files that are created by the installation which will tell us what problems have caused this error. To do this I need to boot my target system into Windows PE again and examine the VHD that way. We can do this by using Diskpart to attach the VHD and assign a drive letter to it. Then I can browse it directly to find the log files, which in this case are in c:\windows\panther\unattendgc. It is recommended to detach the VHD before quitting, using Diskpart commands again. After I checked the log files I found a couple of issues which have resulted in corrections being made to the listed settings in Part 3 of this article series. Part 3 has been updated with these corrections. I fixed up the answer file using WSIM again.

I’ve also decided I will set up a custom folder for DISM for OOB drivers for this image because it’s pretty easy to do and will simplify the process of injection by limiting the number of drivers that are injected to those which are needed for this image. So that stage will require the drivers being copied to a custom folder in the AIK share and then the path in the answer file will be changed. With the changes to the answer file that also needs to be recopied to the VM before reprepping it.

There is one software package I have not been able to install onto the VM because it is the software for the DVD writer and it won’t install if the drive is not present. This means that final customisation of the VHD will require it being deployed to the target platform so this will be done before it gets sysprepped. This of course means a target platform has to be available at some stage of the image development process. I will have to see how I can make this work out in practice. It was something I had hoped to avoid because obviously the primary benefit of using a VM to build up images is that you don’t need access to a target platform until deployment. However in practice this should be OK, just a little inconvenient. After this convoluted process of getting the VHD onto the target and then back again, the software installation was completed. The reprep was then started. This went more or less as expected. I am currently testing and finalising settings and preparing to DISM the image.