During a recent sequence of mailbox moves for a customer, I noticed that mailboxes whose parent objects were disabled failed to move. This is not normal behaviour and I had to do some digging to find out why.

The reason for the mailbox move failure turned out to be a side-effect of the way in which my customer disabled user acocunts. Before we go into what the customer neglected to do, let's have a look at what happens when mailbox-enabled user accounts are disabled.

One of the attributes associated with a mailbox-enabled user is msExchUserAccountControl. For a normal, enabled user account the value is set to 0. When the account is disabled the value is set to 2. If nothing else is done at this stage the mailbox can't receive mail, be logged into or be moved. The reason is that the Exchange Information Store requires at least SELF to have have Associated External Account permissions on the mailbox. I say at least because it is entirely feasible for other accounts to have this permission on the mailbox. It might be a resource mailbox, or one that is associated with an account from another forest (or NT 4.0 domain during a migration), etc. Setting the Associated External Account permission for SELF automatically populates the msExchangeMasterAccountSID attribute value on the parent object.

If there is no msExchangeMasterAccountSID value set for a mailbox-enabled object, Exchange will log a 9548 warning event in the application event log.

In addition to Associated External Account, SELF must have Full Control permissions on the mailbox. In my experience this is permission is generally present and no additional step is required to set it.

Unfortunately, the Associated External Account mailbox permissions for SELF are not set automatically when a mailbox-enabled user is disabled. This means you have to build the step into the standard process for disabling a user. An administrator can perform this step manually using the Mailbox Rights option on the Exchange Advanced tab of the user properties in Active Directory Users and Computers. A better option for most companies is to script the process. The customer I was working with had neither of these steps built-into their procedure for disabling a user account and this is why the mailbox moves failed.

For an sample script see the http://www.msxfaq.de/tools/addself.htm. The page is in German, but the downloadable script is in English.

For organisations (like my customer) that have a number of existing user accounts in this state there are a various ways to solve the problem. Apart from the manual method and the scripting method, there are two good tools available. The first of these is the NoMas (No Master Account SID) tool, which is unfortunately only available from Microsoft Product Support Services (PSS). The tool and how to use it are well documented on Daniel Petri's web site (http://www.petri.co.il/nomas_tool.htm. The second option is to use ADModify.NET or its command line equivalent admodcmd. For further information see (http://blogs.technet.com/exchange/archive/2004/08/20/208045.aspx).

I used ADModify.NET for my customer and this worked perfectly.