Exchange 2000 Server Service Pack 2 (SP2) introduces the ability for Microsoft Internet Explorer (IE) 5.0 and later clients to receive new-email notifications and calendar reminders through Outlook Web Access (OWA). Although Outlook clients typically have a permanent connection to the Exchange server, OWA is a stateless client working over the HTTP protocol. How can the server notify the client that new email has arrived or an appointment is due if the client isn't connected? In this article, I look at how the Web Distributed Authoring and Versioning (WebDAV) protocol's Subscribe and Poll methods support OWA email notifications and calendar reminders. (For more information about WebDAV, go to the WebDAV Resources Web site at http://www.webdav.org.) I use new-email notifications as the primary example, but you implement calendar reminders in a similar way.
When you use OWA to connect to your mailbox and browse to your Inbox folder, you're taking a snapshot view of the folder's contents. Consequently, you need to click Check for new messages to refresh and update the Inbox folder's and other folders' contents. This approach isn't ideal because it results in wasteful processing as users continually ask, "I wonder whether I have new email?" and click Check for new messages. New-email notification lets users cease pondering this question and provides the trigger to refresh the Inbox folder.
New-email notifications and calendar reminders are enabled by default. You can modify them by clicking Options in the left-hand pane and changing the E-mail Options settings, as Figure 1 shows. Note that you can choose to display a notification message or play a sound when new email arrives. These settings are persisted as properties on the mailbox, along with other settings such as enabling reminders for calendar items. You can view these properties by using Exchange Explorer (included with the Exchange Software Development Kit—SDK), as Figure 2 shows. The property http://schemas.microsoft.com/exchange/newmailnotify can have a value of 0, 1, 2, or 3 to specify all possible combinations of these settings. The property http://schemas.microsoft.com/exchange/enablereminders controls the calendar reminder operations. Because these settings are held as properties on user mailboxes, you can programmatically change them.
New-email notification and calendar reminders are restricted to IE 5.0 and later clients because they are implemented using Dynamic HTML (DHTML) behaviors. When you get notification that new email has arrived, the bottom-left corner of the main OWA window displays an icon that you click to refresh the display of your Inbox folder. Figure 3 shows how this window looks for an IE 5.0 client. For IE 5.5 and later, you'll also see a pop-up window that originates from the System Tray. In addition, if you're using Folder View, dynamic client-side script automatically updates the unread count for the Inbox.
WebDAV Poll and Subscribe
The client initiates the process of checking for new email notifications or calendar reminders. Upon initialization, the client subscribes to the Inbox folder and requests that the server maintain information about whether new email has arrived. The client then polls the Inbox on a regular basis and, based on the server's response, determines whether new email has arrived since the last poll. Note that the client doesn't read the contents of the Inbox during each poll, nor does it specify to the client which messages are new; it merely asks the server whether some activity has occurred on the folder since the last poll. The response is enough for the client to know that a simple refresh of the Inbox will reveal new messages.
To check for calendar reminders, the client subscribes to the calendar folder, requesting notification if any updates occur. The client also searches the calendar folder for any reminders that are due within the next 2 days and maintains a local XML document that contains details of the relevant items. The property urn:schemas:calendar:remindernexttime on a calendar item contains information about when the next reminder is due. Client-side script refreshes the local XML document, which is maintained in memory, only if a poll determines that an update has occurred or if all items in the XML document have passed their next reminder time.
The key to these client requests is the ability to use the WebDAV protocol against the Exchange Store (and the document store in Microsoft SharePoint Portal Server) to subscribe to a URL and to subsequently poll that subscription for updates. In the case of new email, the URL points to the user's Inbox (e.g., http://dboexcvs1/exchange/kevin.laahs/inbox).
The WebDAV protocol extends HTTP 1.1 with methods that accommodate manipulating resources, collections of resources, and properties. As Figure 4 shows, an HTTP message consists of three parts—the initial line, header lines, and the main body—and the values in these elements will depend on the nature of the HTTP communication. The initial line has three components. On a request from a client, the initial line will contain the method name, the Uniform Resource Identifier (URI), and the client version. On a response from the server, the initial line will contain the server version, the response status code, and the reason phrase. The header lines specify relevant host headers for the task at hand, and the optional body will usually contain an XML-formatted document that's either being sent to or received from the server. Host headers can supply details such as response timeouts and the number of records to return during a search.
If you take a network trace of an OWA client during initialization, you'll see an HTTP message containing the Subscribe method for the user's Inbox. Figure 5 shows the message (I've removed certain lines for clarity).
The Notification-Type header specifies that this subscription request is for any new email that arrives at the URL passed in the initial line. Other notification types can determine whether items have been updated, deleted, or moved at the URL specified. SharePoint client extensions to Web Folders and calendar reminders, which subscribe to receive Update notification types, often use these notification types.
In response to the Subscribe request, the server returns an HTTP message formatted as Figure 6 shows (I removed some lines for clarity). The server allocates a unique ID to each successful subscribe request and returns the ID in the Subscription-id header. The client essentially leases the subscription; if the client doesn't resubscribe within the lease period, the server cancels the subscription when the lifetime has passed. Figure 6 shows a lifetime of 1 hour (3600 seconds). This leasing mechanism avoids the server having to process subscriptions for clients that don't unsubscribe cleanly (for example, if a user switches off his or her PC or closes the browser without logging off). The Subscribe request can specify the desired lifetime, but the OWA client doesn't use the desired lifetime parameter. All subscriptions default to the 1-hour lifetime, as do calendar reminder update subscriptions.
After a client establishes a successful subscription, a Poll method can determine whether any notifications are available. Figure 7 shows the relevant parts of the HTTP message that the OWA client sent. The client initiates polling the Subscription-id at regular intervals—every 2 minutes for new email notifications and every 15 minutes for calendar reminders. These timings are set as the pollinterval attribute on the notification and reminder behavior elements that are hidden on the server-generated navigation bar Web page. The behavior definitions are in the Ctrl_notify20.htc, Ctrl_reminder20 .htc, and Ctrl_poll20.js files in the \exchweb directory on the server. You can use the registry to change the default polling time on the Exchange 2000 server, but implementing user-specific timing requires changes to these files. Figure 8 shows the registry entry for new email notifications. Figure 9 shows the registry entry for new calendar reminders.
The SP2 deployment guide (http://www.microsoft.com/exchange/techinfo/deployment/2000/sp2deployment.asp) states that each client poll takes 0.064 megacycles on a server running Exchange 2000. Therefore, a system with an eight-processor, 550MHz server and 3000 users generates the following CPU load (assuming all clients poll simultaneously): A 1-minute poll generates a 7.2 percent CPU load, a 2-minute poll generates a 3 percent CPU load, and a 5-minute poll generates a 1.4 percent CPU load. Note that the Default reminder time for calendar items, which you can specify in the Options dialog that Figure 1 shows, isn't related to the reminder polling interval. The reminder polling interval is the default used to calculate reminder times for new appointments (and is stored in the http://schemas.microsoft.com/exchange/reminderinterval property on the user's mailbox).
Upon a successful poll, the server will send an HTTP response message. From the message status and XML body, the client can determine whether new email has been delivered. Figure 10 shows two examples of HTTP response messages (with some lines removed for clarity). Both responses are multistatus responses because, in theory, a single Poll request can ask for the status of multiple subscription IDs. Therefore, you need to look at the XML body to see the status of the individual IDs. In the first example, you can see that the status specifies that No Content was found, whereas in the second example you see 200, specifying that new email has been delivered. The client then displays the new-email icon. When the user clicks the icon, it issues a URL to the contents of the user's Inbox (e.g., http://dboexcvs1/exchange/kevin.laahs/inbox?cmd=contents).
When the client chooses to have sound play with notifications, the sound comes from the file Exchweb/img/notify.wav held on the server (the calendar reminder comes from reminder.wav). As with setting the poll interval, setting a user-specific sound requires customization of the dynamic behavior. In addition, the client will use the PROPFIND method to read the value of the property urn:schemas:httpmail:unreadcount on the user's mailbox and display this value alongside the Inbox folder. The ability to display the unread count of both mailbox and public folders is another new feature in SP2. The only other status value that the client acts upon is labeled 412 (Precondition failed), which indicates that the subscription has expired. In this case, the client executes a new Subscribe request.
Microsoft has provided support for Poll and Subscribe methods in the Exchange Store since Exchange 2000's first release. But the OWA client didn't take advantage of these methods until Microsoft released SP2. Instant Messaging (IM) uses the Poll and Subscribe methods in SP1 for client-instantiated communications, and SharePoint Portal Server Client Extensions use the methods against the Document Store for Web Folders functionality. You can also use these powerful methods in your own applications that work with data in the Exchange Store or Document Store.