Wednesday, July 9, 2008

ADMT UPN Issue when Merging Objects (zero appended)

Have you run into a strange issue in ADMT where you see a random zero ("0") or one ("1") appended to a UPN after using ADMT to migrate and merge a source object with a target object?

This happens in ADMT where target accounts, after merged with a source account, are randomly getting a zero appended to their UPN. If you fix the UPNs (using ADSIEdit, ADExplorer, or ADModify) and re-migrate the same batch of users, it will happen again, but to a different, random set of users. A workaround is using ADModify to query for (userprincipalname=*0@domain.com) …then reset their upns to samaccountname@domain.com. It’s a pain to run ADModify after every batch of users however, not to mention keeping track of any accounts to exclude (i.e., Student10@domain.com might accidentally get changed to Student1@domain.com).

This question was raised to the ADMT PM for Microsoft, and his comments were
:

It happens when:


  • there is an existing account in the Target domain with same UPN
  • an include file is used to specify SourceName and TargetName values and these values are different

To fix it the best practice is to specify SourceName, TargetRDN, TargetSAM and TargetUPN in Include file.

We will be updating existing documentation to cover this better shortly for ADMT v3.1.




1 comment:

Unknown said...

Very nice interested blog very nice blog full information. Please Visit:

SCCM Peer to Peer
legacy applications
windows migration