How to Fix Intune Policy Tattooing When Deleted Settings Persist

Start by capturing SyncML traces to identify missing Delete commands. Open Command Prompt as administrator and run the MDM Diagnostics Tool to generate traces.

mdmdiagnosticstool.exe -out C:\temp\mdm_trace.etl

While the trace is running, force a device sync from the Intune admin center. Navigate to Devices > All devices, select your device, and click Sync. Wait for the sync to complete (usually 2-3 minutes).

Stop the trace by pressing Ctrl+C, then convert the ETL file to XML for analysis:

mdmdiagnosticstool.exe -xml C:\temp\mdm_trace.etl

Open the generated XML file and search for your policy's URI. Look for Add, Replace, or Get commands but note any missing Delete commands for settings that should have been removed.

Open Event Viewer and navigate to the MDM policy logs to confirm missing delete operations. Press Win+R, type eventvwr.msc, and press Enter.

Navigate to: Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin

Look for Event ID 819 with the description "MDM PolicyManager: Delete Policy". The absence of these events for your removed policies confirms tattooing.

# PowerShell command to search for Event ID 819
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'; ID=819} -MaxEvents 50 | Format-Table TimeCreated, Id, LevelDisplayName, Message -Wrap

Also check for Event ID 818 (Add Policy) and 820 (Replace Policy) to see what operations are occurring versus what should be happening.

Check the Windows registry to identify which policies are still enforced despite being removed from Intune. Open Registry Editor as administrator by pressing Win+R, typing regedit, and pressing Enter.

Navigate to the main policy locations:

HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\current\device\[CSP_Name]
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\[Application_Name]

For example, to check Edge policies that should have been removed:

HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Edge

Document any keys that exist for policies you've removed from Intune. Take screenshots or export the registry keys for comparison after remediation:

# Export registry key to file for comparison
reg export "HKLM\Software\Policies\Microsoft\Edge" C:\temp\edge_policies_before.reg

Also check the PolicyManager location for CSP-specific settings:

HKEY_LOCAL_MACHINE\Software\Microsoft\PolicyManager\current\device\settings

Log into the Microsoft Intune admin center and check for invalid assignment filters that may be blocking the deletion pipeline. Navigate to Tenant administration > Filters to review all existing filters.

Next, examine each configuration profile that previously had the tattooed settings. Go to Devices > Configuration profiles and select each relevant profile.

Click on Assignments for each profile and look for any filters that show as "Invalid" or reference deleted filter names. This is a common cause of tenant-wide tattooing issues.

# PowerShell script to check assignment filters via Graph API
$tenantId = "your-tenant-id"
$clientId = "your-app-id"
$clientSecret = "your-secret"

# Get access token
$body = @{
    grant_type = "client_credentials"
    client_id = $clientId
    client_secret = $clientSecret
    scope = "https://graph.microsoft.com/.default"
}

$tokenResponse = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method Post -Body $body
$headers = @{Authorization = "Bearer $($tokenResponse.access_token)"}

# Get all device configuration profiles
$profiles = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations" -Headers $headers

# Check assignments for each profile
foreach ($profile in $profiles.value) {
    $assignments = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations/$($profile.id)/assignments" -Headers $headers
    Write-Host "Profile: $($profile.displayName)"
    foreach ($assignment in $assignments.value) {
        if ($assignment.target.deviceAndAppManagementAssignmentFilterId) {
            Write-Host "  Filter ID: $($assignment.target.deviceAndAppManagementAssignmentFilterId)"
        }
    }
}

Look for profiles that reference non-existent filter IDs or show assignment errors in the admin center.

Resolve invalid assignment filters to restore the deletion pipeline. In the Intune admin center, navigate to the configuration profile with the invalid filter assignment.

Click on Assignments, then click Edit next to the assignment group that has the invalid filter. In the filter dropdown, select a valid existing filter or choose (None) to remove the filter requirement.

Click Review + save to apply the changes. This should immediately restore the ability for Intune to send Delete commands to devices.

If you need to create a new filter to replace the invalid one:

1. Go to Tenant administration > Filters
2. Click Create and select Managed devices
3. Provide a name and description
4. Build your filter rule using the rule builder
5. Click Create

Return to your configuration profile assignments and select the new filter. Here's a PowerShell example to update assignments via Graph API:

