Usually, I want to roll out new features gradually to my users.
I used to do this by creating a security group, assigning new policies/software/patches etc to it, and then telling the IT staff to add users to it in groups and check with them if things went well.
But why? Why is that manual step needed?
Exactly, it is not!
So attached script can be scheduled in an Azure Automation Account (with Managed Identity enabled!) to add an X amount of users from Group A to Group B. This script can be scheduled to e.g. run daily until all users have been moved. Multiple scheduled would also work in case you’re deploying multiple features.
When certain users need to be excluded, simply create an exclusion security group and exclude that from your policies. Exclusions take precedence in most systems.
You can group deployment by supplying the groupByProperty, e.g. by Country
You’ll have to give the Managed Identity of your automation account sufficient graph permissions. This cannot be done through the GUI, so I’ve added a snippet you can use here:
You’ll probably want to communicate to your users in advance, it’d be fairly easy to generate a report in advance or to add email notifications to the script but that will require additional graph permissions.
[…] advantages that managed identities in Azure offer, here’s another use case similar to the scheduled migration script that also uses the managed identity (and graph permissions) to autonomously run as an Azure […]