The new messaging server offers plenty of enhancements
This summer, 3 years after shipping Microsoft Exchange 2000 Server, Microsoft plans to ship Exchange Server 2003. If you're using Exchange 2000, Exchange 2003 will look more like a service pack than a full product release. However, the new version contains some interesting manageability, mobility, scalability, security, and client enhancements. Let's take a brief look at some of the more interesting changes and at how an Exchange 2003 deployment might play out.
Manageability improvements in Exchange 2003 come from better integration with Windows (especially Microsoft Internet Information Services—IIS); a more fully developed, built-in Exchange module for the Microsoft Operations Manager (MOM) framework; improvements to the Exchange System Manager (ESM) console; and 3 years of Exchange 2000 customer feedback. Hundreds of small changes make Exchange 2003 easier to manage than Exchange 2000.
For example, you can use simple Lightweight Directory Access Protocol (LDAP) queries to maintain dynamic distribution-group membership. After you populate Active Directory (AD) with the necessary data, you can create query-based lists that Exchange builds on the fly. For example, you can have lists that let users address messages to all users with a mailbox on a specific server or to everyone in a particular department.
Another example of a small but useful improvement is ESM's view of message queues. The console now presents queues for a server in one pane that also incorporates options to examine, freeze, and release queue contents, as Figure 1 shows. This change might not be dramatic, but making sure that email flows properly is an important part of an email administrator's life, and the elegant new ESM interface simplifies that task.
Spam is an obvious irritant to anyone who manages an email server. Exchange 2003's new spam-blocking capability is yet another improvement. See the sidebar "Antispam Support," page 40, for information.
In response to the spread of mobile computing devices such as Pocket PCs, Microsoft has made Exchange 2003 a key point of integration for mobile devices. Email, calendars, and contacts are the most important features for most mobile-device users, so making mobility a core Exchange attribute makes sense. When you deploy Exchange 2003, you can use the Exchange Task Wizard to configure mobility settings along with other Exchange features, as Figure 2 shows.
Microsoft has put on hold its attempt to expand Exchange into a collaboration server and instead has focused on making Exchange 2003 the best possible messaging server. As a result, the company has removed the optional Exchange-branded versions of Instant Messaging (IM), Chat, and Conferencing Server from Exchange 2003. If you want to deploy a Microsoft version of IM, you'll need to wait for the upcoming Microsoft Real-Time Communications (RTC) Server (code-named Greenwich). Greenwich builds on the Internet Engineering Task Force's (IETF's) Session Initiation Protocol (SIP) and is far more firewall-friendly than Exchange IM, which uses Microsoft's Rendezvous Protocol (RVP). For more information about Greenwich, see "Microsoft Releases 'Greenwich' RTC Server Beta," March 6, 2003, http://www.winnetmag.com, InstantDoc ID 38261, and "Understanding the Session Initiation Protocol," January 2003, http://www.winnetmag.com, InstantDoc ID 27397.
Exchange 2003 includes new features to let you take advantage of powerful hardware. Currently, worries about the time required to restore an Exchange database make many administrators limit the number of mailboxes they place on a server, regardless of how many mailboxes the hardware can actually support. Improvements such as support for hot backups (through a combination of Microsoft's new Volume Shadow Copy Service—VSS—and VSS-aware backup software and hardware) and better clustering (including the ability to group as many as eight servers in a cluster) might change all that. Along with changes that reduce the load that clients place on your Exchange servers and the bandwidth clients consume, these improvements might encourage you to reconsider server consolidation. (See the Web-exclusive sidebar "Consolidate Those Servers?" http://www.winnetmag.com, InstantDoc ID 38932, for information.)
During its recent Trustworthy Computing initiative, Microsoft conducted a full code review of its products to locate potential problems and tighten security. Apart from Windows Server 2003, Exchange 2003 is the first server product to benefit from that exercise. Real-world customer experience with multiple forests, forests with many domains, and single-domain environments identified opportunities for Microsoft to tighten Exchange security, and the company has taken that opportunity.
The new version of Microsoft Outlook Web Access (OWA) provides several examples. OWA now uses IIS 6.0's worker process isolation mode to drive the set of applications that collectively deliver OWA functionality and leverages the new HTTP.sys kernel-mode HTTP listener, instead of depending on the Inetinfo process, to channel communications to the Exchange Store. On the client side, OWA now provides a downloadable control to support signed and encrypted email. OWA uses the same X.509 certificates as clients such as Microsoft Office Outlook 2003 (formerly code-named Outlook 11) use to sign and encrypt messages. And OWA supports forms and cookie authentication to let you control session timeouts and impose greater security for sessions that originate in kiosk-mode environments.
Outlook 2003 will ship with Exchange 2003 and will include several new features—such as cached replication, optimized network connections, compression improvements, bandwidth profiles, and Messaging API (MAPI) remote procedure calls (RPCs) over HTTP—to help reduce the load on Exchange servers and increase client accessibility to Exchange. (For an extensive look at these new client features, see "Outlook 11 and Exchange Server," April 2003, http://www.winnetmag.com, InstantDoc ID 38271.) Although Outlook is typically the Exchange client of choice, many companies have begun using OWA as their primary client. For those companies, Exchange 2003's new OWA version will be a godsend. In fact, the client's new features and interface might cause more companies to consider taking the OWA route.
OWA has a new, streamlined UI and new functionality such as a spell checker, Secure MIME (S/MIME) support for message encryption and digital signatures, and support for rules. You can also set options to prevent OWA from opening external Web content within messages, and OWA blocks Web beacons to prevent sites gathering validated email addresses when users click such links within messages. OWA's new rich UI looks and behaves like the full-blown Outlook client, as Figure 3 shows. The client's performance and responsiveness have improved too, especially when you run Exchange 2003 on a Windows 2003 server with IIS 6.0.
Microsoft implements the OWA spell checker (exchweb/bin/spell/owaspell.dll) as an Internet Server API (ISAPI) extension. When a user runs spell checking on a message, the client issues a POST request to the Exchange 2003 server, which loads the necessary language module and processes the message's text. All spell checking takes place on the server, which sends the client an XML document that contains all possible corrections. The OWA client then displays an HTML form through which the user can view and accept or reject the suggested changes. Although users must run spell checking on an entire message (rather than selected areas), the mechanism is effective. As in Outlook, users can configure spell-checking options such as which language to use, whether to ignore uppercase words, and whether to ignore words with numbers.
Users need to run Microsoft Internet Explorer (IE) 5.01 or later to access OWA's rich client interface; earlier browsers can access the simpler reach client interface, which Figure 4 shows. The rich client is more compelling than the reach client, but you can force users to access the reach interface (to simplify support or training or because you channel OWA communications through a firewall that won't pass the HTTP-DAV verbs that the rich client uses). To do so, add the ForceClientsDownLevel value (of type REG_DWORD) to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeWEB\OWA registry subkey on the server and set the value to 1. (Setting the value to 0 lets an OWA client browser access the highest level of functionality it can support.)
The system requirements for Exchange 2003 are straightforward, and an upgrade from Exchange 2000 to Exchange 2003 is the easiest upgrade since the move from Exchange Server 5.0 to Exchange 5.5. The stability of the Exchange 2003 betas and the ability to deploy those betas on Windows 2000 Server mean that many large companies have been able to roll out the betas to production. I've been using Exchange 2003 and Outlook 2003 betas as my only email server and client since January, and I've experienced no major outages or problems.
Exchange 2003 depends on AD to hold information about your organization, servers, connectors, and users, so you need to prepare the AD infrastructure before you upgrade. Your domain controllers (DCs) and Global Catalog (GC) servers must run Windows 2003 or Win2K Service Pack 3 (SP3); the Exchange 2003 Setup procedure will confirm that your DCs and GCs run an appropriate OS, so you can't avoid the necessary Windows upgrade. You'll also need to run Exchange 2003's Forestprep procedure to update the forest before you install the first Exchange 2003 server, then run the Domainprep procedure in every domain that hosts mail-enabled objects.
You can upgrade an existing Exchange server only if it runs Exchange 2000 SP3 or later. Therefore, if you're running Exchange 5.5, you'll need to upgrade to Exchange 2000 or install new Exchange 2003 servers and use Exchange's Move Mailbox feature to transfer Exchange 5.5 mailboxes to the new servers. Microsoft has upgraded Move Mailbox, so you can schedule the mailbox moves to happen overnight, which makes life easier. That said, an upgrade from Exchange 2000 to Exchange 2003 is easy; you can apply it in a couple of hours on all but the largest servers. (Of course, be sure to make a backup before and after the upgrade, just in case you need to roll back.)
To take advantage of new features such as VSS and four- to eight-node clustering, you must run Exchange 2003 on Windows 2003. If your company plans to deploy both Windows 2003 and Exchange 2003, consider a phased approach, moving to Exchange 2003 first. (Upgrading an OS and email server concurrently creates more complexities than most administrators want to deal with.) For example, if you run Exchange 2000 SP3 on Win2K, first upgrade to Win2K SP3, then upgrade to Exchange 2003, then finally upgrade to Windows 2003. (You can take a server through all these steps in 1 day, but such a speedy approach is recommended for only testing environments, not production environments. This type of phased approach typically requires at least 2 weeks between each major upgrade to permit the overall environment to settle down, to let AD replicate fully, and to identify any bugs that might be unique to your installation.)
Microsoft has created a deployment kit, called ExDeploy, to help you assess the steps you need to take to prepare your infrastructure before installing Exchange 2003. You can find the kit, which includes a deployment guide and tools, in the \support\exdeploy folder on the Exchange 2003 CD-ROM. The tools are basic and might not include the same depth of functionality that you find in most third-party directory-management tools, but they'll help you to move smoothly to Exchange 2003. To start ExDeploy, launch the exdeploy.chm compiled Help file, which presents a menu and calls various utilities as necessary, depending on the options you select. Many of the tools are designed to help migrate Exchange 5.5 servers to Exchange 2000 as the first step in an Exchange 2003 migration because Microsoft knows that only about 25 percent of Exchange 5.5 installations have moved to Exchange 2000. Among the more interesting ExDeploy tools are the following:
- OrgPrepCheck—The OrgPrepCheck tool confirms that the proper security policies and groups exist and have been correctly replicated within the organization before you install the first Exchange 2003 server. You run this tool after you run Forestprep (which prepares the AD forest) and Domainprep (which prepares an individual domain for Exchange).
- DSScopeScan—The DSScopeScan tool audits an Exchange 5.5 server and reports the essential data (e.g., servers, stores, connectors, mailboxes, public folders) that you need to know to scope the migration to Exchange 2000.
- SetupPrep—The SetupPrep tool confirms that the necessary infrastructure components (e.g., AD, DNS) are available and functioning.
- ADCUserCheck—The ADCUserCheck tool scans an Exchange 5.5 Directory Store and creates a recommended list of AD connection agreements necessary to synchronize the Directory Store with AD. ExDeploy calls this tool when you choose to review the necessary procedure to upgrade an Exchange 5.5 server to Exchange 2000.
Exchange 2003 delivers enough useful functionality for both administrators and users to make the product a candidate for early deployment, but you won't realize the full benefit of the server's improvements until you also deploy Windows 2003 on your servers and Windows XP and Office 2003 on your desktops. And before you make a move to Exchange 2003, find out whether you need updated versions of add-on products such as virus checkers and backup utilities—the changes in Exchange 2003 might affect these products.