• Sidebar: Upgrade and Migration Issues
• Sidebar: Antispam Protection: Exchange IMF or Forefront?
• Illustration: Exchange 2007 Roles
• Illustration: Revamped Administration Console

In addition to new features aimed at end users, Exchange 2007, the new version of Microsoft's e-mail server software, offers IT professionals a slew of important new capabilities—increased security, scalability, availability, and manageability—that should drive down costs while lessening IT workloads. However, these features are most useful for larger organizations that need multiple Exchange servers; benefits to small customers are more modest. Furthermore, since Exchange 2007 will be available in a 64-bit version only, an upgrade from Exchange 2003 is not nearly as simple as was the upgrade from Exchange 2000 to 2003.

This article does not cover new features in Exchange 2007 and Outlook 2007 pertaining to end users; these are detailed in "Outlook 12 Adds Internet Hooks" on page 24 of the Jan. 2006 Update, and "More Than Unified Messaging Coming to Exchange 2007 Users" on page 3 of the Dec. 2006 Update. New Exchange 2007 compliance features that help organizations meet business document-retention regulations are covered in "Exchange 2007 Assists Regulatory Compliance". Future Update articles will cover Exchange 2007's unified messaging and voice access features, as well as its new developer APIs.

Significant Architectural Changes

Several years ago Microsoft abandoned a project code-named Kodiak, which utilized a SQL Server—based database for Exchange mailbox and public folder storage. However, Exchange 2007 contains major architectural changes that accomplish much of what the Kodiak project promised, such as a 64-bit database, data replication (using log shipping), and a better programmatic interface. In addition, Exchange 2007 includes a new role-based architecture and an improved security model.

64-Bit Only

Exchange 2007 is the first Microsoft server application to ship solely for use on 64-bit versions of Windows Server 2003. It requires AMD or Intel x64 processors, and it will not work on servers with 64-bit Intel Itanium processors. Although Microsoft has also developed a 32-bit version of Exchange 2007, it is unsupported and intended strictly for limited-time product evaluation.

The decision to go exclusively with a 64-bit version allowed the Exchange team to redesign the mailbox database and other core components to take advantage of the vastly larger amounts of physical memory supported by 64-bit servers (in theory, 16 exabytes, but in practice limited by the number of physical memory slots in the server and the fact that the largest memory modules currently available are 4GB). Exchange 2007 exploits the added memory by using new caching routines to reduce disk access. Testing at Microsoft has shown up to 70% less disk I/O, yielding better performance and scalability and allowing Exchange 2007 to support greater numbers of users and more mailbox data.

However, Microsoft's decision to eliminate 32-bit Exchange imposes some challenges. It makes upgrade from Exchange 2003 more difficult and expensive, and unless a replacement server has significantly more memory than what was optimal for the Exchange 2003, performance could actually be worse. Furthermore, Exchange 2007 cannot be run on virtual machines hosted by Microsoft's Virtual Server 2005, which support 32-bit guest OSs only.

(For more information on migration from Exchange 2000 or 2003, see the sidebar "Upgrade and Migration Issues".)

More Granular Storage

As with prior versions of Exchange, Exchange 2007 mailbox and public folder items are still stored in an Extensible Storage Engine (ESE, also known as Jet) database, but the ESE has been ported to a 64-bit.

With Exchange Server 2007 Enterprise Edition (EE), administrators can subdivide mailbox and public folder storage into as many as 50 independent units called storage groups, each of which consists of a transaction log and one or more database files. Standard Edition (SE) supports up to five storage groups. (With Exchange Server 2003, the corresponding limits were 20 storage groups in Enterprise Edition and one in Standard Edition.)

It is common for larger organizations (including Microsoft itself) to split their Exchange mailbox storage among multiple storage groups for the following reasons:

Limit impact of data corruption. When users are spread across multiple storage groups, corruption of a storage group impacts fewer users.

Minimize restore time. During a recovery operation, data for a storage group can be restored more quickly than the entire message database.

Administrative flexibility. Subdividing the mailbox database allows organizations to delegate administration of the mailboxes of specific groups of users to different individuals. It is also a convenient starting point for implementing different service level agreements for different sets of users—for example, performing tape backup more frequently for the legal department than for other users.

Support for large numbers of storage groups will be especially important to Internet hosters that provide hosted Exchange services to small businesses, because they can support more businesses on each server while still isolating each to its own storage group.

Exchange 2007 Server Roles

At install time, administrators select the specific role or roles—groups of features required to perform a particular function in the Exchange environment—that they want each Exchange 2007 server to perform. Only the components needed for that role are installed, thereby reducing the attack surface and eliminating processing overhead.

