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 2013 (part 8)

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
12/13/2014 8:16:32 PM

Examining the Role of Domain Controllers in AD

Even before the existence of Active Directory, Exchange has relied on domain controllers to authenticate user accounts. With the advent of Active Directory, this has not changed. Exchange still relies on domain controllers to provide all authentication services. To provide optimal logon authentication response times, the proper placement of domain controllers is crucial.

Examining Domain Controller Authentication in Active Directory

To understand how Exchange manages security, an analysis of Active Directory authentication is required. This information aids in troubleshooting the environment, as well as in gaining a better understanding of Exchange Server 2013 as a whole.

Each object in Exchange, including all mailboxes, can have security directly applied for the purposes of limiting and controlling access to those resources. For example, a particular administrator might be granted access to control a certain set of Exchange servers, and users can be granted access to mailboxes. What makes Exchange particularly useful is that security rights can be assigned not only at the object level, but also at the attribute level. This enables granular administration, by allowing tasks such as a Telecom group being able to modify only the phone number field of a user, for example.

When a user logs on to a domain, the domain controller performs a lookup to ensure a match between the username and password. If a match is made, the client is then authenticated and given the rights to gain access to resources.

Because the domain controllers provide users with the permission to access the resources, it is important to provide local access to domain controllers for all Exchange servers. If a local domain controller became unavailable, for example, users would be unable to authenticate to their mailboxes in Exchange, effectively locking them out.

Determining Domain Controller Placement with Exchange Server 2013

Because Exchange relies on the security authentication performed by Active Directory domain controllers, the placement of these domain controllers becomes critical to the overall performance of your messaging environment. If a domain controller cannot be reached in a reasonable amount of time, access to messages and network resources is delayed.

At a minimum, at least one Active Directory domain controller must be within close proximity to any Exchange server to ensure speedy authentication for local users and mailboxes. Additional Active Directory domain controllers can be implemented to provide increased performance in heavily utilized sites or to provide redundancy in the event of a domain controller failure.

For organizations with a high concentration of Exchange servers and clients, a significant demand for directory services can negatively impact all aspects of network performance. The presence of other applications and services that require authentication, directory services, or directory replication can cause your Exchange performance to suffer. A current best practice to avoid these pitfalls is to create a dedicated Active Directory site, with dedicated domain controllers and global catalog servers. By segmenting a Service Delivery Location (SDL) into multiple Active Directory sites, you can separate the directory traffic generated by Exchange servers and Microsoft Outlook clients from other directory service traffic.

In addition, you can deploy more than one Active Directory domain controller in close proximity to users for user authentication. This enables the distribution of domain controller tasks and builds redundancy into the design. Because each Microsoft Windows Server 2012 domain controller is a multimaster, in the event of a failure of one domain controller, others are able to continue to function and allow uninterrupted authentication.

Defining the Global Catalog

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 2013 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 processor cores to global catalog server 32-bit processor cores. So, if you have four Exchange servers, each with four processors, you should have four processors running your global catalog servers. For global catalog servers with 64-bit processor cores, there should be an 8:1 ratio of Exchange processor cores to global catalog server 64-bit processor cores when there is sufficient memory in to cache the entire Active Directory database (DIT file). Of course, Exchange Server 2013 processor cores are always 64-bit.

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.

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.

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

1. Open the Active Directory Sites and Services tool.

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 5.

Image

Figure 5. Making a domain controller a global catalog server.

6. Click OK to finalize the operation.

Other -----------------
- Windows Server 2012 : Enhancing DHCP Reliability - Windows Server 2012 DHCP Failover
- Windows Server 2012 : Enhancing DHCP Reliability - Implementing Redundant DHCP Services
- Windows Server 2012 : Enhancing DHCP Reliability - DHCP Network Access Protection Integration
- Windows Server 2012 : Enhancing DHCP Reliability - DHCP Name Protection, DHCP and Dynamic DNS Configuration
- Windows Server 2012 : Enhancing DHCP Reliability - Link-Layer Filtering, DHCP Reservations
- Exploring DHCP Changes in Windows Server 2012 : Migrating DHCP Services from 2008 R2 to Windows Server 2012, derstanding DHCP Client Alternate Network Capability
- Exploring DHCP Changes in Windows Server 2012 : Migrating DHCP Servers Using Windows Server Migration Tools
- Sharepoint 2013 : The Office Web Applications for Sharepoint - Preparing the Server and Installing OWA via the GUI
- Sharepoint 2013 : The Office Web Applications for Sharepoint - Topology
- Sharepoint 2013 : The Office Web Applications for Sharepoint - Mobile Device Support
 
 
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
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server