Worked on the Free / Busy issue recently and thought to share troubleshooting steps. Free / Busy usually is “black box” for a lot of Exchange folks I was talking with, but essentially it is really easy and straight forward service to troubleshoot. I’m planning to write article about it and most common troubleshooting scenarios in future.
Now, back to the case. FB access was working for entire org, just several users were suffering FB issues. UserA couldn’t see FB of UserB and UserC… And vice versa. Other users could see FB for UserA, UserB… All users were part of the same Exchange organization.
With above, conclusion was that probably permission level issues were in place. Fiddler trace confirmed suspicious:
<FreeBusyResponse><ResponseMessage ResponseClass="Error"><MessageText>Microsoft.Exchange.InfoWorker.Common.Availability.NoFreeBusyAccessException: The caller does not have access to free/busy data. . Name of the server where exception originated: SERVER01. LID: 44348</MessageText><ResponseCode>ErrorNoFreeBusyAccess</ResponseCode><DescriptiveLinkKey>0</DescriptiveLinkKey><MessageXml><ExceptionType xmlns="http://schemas.microsoft.com/exchange/services/2006/errors">NoFreeBusyAccessException</ExceptionType>
Fired PowerShell session to check permission and to my surprise, permissions seemed OK:
Get-MailboxFolderPermission userA:calendar FolderName User AccessRights ---------- ---- ------------ Calendar Default {AvailabilityOnly} Calendar UserB {Reviewer} Calendar UserC {Reviewer} Calendar UserD {Reviewer} Calendar UserF {Reviewer}
For all users that was working, ACL wasn’t present which means they are going to fail to “Default” scope and get “AvailabilityOnly”. Other users that have permissions shouldn’t get “NoFreeBusyAccessException” as ACL allows them “FullDetails” with “Reviewer” permissions. Only one strange thing I found here is that default “Anonymous” permission of “None” is missing, but that shouldn’t matter at all since all users within same Exchange organization should have authenticated session.
Going forward I wanted to compare raw store level permission with what Get-MailboxFolderPermission cmdlet was showing. In order to do that, Get-StoreQuery should be used and steps as outlined below:
1. Find MailboxNumber within store:
$userMbx = Get-Mailbox user@domain.com
Get-StoreQuery -Database $userMbx.Database -Query "Select MailboxNumber from Mailbox Where MailboxGuid='$($userMbx.ExchangeGuid)'"
MailboxNumber
-------------
194
2. Find Calendar folder in the store:
$userMbxFolder = Get-StoreQuery -Database $userMbx.Database -Query "Select * From Folder Where MailboxNumber=194 and DisplayName='Calendar'"
3. Parse Folder ACL blob:
$userMbxPerms = Get-StoreQuery -Database $userMbx.Database -Query "Select * From ParseAclTableAndSD($($userMbxFolder.AclTableAndSecurityDescriptor))" $userMbxPerms.Value ACL table: Name(0): SID(0): S-1-1-0 IsGroup(0): False Rights(0): FreeBusyAll EntryId(0): Name(1): UserA SID(1): S-1-5-21-1234567890-1234567890-123456789-1681589 IsGroup(1): False Rights(1): EditAny, DeleteAny, Author, FreeBusyAll EntryId(1): 00000000 12345678 12345678 12345678 12345678 12345678 00000000 12345678 4D532F6F 753D4578 6368616E 67652041 646D696E 69737472 61746976 65204772 6F757020 28465944 49424F48 46323353 50444C54 292F636E 3D526563 69706965 6E74732F 636E3D4D 41594552 45303000 EntryId(1).Eidt: UserA EntryId(1).EmailAddress: /o=G/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserA Name(2): UserB SID(2): S-1-5-21-1234567890-1234567890-123456789-1724373 IsGroup(2): False Rights(2): ReadOnly, Visible EntryId(2): 00000000 12345678 12345678 12345678 12345678 12345678 12345678 12345678 EntryId(2).Eidt: UserB EntryId(2).EmailAddress: /o=G/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=UserB ... ... ... SID to Type map: SID:S-1-1-0, Type:User SID:S-1-5-21-1234567890-1234567890-123456789-1681589, Type:User SID:S-1-5-21-1234567890-1234567890-123456789-1724373, Type:User SID:S-1-5-21-1234567890-1234567890-123456789-1366337, Type:User ... ... ... SD: O:SYG:SYD:(A;CI;0x1208ab;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(D;CI;0xd4114;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(A;OIIO;0x1f0fbf;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(A;CI;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(D;CI;0xd4116;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(A;OIIO;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(D;OIIO;0xd0716;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(A;CI;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(D;CI;0xd4116;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(A;OIIO;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(D;OIIO;0xd0716;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(A;CI;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1664815)(D;CI;0xd4116;;;S-1-5-21-1234567890-1234567890-123456789-1664815)(A;OIIO;0x1208a9;;;S-1-5-21-1234567890-1234567890-123456789-1664815) ... ... ... FreeBusy SD: O:SYG:SYD:(A;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1681589)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1724373)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1366337)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1664815)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1549750)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-2149643)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1679850)(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-2181067)... ... ...
After observing raw FreeBusy SD, I noticed that all SIDs from the subject had “D” in front of ACE string which stands for “Deny”:
(D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1724373) (D;CI;CCDC;;;S-1-5-21-1234567890-1234567890-123456789-1366337)
ACL string structure can be found here.
Raw ACL showed that FB permissions were incorrectly set on ‘Calendar’ folder, while Get-MailboxFolderPermission displayed folder level permission which were bit misleading. In order to correct this issue, user must set FB level permissions on ‘Calendar’ folder through Outlook and give the appropriate permission to the people that were experiencing the issue.