Once you have Exchange Server 2010 up and running, you shouldn’t think of it as something you provision once and forget about. Apart from the usual day-to-day maintenance, which is inevitable with any server, each Exchange server role needs long-term management.
In addition, you should learn to use PowerShell, if you haven’t yet done so. Many important management tasks for Exchange should be accomplished with PowerShell -- not just because it’s faster than using the graphical user interface (depending on your typing speed), but also because it’s often far more powerful.
As you grow more comfortable with Exchange 2010, you may find places in your organization where you want to rework your implementation. Here we'll discuss best practices for managing the five Exchange Server roles and what to expect from each as you expand your use of Microsoft’s product.
Table of contents:
The client access server role
Client access servers must provide satisfying connections for users, so IT managers must consider network throughput. Administrators should know the limits that the client access server (CAS) role imposes on the number of simultaneous sessions per user and per server via client-throttling policies, which are now turned on by default.
Client-throttling policies can be tuned via the Exchange Management Shell. They can, for instance, allow more concurrent connections or allow the CAS to devote more system time to performing certain requests.
That said, it’s never a good idea to tinker with throttling willy-nilly. Many throttling policies are set by percentages of absolute time -- for example, total amount of time in a given minute to devote to X -- so they scale more or less automatically and intelligently. They should only be changed if analysis of the throttling performance counters reveals a need.
The protocols in use will also affect CAS performance. A Microsoft-authored white paper provides technical details about how the CAS (among other roles) is affected by different access methods. ActiveSync and Outlook Web App (OWA) are the most costly in terms of network and CPU. Outlook is the least CPU-costly, and Internet Message Access Protocol is the least network-costly.
If you use Exchange’s native statistics to get an idea of how much of each resource is being used, you can then adjust protocol use to match your available CPU and bandwidth -- or, if possible, use that knowledge to make recommendations for CPU and bandwidth upgrades.
Don’t forget about security when dealing with the CAS role, especially as workers bring new devices into the enterprise. Secure Sockets Layer (SSL) is a must, especially over a wide area network (WAN) connection when using ActiveSync or OWA. SSL works with the widest range of devices, including those iPads everyone’s itching to bring into the office.
In addition, consider enabling form-based authentication as an enhanced security measure, even if you’re allowing OWA only from within your organization. You should first check to see whether the range of devices used in your organization supports it. Finally, if you’re using Integrated Windows authentication with any CAS services, look into enabling Extended Protection for Authentication.
The mailbox server role
Mailboxes are the guts of Exchange Server, but the database availability groups (DAGs) that hold them are now in some ways even more important. If your experiences with managing Exchange thus far have been limited to or focused on mailboxes, you should also think about DAGs, given their increasing importance to mailbox servers. Become familiar with how mailbox storage and high availability works, and get in the habit of thinking about DAGs as a natural part of the big picture.
If you have a mailbox server in a DAG that needs any kind of maintenance, it should always be formally removed from a DAG and put into maintenance mode before any work is done. This includes hardware upgrades or update rollups for Exchange or Windows Server. When a mailbox server is taken offline, Exchange automatically moves its databases to whichever server it thinks will be the best for them. You can, however, manually redirect databases to a given server -- for instance, if you plan to take all but a given server offline.
If a database is lagging, Exchange provides tools to determine from the inside out—starting with Exchange itself—what the problem might be. The Troubleshoot-DatabaseLatency.ps1 script returns useful statistics that can pinpoint if a database’s lag is the result of a disk problem, a slow domain controller or a general server bottleneck that might call for another mailbox server role system to be rolled out.
If you have an even number of mailbox servers in a given DAG, you must configure at least one Exchange-role machine that’s not a mailbox server as a “witness server” in order to maintain high availability. It’s a good idea to set up a substitute just in case that server goes offline for maintenance or some problem.
Content indexing and the attendant overhead in disk and CPU are other major considerations for mailbox servers. If you plan on allowing Office 2007 and 2010 content to be indexed through a mailbox server role machine, you’ll need to add the appropriate indexing filter packs to the mailbox server.
Indexing PDF files is a slightly different story: You can use Adobe Acrobat’s indexing filter, although a for-pay, third-party filter by FoxIT apparently yields up to five times better performance.
The hub transport server role
If mailboxes are Exchange Server’s guts, then the machines in the hub transport role are the heart. They’re responsible for how mail flow works within your organization. All work involving internal message policies, regulatory compliance, distribution groups, third-party transport agents and message moderation is done through the hub transport role. You can expect to work closely with your legal department over many of these issues, especially message policies and regulatory compliance.
Among the management considerations for hub transport servers is “back pressure.” This hub and edge transport feature prevents the system from running out of vital resources like disk space and memory. A system under heavy load will have incoming connections throttled or rejected by the back pressure system, which to the untrained eye can look like the server simply being balky. The thresholds for back pressure behavior are configurable, but remember that the default settings are the best place to start, so don’t change them unless you have very good reasons.
Delivery-class message throttling policies let you control how many connections, mailbox deliveries or mailbox submissions can take place in a given period of time. These policies also control timeout periods for connectors, such as the “tarpit interval” that slows connections from hosts that may be sending spam. Once again, start with the default policies and only change them if you are debugging specific behavioral scenarios. Exchange (and many Microsoft products) have reached a point where they come with sane defaults and need very little tweaking in most production scenarios.
Multiple hub transports automatically balance delivery loads among them. If you have specific reasons for overriding this, such as network topology, you can alter which messages flow to which hub transports.
Exchange blogger Nicolas Blank offers a great example of this, where he describes how to restrict a given hub transport server for nothing but mail relaying. This is handy if you’re trying to build a hub transport arrangement that complements your existing network topology.
In addition, enterprises often use hub transports for spam control, although this function is normally handled in edge transport servers. If your organization has no edge transport servers, you can manually enable spam control on a hub transport server. Just remember to disable it again if you put an edge transport role into place later.
The edge transport server role
Because edge transport servers sit between your Exchange installation and the outside world, they’re your first line of defense against spam and other unwanted communications. Exchange 2010 itself ships in a locked-down state, so you don’t need to use the security configuration wizard (SCW) with it. That said, it does help to use the SCW on Windows Server itself to make sure you haven’t inadvertently exposed it to danger.
The edge transport is also where most of Exchange’s antispam and antivirus blocking takes place. Third-party antivirus systems are hosted here. Microsoft’s own Forefront Protection 2010 for Exchange Server can also run on an edge transport, but note that some of Forefront’s functions aren’t available there. If you already have Forefront on an edge transport server, but find your management options will benefit from having some of the other scan types available, consider relocating it to a mailbox or a hub transport (as a bridgehead) role server.
Things that you might take for granted with other Exchange server roles are different in an edge transport. For one, edge transports have no direct access to Active Directory (AD); they use the EdgeSync protocol to keep a local cache of the relevant AD information. Edge transports sync every five minutes at most with their attendant AD stores, but that number can be bumped up if needed.
Another key thing has to do with managing how edge transports control message throttling and message size limits. These functions have a bit more significance in an edge transport server than on a hub because they govern the size of messages that come in from and go to the outside world. That affects the overall bandwidth available for mail.
This impact goes double for recipient lists. If you use a lot of them, bear in mind that Exchange 2010 now handles an entire distribution group as a single recipient. You may need to adjust your bandwidth expectations if you use distribution groups in high volume or send out big attachments.
Note that if you have a mix of Exchange 2007 and Exchange 2010 hub role servers, the 2010 servers take precedence in edge-to-hub relationships.
The unified messaging role
Managing a unified messaging server involves a number of things that are entirely separate from Exchange itself, because unified messaging involves interfacing with third-party technologies such as Asterisk.
Be aware of quality of service (QoS) issues, which also involve the instance of Windows Server that the unified messaging role runs on. Unified messaging uses “DiffServ,” which Windows Server 2008 supports via the QoS Packet Scheduler and Group Policy options.
If you are using unified messaging with Office Communications Server 2007, you’ll need to have QoS enabled manually. Also, any routers that manage traffic to and from unified messaging servers must support DiffServ if you want to use QoS on that network fabric.
Unified messaging role servers can each accept up to 200 concurrent voice calls, with 100 being the out-of-the-box default. If you find that the system is being underprovisioned or overprovisioned for calls, you can adjust the total number of concurrent calls and see how that affects the server’s performance.
A lot of the system load will depend on what your users are doing. For instance, voicemail transcription is among the most CPU-expensive processes, and the codecs used will also have an impact. They can affect not only CPU, but also network bandwidth. Microsoft recommends using the G.721.1 codec for any branch-office or WAN-connection scenarios to minimize the amount of traffic needed there.
If you’re planning to virtualize your Exchange installation, note that there was initially no official support for running the unified messaging role in a VM. That has changed: Microsoft now supports a virtualized instance of Unified Messaging in both VMware and Hyper-V.
There are a couple of caveats, however. Unified Messaging must be the only Exchange role on the virtual machine instance in question, and the VM running Unified Messaging must have at least four CPU cores and at least 16 GB of RAM.
When Exchange Server 2007’s concept of roles was introduced, it made Exchange that much more complicated. In some ways, each role works as its own miniature server product, all under the general umbrella of Exchange Server. But this complexity allows you to deploy Exchange in a far more granular and flexible way. The more you work with that instead of against it, the better -- and not just once, but continuously across the lifetime of your Exchange deployment.
ABOUT THE AUTHOR:
Serdar Yegulalp has been writing about personal computing and IT for more than 15 years for a variety of publications, including (among others) Windows Magazine, InformationWeek and the TechTarget family of sites.