The Error Message That Wasted Part Of My Day – or – I Am Not A Smart Man…

, , , , , , ,

I’ve run into an issue that I couldn’t find documented anywhere, so I am hoping this post can help someone else in the future.

I recently stood up a new environment for a school district and it’s running ConfigMgr 1902 with ADK 1903. I prefer to have a custom boot image that is separate from the default boot images that are created with setup, because I don’t want to risk breaking a boot image during an upgrade of ConfigMgr/ADK in the future. So, I open the Deployment and Imaging Tools Environment cmd prompt and run:

copype.cmd amd64 c:\bootimagex64

I take the boot.wim file from c:\bootimagex64\media\sources and place it in my site server sources folder for import. I go to Software Library -> Operating Systems -> Boot Images, select Add Boot Image, type out the UNC path to my site server sources folder and the new boot.wim file. Easy Peasy … but then I’m presented with the following error message:

The specified UNC path does not contain a valid boot image file or you do not have permission to access it. Specify a valid path.

The specified UNC path does not contain a valid boot image file or you do not have permission to access it. Specify a valid path.

The path IS valid! The Add Boot Image Wizard even completes my UNC path as I type it …

y u no like my path?!

Yet it still gives me that error!


Welp – Time to troubleshoot.

typey, typey, type

First thing I checked is permissions. I verified that the site server computer account had full permissions for NTFS on that drive and within sharing for that particular share. I also verified that the service account had full permissions to NTFS and sharing, just in case. I even checked the permissions on the boot.wim file thinking maybe they didn’t inherit properly. None of that seemed to matter.

Next thing I checked is if the boot.wim is a valid boot image. I started up psexec in the context of system so I could run dism to verify that I could mount the boot.wim with:

psexec -i -s cmd

and then:

dism /mount-image /imagefile:”c:\bootimagex64\media\sources\boot.wim” /index:1 /mountdir:”C:\bootimagex64mount”

Then I go browse over to c:\bootimagex64mount and I can see the boot image successfully mounted so I know I can unmount it with:

dism /unmount-image /mountdir:”c:\bootimagex64mount” /discard

I was still unable to add this boot image to ConfigMgr.

So, I did what any self-respecting sysadmin would do and I went grovelling to my community for assistance. I tried the winadmins slack first, but the ideas presented didn’t get me anywhere.

[If you aren’t in the winadmins slack yet, then head on over and join us]

  • I tried using an alternate boot.wim, like the ones found at <ConfigMgrInstallDirectory>\OSD\boot\x64, but was met with the same error message as before.
  • I really didn’t want to rollback the ADK, even just for testing purposes. I was willing to try it, as a last recourse, since the support matrix shows it is supported, but I’m stubborn.
Windows 10 ADK & ConfigMgr Support Matrix

Next I went to reddit and posted on /r/sccm to see if I could get any help there.

reddit post

I was fully prepared for Jason Sandys to jump in and comment as he seems to be on the most popular Google results for this error message and he’s present on technet and reddit comments that I was looking at during my research, but I think I got an even better response…

I love you /u/vsoro00

I blame Jeffrey Snover for making me not want to click buttons, but really … I’m not a smart man. I cannot believe I never thought to browse to the damn wim file.

Windows 10 ADK & ConfigMgr Support Matrix

I came into the office today and decided to listen to /u/vsoro00 and click that browse button:

Windows 10 ADK & ConfigMgr Support Matrixand wouldn’t you know it … it worked!

I still don’t understand how this is functionally different from my typing it … but hey!


Woot! Now let’s make sure it will fully import…

There we have it folks … a new boot image added successfully!

I want to say a heartfelt thank you to /u/vsoro00, who I assume is Vladimir Sorokin over on the ConfigMgr team at Microsoft, for taking time to answer my post in reddit with exactly what I needed to hear. I don’t understand the technical limitations they are working with or what he means about how expensive the process can be to validate everything I type in, but if this is truly an issue for others than I look forward to them removing the typing functionality altogether! I love this community!

Chris Thomas

Importing drivers into SCCM in bulk

, , , , , ,

Importing SCCM drivers in bulk

This is taken from my TechNet gallery here:

When you’re tasked with something like a Windows 10 upgrade, you’ll find yourself spending lots of time downloading and importing SCCM drivers.  While this script won’t go out and download them for you (like the Dell and HP Driver Import tools I’ve seen out there), it manufacturer, model, and architecture agnostic, you don’t get caught up trying to negotiate your way past your firewall and proxy teams, and it runs in a bit under 50 lines of code (including comments). Rather than pasting in the entire thing, I’ll do a screenshot and walk through from there.

sccm drivers

For this script to work, there’s some groundwork required on your part. When you download the drivers, they need to be downloaded into a folder that has whatever name you want for your driver package later.  If you’re like me, you’re already doing this as you download. If I need drivers for an HP Z230 desktop, the folder they’re saved in is already called “HP Z230 Windows 10 x64” or something similar so I can find them later.  The way this script works, whatever your folders’ names are is what names your driver packages will end up with.
Aside from that, all you need to do is plug in the path to the file share that has all your make/model folders in the root, as well as the location where you want to store your driver packages.
Something you will notice in this script is that I bounce between my C: drive and my SCCM drive. This is because UNC paths don’t always work as expected when you’re on the SCCM drive, and SCCM cmdlets don’t play nice running from anything other than the SCCM drive.  To guarantee they both work when needed, I just switch between locations, and it’s no big deal.
This script can take a little while to run, but it will give you feedback as it goes, and it doesn’t lock you out of the SCCM GUI while it runs.