AD: Active Directory Users and Computers Slow to Initialize

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 & " "
   next
End Function
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.

dsa.msc /server=sandiegodc.ourdomain.com

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…

Chrissy is a PowerShell MVP who has worked in IT for nearly 20 years, and currently serves as a Sr. Database Engineer in Belgium. Always an avid scripter, she attended the Monad session at Microsoft’s Professional Developers Conference in Los Angeles back in 2005 and has worked and played with PowerShell ever since. Chrissy is currently pursuing an MS in Systems Engineering at Regis University and helps maintain RealCajunRecipes.com in her spare time. She holds a number of certifications, including those relating to SQL Server, SuSE Linux, SharePoint and network security. She recently became co-lead of the SQL PASS PowerShell Virtual Chapter. You can follow her on Twitter at @cl.

Posted in Active Directory
9 comments on “AD: Active Directory Users and Computers Slow to Initialize
  1. Hi

    i found that using the ip address fixed the problem however what about fault tolerance and redundancy? what if that server is busy or down?

  2. Chrissy says:

    Cyril,
    AD should automatically be finding it for you. The above workaround is really a hack. Check your Active Directory Sites and Services to ensure that you’ve got sites setup and working properly.

  3. DK says:

    Have you checked AD Sites and Services to see which site his Workstation/Client IP address is a member of? Is it covered by a subnet, if not, create a subnet and assign it to the site where his local DC is located.

  4. Chrissy says:

    Hey DK,
    Yep, that’s exactly what it was. He wasn’t assigned an IP address under DHCP and set his own. His subnet was not defined under Sites and Services. Once that was added, it worked great.

    Thanks for commenting!

    Chrissy

  5. vikrant says:

    I am facing a similar problem.I have 2 sites geografically seperated by 1000 miles. I have 512 kbps lease line between the sites.
    Now whenever I launch ADC.msc, it loads the remote site ADC.
    How can I make it load the ADC where I belong. I have added my subnet address in the ADsite and services then also I am facing the same problem.
    Please help….
    regards Vikrant

  6. Wim says:

    thanks a MILLION! Really wouldn’t have come up with that solution by myself!

  7. Wim says:

    With your script I figured out the probleme here wasn’t on the LDAP layer. My collegue noticed when he closed the AD mmc the mmc.exe process did not stop. In face it took 100% of system resources..

    The probleem seems to be known to microsoft though they have not yet come up with a solution and the kb seems to be about win2k instead of the Win2k3 R2 we’re using…

    http://support.microsoft.com/kb/300036

  8. Jaremy says:

    Your script helped point me in the right direction. I confirmed that my LDAP lookup was the same speed on a machine that had this issue as one that didn’t have the issue. As per most threads and articles that discuss this problem, it turns out that I have a DNS issue. I used NetMon to confirm that I had multiple DNS lookups produced by my mmc use. Changing the /server target on launch (and subsequently changing this permanently in the mmc, itself) and using the IP of the server, rather than the FQDN gave me the fast response I see when using the snap-in on my Terminal Server. Now, to identify the dns caching problem on my local machine. I’ve already tweaked my MaxCacheTtl key – going to reboot and hope that helps. Thank you for your post!

  9. Aaron says:

    Hmmm… the comment about using the ip address made me want to check my hosts file. Empty. Added ip and hostname… problem resolved for me.

Leave a Reply

Your email address will not be published. Required fields are marked *

*