OK, so if the title of this post made you read further, I’ll give you the short version – it won’t work and you really shouldn’t try it. But the question you never thought you’d ask came up and I thought I’d answer it and try to explain why.
So here’s the scenario, there may be others that lead to the same question though:
- We have several Windows Autopilot deployment profiles in play
- We have groups assigned to each of those deployment profiles, in this case with assigned members
- A device is a member of one of the groups and thus in scope of the appropriate deployment profile
- The device is provisioned with Autopilot, in this case a user-driven Azure AD join
For the purposes of testing mixed with a sprinkle of chaos theory, what say you add the device record into one of the other groups which are assigned to another deployment profile. Well, the answer is nothing really. There’s nothing stopping you from doing it but it has no result.
Going back to the original device record import which used the hardware hash, this creates an Autopilot device record. When you add that device record into the appropriate group, the deployment profile is assigned to it.
If you try to import that device again, Autopilot will reject it with “806 – ZtdDeviceAlreadyAssigned” and that makes sense as there’s a mechanism in place to check for that.
We can see that the in the Autopilot profile, the device shows as assigned.
So, once the device is provisioned (i.e. has ran through the Autopilot process) successfully, the device will then have an Azure AD record in play which corresponds to that device, and you’ll note if you look in Azure AD that it’s marked as an Autopilot device. In this case this is an Azure AD joined device as shown.
In theory what’s to stop you now adding that record into one of the other groups too? Well, nothing. You might be forgiven to think that if you do that the device will also appear as an assigned device, it won’t. There is another mechanism in place within Autopilot which does a check to see if there is an existing record for the device.
So, why did I write this? Well it came up and there were no other posts out there that said as such. To many folks with some Autopilot experience this may seem obvious, but if you’re new to Autopilot and even more so if you’re used to something like Configuration Manager where you can assign a bunch of different task sequences to one device, it’s maybe not so obvious.
In summary then, it’s a wise idea to use dynamic memberships in groups and use things like Group Tags. Read more on Group Tags here – https://oofhours.com/2020/04/08/fun-with-windows-autopilot-group-tags/
It’s also a good idea to use the toggle switch to convert targeted devices to Autopilot. More info here – https://docs.microsoft.com/en-us/mem/autopilot/enrollment-autopilot#create-an-autopilot-deployment-profile
Also, some general Autopilot troubleshooting info is here – https://docs.microsoft.com/en-us/mem/autopilot/troubleshooting
I hope that’s useful to someone somewhere.
/Peter
Good write up Peter but if I may respectfully point out that I didn’t find an answer to the actual question because of the convenient scenario described here, where group membership has occurred already and one is trying to finagle the process by attempting to add the device to more groups, after the provisioning process. The true question IMHO is this:
Brand new Auto Pilot import, never before the device had existed. Tag matches 2 dynamic groups, each group assigned to separate Windows Autopilot deployment profile profile.
Now what? Which profile will be assigned to the device? Both?
Thanks
~B
LikeLike