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 4)
- 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
In the first article of this series we briefly examined the history of Active Directory restructuring, and then introduced the Active Directory Migration Tool (ADMT), a free set of tools from Microsoft you can use to perform forest or domain migration or consolidation. The second article then discussed the risks/costs vs. benefits of performing forest or domain migration or consolidation, and then looked at some steps you can take to mitigate the risks/costs so you can take full advantage of the many benefits.
The second article then concluded by discussing one of the key limitations both of ADMT in particular and of Active Directory migrations in general, namely the difficulties you typically encounter when migrating servers and the applications running on them. The reality with large migration projects is often that more than half of the time needed for your migration job will be consumed simply with the task of migrating server roles and back-end applications. In fact sometimes it’s even 80 or 90 percent of the job. That’s because most other migration tasks such as migrating user accounts only have a learning curve at the start. Once you’ve successfully migrated several batches of user accounts, the remaining half million or so are relatively easy and sometimes almost trivial. But trying to migrate a Microsoft Exchange or Microsoft SQL Server infrastructure can be a colossal headache, and such migrations cause much worse headaches than simpler user migration because if your SQL servers fail your whole business can be brought to a standstill while failed migration of a few dozen user accounts only results in having helpdesk get mad at you.
Before we describe some tips and gotchas you should be aware of when using ADMT for forest or domain migration or consolidation, let’s continue in this article with a discussion of some other limitations of using ADMT for such purposes.
Migration rollback
Active Directory migration isn’t for the faint of heart. Depending on how large and complex your Active Directory environment is and your own level of expertise (and self-confidence) as an IT pro in this area, you may or may not want to use ADMT to migrate or consolidate your Active Directory environment. If your lack the confidence in your expertise, you may want to engage outside help, for example from Microsoft Consulting Services (MCS), and we’ll talk about what’s available from them in this area in a later article in this series. On the other hand, even if you’re fairly confident in your own technical ability and feel you can handle things when something goes wrong, you still may want to opt out of using ADMT to perform your migration.
Why? Because the rollback functionality of ADMT is not quite up to par. Being able to roll back (safely undo) each stage of the migration process can greatly reduce the amount of stress you’re going to feel when you perform your Active Directory migration. As long as you can roll back a step, you don’t need to worry because if something goes wrong you can simply undo it by reversing the action that was performed in the step.
Unfortunately ADMT is somewhat limited in the area of safe rollback. Specifically, rollback of inter-forest migrations is (as far as I am aware) not possible with ADMT. Rollback of intra-forest migrations is possible however, but only if you’re careful and know what you’re doing. For example, when you use ADMT to move an Active Directory object like a user account from one domain to another, ADMT leaves behind a cross-domain proxy object for the account in the source domain. Do not delete these proxy objects if you want to be able to roll back the move! If you delete them, you won’t be able to restore the moved objects in the source domain. In other words, you won’t be able to roll back the move.
Given these limitations and especially the lack of safe rollback for inter-forest migrations, if you do need to perform an inter-forest migration you might want to consider looking beyond the free ADMT tool and instead use one of the commercially available Active Directory restructuring offerings available from third-party vendors like Dell which acquired Quest’s offerings in this area two years ago. We’ll examine some of these third-party products and solutions towards the end of this series.
ADMT scalability
Another thing to consider if you’re going to use ADMT for domain or forest migration or consolidation is the scalability of the tool. Let’s say for example that you need to migrate 100,000 uses across a forest from one domain to another domain. Can you use ADTM to do this? Yes, but it’ll take some time. If you read the ADMT documentation you’ll see that it says you should use a batch approach for migrating large numbers of users to keep things manageable. Typically this means migrating a few hundred users at a time because that’s likely all that helpdesk can handle if something goes wrong with the migration.
Of course, if you’re migrating only a few hundred users at a time then it’s going to take you quite a while to migrate all 100,000 users for your organization. But this isn’t really the fault of ADMT, it’s more a limitation on how much volume of support your helpdesk can provide to frustrated users during the migration process. And once your migration picks up some steam and you’ve shaken out the bugs and the process is going smoothly, you can consider migrating batches of a thousand or more users to speed things up.
But can ADMT actually handle increased migration volume of this order? Yes, provided you’re using Microsoft SQL Server instead of Microsoft SQL Server Express as your migration database engine. The full version of SQL Server can scale way beyond what the Express version is capable of, so if you’re going to migrate hundreds of thousands of users then you should definitely choose SQL Server over SQL Server Express to take advantage of the extra scalability.
In addition, with the full version of SQL Server you can perform migrations from multiple consoles using the same ADMT database. But while this can provide some additional flexibility for how you perform your migration, you should note that ADMT doesn’t support parallel processing. So if you need to do a really quick migration of a large Active Directory database you’ll probably want to consider using something like Quest’s offering (which is now available from Dell).
The important thing not to forget however is that you’ll need to bring your helpdesk management team onboard with your Active Directory migration planning so you can ensure that solving an existing technical problem (getting the migration done) doesn’t inadvertently create new business problems (helpdesk unable to handle the volume of user complaints during the migration). Remember, frustrated users generally means work isn’t getting done, which means lost productivity, which can mean lost business. And the function of IT is to be a business enabler; IT doesn’t exist for its own right or purpose.
Other ADMT limitations
ADTM has some other limitations you need to be aware of. For example, ADMT can’t translate permissions for SQL Server or for shared folders on network attached storage (NAS) appliances. This means for example that if you have a large number of NAS appliances deployed as work storage for different departments, you might want to consider using a more powerful tool like the Dell (formerly Quest) migration tools instead of using the rather basic functionality provided by ADMT.
ADMT also isn’t really a product in the integrated sense of the term. It’s actually just a collection of tools (a toolkit) that has a very basic user interface. Most of the time you’re going to want to write scripts to leverage various ADMT functionality since doing things manually with the user interface will simply be too slow and cumbersome. This means you will need good expertise in writing scripts, and writing/testing/debugging scripts can take a lot of time which can slow down your migration quite a lot.
So basically if your migration project is fairly basic (few server applications, no NAS appliances, only a few thousand users, and lots of time to complete it) then ADMT is probably a good tool for you to use. It’s also a great tool if your budget is very limited, because buying a third-party migration product like the one from Dell or paying an outside consultancy like MCS to perform your migration can both be very expensive options.
Anyways, we’ll get back now to talking about ADMT in the next article in this series while we’ll postpone the discussion about third-party migration products and MCS migration offerings until we reach the final article in this series.
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 4)
- Active Directory Migration Considerations (Part 5)
- Active Directory Migration Considerations (Part 6)
- Active Directory Migration Considerations (Part 7)
- Active Directory Migration Considerations (Part 8)
