The documentation from Microsoft seems to suggest that disabling a mailbox is a straightforward operation. Unfortunately, there are a few "gotchas".
Mailbox Retention
When a mailbox is disabled, it is reclassified as a "Disconnected Mailbox". By default, Exchange will retain disconnected mailboxes for 30 days. This is an attribute of the database where the mailbox resides. However, it's possible for an Exchange administrator to change this value. If the value of MailboxRetention is set to 0, the mailbox will be instantly deleted. (Oops.) (Deleted Mailbox Retention on technet.com)
EDIT: Disconnecting an uninitialized mailbox will also result in its immediate and unrecoverable deletion. An uninitialized mailbox is one that has never been accessed through OWA or Outlook. This can cause difficulty when writing scripts that disconnect + reconnect mailboxes because some mailboxes might not be reconnectable.
Reconnecting a Mailbox
Disabling and connecting mailboxes isn't quite instantaneous. That's fine when you only want to disable a mailbox, but if you plan to reconnect the mailbox again right away, you need to be aware of two things.
- The list of "Disconnected Mailboxes" is not populated until the mailbox database is cleaned. If you're in a panic because you can't find the mailbox you just disabled, then tell Exchange to start cleaning the databases and wait a few minutes.
- If you're writing a PowerShell script, you must wait for changes to propagate to Active Directory before executing any further operations. Depending on your environment and your luck, this ranges anywhere from a few seconds to a few minutes. (Protip: You can call
Get-User in a loop to determine whether the changes have fully propagated.)
Mailbox metadata
When a mailbox is disconnected, the quota information is discarded. If you want to preserve mailbox quotas, you need to record those values before issuing the command to disable a mailbox.
The same thing applies to the list of EmailAddresses, and the mailbox Alias.
Delegations and Permissions
Now things start to get unfriendly. For any given user, there are several possible linkages with either regular exchange mailboxes, or legacy-style public folders.
- Regular Mailbox
- Send-As rights
- Send on behalf
- ACLs on mailbox subfolders
- Full Access rights
- Public Folders
- Send-As rights
- Send on behalf
- Folder permissions
Mailbox -> Send-As
The Send-As right is represented by an ACL on an Active Directory user object, and the ACL is internally stored as a list of SID values. Therefore, this permission can be entirely managed outside of Exchange.
When a mailbox is disabled it has no effect on send-as rights. The ACL on the user object is unchanged, so no information is lost.
If the disconnected mailbox is reconnected to the same user, any users that previously were able to Send As that user will regain that ability.
If the disconnected mailbox is connected to a different user, no users will be able to Send As the new user. You need to reapply the desired "Send As" rights to the new user.
Mailbox -> Send on behalf
The Send on behalf right is closely connected to the idea of "delegations" as presented by the Outlook client. It is common to grant send on behalf to another user, especially when delegating management of a calendar. It's not clear how Exchange stores this internally, but I do know that Send on behalf rights connect mailbox objects, NOT users.
When a mailbox is disabled, all "send on behalf" connections are discarded. This affects not only the mailbox being disabled, but also if another mailbox had granted send on behalf to this mailbox, that link would be removed now.
Needless to say, if the mailbox is reconnected to any user, the "send on behalf" rights are not restored. That information is immediately lost forever when a mailbox is disabled. I refer to these links as "volatile". This volatility stems from the fact that send on behalf rights are the only privilege that isn't stored internally with SIDs.
Bonus Tip: Exchange will populate two attributes on the AD user object, publicDelegates and publicDelegatesBL that contain the distinguished name of delegate mailboxes and mailboxes that have provided delegate permissions, respectively.
Mailbox -> ACLs on subfolders
Permissions on mailbox folders are one of the most commonly used links between mailboxes. Folder permissions are important as the second half of Outlook "delegations", but they are often assigned manually and without the associated send behalf rights.
Although Exchange represents folder permissions with a typical ACL based on user SIDs, you cannot manipulate them like regular ACLs. Outlook only allows the selection of mail-enabled users and similarly the PowerShell Add-MailboxFolderPermission cmdlet will only let you add permissions for another user if they have an associated mailbox.
If a user delegate is granted folder permissions (eg. Reviewer, Editor) and the mailbox of that delegate is later disabled, the permissions will appear like "NT User:DOM\samname".
If the delegate's mailbox is reconnected to the same user, they are apparently able to take advantage of the permissions despite their now malformed appearance.
But if the delegate's mailbox is connected to a different user, that new user won't inherit the original delegation because they don't have a matching SID. Although it looks like folder permissions are granted to a mailbox, truly they are granted to an AD security principal.
Mailbox -> Full Access
Full access permissions can only be assigned by an Exchange Administrator. Much like Send-As permissions, they are granted to an AD user object and stored internally based on SIDs. But unlike Send-As permissions, it turns out that full access permissions are actually stored as part of the Exchange mailbox object.
If a mailbox is disconnected, the list of users with Full Access is preserved in the mailbox object.
If that disconnected mailbox is reconnected, regardless of which user it is connected to, any users that previously had Full Access will regain the ability to exercise Full Access rights on that mailbox.
Bonus Tip: There is an optional feature of Full Access permissions called AutoMapping. If Full Access is granted with AutoMapping enabled, Exchange will populate the msExchDelegateListBL attribute of the user receiving the FullAccess permission. This makes it easy to see what you have FullAccess to, but it's not always enabled so you can't rely on it for a complete answer.
Public Folder -> Send-As
The Send-As rights for public folders work much the same way as with regular mailboxes. "But public folders aren't associated with user objects!" you shout. Actually, Exchange does create secret objects in Active Directory for each public folder you make.
(You can use ADSI Edit to open the Default naming context for the root domain in the forest where your Exchange server is installed, then look for "CN=Microsoft Exchange System Objects". In this container you will find an object for each public folder, and each object has an ACL that includes Send-As permissions.)
Public Folder -> Send on behalf
The idea of having "send on behalf" for a public folder is a bit weird, since the concept of "delegations" from Outlook doesn't apply to public folders at all. But it's there, nonetheless.
The differentiating factor of send behalf permissions on public folders is that they will never populate the "publicDelegatesBL" attribute of a user object which has been granted send behalf rights.
At this point, it's unclear to me whether send behalf rights are also volatile on public folders. If somebody knows this, feel free to edit this answer! (TODO/FIXME)
Public folder -> Permissions
Permissions on public folders are unlike permissions on mailboxes. Because they are linked to a mailbox, they are volatile.
If a mailbox is disconnected, then that mailbox will lose any public folder permissions it had been granted. (TODO/FIXME or do they follow NT USER format?)
A "seamless migration"
If you have a person with AD user accounts in two separate domains, and you want to move the mailbox from the user in one domain to the user in another, you have an uphill battle.
Unfortunately, Exchange does not make it easy to trace how permissions and delegations have been applied. If you need to move a mailbox from one AD user to another user in the same forest, and you hope to preserve the permissions entirely, you need to discover and restore those permissions yourself.
This becomes a very expensive operation even on a medium-sized forest, so if you are frequently moving mailboxes then it is worthwhile to do one big enumeration over all the mailboxes to gather a list of all current linkages. Then when you want to assign a mailbox to a different AD user account, you know precisely which other mailboxes need to have permissions updated.
Conclusion
- These permissions are durable. They remain intact after a mailbox is disabled.
- Send-As
- Mailbox Folder ACLs
- Full Access
- Public Folder Send-As
- These permissions are volatile. They are lost when when a mailbox is disabled.
- Send on behalf
- Public Folder Send on behalf
- Public Folder permissions
- Disconnecting a mailbox has numerous side effects.
- Loss of Quota setting
- Loss of connected Email Addresses
- Be wary of delays due to AD propagation when writing scripts that Disable or Connect mailboxes.
