This tip was submitted to the SearchWin2000.com Tip Exchange by member Carol Miller. Let other users know how useful it is by rating the tip below.
Most administrators, unless they also have exposure to and a knowledge of databases, may find Active Directory very cumbersome, complex and difficult to work with. Many administrators may not be able to manage Active Directory to it's full potential; instead being satisfied to do only the basics and use only the most minimal of features within the console.
Active Directory can be a very powerful yet easy tool to work with if approached in the correct fashion. Firstly, realize that the Active Directory is a database -- A relational database in fact. One that controls, keeps track of and monitors the objects within it. The only difference between the Active Directory and say, SQL Server, is the nature of the objects that it controls.
To properly plan your Active Directory structure, you must use the same principles that apply to a well-designed database. Firstly, know your company's needs. What is more important -- flexibility, control or security? Once this is established, determine how to physically and then virtually organize the objects.
The physical location of an object is obvious -- is it in Los Angeles or Toronto? The virtual aspect is much more difficult and largely depends upon how management will control it. It could fall under the control of the Los Angeles supervisor or the Seattle supervisor, contrary to its physical location.
Start by drawing out a rough schematic (on paper,) of what is perceived to be your structure based on the following: Security, physical location, virtual location, and management control. Then address the issues of scalability, delegation and movement within the Active Directory. Don't forget to address these issues within one domain, across trusted domains and across entire forests if necessary.
Once the structure is defined, address the issue of schema changes. If schema changes are to be required, do them as early in the deployment planning as possible. If Group Polices are required, structure them in such a way that they are loaded early in the boot up or log on for a computer or user. Avoid multiple layers of Group Policies that are performance pigs when loading and a nightmare to troubleshoot.
Keep the structure as 'thin' as possible. Create a document showing all the GPOs and where they apply. If a user is moved from one OU to another, will his/her GPO still apply? You need to address these kinds of issues. Name the objects within the Active Directory structure in such a way that they are easily attributed to their parent container or domain.
Keeping a well working database is simple, if planning is done and maintenance performed regularly. Treat your Active Directory deployment in a similar fashion, and you'll be well ahead of the game.
