If you would like to read the other parts of this article series please go to:
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 1)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 2)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 4)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 5)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 6)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 7)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 8)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 9)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 10)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 11)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 12)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 13)
Introduction
In part 2 of this multi-part article, we prepared the network and storage side of things. Previously, we checked that each server could communicate properly with each other both in the same datacenter and over the WAN.
In this part 3, we will continue where we left of in part 2. That is we will start with the Active Directory preparation and installing Exchange 2010 on the four servers. Then we will create the namespaces required for this scenario.
Preparing Active Directory
Although the schema extension and active directory preparation steps can run as part of the setup process when installing the first Exchange 2010 server, a good best practice is to always perform the active directory preparation and Exchange 2010 installation steps.
So the very first thing we will do is to mount the Exchange 2010 SP1 media and run the following command in order to extend the schema with Exchange 2010 SP1 classes and attributes:
- Setup /PrepareSchema
When the schema has been extended successfully, we run the following command in order to prepare the Active Directory for Exchange 2010 SP1 and create the Exchange organization (if one doesn’t already exist):
- Setup /PrepareAD /ON:”Exchange Online DK”
Finally we need to prepare the Active Directory domain (or domains if you have more than one in the forest that will have Exchange users or servers) with the following command:
- Setup /PrepareDomain
For more details about preparing the Active Directory and domains, see Prepare Active Directory and Domains in the Exchange 2010 TechNet documentation.
Installing Exchange 2010 SP1 on the Servers
Before you can install Exchange 2010 SP1 on the Windows 2008 R2 servers, you must first install the following hotfixes (TechNet):
- Install the update described in Knowledge Base article 979099; An update is available to remove the application manifest expiry feature from AD RMS clients. Without this update, the AD RMS features may stop working.
- Install the hotfix described in Knowledge Base article 982867; WCF services that are hosted by computers together with a NLB fail in .NET Framework 3.5 SP1. For more information, see these MSDN Code Gallery pages:
- For additional background information, see KB982867 – WCF: Enable WebHeader settings on the RST/SCT
- For the available downloads, see KB982867 – WCF: Enable WebHeader settings on the RST/SCT.
- Install the update described in Knowledge Base article 979744; A .NET Framework 2.0-based Multi-AppDomain application stops responding when you run the application.
- Install the update described in Knowledge Base article 983440; An ASP.NET 2.0 hotfix rollup package is available for Windows 7 and for Windows Server 2008 R2. For more information, see these MSDN Code Gallery pages:
- For additional background information, see KB983440 – Win7 rollup package (PR for QFE 810219).
- For the available downloads, see KB983440 – Win7 rollup package (PR for QFE 810219).
- Install the update described in Knowledge Base article 977020, FIX: An application that is based on the Microsoft .NET Framework 2.0 Service Pack 2 and that invokes a Web service call asynchronously throws an exception on a computer that is running Windows 7.
Because these are multi-role servers that will hold the Client Access, Hub Transport and Mailbox server roles, you must also install the 2007 Office System Converter: Microsoft Filter Pack (required by the Hub Transport and Mailbox servers).
Afterwards, you must open an elevated Windows PowerShell console, and run the following command:
Import-Module ServerManager
Figure 1: Elevate Windows PowerShell console
Now run the following command in order to install the Windows components required for a typical Exchange 2010 installation:
Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart
Note:
With Exchange 2010 SP1 we also have a new /InstallWindowsComponents switch that can be used when installing Exchange in unattended mode. When using this switch, any necessary Windows components for the specified Exchange 2010 server roles will be installed automatically. One caveat though – The servers typically require a reboot after the Windows components have been installed. So, using the above legacy method is usually just as good as using the new switch.
When the components have been installed, we can install the Exchange 2010 roles on each server. In order to do a typical installation, we would use the following command:
Setup.com /mode:Install /role:C,H,M
When Exchange 2010 SP1 has been installed on all four servers, we can move on to the next section.
Figure 2: The four Exchange 2010 SP1 servers installed in the organization
Client Access Namespace Preparation
One of the most vital pieces to get right from the start is the namespace planning as its somewhat difficult to change when the Exchange 2010 solution is in production.
A good best practice is to use a split DNS model where the same namespace is used internally and externally. That is users will connect to the same namespace no matter if they are connected to the internal network or connected via the Internet. The key difference is the IP addresses associated with the DNS records in internal and external DNS.
So why do you use split DNS in your Exchange 2010 messaging infrastructure? Well that’s an easy one really. First, using split DNS makes the solution way less complex for the administrator point of view (especially when using site resiliency). Secondly, it’s easier to deal with the UC/SAN certificates, the load balancer solution etc. Finally this is a good thing for the end users since they don’t have to remember different namespaces depending on whether they are connected to the internal or external network.
Creating the namespace in Active Directory
In the test environment of this multi-part article, we have an active directory forest containing a single domain named “Exchangeonline.dk”. This is also the name we will use as the Client Access namespace, which means we don’t need to create a new forward lookup zone in DNS. However if you have plans on using a namespace that is different from the Active Directory domain in your forest, you need to create a new forward lookup zone in DNS. Let’s say you have an AD domain named forest-int.local. In this situation you would need to logon to a domain controller and launch the “DNS Manager”. In the “DNS Manager” you would need to expand the domain controller, right-click on “Forward Lookup Zones” and select “New Zone…” in the context menu. This will launch the “New Zone Wizard”. Click “Next”.
Figure 3: Welcome to the New Zone Wizard
Accept the defaults (Primary zone) and click “Next”.
Figure 4: Zone Types
Again usually the default selection is just fine, so click “Next”.
Figure 5: Active Directory Zone Replication Scope
This is where you need to enter the zone name (namespace) you want to use. Then click “Next”.
Figure 6: Zone Name
Accept the defaults and click “Next”.
Figure 7: Dynamic Update
Finally click ”Finish” to have the new zone created.
Figure 8: Completing the New Zone Wizard
Bear in mind that you also need to register this domain name and have the zone created on public DNS servers.
Yes I know this is probably basic stuff to many of you but nevertheless an important step for those that want to use a new namespace for Exchange 2010.
Creating the necessary DNS records
Let’s take a look at the diagram showing the first scenario we’re covering.
Figure 9:
Site Resiliency in Exchange 2010 (active/passive datacenter model)
As you can see you need to create the following records in the new zone in the internal DNS:
- Mail.exchangeonline.dk This FQDN is used by HTTP(S) based clients such as Outlook Web Access (OWA), Exchange Control Panel (ECP), Outlook Anywhere (OA) Exchange ActiveSync (EAS) and services like the Offline Address Book (OAB) and the availability service (AS).
- Failover.exchangeonline.dk This FQDN is used by HTTP(S) based clients such as Outlook Web Access (OWA), Exchange Control Panel (ECP), Outlook Anywhere(OA) Exchange ActiveSync (EAS) and services like the Offline Address Book (OAB) and the availability service (AS) when a full site switch/failover (aka *over) has occurred.
- Outlook-1.exchangeonline.dk This FQDN is used by internal Outlook client connecting to the CAS array via MAPI.
- Outlook-2.exchangeonline.dk Not really used in this scenario since we only have active users in one site at a time. Not even in a *over situation since we aren’t required to change the RpcClientAccessServer property on the mailbox databases when an *over has occurred. It’s important to create this record though since the FQDN will be associated with the CAS array created in the failover datacenter.
And the following must be created in external DNS:
- Mail.exchangeonline.dk This FQDN is used by HTTP(S) based clients such as Outlook Web Access (OWA), Exchange Control Panel (ECP), Outlook Anywhere (OA) Exchange ActiveSync (EAS) and services like the Offline Address Book (OAB) and the availability service (AS).
- Failover.exchangeonline.dk This FQDN is used by HTTP(S) based clients such as Outlook Web Access (OWA), Exchange Control Panel (ECP), Outlook Anywhere(OA) Exchange ActiveSync (EAS) and services like the Offline Address Book (OAB) and the availability service (AS) when a full site switch/failover (aka *over) has occurred.
- Autodiscover.exchangeonline.dk Used to automatically configure Outlook 2007 or Outlook 2010 clients for features such as the availability service (AS), Offline Address Book (OAB) and Outlook Anywhere (OA). Also used to configure mobile devices that support the autodiscover service.
When creating the DNS records make sure to use a TTL of 5 minutes for the mail.exchangeonline.dk and failover.exchangeonline.dk records as shown below. You need to enable the “Advanced” option under “View” in the DNS Manager menu in order to see and configure the TTL value when creating the records. This is so that they update quicker during full *over between datacenters.
Figure 10: Creating DNS records with a TTL of 5 minutes
Conclusion
That’s all for part 3, but stay tuned for part 4 which will be published very shortly. In this part we have checked Active Directory preparation and Exchange 2010 installation on the four servers. Then we created the namespaces required and configured the DNS records.
If you would like to read the other parts of this article series please go to:
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 1)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 2)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 4)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 5)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 6)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 7)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 8)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 9)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 10)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 11)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 12)
- Planning, Deploying, and Testing an Exchange 2010 Site-Resilient Solution sized for a Medium Organization (Part 13)