Windows Server 2003/AD/Group Policy Help

dx2

Gawd
Joined
Jan 6, 2005
Messages
545
Anyone know of some good tutorials on setting up Active directory in a purely 2003/XP environment and implementing group policy objects?

dx2
 
I don't know of any tutorials, I just know how to do it. (I know that doesn't help, I am just trying to catch up with MajorDomo's POST count.) :D

On a more helpful not, if you have specific quesitons, we might be able to answer them.
 
Well here is the deal....we are creating a "child" domain on an open academic network. However our child domain needs much more restrictive policies than the typical university hospital computers.

The AD we are going to draw objects from is a good couple thousand objects, very loosely organized.

Any tips on implementing/going this child domain route? or better ways?
 
dx2 said:
Well here is the deal....we are creating a "child" domain on an open academic network. However our child domain needs much more restrictive policies than the typical university hospital computers.

The AD we are going to draw objects from is a good couple thousand objects, very loosely organized.

Any tips on implementing/going this child domain route? or better ways?
Child domains are a good way to segment out something that needs a different set of standards from the rest of the organization. I would suggest getting organized. Decide what your "ideal" structure is. Decide where you want to place user, computers, etc in the directory. Keep a consistant structure. Limit who can modify that structure. Here's one way that I have done this:
Code:
(root)
     >Users
     >Computers
     >(etc)
     >Departments
          >(Department 1)
               >Users
               >Computers
          >(Department 2)
               >Users
               >Computers
          >(etc)
This allows group policies to be inherited easily which reduces adaministrative effort to manage the policies.
 
We've started meeting to plan the directory structure. What concerns me is how many branches my manager wants it broken down into.

We have 25 sites, each with doctors, 3 kinds of nurses, and various other workers.

Is there any point that a directory structure can become to deep that it makes management a chore or impacts performance?
 
dx2 said:
Is there any point that a directory structure can become to deep that it makes management a chore or impacts performance?
Yes. Where that point is must be decided by the business/administrators. There will be some middle ground though. The main goal should be standardization. Once that standard is defined, everything else should fall into place.

Given some of your information, here is the direction I might go:
Code:
(root)
     >Users
     >Computers
     >(etc)
     >Sites
          >(Site 1)
               >Users
               >Computers
          >(Site 2)
               >Users
               >Computers
          >(etc)
Even though AD has it's own sites in "AD Sites and Services", I find it easier to keep everything in "AD User and Computers" so you can have a single MMC snap in for management.

You can always subdivide each site into more detail. That's up to you. If you are using policy inheritance (recommended), most policies will be assiged to a site. You should only use the "more detailed" when a specific case requires it as this will reduce administrative effort to manage the system.
 
I have always done this on a single domain. Through AD you can group seperate computers in another organizational unit and set their policies and what not seperately. A Child domain isn't necessary in many cases.
 
Dan_D said:
I have always done this on a single domain. Through AD you can group seperate computers in another organizational unit and set their policies and what not seperately. A Child domain isn't necessary in many cases.
There are some things that are a domain-wide settings. Password policy is one of them. You can only have one password policy per domain. So, if you need to implement multiple password policies, then the only way to accomplish this is to create another domain in the forest or use a third party tool.
 
Dan_D said:
I have always done this on a single domain. Through AD you can group seperate computers in another organizational unit and set their policies and what not seperately. A Child domain isn't necessary in many cases.

Since we are seperate from the data-center where the majority of the servers are...they want to delegate control to us as a child domain instead of risking us accidentally misconfiguring something and having the dns stop working in the ER. :p

an even scarier thought being an ER is using microsoft :eek:
 
Back
Top