MicrosoftGreat to see this go GA. A question on the static group requirement for the PSSO update in the "Before you begin" section: the doc requires assigned (static) user groups and rules out both dynamic groups and device groups. I'm trying to understand the underlying mechanism rather than just the rule. For example, an environment of ~3000 macOS users now needs to completely restructure and manually maintain a static user group that is realistically in constant flux. A previously automated process becomes significantly manual, without building a secondary and tertiary automation for group addition/removal via graph or Power Automate.
For ordinary config policies, late group resolution is harmless because the policy just lands on a later check-in. This feature is different since the PSSO policy has to be present and evaluated before Setup Assistant runs the registration step, with no graceful late-apply (the recovery path is wipe and re-enroll). That said, my mental model is that the assignment evaluates membership at enrollment time per device. If a group has 200 members when one device enrolls, and another device enrolls a week later when the group has 210, I'd expect the policy to apply correctly to whoever is a member at each enrollment, without breaking the original 200. So a changing count alone doesn't obviously explain the restriction.
Is the static requirement there because dynamic group membership is evaluated asynchronously by Entra and can lag the ADE enrollment event? So at the moment Setup Assistant needs the answer, a genuinely-entitled user may not yet resolve as a member? Or is the breakage caused by something else entirely?
Related: does "All users" fail for the same reason (resolved at evaluation time rather than stored membership), and if a user is added to the static group well ahead of their build, is there any remaining timing sensitivity, or is pre-populated membership fully sufficient?
Thanks for any detail on the sequencing here.
