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

AD & OU setup

Have the following network, single forest, single domain. Would like to make sure initial AD is setup correctly. Total users 100, located in 8 offices. Main office is 70 users with all servers. Branch offices have no servers. All offices linked together via dsl VPN. Organization is public service, no sales. Four departments including 5 sub-departments, administration and management. Resources required at main office on main server(DC) for login, home directory, and intranet on seperate web server. All offices have own printers and access internet/email via local isp's. All applications accessed locally. Installed so far(test environment): DHCP, DNS and AD(shows several default OU's). It seems that seperate Login scripts and Group Policies will be necessary. Questions: Should the OU's be setup in a departmental hierarchy or branch office structure ? What would be the next steps in the above scenerio to complete the AD ? Can multiple group policies exist per OU ? Can users belong to multiple OU's ? If yes, do I not want to avoid this ? Under default Computer and User OU, should these be populated with OU's or users ? Also, is there other OU's that should be added to complete a typical AD ?
Thx.
0
mmm5
Asked:
mmm5
  • 5
  • 4
  • 3
  • +1
3 Solutions
 
bilbusCommented:
if you only have servers at the main site then create OUs for each location

install the new GM management console

yes apply the GP's in the OUs. so have one OU/GP for office 1, 2, 3, ect

you can put 100's of GPs in a single ou.. though you only add the groups you want it applyed to in the delegation window

so say you have 6 groups
so you can put GP1 in a OU, and add 3 groups to it. only those 3 groups wioll have the GP applyed, the other groups will not. you can add another GP in that OU and have it apply to the other 3 groups.

0
 
joedoe58Commented:
I would look on what I want to establish with my OU. If the group policies will be applied accordint to departments and you have the departments spread out over the branches you could also set up your OU strategy as departments. This would eliminate the need to move a user just because he moves office but stay in same department.
0
 
Netman66Commented:
I agree with joe on this one.

Departments are how this should be setup initially.

Like so:

Domain
     Dept1 OU
     Dept2 OU
     Dept3 OU
     Dept4 OU
     Dept5 OU

Sub-OUs can be created under each department if necessary.  If, in the future, you decide that each remote office will require a server, then the above structure could simply be moved into a "site-specific" structure without the need to move user and computer accounts around.

In your case, you will not need any sites created other than the Default-First-Site-Name (which can be renamed if you want) since there are no offsite servers to replicate with.

Just make sure that your sites are using the VPN connection and DNS on your main site as the primary - otherwise, domain-related queries will not be sent to the correct server.

Hope this helps.
0
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

 
mmm5Author Commented:
I would like to add a further description of our network. The main office, along with all servers,  has 5 HP print servers and all staff physically located in their respective departments. Branch office staff use single print server per per office, or personal printers, and are not separated into departments. Largest branch office is 10 staff. Half of offices only 2 staff.  It would seem to me that a sort of mixed OU structure may best suit us. ie:

Branch Offices
--Location 1
-----users
-----computers
-----printers
--Location 2
-----users
-----computers
-----printers
etc.....

Main Office
--Department 1
-----Sub-Dept
--------users
--------computers
--------printers
-----Sub-Dept
--------users
--------computers
--------printers
--Department 2
-----Sub-Dept
--------users
--------computers
--------printers
etc..........

Any thoughts on this structure ? Has anyone implemented similar OU structure. Thx.

0
 
joedoe58Commented:
Yes you can have a mixed structure. What is important is that it is flexible and will meet your needs without creating an overhead of administrative work
0
 
Netman66Commented:
No need to break out OUs for users, computers and printers.  When you use GPOs they only apply to the respective object you set values on -- either the computer or user (or both if you combine settings in a single GPO).

Other than that, you have the right concept, yes.

You could do this also,

Department1
     Main Office
          Servers
     Remote Office1
          Servers
     Remote Office2
          Servers


The choice is purely preference, but either one will do just fine.  One thing to keep in mind is to keep the number of OUs to the lowest you can to accomodate your needs.  The Servers OU is there for two reasons: 1) To group the objects for ease of administration, and 2)  You will Block Policy Inheritance on these Server OUs to prevent policies applying to them that can cause you pain - example is a GPO for workstations.  Link the Default Domain Controller policy to each Servers OU you create so that the base policy applies to them.  Alternately, you can leave all the DCs in the Domain Controllers OU - the choice is yours.

Cheers,
NM
0
 
mmm5Author Commented:
I'm a little confused NM. Are you saying not to create OU for users, computers or printers ? Can you expand or simply edit my OU structure ? There are no servers in any remote office ! I can however see a servers OU under Main office. Thx.
0
 
Netman66Commented:
Sure I can clarify.

Branch Offices
--Location 1
--Location 2

etc.....

Main Office
--Department 1
-----Sub-Dept
-----Sub-Dept

--Department 2
-----Sub-Dept

etc..........

There is no need to break out users, computers or printers - it just adds overhead for you.  You can easily distinguish these objects when they are in the same OU.  Group Policy only affects computers and users.  If you apply a GPO on an OU it will simply apply to whatever object you set the elements on.

The separate Servers OU is simply used to shield your servers from policies that you want to deploy to workstations.  Many people move server objects into sub OUs only to find out the hard way that a GPO has locked down the server console just like any other workstation.  I just wanted to make sure you had that in your mind.  If you only have servers in the main site, then leave them in the Domain Controllers OU - they'll be just fine in there.

NM
0
 
mmm5Author Commented:
I think I get it. Thanks.

Last bit of clarification. When I join the AD domin via XP workstation route,  the computer(machine) account installs itself into the default computer OU. However, if user accounts are created in the sub-Dept OU and Location OU's, as objects, should the computer accounts also be created(exist) in these OU's and not the default computer OU ? Is this a big deal ? Is there a GPO factor ?

It seems that everywhere I read it is stressed that the AD structure be done correctly, especially from the onset. I certainly want to get it right !

Thx.
0
 
joedoe58Commented:
No you do not have to move them to the users OU. Usually you group your computers into a OU structure for controlling SUS server or other settings that is computer related and you want to configure the computers in a specific way.
0
 
Netman66Commented:
No, it's not a big issue.  The computer accounts get created there by default.  You can move them to the correct OU afterwards.  SUS settings - as joe points out - are computer specific.  So, they can be grouped with your office OU without affecting the users whatsoever.

There are scripts that can be used to join a computer to the domain *in a specific OU*, but if you're the only Administrator then it's easy enough to do it manually.  You might want to consider prefacing the computer names by office so that you can tell immediately where they belong.

An example using the asset # (if you use them)

FLD166248

where FL stands for Florida
and D166248 might be the asset #.

If you standardize the naming scheme it will make your life much simpler.  You can always create labels that are unique for each PC that you can use for naming schemes.


0
 
mmm5Author Commented:
Sorry Netman66, is asset # - D166248 - a computer referenced as a record in a separate file or document.  

Also, can you tell me what restrictions do user logon names have. I was wondering if I could place a period in it. ie: joe.smith  or joe.s
Thanks.
0
 
Netman66Commented:
What I meant by asset # is that some companies use asset tags they attach to each piece of equipment they buy so that they can track it's location and reference it specifically when keeping records on it.  We use asset numbers on our equipment and no two are they same - which makes it a viable way to name workstations and guarantee you don't duplicate names.

No restrictions - the period is fine.  You Pre-Windows 2000 logon DOES have a 20 character limit, though - so keep that in mind.

0

Featured Post

Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

  • 5
  • 4
  • 3
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now