Active Directory consolidation strategy after merger/acquisition

Upfront disclaimer: I'm a UNIX guy by design and trade. However, I've been involved with Windows boxes for at least a decade from an operational support/performance tuning perspective.

My company has recently acquired another company, and we're looking into strategies for consolidating Active Directory between the two. We have a site-to-site VPN connection and quick-n-dirty name resolution working between the two sites.

I would appreciate:

• Advice from anyone who's been in the same situation.
• Links to articles describing both high-level considerations and technical details.
• Gotchas, never-dos, I-wish-I-had-knowns, always-dos-but-never-documented.

Solution 1:

I'd plan on disusing one of the Active Directory forests and trashing it. Maintaining a multi-domain, let alone a multi-forest, Active Directory is just a pain.

If you don't have a large number of users / computers or complex filesystem permissions in the forest being disused I wouldn't even bother with a tool like the Active Directory Migration Tool.

Migration tools are fine for getting something done quickly, but if you have the time to setup a trust relationship between the forests and move deliberately you can give all the file permissions, applications, and any other services that rely on Active Directory a true top-to-bottom review and assimilate the acquired company into your Active Directory in a controlled and coordinated manner, instead of bringing over a lot of baggage from their AD that'll turn out to be a "legacy" millstone about your neck for years to come.

I'd setup a trust relationship between the forests such that users from one domain can logon to computers in the other. Then, the domain membership of the client computers becomes somewhat irrelevant. I'd deploy a number of domain controllers for the destination domain into the acquired company's office. You could even deploy these as VMs on the existing domain controllers, Windows licensing nonwithstanding.

I'd map out what Group Policy is being used for in the forest being disused, and stage sites and OUs in the destination forest to house the computers as you move them over. You'll probably find that they're not really using Group Policy for much of anything (seems, depressingly, to still be the case 9 years after Active Directory and Group Policy came onto the scene), but definitely give it some thought.

I'd deploy a startup script using the "NETDOM" tool (see http://technet.microsoft.com/en-us/library/cc781853(WS.10).aspx) to disjoin the client computers from the forest being disused and join them up to the destination forest. User logons will continue to work as they always have for the users of the forest being disused.

Whether or not to migrate the users and groups from the forest being disused would depend on the number of users and groups and the difficulty of just re-creating the users, groups, and filesystem ACLs in the destination forest.

You didn't mention Exchange. If Exchange is in play you have cross-forest / cross-organization mailbox migration to worry about. I'll refrain from comment on that issue unless you update and say you need information about it.

Solution 2:

You're looking at two different ways to do this: 1. Domain trust (simple): creates a link between your two domains, so that you can give users in domain a access to shared resources in domain B and vice versa. You can also create a one-way trust that only works in one direction 2. Domain migration: Move all objects (users, computers and so on) from one domain to the other. ADMT (Active Directory Migration Tool) is the toolbox you normally use here. If both of the domains have installed Exchange Server you're also looking at a mailbox migration from one Exchange Org to the other (there is a one-to-one relationship between Exchange and Active Directory Forests, so you can't simply move exhcange between AD forests).

As Sam points out, this is one where you'll want to test, test and test some more! The migration itself isn't that complicated, but any screwup could be potentionally disasterous.

Solution 3:

Evan Anderson is going to give you the really good answer on this one, but until he shows up, I can give you some stuff to research.

Basically, you've got an Active Directory "tree". It's your domain. Your new company has one, too. Their "tree" is their domain. What you want to do is put both "trees" in the same "forest". I'm not being cute, these are the actual terms.

I only know enough technically to know that I don't know the answer. Google provides some good looking results, but definitely talk to someone who knows before you do it. Is there anyone in the other company with more Windows experience?

Also, I'd recommend picking up an AD book for the version of Windows Server you use. They're enlightening, and as a Linux guy myself, seeing their mindset is a little unsettling at time, but it usually works. It's just different.

Good luck!

Solution 4:

Typically you end up using something like ADMT or Quest to migrate all the relevant objects (users, groups, computers, servers, etc) out of the domain(s) owned by one company and into the other's domain.

This requires some significant planning and you'll need to look at servers on an application by application basis. Some things are fairly easy to move e.g. file and print servers while others e.g. SQL/SharePoint are much more involved.

ADMT and similiar can do the work of touching all the machines for you as well as copying principals over.