This blog will be about my experience with dynamic group membership within Azure AD.
I will divide this blog into multiple parts
Let’s begin with the issue, as we can’t solve anything if there aren’t any problems!
Waiting for dynamic group membership to be updated can be a pain, certainly when combining dynamic groups with Autopilot. Imagine you have a Windows 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.
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.
2. Trying to Solve it!
When you configured Autopilot to use a dynamic group and assigned this profile to this group you could end up in the same situation as I did. Let’s see what we can do to solve it.
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.
The 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 :
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.
3. The real Solution:
But waiting is not the solution you want. Instead of assigning the autopilot profile to a dynamic group, assign it to a static group. When you run the get-windowsautopilotinfo command you can specify the group and assign it.
Get-WindowsAutoPilotInfo.ps1 -online -addtogroup “AutoPilotstaticgroup” -assign
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”…. that sounds like war!
The best option you have is to create 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.