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.
End of Article
Prev. page
1
2
[3]
next page -->
