Recently, two of the network administrators at my firm ran into an issue with with the Active Directory Users and Computers MMC snap-in. ADUC often loaded slowly. Sometimes rebooting would fix the issue, sometimes it wouldn’t. I never had an issue but I didn’t use ADUC as often on my workstation (I use it primarily on the DCs themselves) and I was also in another city. The two network admins were in San Diego with the operations master, I was in San Francisco with an outer city DC.
We searched the web and found an unhelpful Microsoft KB article promisingly titled “Active Directory MMC Tools Are Slow to Initialize. All of our DNS records appeared just as they should.
Each time one of the network admins, Jeff, would encounter the problem, he would call me to see if my ADUC snap-in would load quickly — I never had any issues. I wondered if it was an issue with MMC.exe or with LDAP itself. I asked him to run the following script derived from the Active Directory Cookbook when he was having issues and report back to me the time that would pop up:
startTime = timer()
DisplayObjects "LDAP://OU=Users,DC=San Diego,DC=OurDomain,DC=com", ""
Function DisplayObjects( strADsPath, strSpace)
set objObject = GetObject(strADsPath)
for each objChildObject in objObject
DisplayObjects objChildObject.ADsPath, strSpace & " "
FinishTime = timer()
totalTime = finishTime-startTime
msgbox "This script took " & totalTime & " seconds to execute."
This script, which iterates through each of the users and their child objects in our San Diego Users OU, usually takes about 0.3 seconds to run. When Jeff ran into the issue, it would take up to 40 seconds. After we confirmed that his issue with his network or LDAP connection, not the actual MMC, we began to troubleshoot at a lower level — this likely isn’t an anti-virus+mmc issue that some people have reported.
I then asked Jeff to rerun the script I sent but this time, we would specifically query the San Diego DC. He changed the “LDAP://OU=Users” string to “LDAP://SanDiegoDC/OU=Users”. Bingo! The script’s time reported finishing in 0.3 seconds as opposed to 20 seconds. I then had him open up ADUC, right click on the domain icon and select “Connect to specific domain controller”. The dialog box confirmed that he was connected to an outer office DC and the default was set to “Any Writable Domain Controller.” We set that manually to the San Diego DC and ADCU instantly became more responsive.
Finding a way to set the San Diego DC to be the default for the Active Directory Users and Computers MMC snap-in was a challenge. I checked the registry but didn’t find much. Finally, I used The Google and found that he could create a shortcut which opens up the proper DC.
I’ll admit, that’s a bit of a band-aid but it will permanently solve Jeff’s ADMC problem. I still need to dig to figure out why his machine thinks that the outer office DC is the closest DC. Time to re-check our AD Sites and Services setup…