As mentioned during the introduction, Exchange 2013—like its predecessors—depends heavily on Active Directory (AD) and Domain Name System (DNS). If AD or DNS is not functioning correctly, your Exchange 2013 platform on top of that won't either.
For the following steps and information outlined, we assume you already have an Exchange Server infrastructure in place, meaning you are already using Active Directory (and DNS). Nevertheless, we want to draw your attention to some AD and DNS requirements and changes that are happening as part of your Exchange 2013 platform implementation.
Even if you are not using Exchange in your environment yet, the following items will be of interest to you.
We are not going to explain you how to set up your Active Directory domain controllers from scratch; we assume you already have that running. What's more important is knowing what the different system requirements for your Active Directory infrastructure are; just to be sure it is according to the Exchange 2013 requirements.
Let us start by giving an overview of the supported Operating System versions for each of the necessary AD components. The following information can also be found on TechNet. The following is the website for TechNet:
http://technet.microsoft.com/en-us/library/aa996719(v=exchg.150).aspx
Just as with the Active Directory bits of your environment, having a healthy DNS infrastructure is a vital part in your Exchange Server 2013 platform preparation work. While we could again assume this is already all in place and available, we would like to draw your attention to some DNS specifics and best practices.
One of the most recurring questions when designing Exchange (and Active Directory as well, if you will) infrastructure is, How should I decide on defining my DNS namepace? A short answer to this is, "There is no single best solution for this".
It depends on different parameters. The first question is whether you are using a split-DNS configuration or not? Now what does this mean? In most organizations, the internal Active Directory domain name will differ from the public internet domain name (for example, company.local and company.com). A split-DNS configuration means you will be using the same DNS namespace for your internal network as for your external. Back in the early days, when Active Directory had just come to life, Microsoft used to recommend using a different namespace internally and externally in the Active Directory design guides. Nowadays, it's just the opposite! There are various reasons for this, mainly to simplify the integration between different internal and external resources.
As a side note, we'd like to mention that maintaining a split-DNS setup, requires some additional overhead in the area of managing DNS entries in your DNS namespace. Let's take Outlook Web App as an example. Both URLs (internal and external) could potentially have the same name. Let's say it is set to https://owa.company.com/owa.
In your internal DNS namespace company.com, you will create a hostname entry which refers to the internal IP address(es) of your Client Access Server.
In the external DNS namespace, also company.com, you will create a hostname entry which refers to the public IP address of your firewall.
It has already been mentioned before that Exchange is highly dependent on DNS. Although no changes are required to your DNS infrastructure as such, it might be a good practice to verify that everything runs well before performing the Exchange 2013 installation.
As with a lot of applications and Windows components, your primary source for troubleshooting is the Event Viewer. Although this is also true for DNS, when using Server 2012 the DNS event entries are integrated into the DNS management console itself. In case of major issues with your DNS infrastructure, one might want to activate Debugging logging, which can be achieved as follows:
Open the DNS console on one of your DNS Servers
In the console, select your DNS server
Right-click on Properties and select Debug Logging
Check Log packets for debugging
As this is only to be used for detailed troubleshooting, do not forget to turn the checkbox off again when the issue has been resolved.
Without unwrapping all details of how DNS is operating, the following table will help you in verifying and troubleshooting your DNS name resolution mechanism:
When the Active Directory Server roles and OS versions we just saw have been verified, check your Active Directory replication and DNS replication to make sure it is working correctly as well. Again, Active Directory and DNS are the foundation for your Exchange 2013 installation!
Active Directory replication can be checked using the tool repadmin.exe, which is automatically installed on Server 2008 R2 and 2012 as part of the Remote Server Administration Tools for AD (RSAT-ADDS):
Open a command prompt with elevated rights. To do this, right-click on the command prompt icon and select Run as Administrator. If prompted by User Account Control (UAC), click on Yes.
repadmin /replsummaryThis will give you a summary of the replication status. If no fails/errors are shown, your Active Directory domain controllers are all in sync and replication is working fine, for example:
C:\Users\Administrator > repadmin /replsummary Replication Summary Start Time : 2013-07-06 18:09:26 Beginning Data Collection for replication summary, this may take a while: … Source DSA largest delta fails/total%% error Destination DSA largest delta fails/total%% error C:\Users\Administrator