Event Notifications in Exchange 2010
Last modified: September 21, 2010
Applies to: Exchange Server 2007 | Exchange Server 2010
In this article
Event Notification Clients
Pull Event Notifications
Push Event Notifications
Exchange Web Services includes an event notification subsystem. The purpose of this subsystem is to notify server and client applications of events that occur in mailboxes on an Exchange server. Clients subscribe to the notification subsystem and can specify the events for which they want to receive notifications. Exchange Web Services allows for the following types of notifications:
Pull event notifications Notifications that are requested by the client applications.
Push event notifications Notifications that are sent by the notification subsystem.
Streaming event notifications Notifications that are sent by the notification subsystem through a connection that remains open.
Event Notification Clients
Exchange Web Services event notification clients are either loosely coupled or tightly coupled. The following are the characteristics of loosely coupled clients:
They are connected to the Exchange server through firewalls and/or multiple networks or are otherwise topologically distant.
They are not IP addressable from the Exchange server on which the Client Access server role is installed.
They are not reliably connected to the network.
The following are the characteristics of tightly coupled clients:
They are usually on the same network as and frequently in close logical proximity to the Exchange server.
They are IP addressable.
Pull notifications are generally more appropriate for loosely coupled clients. Push notifications are generally more appropriate for tightly coupled clients.
Pull Event Notifications
Client applications that subscribe to pull event notifications specify particular events for which to be notified and periodically request accumulated notifications from the Client Access server. Because the clients are not called directly by the Client Access server, but instead reestablish connections to the server as necessary based on their requirements, pull notifications are best used for loosely coupled clients.
Pull Event Notifications Topology
In a standard pull event notification scenario, loosely coupled clients interact with a Client Access server by using a marginally reliable, fast, and quickly reestablished connection, such as a wireless LAN. These clients can connect to the Client Access server as needed; they do not have to maintain open connections to the server. However, they are frequently inaccessible to inbound IP connections because of firewalls and changes in dynamic IP addresses.
The following figure shows a standard pull event notification scenario.
Loosely coupled clients that have quickly established, low-cost connections to the Client Access server
.gif "Pull subscription with loosely-coupled clients.")
Tightly coupled client that has high-speed, reliable connection to the Client Access server
.gif "Pull subscription for a tightly-coupled client.")
Push Event Notifications
Push event notifications enable client applications to subscribe to particular events and provide the Client Access server a callback address and a client-side Web service to which the event notifications are actively delivered. Generally, push notifications provide for smaller notification latency than pull notifications and are the best option for tightly coupled clients to which the Client Access server has reliable access.
Because servers can host a Web service, and have a stable IP address or DNS name, they are best served by push notifications. The servers can then process and redistribute notifications as needed to their clients.
For an example that shows how to use push notifications, see Push Notification Sample Application.
Push Event Notifications and Proxy Servers
In networks that use a proxy server, push notifications from the server are sent to the proxy server and not directly to the URL that is specified in the subscription. To bypass the proxy for push notifications, you can set the bypasslist setting in the web.config file. The following example shows you how to bypass a proxy for push notifications.
<configuration>
<system.net>
<defaultProxy>
<proxy usesystemdefault="true" bypassonlocal="true" />
<bypasslist>
<add address="exchangeserver.example.com" />
</bypasslist>
</defaultProxy>
</system.net>
</configuration>
The bypass list supports multiple computers. DNS and IP address regular expressions are also allowed.