Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Understanding Network Services and Active Directory Domain Controller Placement for Exchange Server 2007 : Defining the Global Catalog

- How To Install Windows Server 2012 On VirtualBox
- How To Bypass Torrent Connection Blocking By Your ISP
- How To Install Actual Facebook App On Kindle Fire
4/1/2013 6:20:47 PM
The global catalog is an index of the Active Directory database that stores a full replica of all objects in the directory for its host domain, and a partial replica of all objects contained in the directory of every domain in the forest. In other words, a global catalog contains a replica of every object in Active Directory, but with a limited number of each object’s attributes.

Global catalog servers, often referred to as GCs, are Active Directory domain controllers that house a copy of the global catalog. A global catalog server performs two key roles:

  • Provides universal group membership information to a domain controller when a logon process is initiated

  • Enables finding directory information regardless of which domain in the forest contains the data

Access to a global catalog server is necessary for a user to authenticate to the domain. If a global catalog is not available when a user initiates a network logon process, the user is only able to log on to the local computer, and cannot access network resources.

With such an important role to play, it is a common practice to locate at least one global catalog server in each physical location, as it is referenced often by clients and by applications such as Exchange.

Understanding the Relationship Between Exchange Server 2007 and the AD Global Catalog

In the past, an Exchange server could continue to operate by itself with few dependencies on other system components. Because all components of the mail system were locally confined to the same server, downtime was an all-or-nothing prospect. The segregation of the directory into Active Directory has changed the playing field somewhat. In many cases, down-level clients no longer operate independently in the event of a global catalog server failure. Keep this in mind, especially when designing and deploying a domain controller and global catalog infrastructure.

Note

Because Outlook clients and Exchange can behave erratically if the global catalog they have been using goes down, it is important to scrutinize which systems receive a copy of the global catalog. In other words, it is not wise to set up a GC/DC on a workstation or substandard hardware, simply to off-load some work from the production domain controllers. If that server fails, the effect on the clients is the same as if their Exchange server failed.


Understanding Global Catalog Structure

The global catalog is an oft-misunderstood concept with Active Directory. In addition, design mistakes with global catalog placement can potentially cripple a network, so a full understanding of what the global catalog is and how it works is warranted.

As mentioned earlier, Active Directory was developed as a standards-based LDAP implementation, and the AD structure acts as an X.500 tree. Queries against the Active Directory must, therefore, have some method of traversing the directory tree to find objects. This means that queries that are sent to a domain controller in a subdomain need to be referred to other domain controllers in other domains in the forest. In large forests, this can significantly increase the time it takes to perform queries.

In Active Directory, the global catalog serves as a mechanism for improving query response time. The global catalog contains a partial set of all objects (users, computers, and other AD objects) in the entire AD forest. The most commonly searched attributes are stored and replicated in the global catalog (that is, first name, username, email address). By storing a read-only copy of objects from other domains locally, full tree searches across the entire forest are accomplished significantly faster. So, in a large forest, a server that holds a copy of the global catalog contains information replicated from all domains in the forest.

Using Best Practices for Global Catalog Placement

All users accessing Exchange resources should have fast access to a global catalog server. At least one global catalog server must be installed on each domain that contains an Exchange server; however, to achieve the best performance in larger organizations, additional global catalog servers should definitely be considered.

As a starting point, per site, there should be a 4:1 ratio of Exchange processors to global catalog server processors, assuming, of course, the processors are of comparable models and speeds. So, if you have four Exchange servers, each with four processors, you should have four processors running your global catalog servers.

Bear in mind, however, that increased global catalog server usage, very large Active Directory implementations, or the use of extremely large distribution lists might necessitate more global catalog servers.

Note

With respect to the global catalog processor ratio rule, the 4:1 processor ratio rule from prior versions of Exchange, which assumes a result of one global catalog server being deployed for every two mailbox servers, applies to any environment where the database file (the .dit file) for Active Directory is larger than 1GB, and, therefore, cannot fit into memory. Exchange 2007 is undergoing a variety of performance tests, and more prescriptive guidance is expected in the RTM version of Exchange 2007.


Promoting a Domain Controller to a Global Catalog

Although any domain controller can easily be promoted to a global catalog server, the promotion can have a significant impact on network operations and performance while the topology is updated and the copy of the catalog is passed to the server.

During the promotion, the server immediately notifies DNS if it’s new status. In the early days of Active Directory, this often caused problems, as the Exchange servers would immediately begin utilizing the global catalog server before it had finished building the catalog. This problem was rectified in Exchange 2000, Service Pack 2, with the addition of a mechanism that detects the readiness of a global catalog server and prevents Exchange from querying new servers until a full copy of the catalog has been received.

The procedure to promote a domain controller to a global catalog server is as follows:

1.
On the domain controller, click Start, point to Programs, click Administrative Tools, and then click Active Directory Sites and Service.

2.
In the console tree, double-click Sites, double-click the name of the site, and then double-click Servers.

3.
Double-click the target domain controller.

4.
In the details pane, right-click NTDS Settings, and then click Properties.

5.
On the General tab, click to select the Global Catalog check box, as shown in Figure 1.

Figure 1. Making a domain controller a Global Catalog server.


6.
Click OK to finalize the operation.

In older versions of the Windows Server operating system, it was necessary to restart the domain controller after a promotion to a global catalog; however, as of Windows Server 2003, this step is no longer necessary.

Verifying Global Catalog Creation

When a domain controller receives the orders to become a global catalog server, there is a period of time when the GC information will replicate to that domain controller. Depending on the size of the global catalog, this could take a significant period of time. To determine when a domain controller has received the full subset of information, use the replmon (replication monitor) utility from the Windows Server 2003 support tools. The replmon utility indicates which portions of the AD database are replicated to different domain controllers in a forest, and how recently they have been updated.

