• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 354
  • Last Modified:

Moving a DC out of the Default Domain Controllers Container

We currently have only one site but I will be setting up a second site soon.  I am restructuring the AD organization and am contemplating creating a new DC container because I need some different setting on DC's in the new site.  

Besides being linked to the [default domain cotrollers GPO] is there anything "special" about the default domain controllers container?
0
jcneil4
Asked:
jcneil4
1 Solution
 
Jeff BeckhamEngineerCommented:
Setting up a new OU for your secondary domain controller shouldn't be necessary.  What type of settings/restrictions would you need to apply to your second DC and not your first?

If you really decided that you need to do something like this, it would be better to create a security group, add the second DC to the security group, create a GPO with the settings that you'd need, disable the GPO, apply the new GPO to the "Domain Controllers" OU, filter it based on group membership of the group you created and finally enable the GPO.

One last suggestion, is to remember to try and keep your AD design as simple as possible while still accomplishing your administrative and management goals.
0
 
jcneil4Author Commented:
Actually I think I have a better solution.  
The main setting I was concerned with is Windows update settings... Each site has a different WSUS server and I like desktops to automatically install on Friday mornings but servers to not automatically install.  

What I think I'll do is: link the time and method setting (download updates and prompt for install) GPO to the Default DC Container, link a auto install method setting GPO to the appropriate desktop OU's.  Then link GPO's with the appropriate Windows Update server to the sites.

Setting one will come from the OU level GPO and setting two will come from the site linked GPO.

This should work right?

0
 
Jeff BeckhamEngineerCommented:
That would work, but it's not generally recommended to apply GPOs to your site links, although it is technically feasible.  You can run into issues because the site-linked GPOs are stored in your forest root and it needs to be available in order for the GPOs to be applied.

Since you're working with WSUS, you can also manage what WSUS servers your client connect to from the WSUS management console via groups.  See:

http://technet2.microsoft.com/WindowsServer/en/Library/d643f37e-9958-401d-9b56-1bb332c690f31033.mspx
http://technet2.microsoft.com/WindowsServer/en/Library/ace052df-74e7-4d6a-b5d4-f7911bb06b401033.mspx
0
 
Netman66Commented:
Agree here.

What you want to do is create target groups and place the servers in their own group.

I think you may find that using your own WSUS for these servers is not practical.  I would never allow the servers to update themselves.  I set each server's local Group Policy to go to MS and download the updates and tell me when they're ready.  I then manually update them selecting the Custom radio button so I can see what updates are there.  This gives you the opportunity to deselect any update you definitely don't want.

Just my thoughts.

0
 
edhensleyCommented:
Another issue is say its a remote site where you want to give rights to a 2nd person to control the dc.  Thereby giving them rights to create shares and reboot the system.  As for WSUS, I'd say let the one server do all machines if it s small # of sites.
0

Featured Post

Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now