Might be a strange behaviour, or by design?…. Whatever the reason, a customer “lost” the ability to use scheduling assistant in outlook when creating new meeting requests. The calendars was not showing any information, and hoovering over the calendars gave me information about not having permissions. Scheduling assistant uses the “Default” permissions, if the user is not assigned as a member of another group with different accessrights. That’s how i ended up with two problems.
I’m not sure why the “Default” accessrights suddenly got “corrupted”. Maybe an Exchange Server 2013 rollup. Migration from Exchange 2010 would have raised this problem a year ago, and I didn’t get any feedback about this issue until some weeks ago, when I installed two new exchangeservers with CU7 out of the box.
Anyway. When running Get-MailboxFolderPermission on the calendars in the organization, it showed Default had “Reviewer” accessrights, but It really hadn’t. I had to “refresh” the permissions of “Default” user, running this script. With english and norwegian outlook, there is a mix of names for the calendar folder. The script checks what the name of the calendar folder is, before it executes.
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
# Get the mailboxes
$Mailboxes = Get-Mailbox -Filter {RecipientTypeDetails -eq “UserMailbox”} -ResultSize Unlimited
# Looping
ForEach ($Mailbox in $Mailboxes) {
# Get the name of the calendar folder
$Calendar = (($Mailbox.PrimarySmtpAddress.ToString())+ “:\” + (Get-MailboxFolderStatistics -Identity $Mailbox.DistinguishedName -FolderScope Calendar | Select-Object -First 1).Name)
# Set the permissions on the folder
Set-MailboxFolderPermission -Identity $Calendar -User Default -AccessRights Reviewer}
NOTE: New folderpermissions uses New-MailboxFolderPermission if no permission is already set for a user.
Running this updated the default accessrights on the calendars, and scheduling assistant started showing free/busy for people entered in the assistant.
All good? No.
People that was assigned to another group with “Author” accessrights to calendars, was still having problems. Running the script again updating the Calendar-authors group fixed the problem for those users.
As stated earlier, I don’t know why this was happening, but it’s an easy fix. If anybody can enlighten me about the cause for this accessrights problem, please leave a comment.
Kjartan's notes from the field 