This blog will be about my experience using a dynamic group for the Windows Autopilot Profile assignment and how processing the dynamic group membership takes longer than we want it to take.
1. The Issue
Let’s begin with the issue, as we can’t solve anything without problems!
Waiting for dynamic group membership to be updated can be a pain when combining dynamic groups with Autopilot. Imagine you have a Windows device that’s not imported into Autopilot. You’ll need to upload the hardware hash and wait for the device to change its autopilot device status to assigned.
Waiting…waiting…waiting.
However, the profile status has not been assigned. So, what to do now? Grab 10 cups of coffee and be patient, or begin troubleshooting? (Waiting will probably 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 fix the slow dynamic group membership update!
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 whether the device has been added to your autopilot group.
There are a lot of devices, but not the one you just added. I guess that’s why it has no autopilot profile assigned. Open the audit log file to check if “something” happened. As shown below, 04:12 was the last time a member was added. That’s definitely not today.
Next, I checked if the dynamic rule was still valid and if the autopilot devices were 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 should we do next? We need 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.
3. The Better 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 and assign the group.
Get-WindowsAutoPilotInfo.ps1 -online -addtogroup “AutoPilotstaticgroup” -assign
https://call4cloud.nl/wp-content/uploads/2022/01/Get-WindowsAutoPilotInfo.zip
4. The Autopilot device Preparation Solution
This is a way better solution than using a dynamic group and waiting until it’s updated or using a static group. We could use the Enrollment Time Group. As I mentioned in the blog below, when the device enrolls into Autopilot, it will automatically be placed inside this new Enrollment Time Group!
This group can be used in your Win32app and policy assignment.
Conclusion
Autopilot is a great feature, but with no possibility of triggering 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!
Your best option is to create a static group and use the—online switch combined with the—add to group parameter.
Get-WindowsAutoPilotInfo.ps1 -online -addtogroup “AutoPilotstaticgroup” -assign
Yes, Azure AD dynamic groups are a pain. But if you’re already going through the work of manually adding the device to Autopilot, why not take one simple extra step and add it to a static group at the same time. See https://oofhours.com/2020/07/13/automating-the-windows-autopilot-device-hash-import-and-profile-assignment-process/.
Awesome blog!
Are filters the way around this? They seams to be evaluated in a different way.
The only problem with the “Get-WindowsAutoPilotInfo.ps1” solution is that if you run it through AppRegistration it is specified that you cannot add it to the group as it does not support authentication to Azure : “Connected to Intune tenant $TenantId using app-based authentication (Azure AD authentication not supported)” . Solutions ?