PART 1 OF 2 

Configuration Drift Management in Microsoft Intune

A practical guide to detecting and managing configuration drift using PowerShell, Power Automate, Graph API, Intune Remediations, and free community tools. No expensive third-party tools or additional licensing required.

Audience: Intermediate IT Pros  ·  Prerequisites: Microsoft Intune, Entra ID, basic PowerShell

If you’ve been managing devices with Microsoft Intune for any meaningful length of time, you’ll already know the feeling. You spend weeks getting your compliance policies, configuration profiles, and app assignments tuned to perfection. Everything is green in the dashboard. You declare victory.

Then, three months later, someone opens a ticket. A device is suddenly non-compliant. A security baseline has silently drifted. A profile conflict has crept in. Somehow, between your triumphant ‘we’re done here’ moment and right now, your carefully configured fleet has developed opinions of its own. Welcome to configuration drift.

This is Part 1 of a two-part series. Here we’ll cover the practical, mostly free approaches available to IT Pros managing drift with Intune tooling — PowerShell, Power Automate, Graph API, Intune’s own built-in features and a selection of free community tools that do a lot of the heavy lifting for you. These are not workarounds or stopgaps — they are genuinely capable approaches that many mature Intune environments rely on. Then in Part 2 I’ll cover my experience with Microsoft’s Unified Tenant Configuration Management (UTCM), the emerging Microsoft native answer to this problem.

Let’s get into it.

Understanding the Problem Space

Configuration drift in an Intune context can show up in a few distinct ways, and it’s worth being precise about each, that’s because the right detection method depends on what kind of drift you’re actually dealing with.

• Policy non-compliance – A device that was previously compliant is no longer meeting one or more compliance policy requirements. The device is still enrolled and receiving policies, but its state has diverged.
• Profile drift – A configuration profile is assigned and reporting as Succeeded in Intune, yet the underlying setting on the device doesn’t match the intended value. This is more common than people realise, especially with CSP-based policies.
• Remediation regression – You fixed a problem on a device. The fix didn’t stick. Common with settings that apps or Windows Update can overwrite post-boot.
• Orphaned assignments – Devices or users moved between groups, re-enrolled, or with changed licensing, leaving them with stale or missing policy assignments.
• Baseline gaps – New devices enrolled into your tenant that haven’t fully received their intended policy stack yet, often because of sync timing or group membership delays.

The Graph API Endpoints You’ll Use

The Microsoft Graph API is your primary source of truth for device and policy state in Intune. These are the endpoints you’ll come back to throughout this guide:

The key property to monitor on each device is complianceState on the managedDevice resource. Possible values are: compliant, noncompliant, unknown, notApplicable, inGracePeriod, and error. Anything that isn’t compliant or notApplicable should be on your radar.

The Classic Hammer

PowerShell is the natural starting point for most IT pros. It’s familiar, flexible, doesn’t require additional licensing, and you can build something genuinely useful in an afternoon. The Microsoft.Graph PowerShell SDK provides cmdlets that wrap the Graph API — use the newer Microsoft.Graph SDK, not the old AzureAD module.

What You’ll Need

A Practical Drift Detection Script

The script below connects to Graph, retrieves all managed devices, and flags those with non-compliant or unknown states. It outputs to both the console and a CSV for review:

