Preparing to Deploy Exchange 2010

New software brings new challenges, and Microsoft Exchange Server 2010 is no different. The urge to take the shrink-wrap off the new software is intense, but foolish administrators rush to deploy where hard-bitten and scarred practitioners pause for thought. Before deployment can begin, you need to understand the prerequisites that exist and the obvious pitfalls to avoid. This article describes what you need to do to prepare to deploy Exchange 2010 into new or existing organizations.

Get the OS Right

A solid implementation of the OS provides the foundation of any successful deployment. Exchange 2010 supports both Windows Server 2008 SP2 and Server 2008 R2. The most sensible option is to deploy on Server 2008 R2 because Microsoft doesn't support an OS upgrade after you install Exchange 2010 on a server. Thus, you can deploy Exchange 2010 and Server 2008 SP2 and plan for a complete refresh subsequently, or you can deploy Exchange 2010 and Server 2008 R2 and anticipate stability at least until the next major release of Exchange or Windows Server appears.

You'll have to deploy other software to create the right environment for Exchange 2010, including Windows Remote Management, the latest version of the .NET Framework, Windows PowerShell 2.0, various Windows components such as the Active Directory (AD) management tools, and various server roles. See the Microsoft article "Exchange 2010 Prerequisites" for more information.

If you scan the Internet, you’ll find scripts that others have written to prepare servers for Exchange 2010, mostly by installing the long list of server features that Exchange depends on. I’ve used the script posted at www.ucblogs.net/files/folders/powershell/entry125.aspx to prepare a server, and it worked well. Be sure to test any script you download before you use it in production, and always verify that you understand what the code does because you don’t want to take any chances by downloading and running unverified code.

Be sure to check for required OS upgrades and hotfixes before you install servers. Exchange touches many parts of the OS and has a track record of exposing weaknesses. Microsoft IT discovered a problem with NTFS deadlocks on heavily loaded Mailbox servers soon after they deployed Exchange 2010 internally. This problem is specific to Server 2008 SP2 and required administrators to kill store.exe to free the condition, so it was pretty serious. Microsoft released a hotfix, which you can download from Microsoft Support, but it's a good example of the kind of problem that comes to light when new combinations of OS and applications go into production.

Get Your Infrastructure Ready

Exchange 2010 requires AD to operate in Windows Server 2003 functional mode, so you can upgrade the forest to this level now if you haven't already done so. Exchange 2010 extends the AD schema, too. In fact, the same schema extensions are applied if you deploy Exchange 2007 SP2. If you plan to run Exchange 2010 in an existing Exchange organization, you have to make sure that legacy servers run at least Exchange 2003 SP2 or Exchange 2007 SP2 before you can deploy the first Exchange 2010 server; no Exchange 2000 servers can be present in the organization.

Microsoft has invested a lot of energy in the development of the Exchange Server Best Practices Analyzer (ExBPA) and has incorporated it into the Exchange 2010 installation procedure to run preinstallation checks to validate that you're ready to deploy Exchange 2010. If you're already running an older version of Exchange, you can take a proactive step and run ExBPA at any time to see whether your organization is functioning properly. This step won’t tell you if your organization is ready to support Exchange 2010, but it will pinpoint any obvious problems that you should address before you get serious about moving to Exchange 2010.

What to Do About Hardware

Server hardware is next on the list. Any server shipped since about 2006 should be capable of running Exchange 2010, so there's no immediate need to invest in new hardware unless you’re making a move from Exchange 2003, which might still be deployed on 32-bit hardware rather than the 64-bit systems required by Exchange 2010. However, remember that you can't upgrade a server in place; you have to make a fresh start with Server 2008 R2 and Exchange 2010.

There's a natural temptation to deploy new software on new hardware. If your servers are older and becoming harder and more expensive to support—say, three years old or older—they struggle with the existing load, or they're simply not available enough because of current demand, you probably need to invest in new servers. A desire to deploy virtual servers is another reason to consider new hardware because vendors are increasingly focusing the latest multicore servers on being great virtualization platforms.

