Search for a command to run...
IntuneCD + GIT repository + Pipeline + Intune Audit Log = Intune configuration backup solution where even who made the change is back-upped
I work as System Administrator for more than 15 years now and I love to make my life easier by automating work & personal stuff via PowerShell (even silly things like food recipes list generation).
No comments yet. Be the first to comment.
Or any other Azure service requiring special authentication strength
If you are using Azure Local (HCI), you might find the following PowerShell script AzureLocalVMImageUpdater.ps1 useful. What is it good for? The code replaces the Windows VM images in the specified Azure Local cluster(s) with the latest compatible ve...
Problem It happens that the hardware hash of your Autopilot device gets changed. Thanks to the replacement of the motherboard or some other issue. This can lead to future problems when your users need to reinstall the operating system, but the Autopi...
Learn how to use undocumented Azure APIs for massive performance gains
Keeping a secure, version-controlled backup of your Intune-managed device data, including BitLocker, LAPS, and FileVault keys, is a best practice for any modern IT team. In this post, I’ll guide you through an Azure DevOps pipeline that automates the...
I was quite surprised when I found out how easy is to regularly back up your Intune environment configuration using the great IntuneCD tool and Azure DevOps service.
Today I will show you how I took the existing solution and improved it so that even the author of the Intune configuration change is included in the backup.
The result?
You can easily browse through your Intune environment history saved in your GIT repository and see who made what change and when it happened 🤯
it is free of charge
all your Intune configuration will be regularly backed up to your private Azure DevOps GIT repository
visibility to Intune changes made during the time including the author of such change
ability to see how the Intune was configured at a specified point in time
runs in Azure DevOps Pipeline a.k.a. purely code-driven & cloud-driven (no on-premises requirements whatsoever)
Azure Global Administrator permissions so you can
create an Azure DevOps project and Workload Federating identity
grant required Graph Api permissions
This solution needs:
Azure DevOps
Azure DevOps Pipeline
Workload Federating identity
Go to https://dev.azure.com/ and create a PRIVATE new GIT repository (project).
Intune Backup in my case.
Go to Project settings > Repositories > Security and grant Contribute 'ALLOW' permission to Build Service account. Otherwise, pipeline jobs will fail when a commit is made.
Instead of using Azure Service Principal (SP) to authenticate to Graph Api, we will use Workload Federating identity. The main benefit is that you don't have to worry about passing SP secret to your pipeline, renewing it, etc.
How to create a Workload Federating identity is outside of the scope of this article and is described in my other post.
It is just a few steps, the only important thing is to remember, what name you have used to create Service connection name during the setup because we will use it in our pipeline later.
In my case it is intune_backup_connection.
Grant the following Graph API application permission to the created Workload Federating Identity:
DeviceManagementApps.Read.All
DeviceManagementConfiguration.ReadWrite.All (ReadWrite because of this "feature")
DeviceManagementConfiguration.Read.All, but don't forget to add the parameter --ignore-omasettings when calling IntuneCD-startbackup command in the pipeline later!DeviceManagementManagedDevices.Read.All
DeviceManagementServiceConfig.Read.All
Group.Read.All
Policy.Read.All
Policy.Read.ConditionalAccess
DeviceManagementRBAC.Read.All (since 2.1.0 version)
Grant-AzureServicePrincipalPermission (part of the AzureApplicationStuff module)
Grant admin consent for all those permissions too!The pipeline is where all the magic happens. It is in fact script that defines what should happen.
To be able to create a pipeline, your repository needs to be initiated first.
Repos > Files > choose Initialize
Pipelines and create the pipeline using Create Pipeline button
Azure Repos Git
Starter pipeline
If you want to create
Markdown document describing your Intune environment, uncomment Task
Generate markdown document & commitPDF and HTML documentation reports as artifacts, uncomment also whole
PUBLISHjobBy default this pipeline will be started every day at 1 am. If you want to change that, just alter the cron key value (
cron: '0 1 * * *'). You can use https://crontab.guru to generate a new one.
At the beginning of the pipeline code, there are some variables defined that need to be set to suit your environment.
TENANT_NAME
this has to be set to match your tenant!
something like contoso.onmicrosoft.com
SERVICE_CONNECTION_NAME
Service connection name) created earlierUSER_EMAIL
you can leave it as it is
default email that will be used as commits author email, something like Intune_Backupper@contoso.com (or whatever you wish)
USER_NAME
you can leave it as it is
default username that will be used as commits author, something like Intune_Backupper (or whatever you wish)
Now when the pipeline is ready, save it by choosing Save and run . This way you will immediately see whether the pipeline is working fine 👍
After pipeline finishes, you should see that prod-backup folder was created and is filled with your Intune configuration JSON files 😍
According to the schedule, it will be automatically started by default every day at 1 a.m.
Install IntuneCD tool
Export Intune configuration backup to prod-backup folder
If a change in configuration is detected
For each changed file find who did it
Group changed files by author(s) who changed them
Commit each group separately by using the author name(s) as the commit author(s) too
Create an Intune configuration documentation file (as markdown)
Generate markdown document & commit)Create Git TAG
Generate HTML and PDF files from the Intune configuration documentation file and save them as Pipeline Artifacts
Generate markdown document & commit, job Publish as-built artifacts and add the folder md2pdf (from this repository) to your repository root)If there is no change
By default you have 1800 minutes of pipeline run per month for free. One Intune backup pipeline run takes approximately 2 minutes from this pool, so no problem here.
It is useful to be notified when the pipeline fails. For example because application secret expired etc. To do so go to Project settings > Notifications > New Subscription and select Build > A Build fails end finish the wizard.
Because backup is saved in the GIT repository, you can use commands you are familiar with (git log, git diff, git blame, etc) and don't be limited to GUI as shown below.
To get a list of all changes to the particular file. Open such file in the DevOps interface and choose History tab.
To see what has changed between two commits/conf. backups. Choose Compare tab.
Because change author name is used as commit author and in commit name itself, you can search it by several ways. In DevOps gui, you can switch to Commits > Click on Show filter button in top right corner
And type author's name to Author field.
In GIT, you can use git log command to achieve the same
To get a visual list of changes made in your Intune configuration between specified dates, go to Repos > Tags select the first Tag and Set as compare tag, then select the second one and run the comparison by Compare tags
On the result page select Files and enjoy the view 🙂
Strikethrough files are settings that were deleted. Plus sign on the right side of the file means it is a new setting that was created.
To see what your Intune environment looked like on a specific date. Go to Repos > Tags > Pick the nearest olderTag > Open the folder prod-backup and browse the content (exported JSON configuration files).
This way you will see how your Intune looked like just before the specified date.
To see what changes were made during this time, compare thisTag with the nearest newerTag.
Beware that if someone made some changes in the configuration and reverted them back before the next backup occurred, they won't be shown (obviously).
To modify what type of Intune configurations should be backed up, you must edit Create Intune backup task section in the Pipeline configuration code.
Go to Pipelines > <yourPipeline> > click Edit > Find a task with the name Create Intune backup and modify its script section by modifying the --exclude parameter.
By default, I am excluding CompliancePartner, because its data changes every day and I want new commits to be created only in case some real change happens.
When restoring the backup, you have basically two options.
Use the IntuneCD update feature
create new folder
copy just folder structure with JSON(s) you want to restore to this folder
run IntuneCD-startupdate with --path "pathToFolderWithBackup"
Manually create the required Intune configuration(s) by filling in the values shown in your backup JSON(s)
In the GIT repository, if you want to see who changed file XYZ, you check who was the author of the commit that changed such file. Therefore it was only logical to use the same approach to "save" information about who has changed the Intune configuration (JSON file).
When change is detected in the created backup (some JSON configuration file is changed) the pipeline will
Get a list of all changed files
Getting the last configuration backup commit date ($lastCommitDate)
For each changed file find out who changed it by
retrieving resource ID from its name
searching such ID in the Intune Audit log (between dates saved in $lastCommitDate and start time of this backup run) and making note of all authors that made some changes there
Group the changed files by found authors and make a commit for each group where the list of all authors that changed such files is used in the commit name and as the commit author
Put all found authors into Git Tag description too
The list of author(s) doesn't have to be 100% accurate. If you need 100% accuracy (because of security incident etc), use the command Get-MgDeviceManagementAuditEvent
The list of commit authors shows who has made any changes to committed files (since the last commit). It doesn't show who made what particular change
If a change was made by an application (instead of a user), the name of the application is used as the author name with (SP) suffix (for example Modern Workplace Management (SP))
Some Intune configuration changes aren't captured in the Intune Audit log at all! Like changes to ESP profile etc.
unknown is used insteadIntune uses several formats of IDs! Not just <GUID> as you would imagine, but for example ESP profile, Apple configurator profile , App Protection policy uses <GUID>_<GUID>, <GUID>_<somestring>,T_<GUID> and there are probably some other crazy stuff
If you finished all the required steps, you now have a working backup solution for your Intune configuration which you can easily use for tracking changes & blame the change authors 😎
Next time I will show you have to achieve the same thing for Azure configuration as well 👍