A common question and reality that I see rear its head, is “single AD or Child Domain?” and “Single AD or split Domain/Forest?” This is often one of the big challenges that an Admin will face when either initially designing AD architecture or rebuilding an existing configuration, what is commonly missed and not understood correctly, is the reality of how business rules and structure can govern the direction that needs to be taken with an AD design. The reality is, AD and Business governance tie in together strongly, more likely than not, the business rules will completely govern your AD architecture

So, what do you need to look at when designing an Active Directory Architecture and how do you answer the above questions?

The Below details are what i have found for myself, when looking at designing the outskirts of AD, this doesn't go into internal AD design at an OU level. Your business may have to answer different questions than what I have had to, but this might at least be a start for you

			How Is My Company Structured?

The logical and physical aspects of your company are your starting point when looking at how to structure your architecture. Do you have child or subsidiary companies underneath you, or are you in fact a child company of a holdings company above?

Take a company Such as the one I am currently employed by, And I will use this company as the example throughout the article. Let’s call it Ultimatum Holdings (UH). Ultimatum Holdings, as per its name, Is a holdings company with numerous chains, or sub companies underneath them. Let’s call them Custom Leather Manufacturers (CLM), Quality Mattress Importers (QMI), Budget Furniture Wholesalers (BFW) and Outdoor Furniture Specialists (OFS)

Each of these Sub Companies is a completely separate chain, with different brands and a different driving market area. However, they are all completely owned and operated by Ultimatum Holdings. So, when designing an AD, I had to look heavily at the aspects below to make a decision on architecture.

			What Does My Company Require From Active Directory?

The basis of any implementation of any system from small to large is of course, “What do I need from my investment”. What do I want and want to do I need, basically, what can the technology, in this case, Active Directory, Bring to the table.

When looking at an architectural point of view, the same basic principles apply. In the case of UH I can take a step back and say ok, what do I want my AD to look like? Do I need to segment my chains into child domains? Looking at the above company structure, most people would say straight off the bat that yes, being separate businesses, you should push an Autonomous Name Space for each domain. However, this is where the aspects below can completely change that mindset and pull a much simpler design for AD. For me, those autonomous name spaces really became a mute point when I looked at the next few points.

			What Direction Does My Company Intend To Take

Probably the most important question and the crux of what we are looking at here, is what direction will your company be taking in the future? Will they be selling any of the subsidiary companies, or will they be buying more in the future? Are there mergers to take into consideration in the future?

If the company can express any interest whatsoever in selling off one of the child companies, then you almost instantly have a decent reason to use a Child Domain. The beauty of a child domain in this instance is that a child domain can actually be ripped out and configured as its own standalone domain later down the track. Though saying that, this is not a great way of doing things and should only be completed with the expertise of a weathered AD Technician.

If it is certain that your company will be selling off a child company, you would be much smarter and better off to create a separate forest for that company. Once the company has been sold, you can break any trusts and simply hand over the forest to the new Administration team. A much cleaner approach to segmenting and breaking off your AD than ripping out a child domain, but also more aimed at the certainty of a sell off

If there is no intention of ever selling of the companies, then a Single AD is going to be a lot better option. Active Directory Architecture should always be as simple as possible. There is no point in using Child Domains or different forests when there is the ability of using a single AD. A single AD provides you

 • A single point of management,
 • A single manageable set of assets,
 • Higher redundancy in off site locations,
 • Less hardware requirements,
 • A single managed namespace,
 • Higher levels of control through technologies such as Delegation of Control in Active Directory,
 • A single point of reporting,
 • Less room for things to go wrong with your AD,
 • Simple DNS structures,
 • Overall simpler manageability.

In an ideal scenario, I would encourage you to push for a single AD where possible, the benefits are obvious and coming from working in both scenarios, AD works better with a simple design.

			What Hardware Do I Have And What Do I Need?

The fact of the matter is the more complex your design is, the more hardware you are going to need. Each Child Domain needs a minimum of one Domain Controller, Best practice and common sense would say that you should have at least two DC’s per child domain, and this is a basic assumption that you are using a single site for each child domain….

If I take a look at Ultimatum Holdings our example company, I would be looking at two DC’s minimum for my root domain (Must be two as the need to split the FSMO roles comes into play because of child domain usage). I would then have a need for two DC’s per Child domain. With 4 Sub Companies, that’s 8 DC’s initially, meaning that hypothetically saying we only have one site per child company I would need 10 DC’s for my initial infrastructure.

Now If I were able to have a single AD, I only have the requirement of putting a DC in locations that I feel need them, So in the UH example again, I could have two DC’s in my head office, then a single DC (still two Is better) in each site, so in this case, I could get away with 5 DC’s rather than 10. The other bonus here is that each DC holds a copy of my AD database, and I have instant redundancy held in 5 sites.

			How is My Network Setup From A WAN Point Of View?

Everything I have based my notes so far on has been under the assumption that there is network connectivity between sites. A single AD requires connectivity for replication and WAN logons, A child domain does not necessarily need to communicate with the parent constantly and can operate on its own quite happily most of the time.

If you do not have network connectivity between sites and never intend to have it, you would be better off with a separate forest for that standalone site. If you have connectivity, again, a single AD becomes a very appealing option once again

			Enough About Child Domains, What About A Seperate Forest?

So far I have focused on when to use a child domain and when to use a Single Active Directory Structure. But what about Forest Segmentation and where should it be used and why?

An important aspect that needs to be looked at is security and where does active directory fall into play? Am I going to be hosting public websites that require Active Directory logon accounts, Maybe I am making use of a DMZ. This is a huge point of confliction in the Directory Services community, The most commonly agreed on approach, is using a separate forest for publicly accessible services, and implementing a trust (if necessary) between your internal and external domains

Mergers – an Active Directory Administrators favourite job….You have your AD finished, it’s up and running , exchange is running nicely, everything is running single sign on capabilities, your life just got easy, and then you are informed that you have purchased an existing company with two and a half thousand employees and you need to integrate them into your network…..

Best case scenario is that they also have a nice competent admin who also has a nicely configured AD that runs nice and smoothly and you can simply spend an hour with the existing admin, and get some forest trusts up and running and wallah, company integration achieved (minus of course the leg work but hey, this is best case!)….more realistically though, you are going to inherit a shambles and you need to go back to the drawing board again….

How is the new company going to relate to your current company? Is it being swallowed up and made a part of your existing structure and staff base, or is it going to run as it was with no changes, but you simply own the company now? You have to have some serious chats with management about what path they want the company to take, as they will basically, indirectly dictate the path you will take with your AD forest design – do you migrate or do you append…,(Forest Trusts)

Another left wing concept…..development. How do your companies in house developers develop against active directory? Hopefully they aren’t developing against your live Active Directory….This is another good scenario for a separate forest – they can break it and it doesn’t touch your live system….Another better solution is of course ADAM, but this is out of this article scope…

			Conclusion?

As you can see, the business structure governs heavily what you will do with AD design…sure, the nitty gritty design of OU’s, Users, Groups and Policies fall solely under the administrators charge, but the actual architecture and design of the Outskirts of Active Directory, must be governed by not only technical preference, but by management and the future plans of where the company will go.