A short while ago, we posted an article on how to Use Exchange Web Services and PowerShell to Discover and Remove Direct Booking Settings. We received a lot of constructive feedback with some noting that users can experience an issue when enabling the Resource Booking Attendant on mailboxes that were cleansed of their direct booking settings via the sample script we provided. Specifically, the following error can be encountered when the organizer is scheduling a regular non-recurring meeting against the resource mailbox:
“…declined your meeting because it is recurring. You must book each meeting separately with this resource.”
We have updated the script to account for this scenario to prevent and correct this from occurring and we have also updated the article to reflect the changes as well.
In a nutshell, the issue is encountered when we have a divergence of what settings are enabled/disabled between the Schedule+ Free/Busy System (Public) Folder item representing the user’s mailbox and the user’s local mailbox free/busy item. Outlook’s Direct Booking process actually queries the Schedule+ item’s Direct Booking settings when attempting to perform Direct Booking functionality. The Schedule+ folder tree normally contains an item that contains a synced set of Direct Booking settings of that which is stored in the user’s localfreebusy mailbox item. The issue is encountered when the settings between the Schedule+ item and the local mailbox item do not match.
Normally, Outlook triggers a sync of the local mailbox item to the Schedule+ item via deliberate native MAPI code. However, in our case we are using EWS in the sample script, and that syncing trigger does not natively exist. We therefore updated the script to find the Schedule+ item and ensure its settings are congruent with the local item’s settings. The logic for this is actually a bit complicated for two main reasons:
- No Schedule+ item exists in the organization – There are valid scenarios where the Schedule+ item may not exist, such as the mailbox was never opened with Outlook and the Direct Booking settings were enabled via another means, such as MFCMAPI and so on.
- Co-existent versions of Exchange - EWS is rather particular on how public folder and public folder item bindings can occur. EWS by design will not allow a cross-version public folder (or item) bind operation. Period. This means a session, for example on a mailbox on Exchange 2010 would not be able to bind to a public folder or its items on Exchange 2007, there would need to be a replica of the folder on Exchange 2010 for the bind operation to be successful. Further, continuing our example, even if the there is a replica on Exchange 2010, the bind operation would still fail if the user’s mailbox database’s “default public folder database” is set to a non-2010 public folder database (i.e. an Exchange 2007 database). The EWS session would kick back an error stating: ‘There are no public folder servers available’
With these guidelines in mind, we approached the script update to maximize the congruency potential between the local mailbox item and the public folder item. We only disable the direct booking settings in the local mailbox item if one of the following criteria is met regarding the Schedule+ item:
- We can successfully bind to the user’s Schedule+ item
- There is a replica we can touch with the EWS session, and we found the item representing the user and we can therefore safely keep congruency between the local and the Schedule+ items.
- There is no replica present that would potentially contain an item representing the user
- There is no replica in the org (any version of exchange) that would contain an item for the user so there is no potential for getting into an incongruent state between the local and the Schedule+ items.
- There is a replica of the Schedule+ folder on the same version of Exchange that the EWS session is connected to, AND the default public folder database of the user is likewise on the same version of Exchange.
- We could not find a Schedule+ item for the user (if we did, we would have satisfied condition 1 above), but not because there was no replica containing the item (if we did, we would have satisfied condition 2 above), and not because we could not bind to the folder via the EWS limitations we outlined above. We can therefore state that congruency between the local and the Schedule+ items are not at risk and there is no Schedule+ item representing the user.
It should be noted that we will always take action to disable the Direct Booking settings from the Schedule+ item even if the local mailbox item does not have its Direct Booking settings enabled – this keeps us true to our “congruency” logic.
In closing, please remember that the script is a sample and does not cover every possible scenario out there – we made this update because the aforementioned issue reported is central to having the script produce the desired outcome of fully disabling Direct Booking. We are thankful for and welcome your continued feedback!
Dan Smith & Seth Brandes
Exchange PFEs
