Alternatives to Cloning Accounts

You might be tempted to use one of two workarounds to upgrade accounts to Active Directory (AD). However, these techniques don’t work for the Forestprep operation. The first technique is to create a new account in the destination domain with the same username/password pair. Having the same credentials usually let you access resources or system components in the source domain. However, this method doesn’t work for the ForestPrep operation because the bind operation to Exchange Server 5.5 doesn’t pass the credentials, but instead uses the SID of the logged account. When creating a new account in Windows 2000, you get a new SID for this object. Using this new SID to bind to an Exchange Server 5.5 server results in denied access to the Exchange Server 5.5 DS because the SID has no administrative rights on the Exchange organization level, and the Exchange 2000 installation will fail.

The second technique is to create a trust relationship between the old account domain and the Win2K domain. Then, you add the source service account as a member to the destination Schema Admins group and the Enterprise Admins group. Finally, you use this account to perform the ForestPrep operation. However, the default global scope of these security groups in Win2K doesn’t let them contain objects outside the domain. Therefore, the service account won’t have sufficient rights to perform the operation in the Win2K domain.