Do I need child domains in AD?

I have a an organization having HQ(about 150 users) in one city and 16 branches (high schools, 300-400 users each) each in different city.

What I have to do is create a domain(s) in AD for corporate network.

I was suggested to do the following:

• create OU for each school, and delegate administrative control to local admin.
• create site for each school and control replications(for ex. replicate at night).
• have 1 working DC and 1 duplicate(backup) DC for redundancy in each location(school)

My question is

• Do I need to create a child domain for each location like city1.school.org, city2.school.org and so on? And what would be the benefit of it?

I was said that it would create more headache and it more depends on logical structure of organization rather than physical. Howerver, I would like to hear pros and cons of it and in what cases it is more suitable.

Solution 1:

No, almost certainly not. Unless you have political pressure in terms of one administrator effectively having access to everything, then stick to one domain. There are arguments with regard to the same DNS namespace being used, which might not suit a multi-branded multinational, but sounds like this isn't an issue for you. Again, this is all bollotics. In terms of scalability, AD now scales very well. Replication can be controlled quite nicely too. Things have moved on since Windows 2000 Server.

Flipping the question on its head, multiple domains increase operational overheads (from day-to-day user/group management, auditing, securing AD backups, proving recovery, Etc.), but also introduces the potential for configuration inconsistencies across domains.

Single domain... the way forward.

In terms of DC placement, don't get tooooo carried away with Microsoft's two-DCs per site model. Look at your WAN links, and more specifically, triangulation into sites. If you have redundant links, and the MTBF on those links is high, then don't over-engineer unnecessarily. I don't know how big / autonomous your schools are. However, if the latency on your links is high, then perhaps on-site DCs will be necessary. This whole argument comes down to the service level that your WAN gives you. You can always add additional DCs if required. Taking them away isn't quite as straightforward (experience vs theory).

Also, don't forget about Read Only Domain Controllers (RODCs), which work beautifully on server core. This might not be relevant for you, as it sounds like your schools are quite autonomous, but if you, for example, had a smaller school, which didn't / couldn't do its own user management, then an RODC would be fantastic.

In summary, get your bollotics nailed, then get a WAN survey sorted.

Solution 2:

Generally speaking, you should always try to have as flat a domain structure as possible, preferably a single domain. Partitioning into domains should have clear business drivers, as there are few technical reasons for "architecting" an Active Directory system this way. Multiple domains create complexity that can be daunting when issues occur. Domains have trusts that can break, and that wreaks havoc on just about everything.

Some of the decision criteria may be driven by politics. There may be entities that require control over a security boundary; one way to do that is to provide them with their own domain. One example would the US government, where it is not uncommon for a department to have its own forest, and the constituent agencies have their own domain. Aside from politics, the technical rationale for this is not always compelling. Before Windows 2008, some things such as password policies may have required their own domain. One technical driver may be that another domain wants to use an Active Directory functional domain level that is currently unavailable if they were consolidated in a single domain.

Some people are of the opinion that some types of business units are candidates for separate domains, such as wholly-owned subsidiaries where the strategy is to eventually spin it off into a separate company. Or if regulatory requirements specified a separation of concerns, such as if there were a business unit that were subject to strict regulatory or financial controls, or if a business unit were a not-for-profit foundation.