Although Exchange 2003 could be configured for specialized roles, such as back-end message databases, front-end servers handling Hypertext Transfer Protocol (HTTP) and Post Office Protocol (POP) traffic from users, and bridgehead servers that route traffic to other sites and to the Internet, each role still installed all the Exchange components. Exchange 2003 roles exist in Exchange 2007, but some have new names and all contain many technical changes and improvements.

Furthermore, Exchange 2007's support for the Simple Mail Transport Protocol (SMTP) is provided by the new Microsoft Exchange Transport service rather than by Internet Information Services (IIS), which provided SMTP support in all previous versions of Exchange. The new SMTP protocol stack has been written in managed code, which helps reduce susceptibility to denial of service attacks. Although it requires the .NET Framework, it eliminates the need to install IIS for most Exchange server roles.

Exchange 2007 roles are as follows (for a graphical representation, see "Exchange 2007 Roles"):

Mailbox. This role installs the components needed by the message database, which can contain public folder data in addition to users' e-mail, calendar, contact, and task data. The mailbox role installs the ESE database and support for Microsoft's remote procedure call (RPC)-based Messaging API (MAPI) communication protocol, which is used by Outlook clients and for communicating with other Exchange servers on the local network.

Client access. Performing a function similar to an Exchange 2003 front-end server, this role requires IIS and installs the components and protocols needed by Outlook Web Access (OWA), POP3 clients, IMAP4 clients, Exchange Server ActiveSync, and Outlook Anywhere (formerly known as MAPI RPC over HTTP). The client access server is also the component that hosts Exchange 2007's new Web service API, so customers who build or purchase applications that call the new API will need client access servers to access mailbox or public folder data residing on mailbox servers.

As with Exchange 2003, Outlook clients using regular MAPI instead of Outlook Anywhere still connect directly to their mailbox server and not to a client access server.

Unified messaging (UM). The UM option in Exchange 2007 enables users to receive not only e-mail messages and meeting invitations in their Exchange inboxes but also voice mail and faxes. A speech-enabled Automated Attendant provides touch-tone menus and speech recognition to prompt callers to leave messages and allows users to interact with their messages and calendar items over the phone. For example, phone users can delete a message or change a meeting time or location, and the Automated Attendant can even convert e-mail text to speech and play it back over the phone.

Servers configured in the UM role sit between the organization's private branch exchange (PBX), or a PBX gateway, and Exchange 2007 servers performing other roles.

Hub transport. Exchange 2007 servers configured with the hub transport role perform functions similar to Exchange 2003 bridgehead servers, but do much more. All message movement, even to a recipient located on the same mailbox server as the sender, now must pass through at least one server configured with the hub transport role. The hub transport server uses MAPI for message transfer between mailbox servers on the local LAN, but it uses SMTP for exchanging messages between Exchange servers in remote offices and to and from the Internet. Hub transport servers can also inspect messages to enforce regulatory and corporate record-compliance requirements.

Unlike Exchange 2003, which required administrators to define routing groups of Exchange servers that had high-bandwidth connectivity with each other, Exchange 2007 uses the Active Directory (AD) site definitions instead. This change makes it simpler to configure traffic between Exchange servers joined by WANs, and makes Exchange's site definitions consistent with those of AD.

Edge transport. The new edge transport role processes and routes mail to and from the Internet. Unlike Exchange 2003's Internet Connector component, which ran on an Exchange server that was a member of the organization's AD forest, Exchange 2007 edge transport servers are not domain members and can be located outside the corporate firewall. This makes the system more secure, since a compromised edge transport server does not have access permissions to servers in the forest. However, edge transport servers can still filter out mail addressed to invalid recipients because they store a read-only subset of the AD user data (stored in a local Active Directory Application Mode [ADAM] directory populated by a hub transport server inside the firewall). The edge transport server also inspects incoming messages for spam using the Exchange Intelligent Message Filter and a copy of each user's Outlook safe-sender and blocked-sender lists.

Even though Exchange 2007 does not have built-in antivirus scanning, antivirus products such as Microsoft's Forefront for Exchange 2007 are supported on edge transport servers, hub transport servers, and mailbox servers. After messages are scanned on an edge transport server for viruses and spam, they are tagged to tell downstream hub transport and mailbox servers not to repeat the scans, thereby reducing the workload of those servers.

