Active Directory

Posted on 2013-06-27
Last Modified: 2013-07-09
I am looking for best practice setup of our environment.
This is what we presently have now, and it is very confusing:
I am just helping someone who has this situation. three data centers, each data center has four forest with single domain, one for public, one for data, one for emails, and one for something else. Some of them have trust relationships.

location 1:

location 2:

location 3:

As you can see there are 12 domains.

We want to redesign this, and what would be best practice, create one forest say:

root domain: then create child domains,

My concern here is the FSMO's.     Since Schema & Domain naming is per forest, what happens if I loose the DC.

WHat is the best practice for redesigning.
Question by:techgenious
LVL 57

Expert Comment

by:Mike Kline
ID: 39281770
Have you also thought about just going with one domain  You can create zones for public/email/data.

Even if you go with three domains if you lose the FSMO that holds the forest wide roles you would either repair the server or seize the FSMO roles (no different than in a single domain).   The schema master and domain naming master are fairly quiet and don't have a lot to do.



Assisted Solution

by:Matthew England
Matthew England earned 125 total points
ID: 39282033
Consolidating down to a single forest would simplify things greatly. There's really no need to have seperate forests and domains at each datacenter. Delegation can be used to ensure admins at each datacenter have the proper privledges, and AD Sites can be defined to help control any replication traffic.

As for splitting up the domains, I agree with your approach to create a central root domain, then use child domains for each function, (ie Exchange, Something Else.) While it's actually not neccisary to have seperate forests or domains for different services like Exchange, Users, SharePoint etc., in some larger more complex or high security environments I have seen this setup work well.

From a "best-practices" perspective, Microsoft reccomends keeping it as simple as possible. Before you create any new forests or domains, always outline exactly why those are being created. For example, some GPO's are domain wide settings. Account policies being the major one. While you can use Fine Grained Policies to adjust this, if Account Policies for servers and Admins need to be different than those for typical users and PC's, that may be a good indicator of creating seperate domains. The Administrative management of both groups are quite different.

One of the good reasons things like Exchange are often found issolated, is because Exchange, Lync, Configuration Manager and various other Microsoft Server applications require Schema modifications be made, which are forest wide changes. While it's not required they be issolated, doing so allows the Exchange group to manage their systems, including schema updates, without worry of impacting other core groups.

The following article provides a lot of goood information pertaining to deciding when to break up domains and forests, and what to consider in doing so.

Author Comment

ID: 39282036
I understand that, but our concern is a single point of failure especially with the FSMO's.
Is there another way to configure this.

Expert Comment

by:Matthew England
ID: 39282049

FSMO Roles shouldn't be a factor in determining your design really, other than where to place them. Unforunatly they will always be a single point of failure, but if you're environment is being properly monitored and maintained, the impact of losing any one DC, should be quite minimal. As mentioned, they can be moved and recovered fairly easily when needed.
LVL 24

Accepted Solution

Sandeshdubey earned 125 total points
ID: 39284260
There's some info on FSMOs and what would happen if any specific FSMO is down for any length of time, permanently or termporarily.

Active Directory FSMO Roles Explained and What Happens When They Fail and Why you may not be able to keep a DC up once roles were seized.
Regarding the domain consolidation you have to do lot of work.You need to understand nuances of ADMT and its working before you actually taken on migration production env.Also, its much better if you can simulate in a lab environment for successful result. I have below link which might help you to understand this. Start from reading ADMT guide first.

ADMT Guide: Migrating and Restructuring Active Directory Domains


ADMT Series

Note:ADMT doesn’t have an Exchange/mailbox migration option.

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
DNS Replication 12 71
DSRM password 5 42
Find users who are in no AD group with Powershell 5 18
SSSD - Automatic kerberos ticket initialization 1 18
This script can help you clean up your user profile database by comparing profiles to Active Directory users in a particular OU, and removing the profiles that don't match.
In-place Upgrading Dirsync to Azure AD Connect
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …
Attackers love to prey on accounts that have privileges. Reducing privileged accounts and protecting privileged accounts therefore is paramount. Users, groups, and service accounts need to be protected to help protect the entire Active Directory …

733 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question