Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

My company is opening a new site in a different country. We will be installing new servers there and I have a question I can't decide on. Should we create a new domain in the forest or should we just use the same domain and implement a new domain controller, possibly and RODC?

The two companies are separated, but collaborate tightly. Also we manage IT for both of them, but I can't exclude they might have an IT of their own when they grow up. We access common network shares and might use resources located in both companies. Also, some of our users are often traveling from one company to the other.

The advantages I see in a new domain are mainly related to a tidier organization, better management in case of a dedicated department while still retaining the advantages of using GPOs from the forest. I'd set up a trust to let users access data in different domains.

The only disadvantages I see might be in having to add both usergroups in some cases and possibly some kind of problems with software based on AD if not properly set. I have no experience with this, so I'd like to hear your opinion about it and maybe help me figure out where the issues might arise.

share|improve this question
You write that "My company is opening a new site in a different country" but then you state that "The two companies are separated, but collaborate tightly." - Well which is it? The organization, logically and legally, as well as the prospects of its future could (or should) potentially be a deciding factor when planning and designing your Active Directory deployment – Mathias R. Jessen Jan 20 '14 at 20:15
I went through something similar for my organization. We bought out a competing company. But kept their brand name intact. In this case, I build a separate domain in the same forest. This was because we wanted to keep distinction between the brands. It looked pretty silly for a CompanyA employee to log in to CompanyB domain, which inherits CompanyB desktop policies... – user206214 Jan 20 '14 at 22:34
All of which could be handled in a single-domain environment with GPOs linked to OUs (or sites) and additional UPN suffixes. – Evan Anderson Jan 20 '14 at 23:05
the new site will need at least one writeable DC, and a 2nd DC that might as well be writeable too. – BeowulfNode42 Jan 20 '14 at 23:46
They are legally two separated companies, which are part of a holding. We, as a bigger company, provide some of the servicies which are in turn invoiced to the smaller one. It's no problem from this perspective. – Mateusz Kapusta Jan 21 '14 at 8:51
up vote 12 down vote accepted

Creating another domain adds complexity. To the extent that you are able to maintain a single domain environment you will limit complexity. I find that administrative activities are easier in a single domain environment.

Visual organization ("a tidier organization") could be accomplished with other features, like organizational units (OUs) in Active Directory. Personally, I wouldn't consider such "tidiness" reason enough to create a second domain.

Just about any delegation of control scenario that you can envision in a multi-domain environment can be handled in a single domain by delegating control at an OU.

From a logon efficiency perspective it makes sense to have Domain Controller (DC) computers at a location for whatever domains will be used in that location. If you are going to have users travelling between locations you will need more DCs (one for each domain, at minimum) if you have a multi-domain environment.

Cross-forest Group Policy Objects (GPOs) have, in my experience, been somewhat flaky. You will need a DC from the domain where a GPO is hosted well-connected to machines that apply GPOs from that domain. That may also cause to need more DCs in a multi-domain environment as compared to a single domain.

My opinion is that a multi-domain environment is only necessary when you require multiple domain-level password policies (and can't make use of fine-grained password policy within a single domain for some technical reason), or when the domain replication traffic would be so extreme as to warrant isolation to limit replication traffic.


If you really do need separation, legally or organizationally, then a separate Forest for the other company is really the only way to go. Separate domains in the same forest offer no practical separation, aside from partitioning the replication of the Directory.

share|improve this answer
How hard would it be then (if possible at all) to sort of "split" the OUs into two separate forests? Let's say our holding sells the second company to somebody else and we need to make two separate forests, is there ANY way to do it? – Mateusz Kapusta Jan 21 '14 at 8:53
@MateuszKapusta: The Active Directory Migration Tool (ADMT) ( will let you move accounts between AD Forests. That tool is typically what would be used in divestiture scenarios. – Evan Anderson Jan 21 '14 at 17:02

As your question is currently posed, it sounds to me like you could get as much mileage out of setting up a new Site in Active Directory as you would with a new domain. You'd create a new domain controller at the new physical location, but in the same domain and forest, and set it up to serve the new site in question (through the Active Directory Sites and Services management tool).

Of course, without a clarification on Mathias' comment, I'm not comfortable saying that with any certainty. If these really are two different companies, you should probably have a forest for each company, even if they collaborate tightly. Binding them into one AD forest could have undesirable legal or compliance implications that might outweigh the advantage of simple Active Directory management. And then there's the question of what happens when/if these two companies go their separate ways. Who "owns" the existing forest, how do you perform proper disengagement, who pays for that work, and who pays to set up a new forest for the company that now doesn't have one?

Federated services exist precisely to allow for interaction between companies' forests and cross-use of resources in those different forests, so that separate organizations don't need to share the same forest to work together. It a more complicated setup, and more to manage, but if there really are two companies in play here, it's the setup I'd recommend - two separate forests using federated services to connect to each other. Less hassle, mess and politics involved when each organization owns their own forest, and connect to each other using federated services, and no worries about what happens after the collaboration ends.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.