Finally, if your current Exchange organization runs a configuration that isn't supported by Exchange 2010, you might need to upgrade your hardware. These unsupported configurations include single copy or "classic" mailbox clusters and the variants on cluster replication available in Exchange 2007. These high-availability options have all been replaced by the Database Availability Group (DAG) in Exchange 2010. It's possible to deploy a DAG for even small installations, but we're still learning how to leverage DAGs to run on a small number of servers so you should take time to figure out your high-availability needs and then how to use the Exchange 2010 technology to satisfy those requirements.

Of course, you might be able to reuse existing servers for Exchange 2010. The usual approach would be to follow these steps:

Note that Microsoft doesn't provide 32-bit versions of Exchange 2010. Workstations have to run 64-bit versions of Windows 7 or Windows Vista before you can install the management components, Exchange Management Console (EMC) and Exchange Management Shell (EMS). Exchange 2010 includes a new web-based management utility called the Exchange Control Panel (ECP) that includes tasks such as recipient management (basically, working with properties of mailboxes, groups, and contacts). You don't have to install anything except a recent browser—Microsoft Internet Explorer (IE) 7.0 or later, Firefox 3.0 or later, or even Google Chrome—to be able to use ECP, but most administrators will find that the current iteration of ECP is somewhat limited and best suited to Help desk or support personnel and will need to use EMC or EMS to fully maintain the organization. You should use 64-bit hardware for test boxes as well, although it's possible to deploy small test environments on 32-bit workstations by using virtualization software that supports 64-bit environments. And of course, you can always use RDP to connect to a server and run EMC there to perform management operations.

Server Workload

Exchange 2010 Client Access servers do more work than their Exchange 2007 equivalents because they handle all client connections. MAPI clients are handled by a new RPC client access layer. This reorganization lets Exchange break the link between server and database, a development which is exploited by the DAG to achieve resilience against server and storage failure. In other words, all previous versions of Exchange have a fixed connection between the database that hosts a mailbox and the server where it's located. Servers in a DAG can move connections between database copies as conditions in the DAG change. The RPC client access layer directs incoming client connections to the current live database for the associated mailbox instead of always going to a fixed server. The results of full performance tests in production environments aren't yet available, but a rule of thumb suggests that you can expect a double workload for Client Access servers. Hub Transport servers boast some useful new features but generally do much the same work as in Exchange 2007 and shouldn't cause problems.

Mailbox servers benefit from the changes Microsoft made to the database schema to reduce I/O demand. However, you have to compare apples to apples to get an accurate view of server performance. You'll see the improvement if you run Exchange 2010 in exactly the same configuration as Exchange 2007. Your results will be different if you decide to exploit some of the new features such as supporting much larger mailboxes (5GB is a typical figure) or archive mailboxes. New features always consume extra resources, so be sure you understand the full context before you settle on a server configuration.

What to Do with Storage

The reduction in I/O demand has received a lot of attention because it lets Exchange support low-cost storage. In the past, the relatively high I/O demand exerted by Exchange servers made system designers use SAN-based storage for high-end systems. SAN-based storage has been the cornerstone of many successful corporate storage architectures, but it's expensive and complex. Exchange 2007 offers lower I/O demand than previous Exchange versions, but really only for small mailboxes (200MB or less).

Apart from some tinkering with page size in Exchange 2007, Microsoft never really bit the bullet to redesign the internal workings of the Information Store until now, but the early signs are that the new schema contributes to a much lower I/O demand—on the order of 0.25 I/O operations per second per active mailbox. This improvement, taken together with the additional resilience available through the deployment of multiple database copies in a DAG, makes it feasible to deploy disk configurations such as Just a Bunch of Disks (JBOD) arrays that would never have been considered for Exchange in the past.

Backup and Other Third-Party Applications

