Home / server / Questions / 44372
Accepted
Ehtyar
Asked: 2009-07-23 16:53:01 +0800 CST

How to reduce performance impact of joining Windows domain?

  • 772

We're a satellite office of a multinational corporation. We have a local domain controller, but we still experience a crippling performance drop after joining machines to our domain. Does anyone have any suggestions on how we might lessen or mitigate the performance impact of having machines joined to the domain? Please feel free to ask probing questions in the comments should you need additional info.

Note: We do not have full access to the domain or the DC, and thus are unable to effect changes even to our local OU regarding GPOs or general structure/layout etc. However, in the interest of completeness, please post even ideas that may require this level of access.

windows performance domain-controller active-directory

5 Answers

  1. It sounds to me like you've got startup / shutdown scripts that might be running and referencing resources on servers outside your office. I've also seen admins who don't understand DFS and try to do software installations across a WAN.

    Run RSoP and see what's applying to one of your machines for startup / shutdown scripts. Odds are good the permissions will be such that you can go out and read the scripts and see waht they're doing. Look for software assignments, too, and see if they're referring to off-site servers.

    I'm going to also recommend sniffing the traffic on a PC during startup or whatever other times are slow. Get a box with two NICs, bridge them, and use Wireshark to sniff on the bridge with the PC connected to one NIC and the LAN to the other. You'll get to see what your PC is trying to talk to during those "slow times".

    • 3

  2. Hrm. That's interesting. What performance are you speaking of? WAN network performance? That might point to AD syncing. LAN performance of the machine being synced? That would make me question your AD size. LAN performance of the local DC? I'm not sure where I'd go with that, honestly.

    Or is it just taking forever? If that's the case, it may be inadvertantly querying a remote DC across the WAN.

    • 1

  3. Hmmmm.... It could be that the Relative ID Master is off-network for you. When you create new Computer objects (join the domain, I'm assuming you don't pre-create your objects), it has to go to the RID master. If the DC holding that role is off network for you, it could take a long time to round-trip.

    Alternately, it could be that your AD tree doesn't have a Site declared for your satellite network. Therefore, domained machines keep referencing Global Catalog servers not local to you because no site boundary was declared for some reason. You might be able to look that one up yourselves (but not make changes) through the AD Sites MMC tool.

    A pair of (very possibly wrong) thoughts.

    Edit: Everything? That sounds a lot like the Security checking is horribly slow for some reason. SID lookups and the like are horribly slow. That makes it sound a lot like you're going across the WAN for those lookups when you shouldn't have to. Incorrect sites, or perhaps your local DC doesn't have GC.

    How it works is like this:

    • Visual Studio accesses a DLL
    • The OS then determines if Visual Studio can access that DLL at all
      • The User's security token, given to the user a login and contains all their group memberships as well as their direct security identifiers, is then referenced
      • The OS checks the security details of that DLL, finding a list of SIDs
      • The OS then resolves those SIDs against the Domain
        • The domain is probably in Australia for you
      • The OS checks the security principles against the user's security token
    • The OS grants access

    Wash, rinse, repeat for every file accessed. The workstation should keep a cache of SIDs, but VisualStudio opens up a metric bajillion of files which may over-run the cache.

    You can do a very rough check of domain lookup speeds by right-clicking on any NTFS file or directory and going to Security, entering a real user, and clicking the Lookup User button. How fast that goes should scale with the speeds you're experiencing between your domained/non-domained workstations.

    • 1

  4. Can you verify that the performance is indeed confined to the remote office by possibly taking a fresh machine to the site of the PDC, and joining the domain there? If the performance is still negatively impacted by joining the domain at site of the PDC, it's not your remote office's domain controller.

    If the performance is not impacted when joining at the site of the PDC, then you know for sure that it's an issue with your site's domain controller.

    Also, for the sake of reference, can you give us an idea of what kind of credentials you have in your domain, so we can base our suggestions on things you will actually be able to do?

    • 0
  5. Best Answer

    After reading the comments from Dayton Brown and sysadmin1138, I had a poke around the startup scripts, and I noticed the installation for an app we use to push software packages to remote machines. Upon further investigation, I found that it apparently does a lot more than push software.

    It is a complete IDS and antivirus solution (in addition to Symantec Antivirus for some reason), with about 6 related processes running on each machine. I think it's safe to say that this is causing our performance problems.

    My boss has agreed to let me rebuild a machine and prevent it from installing, to test. I'll keep you all posted, thanks for your feedback thus far guys.

    • 0