Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

What's the best approach of having multiple test environments next to production one?

We have multiple programming teams that build solutions that use Active Directory very often. We have tried different approaches, starting with their own domain controllers (in same subnet), or additional OU's in our production AD that the team gets control over and can create/delete accounts within that one OU.

We thought of possible 4 solutions:

  1. Setting up separate OU's in ou production env.
  2. Creating subdomains for our domain like, and delegating control to the teams (would we need additional DC's or the two that we have already would be enough to hold this?
  3. Setting up additional test domain controler that has a trust to our main domain and all teams can use the test domain controler as they please.
  4. Setting up single domain controller for every team/project.

We're taking in consideration amount of resources needed, security (for example having multiple domain controlers with multiple passwords may lead users to use simpler passwords) and overall best practices for this scenario.

Update: In 90% cases it will be authentication for SharePoint, BizTalk, CRM's etc. In other cases it can be SPN, kerberos authentification and tests with Certificate Authority.

share|improve this question
up vote 3 down vote accepted

It depends on what you're testing and what it needs to do in AD. My thoughts on your solutions:

  1. That's fine if you're just testing account creation/deletion, as you said in your question. As long as that's all or most of what your products are doing.
  2. Yes - every domain needs at least a single DC - two is better in case one fails. Even for a testing environment. This lets them dick around all they want.
  3. That's terrible idea. It doesn't matter what DC in your domain they connect to - AD is a multi-master database, so a change made in one place will be replicated everywhere. You haven't secured anything - if you let them add/delete accounts anywhere, they could accidentally delete all accounts or perform other fuckery on your production network. The first task after restoring your network will be a blizzard of pink slips, and probably for your sysadmins, not the dev team.
  4. In today's age of easy virtualization, you're probably best off to make at least one test domain (no trusts to/from the prod domain) for everyone, and depending on your corporate and network layout, make additional test domains for everyone to interact with as needed, or let each of your devs have a DC (or more) running in a VM on their own machine or at a second desktop in their cube. There's a lot of other architectural options there too; depending on your budget and needs.
share|improve this answer
Wouldn't the 2 have the same trusts that the 3rd point does? Can the trust be set only partially as Main domain can do things in everywhere (as in using authentification etc) and the subdomains can't do stuff on main domain ? – MadBoy Dec 28 '10 at 17:15
No - separate domains don't have to have the same administrators. You can definitely have different domains, with different admins, in the same forest. You can make the admins in the top-level production domain also have enterprise admin rights so they can still control the additional domains. But really, for testing purposes, it's probably best to have totally isolates domains. – mfinni Dec 28 '10 at 17:59

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.