1

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.

1

The required NIC driver "MUST" be either off-line injected and loaded by loaddrv at boot or on-line injected (Dism) in your Boot.wim file. Off course if the NIC driver is not properly loaded you will never see the MDT repository that means no access to anything MDT has to offer using its shares.

I think PE is detecting the NIC but your driver is not correctly "on-line" injected, that's why everything works if you manually load the driver with loaddrv.

  • Yes, I agree with what you noticed. – Elliot Labs Dec 6 '14 at 15:45
  • So I tried on-line injecting with dism to the LiteTouchPE_x64.wim file that MDT generated (backing up first, of course) and then tested, but still no luck. Is that what you mean by online injected? For reference, I ran dism /mount, dism /add-driver /recurse /forceunsigned (some of the driver files are unsigned), and finally dism /unmount-wim /commit. – Kevin Dec 10 '14 at 19:52
  • I tried it both with the vanilla inf and the one that I added the hardware ID to it. Neither worked. – Kevin Dec 10 '14 at 20:02
  • the on-line injecting is what you do with dism. you should not mess with HWD_IDs (that's no really simple). You said you were able to load the driver from the booted PE then you should be able to on-line inject the same driver with dism. Your problem is the driver; make it work with dism. – Pat Dec 10 '14 at 20:28
  • 1
    So after returning to work today after break, I was talking with my coworkers and realized that after all of the changes we made to the image, I had never re-imported the images back in WDS to replace it in the boot menu. So I again injected the drivers with DISM, deleted the old wim, imported the new one, gave it another go, and it worked. I apologize for my incompetence. – Kevin Jan 6 '15 at 1:02
1

I'm going to assume you're deploying Windows 7. I ran into a similar issue on newest Intel wired NIC chipsets. Check the Kernel Mode Driver Framework for an update. Windows 7 launched with version 1.9 per TechNet, and this needs to be injected into the image as a task in MDT. Windows 8 certified hardware will likely target KMDF 1.11

This Post explains in detail the process. This covers the actual image deployment, not the issue that seems to be your WinPE image is not detecting the NIC.

What version of WinPE are you using?

  • Sorry, we are deploying windows 7. However, the issue arises before I'm able to start the deployment, so creating a task sequence to do this won't work since I'm not able to select any task sequences to run. Also we haven't made the jump to SCCM yet (that's going to be after we know WDS + MDT inside and out). I tried to inject this into the litetouch image through the packages folder (right click on packages, import) and it collected the two. Updated the share, tried again, but no luck. – Kevin Dec 5 '14 at 20:01
  • Let me go back over my deployment, it's actually a step in before the closing of the Install image process, and before the first reboot. – blaughw Dec 5 '14 at 20:04
  • I found it. I'm using a later WinPE version, so KMDF is updated. I only needed the framework update in my Windows 7 image. You will either need to update your WinPE, or inject the framework update into your WinPE image using DISM. – blaughw Dec 5 '14 at 20:17
  • Ok. Using the ver command in the WinPE environment, I'm using 6.2.9200. That's Windows 8, so do I need to use a windows 8.1 based WinPE Environment? – Kevin Dec 5 '14 at 20:31
  • So yes, the problem is that WinPE isn't detected the NIC and therefore not loading the right driver (sorry if I wasn't clear on that). I checked the version of WinPE, and it looks like 6.2.9200 corresponds to Windows 8 (NOT 8.1) which is WinPE 4.0. Would updating to 5.0 (8.1) help? – Kevin Dec 5 '14 at 21:25
0

From the CAB file which is unzipped, remove the network driver folder. Import all the drivers except those in the network driver folder. Once that has imported, then import the network drivers. This resolved the issue for me.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.