Exchange 2010 doesn't support streamed backups. Instead, you have to deploy a Microsoft Volume Shadow Copy Service (VSS)–based backup solution. Now is a good time to review how you perform backups and to make any changes that are required to prepare for Exchange 2010. Check with the vendor of your current backup software about when they'll have an upgraded version. The same advice applies to any other third-party solution in your organization, including RIM's BlackBerry Enterprise Server, which definitely requires a new version to support Exchange 2010. Microsoft has made many changes to the Store and APIs in Exchange 2010, and most third-party applications need to be upgraded before they'll run properly. Some APIs, such as WebDAV, aren't supported by Exchange 2010, so applications that depend on these APIs are simply not supported.

On a positive note, it's possible some software you run now is no longer required because of the new Exchange 2010 features or improvements that Microsoft has made to the way the product works. For example, some companies deploy software that regularly rebuilds databases to free up disk space. This procedure hasn't actually been required since Exchange 2003 because Exchange itself does a good job of online defragmentation to reuse white space in databases, so these products are good candidates to be decommissioned. Archiving software might be another candidate because Exchange 2010 lets you assign archive mailboxes to users and includes a range of other features to enable better indexing and discovery of information kept online to meet legal and regulatory requirements. All of this proves that you should take an inventory of third-party applications and ask whether you need them after Exchange 2010 is deployed. If you do, get a new version from the vendor. If you don't, be happy that you've saved some money.

Get to Know Exchange 2010

No deployment is possible if you don't understand the software. Exchange 2010 has many changes that affect systems administration. The two biggest changes are the introduction of Role Based Access Control (RBAC) and PowerShell 2.0, which includes remote PowerShell. RBAC replaces the permissions model used in previous versions of Exchange and is designed to give administrators the correct level of access to Exchange objects to get their job done. Organization administrators have access to every object from servers to connectors to mailboxes; Help desk personnel might just be able to update recipient objects to change their phone number; and users can update only their personal information. RBAC has a much larger influence over large deployments where multiple administrators work; it's much less important for deployments managed by a few "all-powerful" administrators who likely have access to everything.

Using remote PowerShell means that rather than running PowerShell locally on a server, all access to the code that implements Exchange functionality (what the development team calls “business logic”)—provided in the form of an expanded set of cmdlets—flows through Windows Remote Management, Microsoft IIS, and RBAC. Access is always remote, even when running on an Exchange server. The intention is to ensure that all connections to Exchange flow through a gate where access can be validated and tailored for the requesting user. For example, when you start EMS, RBAC determines what access level you have and provides a tailored set of cmdlets that lets you do your work. The same happens when you start EMC: The UI includes only options that you're allowed to access.

RBAC and remote PowerShell are just two of the many changes that occur across the product, but they underscore the need for administrators to upgrade their knowledge to fully understand Exchange 2010 before they even think about installing a server.

The Online Option

Of course, you don't have to deploy Exchange 2010 yourself. You can let Microsoft do the job for you and connect to Exchange 2010 through Microsoft Business Productivity Online Standard Suite (BPOS). Microsoft has invested a lot of engineering effort to make Exchange 2010 operate as smoothly in a hosted environment as it does for on-premises deployments, and using BPOS is a viable alternative for many companies that use Exchange only as an email server and don't have special needs for data retention, privacy, extended security, or legal and legislative functionality that's still best delivered through an on-premises deployment. At press time, Microsoft hadn’t yet deployed Exchange 2010 as the basis of its BPOS service, but this event will occur in the near future.

Maximize the Joy

Like any major upgrade of a server application, Exchange 2010 delivers a mixture of joy, with its new features and enhancements, and pain, in the cost to prepare for and then execute the deployment. The trick is to maximize the joy while minimizing the pain, and good preparation is key to achieving this goal. Don't expect to deploy Exchange 2010 successfully without putting in the effort to understand the full context of your existing installation, including third-party applications. Take your time, prepare well, and then execute. It's much better than plunging in only to fail.