Audit changes in GPOs using Azure DevOps – Config as Code Part 2

In part 1 of our Config as a Code series, we monitored changes in Intune. Since we still have machines that are managed via GPOs like Servers and some VDI, in part 2 now I want to show you how you can monitor these Group Policies as well in the same DevOps project.

DevOps Project

If you haven’t checked out part 1, we were 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 had the Organization, we created the new project and gave it a speaking name:

Since we already have the project set up in part 1, we can now set up a new Repo, that we will use here in Part 2 for our GPOs.

DevOps Agent Pool

If you already set up the Agent Pool in Part 1, you can skip directly to the creation of the DevOps Pipeline. If you skipped Part 1, you will need to create an Agent Pool, where we can run out CI/CD Pipeline. Since we want to collect configs from our GPOs, I will create my Agent Pool on an onPrem Server.

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.

Finally, we need to make sure, we need to make sure, we have the RSAT Tools installed on our Server used in the Agent Pool

DevOps Pipeline

For our Pipeline to work, (if not already done in Part 1) 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 all prerequisites ready, we can create our CI/CD Pipeline. I uploaded the Pipeline.yml file that contains the logic and the GPO.ps1 Script to GitHub. First, we upload these two files to our newly created GOP Repo:

Modify the GPO.ps1 to match your Domain name in line 10. Once we uploaded the needed files, we can create the new Pipeline itself:

We will choose the GPO Repo, select existing Pipeline and select the GPOPipeline.yml file.

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:

If everything went well, just as in Part 1 you should see the first successful run of the Pipeline:

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 a 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 someone modifies an GPO, you will get an e-mail notification about this change, and you can check what changed.


Now that we have not only Intune configs (Part 1) but also GPO Data in our DevOps Repo, we have a nice central place for all of our configurations and also a alerting system for changes. The GPO Export script also creates an GPO Backup every time a change in the XML Export is detected, so we also have a ready to restore Backup available in case something gone wrong during a change of a GPO.






One response to “Audit changes in GPOs using Azure DevOps – Config as Code Part 2”

  1. […] Audit changes in GPOs using Azure DevOps – Config as Code Part 2. Learn more […]

Leave a Reply

Your email address will not be published. Required fields are marked *