If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
- Active Directory Insights (Part 1): Configuring DNS on domain controllers
- Active Directory Insights (Part 2): Digging into Trusts
- Active Directory Insights (Part 3): Re-examining read-only domain controllers
- Active Directory Insights (Part 4): More on read-only domain controllers
- Active Directory Insights (Part 5) – Domain controller hardware sizing
- Active Directory Insights (Part 6) – Domain controllers and NIC teaming
- Active Directory Insights (Part 7) – More on using virtual domain controllers
- Active Directory Insights (Part 8) – Virtual domain controllers and disaster recovery
- Active Directory Insights (Part 9) – Automating user account provisioning
- Active Directory Insights (Part 10) – DHCP and domain controllers
- Active Directory Insights (Part 11) – sIDHistory
- Active Directory Insights (Part 12) – MaxTokenSize
- Active Directory Insights (Part 13) – Digging into the Global Catalog
Introduction
In the previous article of this series we began examining the Global Catalog (GC) and how it works and various considerations associated with implementing and maintaining it in Active Directory environments. This article continues digging into the operation of the GC and various issues that may arise with its operation.
Sizing the GC
GC sizing is tightly integrated with domain controller sizing since global catalog servers are domain controllers. We looked previously at the topic of domain controller sizing in Part 5 of this series but it’s worthwhile revisiting this briefly as we focus on global catalog servers.
In general the key thing you want to ensure when sizing your domain controllers is that your entire Active Directory directory database (.DIT file) can fit into the available memory of your domain controllers. Unfortunately it can be difficult to predict in advance how much RAM you will need on your domain controllers even if you have an accurate estimate of the number of users, concurrent users, groups and co computers you’re going to have in your Active Directory environment. The reason for this is because it’s not just the number of directory objects that matters but also how many attributes are going to be set for each user or computer object and the number of members each group is going to have.
Also important when you’re sizing domain controllers is how frequently objects and their attributes will be changing in your environment, the number of Group Policy Objects you’ll have and how they will be linked and processed, the number of user and computer objects that will be authenticating per second, and so on. Not only will these considerations impact the .DIT file size and thus the amount of RAM your domain controller will need to keep the .DIT file in memory at all times, they will also impact the estimated number of IOPS that the disk subsystem on your domain controllers will need to be able to support.
Still, it’s possible to perform some rough estimates of all this, and one estimate I’ve heard from some of my colleagues who are Active Directory consultants which they tell me they use as a rule of thumb when sizing domain controllers is that a .DIT file for storing information for about 1 million users where only commonly used attributes are set will be around 10 GB in size, which means the domain controller (including one hosting the GC) should have a minimum of about 16 GB RAM.
And of course the above is only a rule of thumb that may need to be tweaked further should you find a performance bottleneck. For example, if you have a very large number of users that all log on around the same time each morning then the above sizing estimate may be too conservative and you might need to double your domain controller memory to 32 GB RAM to avoid users experiencing excessively slow logons. The same kind of bottleneck can also occur because of an application or service that issues an excessive number of expensive queries against Active Directory over a small period of time, so keep that in mind as well if you have such applications or services deployed in your environment.
Global catalog servers and lingering objects
Lingering objects can be a problem in Active Directory environments where configuration changes are performed improperly or in the wrong sequence. A lingering object (LO) is an object that exists on only some of the domain controllers that host the same directory naming context (NC, also called a partition), and the presence of a LO generally means that an object has been deleted from the directory but the delete operation has failed to replicate successfully to all of the domain controllers (and thus global catalog servers) that host the NC where the deleted object resides. A good resource for understanding LOs and how you can deal with them is the post titled Clean that Active Directory forest of lingering objects from Glenn LeCheminant’s blog. The post is old but the information in it is still accurate for the current version of Active Directory in Windows Server 2012.
Focusing in particular on global catalog servers and considering this TechNet article explains how you can add or remove the GC from a domain controller, it’s important to understand that if you un-GC a domain controller and then later re-GC it you could end up polluting your GC with LOs. The way to avoid this is to un-GC and re-GC all of your domain controllers at the same time, but obviously that’s not feasible in most Active Directory environments. Why would you even want to do this however? The answer seems to be that confusing advice is usually the culprit. For example, you hire a consultant to perform a forest or domain migration and they decide to do a clean-up of LOs in your forest before performing the migration, and they recommend disabling GC-to-GC replication before doing the cleanup and they do so but leave one global catalog server turned on. As a result, the GC ends up being offline for several hours causing problems for users and applications that rely upon it. Not only that, the removed LOs suddenly reappear a few days later!
Once you’ve cleaned up LOs in your environment using the RepAdmin /removelingeringobjects command you can then use the ReplDiag command-line tool for validating that cleanup has been successful. ReplDiag is available for download from CodePlex as one of the out-of-band Active Directory utilities found here: http://activedirectoryutils.codeplex.com/releases/view/13664. For more information on how to use ReplDiag to troubleshoot problems with LOs replicating in your forest, see this four-part series of blog posts by Rob Bolbotowski. Also be sure to check out KB 314282 “Lingering objects may remain after you bring an out-of-date global catalog server back online” found at http://support.microsoft.com/kb/314282/ which still applies to the current version of Windows Server even though the KB article itself says it only applies to Windows 2000 Server.
To be continued
We haven’t yet exhausted everything important we can talk about concerning the GC so we’ll continue our discussion of its operations and maintenance in the next article of this series.
Still got questions about Active Directory?
If you have any questions about domain controller hardware planning, the best place to ask them is the Active Directory Domain Services forum on TechNet. If you don’t get help that you need there, you can try sending your question to [email protected] so we can publish it in the Ask Our Readers section of our newsletter and see whether any of the almost 100,000 IT pro subscribers of our newsletter have any suggestions concerning your problem.
If you would like to be notified when Mitch Tulloch releases the next part of this article series please sign up to the WindowsNetworking.com Real time article update newsletter.
If you would like to read the other parts in this article series please go to:
- Active Directory Insights (Part 1): Configuring DNS on domain controllers
- Active Directory Insights (Part 2): Digging into Trusts
- Active Directory Insights (Part 3): Re-examining read-only domain controllers
- Active Directory Insights (Part 4): More on read-only domain controllers
- Active Directory Insights (Part 5) – Domain controller hardware sizing
- Active Directory Insights (Part 6) – Domain controllers and NIC teaming
- Active Directory Insights (Part 7) – More on using virtual domain controllers
- Active Directory Insights (Part 8) – Virtual domain controllers and disaster recovery
- Active Directory Insights (Part 9) – Automating user account provisioning
- Active Directory Insights (Part 10) – DHCP and domain controllers
- Active Directory Insights (Part 11) – sIDHistory
- Active Directory Insights (Part 12) – MaxTokenSize
- Active Directory Insights (Part 13) – Digging into the Global Catalog
