More on multiple forests

I've received a few interesting email messages about my last post on multiple forests (https://blogs.technet.com/wincat/archive/2006/05/23/429988.aspx).

Here's a good excerpt from one of them, verbatim:

“More forests equals more administrative tasks”.  

I’d say that it necessarily must also be more complex administrative tasks. It may not seem that way to folks that have been working with multiple forests or are very experienced, but the bottom line is that having another forest to work with means you must either:

a) You need to handle an arbitrary number of forests in code. This code is thus longer and more complex than one that works against a single forest and AD namespace. It may not be much more complex or longer, but it must be to some degree. So now your administrative burden is increased (more code to write, more code to test and vet).

b) Have your scripts run only with one forest in mind and depend on the administrator to be able to keep track of the different forests and make changes as appropriate. Holy bejesus. Can you say operator error?

Which leads us to this:

“If you use scripting, the impact in a multi-forest environment is similar to the impact in single forest because the automated tasks will span all forests.”

But from above, if you use scripts to span multiple forests, I don’t think you can be at the same level of risk. Either your scripts are more complex or your administrators must be. Thus, best case scenario is a higher risk than a single forest.

I also got a few "multiple forests work just fine for us, thank you very much" messages. I want to dig into that a bit more. I'm looking at the risk of multiple forests, not the overall suitability of them. Isolation from service administrators is still the right reason to move towards multiple forests. The risk issues I'm talking about should be used to decide if the isolation requirement is a true requirement or actually more of a preference. Let's look at some cases where multiple forests are effective at reducing risk.

In my prior post, I described one of the scenarios where multiple forests work well - when every business function is covered by at least two forests. The downside is often an environment with significant cross-forest access and added complexity. Let me describe a good exception to this (albeit rare and expensive). I was reviewing a customer AD design with one of our infrastructure architects this week. The customer built two completely independent forests to support a mission-critical application. Half of the app servers are joined to one forest and half to the other. Redundancy is provided at the application level so everything keeps working seamlessly if half of the environment fails. With proper change management controls in place, this helps reduce overall risk. Scripting is still important to ensure adminstrators don't make accidents while making changes, but the impact of an error is limited because the app can run fine if one of the two forests disappears. The only missing piece here is forest recovery. A good forest recovery plan acts as a stop-loss measure, ensuring that the impact of a forest failure is capped at a known quantity. There's a lot to say about forest recovery so I'll save it for another post.

Other multi-forest scenarios that makes sense from a risk perspective? Political reasons always rise to the top of my list. In some cases, a business unit may have no control over the quality of forest admins. Probability of failure is all about administrator error, so a business unit with strong admins might be better off with their own forest instead of relying on weaker admins from another part of the organization. In a perfect world, the strongest admins would run a big forest for the whole company. In reality, the strong admins set up a separate forest for their business unit. Not ideal, but sometimes realistic... especially if the business unit is more important that the others.