The larger the organization the less it seems that the Exchange Administrators talk to or work with the Active Directory Administrators. This is usually a two-way street. This lack of understanding can severely impact your Exchange environment. The purpose of this blog post is to educate YOU the Exchange Administrator on what you need to understand about Active Directory (AD), a few AD basics, and a few tips. Hopefully this knowledge will allow you to proactively talk to your AD Administrator(s). It would be great if you read this before you implemented Exchange Server 2007, but we can't have it all, can we? Finally, I hope by the end you will understand why we need Active Directory (we already know they need us - everyone needs email right?).
No discussion of Active Directory would be complete without talking about Domain Name Servers (DNS). I am not going to go deep on this topic, but I do want one thing made very clear. Your organization may decide to dynamically update DNS or do it manually, either will work for Exchange - just make sure you have all the proper DNS Service Resource Records (SRV RR) as explained in RFC 2782. SRV record Priorities determine the order in which servers will be used (lowest priority first), Weights determine the load balancing to servers with same priority. The Microsoft default for Domain Controllers priority/weight is 0/100.
Don't panic, you really don't have to read the RFC, though I have and it is not that bad. What we care about here is AD Sites SRV records (more on this topic later).
Run "DCDiag /test: registerindns /dnsdomain: FQDN /v" from a DC to verify the records are in DNS.
Domain controllers running Windows Server 2003/2008 register SRV records in the _msdcs subdomain in the following format:
Tips & Tricks: use DnsAvoidRegisterRecords registry key in hub/spoke environments to manage what SRV records are registered.
A great DNS utility is DNSLint; the best part - it's a free download from Microsoft. It will provide you with a detailed listing of your DNS environment. You can also use it to troubleshoot AD, see How to use DNSLint to troubleshoot Active Directory replication issues for details.
You can install DNS on a Read-Only DC (RODC), but just like the DC component, it will be read-only. If a write request/update comes into a Read-Only DNS server, a referral is made to a writeable copy of the appropriate application partition, and the record is replicated back to the application partition stored on the RODC DNS server.
Domain Controller Defined
Domain controllers store data and manage user and domain interactions, including user logon processes, authentication, and directory searches. DCs are used by several Exchange Server directory components, such as Directory Service Access (DSAccess or ADAccess), Directory Service Proxy (DSProxy), Offline Address Book (OAB) and the Message Categorizer use domain controllers or global catalog servers.
Read-Only Domain Controller (RODC)
An RODC is an additional domain controller for a domain that hosts read-only partitions of the Active Directory database. An RODC is designed primarily to be deployed in a branch office environment. Branch offices typically have relatively few users, poor physical security, relatively poor network bandwidth to a hub site, and little local IT knowledge. Exchange requires a write-able Domain Controller and cannot use a RODC or Read-Only Global Catalog (ROGC).
Global Catalog Defined
A global catalog (GC) stores a full copy of all objects in the directory for its host domain and a partial copy of all objects for all other domains in the forest. To optimize network performance in a multiple-site environment, consider adding global catalogs for select sites. In a single-site environment, a single global catalog is usually sufficient to cover common Active Directory queries. However, in a multiple-site environment it is recommended that you use global catalogs in each site. Exchange Server 2007 loves global catalog servers, all distribution groups should be Universal Groups now. Universal groups are stored in the GC and replicated throughout the forest.
Tips & Tricks: To avoid excess replication traffic, keep Universal group membership changes to a minimum (Windows 2003 Interim/Forest Functional Mode helps this because it use Link Value Replication (LVR)).
32-Bit or 64-bit Domain Controllers?
As you probably already know a 64-bit machine and operating system (OS) is a requirement for Exchange Server 2007 in production. What about the Domain Controllers (DCs)? You probably already have 32-bit Domain Controllers; do you need 64-bit? The best practice answer is YES. 32-bit machines have several memory limitation and constraints, 64-bit have much larger limits that most of our customers will never hit. With a 64-bit DC and right amount of memory you can store your entire AD in RAM. Exchange loves talking to DCs, and you get a big bang for your buck from 64-bit DCs - the increase in lookup response times can be staggering. See Guidance on Active Directory design for Exchange Server 2007 for more information. The bottom line is update/upgrade your DCs to 64-bit before installing Exchange 2007 or after reading this if you have not already.
Windows Server 2003 or Windows Server 2008 Domain Controllers?
Let me state right off the bat that Exchange Server 2007 SP1 works with either version of the OS on your DCs. You can even install Exchange Server 2007 SP1 on Windows Server 2008 (see Exchange Server and Windows Server 2008 and Exchange Server and Windows Server 2008, Part II for more details). With that said, if you are updating your DCs to 64-bit I would seriously look at Windows Server 2008. Here is a simple list to discuss with your AD Administrators before deciding to use Windows Server 2008 or stay on Windows Server 2003:
· If you deploy Windows Server 2003 today, what is the life of that computer? 3, 4, even 5 years? Will Microsoft support you during that entire span? In 2013 will you really want to be running Windows Server 2003?
· New hardware, new OS - it's just that simple J
· Dozens of enhancements have been made to 2008. See http://www.microsoft.com/windowsserver2008/en/us/active-directory.aspx for a short list. Restartable Domain Services is awesome and will allow your AD Administrators to apply patches or do an offline defrag all without a reboot.
· Server Core is a great option for a DCs and DNS servers. On the plus side it's more secure.
Windows Schema Update for Exchange
Your AD Administrators might give you a hard time about running a schema update, believe me it happens. The reason is that when a DCs learns about a schema update, but has not replicated it yet, the DC will stop all other forms of AD replication until there schema is up to date. No single attribute is expected to be more than 500 kilobytes (KB). No single object is expected to be more than 1 megabyte (MB). Have them test the update in a lab, but the process should go quickly in most environments.
Make sure they understand that Exchange has two versions of the schema - RTM and SP1. The SP1 version includes the RTM changes. If they used the RTM update, they will have to rerun it with SP1. See How to Prepare Active Directory and Domains for more details.
Active Directory Replication
All DCs (expect RODC's) maintain a writeable copy of the AD database. Replication is the process by which DCs keep each other up to date.
Active Directory Sites
Active Directory sites are a very important topic and yet are commonly misconfigured. A site is a combination of the physical (wires, cables, routers, etc.) and the logical (Active Directory configuration, IP Subnet, etc.). A site may span one or more domains. A site needs to be able to allow all the domain controllers within it to replicate to each other in a timely fashion. Clients will treat all DCs in the site as equals.
Common Configuration errors include:
· not defining a client's subnet within sites, this will cause clients to seek out a DC, which could be anywhere in the forest
· not having enough sites or improper site chaining, this will cause extra replication traffic on the site bridgeheads
· having sites that span too large of an area, this will cause replication slowness
Exchange Server 2007 uses AD sites to route and send emails; it does not manage its own routing topology any more. This change makes AD sites very important to the health of Exchange Server 2007. The Client Access Server (CAS) role is very heavily dependent on AD sites as well, for things like Autodiscover, calendar assistant, etc. Lastly, Exchange Server 2007 won't install unless it is in an AD Site that contains a GC.
Dedicated Active Directory Site for Exchange
To dedicate or not to dedicate, that is the question. For most the answer is not to dedicate, unless you can't control application access to the DCs or you have another valid business reason. Testing is the best way to figure out if you really need a dedicated site for Exchange. Mike Lee wrote a great blog post about our Guidance on Active Directory design for Exchange Server 2007.
Active Directory Access (ADAccess) is a core component of Exchange. ADAccess performs auto discovery using cached information to reduce lightweight directory access protocol (LDAP) requests for your Active Directory topology; which means it detects domain controllers and global catalog servers in your environment on a regular interval.
Tips & Tricks: You can turn up logging for ADAccess, see this TechNet article.
Directory Service Proxy (DSProxy) is the process used to provide either referrals or proxy requests to a GC on behalf of Outlook clients. This process is the same for Exchange Server 2007.
Where does Exchange store data in AD
If I had to a put a percentage on Exchange's use of AD, I would say Exchange Server 2007 is 70% Active Directory, where Exchange Server 2003/2000 was 40%. In the chart below you can clearly see Exchange stores information in several naming contents - Domain, Configuration, and Schema. Remember Exchange Server 2007 uses AD Sites for routing.
Active Directory Tweaks worth looking into
Here is a list of some common, but important tweaks for Active Directory. As always please test changes in a lab first before deploying to production.
- Default is 120 seconds - too long in some cases, Microsoft IT is 45 seconds
- Reduced for better end user experience (response time)
- Default is 20, Microsoft IT is set to 32
- Allows for more concurrent LDAP queries
- ANR search behavior (among many others)
- Forest wide settings
- Microsoft IT is set to 0001 - pre-emptive nickname resolution
Active Directory Troubleshooting
I would like to end with troubleshooting. Below are just a few things to look into.
- 24 diagnostics registry keys
- Verbosity 0-5 :: 0-Off, 1-Lowest Verbosity, 5-Highest Verbosity
- "3 ExDS Interface Events"
- "4 MAPI Interface Events"
- "6 Garbage Collection"
- Set to 1 on all DC's - creates two added events every 24 hours
- Event ID 1646 displays available white space recoverable with offline defrag
- "9 Internal Processing"
- "15 Field Engineering"
- Identifies expensive and inefficient queries
- Thresholds can be managed via the registry
Tips & Tricks: Never leave at any value other than 0 (zero) unless troubleshooting. A value of 5 can fill up the Directory Service Event Log in a matter of minutes!!!
o Server performance Reports
o Resource utilization information
o Identify offending clients
o Identify bottlenecks
o Workload Stress
o Typically caused by DNS or network issues
o Replication latency depends on topology and settings
o Use Repadmin to identify the source of the problem
o Increase Diagnostic keys to track significant events
o Repadmin.exe is the primary tool for identifying and resolving all replication issues
o DCDiag provides overall "health" of a domain controller
o Risk Assessment Program for Active Directory (ADRAP) is an ideal delivery for identifying current issues
My hope is that reading all of the above has shed a light on why you as an Exchange Administrator needs Active Directory. An even more important goal is to point out why Exchange requires a healthy Active Directory environment. My goal was to give you enough AD information so that you can talk to your AD Administrators and help get your AD into shape, so that Exchange can live a long and healthy life.
For more information on AD please see our Directory Services Community page.