Active Directory Migration Considerations (Part 6)

If you would like to read the other parts in this article series please go to:

Introduction

To recap: the first three articles in this series described some of the general considerations concerning Active Directory restructuring projects. The articles also described some of the limitations involved when using ADMT to perform forest or domain migrations or consolidations. The fourth and fifth articles discussed some specific issues relating to the use of the ADMT itself. These issues are things you need to be aware of during the planning stage of your migration/consolidation project. The present article concludes this discussion with more tips and gotchas when using ADMT for Active Directory migrations/consolidations.

Migrating user profiles

When you use ADMT to migrate user accounts from a source domain to a target domain, everything works fine except that the name of the user profile folder remains unchanged after the migration process. For example, let’s say you migrate the user account CONTOSO\worker05 in the CONTOSO domain to become the user account FABRIKAM\drone05 in the FABRIKAM domain. The result will be that the user profile folder of user FABRIKAM\drone05 will be C:\Users\worker05 and not C:\Users\drone05. Of course, everything will still work fine on the computer that user drone05 is using at Fabrikam Inc. He’ll be able to save his documents and open them in the usual way. But if he opens a command prompt it will display C:\Users\worker05 as a prompt, and this will likely prompt him to contact Helpdesk and say. “Hey, my username is drone05 not worker05 so there must be something wrong with my computer” and so on.

This problem happens regardless of the type of migration you perform, and it only happens with the user profile path. Everything else such as the user’s Security Identifier (SID) gets translated properly, but if you open Regedit and look under HKLM/SOFTWARE/Microsoft/Windows NT/Current Version/ ProfileList you’ll see that the ProfileImagePath value still displays the CONTOSO name of the user’s profile folder.

Of course, the best way to fix this issue is to educate your users that it’s a non-issue. But let’s say your CEO mandates that all traces of CONTOSO be eradicated from your systems because of some legal matter associated with the recent acquisition of Fabrikam Inc by Contoso Corp. Is this technically feasible?

It might be. There’s a Microsoft Knowledge Base article KB2454362 titled “Renaming a User Account Does Not Automatically Change the Profile Path” that describes a manual workaround for renaming the user profile path for a user. So you could perform these steps on each computer at the conclusion of your migration project, and you could probably script the process instead of doing it manually.

Does it really work however? And is it supported? Here’s where things are not clear. For example, this TechNet forum thread suggests that while the steps in the KB enable you to change the user profile folder, they don’t alter the value of the %USERNAME% environment variable. And a post on PhilSismondo’s blog “IT world and my experience working in it” suggests that changing the user profile name only scratches the surface of the matter as there may be additional instances of the old user profile path stored in the user’s registry hive. Phil’s solution to this was to use Windows PowerShell to create a symbolic link that points from the old profile folder path to the new path. That’s pretty ingenious, but once again the best way to resolve this issue is probably just to ignore it and tell your users to ignore it as well. However whether Phil’s solution is supportable from a Microsoft PSS perspective is uncertain, so you should use it at your own risk.

ADMT fails

What do you do when you try to use ADMT to perform a migration or consolidation and something goes wrong? Usually an error message is generated, an event is logged, or some other information will give you a clue to what happened. This section is a grab bag of miscellaneous fails I’ve either seen or heard about when using ADMT to migrate or consolidate an Active Directory infrastructure. Hopefully the information in this section may give you some clue that helps you troubleshoot your own problems with this tool.

Failed to add SID history

This error indicates that the RPC server was not available when ADMT was doing whatever it was supposed to be doing. Either the source domain or the destination domain might be unavailable, and such a condition is usually the result of one of the following happening:

  • A firewall port on a domain controller that should be open is closed instead.
  • There’s a stale IP address in a DNS record for a domain controller.
  • There’s a stale IP address in a WINS record for a domain controller.

Check the firewall on your domain controller using this tip on WindowsNetworking.com:

Be sure also to review the TCP/IP configuration of all domain controllers. Another good resource here is the following TechNet Wiki article:

Windows Server Troubleshooting: “The RPC server is unavailable”

Unable to retrieve the DNS hostname for the migrated computer

The details of this error being logged includes the name of the migrated computer and continues with “The ADSI property cannot be found in the property cache” but this can be misleading as I’ve been informed by a colleague in the field that the solution for him involved populating the value of the NullSessionPipes registry key as described in the TechNet forum thread even though the discussion in this thread involves a different error.

However there may be other things causing this problem such as issues with DNS name resolution or certain Windows services not running. A good discussion of these various other causes and possible resolution steps can be found in this TechNet forum thread.

The computer failed to update the dnsHostName and/or servicePrincipalName (SPN) attribute in its Active Directory computer account

This domain controller event may be logged during a migration when the source and target domains are running Windows Server 2012 R2 and your attempt to join a computer to the new domain without first dis-joining it from the old domain. The reason for the error is because starting with Windows Server 2012 R2 domain controllers now block the creation of duplicate service principal names (SPN) and user principal names (UPN) as described in this TechNet page. There doesn’t seem to be any way to disable the check for unique SPNs in the current version of ADMT, but you could try contacting Microsoft Support and see if they have a fix available if you get yourself in this situation.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top