Active Directory Migration Considerations (Part 5)

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

Introduction

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. Then in the fourth article we began discussing 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 last few articles in this series will continue this discussion and will include various tips and gotchas associated with using ADMT for Active Directory migrations/consolidations.

Migration and schema modifications

Large enterprises sometimes modify their Active Directory schemas by extending it with the addition of custom attributes. This is done for various reasons, see this link for a general description of what’s involved. Also see this old article from TechNet Magazine which has a good introductory explanation of what happens to the schema when you extend it. One of the key pieces of information contained in the schema is the object identifier (OID), a string of numbers like 1.2.840.113556.1.5.9 that uniquely identifies a user classSchema object in Active Directory. Extending your Active Directory schema by adding custom attributes basically means you’re defining new portions of the OID namespace.

Let’s say that you want to migrate Active Directory objects from a source forest that has had its schema extended by the addition of custom attributes to a target forest. You start by extending the schema of the target forest with the same custom attributes. You then establish a trust between the two forests, set up ADMT in the target forest, and migrate Active Directory objects from the old forest to the new one. Does it work?

Unfortunately I was told by a colleague that the custom attributes won’t get migrated to the new forest. Everything else gets migrated properly, but not the custom attributes. This seems to be a limitation of how ADMT is designed, so if this is your scenario then you may need to use a third-party Active Directory migration tool for performing your migration successfully. I’ll talk about some of the third-party tools available in the final article of this series.

Migrating without trusts

When you use ADMT to migrate users or other Active Directory objects from one forest to another, you need to create a trust between the source and target forests. This typically isn’t an issue since most inter-forest migrations happen because one company acquires or merges with another company. But in some cases creating a trust might not be appropriate. For example let’s say your old CONTOSO forest is running Windows Server 2008 and you want to do the following to upgrade your forest:

  1. Create a new CONTOSO forest running Windows Server 2012.
  2. Create new user accounts in your new CONTOSO forest that are identical to the old user accounts in your old CONTOSO forest.
  3. Export the user profile data from the user accounts in the old forest to the corresponding user accounts in the new forest.
  4. Disjoin all the user PCs from the old forest and join them to the new forest.

Is this possible? Yes but it’s tedious and there are several ways you could approach it. For example, you could use the User State Migration Tool (USMT) to migrate the user profile data from the old user accounts to the new user accounts. You’ll have to ensure however that the access control lists (ACLs) on the user PCs are modified accordingly for the new user accounts. In this case you won’t be using ADMT at all, only USMT.

Or you could create a SID mapping file that maps the SID of the source domain to the SID of the target domain and populate your file with the old and new user account names and SIDs. The post titled “Creating a SID Mapping File with Windows PowerShell” on The Deployment Guys blog may be of help here. Also see again Ashley McGlone’s blog posts on SID history which I mentioned earlier in Part 4 of this series. In particular you should check out Ashley’s post which goes into detail about how you can use a SID mapping file to translate file system ACLs. It probably wouldn’t be hard to script the creation of such a SID mapping file, and once you’ve created it you could use it to translate the profile data and settings and their ACLs on the users’ PCs. One tip concerning re-ACLing the file system on the PCs: don’t use the Subinacl.exe utility, that was an unsupported tool from the Windows Server 2003 Resource Kit. Use Icacls.exe instead, which can replace SIDs by including the /substitute parameter.

There’s also a sample Windows PowerShell script in the Script Center Repository on Microsoft TechNet that could be of help in this situation. The script was created to help its creator resolve issues with broken SIDs resulting from a large migration project. While the goal of the script is to copy the ObjectSID of users in the source domain to a sidHistory value in the target domain, you could probably modify it to enable you to copy the SID from each old user account in your old domain to the corresponding new user account in your new domain.

One additional approach for PCs running Windows Vista or later is to utilize the new Windows Management Instrumentation (WMI) provider Win32_UserProfile. In olden days (circa Windows Server 2003) you could use a free utility called Moveuser.exe from the Windows Server 2003 Resource Kit to move user accounts, but this utility doesn’t work on Windows Vista, see this link. For more information about the Win32_UserProfile WMI provider, see this link which includes a sample script for how you can automate the process of migrating the user profile information without using either ADMT or USMT. There’s even an updated version of this script that works more like a command-line utility which you might want to check out. And you could probably use the ChangeOwner method of the Win32_UserProfile class to change the old SID to the new SID for each user profile you’re migrating, see this link. But it’s simplest if you can simply establish a trust between the two forests so you can use ADMT.

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