Deciding whether to implement a new service pack is a common part of an administrator's life. The trick is to know what the service pack includes and to understand how it will affect your Exchange Server environment. As expected, Exchange 2000 Server Service Pack 2 (SP2) provides a rollup of hotfixes and patches. But this service pack also aims to rev up reliability. How? Through significant new functionality for systems management tools such as DSAccess and Message Tracking, support for Microsoft Operations Manager (MOM), enhancements to Microsoft Outlook Web Access (OWA), better memory management for Exchange 2000 clusters, and several smaller changes that pack a cumulative punch.
DSAccess Mark Two
Exchange 2000's use of Active Directory (AD) rather than the Exchange Directory Service (DS) is the most fundamental architectural difference between Exchange 2000 and earlier Exchange versions. Exchange 2000 components (e.g., the Routing Engine service) use DSAccess to access domain controllers (DCs) for server and organization data, to access Global Catalog (GC) servers for mailbox data, and to find, access, and cache directory information from AD. As such, DSAccess is a crucial part of Exchange 2000 and probably the component that comes under the most strain in a production environment. And correct DC and GC placement is key to successful Exchange 2000 deployments. (For information about DSAccess and proper DC and GC placement, see "Learning from Exchange 2000 Deployments," November 2001, InstantDoc ID 22553; and Kieran McCorry, "MAPI Client Directory Access in Exchange 2000," http://www.exchangeadmin.com, InstantDoc ID 21458.)
In response to customers' experience during Exchange 2000's first year of real-world deployments, Microsoft has built in additional robustness and resilience to DSAccess and has added a graphical way to access information about DC and GC access. (SP2 makes obsolete Dsadiag, the command-line utility that provides rudimentary insight into available DCs and GCs.)
The primary concern was the need to provide more information about the DCs and GCs that an Exchange 2000 server accesses. With SP2's DSAccess component, you can expect smarter detection and selection of available DCs and GCs and an improvement in Exchange 2000 failover when the currently selected DC or GC becomes unavailable because of a network or hardware failure. SP2 also includes numerous fixes to better handle error conditions that result from such failures.
SP2 includes code that polls the original DC or GC 15 minutes after a failure to determine whether Exchange can revert back to the original machine. Overall, though, DSAccess now spends less time checking for changes to configuration data and thus improves performance. This change makes sense because an Exchange organization's configuration doesn't change often after the initial deployment period.
Exchange service pack for a spin
The most obvious change is a new GUI for Directory Access, which Figure 1 shows. This GUI appears as a tab in each Exchange server's Properties dialog box (which you access through the Microsoft Management Console—MMC—Exchange System Manager—ESM—console). You can use this interface to view all available DCs, the DC that the server is using to fetch configuration data, the GC that the server is using, and the Lightweight Directory Access Protocol (LDAP) port that DSAccess uses. (You might need to scroll the option text across to the left to reveal the LDAP port.) SP2 also adds event 2081 to the event log. This event reveals the controllers that Exchange 2000 selected when it started up.
The redesigned DS-Access is a welcome improvement, and the new interface illuminates a part of Exchange 2000 that can be a mystery to administrators. These new capabilities alone might be reason enough for you to deploy SP2.
More for MOM
Exchange has always been a prime target for management applications, and efforts are under way for Exchange 2000 to fully support Microsoft's MOM management framework. MOM provides a centralized view of distributed systems and the applications that run on those systems and includes methods to monitor and extract data about server conditions (e.g., disk space, CPU load) and applications (e.g., mounted databases, active services). MOM 2000's Application Management Pack includes an Exchange 2000 Management Pack, which offers Exchange-specific features. (For details about this management pack, see Jerry Cochran's Exchange & Outlook UPDATE article, "A Look at the Exchange 2000 Management Pack for MOM," http://www.winnetmag.com, InstantDoc ID 22880.)
MOM's Exchange 2000 Management Pack can monitor Exchange 2000, but the MOM/Exchange interaction will be more powerful when you combine Exchange 2000 SP2 servers with MOM's next management pack release, which will include upgraded components that can take full advantage of SP2's enhancements. (At the time of this writing, the next MOM management pack is due early this year.) SP2 incorporates the necessary probes that will let MOM interrogate Exchange 2000 for data such as the size of mail queues, outstanding Outlook Messaging API (MAPI) remote procedure calls (RPCs), disk I/O, and database status. MOM also can monitor Win2K DCs and GCs and provide a one-stop monitor for the essential parts of an Exchange 2000 infrastructure.
Easier Server Management
The enhanced DSAccess component and MOM support are the most important technological enhancements that SP2 makes to Exchange 2000 management. However, Microsoft has included other fixes and updates in SP2.
Message archival. The SP2 CD-ROM's \support directory contains a message-tracing tool called Regtrace. This tool isn't the same type of message-archival application that third-party vendors provide. Rather, you can use the utility to help debug problems with SMTP traffic. Regtrace dumps all the email that an SMTP virtual server handles into a disk directory, from which you can examine the email to determine where problems exist. You won't use this utility every day, but it's a useful addition to your toolkit.
Message tracking. Along the same lines, the MMC Exchange Message Tracking Center snap-in, which you can access directly through a custom MMC console or through the ESM, has received a complete face-lift. The snap-in now has an Outlook-like GUI, which Figure 2 shows, to help you through the process of tracking down missing messages. The way that Exchange processes tracking requests also has changed. Previously, an administrative console that wanted to track a message needed to poll all the servers involved in the message's path through the organization. The console extracted the tracking logs from any of the servers on which message tracking was enabled, then interrogated the logs for matching entries. With SP2, the console sends tracking requests to each server, which processes the request locally and responds only with matching entries instead of with the entire log. This approach reduces network traffic and speeds up the tracking process. (For more information about message tracking, see "Exchange 2000's Message Tracking Center," December 2000, InstantDoc ID 16006.)
New Exchange Management service. The new DSAccess and Message Tracking interfaces both depend on SP2's new Microsoft Exchange Management service. This service is somewhat like the System Attendant service in that it performs management operations on behalf of a server. (You can find the Exchange Management service in the service list that appears when Exchange 2000 starts up.) If the service isn't running, you won't be able to access directory information or use the Message Tracking Center.
Clearer notifications. Another SP2 benefit comes in the form of improved text for Delivery Status Notifications (DSNs), which users receive when a message can't be delivered. Messages might go undelivered for myriad reasons, but the cause is often obscured by cryptic text that makes little sense to the average user. SP2 clarifies this text somewhat. For example, Exchange 2000 and SP1 generate the same DSN for a message with an address that Exchange can't resolve by looking up a target server in DNS and for a message that an administrator removed from an SMTP queue. SP2, however, provides more information. Figure 3, page 54, shows the DSNs that SP2 sends for both of those situations. (Exchange 2000 SP2 generates the upper DSN when an address doesn't exist in the SMTP domain and returns the lower DSN when an administrator removes a message from a queue.) Users still might not fully understand the DSNs' text, but at least the improved text can help support personnel resolve the problem that caused the DSN.
You can't customize DSN messages, but SP2 does add a new transport event that the Routing Engine service can fire before Exchange generates a DSN message. You can write code and associate it with this event to add suitable text to a DSN message, but only for outgoing messages to people who've sent undeliverable messages to your server. The new event is interesting, but it won't help most users, and most administrators don't want to write code.
OWA: More to Love
Microsoft was pleasantly surprised by the success of Exchange 2000's OWA client. Many enterprises have realized the benefit of providing users with this highly functional stateless client. Microsoft responded to the increased customer interest by upgrading OWA functionality in SP1 and providing more upgrades in SP2. Some of the benefits are subtle: Performance is snappier and OWA's available views are more similar to Outlook's. OWA now sends out notifications when new messages arrive and supports calendar notifications. Such notifications might seem like a small step, but they'll endear OWA to users. (The notification features depend on extended browser support, so they're available only to clients that use Internet Explorer—IE—5.0 or later.)
SP2's version of OWA also provides a logoff page so that users can flush their credentials and prevent another person from coming along and accessing their email. The logoff page shuts down IE, which is a good (if blunt) method. OWA now delivers better printing, too—my favorite improvement. Earlier versions of OWA never quite seemed able to format calendars for printing. Application service providers (ASPs) will be happy to know that you can now provide OWA in a modular fashion. In other words, you can give users select access to one or several components, including email, calendar, and public folders. And SP2 upgrades OWA's search capabilities. For example, OWA now can exploit any full-text indexes that you've created on the Exchange 2000 server for public folders or mailboxes.
OWA still isn't perfect, but it's now the richest and most functional browser-based email client available. OWA still doesn't provide all the functionality of Outlook. A spell checker is the most obvious omission, but Microsoft speakers at the recent Microsoft Enterprise Conference (MEC) in Orlando, Florida, expressed interest in providing spell-checking functionality, so maybe that feature will appear in the next service pack. Of course, amenities such as Outlook's encrypted email feature might never appear in OWA because of the security concerns such features would involve.
Better Memory Management
All software allocates and reallocates memory to deal with data structures, and Microsoft has always paid close attention to the way in which the Information Store (IS)—which is the heart of Exchange—uses and manages memory. In addition, if you run Exchange 2000 Enterprise Server, that version's support of database partitioning and active-active clustering complicates memory management within the Store.
SP1 improved the way the Store uses memory internally (reducing the demand for contiguous virtual memory) and added performance counters to let you monitor the state of virtual memory. In addition, SP1 provided a warning and logs a new error event (event ID 9582) in the Application log when the largest available free block is smaller than 32MB and again when the block is smaller than 16MB. SP2 builds on these SP1 features to improve Exchange 2000 clustering's scalability and reliability. (However, you should always test your expected user demand on different server configurations before you settle on an exact configuration for deployment.)
For more details about Exchange 2000 clusters and memory management, see the Microsoft white paper "Deploying Microsoft Exchange 2000 Server Service Pack 1 Clusters" (http://www.microsoft.com/exchange/techinfo/deployment/2000/clusterssp1.doc). The document was written for SP1 but contains a wealth of applicable information. (Keep your eyes open for an updated version after Microsoft completes the load testing necessary to fully understand the effect of SP2's improvements under real-life conditions.) You can also read Paul Robichaux, Getting Started with Exchange, "Clustering in Exchange 2000," November 15, 2001, InstantDoc ID 22772; and Jerry Cochran, "Clustering Exchange 2000, Part 1," December 2000, InstantDoc ID 16007, and "Clustering Exchange 2000, Part 2," January 2001, InstantDoc ID 16241.
Little Changes Add Up
SP2 includes several smaller but important adjustments. These small improvements' accumulative effect is a big benefit in the long term.
Rosebud's demise. Several Microsoft products (including Exchange 2000 SP1 and earlier versions) use Rosebud, a generic OLE provider interface, to communicate with WWW Distributed Authoring and Versioning (WebDAV). ESM's Public Folder snap-in uses Rosebud to communicate with pre-SP2 public folders, but experience has shown the downside to this setup. Administrators have reported that ESM can be unresponsive when they access public folders and that ESM displays indecipherable messages when it can't access a public folder's properties. Problems occur more often when the public-folder hierarchy is large and distributed, and many of the errors are the results of insufficient permissions. In response, SP2 replaces Rosebud with direct WebDAV calls, thus improving responsiveness and giving Exchange better control over the type and quality of error messages that are generated.
Automatic error reporting. SP2 incorporates support for Microsoft Error Reporting. This tool attempts to catch errors in crucial code components, then automatically reports the details to Microsoft across a secure HTTP over Secure Sockets Layer (HTTPS) link. (For details about the tool and Microsoft's data-collection privacy policy, see http://watson.microsoft.com/dw/1033/dcp.asp.) The data is collated in a database and can generate entries in Microsoft's bug-tracking system. The idea is to capture data directly without going through several levels of human interaction so that Microsoft can quickly identify and address component-reliability trends and specific bugs.
SP2 upgrades the Information Store and System Attendant services to incorporate the necessary probes to support Error Reporting. The feature is disabled by default; to enable it you must open the Exchange server's Properties dialog box, go to the General tab, and select the Automatically Send Fatal Service Error Information to Microsoft check box. When a problem occurs after you've enabled Error Reporting, the tool will prompt you to let it send data to Microsoft.
RPC to LDAP. For servers that run in front-end/back-end configurations, SP2 replaces (with LDAP calls) the RPC requests that earlier versions used to locate GCs. This change might seem unimportant, but RPCs typically use dynamic port mapping, which makes them difficult to configure and control in a demilitarized zone (DMZ). You can assign LDAP to a known port, so you can configure a more manageable environment.
Less waiting. SP2 introduces asynchronous processing to permit the Transport Engine service to process messages for local delivery without waiting for the Store to release a thread. (Synchronous processing occasionally causes slow local delivery.) As a result, Outlook users will be free of the slight hang that sometimes happens as Exchange delivers messages into the Store, and overall message throughput on a server will be faster.
The Finer Points
SP2 delivers a solid combination of fixes and new features, so why wait to deploy the best version of Exchange 2000 to date? You can download or order SP2 from http://www.microsoft.com/exchange/downloads/2000. Be sure to read the release notes to understand the finer points.
Your Exchange servers must run Windows 2000 SP2 to support Exchange 2000 SP2. You can upgrade existing Exchange 2000 servers selectively and run a mixture of Exchange 2000, SP2, and SP1 servers with the caveat that front-end/back-end configurations must run the same version on both ends.
As with any service pack, the most important step in deploying SP2 in your production environment is to install and test the product thoroughly in a test environment. Pay special attention to the interaction between SP2 and any third-party software that you run.
Corrections to this Article:- "Exchange 2000 Service Pack 2" mentions that the message archival tool is Regtrace. The message archival tool that ships with Exchange 2000 Service Pack 2 (SP2) is Archive Sink, which is the \program files\exchsrvr\bin directory on the Exchange server after you install SP2. We apologize for any inconvenience this error might have caused.
