I have been testing a replacement imaging system to replace our limited Ghost deployment system for a good portion of the last year. We bought a new batch of machines (HP Workstation Z230) which have the Intel i217-LM NIC. I have had a significant amount of trouble getting this little guy to play nicely with WinPE. I thought I had figured it all out, but here I am again, stuck even more than I was before.
Our imaging server consists of a Windows Server 2012 box with WDS, WAIK, and MDT installed on it. Deployments to other hardware platforms work fine, however when I try the newer Z230 machines I get a message:
Wizard Error
A connection to the deployment share (\servername\sharename$) could not be made. The following networking device did not have a driver installed. PCI\VEN_8086&DEV_153A&SUBSYS_1905103C&REV_05
Retry: Try again to connect to the deployment share. Cancel: Give up, cancelling any in-progress task sequence.
This is the first thing to pop up after PxE booting the client and selecting the LiteTouchx64 boot image. I get no other options.
I knew this likely was a driver issue (again!). So I brought up the command line with F8 and gave the good old ipconfig a try. Nothing. No adapters listed at all. I looked back at MDT and confirmed that the INF files which fixed the problem the last time were in the "Out-of-box Drivers" folder (we also have the drivers separated based on Manufacturer, OS, and Model Number; Hewlett-Packard->Windows 7 x64->HP Tower Workstation Z230. These were found using the 'wmic' command in command line with the appropriate flags). Of course, it was there. I updated the deployment share, just to be safe. No luck. I tried both the x64 and x86 boot images. Again, nothing.
So I went back to Intel's website, and downloaded the NIC drivers again. Rinse, repeat, and still nothing.
Next thing I tried was to manually load the drivers through command line using the drvload command from a flash drive (the updated drivers from Intel's website):
for the 64 bit WinPE image
drvload F:\Winx64\NDIS63\e1d63x64.inf
or, for the 32 bit:
drvload F:\Win32\NDIS63\e1d6332.inf
For more information on this, see: http://www.adamfowlerit.com/2013/10/08/troubleshooting-nic-drivers-in-winpe-for-sccm-2012/
Both commands were left thinking for 10-20 seconds before completing and exiting with a "Completed Successfully" message. I then went back to ipconfig and found that I now had an IP address. I clicked retry and the rest of the OS deployment completed (with a few unrelated errors which have now been fixed). Once Windows had been setup and booted, I checked in Device Manager to see what was what with this NIC.
I found some interesting things: First of all, the driver had been automatically pulled from MDT, so I know that somehow the correct driver was there. Second, that Windows was using a different driver inf (e1d62x64.inf).
So I checked to make sure that this driver was also in MDT: it was. I tried again, this time manually loading the driver specified in Windows. The command "completed successfully," but when I went to ipconfig and checked to see if it had worked, I had no adapters listed and no IP address.
I also tried:
wmic nic get name
This returned:
Name
Microsoft Kernel Debug Network Adapter
so then I again loaded the e1d63x64.inf file manually and tried again:
Name
Microsoft Kernel Debug Network Adapter
Intel(R) Ethernet Connection I217-LM
Great. It works. So, again, I ensured the driver was in MDT. I also tried adding it again, this time just to the Out-of-box Drivers folder, not under any other folder. Updated the deployment share again, gave it another go, and nothing.
Next thing I tried was to manually add the hardware ID to the e1d63x64.inf file so that it would hopefully pull automatically. I didn't have any idea what I was doing, really, so I probably did it wrong. I ended up seeing a section of lines which had hardware ids listed with some other jibberish, so I added the HW ID to this section. (Like I said, I had no idea what I was doing, it was a shot in the dark).
I also tried manually injecting the drivers into a copy of the LiteTouch image. I was able to mount the images using DISM, but when I tried to inject the drivers using /recurse and /forceunsigned (the first version of the drivers I tried months ago was unsigned, which gave me some headaches. I also tried combinations of one of each) it was unable to inject the driver, and I didn't think this would be a valid solution for a production environment, so I didn't spend any more time on it.
I also checked the DISM log, and found these lines:
2014-12-05 10:12:11, Info DISM DISM Provider Store: PID=9932 TID=8808 Getting Provider DriverManager - CDISMProviderStore::GetProvider 2014-12-05 10:12:11, Info
DISM DISM Provider Store: PID=9932 TID=8808 Provider has previously been initialized. Returning the existing instance. - CDISMProviderStore::Internal_GetProvider 2014-12-05 10:12:11, Warning DISM DISM Driver Manager: PID=9932 TID=8808 Could not get boot critical status for the driver class {4D36E972-E325-11CE-BFC1-08002BE10318} from driver store. Assuming that this is not boot critical. - CDriverPackage::InitBootCriticalFlag(hr:0x80070490) 2014-12-05 10:12:11, Info DISM DISM Driver Manager: PID=9932 TID=8808 Signature status of driver C:\DeploymentShare\Out-of-box Drivers\Net\e1c63x64_12.10.29.0_BB24AD7808CE1BF67EDB58B8B4A03234EFF8712D\e1d63x64.inf is: UNSIGNED - CDriverPackage::InitSignatureStatus 2014-12-05 10:12:16, Info DISM DISM Driver Manager: PID=9932 TID=8808 Successfully proccessed driver package 'C:\DeploymentShare\Out-of-box Drivers\Net\e1c63x64_12.10.29.0_BB24AD7808CE1BF67EDB58B8B4A03234EFF8712D\e1d63x64.inf'. - CDriverPackage::InstallEx
So treated as not boot critical and unsigned. Is there a way to declare this driver as boot critical? If so, how? Would this be likely to fix the issue?
Summary
To summarize and clarify: I can't get the i217-LM NIC to load during WinPE so I can't connect to the deployment share during PxE boot and cannot select any task sequences. By manually loading the driver with the "drvload" command, I can get past this and complete the deployment, however with the large number of computers that will need to be imaged, this is not a desirable solution, so I was hoping to find a fix so the driver will automatically load.