Autopilot: The group membership war

Autopilot: The group membership war

This blog will be about my experience with dynamic group membership within Azure AD.

Waiting for dynamic group membership to be updated can be a pain, certainly when combining dynamic groups with Autopilot. Imagine you have a Windows 10 device that’s not imported in autopilot, you’ll need to upload the hardware hash and wait for the device to change the autopilot device status to assigned.

Waiting…waiting…waiting.

But still, the profile status is not assigned. So, what to do now? Grab 10 cups of coffee and have some patience, or begin troubleshooting? (probably waiting will be the best option… it can take up to 24 hours sometimes). But for most business cases this will take too long.

When you configured Autopilot you created an autopilot dynamic group and an autopilot profile which the group is assigned to. So, the first thing we need to check is… is the device added as a member to your autopilot group?

A lot of devices, but not the one you just added. Guess that’s the reason why it has no autopilot profile assigned. Open the audit log file to check if “something” happened. As shown below on 04:12, that was the last time a member was added. That’s definitely not today.

Next thing I did is I checked if the dynamic rule is still valid and the autopilot devices are still targeted. The only thing we need for this is the serial number you got when importing the device into autopilot.

Add the device, to begin validating…

So, everything is green, but the device is not a member of the autopilot group?  What to do next? We need to have the object group id.

Now  we have the group ID, open a powershell session and :

connect-azuread
import-module azureadpreview –force

get-azureadmsgroup –id “id”

Take a look at the picture, Membershipruleprocessingstate: On. I guess we can change it to paused and back to on and hopefully we will trigger something?

set-azureadmsgroup -id a44b57ca-57af-412f-8288-1efb4ae6d3b0 -membershipruleprocessingstate “paused”

set-azureadmsgroup -id a44b57ca-57af-412f-8288-1efb4ae6d3b0 -membershipruleprocessingstate “on”

But unfortunately, nothing changed for now. What can we do next? Take a look at this uservoice and the reply:

Okay? That’s also a possible solution? So, open your autopilot group and add a space in your dynamic membership rule.

But again, nothing changed…

After spending some time on google I gave up and went for some drinks. 3,5 hours later group membership was finally updated and the autopilot profile was assigned.

Conclusion

Autopilot is a great feature, but with no possibility to trigger the group membership it can be totally worthless when you don’t know how long you’ll need to wait. Imagine a customer behind your back asking every 5 minutes if “it’s working already”.

The best option you have is creating a static group and use the -online switch combined with the -addtogroup parameter.

Get-WindowsAutoPilotInfo.ps1 -online -addtogroup “AutoPilotDevices” -assign

So, what did we learn? Make sure you also have the possibility to manually join the device to Azure AD and Intune. When manually joining Azure Ad, please take a look at some of my blogs about “adminless”. My next blog will be about the hiding the OOBE stage when performing a regular Azure AD join.

One thought on “Autopilot: The group membership war

Leave a Reply

Your email address will not be published. Required fields are marked *