Admin Tasks – Cleaning up Stale Shared Mailboxes

I’ve written about preparing for Office 365 migrations in the past. I focused mainly on server tasks

here http://365unity.com/planning-your-exchange-online-migration/

here http://365unity.com/preparing-your-exchange-migration-checking-your-size-and-item-count/

here http://365unity.com/preparing-your-exchange-migration-part-2-converting-shared-mailboxes/

and

here http://365unity.com/preparing-your-exchange-migration-part-3-the-cleanup/

There’s a client task that I’d like to mention, and this applies more so to administrators than users, but can apply equally. If you often connect to other users mailboxes or have AutoMapping set to $True you will sometimes find that mailboxes get orphaned in Outlook. The non-orphaned mailboxes are easy to fix, you simply

  1. Right click your Account in Outlook
  2. Click Properties
  3. Click Advanced
  4. Go to the Advanced Tab
  5. Delete the mailboxes you have access to

However, if this list is empty and you still have mailboxes displaying in Outlook, fixing this becomes more of a manual process. The problem exists because the AutoMap feature has filled a property on the objects Active Directory account that you don’t directly have access to. You will need your System Administrators to fix this. You will need to use ADSI edit to fix this.

The usual caveat, becareful with ADSIedit, the changes are permanent and like the registry if you don’t understand the setting being removed you could cause unwanted and unexpected issues.

Remove msExchDelegateListLink setting

  1. Open ADSIedit
  2. Connect to default naming context
  3. Locate the Active Directory Object (You can do this using Advanced Features in ADUC) (Every object in AD is available here Room, Users, Shared Mailboxes)
  4. Right Click Object
  5. Click Properties
  6. Scroll down to MSExchDelegateListLinked
  7. Double click or highlight and Edit
  8. Delete the Attribute that you want to remove

The mailbox will be removed on the next AD refresh.

To keep this from happening you can use a PowerShell cmdlet to apply the permissions, but it’s not terribly practical

Add-MailboxPermission -Identity user@company.com -User admin@company.com -AccessRights FullAccess -AutoMapping:$false

The important setting here is the automapping.

I would recommend looking at this prior to migrating mailboxes, it sucks more when you have to try to do this with a mailbox in the cloud.

Leave a comment

Your email address will not be published.


*