Windows 10 Upgrade GUI is designed to provide administrators the ability to give users the power to run upgrades in their own time, being a welcoming user friendly experience. This is designed to run prior and subsequently start a ConfigMgr\SCCM Upgrade Task Sequence.
I’ve created dozens of State Migration Points over the last few years, and 99% of the time, i’ve had to alter the permissions in 1 place or another to get it to work properly.
Having researched this alot, I note there is no 1 place to say, Set these permissions…Until now..
How do we make OSD failure obvious? How do we make it so it’s impossible to miss even to the most basic of user that the machine they are looking at has not been deployed correctly, and needs attention..
Picture this if you will, you have 20 models of hardware in your organisation that you’ve meticulously created Driver Packages for and ensured they build correctly with your managed images, thus creating a list of Supported Hardware. Sounds good, right?
So imagine the surprise and confusion when on a cold and dark Monday morning before your first cuppa, someone rings you up to say their computer won’t build, or missing certain drivers once it does!
Only, things aren’t as they seem. As you find out once you’ve delayed your first cuppa, and have come to find out that this computer is a completely different Manufacturer, let alone Model from anything anywhere near your list of Supported Hardware. So it’s not surprising it’s failing to build!
Sound familiar?
Bringing OEM Files back to life, and why you should use them.
OEM Files as I call them, or $OEM$ as it was more commonly referenced in MDT times gone by, are quite simply a bunch of files and folders that you wan’t to copy onto every machine you image. Why would I want to do that? – I hear you ask, well for a multitude of reasons I would reply.
Everything SCCM 