Exchange users unable to share calendars post AD/Exchange migration

We just recently went through an AD forest migration AND an Exchange 2010 -> 2016 migration across forests at the same time. Good times.

One of the many issues that came up after the migration was the majority of our users being unable to share their calender’s with other users.

When trying to share via manually editing the calendar permissions users would get the error “One or more users cannot be added to the folder access list. Non-local users cannot be given rights on this server.”

 

If users tried to go the invite route by right clicking their calendar, choosing ‘Share’ and ‘Share Calendar’ they would get “Calendar sharing is not available with the following entries because of permission settings on your network:”

 

If you took a look at our GAL you’d see all of the users you couldn’t share with had a circle with a line through their entry:

 

I ended up stumbling across a solution by accident when trying to fix this on my own account. It turned out my account was a ‘Shared’ mailbox and not a ‘User’ mailbox. I converted it with the below PowerShell and then my account started working again:

Set-Mailbox -Identity <USERNAME> -Type Regular -DomainController <DC FQDN>

This worked great for me but my situation was unique. Other users with the issue were already ‘User’ mailboxes. I took another problematic account and ran the above command on it and got this:

Set-Mailbox -Identity <USERNAME2> -Type Regular -DomainController <DC FQDN>
WARNING: Couldn't convert the mailbox because the mailbox "USERNAME2" is already of the type "Regular".

Despite that warning message this users mailbox was now fixed after the user closed/re-opened Outlook.

I re-ran the command against their mailbox and the output was this:

Set-Mailbox -Identity <USERNAME2> -Type Regular -DomainController <DC FQDN>

WARNING: Couldn't convert the mailbox because the mailbox "USERNAME2" is already of the type "Regular".
WARNING: The command completed successfully but no settings of '<DOMAIN FQDN>/User Accounts/Staff/USERNAME2' have been
 modified.

Why didn’t I get that second warning about not making any changes the first time I ran it? Simple. It’s because something was changed and Microsoft doesn’t think I need to know that.

Digging into the account attributes I figured out what changed. It’s called ‘msExchRecipientDisplayType’ and was introduced in Exchange 2007. This attribute determines what kind of recipient the mailbox is in the Address Book.

Pre-AD Migration msExchRecipientDisplayType was set to 1073741824 which is a “ACL able Mailbox User”.

Post-AD Migration msExchRecipientDisplayType was set to 0 which is a “Mailbox User”.

Makes sense now why you can’t apply permissions (ACL) on a “Mailbox User” when a “ACL able Mailbox User” user type exists.

We used Microsoft’s own tools (ADMT, Exchange 2016) to migrate our users from one forest and Exchange to another. Some where in that migration the attribute was wiped out and not transferred on 2941 out of 3123 mailboxes.

Here is how you can identity all users in your environment with this attribute set to “0”

Get-AdUser -Filter * -Properties Name,msExchRecipientDisplayType -Server <DC FQDN> | Where-Object { $_.msExchRecipientDisplayType -eq "0" } | Select Name,msExchRecipientDisplayType

Our environment is a mix of Shared, User, Resource and Equipment Mailboxes. There were affected accounts in all four categories. If we did a simple script that looked for “msExchRecipientDisplayType=0” and changed it to “1073741824” we might end up with the wrong value for a mailbox depending on what type it’s supposed to be. Based on my reading msExchRecipientDisplayType should be 1073741824 for Shared and User mailboxes, 7 for a Room Mailbox and 8 for a Equipment Mailbox.

We decided the best way to fix this was simply re-applying the user type that a mailbox already was. This made the PowerShell much simpler. Here’s what we ran:

Get-Recipient -Resultsize unlimited | where {$_.RecipientTypeDetails -eq "SharedMailbox"} |Set-Mailbox -Type Shared -DomainController <DC FQDN>
Get-Recipient -Resultsize unlimited | where {$_.RecipientTypeDetails -eq "UserMailbox"} |Set-Mailbox -Type Regular -DomainController <DC FQDN>
Get-Recipient -Resultsize unlimited | where {$_.RecipientTypeDetails -eq "RoomMailbox"} |Set-Mailbox -Type Room -DomainController <DC FQDN>
Get-Recipient -Resultsize unlimited | where {$_.RecipientTypeDetails -eq "EquipmentMailbox"} |Set-Mailbox -Type Equipment -DomainController <DC FQDN>

These commands together fixed 2890 of 2941 broken mailboxes.

This will generate a simple report of which mailboxes weren’t converted and what type they are:

$domainController = "<DC FQDN>"
$brokenUsers = Get-AdUser -Filter * -Properties Name,msExchRecipientDisplayType -Server $domainController | Where-Object { $_.msExchRecipientDisplayType -eq "0" }
$user = ""

foreach ($user in $brokenUsers) {

    Get-User $user.Name -DomainController $domainController | Group RecipientTypeDetails

}

Clear-Variable domainController
Clear-Variable brokenUsers
Clear-Variable user

I took one of the accounts that wasn’t fixed and ran this command:

Set-Mailbox -Identity <USERNAME> -Type Regular -DomainController <DC FQDN>

This corrected the account. No idea why the batch command didn’t. I ran this command for all of the regular mailboxes that didn’t fix in the batch and it worked fine. That left me with a bunch of shared mailboxes that were still broken and one user account that would not fix.

Running this on the shared mailboxes did not help:

Set-Mailbox -Identity <USERNAME> -Type Shared -DomainController <DC FQDN>

I checked one of the problematic accounts in ADSIEdit.msc and it had the correct msExchRecipientDisplayType value of 1073741824 despite PowerShell telling me it was set to 0.

Since there were only 23 accounts left that were problematic I used ADSIEdit to verify and fix the remainders.

We ran into a few users who still had problems using the e-mail invite method to share their calendar. This was fixed by having them clear their Outlook auto-complete via these steps:

1. On the File tab, choose Options > Mail.
2. Under Send messages, choose Empty Auto-Complete List
3. Choose Yes to confirm you want to empty the list.
4. Close/Re-open Outlook
5. Try again

 

References

• https://blogs.technet.microsoft.com/johnbai/2013/09/11/o365-exchange-and-ad-how-msexchrecipientdisplaytype-and-msexchangerecipienttypedetails-relate-to-your-on-premises/
• https://blogs.technet.microsoft.com/benw/2007/04/05/exchange-2007-and-recipient-type-details/
• http://www.mistercloudtech.com/2016/05/18/reference-to-msexchrecipientdisplaytype-msexchrecipienttypedetails-and-msexchremoterecipienttype-values/
• https://blogs.technet.microsoft.com/benw/2007/04/05/exchange-2007-and-recipient-type-details/