IT Employment·20,064 discussions

What makes a good ad structure?

Locked

i’m currently restructuring the organizations AD structure. i have only been with the company for a little over a week. they have about 800 some users, and about 600 some machines. i’ve never worked for a company of this size and of this many different departments. am i better keeping the bottom of the hierarchy more defined or less defined?

Topic

Active Directory Structure

In reply to What makes a good ad structure?

Keep it simple

make it flexible

delegate

If you can, use single forest, single tree.

try to stay within 3 or 4 levels on the tree.

with OUs see #1 & #2

If it isn’t broke don’t try to fix it.

Active directory structure

In reply to Active Directory Structure

well it is broken… there is no structure. its a hospital environment with three other locations on the same domain. numerous departments and areas. i started to do the visio diagram of how i think it would be most ideal and leave room for growth later down the road. but it just looks like too many ou’s in the third level and i dont want to take it anymore then 4 levels.

at my first level i have the locations. then at the second level of each i have ou’s named servers, departments, and areas. then on the third level i get a little more detailed with the departments and areas.

Active Directory – A Logical Structure

In reply to Active directory structure

what came to mind when you mentioned there is not structure, a hospital with 3 locations on the same domain is what gets most IT guys confused about Active Directory. Its a logical structure that does not “need to” mimic [and more often than not should not mimic] physical layout of the company. To mimic the physical layout of a company invites problems because it limits flexibility in a growing company. Example: Companies typically have a sales department, manufacturing, engineering, management, accounting, human resources. under these department headings can be any # of “sub departments”. Under sales can be regional sales, local sales and a branch off the top level sales such as customer service. OUs can be created at the top level such as Sales OU and then sub OUs nested inside the Sales top level OU. You can then collect users or computers in those OUs regardless of their actualy physical location and have GPOs applied [or delegate admin]. There is flexibility in this design approach and simplicity because your not limiting the design to match the physical design. This holds true for forest/domain design as well which is also a logical structure.

is physical sometimes better then logical?

In reply to Active Directory – A Logical Structure

in our environment here we do more of trying to control things based up where they are located. our off sites are different specialties then at the main campus. so there isn’t much repeating of the departments across the locations.

With the past companie’s i was with a logical structure was good.. control didn’t need to be as granular. and everything was within two levels

DNS and Active Directory

In reply to is physical sometimes better then logical?

You can create an AD structure that mimics physical layout. you can group computers into OUs that match physical layout.

There’s nothing in the rule books that says you can’t, only that its “better” to go with logical structure because its easier to manage and flexible.

AD Design

In reply to DNS and Active Directory

Remember that you can apply GPOs on a “per site” basis also.

You talk of different physical locations… Will these be in different sites? (i.e. are they on different subnets? Do you have a DC on each remote location?)

Second – it is advisable to keep the directory as flat as possible. Remember that you only NEED to create more than one domain if you require a different password/security policy for different users.

Of course we are assuming that you will only need one tree in your forest! That is correct isn’t it? 🙂

We do create OUs named after our geographic locations for USERS only. Our computer accounts exist in OUs that reflect the role they have. For example we have an OU for laptops, one for Service PCs, one for kiosk PC, one for general staff PCs etc.

I think you need to consider things in this order:
1. DNS namespace – get that sorted first!
2. Domain structure.
3. Site structure.
4. OU structure.

Give us a clue about your sites (physical locations), whether you are looking at multiple domains, a very brief organisational structure if possible.

Good luck! Spend the time carefully working through this, don’t hesitate to ask questions! It’ll look great on your CV!!
🙂

ad design

In reply to AD Design

there is already a domain in place here. i am just redoing the AD structure before we bring in the exchange server. with it being a hospital environment we like to have very granular control over things. the physical layout that i came up with works fairly well with our group policy design. as of right now only the main campus has servers, plan on having servers at each location in time. mainly to help free up the wan line. for the most part things are on the same subnet with the exception of the phones which and a few other medical equipment devices. we like to have control over things based upon where they are. and in our opinion the placement of where people and computers are added would be easier in a physical layout. this is because they will only be using machines in that area. and coming up with a logical structure has been very difficult.

Simple is best

In reply to What makes a good ad structure?

Sometimes defining the physical can lead to more problems and admin for yourself as departments grow. Its best not to break departments down into too many OUs as it becomes a nightmare creating users/computers in the correct OU. When designing the structure it is often best to try and reduce the number of physical departments into one OU,then use groups to allocate policy.

Its often worth considering what policys you plan to enforce before thinking about the OU structure.

Define by GPOs

In reply to What makes a good ad structure?

Personally, i like to define my AD by how I want to implement Group Policies. For example, if I keep all my workstations in one OU and my Users in another, I can define machine policies and seperate user policies. By being more granular, I can put those workstations and users into additional sub-OUs based on who needs which policies. I can define top-level GPOs that impact all users, and create more specialized policies to apply to the sub-OUs.

Same subnet

In reply to Define by GPOs

Earlier you stated “for the most part things are on the same subnet with the exception of the phones.” Why are most things on the same subnet? Isn’t that sucking up bandwidth? Different locations should be on different subnets and then these subnets broken down further for departments. This would free up the WAN line.

still new here

In reply to Same subnet

as i had said i’m still new here and as of right now there are no servers at the other sites. and we dont really have any problems with it yet. but in the near future we plan on going to servers on each location and different subnets.

you still working on this?

In reply to still new here

Send me a pm if your still working on this I’ll send you a sample logical Active Directory domain based structure.

I won’t say that this is how you should do yours [I remember you sending me a chart] rather that, if you start your design process this way, it may be easier than if you try to design an AD structure using a physical layout.

Note: you mention adding server and sites and this is probably where your going to run into trouble mixing a logical with physical structure.

AD & The Org Chart

In reply to What makes a good ad structure?

I was always told AD should follow the org chart, but that may be too old school (and too simple).

depends

In reply to AD & The Org Chart

depends on the business i suppose as well

2 cents

In reply to What makes a good ad structure?

The first thing you’ll have to do is identify what you are trying to achieve with your AD OU’s.

The two most important reasons for a more granular tree design are delegation and GPO’s.

Take for example your servers, do you need to give access to another group for them to be able to administer servers in a different location? If so, putting them in a different OU is valid. But if one group administers all servers, you might as well have them all in a single OU, even if you want to apply different GPO’s, you could achieve that by filtering based on groups.

I don’t think there’s a “one size fits all” approach here. Like some others mentioned, a lot of it depends on the structure of your organization.

[Author]

Replies