# Summary line
Write-Host ("  ⚠  {0} drifted device(s) out of {1} total  ({2:0.0}%)" -f `
    $Report.Count, $Devices.Count, (($Report.Count / $Devices.Count) * 100)) `
    -ForegroundColor Yellow
Write-Host ""

# Column widths — dynamic, based on actual data, capped for readability
$colW = @{
    DeviceName = [Math]::Min(30, ($Report | Measure-Object { $_.DeviceName.Length } -Maximum).Maximum + 2)
    UPN        = [Math]::Min(36, ($Report | Measure-Object { $_.UPN.Length }        -Maximum).Maximum + 2)
    State      = 18
    OS         = 10
    DaysSync   = 12
}

# Header row
$header = "  {0,-$($colW.DeviceName)}{1,-$($colW.UPN)}{2,-$($colW.State)}{3,-$($colW.OS)}{4,-$($colW.DaysSync)}" `
    -f 'Device Name', 'User', 'State', 'OS', 'Days Since Sync'
$divider = "  " + ("─" * ($colW.DeviceName + $colW.UPN + $colW.State + $colW.OS + $colW.DaysSync))

Write-Host $header    -ForegroundColor White
Write-Host $divider   -ForegroundColor DarkGray

# Data rows — colour by state
foreach ($Device in $Report | Sort-Object State, DeviceName) {
    $stateColor = switch ($Device.State) {
        'noncompliant'  { 'Red'    }
        'error'         { 'Red'    }
        'unknown'       { 'Yellow' }
        'inGracePeriod' { 'Cyan'   }
        default         { 'White'  }
    }

    $row = "  {0,-$($colW.DeviceName)}{1,-$($colW.UPN)}{2,-$($colW.State)}{3,-$($colW.OS)}{4,-$($colW.DaysSync)}" `
        -f `
        ($Device.DeviceName   | Select-Object -First 1),
        ($Device.UPN          | Select-Object -First 1),
        $Device.State,
        $Device.OS,
        $Device.DaysSinceSync

    Write-Host $row -ForegroundColor $stateColor
}

Write-Host $divider -ForegroundColor DarkGray
Write-Host ""

# State breakdown
Write-Host "  Breakdown by state:" -ForegroundColor White
$Report | Group-Object State | Sort-Object Count -Descending | ForEach-Object {
    Write-Host ("    {0,-20} {1} device(s)" -f $_.Name, $_.Count) -ForegroundColor Gray
}

Drilling Deeper: Per-Policy States

Device-level compliance state tells you that a device has drifted, but not which policy or setting caused it. For that, query the deviceConfigurationStates endpoint per device

Option B — use the device name as shown in Intune:
    .\Get-DevicePolicyDrift.ps1 -DeviceName "DESKTOP-ABC123"

Option C — run the script with no parameters and it will prompt you.
    Paste either the DeviceId or DeviceName when asked.
    The script will detect which you've entered automatically.

# Heuristic: GUIDs are 36 chars with hyphens — treat everything else as a name
if ($Input -match '^[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}$') {
    $DeviceId = $Input
} else {
    $DeviceName = $Input
}

    $Lookup = $Response.value

    if ($Lookup.Count -eq 0) {
        Write-Host "  [XX] No device found with name '$DeviceName'." -ForegroundColor Red
        Write-Info "Check the name matches exactly as shown in Intune (case-sensitive)."
        Write-Info "Alternatively, use the DeviceId from the DriftReport CSV."
        Disconnect-MgGraph
        Read-Host "  Press Enter to close"
        exit 1
    }

    if ($Lookup.Count -gt 1) {
        Write-Warn "Multiple devices found with that name — picking the first match."
        Write-Info "If this is wrong, re-run using -DeviceId from the CSV instead."
    }

    $Found    = $Lookup[0]
    $DeviceId = $Found.id
    $Device   = [PSCustomObject]@{
        DeviceName        = $Found.deviceName
        UserPrincipalName = $Found.userPrincipalName
        ComplianceState   = $Found.complianceState
        OperatingSystem   = $Found.operatingSystem
    }
    Write-Ok "Device resolved: $($Device.DeviceName) → $DeviceId"

} catch {
    Write-Host "  [XX] Name lookup failed: $_" -ForegroundColor Red
    Disconnect-MgGraph
    Read-Host "  Press Enter to close"
    exit 1
}

    $Device = [PSCustomObject]@{
        DeviceName        = $Found.deviceName
        UserPrincipalName = $Found.userPrincipalName
        ComplianceState   = $Found.complianceState
        OperatingSystem   = $Found.operatingSystem
    }
} catch {
    Write-Host "  [XX] Device ID not found. Check the ID is correct and belongs to this tenant." -ForegroundColor Red
    Disconnect-MgGraph
    Read-Host "  Press Enter to close"
    exit 1
}

$AllStates = $Response.value
Write-Ok "Total policies assigned to this device: $($AllStates.Count)"

Write-Host ("  ⚠  {0} policy/policies with issues found  ({1} total assigned)" -f `
    $ProblemStates.Count, $AllStates.Count) -ForegroundColor Yellow