# Update assignment filter for a configuration profile
$profileId = "your-profile-id"
$assignmentId = "your-assignment-id"
$newFilterId = "your-new-filter-id"

$updateBody = @{
    target = @{
        "@odata.type" = "#microsoft.graph.groupAssignmentTarget"
        groupId = "your-group-id"
        deviceAndAppManagementAssignmentFilterId = $newFilterId
        deviceAndAppManagementAssignmentFilterType = "include"
    }
} | ConvertTo-Json -Depth 3

Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/deviceManagement/deviceConfigurations/$profileId/assignments/$assignmentId" -Method Patch -Body $updateBody -Headers $headers -ContentType "application/json"

After fixing the assignment filters, force a device sync to trigger the Delete commands. In the Intune admin center, go to Devices > All devices, select your affected device, and click Sync.

While the sync is processing, start a new SyncML trace to monitor for Delete commands:

mdmdiagnosticstool.exe -out C:\temp\mdm_trace_after_fix.etl

Wait for the sync to complete (usually 2-3 minutes), then stop the trace and convert to XML:

mdmdiagnosticstool.exe -xml C:\temp\mdm_trace_after_fix.etl

Open the XML file and search for Delete commands for your previously tattooed policies. You should now see entries like:

<Data Name="RequestData"><![CDATA[<Delete><CmdID>2</CmdID><Item><Target><LocURI>./Device/Vendor/MSFT/Policy/Config/YourCSP/YourSetting</LocURI></Target></Item></Delete>]]></Data>

Simultaneously monitor Event Viewer for Event ID 819 (Delete Policy) entries:

# Monitor for new delete events in real-time
Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'; ID=819; StartTime=(Get-Date).AddMinutes(-10)} | Format-Table TimeCreated, Message -Wrap

Some Configuration Service Providers (CSPs) require special handling even after Delete commands are sent. For CSPs like RemovableStorageAccess or certain BitLocker settings, manual intervention may be needed.

First, identify which CSP is causing persistent tattooing by checking the registry location:

# Check for persistent CSP settings
Get-ChildItem "HKLM:\Software\Microsoft\PolicyManager\current\device" -Recurse | Where-Object {$_.Name -like "*RemovableStorage*" -or $_.Name -like "*BitLocker*"}

For RemovableStorageAccess CSP tattooing, you may need to manually set the registry value before deletion:

# Temporarily enable the setting in registry
Set-ItemProperty -Path "HKLM:\Software\Microsoft\PolicyManager\current\device\RemovableStorageAccess" -Name "RemovableStorageAccess_Deny" -Value 1

Then create a new Intune policy with the opposite setting (Enabled instead of Disabled), assign it to the device, wait for it to apply, and then delete the old policy. This forces the CSP to properly process the removal.

For stubborn policies, use the "replacement method":

1. Create a new configuration profile with the desired end state
2. Assign the new profile to affected devices
3. Wait for the new profile to apply and verify it works
4. Delete the old problematic profile
5. After 24 hours, delete the temporary new profile if no longer needed

Perform comprehensive verification to ensure the tattooing issue is fully resolved. Start by checking the registry locations you documented earlier:

# Compare registry state before and after
reg export "HKLM\Software\Policies\Microsoft\Edge" C:\temp\edge_policies_after.reg

# Compare the before and after files
fc C:\temp\edge_policies_before.reg C:\temp\edge_policies_after.reg

Check that the problematic registry keys are now absent:

# Verify specific policy keys are removed
$policyPaths = @(
    "HKLM:\Software\Policies\Microsoft\Edge",
    "HKLM:\Software\Microsoft\PolicyManager\current\device\settings"
)

foreach ($path in $policyPaths) {
    if (Test-Path $path) {
        Write-Host "Checking $path:"
        Get-ChildItem $path -Recurse | Select-Object Name, Property
    } else {
        Write-Host "Path $path does not exist (good - policy removed)"
    }
}

Verify that the actual policy enforcement has stopped by testing the previously enforced settings. For example, if you removed a browser policy, check that users can now access previously blocked sites or change previously locked settings.

Run a final SyncML trace to confirm ongoing Delete commands are not being sent (indicating the policy is fully removed):

mdmdiagnosticstool.exe -out C:\temp\final_verification.etl

After capturing a sync cycle, convert and check that no Add/Replace commands exist for your removed policies.