Hey CheckYourLogs Fans,

I’ve got a real-world troubleshooting story for you today. Recently, I encountered a Windows environment where we uninstalled the SCCM (System Center Configuration Manager) client from several servers, only to find that Windows Defender settings were still locked down as if SCCM were still managing them. The Windows Defender console showed “Some settings are managed by your organization,” even though ConfigMgr was long gone.

In other words, the system was left in a “tattooed” state – SCCM’s client policies (like Defender AV exclusions and update settings) had etched themselves into the machine and persisted after the agent’s removal.

In this post, I’ll walk you through why this happens, how Group Policy processing order plays a role (SCCM vs local vs domain policies), and how clearing the Group Policy cache on the affected Windows systems fixed the issue. By the end, you’ll know precisely why tattooed policies occur and how to scrub them clean using simple commands. Let’s dive in.

What’s a “Tattooed” Policy State?

In Group Policy terms, tattooing refers to policy settings that remain in effect even after the policy is no longer supposed to apply. True Group Policy settings are normally removed automatically when a GPO falls out of scope. However, not all configurations get cleaned up, especially if they were set via local policies or the policy engine believes they’re still in force.

In our case, SCCM had configured specific Windows Defender settings on the client. When we removed the SCCM agent, those settings didn’t vanish. They stayed tattooed in the registry. The result? Windows still behaved as if SCCM was managing Defender.

Common signs of tattooed SCCM settings include:

  • The Windows Defender Security Center shows “Some settings are managed by your organization.”
  • Defender configurations (like exclusions or update sources) remain enforced.
  • In Local Group Policy Editor (gpedit.msc), specific Defender Antivirus settings appear as Enabled/Disabled instead of “Not Configured.”

How SCCM Applies Policies

SCCM does not use Active Directory Group Policy when it manages settings like Windows Defender Antivirus. Instead, the SCCM client applies those settings locally on each machine, writing them into the same places Group Policy would—typically into the registry under the Local Policy sections.

You can see this in:

  • Registry Editor: Under HKLM\SOFTWARE\Policies\Microsoft\Windows Defender\…
  • Local Group Policy Editor: Navigate to Computer Configuration > Administrative Templates > Windows Components > Windows Defender Antivirus to see settings that reflect SCCM policy.

SCCM’s client essentially acts as a local policy engine, embedding its settings directly into the system.

Here’s the twist: once SCCM sets those configurations, they become indistinguishable from manually configured Local Group Policy settings. Those settings will stick around if you remove the SCCM client without cleaning it up.

Group Policy Processing Order

Let’s go over the policy processing order in Windows. Understanding the hierarchy helps clarify why SCCM tattooing is such an issue:

  1. SCCM Client Settings (Local Policy)
  2. Local Group Policy
  3. Site-level Group Policy
  4. Domain-level Group Policy
  5. OU-level Group Policy

Windows applies policies in this sequence, with later layers overriding earlier ones.

So, if SCCM applies a Defender exclusion list via local policy, and no domain GPO exists to override it, that setting sticks indefinitely—even after SCCM is removed. It becomes a ghost in the machine.

Why Do SCCM Client Settings Persist?

You might assume that uninstalling SCCM would clean up its policies. Unfortunately, that’s not how it works.

SCCM often writes settings directly into the registry; the uninstaller does not roll them back. Whether it’s a Defender AV exclusion, Windows Update settings, or cloud-delivered protection flags—once it’s there, it stays until something explicitly clears it.

This design is intentional to ensure settings remain consistent, but if you abandon SCCM without fully transitioning management, you’ll likely deal with tattooed policies.

Verifying Tattooed Settings via Local Group Policy Editor

To confirm whether a system is in a tattooed state:

  1. Open Local Group Policy Editor:
    Press Win + R, type gpedit.msc, press Enter.
  2. Navigate to Defender Policies:
    Computer Configuration > Administrative Templates > Windows Components > Windows Defender Antivirus
  3. Review Settings:
    Settings that should say “Not Configured” will say “Enabled” or “Disabled” if tattooed.

This behavior typically indicates that SCCM client policies are still in effect.

Why Clearing the Group Policy Cache Fixes It

Now for the good part—the fix.

Instead of digging through the registry or flipping each setting in gpedit, you can wipe the local Group Policy configuration entirely and rebuild from scratch. This removes all tattooed entries and resets the local policy to the default.

This fix is especially effective when:

  • SCCM is no longer installed.
  • You are moving to Intune or another management solution.
  • You want to reset the Defender to the default settings.

The local Group Policy configuration lives in these folders:

  • %windir%\System32\GroupPolicy
  • %windir%\System32\GroupPolicyUsers

Delete those, and you nuke the local GPO state. After that, Windows reverts to the default unless a Domain GPO applies.

How to Clear the Local Group Policy Cache

Here’s the exact process:

  1. Open an Elevated Command Prompt:
    Start > Search cmd > Right-click > Run as Administrator
  2. Run These Commands:

 

rmdir /S /Q %windir%\System32\GroupPolicy

rmdir /S /Q %windir%\System32\GroupPolicyUsers

gpupdate /force

Alternatively, reboot the machine to force the policy engine to reload a fresh set.

What Happens After the Reset?

Once you’ve cleared the policy cache and refreshed:

  • The gpedit.msc console shows all settings as “Not Configured.”
  • Windows Defender updates settings from defaults or the next management layer.
  • The “Managed by your organization” warning disappears.
  • AV definitions download from Windows Update again.
  • Any exclusions or configuration applied via SCCM vanish.

You can reapply management via domain GPO or Intune or leave it unmanaged based on your environment.

Scriptable Fix

This process is easily scripted for bulk operations. Example PowerShell one-liner:

Remove-Item -Recurse -Force "$env:windir\System32\GroupPolicy","$env:windir\System32\GroupPolicyUsers"; gpupdate /force

Use responsibly and always test in dev/staging before applying to production systems.

Lessons Learned

This scenario is an excellent reminder of the importance of a clean separation between management platforms. If you’re transitioning from SCCM to Intune or simply decommissioning SCCM clients, be aware of the potential for lingering policies.

Tattooed settings are sneaky. They look and act like policies but no longer have a managing source. That’s when problems begin. Defender settings don’t update, users can’t manage exclusions, and update sources get stuck.

Understanding the Group Policy hierarchy and how SCCM fits into it allows you to undo old settings and restore proper configuration cleanly.

Summary

Problem:
The SCCM client was uninstalled, but the Defender AV settings remained “tattooed” on the system.

Cause:
SCCM applied policy via Local Group Policy. Without a domain GPO to override it, the settings stayed in effect after uninstall.

Fix:
Clear the Local Group Policy cache using:

rmdir /S /Q %windir%\System32\GroupPolicy

rmdir /S /Q %windir%\System32\GroupPolicyUsers

gpupdate /force

Result:
The system resets to the default policy state, removing SCCM’s leftover configurations. Defender and Windows Update work as expected.

That’s it for this one, folks. Hopefully, this saves you a headache the next time you fight phantom policies. Until next time—keep those systems clean, and always CheckYourLogs!

—Dave Kawula
Senior Solutions Architect | Microsoft MVP | Infrastructure Guru