6

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.

HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
Mateusz Kapusta
  • 151
  • 1
  • 2
  • 14
  • 8
    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
  • 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 08:51
  • 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... –  Jan 20 '14 at 22:34
  • 1
    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

3 Answers3

11

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.

Edit:

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.

Evan Anderson
  • 141,881
  • 20
  • 196
  • 331
  • 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 08:53
  • 1
    @MateuszKapusta: The Active Directory Migration Tool (ADMT) (http://technet.microsoft.com/en-us/library/cc974332(v=ws.10).aspx) 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
6

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.

Community
  • 1
HopelessN00b
  • 53,795
  • 33
  • 135
  • 209
1

It sounds like most of your questions need to be directed at a business level rather than technical. Firstly, if the business intends to grow the second company and then separate when they are grown up, a separate domain could be useful in that scenario in order to help them split.

Unless you have hard security requirements never use a RODC they are just another administrative overhead and not worth the bother in almost all scenarios. Great in theory, painful in practice. At least lab and understand what you are getting into before you do it anyway.

If the companies intend to stay together it will depend how separated the IT administration will need to be. A domain admin is a commonly used, often overused but also often necessary for key staff in the IT organisation. A single domain means tht this powerful user group will allow full access within that domain to a great many admin consoles and cover both parts of the company. Changing those defaults where it is allowed can be even more messy than the extra admin effort of managing 2 child domains. So if you believe there will be a requirement to split administrative responsibility and this level of control (per company) is likely to become a hard requirement, then separate domains is the way. If that will never happen and 2 IT orgnisations can work in harmony (good communication and collaborative change control the key here), or only 1 IT org can handle/share the 2 companies then stick to one.

I am currently helping a company with around 12 separate domains, regional IT support and 60000+ users consolidate into a single domain again because they don't have the need to remain separate and it is a painful process. So the early decisions need to be the right ones and while you can't always plan for what the business might do in 10 or even 5 years time, ask questions at all levels now, document their responses and prepare well.

Chris Williams
  • 11
  • 1