OWA Free/Busy posting process


OWA and Outlook both post and poll the same FB data to the public store, but each client has its own method and time frame when data is posted. When Outlook needs to post data, each client simply calculates the data and writes it directly to the public store on the Exchange server. Read more here. Each Outlook user has direct control of how often FB data is written to the public store. (Tools, Options, Calendar Options, Free/Busy Options) but is easily changeable.

OWA has a different method. For OWA to post FB data, the Exchange server has to post it on behalf of all the users. Since the Exchange server posts the data, the time frame is the same for all users on that server, there is no individual settings that allow the users to select how often data is posted.

To understand how to speed up the OWA FB posting, here is the high level process the Exchange server follows to post FB data after a calendaring item is booked using OWA.

When the calendaring item enters the store, it’s processed like any other calendaring item. Store then packs all the relevant FB information up into a new message and places it in the System Attendant’s (SA) mailbox where it waits to be processed by the Polling Thread.

The polling thread scans the SA mailbox for new FB messages every 5min, once it finds messages that needs to be posted it queues it up where a worker thread processes the queue posting the FB data to the Exchange public store.

Although this process may seem like there are more steps than required, the design had to take into consideration many things like legacy support, clustering, scalability and performance. Certainly we don’t want to choke off the store process trying to post FB data when the public store happened to be unavailable.

The polling thread by default scans every 5 min, but can be changed by adding a registry key on the Exchange server. This change affects all OWA users on the Exchange server where the registry key as been added. The shortest polling interval is 30 seconds. If this value is set to anything less than 30, it has no effect. i.e., the default value (5 min.) is used.

PollingInterval (DWORD: seconds)
 Location: SYSTEM\CurrentControlSet\Services\MSExchangeFBPublish\Parameters\<VS name>
This is the periodic interval used by polling thread to poll the SA mailbox for FB messages.

<VS name> is the name of the Exchange server (Virtual Server); this is used to support clustering.
For the new polling interval to take effect, you need to restart the system attendant service (MSExchangeSA).

Watch the process:
You can watch the messages enter and get deleted after it’s been processed from the SA mailbox. In ESM, Servers | <Select Server> | Storage Group | Mailbox Store | Mailboxes and look for System Attendant. After adding a calendaring item using OWA, you will see this increase, then after the polling thread has processed, and you refresh, it will decrease.

Eric Hartmann

Comments (2)
  1. Raveendran Chinnasamy says:

    I always wonder why i used to get MSPublicFBPublish event error ids are generated every 5 min . The resolutuion is to restart SA as per MS .( Event id 8197) . Very negligible OWA users so i always ignore it .

    Thanks for the information .

    Raveendran@gmail.com

  2. Jason Krueger says:

    Fantastic! I’ve been looking high and low for this information.

    I originally had been hoping that the worker thread would provision *both* the public and personal free busy items. This would have been a great workaround to the problems I’m facing trying to find an alternative for provisioning both these items by manipulating Outlook using the object model to create them as a side-effect of posting a dummy appointment (although I found out I didn’t have to save the appointment).

    Alas it turned out to only provision the public free/busy and not the local which is required for doing the delegation and flipping the resource scheduling bits required for creating conference rooms (Why the hell are these on the LocalFreebusy?!?).

    Unfortunately using the object model has turned out to be completely unreliable. Particularly it’s conflicts with CDOEX.

    So I’ve dived into the ol’ Outlook Spy to figure out what I need to do to simulate the Outlook app (the key bit I missed earlier was the PR_FREEBUSY_ENTRYIDS prop on the Inbox and Root folder).

    Any warnings from the wise before going completely down this hole? (local free/busy item provisioning)

Comments are closed.

Skip to main content