(Customers who purchase the new Exchange 2007 Enterprise Client Access License together with Software Assurance get the rights to run Forefront for Exchange, which also includes an antispam feature. The differences between Forefront and Exchange's built-in IMF antispam features are described in the sidebar "Antispam Protection: Exchange IMF or Forefront?".)

Except for the edge transport role, smaller organizations or branch offices that don't need individual servers dedicated to each role can install any combination of the other four roles on a server. Furthermore, edge transport servers, while recommended for optimum e-mail security, are not required; organizations can still configure firewalls to forward inbound SMTP messages to an internal server running the hub transport role.

Improved Delegation and Security

Exchange 2007 offers two major improvements in the area of security: the ability to assign more granular administrative rights to IT staff and Transport Layer Security (TLS) encryption of messages.

More granular delegation. The security principle of least privilege stipulates that IT pros and users alike be given only those rights and permissions needed to do their work and no more, and that software should be designed with sufficiently granular access controls to configure rights accordingly. For Exchange, the number of IT professionals with full privileges to the servers should be kept to a minimum. For example, an organization might want its help desk technicians to be able to reconfigure users' mailboxes or create new ones, but not want them to have rights to modify global Exchange settings.

Exchange 2003 had an administration roles feature that allowed full administrators to delegate restricted and view-only rights to other AD users or groups, but the feature was not perfect. For example, restricted rights could be delegated only to the entire Exchange system rather than specific servers. To administrate per-user Exchange settings, individuals assigned the restricted role still required being granted the excessively broad Account Operator permissions on all AD user account settings. Administrators could manually edit the permissions on specific Exchange 2003 objects to delegate more granular access permissions, but the process was difficult and prone to error.

Exchange 2007 has a revamped delegation system with four defined roles: Organization Administrators, Server Administrators, Recipient Administrators, and View-Only Administrators. Each role is linked to preconfigured rights and access lists on both Exchange and AD. Access list editing is no longer required (or even exposed in the graphical administration console). AD users or groups can be assigned the Server Administrators role for specific Exchange 2007 servers without getting access to others, and AD users or groups assigned the Recipient Administrators role can manage mailboxes and Exchange-specific AD properties, such as a user's e-mail address or mailbox server assignment, without also requiring them to have Account Operator privileges.

TLS encryption. By default, SMTP mail goes across the network unencrypted and unauthenticated, making it susceptible to spoofing and eavesdropping. With Exchange 2007, this risk is lower. Exchange 2007 Hub Transport and Edge Servers will not only secure SMTP communication using the digital certificate-based TLS protocol but will also detect whether an outside recipient's server is running Exchange 2007 and, if so, automatically configure the connection to use TLS (as long as both servers have certificates issued by a trusted public issuer, such as VeriSign, or the edge servers are each configured to trust each other's private certificates).

RPC-based MAPI communications with mailbox, client access, and UM servers are also now encrypted using TLS rather than the native Windows RPC encryption used by earlier versions of Exchange. This is important because it allows Exchange servers in all roles to offload TLS encryption and decryption to special network adapters, thereby freeing up CPU cycles and boosting overall performance and scalability.

Improved Mailbox Availability

As e-mail continues to grow in importance, e-mail outages have the potential to do significant business damage. Users have come to count on e-mail to be as reliable and available as their telephone, and Exchange customers—even small organizations—want the product to have enough redundancy features to tolerate failures in individual system components without taking down the whole e-mail service. Although prohibitively complex and expensive for small organizations, large organizations can use multiple redundant Exchange servers in each role to avoid most single points of failure. However, until Exchange 2007, organizations of all sizes were susceptible to failure of the mailbox and public folder databases.

With Exchange 5.5 and later, larger organizations could use Windows Cluster Services to provide greater mailbox server availability (which required special storage network hardware and the more expensive Enterprise Editions of Exchange and Windows Server). Even then, however, the actual mailbox data still resided in one set of files accessed by whichever cluster node was currently active. Although storage redundancy using a redundant array of independent disks (RAID) or disk volume replication protects against disk failures, it does not prevent servers from corrupting data. With no storage group redundancy, if the Exchange data was damaged or destroyed, the only recourse was to restore from the last tape backup, a slow, manual task that deleted all data added since the last backup. Furthermore, as mail volume and the number of mailboxes get large, storage group restore time can become prohibitive.

Exchange 2007 introduces two new features—Local Continuous Replication and Cluster Continuous Replication—that improve availability and reduce risk. Both use a technique called log shipping to maintain independent replicas of Exchange storage groups.

