How to Clear the Windows Server Active Directory Web Services (ADWS) Cache via PowerShell

The Communication Layer

In legacy Windows Server environments, whenever a client application needed to query Active Directory (e.g., searching for a user, modifying a group), it connected directly to the Domain Controller using the raw LDAP protocol over TCP port 389. As enterprise environments modernized, direct LDAP queries became a security and networking liability across complex firewalls and cloud boundaries.

To solve this, Microsoft introduced Active Directory Web Services (ADWS). ADWS acts as a modern, XML-based gateway. When you run a PowerShell cmdlet like Get-ADUser on your Windows 11 laptop, your computer does not send a raw LDAP query. Instead, it securely connects to the ADWS service on the Domain Controller over port 9389. The ADWS service translates the PowerShell command into a backend LDAP query, retrieves the data from the NTDS.dit database, translates it back into an XML SOAP response, and sends it to your laptop.

Because translating XML SOAP responses is highly CPU-intensive, ADWS maintains a massive local cache of recent directory schemas and query results. If the underlying Active Directory schema is abruptly modified (e.g., you extend the schema for Microsoft Exchange), or if a Domain Controller experiences a replication collision, the ADWS cache becomes corrupted. When this happens, Get-ADUser commands will timeout, and modern applications relying on the Active Directory Administrative Center will refuse to load. To fix this, you must forcefully purge the ADWS cache via PowerShell.

Locating the ADWS Subsystem

ADWS is deeply integrated into the Domain Controller architecture. The cache files and XML translation definitions reside inside the C:\Windows\ADWS directory, and its memory footprint is managed by the Microsoft.ActiveDirectory.WebServices.exe process.

Purging the Cache via PowerShell

You must perform this operation directly on the affected Domain Controller using an elevated PowerShell session as an Enterprise Admin.

Step 1: Violently Terminating the Web Service

The ADWS service is incredibly resilient and locks its cache files to prevent tampering. You must stop the service to release the locks.

# Stop the Active Directory Web Services daemon
Stop-Service -Name ADWS -Force -ErrorAction SilentlyContinue

Step 2: Clearing the Temporary XML Caches

While the service is down, navigate to the ADWS temporary directory. This is where the service compiles the XML SOAP translators. Delete any corrupted temporary data.

$ADWS_Cache = "C:\Windows\ADWS\Temp"

if (Test-Path $ADWS_Cache) {
    Remove-Item -Path "$ADWS_Cache\*" -Recurse -Force -ErrorAction SilentlyContinue
    Write-Host "ADWS XML Translation cache purged." -ForegroundColor Green
}

Step 3: Flushing the DNS and LDAP Stacks

Because ADWS relies on DNS SRV records to advertise itself, and LDAP to communicate with the local database, you should flush the local resolver cache to ensure it binds to the correct internal interfaces upon restart.

Clear-DnsClientCache
ipconfig /flushdns

Step 4: Restarting the Service

Now that the corrupted translation cache is gone, you must restart the daemon.

Start-Service -Name ADWS

The Schema Reinitialization

When the Microsoft.ActiveDirectory.WebServices.exe process boots up, it will realize its temporary XML compilation folder is empty. It will immediately reach down into the local NTDS.dit database, perform a full re-read of the entire Active Directory Schema (including your new Exchange or SCCM attributes), and dynamically recompile the XML translation cache in RAM.

This process takes about 30 to 60 seconds on a large domain. During this time, the service will consume a noticeable amount of CPU. Once it finishes, the ADWS gateway will come back online. The Active Directory Administrative Center GUI will instantly load, and your remote Get-ADUser PowerShell scripts will resume executing with lightning speed, utilizing the uncorrupted schema definitions.