MDT 2010 hangs on uefi equipped machines

Question

Hi all,
I'm new to MDT (Started playing with the betas earlier this year), but I've been using WDS for nearly a year or so.  I have an MDT 2010 server running on a Windows 2003 box with all of the latest service packs, fix packs, etc. The MDT server has been configured to deploy our install images to our test lab (We run everything from 2003 R2 up to 2008 R2). So far the MDT server (I upgraded the betas to the RTM code) has been running great on almost all of our machines, with the exception of our uEFI based machines.
We are primarily an IBM lab (We have a smattering of Dell and HP boxes, but none yet that have a uEFI Bios). We have mostly xSeries and BladeCenter products.
Our scenario:
We're running MDT 2010 in an LTI setup. No database, we just want the end user to be able to PXE boot the box, boot the Lite Touch 32 or 64 bit wim and then get the MDT screen that allows them to pick what operating system they want installed. Let the install start in the WinPE mode and then the WinPE mode reboots and continues on its installation path (DOS boot mode for the 2003 R2 installs , 2008 GUI setup, etc)
That part works fine for all of our regular xSeries (ie non uEFI) blades and servers. The user picks their OS, the preinstall phase starts, finishes and reboots out of the WinPE shell and then continues on with its next phase of the install.
Our uEFI enabled boxes (Mostly IBM HS22, x3200 M3, x3250 M3) boot into the MDT selection screen just fine. We can choose our os and the install starts in the PE phase (Sorry if I'm messing up the phase names still learning MDT as I go). Once the WinPE phase finshes, instead of rebooting (like the non uEFI boxes do) these boxes automatically open a Command Prompt window and then sit there until you close the window or type exit. I have not opened the command prompt (I know you can hit F8, but this is being done by MDT on its own). Once you manually close this window, the install continues just like it should.
I've updated alll firmware levels on these boxes to see if it might be something going on there, but no luck. MDT 2010 continues to hang (opens the command prompt) after completing the WinPE portion of the installation.
Has anybody else out there seen this behaviour? Anyone have any ideas how to correct it?
Thanks,
Jim Kosek

Answer 1

Hi there,
This is the original poster.
I had meant to list out our steps to correct this issue earlier this week, but this is the first chance I got to update this. Hate being the only one in on a holiday week :(
Like Keith stated above this is caused by the NETIMM.INF driver. Thanks to Keith's guidance in parsing through the log files (Especially since I had no idea where most of them were hiding) we were able to see that the NETIMM.INF driver would try and load during the Windows PE Setup phase. This driver does not appear to load correctly in Windows PE (I've been trying to get it to load into a different PE image for the better part of a year for other reasons). When this driver gets loaded during the PE phase, the installer would see that the driver did not load correctly. The installer would pop open a command prompt window to allow you to debug what went wrong. Since this driver isn't really needed for the installation, you could exit the command prompt window and your install would continue along just like it should.
If you look at your wpeinint.log file you should see something like this:
Info      Installing device usb\vid_04b3&pid_4010 X:\WINDOWS\INF\netimm.inf failed with status 0xe0000219
Info      Spent 19095ms installing network drivers
Info      STATUS: FAILURE (0xe0000219)
Warning   Applying WinPE unattend settings failed with status 0xe0000219; ignoring shutdown settings
This is what hangs the box.
When Keith first pointed me to the driver being the problem, I just removed the driver from my Out-Of-Box-Drivers and still had the issue. The NETIMM.INF file is part of the base install media so it shows up anyway. I then did just what you did by disabling the Commands on the USB Interface. This basically stops that device from being available during the install, so no device, no driver and MDT is happy and reboots like it should.
The problem I have with that solution is that all of the OS Firmware update disks from IBM want to try and communicate through that USB device when you go to update anything on that machine (uEFI code, Diagnostics, ASU, etc). So if that device is not there, then you cannot use any of the on-line flash utilities to update your machine. Not sure how many machines you have (or how often you upgrade the Firmware on them), but that might come back to bite you later. Plus you also have to remember to disable that on all of your IMM equipped machines BIOS's. And then when a user resets the Bios back to defaults that USB device gets turned back on again and you start getting calls that the deployments are hanging. I'm in a test lab and we get new machines brought to us all of the time. I may not be the one to set it up and then I have to rely on somebody remembering to change a setting in Bios. I'd rather just change it globally from my end and then I know its fixed. But to each their own.
I did like Keith suggested and edited the WIM files. I simply renamed the NETIMM.INF to NETIMM.OLD and closed the WIMs back up. I too was worried about having to change the WIM files repeatedly. I'm the one that built out our MDT server. My co-workers know enough to rebuild the deployment share if need be, but they don't use MDT enough to know about mounting WIMs and changing files and such. What I did was I changed these on our base install media. In my case, MDT picked Windows 7 to build out the 32 Bit LiteTouch.wim and 2008R2 for the 64 bit LiteTouch.wim file. Once I changed these on the original disks, all of my LiteTouch rebuilds have kept this change intact. Now if I ever change these original disks and have to completely rebuild the WIM files, I'm sure I'll forget to make that change. However I'd rather deal with that then (My end users will let me know if the installs start hanging again) instead of having to remember to change each machine's bios settings.
Now since the NETIMM.INF driver is no longer on the install media, I need some way to add that driver during the installation and not during the PE phase. What I did was to add the NETIMM.INF file into my Out-of-Box Drivers section. I then created a new selection profile called LiteTouch. I added all of my necessary drivers, with the exception of the NETIMM.INF driver, into that new LiteTouch selection group and I changed my LiteTouch Components to only load from the LiteTouch Selection group during the PE phase. I then call my All Drivers group during the installation of the Operating Systems. That way I do not get the driver during PE, but I get the driver installed during setup and I can then talk to the IMM for updates and such. 
My way might not be the best way for everyone else, but it does what I need it to do.
I would like to take a minute though and thank Keith again for all of his help in troubleshooting this problem. We have a lot of remote users and this was causing them some grief because they would start a deployment and expect it to be done when they came back later. On the IMM equipped machines, they would be staring at a command prompt screen and have no idea what went wrong. I would then get calls stating that the install failed. Without Keith's help I'd still be getting those calls from our users.
Jim Kosek