Active Directory Migration Considerations (Part 4)

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

• Active Directory Migration Considerations (Part 1)
• Active Directory Migration Considerations (Part 2)
• Active Directory Migration Considerations (Part 3)
• Active Directory Migration Considerations (Part 5)
• Active Directory Migration Considerations (Part 6)
• Active Directory Migration Considerations (Part 7)
• Active Directory Migration Considerations (Part 8)

Introduction

Having discussed in the first few articles of this series some of the general considerations involved in any kind of Active Directory restructuring project and also the limitations of using ADMT for performing forest or domain migrations or consolidations, we’re now going to move on to discussing some particular issues relating to using ADTM itself. These issues are all things you should be aware of during the planning stage of your migration or consolidation project, and along the way I’ll be including various tips and pointing out some gotchas associated with using ADMT for Active Directory migrations/consolidations.

Note that the topics that follow in this article and the next few articles are in no particular order. Hopefully some of the issues raised will be of help to you as you plan and implement your own Active Directory restructuring project.

Which first, consolidate or upgrade?

Let’s say your Active Directory infrastructure consists of two forests running Windows Server 2008 R2. Your goal is to modernize and simplify your infrastructure to make it more powerful and easier to manage. To achieve this goal you want to perform two tasks:

• Consolidate the two forests into a single forest.
• Upgrade your domain controllers to Windows Server 2012 R2.

The question you now face is this: Should you start by consolidating your two Windows Server 2008 R2 forests into a single Windows Server 2008 R2 forest and then upgrade that forest to Windows Server 2012 R2 Active Directory? Or should you do it the other way around i.e. start by upgrading both Windows Server 2008 R2 forests to Windows Server 2012 R2 Active Directory and then consolidate the upgraded forests into a single Windows Server 2012 R2 forest?

In other words, which should you do first: consolidate your forests or upgrade them to the newer versions of Active Directory?

Figure 1: Consolidate first then upgrade vs. upgrade first then consolidate.

The answer is pretty easy to deduce from the number of steps in each part of the above diagram. In other words, you should begin by consolidating one forest into the other forest, then upgrade your surviving forest to the new version of Active Directory. It doesn’t make sense to upgrade the forest because it’s unnecessary extra work to do so.

SID history and ADMT

When you create a new user account in Active Directory, the security identifier (SID) for the account is stored in the objectSID attribute of the object representing the account in Active Directory. A 128-bit globally unique identifier (GUID) is also assigned to the object and this GUID is stored in the objectGUID attribute of the object. Internally, Active Directory uses GUIDs instead of SIDs for identifying objects. That’s because GUIDs never change but SIDs may change. For example, when a user account is moved from one domain to another, the SID changes. Active Directory records how the SID changes for an account in what’s known as the SID history for the account, which is stored in the sidHistory attribute of the object. If you want to read more background information on how all this came into being, see this link.

When you move user accounts in an Active Directory migration or consolidation, you can either use the SID history or not use it for performing the migration. For information about migrating accounts while using SID history, see this link. And for information about migrating accounts without using SID history, see this link.

Sometimes during a migration you may need to export or import sidHistory attributes or even add or remove them to/from account objects. While you can perform such actions using ADMT, it can be messy to try and do so. Fortunately it turns out you can also use Windows PowerShell to do this kind of stuff, and the reigning expert on this subject is Ashley McGlone, a Premier Field Engineer (PFE) at Microsoft specializing in Active Directory and Windows PowerShell. Ashley has developed a Windows PowerShell module called the SIDHistory Module which gives you visibility into the status of your SID history throughout your Active Directory forest, helps you translate SID history into NTFS ACLs, and easily target SID history removal. The SIDHistory PowerShell module can be downloaded from the TechNet Gallery and you can find all of Ashley’s blog posts on the topic of SID history at here.

Migrating local user accounts

Here’s an interesting scenario that one consultant told me he had encountered. The customer had a mission critical server running Windows Server 2003 and wanted to migrate all of the local user accounts from this server to a new server running Windows Server 2012 R2. The interesting thing is that the old server was a standalone server in a workgroup i.e. it wasn’t joined to an Active Directory domain. The customer did have an Active Directory infrastructure, it’s just that this particular server wasn’t joined to it.

This posed some interesting problems, so the consultant searched TechNet for some answers and came up with the following article in the TechNet Wiki:

Migrate Local Users & Groups from Windows Server 2003 to 2008 R2 with Windows Server Migration Tools

The Server Migration Tools described in the above article are five Windows PowerShell cmdlets that were first introduced in Windows Server 2008 R2 to simplify the job of migrating server roles and features from earlier Windows Server versions to Windows Server 2008 R2. You can find more information about these tools here. There’s also a 600+ page ebook available as a free download in PDF format that explains how to migrate server roles and features to Windows Server 2012 or Windows Server 2012 R2 available from the TechNet Wiki.

Anyways, the consultant was eventually able to perform the migration that the customer requested but did so only after first attempting to convince the customer to follow a different approach that involves first creating a new Active Directory environment from the old server and then using ADMT to merge the newly created domain into the customer’s existing domain. Here are the steps that the consultant proposed the customer should follow:

1. Begin by running dcpromo on the standalone Windows Server 2003 server to create a new “temporary” Active Directory forest by promoting the server to the role of a domain controller in a new forest. If you’ve forgotten how to do this you can take a look at this article. The result of doing this is that the local account database on the standalone server will become the Active Directory database, so all the local user accounts on the server are now domain user accounts in the temporary domain.
2. Next you will create a trust relationship between the temporary domain and the customer’s production domain.
3. You will now use ADMT to migrate the domain user accounts from the temporary domain to the production domain. You need to use ADMT of course because the temporary and production domains belong to different forests. Follow the instructions in the Active Directory Migration Tool (ADMT) Guide for migrating the accounts between the two forests. Once again, you can download this guide from this link.
4. Once the user accounts have been migrated from the temporary domain to the new domain, be sure to migrate any business data from the old Windows Server 2003 server to the new Windows Server 2012 R2 server that you’ve deployed in the production domain.
5. Once all the user accounts and data have been migrated off of the old server, you can run dcpromo on it again to demote it from a domain controller to a standalone server again and then send it off to retirement.

Note that this process not only migrates the user accounts but also the passwords for these accounts, something that (as far as I know) the other approach (using the Server Migration Tools) doesn’t let you do. This latter approach makes a lot more sense, but unfortunately the customer chose to go instead with the former approach. The good news of course is that the consultant got paid regardless.

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

• Active Directory Migration Considerations (Part 1)
• Active Directory Migration Considerations (Part 2)
• Active Directory Migration Considerations (Part 3)
• Active Directory Migration Considerations (Part 5)
• Active Directory Migration Considerations (Part 6)
• Active Directory Migration Considerations (Part 7)
• Active Directory Migration Considerations (Part 8)