Write-Host ""

# ── Conflicts first — these are the important ones ────────────────────
$Conflicts = $ProblemStates | Where-Object { $_.conflictCount -gt 0 }
if ($Conflicts.Count -gt 0) {
    Write-Host "  CONFLICTS  (two or more policies fighting over the same setting)" `
        -ForegroundColor Red
    Write-Host "  ─────────────────────────────────────────────────────────────────" `
        -ForegroundColor DarkGray
    foreach ($Item in $Conflicts | Sort-Object conflictCount -Descending) {
        Write-Host ("  ❌  {0}" -f $Item.displayName) -ForegroundColor Red
        Write-Host ("      State: {0}   Conflicts: {1}   Errors: {2}" -f `
            $Item.state, $Item.conflictCount, $Item.errorCount) -ForegroundColor DarkRed
    }
    Write-Host ""
    Write-Warn "Conflicts are not fixed by a device sync — they need a policy review."
    Write-Info "Go to Intune > Devices > [this device] > Configuration to see which"
    Write-Info "policies overlap and which setting is being contested."
    Write-Host ""
}

# ── Errors ────────────────────────────────────────────────────────────
$Errors = $ProblemStates | Where-Object { $_.state -eq 'error' -and $_.conflictCount -eq 0 }
if ($Errors.Count -gt 0) {
    Write-Host "  ERRORS  (policy failed to apply)" -ForegroundColor Red
    Write-Host "  ─────────────────────────────────────────────────────────────────" `
        -ForegroundColor DarkGray
    foreach ($Item in $Errors) {
        Write-Host ("  ❌  {0}" -f $Item.displayName) -ForegroundColor Red
        Write-Host ("      State: {0}   Errors: {1}" -f $Item.state, $Item.errorCount) `
            -ForegroundColor DarkRed
    }
    Write-Host ""
}

# ── Non-compliant (no conflict, no error) ────────────────────────────
$NonCompliant = $ProblemStates | Where-Object {
    $_.state -eq 'nonCompliant' -and $_.conflictCount -eq 0
}
if ($NonCompliant.Count -gt 0) {
    Write-Host "  NON-COMPLIANT  (settings don't match policy requirements)" `
        -ForegroundColor Yellow
    Write-Host "  ─────────────────────────────────────────────────────────────────" `
        -ForegroundColor DarkGray
    foreach ($Item in $NonCompliant) {
        Write-Host ("  ⚠  {0}" -f $Item.displayName) -ForegroundColor Yellow
        Write-Host ("      State: {0}   Settings checked: {1}" -f `
            $Item.state, $Item.settingCount) -ForegroundColor DarkYellow
    }
    Write-Host ""
}

# ── Everything else (unknown, inGracePeriod, etc.) ───────────────────
$Other = $ProblemStates | Where-Object {
    $_.state -notin @('nonCompliant', 'error') -and $_.conflictCount -eq 0
}
if ($Other.Count -gt 0) {
    Write-Host "  OTHER STATES" -ForegroundColor Gray
    Write-Host "  ─────────────────────────────────────────────────────────────────" `
        -ForegroundColor DarkGray
    foreach ($Item in $Other) {
        Write-Host ("  •  {0}  [{1}]" -f $Item.displayName, $Item.state) -ForegroundColor Gray
    }
    Write-Host ""
}

The ConflictCount property is particularly useful — a conflict means two or more policies are fighting over the same setting and the device is caught in the middle. This is one of the most common real-world drift causes and one of the most annoying to diagnose manually in the portal.

Pros and Cons

Letting the Robots Handle It

Power Automate elevates drift detection from a script you remember to run into a workflow that runs itself. But its value goes well beyond simply scheduling a compliance poll. With the HTTP connector and Graph API, you can build a complete configuration monitoring pipeline: extract your entire policy configuration as a JSON baseline, store it, compare it on a schedule, and get notified the moment something changes — covering compliance policies, configuration profiles, and Conditional Access policies in a single automated flow.

This section covers two complementary flows: a device-level compliance drift checker, and the more powerful tenant-configuration baseline comparison workflow.

What You’ll Need

A Scheduled Drift Detection Flow

Here’s the logical structure for a scheduled drift checker. The key stages are:

1. Trigger: Recurrence — daily at 06:00 UTC (before the helpdesk opens)
2. Action: HTTP POST to https://login.microsoftonline.com/{tenantId}/oauth2/v2.0/token to get a bearer token
3. Action: HTTP GET to the Graph endpoint below, server-side filtered to non-compliant devices only
4. Condition: if the array is empty, send an ‘all clear’ notification and exit; if not, proceed
5. Apply to Each: loop through drifted devices, create a SharePoint list item for each with device name, state, last sync, and timestamp
6. Action: Post Teams Adaptive Card to your IT ops channel with a count summary and list of affected devices
7. Condition: if drift count exceeds a threshold (e.g. 10), send an escalation email to your IT manager

The OData filter in step 3 does the heavy lifting — rather than downloading all devices and filtering locally, we ask Graph to do it server-side:

Flow B: Tenant Configuration Baseline Capture

The flow makes three Graph API calls to capture the full configuration picture: compliance policies with their assignment groups, configuration profiles with assignments, and Conditional Access policies. Each response is serialised to JSON and stored as a versioned file in SharePoint:

1. Trigger: Manual trigger (Button) — run this deliberately when you want to establish or update a baseline
2. Action: HTTP GET to fetch all compliance policies with assignments:

• Action: Compose to build a single JSON object combining all four responses with a capturedAt timestamp:

• Action: SharePoint Create File — save to your baselines document library as baseline_YYYYMMDD_HHMMSS.json. Use the dynamic timestamp in the filename to version each capture.
• Action: Post Teams message confirming the baseline was captured, with counts of each policy type included.

Flow C: Scheduled Baseline Comparison (Drift Detection)

This is where the value compounds. This scheduled flow runs daily, captures a fresh snapshot of your current tenant configuration, then compares it against your stored baseline JSON. Any differences — a deleted profile, a changed CA policy, a modified assignment group — surface as drift records:

• Trigger: Recurrence — daily at 07:00 UTC
• Actions: Same three HTTP GET calls as Flow B to capture current state
• Action: SharePoint Get File Content — retrieve your most recent baseline JSON from the SharePoint library
• Action: Parse JSON on both the baseline and current snapshot using the same schema
• Apply to Each (compliance policies): compare each policy in the baseline against current. Flag if: policy is missing from current, assignment groups have changed, or lastModifiedDateTime has changed since baseline
• Apply to Each (CA policies): compare each CA policy. Flag if: policy was deleted, state changed (enabled → disabled or vice versa), conditions changed, or grant controls modified
• Condition: if any drift items were found, create a SharePoint list entry per drift item and post a Teams Adaptive Card detailing what changed
• Condition: if CA policy drift was detected, send a priority email — CA changes have immediate security implications

Adding Automated Remediation Triggers

Power Automate can also initiate remediation — not just detect drift. The most straightforward action is triggering a device sync for devices showing compliance drift:

Pros and Cons

Best of Both Worlds

PowerShell is great at data collection and complex logic. Power Automate is great at scheduling, notifications, and workflow orchestration. They’re not in competition — they’re complements. Combining PowerShell runbooks in Azure Automation with Power Automate as the orchestration layer gives you raw capability plus operational convenience.

The Architecture

• Azure Automation Account — hosts PowerShell runbooks that do the heavy lifting: Graph API queries, complex filtering, baseline comparisons, CSV generation. Managed Identity support means no client secret to rotate.
• Power Automate — acts as the orchestrator and notification layer. Triggers the Automation runbook on a schedule, waits for completion, routes alerts based on results.
• Azure Storage Account (optional) — Automation runbooks write CSV reports to blob storage; the Power Automate flow generates a SAS URL and includes it in the Teams notification for easy download.

Granting Graph Permissions to Azure Automation

The step that trips most people up: you can’t toggle Graph permissions for a managed identity in the Entra portal. You have to use PowerShell:

Pros and Cons

Full Control Over What You Monitor

This approach requires real development effort, not just scripting. But for organisations that want policy-level drift detection — ‘has anyone changed an assignment?’ or ‘has a compliance policy setting been modified?’ or ‘was a Conditional Access policy disabled?’ — building a lightweight baseline comparison engine against the Graph API is entirely achievable. It gives you complete control which is different to UTCM, it works today without additional licensing, and covers exactly the configuration dimensions that matter to your organisation.

Three Components

• Baseline Snapshot — a scheduled process that calls Graph API to capture intended state: all policy assignments, configuration profiles, compliance policy requirements. Stored as JSON in Azure Table Storage or similar.
• Current State Collector — runs on a schedule to capture actual policy state from your tenant.
• Diff Engine — compares snapshot against current state and generates a delta report: what changed, what is missing, what is in conflict.

Capturing a Baseline Snapshot

The snapshot should cover the full breadth of what you care about. The example below captures configuration profiles, compliance policies, Settings Catalog policies, and Conditional Access policies in a single pass:

Comparing Baselines

The comparison function checks three types of drift: deleted resources, changed assignments, and modified policy settings (detected via the lastModifiedDateTime timestamp). Conditional Access policies additionally check for state changes (enabled/disabled):

Pros and Cons

The Underused Feature

Before going further down the custom-build path, it’s worth spotlighting a native Intune feature that many IT pros overlook: Remediations (previously called Proactive Remediations before the 2023 rename). This is Intune’s built-in mechanism for detect-and-fix scripting, and it’s genuinely excellent for specific drift scenarios.

Remediations work by deploying two PowerShell scripts to devices. The detection script exits with code 0 if everything is fine, or code 1 if a problem is detected. The remediation script runs only if the detection exits with code 1, makes the fix, and exits 0 on success. This is the closest thing to real-time, device-level drift correction that Intune provides natively.

A Practical Example — Windows Firewall

Licence Requirements

Pros and Cons

When to exhaust all the above options there is naturally one more route you could take: The Community tools path – The Intune community has been active producing great tools for some time including helpful and automated ways to achieve ways of backup, restore and with some, reporting for drift. While these options are will save you a bunch of time an effort they wont help you learn the under the hood fundamentals for how drift management works. You can check the following tools out.

Microsoft 365 DSC

The heavyweight in this space. It’s an open-source initiative hosted on GitHub, led by Microsoft engineers and maintained by the community, designed to automate change management by maintaining a single declarative configuration file across all Microsoft 365 workloads. (https://blog.admindroid.com/automate-microsoft-365-settings-with-microsoft365dsc/#How-to-Install-Microsoft365DSC-Module%3F)

IntuneCD (Tobias Almén — Microsoft MVP)

The most sophisticated GitOps approach. IntuneCD is a Python package designed to back up Intune configurations to a Git repository from a DEV environment and automatically detect any alterations and propagate approved changes to the PROD Intune environment. (https://github.com/almenscorner/IntuneCD)

IntuneAutomate (PowerApps & Power Automate)

IntuneAutomate – Developed by myself, Andy Jones this FREE community tool looks to maximise the use of peoples existing Microsoft investments and uses a Power App and Power Automate solution which includes drift management as one of the key tasks. This tool is soon to be released to the community and you can pre-register for the tool here (https://kumonix.com/intuneautomate-power-app).

TenuVault

Ugur Koc’s Drift-Relevant Tool TenuVault is his most directly relevant tool here. It continuously monitors your Intune environment for unauthorized or unexpected changes, using a backup-as-baseline model GitHub: ugurkocde/TenuVault

IntuneBackupAndRestore (John Seerden)

A PowerShell module that queries Microsoft Graph and allows for cross-tenant backup and restore of Intune configuration, storing everything as JSON files. It includes Compare-IntuneBackupDirectories to compare two backup sets and identify what changed between them. GitHub: jseerden/IntuneBackupAndRestore

Decision Framework

None of the approaches here are mutually exclusive. In fact, a mature drift management strategy typically combines several. But if you need a starting point, here’s a practical approach you may want to take:

Security Considerations Across All Approaches

• Least privilege: App registrations and managed identities should have only the Graph API permissions they need. Read-only reporting needs DeviceManagementManagedDevices.Read.All. Add ReadWrite permissions only for remediation actions — and document the justification.
• Secret rotation: If using client secrets (not recommended for production), set calendar reminders for rotation before expiry. Drift detection pipelines that go silent because a secret expired are an embarrassingly common issue.
• Managed Identity first: Where Azure Automation is involved, use system-assigned or user-assigned managed identities instead of client credentials. No secret to manage, no secret to leak.
• Audit everything: Enable Entra ID audit logging for your app registrations. All Graph API calls made under your app’s credentials are logged — when something unexpected happens, you want that trail.

Configuration drift is one of those problems that feels manageable right up until it isn’t. The good news is that Intune provides a genuinely rich set of APIs for monitoring and remediating device state, and the tooling available to IT pros — PowerShell, Power Automate, Azure Automation, Remediations, and a well-developed free community ecosystem — gives you multiple credible paths to getting drift under control without a significant licensing conversation.

The honest picture is that all of the approaches here require you to do the work, own the maintenance, and stay on top of API changes. That’s not a knock on any of the tools — it’s the reality of building your own management plane. The Power Automate baseline comparison flows and the DIY snapshot engine in particular are genuinely capable at detecting tenant configuration drift, including the high-value scenarios like Conditional Access policy changes. They’re not workarounds; for many organisations they’re exactly the right tool.

Which brings us neatly to the second blog in the series – Part 2.

Microsoft has built UTCM or Unified Tenant Configuration Management service (Currently in public preview -March 2026). This will be Microsoft’s native answer to exactly this problem. In Part 2, we’ll look at what UTCM actually does, how it compares to everything here, the real-world licensing picture, and importantly: what UTCM can actually monitor today vs. what the documentation suggests it can monitor (in my own testing experience in March 2026). Those two lists are not the same — and understanding the difference is the difference between a smooth setup and an afternoon of confusing errors.

Make sure to look out for the next blog post…….

Technical References

Microsoft Graph API — Intune Overview — https://learn.microsoft.com/en-us/graph/api/resources/intune-graph-overview

Microsoft.Graph PowerShell SDK — https://learn.microsoft.com/en-us/powershell/microsoftgraph/overview

Intune Managed Device resource (Graph API) — https://learn.microsoft.com/en-us/graph/api/resources/intune-devices-manageddevice

deviceConfigurationState resource type — https://learn.microsoft.com/en-us/graph/api/resources/intune-deviceconfig-deviceconfigurationstate

Remediations in Intune — https://learn.microsoft.com/en-us/mem/intune/fundamentals/remediations

Azure Automation Overview — https://learn.microsoft.com/en-us/azure/automation/overview

Power Automate HTTP Connector — https://learn.microsoft.com/en-us/connectors/webcontents/

OData query parameters in Graph API — https://learn.microsoft.com/en-us/graph/query-parameters

Managed Identities for Azure Automation — https://learn.microsoft.com/en-us/azure/automation/automation-security-overview