Let me introduce to everyone a great colleague of mine, Andrew Walls. Among other topics he covers, he is our resident Active Directory specialist. He has kindly consented to contribute to the blog– I know you will like it.
By Andrew Walls
Active Directory is everywhere. This is both a testimonial to the success of Microsoft’s product management strategy and a challenge for any enterprise that wants to build a unified AD environment. Consolidation of AD forests and domains is the single most frequent topic raised in inquiry concerning Active Directory. Commercial organizations, governments and educational organizations are all looking for a more efficient approach to managing AD and providing AD services to their internal clients. The complexity of some AD environments is staggering. Many commercial organizations are operating >10 Forests with multiple domains in each forest and a complex network of trust relationships. Quite a number of governments are operating >50 forests with who knows how many domains. To date, the most complex environment I have encountered is at a global organization with 138 forests operating on every major release of AD since Windows NT.
There are good reasons for this infestation of AD. When AD was first released, it was seen as an extension of Windows Workgroups and was implemented as a departmental, localized solution. As the years have gone by, AD has become an enterprise solution but many organizations are still managing it as a departmental solution. This legacy architecture keeps a lot of AD administrators employed and enables departments to act as a separate fiefdom within the overall enterprise. Although this local autonomy has some benefit, the complexity produced by multiple, unique AD implementations can prevent, or drastically increase the cost of, deployments of new, enterprise wide software and work processes.
The allure of a single AD forest with a simple domain design is not fool’s gold. There are real benefits to be found in a consolidated AD environment. A shared AD infrastructure enables user mobility, common user provisioning processes, consolidated reporting, unified management of machines, etc. The reasons for consolidation are clear, but there are significant barriers to success.
- Politics- Let’s face it, the big problem with AD consolidation is political. No one likes to give up local control of users and machines to a centralized bureaucracy. From a technical perspective, a consolidated AD model is clearly a more elegant approach to AD management. From the perspective of local versus centralized control, the best model is not so clear.
- Cost justification- It is very hard to write a business case for an AD consolidation project. Does consolidation reduce costs? Maybe, but probably not by much. You might be able to produce minor reductions in license costs but, consolidation rarely results in AD administrators being laid off. On the other hand, the actual consolidation project can cost a considerable amount. I have reviewed AD consolidation proposals from systems integrators that range in price from ~$200k to over $5million. The benefits derived from consolidation tend to be qualitative rather than quantitative. User portability, shared GAL (Global Address List) and consolidated reporting enhance productivity, but can you measure that enhancement in dollars?
- Complexity- An AD consolidation has to unite and rationalize the ID formats, password policy objects, user groups, group policy objects, schema designs and application integration methods that have grown and spread through all of the existing AD environments. At times, this can feel like spring cleaning at the Aegean stables. Of course, if you miss something, users will not be able to log in, or find their fileshares, or access applications. No pressure.
How do you avoid all of this? You fight proliferation of AD at every turn and realize that consolidation is not a onetime event. The optimal design for AD is a single domain within a single forest. Any deviation from this approach should be justified on the basis of operational requirements that a unified model cannot possibly support (I have yet to see such a requirement except for deployment of AD in an internet-facing DMZ). There is no avoiding the pain of consolidation when your existing environment is already fragmented, but once you build the core AD environment, you should not have to repeat that pain. Many clients that experience regular mergers and acquisitions have established defined processes with time lines for integrating new subsidiaries into the collective (Resistance is futile! Your AD will be absorbed within six months of merge date).
It is never too early to start on consolidation. The pain of consolidation increases the longer you wait to grapple with the situation. Take the bull by the horns and develop a strategy for consolidation now (full consolidation can take years to complete in very complex environments) and get started on implementation right away. While you are consolidating the existing AD environments do not allow any new domains or forests to be created!