The long-awaited day is almost upon us! Microsoft Exchange Server 2003 Service Pack 2 (SP2) will ship at the end of the year. Microsoft is putting the service pack through the final stages of customer testing. SP2 builds on the already solid base that Exchange 2003 and its SP1 updates established and should be a welcome upgrade that most organizations will want to rapidly deploy. Reviewing Exchange 2003 SP2's major updates is a good way to determine whether you want to deploy the release.
Support for Mobile Devices
With so many mobile devices in use—from smart phones to Research In Motion's (RIM's) BlackBerry devices to PDAs—and the fact that messaging, calendaring, and task management are popular applications for these devices, Microsoft clearly needs to integrate mobile devices into Exchange. Pre-Exchange 2003, third-party technology provided the necessary components to connect mobile devices to Exchange, and companies such as Good Technology and RIM built large businesses around their ability to connect to and synchronize with Exchange. Although Exchange 2000 Server had some mobile capability, Microsoft stepped up its game with the first release of the Mobile Services for Exchange subsystem in Exchange 2003, recognizing the mobile-device market's importance and the rapid increase in the devices' features and putting huge development resources into the subsystem. The result is that Mobile Services, with its rich feature set, is now a competitive, low-cost offering that supports mobile devices. Microsoft has also successfully licensed its Exchange ActiveSync technology to mobile-device suppliers such as DataViz, Motorola, Nokia, Palm, and Symbian, so you can expect to see more support for Exchange in mobile devices and applications from these vendors.
Prior to SP2, Mobile Services was in the "cheap and cheerful" mobile solutions category. Although it's bundled with Exchange, it suffers from a lack of functionality in some important areas. Taken in conjunction with some of the advances in Windows Mobile 5.0, SP2 adds:
|
Improved AUTD
Always-up-to-date (AUTD) is a mechanism Exchange uses to provide new mailbox information to a mobile device. AUTD pushes information to mobile devices, but in some ways you can consider it a pull mechanism because it pushes only server notifications. In time, Microsoft could make AUTD push more data (such as message headers) to make the tool a more complete push mechanism.
Certificate-based authentication is especially welcome because it improves security by uniquely identifying a device similar to the way that BlackBerry devices identify themselves to wireless networks. By using certificate-based authentication combined with policy enforcement that requires users to enter PINs to access devices, you can meet the test for dual-factor authentication.
In SP2, AUTD uses persistent TCP/IP connections, rather than Short Message Service (SMS), to send notifications to mobile devices. The device sends a request to Exchange to register a subscription request for updates to the mailbox the same way that Microsoft Outlook Web Access (OWA) registers for new mail and calendar notifications. The request specifies a time interval (typically 15 minutes) and the folders that the device monitors (typically Inbox, Calendar, Contacts, and Tasks). If data changes in these folders during the set interval, Exchange sends a UDP packet to port 2883 on the front-end server that the mobile device uses, and the front-end server uses its open HTTP connection to the mobile device to relay the notification. After the device receives the notification, it issues a synchronization request to Exchange to retrieve the new data and sets up a new subscription. If Exchange has no updates for the device during the time interval, Exchange sends a "no data" message to the device, which can then respond with a new subscription request.
If the network connection (such as a wireless or General Packet Radio Service—GPRS—link) times out or is broken by the device shutting down or moving into and out of coverage, the device can reestablish communications and restart its Exchange connection. GPRS devices consume additional power only when they transmit, so the AUTD mechanism is more power-efficient than devices that have to poll Exchange regularly for updates. Your mileage will vary depending on the workload to which you subject the devices, but according to Microsoft, some users report a 20 percent to 30 percent increase in battery life when using Windows Mobile 5.0 devices.
Searching the GAL
Mobile devices can use the GALSearch feature by accessing the server to validate email addresses against and search the GAL. Memory is at a premium on mobile devices, so GALSearch supports a limited subset of the information that the GAL holds (compared with other clients such as Microsoft Office Outlook). Table 1 lists the properties that GALSearch supports and how they map against Active Directory (AD) attributes. The GALSearch feature takes a user-supplied query string and executes an Ambiguous Name Resolution (ANR) indexed search on the server against mail-enabled objects in the GAL. The ANR search, which is similar to the search that Outlook executes when it searches the GAL, attempts to return as many as 100 results for GAL entries that might satisfy the search string.
Securing Mobile Devices
In SP2, Mobile Services supports a set of secure those that do mobile-device features, including those that do the following:
- Enforce PINs (the user must set and use a PIN to access the device)
- Set a minimum password length (characters)
- Require both numbers and letters in the password
- Enforce a PIN lifetime
- Wipe the device after the set number of password attempts
In addition, Mobile Services lets devices connect to Exchange even when they don't support password settings. Such devices (typically older devices such as those that run Microsoft Pocket PC 2003) can't respond correctly to Exchange requests that they download and set policy data. These devices can ignore password policy and continue to synchronize data with Exchange, which is the approach that you can take if you have to support a mixture of old and new devices. You can also create a list of users who are exempt from the password policy. These users might have older devices or have devices that support other authentication mechanisms, such as biometric fingerprint readers. You access the password policy settings by clicking Device Security from the General property tab for the Mobile Services global settings, as Figure 1 shows. See the Web sidebar "Policy Setting for Mobile Devices" (http://www.windowsitpro.com, InstantDoc ID 48035) for an explanation of the AD attributes that control policy settings for mobile devices.
Wiping Mobile Devices
Until SP2, Microsoft didn't support a way to wipe or reset a mobile device (e.g., smart phone, Pocket PC). Other competing systems, such as GoodLink Server or BlackBerry Enterprise Server (BES), support features that let administrators send instructions to mobile devices to wipe their contents if they became lost or are stolen.
The SP2 wipe functionality is basic but effective. A restricted Web page (https://server-name/MobileAdmin) lets you wipe devices, cancel wipe commands, and delete synchronization partnerships between devices and users. When you initiate a remote wipe, the Web application sends a WebDAV Proppatch command to the user's mailbox to set the mailbox's wipeinitiated property to a nonzero value. Mobile Services notices that the property is set and sends a wipe command to the device, which then locally executes the appropriate command. The client then acknowledges the wipe command back to the server with an indication of success or failure. A log tracks all commands and status as reported by the device. The wipe command doesn't, however, erase data on storage cards; the only data that the device wipes is the user-specific settings. Improvements don't come for free, so if you want to take advantage of SP2's mobility improvements, you need to update target mobile devices with the Windows Mobile 5.0 Messaging and Security feature pack (see http://www.microsoft.com/windowsmobile/business/5/default.mspx for details). Different vendors take different approaches to the provision (or even testing) of upgraded versions of Windows Mobile, so check with your vendor to determine its upgrade policy and which devices support Windows Mobile 5.0.
Continuing the Fight Against Spam
Microsoft has steadily improved Exchange's ability to suppress unwanted email. The original version of Exchange 2003 supported better connection and recipient filtering and the ability to restrict access to distribution groups. SP1 fixed some problems, as did the first version of the Intelligent Message Filter (IMF), which is based on the same SmartScreen Technology that Microsoft uses to protect its MSN Hotmail service. Outlook 2003's Junk E-mail Filter also uses a variation of IMF. Basically, IMF examines an incoming mail stream and sets a spam confidence level (SCL) value for each message. If the SCL is greater than the administrator-set value, Exchange can immediately drop the message; otherwise, it's passed on to the user. Outlook's Junk E-mail Filter then evaluates the message and passes or rejects it, depending on the user's preferences. For example, some addresses might be in a user's safe senders list and, if so, Outlook won't suppress messages from those addresses, even when they have a high SCL value.
SP2 builds on this foundation by upgrading several antispam components and including a new IMF release. For example, SP2 now examines incoming SMTP connections to make sure that the connection partner is sending correctly formatted messages so that malicious users can't transmit messages that include 8-bit characters in the RFC2821 stream (a common tactic used to defeat filters). Also, SP2 responds to incoming SMTP VRFY commands, which remote correspondents use to verify email addresses, but Exchange doesn't provide the directory information because spammers often use VRFY commands to harvest valid email addresses. Exchange doesn't support the SMTP EXPN command, which queries a server about the membership of distribution lists (DLs).
If messages pass the connection test and are accepted, Exchange can then apply recipient filtering to prevent them being delivered to certain addresses. Recipient filtering can stop messages being sent to nonexistent addresses, but spammers can perform address-book mining by attempting to send messages to addresses that they build and monitoring the results to detect which addresses are valid. SP2 supports a technique called SMTP command tarpitting, which lets you configure Exchange to implement a delay (in seconds) to respond to a Rcpt To: command if a remote sender attempts to harvest addresses. As a result, spammers will find that their attacks slow down so much that they don't get any results, and they'll probably find an easier target.
The big news for the upgraded IMF is the way it detects and suppresses messages that contain phishing attacks. The upgraded IMF now contains tests that assess whether a message exhibits the characteristics of phishing and sets a Phishing Confidence Level (PCL) value that you can use to decide whether to accept or suppress the message. The higher the PCL, the more likely the message is dubious.
IMF also supports Sender ID, an industry standard framework that's designed to counter email domain spoofing in which a spammer generates messages that seem to originate from a legitimate domain such as Microsoft.com. Sender ID depends on organizations populating DNS records with details of the mail servers that transmit messages for their domains; servers that support Sender ID can use this information to check whether a message actually came from a legitimate source. You can decide to delete illegitimate messages, reject them and send a nondelivery report (NDR), or accept them with a status that causes the IMF to increase the SCL for the message. The default action is Accept, but any message that comes in as marked from an illegitimate source is likely to have such a high IMF-calculated SCL value that it will be suppressed anyway, probably by the recipient's junk-mail filter. See http://www.microsoft.com/mscorp/safety/technologies/senderid/default.mspx for more information about the Sender ID framework.
IMF doesn't support cluster environments, but that isn't a big deal. The vast majority of servers that participate in mail hygiene operations are standalone and don't do much except process incoming email to filter for spam and viruses, whereas clusters tend to be used for mailbox servers. By comparison, redundancy and availability of mail hygiene servers is usually accomplished by scaling and load balancing across multiple systems.
The New OAB
For many organizations, the new Offline Address Book (OAB) format introduced in Exchange 2003 works very well with Outlook clients running in cached mode. However, large organizations have encountered difficulties that can swamp servers with client requests for OAB downloads, so SP2 introduces a revised OAB format (OAB v4) and a new update mechanism to relieve the strain on servers.
Outlook clients request a full OAB download if more than a certain percentage of the OAB has changed. The default threshold is 12.5 percent, or one-eighth, of the OAB entries. However, even a small change such as the update of one digit in a phone number can cause Exchange to consider the record changed. Any organization that upgrades from Exchange 5.5, consolidates servers, adds or removes administrative groups, or performs typical email operations (e.g., moving mailboxes between servers, changing physical offices, adding new SMTP or other email proxy addresses), generates a large number of OAB changes. In turn, the default 12.5 percent threshold will easily be surpassed, leading to many client requests for complete copies of the OAB and a subsequent heavy demand on servers. Small organizations generate small OABs, so their servers are less likely to be affected, but large organizations have felt the pain and are therefore less willing to deploy Outlook 2003 in Cached Exchange Mode.
Microsoft's response is to introduce LZX compression to speed transfer of OAB data between server and client (this is the same technology that clients use to download Windows updates from the Web) and a mechanism called Binpatch, which uses Binary Delta Compression (BDC) to apply updates to client OAB files. In addition, clients now generate their own sort orders for the ANR and Browse files based on the PC locale setting instead of depending on the locales that the server supports. Because of the changes to the client, only PCs running Outlook 2003 SP2 can download and use the OAB v4 files; clients running Outlook 2003 or Outlook 2003 SP1 will continue to use the OAB v3a format.
During the OAB-generation process, SP2 servers generate two new files called Binpatch.oab and Data.oab and store these files in the OAB v4 system public folder, as Figure 2 shows. Each Binpatch.oab file contains the delta changes from the last OAB generation run, or every change to the GAL that has occurred during a day. Earlier versions of OAB changed files that contained complete updated records, even if the actual change to the record was minimal, but the new files contain binary patches that Outlook 2003 SP2 clients can combine to create an updated OAB. For example, the OAB v3 "full data" file that Figure 2 shows is 66MB, and the August 17 update is 1003KB, whereas the OAB v4 versions are 34MB and 239KB, respectively. The net result is that Outlook now has far less data to download than earlier versions did.
Microsoft expects the new OAB format and SP2 patches to considerably reduce the number of times a client has to request a full OAB download. Full downloads should now occur only when the OAB files don't exist on a client, when files are corrupted, or when the client hasn't downloaded updates for more than a month. One minor problem is that although the new format reduces server load, it also gives the client more work to do to decompress and apply the binary patch files. If your PC is overworked today, it won't appreciate the extra burden, and you'll notice that things slow down during OAB processing.
Increased Store Size Limit (Standard Edition)
Prior to SP2, the limit of a mailbox store in Exchange 2003 Standard Edition was 16GB. This limit had been in place since Exchange Server 4.0, so it was obviously outdated and inappropriate in a world in which the average size of a message has grown, average disk size has increased, and the cost per gigabyte has decreased enormously. Microsoft's response was to increase the SP2 limit to 75GB. In time, Microsoft will update the version of Exchange included in Microsoft Small Business Server (SBS) 2003 to support the new limit, probably in a service pack that's released several months after Exchange 2003 SP2's release. Having a larger limit for the store is nice, but even an increase of 59GB doesn't match the growth in average message size. In 1996, the average message was around 10KB; it's now 100KB or larger. As a result, just to keep pace, Microsoft could have increased the store limit to 160GB or more. You'll find a good discussion about how Exchange deals with the new size limit at http://blogs.technet.com/exchange/archive/2005/09/14/410821.aspx.
Public Folder Management Changes
Public folders are everyone's favorite part of Exchange. Some organizations find that public folders do a good job in meeting their needs, but far more have discovered that better options exist. For example, Microsoft SharePoint Portal Server and SharePoint Team Services are popular alternatives for organizations that want collaboration tools. Microsoft is clearly moving away from public folders and will eventually drop this feature, probably when the company has solid migration tools that take data and the applications that people have built around public folders to new platforms. In the interim, SP2 will address some of the problems that plague Exchange administrators. You can now use Exchange System Manager (ESM) to stop and resume content replication activity (but only to servers that run SP2 or later), force the replication of the public folder hierarchy (as Figure 3 shows), and update permissions on folders and have the new permissions propagate down through the public folder hierarchy. Finally, Exchange will log public folder deletions in the Application log so that you can determine who deleted a folder if a mistake is made.
Welcome Changes
SP2 doesn't introduce any earth-shattering changes, but it includes many welcome improvements that will make life easier for Exchange administrators and users alike. The update is easy to apply and will be worthwhile for early deployment. As always, make sure that you take the time to test SP2 in your production environment before rolling it out across the organization. With that caveat, enjoy the update.
