Points to ponder when planning your Exchange 2007 deployment
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.
4: The Server Becomes Your Secretary
Exchange 2007 includes some spiffy new features targeted directly at end users. Chief among them are improvements to calendaring and resource booking, including a new service, Calendar Concierge, that runs on the server and tentatively accepts meeting requests. Why is Calendar Concierge such a big deal? Imagine that you're an Exchange 2003 user who's using OWA or a mobile device as the primary means of accessing your mailbox. Outlook will tentatively add meeting requests to your calendar, but only when it's running. If you don't use Outlook, or if you're frequently disconnected because you're traveling, your calendar free/busy data won't be up to date. The Calendar Concierge fixes this by handling meeting requests for you; it also consolidates multiple updates for the same meeting so the updates don't clutter up your inbox. (Figure 4, shows OWA's improved calendaring interface.)
The new Scheduling Assistant in Microsoft Office Outlook 2007 also takes advantage of a new server-side component, the availability service. This service provides real-time free/busy information directly from users' mailboxes; it replaces the old Schedule+ Free/Busy system public folder for Outlook 2007 clients. In addition to finding the best possible meeting time for all invited attendees, the availability service lets you specify more granular permissions for your free/busy data. For example, you can control who can see ordinary free/busy data (as you can in Exchange 2003/Microsoft Office Outlook 2003), then grant access to additional calendar data (including the meeting description, location, and so on) to a subset of people who need that access. This is both easier to manage and more secure than the conventional delegation model, and it's much simpler for users to set up.
From a design and deployment perspective, the use of these services means that the CAS role will assume equal importance with the mailbox server in terms of what users need to get their jobs done. Microsoft hasn't yet issued any recommendations about whether dedicated CAS servers are required for given topologies, but no doubt the company will do so as we get closer to the Exchange 2007 release to manufacturing (RTM) date.
5: Outlook and Exchange: A Beautiful Friendship
Outlook 2007 and Exchange 2007 work better together. Big surprise, right? Apart from the Scheduling Assistant, Outlook's other big Exchange-specific feature is its new automatic discovery feature, which lets you set up Outlook profiles based only on the user's email address—Outlook will query an Exchange 2007 autodiscovery server, which in turn will query AD to find the user's mailbox server and the rest of the necessary configuration information. Once Outlook gets the necessary data back from the autodiscovery service, it can automatically create the user's profile, even for remote procedure call over HTTP (RPC over HTTP) connections.
Outlook 2007 also enables another useful Exchange 2007 feature: tailored out-of-office notifications. Users can create separate out-of-office messages for internal and external users and set a start time and stop time for the period for which they want out-of-office messages to be sent. However, administrators will still control which users can send out-of-office messages to the outside world.
Just the Beginning
There's far more to Exchange 2007 than I can cover in a single article, but this preview should help point out some features, functionality, and concerns that you need to keep in mind when designing your Exchange 2007 messaging environment. We'll continue to cover Exchange 2007's new features, both here and online, but this should be enough to whet your appetite for more.