Replmon enables an administrator to determine the replication status of each domain naming context in the forest. Because a global catalog server should have a copy of each domain naming context in the forest, determine the replication status of the new GC with replmon. For example, the fully replicated global catalog server in Figure 2 contains the default naming contexts, such as Schema, Configuration, and DnsZones, in addition to domain naming contexts for all domains. In this example, the companyabc.com domain has been replicated successfully to the VMW-DC2 domain controller.

Figure 2. Replmon GC creation verification.

Exploring Global Catalog Demotion

Removing a global catalog server from production can also have a detrimental effect in certain cases. Outlook 2000 and older clients, for example, experience lockup issues if the global catalog server they have been using is shut down or removed from GC service. The loss of a GC server is the equivalent of the loss of an Exchange server, and should, therefore, not be taken lightly. Outlook 2002 and greater clients, however, automatically detect the failure of their global catalog server and reroute themselves within 30 seconds. Scheduling global catalog or domain controller demotions for the off-hours, therefore, is important.

Note

If a production global catalog server goes down, down-level (pre-2002) versions of Outlook can regain connectivity via a restart of the Outlook client. In some cases, this means forcing the closure of OUTLOOK.EXE and MAPISP32.EXE from the Task Manager or rebooting the system.


Deploying Domain Controllers Using the Install from Media Option

When deploying a remote site infrastructure to support Exchange Server 2007, take care to examine best-practice deployment techniques for domain controllers to optimize the procedure. In the past, deploying domain controller and/or global catalog servers to remote sites was a rather strenuous affair. Because each new domain controller would need to replicate a local copy of the Active Directory for itself, careful consideration into replication bandwidth was taken into account. In many cases, this required one of these options:

  • The domain controller was set up remotely at the start of a weekend or other period of low bandwidth.

  • The domain controller hardware was physically set up in the home office of an organization and then shipped to the remote location.

This procedure was unwieldy and time-consuming with Windows 2000 Active Directory. Fortunately, Windows Server 2003 addressed this issue through use of the Install from Media option for Active Directory domain controllers.

The concept behind the media-based GC/DC replication is straightforward. A current, running domain controller backs up the directory through a normal backup process. The backup files are then copied to a backup media, such as a CD or tape, and shipped to the remote GC destination. Upon arrival, the dcpromo command can be run with the /adv switch (dcpromo /adv), which activates the option to install from media, as illustrated in Figure 3.

Figure 3. Install from media option.


After the dcpromo command restores the directory information from the backup, an incremental update of the changes made since the media was created is performed. Because of this, you still need network connectivity throughout the dcpromo process, although the amount of replication required is significantly less. Because some dcpromo operations have been known to take days and even weeks, this concept can dramatically help deploy remote domain controllers.

Note

If the copy of the global catalog that has been backed up is older than the tombstone date for objects in the Active Directory (which by default is 60 days), this type of dcpromo will fail. This built-in safety mechanism prevents the introduction of lingering objects and also assures that the information is relatively up to date and no significant incremental replication is required.


Understanding Universal Group Caching for AD Sites

Windows Server 2003 Active Directory enables the creation of AD sites that cache universal group membership. Any time a user uses a universal group, the membership of that group is cached on the local domain controller and is used when the next request comes for that group’s membership. This also lessens the replication traffic that would occur if a global catalog was placed in remote sites.

One of the main sources of replication traffic is group membership queries. In Windows 2000 Server Active Directory, every time clients logged on, their universal group membership was queried, requiring a global catalog to be contacted. This significantly increased logon and query time for clients that did not have local global catalog servers. Consequently, many organizations had stipulated that every site, no matter the size, have a local global catalog server to ensure quick authentication and directory lookups. The downside of this was that replication across the directory was increased because every site would receive a copy of every item in the entire AD, even though only a small portion of those items would be referenced by an average site.

Universal group caching solved this problem because only those groups that are commonly referenced by a site are stored locally, and requests for group replication are limited to the items in the cache. This helps limit replication and keep domain logons speedy.

Universal group caching capability is established on a per-site basis, through the following technique:

1.
Open Active Directory Sites and Services.

2.
Navigate to Sites, sitename.

3.
Right-click NTDS Site Settings, and choose Properties.

4.
Check the Enable Universal Group Membership Caching check box, as shown in Figure 4.

Figure 4. Universal group caching.


5.
Click OK to save the changes.

Note

Universal group (UG) caching is useful for minimizing remote-site replication traffic and optimizing user logons. Universal group caching does not replace the need for local global catalog servers in sites with Exchange servers, however, because it does not replace the use of the GC port (3268), which is required by Exchange. UG caching can still be used in remote sites without Exchange servers that use the site consolidation strategies of Exchange Server previously mentioned.

Other -----------------
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 6)
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 5) - Generating a proxy service
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 4) - Configuring the BizTalk endpoints
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 3) - Building the BizTalk components
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 2) - Configuring the BizTalk endpoints
- Integrating BizTalk Server 2010 and Microsoft Dynamics CRM : Communicating from BizTalk Server to Dynamics CRM (part 1) - Building the BizTalk components
- Extending Dynamics AX 2009 (part 3) - Creating Labels, Adding Content to the Wizard
- Extending Dynamics AX 2009 (part 2) - Creating a New Wizard
- Extending Dynamics AX 2009 (part 1)
- System Center Configuration Manager 2007 : Operating System Deployment - Native Mode
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
programming4us programming4us
Popular tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 windows Phone 7 windows Phone 8
programming4us programming4us
 
programming4us
Natural Miscarriage
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Game Trailer