Today I want to show you, how you can monitor changes in Intune configs using Azure DevOps. This will be part one of a multiple part series about Config as a Code with Azure DevOps.
Azure DevOps project
Let’s start with creating the DevOps project, that we will use for the whole series. I’m assuming you already have a DevOps organization, if not check out the official docs to create one, as it’s pretty simple: Create an organization – Azure DevOps | Microsoft Learn. Once we have the Organization, we can create the new project and give it a speaking name:
Once we have the project set up, we can set up a new Repo, that we will use here in Part 1 for Intune Configs. Over the series we will create additional Repos for other use cases, so give it also a useful name.
DevOps Agent Pool
Next thing we should prepare, is to create an Agent Pool, where we can run out CI/CD Pipeline, that we are using to get the configs from Intune into our Repo. Since in part 2 I want to collect configs from local GPOs, I will create my Agent Pool on an onPrem Server. If you don’t need this, you can use an Azure hosted Agent Pool as well.
Once we have created the Agent Pool, we can click on New Agent to get the instructions on how to install the Agent on our self-hosted server.
DevOps Service Connection
Next thing, that we need to create is a Service Connection to get the needed permissions to use Graph API to get our configs from Intune. We are going to use “Azure Resource Manager”:
And then select “Workload Identity federation (automatic):
Finally, we can select a Resource group in an Azure Subscription of our choice.
For now, we are not actually using resources in this subscription, but we are using this connection to grant it API permissions directly, that we are going to use.
Once we found the App registration for our newly created Service Connection, we can assign the needed API permissions.
For now, we need read/write permissions for device configurations, since read only fails to decrypt Custom OMA/URI configurations. For Apps and Service Configs (Autopilot and Co.) a read only permission is enough.
DevOps Pipeline
For our Pipeline to work, we need one last thing, we have to allow the Build Service to contribute to our repo. We can do this in the project settings, under repositories:
Now that we have finally got all prerequisites ready, we can create our CI/CD Pipeline. I uploaded the Pipeline.yml file that contains the logic and the IntuneExport.ps1 Script, that is based on the IntuneBackupAndRestore Project, so the created files should be mostly compatible https://github.com/jseerden/IntuneBackupAndRestore
First we upload these two files from my GitHub to our newly created Intune Repo:
Once we uploaded the needed files, we can create the new Pipeline itself:
We will select existing Pipeline and select the IntunePipeline.yml files.
Once the Pipeline is created, you can review the code, modify the git config to match you needs (Name / mail address) or for example modify the schedule to your needs:
When you run the pipeline for the first time, you need to grant it permission to the Agent Pool and the Service Configuration:
If everything went well, you should see the first successful run of the Pipeline:
Now that everything works as intended, you can search and read all configs in the Repo:
You can basically use every feature that you are used to from a modern source control system, like comparing file history:
Notifications on changes
Now that we finally have all our configs in our repo and automated the updates, we can configure a notification rule, to get an mail alert on changes. We can do this in the user settings:
Create a new subscription for when a commit is pushed:
And enter a mail address to where the notification should be sent. In my example I also added a validation to only do this for this specific repo:
Now when something changes in Intune, you will get a e-mail notification about this change and you can check what changed.
Conclusion
Since we migrated nearly every workload to Intune and Entra joined devices, we are now at a point, where Intune gets a pretty critical system, so I think it is really helpful, especially in a larger team, to have the option to get notifications about changes. Additionally, you can use this information as a kind of backup solution, since we have a nice file history. In Part 2 I will show something similar for onPrem GPOs, since we are still using it for part of our VDI Infrastructure, so it is really nice to all configs on one central place, so stay tuned.
Leave a Reply