Mailbox auto-mapping, Exchange 2010 to Exchange 2016 migration

Question

So when I first came on scene with my company they were running Exchange 2010 and I was surprised to find that anytime we granted a user full mailbox permissions to another user's mailbox, it mapped in Outlook automatically. In the past I had worked in Exchange 2010 environments and this was not the case. You actually had to go into the Outlook config on the client and add this second mailbox yourself.

I actually discovered this because I had done it manually the first time and the user ended up with duplicate entries. The manual add needed to be removed.

During the time we only had Exchange 2010 running, sometimes there would be issues when a user was revoked full permissions to another's mailbox and the auto-mapping in Outlook would remain. So the mailbox would still display in Outlook, but they no longer had access. Because it was auto mapped originally, you couldn't simply delete it from the Outlook profile on the client, you actually had to go into ADSIEDIT and modify an attribute. Here is my note regarding this little hack..

Look for this property in ADSIEDIT. On the origin mailbox, not users who you are connecting the mailbox to.
"MSExchDelegateListLink" <--find user who was revoked and remove. Auto-mapping stops for this user. Not all users, just the user removed.

So.. Fast forward to today and we are in the middle of an Exchange 2016 migration from 2010. All standard user mailboxes have already been moved to 2016 and the users who still have full rights to shared mailboxes (which aren't shared mailboxes, just standard user mailboxes) on 2010 are still connected just fine. Nothing changed, no reports of outages.

The trouble started when we tried to move the shared mailboxes (hate this term, they are actually just user mailboxes that others have full rights to) from Exchange 2010 to 2016. A simply restart of Outlook did not get the user reconnected to the shared resource. I am hearing that helpdesk folks are having to manually add the shared mailbox, but in some cases there are duplicates where one isn't accessible.

So, all that to say what is the smoothest way to get these user mailboxes that happen to be shared moved over to Exchange 2016 without disconnecting everyone and creating this influx of support tickets?

Ps.. I did find a command online that I have never seen before which appears to enable or disable auto-mapping. I am wondering if this command just modifies the attribute I listed above? You can't seem to run a Get-MailboxPermission command to see if it has already been set. Not sure where this command fits in, maybe it is only compatible with certain versions of Exchange, I dunno.

Add-MailboxPermission –Identity shared-mailbox –User
your-mailbox –AccessRights FullAccess –InheritanceType
All –Automapping $false

Regards,
Adam Tyler

Answer 1

Status update... Well, @Kael Yao-MSFT all make sense. I think I had a pretty good handle on this before posting. It seems the root issue may be that a simple restart of Outlook isn't getting users reconnected to these mailboxes that happen to be shared with multiple users. They aren't shared mailboxes again, just mailboxes where multiple users have been given access.

Helpdesk would take this inbound call and start troubleshooting. Typically they would attempt to manually map the additional mailbox further compounding issues in Outlook. At some point there would be multiple entries in Outlook for the same shared mailbox and one may work or all may not. Then the helpdesk would forget which was mapped automatically and which wasn't.

What seems to help in this process is bouncing the MSExchangeAutodiscoverAppPool Application Pool constantly during a shared mailbox move to the new server. I run the Update-GlobalAddressList command too just for good measure. I'm not sure why this AppPool has to be restarted often, but if you don't Outlook can't find the new mailbox server after a move from Exchange 2010 to 2016.

Regards,
Adam Tyler

Answer 2

Hi Adam.

Because it was auto mapped originally, you couldn't simply delete it from the Outlook profile on the client, you actually had to go into ADSIEDIT and modify an attribute.

I tested in my lab (Exchange 2010 and Exchange 2016 coexistence).
If a user was revoked full permissions to the shared mailbox, this process should remove the AD attribute msExchDelegatelistlink, which is responsible for the full access permission.
Not sure why it isn't removed correctly and needs to be manually removed.

---

A simply restart of Outlook did not get the user reconnected to the shared resource.

Did you mean you can see the shared mailbox in Outlook by automapping, but cannot connect to it.
While manually adding the shared mailbox works fine.

Have you tried recreating the Outlook profile?
Usually it is required after a migration to avoid some problems caused by the local cache.

I am hearing that helpdesk folks are having to manually add the shared mailbox, but in some cases there are duplicates where one isn't accessible.

So, all that to say what is the smoothest way to get these user mailboxes that happen to be shared moved over to Exchange 2016 without disconnecting everyone and creating this influx of support tickets?

I suppose recreating the Outlook profile should also work in this case, while it is also not easy to operate.

Another workaround should be as you mentioned, disabling automatting and manually adding the shared mailboxes.

To disable the AutoMapping feature, you may need to first remove the full access permission and rerun Add-MailboxPermission command with -AutoMapping $false.

---

If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.