Active Directory Migrations - Why so hard?
20/01/13 01:27 Filed in: Windows
For some reason the processes and requirements for carrying out directory migrations are often underestimated. In here I talk about some of the issues you may encounter.
Over the years I’ve worked on numerous infrastructure projects that have often involved an element of Active Directory or domain migrations and consolidations. One thing that’s always struck me about these projects is that companies often massively underestimate what is involved, and the potential to impact on the user population in a negative way.
They seem to think that moving a user from one domain to another is a doddle, and can be done with the minimum of resources and in a compressed time-scale.
It absolutely cannot, and assuming that really will just lead to disaster.
There are a number of things you have to consider, including:
Access to Servers & Services
You’ll want to maintain access to your servers and services in the legacy domain until such time they’ve been moved across. For a lot of applications this can simply(!) be a matter of utilising SID History, whereas this won’t work with other applications (admittedly getting fewer by the year). Utilising SID history means turning off SID-filtering on your domain trusts too, so that could have security impacts.
When you migrate a user to a remote domain, and they logon to their machine - they’ll appear as a new user and they’ll get a new profile. Great, your user is now unhappy as they can’t find anything, their email doesn’t work, and they’ve lost any documents they had in their profile.
How do you mitigate against that? Well, some tools such as ADMT are able to not only migrate the computer object but also carry out security translation on these profiles so that when a user logs in they get the same profile they had previously. That’s the ideal really - lessen the impact on the user.
Migrating a user from one domain to another, using SID history to maintain service access is easy... but don’t forget you’ll have to do their machines too at the same time - if you don’t, you’re presented with the new user scenario, and an unhappy user.
This can lead to co-ordination issues, and information gathering - making a sure a user’s workstation is available for such work. Even harder for external people with laptops and the like too.
This is another area that often catches people out - name resolution. Trusts need to be established between the legacy and new environments, and the solutions need to be able to freely resolve IP addresses between the systems. Sounds simple, and yet I’ve seen so, so many people get this basic piece wrong which in turn just wrecks consistency on the migration project, and can utterly ruin an end-users day.
Group Policy/OU Structures Etc.
Choices need to be made on migrating Group Policy, or applying new ones. Both routes have planning considerations including impacts on the user environment, speed of execution etc. Not to mention how you actually migrate the Group Policy and OU structures.
I’ve previously written about how to transfer OU structures and the like - it’s not difficult, just takes some thought.
Application Server Migrations
Now this is an interesting one - domain integrated applications range in complexity and type. The more complex and integrated, the harder they are to move. In fact, for a lot of applications a move of infrastructure just isn’t tenable or supported - things like Exchange for example.
The nearer the app is to the top of the pyramid above, the easier the migration is.
Some organisations choose to leave legacy application servers in the old domain and migrate from them as and when they reach End-of-life...and I completely understand this approach as it often makes best use of available resources and budget.
What about Time-Scales?
I’ve also often seen project plans for migrations that try and compress time-lines by throwing resource at the issue. This doesn’t readily work for Active Directory type migrations as the constraints are not often technical ones. You can for example migrate a fair few hundred people at a time if you’ve got the right information on who they are, and access to their machines. No matter how right you get this however, you will hit some failures and therefore have an impact on support.
The constraints on time-line delivery are usually access to the people and the machines really, rather than having multiple techies running simultaneous migrations.
Doing domain consolidations and Active Directory migrations are not difficult - I’m sure I’ve made it sound technically more challenging than it is. What is difficult though is planning the overall delivery, co-ordinating it successfully, and minimising impact on the end service user. That can take time, testing, and relies on detailed understanding of what you want to achieve.
Spend the time on the planning, the rest of the project will follow. Get that wrong, and you’ll be in a world of pain and your users will be in for an age of frustration.
Also, don’t rely on the standard tools to be able to achieve everything. By standard tools I mean things like the ADMT tool mentioned earlier, or even Quest’s Active Directory Migration Tool. Having a tech around who’s proficient in scripting and automation via things like PowerShell or VB could potentially save you a lot of work by dealing in bulk with items that are specific to your environment - and let’s face it, every environment is different.
Incidently, Quest have a White Paper here on Best Practices for an Active Directory Migration - and it’s a pretty good one too.
Thinking about this planning by the way has brought back an early memory of being called out to a large-ish advertising agency who were in a world of hurt after trying to migrate their NT 4 domain to an Active Directory (around 2000 I think, from memory).
Their method? New user objects in the AD, remove PC from legacy domain, add PC to new domain. Sit back and enjoy the glory. Can you imagine how that turned out, right....?
If I could leave you with one message about such projects it would be this - Active Directory migrations are not that technically challenging; the challenge is in the planning, co-ordination and risk mitigation.