The msExchPreviousAccountSid is used to identify when there was a problem with connection agreements being rolled out before the 5.5 directory is properly prepared. It is the SID the ADC wanted to use as the msExchMasterAccountSid but couldn't because that SID was assigned to another mailbox.
Clear as mud? Maybe an example would help. To get a mailbox with a msExchPreviousAccountSID, first create two normal mailboxes in Exchange 5.5. Make sure the same user (Say TestDomain\TestUser) is the associated NT Account for both mailboxes. Don't put anything special on the 5.5 mailboxes. In particular don't put "NTDSNoMatch" in the Extension Attribute 10. Now, create a connection agreement between your 5.5 Directory and TestDomain. Replicate the objects, and voila! The ADC will replicate on object to TestDomain\TestUser. It will create a second disabled user object with an msExchPreviousAccountSid set to TestDomain\TestUser
I bet you still have many questions-- “What's wrong with the above example? It looks perfectly normal.” “What is NTDSNOMatch?” “What is the msExchMasterAccountSid and why can't it be assigned to two separate mailboxes?” “What is the correct way to migrate mailboxes?” “Couldn't you have made the whole process easier?”
Let’s begin with “What's wrong with the above example? It looks perfectly normal.” Unfortunately, the example is very common. Why is it wrong? Because of the big security model change between 5.5 and E2K-- in E2K we unified the mail directory with the authentication directory. Out went the Exchange 5.5 directory with its own list of mailboxes and permissions. In came the Active Directory. Instead of managing two objects, the 5.5 mailbox object and the Windows user account, you only need to manage one—the user object in the AD. One way customers using E2K could lower their TCO was to eliminate the need to manage two sets of directory servers and objects.
Unfortunately there are complexities with that model. In an ideal world, there is only one object. The user authenticates with a particular user object. That user object also contains their mailbox directory data. The real world is more complex. Not all users authenticate with the Active Directory. Some users will want to have two mailboxes. Suddenly, you don’t have that nice one-to-one relationship between mailboxes and user objects.
So we needed a way to tell Exchange that an external user owned a mailbox and that permissions granted to the mailbox should really be granted to the external user. That’s how the msExchMasterAccountSid, or Associated External Account, was born. You can see the Associated External Account if you pull up the Mailbox Rights on an Exchange Mailbox with the Users and Computers snap-in.
When a mailbox is on a disabled user object, the msExchMasterAccountSid tells Exchange who the mailbox really is. The msExchMasterAccountSid can point to a user account in another NT 4.0 domain or Active Directory domain. It can also be set to “SELF” which means that this mailbox is a resource mailbox—a mailbox that no one will ever authenticate as.
This wouldn’t be bad, except that much of Exchange 2000 assumes that user-account to mailbox is a one-to-one mapping. If you search for a mailbox with the user’s SID, only one mailbox will be returned. This means the msExchMasterAccountSid must also be unique; otherwise a search could return two mailboxes.
Exchange 5.5 did not have this restriction. That means there must be cleanup before migrating from 5.5 to 2000+. Before you replicate your first 5.5 mailbox to the AD, you need to identify all mailboxes that are associated with the same user account, pick one of these mailboxes to be the primary mailbox and mark the rest with NTDSNoMatch. NTDSNoMatch tells the ADC that the mailbox should be replicated as a resource mailbox, not a user mailbox.
And if you don’t do the cleanup? Then the ADC notices that the mailbox would create a duplicate msExchMasterAccountSid. Rather than replicating the object with potentially incorrect permissions, the ADC creates the mailbox in a locked state and sets it with the msExchPreviousAccountSid. Sometime later an administrator can track down the mailbox and correct the problem. This also tells me, when troubleshooting problems, that the ADC didn’t goof when it replicated the mailbox.
This sounds like a lot of work and it is, although we have made the process easier with the Exchange 2003 Deployment tools http://www.microsoft.com/downloads/details.aspx?FamilyId=271E51FD-FE7D-42AD-B621-45F974ED34C0&displaylang=en These tools work fine with Exchange 2000. One of these tools, the Resource Mailbox Wizard, will walk you through the cleanup. It spots 5.5 mailboxes assigned to the same user account, helps you pick the mailboxes that should be resource mailboxes and imports the needed updates.