The Management Bottleneck
In a modern Windows Server infrastructure, best practice dictates that you do not physically log into Domain Controllers or hypervisors via Remote Desktop to manage them. Instead, you manage everything from a secure, centralized administrative workstation (or jump box) using the Remote Server Administration Tools (RSAT). RSAT includes the MMC snap-ins for Active Directory Users and Computers, DNS Manager, and DHCP Manager.
Because these snap-ins frequently query massive databases (like an Active Directory schema containing 50,000 user objects) over the network, the RSAT framework caches schema data, connection profiles, and MMC console states locally on the administrative workstation to speed up load times.
However, if this local RSAT cache becomes corrupted—perhaps due to a sudden network drop while querying a Domain Controller, or a botched Windows Update—the MMC snap-ins will fail catastrophically. The “Active Directory Users and Computers” console might crash the moment you try to expand an Organizational Unit (OU), it might refuse to connect to a perfectly healthy Domain Controller displaying a cryptic “Naming Information cannot be located” RPC error, or the MMC framework itself might lock up and consume 100% CPU. Restarting the target server will not fix this; you must forcefully clear the local RSAT cache on the workstation via PowerShell.
Locating the RSAT Caches
The RSAT caches are heavily tied to the local user profile executing the tools. They consist of temporary schema files, roaming connection data, and the specific XML files that dictate how the MMC console visually renders the snap-ins.
Purging the Cache via PowerShell
You do not need to run this script as an Administrator, but you must run it as the specific IT user account that is experiencing the crashes, as it manipulates their personal AppData.
Open PowerShell and execute the following script.
Step 1: Terminating the MMC Engine
Before you can delete the cache files, you must ensure that no hidden MMC processes are currently holding locks on the database.
Stop-Process -Name "mmc" -Force -ErrorAction SilentlyContinue
Step 2: Obliterating the Local Schema Cache
When RSAT connects to Active Directory, it downloads a temporary copy of the AD schema. This is the most common point of corruption.
$SchemaCache = "$env:LOCALAPPDATA\Microsoft\Windows\SchCache"
if (Test-Path $SchemaCache) {
Remove-Item -Path "$SchemaCache\*" -Recurse -Force
Write-Host "AD Schema Cache purged." -ForegroundColor Green
}
Step 3: Resetting the MMC Console Profiles
If the snap-in itself is refusing to open (crashing immediately upon launch), the .msc profile XML is corrupted.
$MMC_Roaming = "$env:APPDATA\Microsoft\MMC"
if (Test-Path $MMC_Roaming) {
Remove-Item -Path "$MMC_Roaming\*" -Recurse -Force
Write-Host "Roaming MMC profiles purged." -ForegroundColor Green
}
Step 4: Purging the Server Manager Cache
If you use the centralized Server Manager dashboard (which relies on RSAT underneath) and it is displaying stale data or crashing, you must wipe its specific cache.
$ServerManagerCache = "$env:LOCALAPPDATA\Microsoft_Corporation\ServerManager.exe_StrongName_*"
if (Test-Path $ServerManagerCache) {
Remove-Item -Path "$ServerManagerCache" -Recurse -Force
Write-Host "Server Manager cache purged." -ForegroundColor Green
}
The Reinitialization
The next time you launch Active Directory Users and Computers (or any RSAT tool), it will take slightly longer to open (perhaps 5 to 10 seconds). This is expected.
The MMC engine will realize its local cache has been obliterated. It will reach out over the network to the nearest Active Directory Domain Controller, perform a fresh RPC handshake, and download a completely pristine, uncorrupted copy of the AD schema. The interface will render smoothly, and the random crashes will be permanently resolved.