Hobby Chef

August, 2007 - Jive into Messaging world - Site Home - MSDN Blogs

Blog - Title

August, 2007

  • Jive into Messaging world

    Server execution failed while registering StoreSink

    • 2 Comments

    …today after tons of research and banging my head to the wall of steel, I have came to discover the cause to "Server execution failed" error message I was getting while registering a COM+ Store Sink using RegEvents.vbs and "An error has occurred creating the registration item. Event sinks must be registered as a COM+ Application prior to creating the registration event item or there may be issues connecting to the network or the server. Also check the data for accuracy." While registering store sink using Exchange Explorer.

     

    I had following event logged in the System Logs

    Event Type:        Error

    Event Source:    DCOM

    Event Category:                None

    Event ID:              10010

    Date:                     8/27/2007

    Time:                     9:32:21 PM

    User:                     N/A

    Computer:          MyServer

    Description:

    The server {9DA0E0FA-86CE-11D1-8699-00C04FB98036} did not register with DCOM within the required timeout.

    {9DA0E0FA-86CE-11D1-8699-00C04FB98036} belongs to MSEXCHANGEIS (Microsoft Exchange Information Store) service.

    Store Sinks use EXOLEDB to access the store, and exodbprx.dll is used as proxy for Exchange OLE DB

    It might be possible that exodbprx.dll registration got corrupted and re-registering may solve the problem.

    To re-register it, use the following command

    C:\>Regsvr32 "C:\Program Files\Exchsrvr\bin\exodbprx.dll"

  • Jive into Messaging world

    EWS: Exchange 2007 Notification Subsystem

    • 28 Comments

    Exchange Web Service in Exchange 2007 contains an Event Notification subsystem, which notifies the client & server applications of events that occur in mailboxes on Exchange 2007 server. Clients can subscribe to this notification subsystem and specify the kind of events they want to be notified for.

    Exchange Web Service for Exchange 2007 supports two types of notifications:

    • Pull Notification
    • Push Notification

    EWS notification clients can be classified in two categories, loosely coupled & tightly coupled

    Loosely coupled clients are

    • connected to EWS through firewall and/or multiple networks
    • not IP Addressable, exchange server cannot resolve them via their IP address
    • their network connection to server is not reliable

    Tightly coupled client

    • exists in the same network as the Exchange Server
    • IP Addressable

    Note: You can decide the type of notification you want to use on the basis of your requirements, although it is more appropriate to use Pull Notification for loosely coupled clients while Push Notification works best with tightly coupled clients.

     For Pull Notification, clients subscribe for events they want to be notified of, and then periodically check for the accumulated notifications from the CAS (Client Access server). CAS does not automatically notify the client for any event occurred on the server and client needs to re-establish the connection with server whenever they want the changes on server.

    The story is different with Push Notification, client need not to periodically request for changes occurred on server. Client subscribe for the particular events and also provide a callback point (web service), which can be called upon by the CAS in case of any change occurred, for which client registered, on server. Generally, push notifications provide less notification latency than pull notification. Servers those can host web service, and have a static IP or DNS name, are served best by push notifications. The web service can then process and redistribute notifications as needed to their clients.

    Pull Notification

     

     

    Exchange Web Services provides a pull subscription so that client applications can discover events that occur in the Exchange store. Using pull subscriptions involves the following three basic steps:

     

    ·         Creating a subscription

    ·         Retrieving store events

    ·         Ending the subscription

     

    Creating a pull subscription

    ·         Create a new Subscribe request.

    ·         Identify the folders to monitor for events.

    ·         Identify the events to monitor for the subscription.

    ·         Define the timeout period for the subscription.

    ·         Send the Subscribe request and receive the Subscribe response. The Subscribe response includes the Subscription ID and the initial watermark that is used for the first GetEvents call.

     

    Retrieving store events

    ·         Create a new GetEvents request.

    ·         Use the SubscriptionId returned in the subscribe response. For the first GetEvents request, use the watermark returned in the subscribe response. For subsequent GetEvents requests, use the last watermark returned in the previous GetEvents request.

    ·         Send the GetEvents request and receive the GetEvents response. Each GetEvents response includes information about one or more events. A watermark is returned for each event. The last watermark must be saved and used in the next GetEvents request.

    Note:  If no store events have occurred since the last GetEvents request, a status event is returned

     

    Ending the subscription

    ·         Create an Unsubscribe request.

    ·         Identify the subscription to unsubscribe from.

    ·         Send the Unsubscribe request and receive the Unsubscribe response.

    Note: A subscription is also deleted if a GetEvents request is not made within the timeout period. The timeout period is specified when the subscription is created with the Subscribe Operation.

     

    Q & A

     

     

    Q. What is a Watermark?

    A. Watermark act as bookmark and gives you an idea what all events have been fired since last watermark. Every time you ask for changes using GetEvents, exchange will give you a list of changes occurred till that time and also a Watermark for that time. Next time you call GetEvents you pass this watermark to the server asking for any event occurred after that watermark. If there were new events then server will give you those events and a new watermark. Upon receiving the new watermark you can update your database to reflect the latest watermark.

     

    Q. How will I update my watermark?

    A. As already answered, every time you call GetEvents you receive a new watermark representing the events till the time you last called GetEvents. You can replace the previous watermark with this new watermark.

     

    Q. Do I need one watermark for each change (appointment)?

    A. No, you need one watermark per subscription. That subscription will receive all the notifications for all the appointments.

     

    Q. Are there issues to consider in terms of maintaining many pull subscriptions simultaneously?

    A. AFAIK there is no known issue and you should be fine with many subscriptions simultaneously.

     

    Q. Will the subscription return events for changes made to appointment details including add/edit/delete of appointment and its attachments?

    A. Yes, while subscribing you pass the information what all events you are interested in. You can select from the following events

    ·         Mail arrival

    ·         Item creation

    ·         Item deletion

    ·         Item modification

    ·         Item movement

    ·         Item copied

    ·         Mail submission

    Item modification should be fired upon adding/removing any attachments. I will once again confirm this for you.

     

    Q. Can I restart my Pull notification client application?

    A. Yes, you can restart your application. Next time you start your application you can re-use the last watermark to re-subscribe for events.

     

    Keywords: Exchange Web Services, Exchange 2007, Notification, Pull Notification, Push Notification

Page 1 of 1 (2 items)