I’m often asked the question: Why does the Exchange 2003 ADC create accounts with a bizarre logon field? (For Example,
It’s usually hard to answer this question if the person asking it doesn’t have a certain level of ADC knowledge. So let’s discuss a couple of common pitfalls that can go wrong during the Exchange 2000 migration scenario, beginning with how the ADC is running through its very first replication cycle for an object. In the situation where an Exchange 5.5 mailbox is configured with a Primary Windows NT account (assoc-NT-account) residing in an NT4 domain, a properly-configured connection agreement directs the ADC service to perform object-creation. (By contrast, if the mailbox’s “Primary Windows NT Account” was configured with an AD account in the same forest as the ADC, it simply copies 5.5 mailbox information to the pre-existing AD object.) In the former case (object-creation), Exchange 2000’s ADC will create a disabled accounts (called placeholders) in Active Directory, each having the Exchange 5.5 object’s attributes as well as a samaccountname (also known as “Pre-Windows 2000 logon name”) based the Exchange 5.5 object’s alias name. This naming caused problems for a couple of reasons:
1. People often had the misunderstanding that ADC object-creation was an easy way to migrate Windows NT 4 accounts to Active Directory. With that misunderstanding, they would improperly enable these “placeholder” accounts that were generated by the ADC, not knowing that this will cause delegation problems, Public Folder permission problems, and other permissions problems that may prevent logons, mailbox moves, and OWA access in some scenarios. (For information regarding problems caused by enabling the placeholder accounts, see http://support.microsoft.com/?id=316047.) To illustrate this first problem, here is a state diagram beginning with pre-ADC replication:
5.5 Mailbox | ADC-generated account |
Primary Windows NT Account = NT4domain\UserA | Nonexistent |
When the 2000 ADC examines the above state, it uses matching rules to see if the numerical value of the NT4 domain account matches any objectSID or SIDHistory attribute in Active Directory. In this case, none is found in Active Directory, so the 2000 ADC will create a placeholder AD account with Exchange attributes. The new account will also be given a pre-Windows 2000 logon name matching the value of the 5.5 mailbox alias:
5.5 Mailbox | ADC-generated account |
Primary Windows NT Account = NT4domain\UserA Mailbox Alias = UserA | · Disabled · Samaccountname= ADdomain\UserA |
At this point in time, the admins are often tempted to enable the placeholder account since it “appears” that the ADC has performed some sort of account-migration functionality.
5.5 Mailbox | ADC-generated account |
Primary Windows NT Account = NT4domain\UserA Mailbox Alias = UserA | · Enabled (wrong) · Samaccountname= ADdomain\UserA |
Of course, this is the absolute wrong thing to do, as there will be repercussions as explained above.
2. Another migration problem is that ADC-generated objects conflict with the ability of Active Directory Migration Tool (
5.5 Mailbox | ADC-generated account |
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA | · Samaccountname= ADdomain\UserA · Disabled |
When it comes time for the domain admins to perform an account migration from the NT4 domain, ADMT (or similar 3rd party tool) is used to clone the NT4 account SID to a new Active Directory account’s SIDHistory. The user-account migration process will result in 2 security principals corresponding with the same user. The -1 suffix would be appended since there cannot be 2 accounts in a domain having the same pre-windows 2000 logon name:
5.5 Mailbox | ADC-generated account | ADMT-generated account |
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA | · Samaccountname= ADdomain\UserA · Disabled | · Samaccountname= ADdomain\UserA-1 · No Exchange attributes · SIDHistory=0105…4000 |
The Active Directory Cleanup wizard (ADClean) is used to consolidate/merge the ADC’d and ADMT’d accounts. It works by transferring all the Exchange attributes from the ADC-generated placeholder account to a target account, and then it deletes the placeholder account. Logically, ADClean is the next migration step. If it is run in against UserA and UserA-1, the following will be the result:
5.5 Mailbox | ADC-generated account | |
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA | · Nonexistent (deleted) | · Samaccountname= ADdomain\UserA-1 · SIDHistory=0105…4000 · Exchange attributes exist |
The next time the ADC replicates changes to the 5.5 server, the 5.5 mailbox will have Primary Windows NT account = ADDomain\UserA-1. Functionality-wise, there is not a problem. However, from a usability standpoint, we wouldn’t want to instruct all (possibly thousands) of the migrated users to add a “-1” to their logon process!
With the above lessons learned from Exchange 2000 migrations, you can deduce that randomizing samaccountnames resolve the 2 problem scenarios. So in Exchange 2003, the ADC behaves differently, as illustrated below:
5.5 Mailbox | ADC-generated account |
Primary Windows NT Account = NT4domain\UserA | Nonexistent |
The Exchange 2003 ADC replicates, and matching rules find no corresponding AD account, so ADC generates a placeholder account with a randomized logon name (for example “ADC_BDZQ OKNUIZDWPPHG”) where the characters following the underscore are always randomized. Since this random username is difficult to type when a user logs on, it detracts administrators from improperly enabling the placeholder accounts for user-logon purposes.
5.5 Mailbox | ADC-generated account |
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA | · Samaccountname= ADdomain\ADC_ABCDEFGHIJKLMNOP · Disabled |
ADMT is run. This time, ADMT doesn’t encounter conflicts in translating the 5.5 mailbox alias into a samaccountname for a new account:
5.5 Mailbox | ADC-generated account | ADMT-generated account |
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA | · Samaccountname= ADdomain\ADC_ABCDEFGHIJKLMNOP · Disabled | · Samaccountname= ADdomain\UserA · SIDHistory=0105…4000 · No Exchange attributes |
ADClean is run, and the Exchange attributes are transferred to the ADMT-generated account. ADClean also deletes the placeholder account, so the final merged account doesn’t have a “-1” suffix.
5.5 Mailbox | ADC-generated account | ADMT-generated account |
Primary Windows NT Account = NT4domain\UserA (0105…4000) Mailbox Alias = UserA | · Nonexistent (deleted) | · ; Samaccountname= ADdomain\UserA · SIDHistory=0105…4000 · Exchange attributes exist |
The last ADC replication cycle will update the 5.5 object’s assoc-NT account field using the AD account’s objectSID value, thereby fixing-up permissions in the 5.5 directory.
5.5 Mailbox | ADC-generated account | ADMT-generated account |
Primary Windows NT Account = ADDomain\UserA Mailbox Alias = UserA | · Nonexistent (deleted) | · Samaccountname= ADdomain\UserA · SIDHistory=0105…4000 · Exchange attributes exist |
With a much cleaner migration process (among many other things), you can see why our folks in the field are telling customers to skip the E2k migration, and instead migrate Exchange 5.5 directly to 2003!
There are still a couple intended instances where the Exchange 2003 ADC will not randomize th e Pre-Windows 2000 logon name:
- If the Exchange 5.5 mailbox has been designated as a resource mailbox (i.e. “NTDSNoMatch” value exists on custom attribute 10), samaccountname randomization will not occur.
- If the ADC matches the 5.5 mailbox with an existing Active Directory account, the pre-existing account will not have its logon name randomized.
In summary, here are the conditions where the 2003 ADC creates accounts with randomized samaccountname:
- The Exchange 5.5 mailbox’s Primary Windows NT Account is a local or global group.
- The Exchange 5.5 mailbox’s Primary Windows NT Account exists in an external NT4 domain.
- The Exchange 5.5 mailbox’s Primary Windows NT Account exists in a different forest from the ADC service.
- The Exchange 5.5 mailbox does not have NTDSNoMatch value, even though it is really a resource mailbox (i.e. its Primary Windows NT Account is already mail-enabled in Active Directory with some other legacyExchangeDN).