Working on presentations frequently makes me revisit past stuff. And in this case, that “past stuff” predates my involvement with Windows Autopilot (I started working on it in 2018). Let’s go back to 2017, when Windows Autopilot was first being built (technically, it was probably 2016 since it released in 2017). There wasn’t yet any support in Intune, that was still a work-in-progress (and a sure sign of the silos that existed within Microsoft, with Autopilot being done by the Windows team). So, for a system that requires pre-registering and configuring settings on devices, what are you going to do? Pretty much anything you can. The result: multiple ways created by (and maintained by) multiple teams.
Most people started off initially using the Microsoft Store for Business. It lets you (quickly) import devices, created Autopilot profiles, and directly apply those profiles to computers (select a list of computers, choose the profile to apply to them, done in a fraction of a second). What’s not to like about that? Simple: The capabilities in the Microsoft Store for Business (run by yet another team within Microsoft) are frozen in time, supporting only the capabilities that existed in 2017, nothing new after that.
With the Microsoft Store for Business being retired in the first quarter of 2023, this one will be going away, so if you are still using it (for some reason), you need to start making the switch.
There’s also Partner Center, a system that is used by Microsoft partners of all types: resellers, distributors, service providers, etc. When you ask for a reseller to register devices on your behalf, this is what they use, and it works great for that. But like the Microsoft Store for Business, it too is frozen in time, not adding support for any new features released after 2017 (again, maintained by another team within Microsoft). So, it can’t take advantage of those new features. And weirdly enough, it can’t assign profiles that weren’t created in Partner Center, so even for those 2017 capabilities you would have needed to ask the partner to create and manage the profile for you.
It’s great for resellers and distributors to add devices to Autopilot for you via Partner Center, but you should manage the profile creation and assignment yourself. (Note that OEMs typically don’t use Partner Center, they use an OEM-specific API for registering devices. There’s no portal for that, just an API that the OEMs can call from their own systems.)
The portal that I always forget about (and apparently so does everyone else — never did find anyone who actually used it) is the Microsoft 365 Admin Center (https://admin.microsoft.com). It is structured pretty much like the Microsoft Store for Business: you can import devices, create profiles, and directly assign profiles to devices.
And yes, it too is stuck in 2017 (no new Autopilot profile options added since 2017, and yes, another Microsoft team — not that anyone would claim it). It apparently was created for a Microsoft 365 Business Premium and is fully documented, but that doesn’t mean I ever found any customers that used it.
So, at the end of the day Intune is the only portal that has been kept up to date, and as such it’s where you should be defining your devices and profiles. But it’s still useful to look at a more “direct” view — if you used the Microsoft Store for Business in the past (e.g. to manually delete a stubborn machine, to see if a profile has indeed been applied, etc.), you will probably want to shift over to the Microsoft 365 Admin Center as it can do the same stuff. Be careful if you assign profiles through a portal other than Intune though as that will likely flag the Autopilot device as “externally configured” so that Intune doesn’t accidentally overwrite its configuration. (At least that’s the way it was designed to work, not sure that I ever verified that it does indeed work that way.)
Categories: Windows Autopilot
What about SCCM automatic import and even using Graph ?
When moving to Autopilot (AP) SCCM registered the majority of our existing PCs. All we needed to do was add the group tag value and “Voila” Autopilot Ready (managed by Intune).
And the Graph API has been useful for registration of those devices not in SCCM that we needed to deploy with AP. We use (some will cringe) the OA3tool in WinPE in a SCCM Task sequence to apply a generic OS image and register “old” devices.
Graph is the “behind the scenes” method used by Intune. Capturing a hash in Windows PE can be problematic because there are missing drivers; as a result, you won’t have TPM info at minimum, also likely missing Wi-fi MAC info. It may still match on what’s left, but there will be less tolerance to other changes then.
If prior performance is any indication the OA3tool generated hash data has been reliable for us on hundreds if not thousands of PCs. I assume it’s what vendors (Lenovo, etc..) use to generate the data on the production line to be imported.
The main problem with the WinPE / OA3 approach was getting Graph access from WinPE. PS modules aren’t available. And i must use SCCM boot media as it does some crazy magic with Time i haven’t been able to figure out.
Vendors do use OA3TOOL, but they are mandated to run it in the full OS (for the reasons I mentioned). So you definitely have incomplete hashes — the only question is whether that will ever cause you any issues. (SCCM syncs the time with the MP, otherwise a mismatch between the time zone in the machine’s real-time clock and the OS/PE causes all sorts of issues.)
I don’t have devices visible in the admin portal.
I do. Presumably there are some security rights being applied (I’m a Global Admin for my tenant).
I am also Global Admin for our tenant.
I couldn’t comment on your other post Autopilot enrollment using the Get-Windows Autopilotinfo.ps1 -online -AddToGroup “GroupName” -Assign
Do you know any good resources on how to do this with a hybrid setup? I’ve seen before where you can run the “Get-WindowsAutoPilotInfo.ps1 -online -AddToGroup” script and join them to a specific hybrid azure ad group that has a script attached to it that hybrid joins it? Unfortunately, the environment is still on local AD and using group policy, but also using intune for device management.
That’s challenging. If you only have one “Domain Join” profile, it’s easier to just target it to all devices. That is only used during Autopilot HAADJ deployments, so it has no effect on other machines.