EWS PUSH - What is the StatusFrequency for

  • Article

The StatusFrequency value used in EWS Push notifications is often misunderstood.  So, I will try to provide some information on this setting which may help.

The important thing to understand:  StatusFrequency is really not a "frequency" - it’s a maximum timeout value based upon the maximum number of retries - StatusFrequency is in essence the number of retries.

Its best to wait at least twice the time of the expected time out before re-issuing the PUSH request. Push subscriptions notifications will be sent  until the maximum number of minutes is reached (specified by the StatusFrequency element. The way it works is that the initial notification should be tried right away, if that fails then the next try is in 30 seconds.  After that, the next retry is double the prior one... 30, 60, 120, 240 seconds... Each retry is basically the" frequency" of retries. The retries are done until the frequency you specified is reached. Note that the actual time of the PUSH occurs may be delayed by other things happening on the sever, so the expected PUSH time is not exact. The default retry with EWS is 30 seconds.  The Exchange managed API has a default of 30 minutes - that's six retries.

    Retry     Seconds      Time

    0         0:00         Initial Sync
    1         30           00:30
    2         60           01:00
    3         120          02:00
    4         240          04:00
    5         480          08:00
    6         960          16:00
    7         1920         32:00
    8         3840         1:004:00

Related links:

Subscribe:
https://msdn.microsoft.com/en-us/library/office/aa566188(v=exchg.140).aspx

FrequencyStatus
https://msdn.microsoft.com/en-us/library/aa564048(v=exchg.80).aspx

Unsubscribe Operation:
https://msdn.microsoft.com/en-us/library/office/aa564263(v=exchg.140).aspx

Here are some other things to note as your doing Push Notifications...

Push notification subscriptions:

There were some issues with Exchange 2010 and 2013 which were fixed in the latest hotfix rollups – so, it’s important that any issue you encounter has been tested with the latest rollups.

Here are some important points.

  1. Keep in mind that watermarks are good for 30 days.
  2. Water marks always change - you get the old one off the prior call and use it with the next call.  Don't forget to store the last one - you will need it to do the next call.
  3. Notifications do a have a timeout value within that based upon the “StatusFrequency”.  See: https://msdn.microsoft.com/en-us/library/office/aa564048(v=exchg.150).aspx
  4. For Push notations, your code needs a time based piece of compensation code for when notifications have not been received for a while –
    You may need to re-subscribe when that happens.  Notifications can and do fail – expect this to happen sometimes.  This is why you need to have compensating code to check for notifications and have not received a notification for a while.  Also note that sometimes the CAS will delay a response due to things such as it being overloaded.
  5. If the watermark times out then you have to resync and re-subscribe – ie start from zero and do a full new resync.
  6. Subscriptions are not supported for delegate user access.  If you do then you will get an ErrorSubscriptionDelegateAccessNotSupported error.

If your still within the 30 days of the water mark but the frequency has past then do a re-subscribe using the last watermark.

  1. Re-subscribe with the existing watermark if its valid.  Don’t unsubscribe and re-subscribe unless you want to cancel the subscription instead of letting the subscription just timeout.
  2. If your code is just looking for newmail notifications
    and the server is on-premise then a transport agent may be a lot more
    efficient.  This type of application is often used when a lot of mailboxes
    are involved and certain events such as newmail need to have code run when they
    are raised.

Timeout:

  1. The Exchange Managed API has a timeout which can be increased.
  2. There is a timeout server side which you might also be able to increase.  An administrator would need to set this.  This setting cannot be changed for 365 as I understand it.
  3.  Your code should have retry logic.  Servers do get busy.
  4. Be sure that the application is not exceeding throttling limits with your application for that server .
  5. Check the event logs if you get a busy error in case you got throttled.

Listeners:

With listeners there should be 1 listener per process.  Yes, that means you should have just one in your listening application.  The way the listening application should work is to have the listener listen to all incoming traffic and then spawn a new thread to handle each notification as its received. So, basically the listener just receives the notifications and hands off the work to be done.  This allows the listening thread to not be tied up.  This allows the application to handle an immense amount of notifications at once and process them.

Autodiscover:

If you get the EAS URL through Auto discover and cache it then it would increase performance.  AutoDiscover requires a lot of calls, so a lot of AutoDiscover activity can reduce performance. The thing is to avoid doing AutoDisover as much as possible.  However, its recommended to redo auto discover every 24 hours for mailboxes in order to get the optimal CAS server – you might be able to increase or skip this for on-premise mailboxes if the environment does not get changed often. If the mailboxes are not on-premise then set the scplookup setting on the Exchange Managed API service object to false – this will cause AD lookups to be skipped.

Consider doing a call using GetUserSettings to instead of doing AutoDiscover off of the service object whenever possible. Why?  It allows you to specify an array of addresses, which is more efficeient than doing separate AutoDiscover calls for each mailbox off of a service object.

Exchange configuration:

There are Exchange configurations to consider setting for EWS traffic.  If the proxy is not accounted for, the notifications may not reach the listening application even though Exchange tries to send them.

Proxying CAS HTTP Cross Forest Availability Request
https://blogs.technet.microsoft.com/appssrv/2009/08/11/proxying-cas-http-cross-forest-availability-requests/

Event Notifications in Exchange 2010
https://msdn.microsoft.com/en-us/library/office/aa579128(v=exchg.140).aspx#sectionSection2