5 tips for a cheaper, leaner Active Directory environment

Chances are that your Active Directory implementation is a good decade old, done with a long-ago version of Active Directory with limitations that typically resulted in creating more domains than you would with today’s version. Back then, you had to construct a forest, while today would need only a few — or even just one — “tree.”

It makes sense to revisit your existing Active Directory structure and decide, “Hey, I really need to consolidate domains to save time, money, and precious IT staff hours for management and support.” Though doing so probably means a serious migration effort of users, groups, computers, profiles, and more, the effort is worthwhile, and I’ve developed five tips to help ease the effort.

[ Get more tips and insights on managing Active Directory and Microsoft Exchange from InfoWorld. | Keep current on Windows news and developments with InfoWorld’s Technology: Windows newsletter. ]

Recently, a very large organization (more than 50,000 users) asked me about the possibility of making such a move. The first question: Is this going to be an intraforest or an interforest move? The difference is significant because intra means within an existing forest, where you might be consolidating domains. Doing it interforest means establishing a brand-new forest, then moving accounts and such from the old one to the new one. An interforest migration is much more complex, but overall, it results in a cleaner final product because you are starting from scratch. Thus, I advised the client to do an interforest migration.

Then the question was how. My first response: Go with Quest migration tools. Often, when considering a migration (be it for Active Directory or Exchange), my first thought was Quest, especially for large and complex environments. Sure, with a small environment, you might try the free tools, but beyond a certain number of users or domains, you should start looking at third-party products, and Quest happens to be my personal go-to app for migrations. Unfortunately, Quest’s tools are pricey (though worth the money, in my opinion), and this client’s budget for third-party tools was zero dollars.

So I pulled in another Active Directory expert, Greg Shields, an MVP and co-founder of ConcentratedTech.com, for his opinion. His first words were “Go with Quest!” When I informed him of the nonexistent tools budget and, thus, my hope of being able to use Microsoft’s free Active Directory Migration Tool, I was met with a groan.

Let me give you some history on the Active Directory Migration Tool (ADMT): It has been less than reliable. I’ve never seen it work perfectly. But the latest version (3.1) looked promising, so I thought we might at least give it a try. It took a few days of testing and adjusting (and more testing), but it worked. I was able to take two separate forests and migrate user accounts (with SIDs and passwords), group accounts (with memberships retained), local profiles (my test, but it could have been roaming too), and computer accounts (systems rebooted and joined the domain with no issue). Users were able to login as if nothing had changed other than their domain name.

You must be asking yourself, “Did it really work right out of the box?” Absolutely not. At every step of the way, we encountered errors, and the documentation (a 232-page nightmare called “Active Directory Management Tool v3.1 Guide: Migrating and Restructuring Active Directory Domains”) was one of the most difficult documents I’ve ever encountered. About a dozen administrators in a room all day couldn’t make heads or tails of it. We had to plow through each step and kept flipping back and forth through the monolithic beast.

But it does work, and now that I’ve had to figure out how to make it work, let me share five key reminders and tricks to help you along the way. Don’t be afraid to email me with questions or war stories about the Active Directory Management Tool. I believe I’ve become an expert on it over the past week.

The five key tips:

1. Active Directory Management Tool v3.1 runs on Windows Server 2008 — but not R2. You can set it up on a member server for a domain running Windows Server 2008 R2 domain controllers, but don’t try installing it on an Windows Server R2 server. You’ll just be told that Active Directory Management Tool must be installed on a Windows Server 2008. Microsoft is working on a fix with v3.2.
2. You must create a trust relationship between the forests. A two-way trust works best, although a one-way trust is supported. If you’re going to keep SIDs through the migration, keep in mind that you should turn off SID Filtering on the trust. That’s easier said than done. The commands netdom trust <trusted domain> /domain:<trusting doamin> /quarantine:no and netdom trust <trusted domain> /domain:<trusting doamin> /enablesidhistory:yes need to be run by a person with the right permissions on both sides of the forest.
3. Getting the right permissions to perform all migration tasks isn’t easy. You should create a single ADMT Admin (call it what you like) with the highest level of permissions (domain and enterprise admins), and make sure that account is placed in the built-in Administrator’s group of the source and target domains. It may be a bit like overkill, but make sure that account has as much permission as possible to do everything. A cross-forest migration is riddled with failures due to permissions not matching up.
4. If you want passwords to match up for migrated users, you should download the Password Migration Tool (PMT) v3.1 on the source domain. This tool is not required to migrate users; the wizard lets you create new random passwords when you move the users. If you do use the Password Migration Tool to maintain passwords, note this undocumented requirement: You have to create a .pes file on the target domain, then import that .pes file on the target as well. It seems redundant, but it is a necessary step to getting the Password Migration Tool to work.
5. To move over the workstations, you need to ensure the ADMT Admin account (or whatever you called it) is given permissions on workstations as well. You may want to temporarily disable the firewall to ensure the agent can install and flip the workstation into the new domain.

The biggest key of all to getting this to work right — c’mon, you all know this — is practice, document, and test. PDT. Perform your tasks in a lab environment that mimics your real-world environment. Document every single failure, then fix and develop a step-by-step process that works for your organization specifically. Test every kind of move you require, not only in a lab but — this is critical — in your real environment.

You can set up the Active Directory Management Tool and — especially — perform tests of every move before you begin. One of the positive things about this tool is that you can run both forests in tandem until you are ready to make the final move; take all the time you need to test and test again before diving in and migrating.

Do I give the Active Directory Management Tool tool a thumbs-up? I do. It works, it’s free, and once you get past the nasty documentation and see it all come together, you’ll be pleased at the results and the savings.

I suggest that Microsoft’s Active Directory Management Tool team take a look at the newly released Exchange Deployment Assistant. It’s an awesome online tool that asks a few questions about what you are looking to do and provides just those steps, in order, that you should perform. It makes deployments so much easier. The Active Directory Management Tool could use that kind of assistant.

What’s your experience with migrations? Have you worked with third-party tools or are you an Active Directory Management Tool veteran? If so, share your war stories and victories in the comments section below.

By the way, both Greg Shields and myself will be speaking at Techmentor next week in sunny Orlando, Fla. If you haven’t had a chance to see me speak and desire warmer weather, my primary topics will relate to Exchange 2007/2010, virtualization, Windows 7 VDI, and SharePoint backup/recovery — all the fun stuff I talk about in my columns here on InfoWorld.com.

This article, “5 tips for a cheaper, leaner Active Directory environment,” was originally published at InfoWorld.com. Read more of J. Peter Bruzzese’s Enterprise Windows blog and follow the latest developments in Windows at InfoWorld.com.