Local Continuous Replication (LCR) provides increased storage group availability on a single nonclustered mailbox server. LCR creates replicas of one or more storage groups; ideally these replicas are located on disks separate from those that store the production database. Unlike disk mirroring, which sends identical low-level write requests to two disks at the same time (and thus can be corrupted simultaneously if a bad write request is received), LCR uses a copy of each storage group's log file to play back database write commands to a storage group replica and contains mechanisms to prevent corrupted data from being replayed to the replica. In the event of a disk failure or storage group corruption, an administrator can manually switch to the replica storage group in a manner of minutes. However, LCR does not protect against all failures of the mailbox server; if other Windows or Exchange services needed by the Exchange message database hang or malfunction, an administrator must fix those services first before users can access their mailboxes.

Cluster Continuous Replication (CCR) provides even greater storage group availability when using Windows Cluster Services. One limitation of LCR is that the backup storage group is still stored on disks accessible only to a single Exchange server, and failure of the server itself will stop writes to both the production and replicated storage groups. With CCR, the production server (an active cluster node) ships the storage group log to a backup failover server (a passive cluster node) that updates the storage group on its own disk storage, thereby providing greater isolation between the active store and its backup.

CCR provides all of the advantages of Exchange 2003 clustering (automatic service monitoring, automatic failover, and replication of Exchange configuration settings) and also eliminates the dependence on single instances of storage groups. Unlike LCR, which does not protect against server failure, cluster failover automatically uses the CCR replica storage groups, so no administrator intervention is necessary. Furthermore, since no disk volumes need to be shared between active and passive cluster nodes, the nodes can even be located in separate geographic facilities without resorting to expensive storage-area network intersite replication solutions.

In both solutions, the replicas are normally kept up to the minute. This reduces the need for frequent backups, and in the case of CCR backup it improves the performance of the active node, since the backup job can be run against the passive node and its storage group replicas, which aren't serving users.

Management Console Rebuilt

Exchange 2003 administrators frequently complained that the hierarchical user interface of the product's administration console, System Manager, made it hard to find configuration settings and to discover what options were available. Objects could be nested up to five levels deep, and tabbed property pages often required the user to click buttons to expose even more dialog boxes. Furthermore, many common Exchange administrative tasks, such as adding a user, could not even be done in System Manager but instead had to be done in the AD Users and Computers management console. Because Exchange 2003 had poor tools for scripting commonly performed tasks, administrators faced laborious navigation and extensive typing to complete a series of repetitive actions.

Exchange 2007's all-new management console should please these administrators. (See the illustration "Revamped Administration Console".) The new console's hierarchy nests objects a maximum of three levels deep and displays all of the actions that can be performed on a selected object without requiring right-clicks. It includes numerous wizards for performing common tasks, such as adding users, moving mailboxes, or creating new storage groups. The biggest change, however, is that the whole graphical interface runs on top of PowerShell, (previously code-named Monad), the company's next-generation shell-scripting engine. PowerShell enables administrators to run a variety of system and application management tasks at the command line and to compose scripts for routine operations.

PowerShell is a more powerful command-line environment than the Windows command shell, yet it is easier than VBScript and JScript for nondeveloper administrators to use. PowerShell comes with a broad set of built-in commands (called cmdlets, pronounced "command-lets") for performing common Windows administrative tasks, and installing Exchange 2007 adds the Exchange Management Shell—nearly 400 Exchange-specific cmdlets that manage Exchange's configuration and provide status information. When administrators are using the graphical console, they are actually executing Exchange and Windows cmdlets behind the scene. This layered console architecture means that any task that can be done in the console can also be done from the command line or via a script. However, some of the more obscure configuration settings can be managed only with the Exchange Management Shell and are not exposed in the new graphical console. For example, setting content filtering options on hub transport servers requires use of the Set-ContentFilterConfig cmdlet.

To help administrators learn the syntax of the Exchange Management Shell and build custom scripts, wizards in the Exchange Management Console display the PowerShell command line syntax for each action the administrator has entered into the wizard. This text can be cut and pasted directly to the Exchange Management Shell or into a script file.

The Exchange 2007 management console has been localized for Brazilian Portuguese, Chinese-Simplified, Chinese-Traditional, English, French, German, Italian, Japanese, Korean, Russian, and Spanish. However, until the upcoming Windows Server 2003 Service Pack 2 introduces Multilingual User Interface Packs that add base OS support for Brazilian Portuguese and Russian, the Exchange 2007 consoles for those two languages will not work.

Resources

More information and Exchange 2007 evaluation software can be found at www.microsoft.com/exchange.

PowerShell is described in "Release Candidate for Scripting Engine" on page 21 of the June 2006 Update.