ConfigMgr SCCM How to Resolve Errors Adding Boot Image Drivers from a Central Site. With nine regional SCCM 2007 primary sites across our enterprise, it only made sense to implement a Central Administration Site for inventory and central management.
From an OSD perspective, I was more than happy to implement this because it meant I could start centrally managing driver packages instead of maintaining nine separate driver stores and all the fun that entails.
Latest Posts – 11 Days Of Free Intune Training Course By HTMD Community – HTMD Blog #2 (howtomanagedevices.com) & SCCM SQL Server Database Migration | Part 2 |ConfigMgr (anoopcnair.com)
ConfigMgr SCCM How to Resolve Errors Adding Boot Image Drivers from a Central Site
Thus far, integrating new hardware models has been a breeze with the driver packages replicating down and installing just fine during the OSD Task Sequence.
However, in using Johan Arwidmark’s method of driver management, I did run into a little bit of trouble when it came to WinPE boot image drivers.
I added just a handful of network and drive controller drivers to one of my boot images…drivers I had already vetted and ensured were the proper ones for WinPE 3.0 x86…yet I was getting driver injection failures when I would update the boot image. ConfigMgr SCCM How to Resolve Errors Adding Boot Image Drivers from a Central Site.
So, I removed the driver that failed and tried again, only to fail on another driver. ConfigMgr SCCM How to Resolve Errors Adding Boot Image Drivers from a Central Site.
I removed all the drivers, and it updated fine, but to be sure, I re-copied the WAIK WinPE image from the %ProgramFiles%\Windows AIK\Tools\PETools\x86 folder to the source folder for the SCCM boot image to rule out any .wim file corruption. Still no dice. Time to dig into the logs.
Pulling up the DISM log (C:\WINDOWS\Logs\DSIM\dism.log) I get a better picture of the problem:
Error, file not found ‘\\\d$\Drivers\WinPE 3.0 x86\NET\Intel 11.6.92.0\E1K6232.inf’. – CDriverManager::OpenPackageByFile(hr:0x80070002)
So the server can’t access the driver files. I checked the Central Site and verified that the child primary’s computer account was indeed a local admin on the parent primary, so we know it’s not a permissions issue. From the child primary, I tried to hit the path to the driver file. “No network provider accepted the given network path.” Same thing if I tried to hit any share on the server, and a quick ping from the command prompt revealed the source of the problem.
The cause: No name resolution.
The site hierarchy was communicating just fine via FQDN, but SCCM accesses source paths using NetBIOS names in this case, and because there was no WINS entry in the child site’s region for the parent site server, SCCM couldn’t see the driver source path. As soon as we fixed the name resolution issue, the drivers injected, and everything was happy again.
Anoop is Microsoft MVP! He is a Solution Architect in enterprise client management with more than 20 years of experience (calculation done in 2021) in IT. He is a blogger, Speaker, and Local User Group HTMD Community leader. His main focus is on Device Management technologies like SCCM 2012, Current Branch, and Intune. E writes about ConfigMgr, Windows 11, Windows 10, Azure AD, Microsoft Intune, Windows 365, AVD, etc…