By now you know about the upcoming release of Exchange Server 2007, formerly code-named Exchange 12. You might even be familiar with some of the new features and capabilities included in the new product; Microsoft has spent a great deal of effort to improve Exchange by adding new features, fixing old ones, and redesigning some components. You can read more about these enhancements in the Windows IT Pro article "Surveying Exchange 2007," June 2006, InstantDoc ID 50052. With Exchange 2007's release right around the corner, it's time to start thinking about your deployment strategy. Here are five key points you'll need to know to effectively plan and deploy an Exchange 2007 architecture.
1: More Roles for Servers Mean Less Work for You
Exchange Server 2003 supports two server roles: Back-end servers host mailbox and public folder databases, and front-end servers serve as proxies between clients and back-end servers. In Exchange 2007, Microsoft has expanded the range of supported server roles, adding several roles that don't have direct counterparts in Exchange 2003. A single server can have any or all of these roles:
- Client Access Server (CAS)—acts as a proxy server for client connections for non–Messaging API (MAPI) connections. You can think of servers with this role as the replacement for Exchange 2003 front-end servers, although the CAS role does a good bit more than simply act as a front-end server. The CAS role provides Microsoft Outlook Web Access (OWA) service and service to mobile devices that use the Exchange ActiveSync (EAS) protocol.
- Mailbox server—holds mailboxes and accepts MAPI connection requests from clients.
- Edge Transport server—provides message filtering, including antispam and antiphishing capabilities. Edge transport servers don't need to be part of the organization's Active Directory (AD) forest, and you can safely place them inside the network demilitarized zone (DMZ). They can maintain their own Active Directory Application Mode (ADAM) directory, which is synchronized with the organization's AD forest.
- Hub Transport server—moves mail between mailbox servers within the organization. This role is new; in earlier Exchange versions, mailbox servers move their own mail. However, because you can add the Hub Transport role to a mailbox server, there's no explicit requirement that you have a dedicated server in this role—but the ability to separate internal and external mail transport is a nice feature.
- Unified Messaging (UM) server—routes communications between private branch exchange (PBX) or telephone systems, CASs, and mailbox servers. The UM server role acts as a gateway for voice and fax data, sending new incoming messages to your mailbox and retrieving mailbox data for use by Outlook Voice Access (OVA).
Exchange 2007 has a new version of Exchange System Manager (ESM) called the Exchange Management Console (EMC). EMC lets you view servers by role, as Figure 1 shows, so you can quickly see, for example, which CAS servers you currently have. In fact, EMC has been revamped with a much more intuitive interface that makes it easier to find the right objects and commands to accomplish a given task, as Figure 2 shows. As a bonus, EMC's new Toolbox interface provides links to a variety of useful tools, including the Exchange Server Best Practices Analyzer, as Figure 3 shows.
Robert Quimbey of the Exchange team wrote a terrific blog post "Exchange 12 Server Roles and Disk IO" (http://blogs.technet.com/exchange/archive/2006/04/07/424645.aspx), which describes the effect of CASs and mailbox servers on disk I/O. I recommend you read it and its companion posts about other server roles to determine the hardware configurations that will best meet your implementation needs.
2: You Must Be 64 to Enter
In the past, Microsoft has specified a particular processor architecture (e.g., Pentium III) as the baseline for a given product. However, in late 2005, the company made a somewhat different announcement—that Exchange 2007 will run only on 64-bit CPUs from Intel and AMD. (Note that Exchange 2007 doesn't and probably won't run on Intel's Itanium architecture.) The beta builds of Exchange 2007 are available in both 32- and 64-bit versions, but the shipping version will be available only for 64-bit hardware. Therefore, if you're buying servers now, you should ensure that they support either Intel Extended Memory 64 Technology (EM64T) or AMD Opteron architectures—no Celerons, please.
To run Exchange 2007, you'll need the 64-bit version of Windows Server 2003 and the appropriate 64-bit–compatible drivers and versions of certain applications you run on your Exchange server. In particular, any application that requires a kernel-mode driver (e.g., replication software, some types of SAN software) will need 64-bit versions. Some vendors do a better job than others of supporting new OS or CPU versions, and a slow vendor might slow your ability to deploy Exchange 2007, so it's wise to begin planning for this transition now.
Fortunately, the odds are good that if you purchased your current server hardware within the last 12 to 18 months, it already supports one of these architectures,although you probably don't have as much RAM in these servers as they support. Exchange 2007 running on the 64-bit version of Windows 2003 can use several gigabytes of RAM for caching (compared with an upper limit of about 900MB for Exchange 2003 running on 32-bit Windows 2003), and this extra RAM makes a huge performance difference. One key Exchange 2007 goal was to enable the use of large mailboxes while reducing the total I/O required for those mailboxes; adding RAM achieves that goal. Fortunately, it's much less expensive to add RAM than to buy more disks, which is what you'd have to do to get similar scalability on Exchange 2003. Unfortunately, you'll have to do a swing upgrade to get Exchange 2007 onto your 64-bit hardware; there's no way to do an in-place upgrade of Exchange 2003 on 32-bit Windows to Exchange 2007 on 64-bit Windows. You can find more information about upgrading using the swing method in the Microsoft article "How to upgrade to Exchange Server 2003 by using the swing upgrade method" (http://support.microsoft.com/?kbid=821896).
3: PowerShell Is Your Friend
Exchange 2007 is the first Microsoft product to take full advantage of Windows PowerShell, formerly known by its code name, Monad. PowerShell is a powerful object-oriented (OO) scripting language that provides some of the best benefits of UNIX-style command lines while closely integrating with Windows, AD, and Exchange. More correctly, I should say that Exchange 2007 includes the Exchange Management Shell, an extended version of PowerShell. Every action available through EMC is also available through the Exchange Management Shell—a huge relief to people who want or need to script their Exchange maintenance or setup operations. In addition, some advanced tasks can be carried out only from the command line. Because you can extend PowerShell by adding your own cmdlets (i.e., managed code objects), you can customize your command-line environment to a high degree. Third parties will be able to take advantage of this functionality, too, to extend their own products and make them scriptable from within PowerShell. The best way to get used to PowerShell is to try it, either by downloading the beta version at http://www.microsoft.com/windowsserver2003/technologies/managment/powershell/default.mspx (it runs on Windows 2003 and Windows XP) or by using the Exchange-specific version included with Exchange 2007.