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 having to maintain nine separate driver stores and all the fun that entails. 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.
So, I removed the driver that failed and tried again, only to have it fail on another driver. I removed all the drivers and it updated fine, but just 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 just 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 184.108.40.206\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.
See the orginal post