Are you the type of administrator who refuses to upgrade to a new point release until the first service pack appears? If so, you might finally be evaluating whether to upgrade to Microsoft Exchange Server 2003. After a wait of nearly a year, Microsoft released Exchange 2003 Service Pack 1 (SP1) in May. The pace of development for Exchange 2003 service packs promises to be more measured than that of earlier Exchange versions, the theory being that the extra time Microsoft spent developing the base product has resulted in a more stable and feature-rich release—thus Microsoft won't have to rush out service packs in response to flaws.
Exchange 2003 SP1 includes a mixture of bug fixes, updates to existing features, and some new UIs that simplify deployment and management. (The sidebar "The Rundown on Exchange Server 2003 SP1," page 73, gives a quick overview of what's new in SP1.) If you like what you see in Exchange 2003 SP1 and decide that the time has finally come to upgrade from Exchange Server 5.5 (as indeed it has), you'll be pleased to learn that SP1 includes new tools to make migration easier. If you're already running Exchange 2003, I think you'll find two improvements—easier configuration of Remote Procedure Call (RPC) over HTTP and self-healing capabilities for the Store—particularly useful.
Making Migrations Easier
The support deadline for Exchange 5.5 expires in December 2004. True, you can buy extended support from Microsoft and keep using Exchange 5.5 until December 2005, and many Exchange 5.5 supporters argue that it's still stable, works, and offers all the features they need from an email system. But the computing world has changed since Microsoft set the fundamental architectural principles for Exchange 5.5 in 1996. Exchange 5.5 might be able to support communities of several thousand mailboxes on one server, but today's messaging environment requires so much more than that. Exchange 5.5's scalability is limited to a single mailbox store, its SMTP connectivity is basic, it can't take advantage of newer client features (e.g., Microsoft Office Outlook 2003's on-the-wire compression), its administrative model is poorly suited to larger organizations, its implementation of Outlook Web Access (OWA) is rudimentary, and it supports only two-node, active/passive clusters. Exchange 2003 running on Windows Server 2003 is simply a more secure and robust messaging platform.
Furthermore, Exchange 2003 offers a solid platform for consolidation. Exchange 2003 and Outlook 2003 are an especially good combination to implement when you want to consolidate servers. Improvements in how the client and server work together across low-bandwidth networks make it easy to remove servers from branch offices, for example, and cached Exchange mode lets Outlook clients work during network interruptions. Exchange 2003's SMTP connections require less network bandwidth than Exchange 5.5's Messaging API (MAPI)-based site connector or X.400 connectors need, letting you consolidate Exchange 5.5 sites into fewer Exchange 2003 administrative and routing groups and thus reducing the complexity of your administrative and routing topologies. SP1 improves Exchange 2003's Move Mailbox Wizard and makes the notion of site consolidation even more compelling.
The biggest change is that you can now use the Move Mailbox Wizard to migrate mailboxes in a mixed-mode organization from an Exchange 5.5 server in one administrative group (or site, in Exchange 5.5 terminology) to an Exchange 2003 SP1 server in a different administrative group. Without SP1, the wizard lets you move mailboxes between mixed-mode servers only when the servers are in the same administrative group. This new capability might seem unimportant, but it will save a lot of work if you opt to deploy Exchange 2003 by installing brand new servers rather than by upgrading older servers.
The Move Mailbox Wizard also now preserves mailbox rules and updates folder ACLs, instead of merely moving mailbox contents, to ensure the preservation of the complete mailbox environment. Users who have accumulated rules to process incoming messages will be happy to learn that they won't have to recreate all those rules after you move their mailboxes to a new server.
Note that before you can use the updated Move Mailbox Wizard to migrate mailboxes across administrative groups, you need to update your Active Directory Connector (ADC) to the version included in SP1. This version includes new code that lets users continue to use distribution groups (DGs) and access public folders after the migration. There are a few other requirements, which you can find (along with a brief discussion of other SP1 deployment improvements) in the Microsoft article "Deployment Changes in Exchange Server 2003 SP1" (http://www.microsoft.com/technet/prodtechnol/exchange/2003/deploysp1.mspx).
Simplifying RPC over HTTP Configuration
Exchange 2003's RPC over HTTP feature lets users take advantage of a standard HTTP connection (rather than a VPN) to transfer MAPI RPCs between Outlook and Exchange. The idea is simple, but the implementation turned out to be complex, largely because of the need to upgrade all the servers that serve specific roles (e.g., Global Catalog—GC—servers) to Windows 2003 and because of the amount of manual intervention (e.g., tweaking the infamous ValidPorts registry setting) necessary to configure network components to handle the RPCs en route between clients and servers.
Changes in Exchange 2003 SP1 simplify the feature somewhat. A successful RPC over HTTP implementation still requires your domain controllers (DCs) and Exchange 2003 servers to run on Windows 2003. But SP1 updates the System Attendant service to use the DSProxy service, rather than a direct link to a GC, to refer Outlook clients to the Exchange server. This change eliminates the need to upgrade all your GC servers to Windows 2003 (although doing so is still a good idea). Also, SP1 adds a tab to the Exchange server Properties dialog box that you access through Exchange System Manager (ESM); this tab lets you configure the server's role in RPC over HTTP transactions. (An Exchange 2003 server can fulfill one of three roles in an RPC over HTTP scenario. It might not handle RPC over HTTP connections, it might be a front-end server that proxies connections onward, or it might be a back-end server that hosts the mailboxes to which clients connect.) You now can also configure ESM to show the RPC-HTTP field, which displays the server's role.
Commentators often criticize Microsoft for adding features that require manual configuration via arcane command-line utilities or numerous registry changes, so it's good to see that the company has updated the ESM UI to make things easier. Now, if it would just eliminate the need to run Eseutil and Isinteg from the command line to fix database problems ...
Prev. page
[1]
2
next page 
