Chapter 13
Planning Your Deployment
Deploying any version of Exchange for the first time can be a daunting task. Each version of Exchange has architectural considerations that are different from previous versions. Prerequisites may even change between service packs as well as best practices relating to both the deployment and operation of Exchange.
Understanding what makes Exchange 2013 different from other versions of Exchange is critical to rolling it out successfully.
We have emphasized the importance of trying and verifying processes in a controlled lab setting in this book. In this chapter, we wish to emphasize this point once again. Never deploy Exchange 2013 in your live infrastructure without first installing and understanding the subtleties of Exchange 2013 in your lab environment.
As in other parts of the book, we will refer in this chapter to external documentation, such as the Exchange 2013 installation checklist found at:
http://technet.microsoft.com/en-us/library/ff805042.aspx
Unless you're deploying a single Exchange 2013 server in your lab, you will find that there is more to consider than installing the prerequisites and running setup. The references to external documentation are quite necessary, because the requirements or practices for deploying Exchange vary from time to time. This chapter is not meant to replace the Exchange Server 2013 Deployment Assistant found at http://technet.microsoft.com/exdeploy2013. It is meant to augment the assistant with additional processes and best practices.
Very few deployments are as simple as deciding to install Exchange 2013, downloading the latest Cumulative Update (CU), and running setup. Even a single server hosting a few mailboxes requires a minimum amount of planning.
Irrespective of whether you have one or dozens of servers to install, your minimum pre-deployment checklist should be similar to the following:
The minimum Active Directory requirements to deploy Exchange 2013 are as follows:
Planning for the changes that need to be made to Active Directory is essential. The setup process as well as the prerequisite service packs for earlier versions of Exchange may extend the Active Directory schema, which, depending on the size of your Active Directory, may impact replication. Active Directory replication must be completed before the first Exchange 2013 server can be introduced into the domain. Active Directory preparation occurs when installing the first Exchange 2013 server via any setup method. Nevertheless, a number of organizations prefer to introduce Active Directory changes by the team responsible for Active Directory, not the team responsible for Exchange.
As with earlier versions of Exchange, Active Directory schema extension may be done as part of installing the first Exchange server or as a separate step via the command line, specifically setup /PrepareSchema or setup /ps. The account used to run setup must be part of the Schema Admins group and the Enterprise Admins group. Setup must be run on a 64-bit machine that is in the same domain and the same Active Directory site as the schema master. For example, if the schema master is in the root domain of your forest, then you would run setup in the root domain.
Note that the schema extension process is included in the next step of preparing Active Directory, as well as in installing Exchange via the GUI.
This step updates and/or creates the required objects in the Active Directory configuration container, which stores most of Exchange 2013's configuration information.
Note that for the following command line, the parameters in square brackets are optional. If a previous version of Exchange exists in the forest, then the OrganizationName may be omitted. From a command line run
setup /PrepareAD [/OrganizationName:<organization name>]
or
setup /p [/on:<organization name>].
As with the schema extensions, these commands will require Active Directory replication to complete.
The account used to run setup must be part of the Enterprise Admins group. As with the previous step, setup must be run on a 64-bit machine that is in the same domain and the same Active Directory site as the schema master. The machine must be able to contact all domain controllers in the forest on port 389.
This step updates domains for Exchange 2013 or, if necessary, it creates the required objects for Exchange 2013. You must prepare every domain into which Exchange 2013 will be installed. If this command is run in a child domain, then replication from the other two commands must finish or setup will fail.
From a command line, run setup /PrepareDomain or setup /pd to prepare the local domain in which you are running setup.
Run setup /PrepareDomain:<FQDN> where <FQDN> is the fully qualified domain name of a specific domain to be prepared.
Run setup /PrepareAllDomains or setup /pad to prepare all domains in the forest.
The account used to run setup must be part of the Enterprise Admins group to run setup /PrepareAllDomains. In order to run setup /PrepareAD, the account must be part of the Domain Admins group. As with the previous step, setup must be run on a 64-bit machine.
At this point in the chapter, we assume that in order to become familiar with Exchange 2013, your first install will occur in a lab in the virtual environment of your choice. As we called out in Chapter 2, “Exchange Design Fundamentals,” your virtual environment for both lab and production should be listed in the Server Virtualization Validation Program found at:
http://www.windowsservercatalog.com/svvp.aspx?svvppage=svvp.htm
In order to design a rollout process, you need to decide if your deployments will be interactive (that is, an administrator installing Exchange 2013 via the GUI or the command line), or if the process will be unattended and entirely scripted. In order to make this and other rollout decisions, you need to build and test your process in a lab that is representative of your live environment.
The ultimate purpose of the lab beyond becoming familiar with Exchange is to roll out Exchange 2013 for the first time as per the design. This allows administrators to familiarize themselves with the new product, as well as generate the operational documentation that may be required, such as build guides, administrative and helpdesk documentation, and so forth.
Once you have gained familiarity with Exchange 2013, you may then design a rollout process to suit the organization's needs. Such needs may vary along a spectrum from running the setup process on every machine manually, to building a scripted process that starts with a non-domain-joined machine, or to a fully configured Exchange 2013 server.
When deploying a newer version of Exchange into an existing organization, it is customary to redirect incoming client requests to Exchange servers with the newest version of Exchange. The newest version tends to be shipped with the logic for redirection and coexistence with previous versions of Exchange.
When installing Exchange 2013 into an existing Exchange 2010 or Exchange 2007 organization, the following need to be considered:
Exchange 2007, Exchange 2010, and Exchange 2013 are all capable of accepting email from the Internet and routing to the correct mailboxes; however, there is much to consider besides Internet-based mail flow when considering SMTP mail flow interaction for an organization.
MX records are DNS records that define the email delivery location for a given domain. MX records will need to be updated to point to the Exchange 2013 servers during the migration. Considering the complexity of the organization, this may occur at the 50 percent mark of user migration, or it may occur after all mailbox migrations have been completed.
Incoming Internet email is one of the considerations as is outgoing mail flow. Exchange 2013 servers may be added to existing send connectors, or they may have dedicated send connectors created, in order to route outgoing mail by version of Exchange. Send connectors may reflect external as well as internal SMTP name spaces for which Exchange may route email. You need to consider the mail flow via Exchange to these systems when planning for mail flow cutover.
The greatest point of complexity in the migration, however, is not Internet mail flow but rather interorganizational mail flow, which includes down-level versions of Exchange, journaling, other application integration such as SharePoint, and devices including multifunction devices that relay via the older version of Exchange.
Finding and documenting the various elements that send mail via Exchange can be a considerable and daunting task, unless updated configuration documentation exists. Consider enabling verbose logging on the receive connectors used to accept mail from devices for a period of time in order to assist with device discovery.
Many devices in the enterprise may need to have their configuration changed to reflect new destination IP addresses for the newer Exchange servers.
Starting with Exchange 2007, Exchange administrators were required to be familiar with the process of creating SAN certificates or wildcard certificates. While the new Certificate Wizard in Exchange 2013 certainly makes certificate creation easier, the following considerations still apply:
Exchange 2013 provides more load-balancing choices than any previous version of Exchange. The fact remains, though, that some form of load balancing is required in order to ensure that traffic is distributed evenly among CAS servers in the local site.
Exchange 2013 CAS no longer requires affinity for client connections, which allows load balancing to occur at Layer 4 as opposed to Layer 7. At Layer 4, the load balancer is unaware of the application for which it is load balancing; it load balances toward a pool of IP addresses and a port, for example, TCP 443.
At Layer 7, the load balancer is aware of the application it is load balancing, and it is configured toward the target URL, for example, /owa, /ews, and so on.
At Layer 4, load balancers are able to direct significantly more traffic than at Layer 7, since the processing overhead is vastly reduced. Application health, however, is very difficult to track. A Layer 7 device may be able to inject a synthetic transaction toward OWA and adjust its load-balancing profile based on the response. Typically, at Layer 4, a load balancer can track whether TCP port 443 is responding.
At Layer 4, you are faced with choices not available to you in previous versions of Exchange, specifically using DNS round robin as a load-balancing mechanism. DNS round robin returns a list of IP addresses to the requesting client. The client is then able to try each address in turn for a response. A modern HTTP-based client has fault tolerance and retry behavior built into it that allows you to add DNS round robin as a valid choice to your list of potential load balancers. While DNS round robin is a supported choice, it should not be considered except for very small or lab deployments, since it is not service aware. It will continue to balance requests to CAS servers that are down or out of service.
A simple Layer 4 load balancer will distribute incoming requests among all available servers, with respect to the availability of TCP port 443. DNS round robin distributes requests to all CAS servers defined in DNS, irrespective of their status. Together with DNS round robin, a device at this layer offers a single, unified name space with speed and simplicity.
Moving up the functionality scale, load balancers offer per-protocol availability (OWA, EWS, SMTP, and so forth) as well as the ability to define one name space (OWA, ActiveSync, EWS, SMTP) per protocol.
At the top of the scale, load balancers are able to offer all of the previously mentioned features as well as SSL bridging and a single, unified name space. Exchange 2013 no longer supports SSL offloading at the load balancer. Exchange 2013 supports SSL bridging, where the connection is terminated at the load balancer and then re-encrypted toward the Exchange 2013 CAS server.
The downside is that, at this level, considerable networking skills are required in order to configure and maintain the load balancer.
Choosing a load balancer for Exchange 2013 depends entirely on the level of service required by the business. Most organizations will benefit from some level of load balancing, one level up from DNS round robin. While DNS round robin is a viable alternative for very small or lab implementations, it does not offer the level of service required to meet a stringent SLA.
Since Exchange 2013 offers Managed Availability, which tracks which CAS servers are able to answer requests and redirects them to the healthiest node, Layer 4 devices with the ability to check on the health of a CAS server based on protocols such as OWA will normally meet most availability requirements.
At the top end of the scale, SSL offloading and other high-end features are not in as much demand as in previous versions, since modern Exchange servers tend to be less processor bound.
Starting with the availability requirement for each site, you must weigh the risks against the costs and benefits of each load-balancing choice level. Some sites may deploy DNS round robin, whereas larger datacenters may benefit from medium-level Layer 4 devices or even high-level Layer 7 devices.
Although there is no one-size-fits-all answer for this choice, a number of vendors have certified devices for use with Exchange 2013 with a range of virtual and physical devices from which you may choose.
Operating system-based antivirus programs will not protect against email-based worms or Trojans. However, they do offer a greater level of protection of the host itself. Very few environments are secure enough to run without any operating system-based antivirus software. In our opinion, operating system-based antivirus software must be configured correctly, or an outage or data loss will inevitably occur. The few customers who are unable to set and maintain the correct exclusions for Exchange 2013 in their environments should not be using antivirus protection because of the risk presented to Exchange and Exchange-based data.
Operating system-based antivirus software intercepts and inspects file-level activity, among other things, such as preventing communication via network ports, which is deemed unsafe. An incorrectly configured operating system-based antivirus product may break Exchange and/or cause data loss by deleting or quarantining an Exchange log file before it has been written to a local database or shipped to a remote database in the case of a database availability group (DAG). In some cases, antivirus products have been known to edit an Exchange database directly in order to remove what was considered to be a virus, thereby rendering the Exchange database unusable and causing an outage.
In our experience, operating system-based antivirus products have occasionally interfered with Exchange, even when explicit exclusions have been set. Therefore, you should approach this setup with caution. This does not mean, however, that we are recommending that operating system-based antivirus programs should not be deployed. We are recommending that they should be deployed strictly in accordance with the guidelines set out in the TechNet article “Anti-Virus Software in the Operating System on Exchange Servers,” which specifies the recommended directory exclusions, process exclusions, and filename extension exclusions:
http://technet.microsoft.com/en-us/library/bb332342(v=exchg.150).aspx
While troubleshooting an issue with Exchange such that it is unable to execute a particular task that it should be able to perform, you may want to uninstall the operating system-based antivirus product completely and reboot the Exchange server in order to ascertain if the issue is removed or resolved.
Per the guidance provided for previous versions, Exchange 2013 should not be firewalled or segmented away from other Exchange servers or any Active Directory domain controllers to which it may need to connect. Because of the distributed nature of Active Directory, this includes Active Directory domain controllers in other Active Directory sites. Some customers insist on placing firewalls between Exchange servers; however, these need to be configured with a rule allowing “ANY/ANY” port and protocol communication between Exchange 2013 servers and any Active Directory domain controller in the forest.
While significant documentation exists for those ports and protocols that Exchange 2013 and earlier versions use, this documentation should not be confused with a guide for configuring firewalls that could separate Exchange servers from each other.
Exchange client subnets, however, may be firewalled from Exchange servers. The port and protocol segmentation required for load balancing effectively supplies a rule of thumb for firewalling Exchange clients from Exchange servers. Depending on your client configuration, the list of allowable protocols between Exchange clients and servers includes the following:
Pre-authenticating gained popularity with products such as Microsoft Forefront Threat Management Gateway (TMG) and Microsoft Unified Access Gateway (UAG). However, with the announcement by Microsoft that no further development will take place on Forefront Threat Management Gateway and that the product would no longer be available for purchase as of December 2012, many Exchange customers were left wondering what they should do. For customers with existing TMG installations, updated guidance is available that demonstrates how to publish Exchange 2013 securely. Publishing Exchange 2013 via TMG is fully supported and greatly extends the usable lifespan of TMG, up to the end of the support life cycle. Customers who have deployed UAG can publish Exchange 2013 as of UAG Service Pack 3. Several firewall vendors offer reverse-proxy functionality, allowing Exchange 2013 and other services to be published securely to the Internet.
A number of load-balancing vendors now offer pre-authentication as part of their suite of products for load balancing Exchange. While this method of publishing Exchange is popular, it is not required in order to publish Exchange 2013 securely to the Internet.
Microsoft supports publishing client ports via a load balancer directly to the Internet without any intermediary authentication of client traffic, as evidenced by the Microsoft on-premises deployment of Exchange as well as Exchange Online.
The largest change for email clients in Exchange 2013 is the use of Outlook Anywhere as the only method of connectivity for Outlook clients. Outlook 2007, Outlook 2010, and Outlook 2013 are supported email clients, but Outlook 2007 and 2010 require updates before Exchange 2013 can be introduced. Outlook versions prior to Outlook 2007 are not supported.
Apple-based clients are required to upgrade to an email client with support for Exchange web services, such as Entourage 2008 Web Services Edition or Outlook for Mac 2011. Apple-based email clients that require DAV, such as Entourage 2008 and Entourage 2004, are no longer supported.
In summary, the following is the list of supported clients for Exchange 2013 with required patches:
The Exchange Load Generator (LoadGen) and Microsoft Jetstress are tools designed to stress test Exchange 2013 as valid for deployment.
In Chapter 5, “Designing a Successful Exchange Storage Solution,” we described how Jetstress validates the storage deployed with Exchange as fit or unfit for production.
LoadGen creates load on a preproduction Exchange system by simulating different types of users. Email is sent and received to generate a user-defined load pattern, the result of which is then interpreted in order to validate that a deployment matches the sizing stipulated in the Exchange design as well as that the Exchange deployment is fit for production. Note that LoadGen is not supported to run in production.
Both LoadGen and Jetstress are useful in your pre-deployment testing, but only Jetstress should be considered mandatory before commissioning Exchange.
Before Exchange is considered “live,” a number of tests are normally conducted. These include mail-flow testing, database-failover testing, and Exchange server failover testing in the case of high-availability deployments. Nevertheless, the final and arguably most important test mechanism is pilot users. A small group of pilot users is selected in order to validate the desired functionality of the Exchange 2013 implementation. These users' mailboxes are first moved to the system, and they are required to use the email system as they would under normal circumstances. This type of testing is generally referred to as user acceptance testing, and it is common practice when adopting a new system.
If no modifications to Exchange are required, this pool of users is widened to a larger and larger audience until the “all clear” is given to migrate the remainder of the user population. These steps help validate and correct any flaws in the design and/or implementation of Exchange.
Deploying Exchange for the first time, or for the nth time, requires a certain amount of rigor and process to be applied. Correct interpretation of the design and subsequent planning are part of the process. While implementing and while still in preproduction, design validation using Jetstress is an essential step. Besides testing Exchange functionality, consider adding user acceptance testing as part of your acceptance procedures for signing off the Exchange implementation.