Hi All, If your company or customer(s) has/have or had a multiple domain AD forest, what are or were the reasons to consolidate, or not, into a single domain forest? The question above should be related to companies that really have large (and distributed) ADs If you can share thoughts/experiences, please do so Thanks Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto*: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx(: +31 (0)6 184.108.40.206
AD domains | To Consolidate or not?
- 309 Views
- Last Post 25 March 2016
Mine where mainly to streamline operational management, accelerate working together and broadcast the vision of a single company. One had 140 separated forests in the same number of countries and probably three/four/eight times the amount of admins.
Identity replication, consolidation and single user access to applications where a nightmare. Hence the need for a single identity store.
Other companies where "regular" mergers where they wanted to completely absorb the others. Or wanted to downsize the server footprint, reduce complexity and or did not have the need anymore for multiple domains in the single forest as ms added the fine
But also had few customers splitting up businesses and therefore were separating or wished to separate operational management all together. In fact that happens nowadays more than you think.
However. The more businesses consume cloud apps the less need for integrating the AD's becomes. But so far. I haven't met one customer completely going into cloud that didn't exclude the domain consolidation.
_R Sent from my phone
On Mar 24, 2016, at 17:03, Jorge de Almeida Pinto <jorgedealmeidapinto@xxxxxxxxxxxxxxxx> wrote:
Hi All, If your company or customer(s) has/have or had a multiple domain AD forest, what are or were the reasons to consolidate, or not, into a single domain forest? The question above should be related to companies that really have large (and distributed) ADs If you can share thoughts/experiences, please do so Thanks Met vriendelijke groeten / Kind regards, Jorge de Almeida Pinto *: JorgeDeAlmeidaPinto@xxxxxxxxxxxxxxxx (: +31 (0)6 220.127.116.11 <image001.gif>
We have 24 domains in one forest and looking for good reasons to consolidate. What input do you have so far ?
Pro consolidation: usually because of mergers and to make operations and management easier. Lower cost of operations, introduce shared services.
Against consolidation: cost attached to the project of migration of workstations and users and mostly cost attached to handle all applications and changes to those, usually there is lots of dependencies which makes it very hard
This said - I want through consolidation process with large Bank in Poland but that was intra forest, colapsing 17 domains into one. That was long project with long tail of applications to be handled at the end. I know at least two large customers here from
Bank and Insurances who are keeping what they have, beacause of the reasons presented above (mostly cost associated with change and applications)
Tomasz Onyszko | Predica
Blog (Company): http://blog.predica.pl
Blog (EN): http://blogs.dirteam.com/blogs/tomek/
Blog (PL): http://www.w2k.pl
8 forests, 19 domains – no intention to actively consolidate them because the cost/benefit just isn’t there. Impacts to the business and cost/complexity of migrating users/resources just isn’t worth the effort. However, we have started
a process for some of the very small environments, where we are no longer putting users or resources into those forests. Over time, through attrition, we expect the number of migrations to become low enough that we can migrate without significant effort or
impact, but even then it’s more about simplifying the operational environment than anything else.
echo all sentiments above. complexity and the cost of management across multiple forests/domains, the heartache with config drift across so many different systems, etc... same kinds of primary drivers for me to consolidate.
what are you working on jorge?
MS02-001. While Microsoft calls the risk assessment severity ‘Moderate’, I think the impact on AD design is High. The security boundary is the forest, which means all domains in a forest should be managed
to an agreed minimum standard. For some situations, that doesn’t mean much, but for some situations, it is very significant. Put differently, a common reason to have multiple domains in a forest is so you can have differentiated management (different practices,
different admins, different user population, etc) and this security bulletin shoots a hole in that reason.
Pain of coordination. There’s a cost to coordinating DC changes across multiple sets of domain admins (and if customer impactful, each of their sets of user populations) vs. coordinating with a single
set of domain admins (and a single user population). Each DC/GC demotion/promotion across all domains in the forest is a change event that multiple groups need to be aware of because it impacts replication and possibly other functionality. In my experience,
I had domain admins with very different practices who would do crazy things which everyone else in the forest would have to suffer from, and would then require someone knowledgeable to help bail them out from. Some of these types of events: flattening a DC
and rebuilding it with the same name but not demoting it, domain compromise, putting up non-AD friendly firewalls, multiple organizations trying to run single instance per forest applications (e.g. Exchange). So single domain = single set of people accountable
with clear authority = less severe headaches. J
I’d note that I don’t think you can restrict yourself to your stated scenario to only include multi-forest. Here’s why: eventually one of the domains in the shared forest realizes #1 and/or #2 above imply a greater
cost/risk than they are willing to accept. So they move their domain out of the shared forest (or they are smart enough to never deploy a domain in the shared forest). And then you are in a different scenario whose major downside is the complexity of trust
relationships. That cost (in my opinion) is smaller than the cost of the above two things, but it is also more than the cost of a single domain forest.
Finally, I’d note that we have a similar situation out in Azure AD. Our organization went through lots of pain and costs associated with AD domain design (and still are). We don’t want to make those mistakes
again with Azure AD. There is very little out there in terms of recommendations or wisdom on Azure AD design at this level. I know we’ve hashed out some rationale and published some guidance, but frankly, I’m surprised more folks aren’t talking about this
because it’s better to figure this out early in a technology’s life cycle than late.
I am involved in four AD migrations where the customer no longer or has never owned their root domain name. One has to move for legal reasons, one has to move for government mandate and the other two want to
move before they are legally required to move (probably on a forced abbreviated schedule).
I am using these as the basis for my session talk at various conferences this year: (re)Building Your Active Directory.
One of these is using this as an opportunity to start over. They will build a new Forest and will not migrate anything from the old Forest.
Another is such a large org it will take a year or two just for them to do their discovery of all the crap, I mean apps, in their enterprise. I expect this to be a multiple year project and have already informed
them I will be bringing in, at a minimum, BD and MBS into the project. Well, unless they get sued by the owner of their root domain name first.
Going to be some “fun” AD projects.