An SME Active Directory Design Blueprint

Introduction

Many organisations rely on Microsoft Active Directory as either a directory service or a network operating system or both. Active directory is the Microsoft standard for directory services and is an extremely useful and valuable tool for administering and securing any Microsoft or mixed environments that offer LDAP/Active Directory integration.

Right, so Active Directory services are available on my Windows domain after I have installed it and there is some limited configuration done for me with some predefined security groups out box but how should I best design and configure it to allow me granularly manage and secure my domain, devices and applications?

Throughout this article I will share with you a design that I have formulated over the years and implemented into many organisations that has proven to work well.

My Active Directory (AD) design is based heavily on custom OU and AD Security Group configuration to achieve granular security and manageability It is therefore important that we establish a standard for both and we will define this later in this article.

Naming standards are defined throughout the article. It is essential that you stick to a naming standard whether its your own adapted one of the ones I have specified for you.

Before we jump into the deep end, lets have a quick look at the list of the areas we will cover as part of our design:

1. Preparation
3. Organisational Unit (OU) Configuration
4. Security Group Configuration
5. Group Policy Configuration

A few notes before we continue:

Note ** This design is specifically aimed and small to medium enterprise businesses. Although it can be adopted to work in bigger global enterprises - a cut down version would need to be applied to minimise administrative overhead **

Note ** Feel free to use my design in your organisation and please provide any feed back, issues and ideas to improve it where necessary in the comments section at the end of the article **

Note ** This design can be applied to all versions of Windows from 2003 through to 2012.
------

Below is a list of the high level steps to complete your AD design. Each of these steps will be be described in detail in the following section:

1. Perform pre design tasks (document and understand existing AD config if any)
2. Design your organisational unit (OU) structure
3. Design AD security groups naming standards
4. Design your group policy's objects and assign them to associated OU's
5. Move your Objects into their new OU locations
6. Test your new configuration
7. Communicate and train your technical teams

------
** Before you proceed - I suggest you download a free opensource application called KEEPASS to store all your user account details and passwords as you proceed. As you craete a new account, update KEEPASS as you go** 

Preparation

Before we embark on this exciting quest to implement a new and improved AD into your organisation, we must first conduct a short planning exercise first to make sure that we have thought everything through. If you are configuring a brand new installation then we can move swiftly to the next section (Active Directory OU Design), however if you have an existing AD that you are setting out to improve then you should document the existing configuration to ensure that we have everything covered.

I would suggest that you use Microsoft Visio to document the existing AD structure in a diagram like the one below - make sure that you mark which group policy objects apply to which OU and take some time to fully understand what each group policy object does.

-----------------------------------------------------------------------------------------------------------------------

Active Directory Organisational Unit (OU) Configuration

OU's are typically folders that are used to organise your Active Directory structure. For more information on the OU see the link http://en.wikipedia.org/wiki/Organizational_Unit.

In my design I keep OU use to a minimum as too many OU's make it difficult to navigate the directory structure and will end up complicating it in the long run. Simplicity works best for me here so I try to keep to a design that is minimalistic. Remember that you do not need to have a dedicated OU for each Group policy object you want to apply to a set of users or computers. Group Policy objects themselves have a scope setting that allows you to allocate them to a subset of users or computers within the same OU. I prefer to use Group Policy filters instead of OU's and we will go through this later in this article.

If you already have an existing AD domain that you are improving then you will now need to create a new top level OU and this will be the root OU for your new configuration. I usually name this "CompanyName Active Directory" - all my new OU's, as part of this design will be configured under this new root OU. I suggest you prevent this new root OU from having any legacy Group Policies applied to it so set it to "Block Inheritancy" from the Group Policy Management Console (GPMC).

As we progress through this article it I will be referencing my design to an example which will make it easier for you to understand what I am trying to achieve. The example below is what I will be basing my deisgn on. You may have to customise your configuration slightly to meet the design of your own environment. I would suggest that you read through the whole article first before you begin to apply the design.

For this example we will assume that we have a head office location in London and then some branch offices around Europe in France and Germany. note -

All preconfigured / Builtin OU's will remain intact as-is and will not be modified

Based on this example our core OU design will follow the format below:

For this example lets assume that we have a company called ADPOC ltd who employ around 1000 people. They have a head office in London, UK and branch offices in Spain, France and Germany. (If you do not have any branch offices then you can ignore them in the design and just focus on your head office.)

Their new Systems Administrator has identified that the companies Active Directory configuration is not suitable and is going to rebuild it according to the design discussed in this article to improve standards, efficiency and security.

Due to the vast amount of OU's and its untidy structure we have decided to create a new Top Level OU under which we will begin our new AD structure. We will call this new OU "ADPOC Active Directory"

The new OU's I create under my root OU will consist of some OU's that are shared between all sites and some that are site specific. One that are shared will contain common objects that are not bound to location such as Security Grups, Admin Accounts and Service Accounts. Objects that are site specific are computers, users etc.

the OU design will be specific to each business needs but please remember to keep it as simplistic as possible and try not to make the OU tree too deep.   I try to keep a maximum of 3 OUs. remember we will use group policy filtering to apply group policy to a subset of computers rather than OU s.
please be sure to add the top level Security Group OU and all its sub OUs as this is where all the magic happens....

The new OU structure for my example above is shown below:

ADPOC Active Directory
                   >> Admin Accounts
                   >>Service Accounts
                   >> Exchange Resources
                                    >> Contacts
                                    >>Meeting Rooms
                                    >>Distribution Groups
                   >>Security Groups
                                    >>AC_Application Control
                                    >>AD_Administrative Groups
                                    >>DB_Database Groups
                                    >>DG_Department Groups
                                    >>FA_Folder Access
                                    >>WG_Working Groups
                   >>France
                                    >>Computers
                                    >>Mobile Devices
                                    >>Servers
                                    >>Users
                   >>Germany
                                    >>Computers
                                    >>Mobile Devices
                                    >>Servers
                                    >>Users
                   >>London
                                    >>Computers
                                    >>Mobile Devices
                                    >>Servers
                                    >>Users

** Some objects such as domain controllers will need to be placed in the Domain Controllers OU that is automatically created during AD install and this will not change

Lets discuss my AD OU design as illustrated in the picture above.

Global OU's - contain objects that can span all sites. In my design the following OU's contain global objects:

• Admin Accounts
• Service Accounts
• Exchange Resources
• Security Groups

An explaination of each of the OU's follows:

Admin Accounts OU - I use the Admin Accounts OU to store my privileged user account  e.g. any user account that has domain admin or delegated privilegesr. This allows me to easily keep track of all those users that have admin rights by checking which accounts are located in this folder. I will use this folder to conduct audits on a regular basis so that account information is kept up to date.

To follow best practice, admin users should have normal user accounts separate to their admin accounts. Their normal user accounts are for everyday use and should be located in the users OU in the location specific folder whereas their associated admin account is used only as a RUN AS account to elevate privileges when required.

e.g. a user called John Smith is a Domain Admin and also a user in ADPOC and is located in the London Office. I will therefore create two accounts for him as follows:

john.smith@adpoc.internal -> locate in the London-Users OU (non privileged account)
JSAdmin@adpoc.internal -> located in the Admin Accounts OU (privileged account used only for admin tasks)

Service Accounts OU:

Service account are any domain accounts that are used by applications but are not directly associated with a user. For instance an I may have an application that requires an account to run with, in this case I would create a service account for that specific application. For auditing and accountability I try to create a single service account for every task that requires a service account. Generally service accounts should have the 'logon locally' right removed through group policy, and should have their passwords set to extremely complex passwords with password set to never expire.

Service account naming standard and configuration:

svc_<location>_<ServiceName>

• update the description field within the account proerties with the exact purpose of each service account you create.
• Set an extremely complex password and update keepass (your password database)
• Set password to never expire
• Configure a group policy to set all service account security e.g. remove 'logon locally' security right

Each service account has a detailed description of what it is used for in the description field in the properties of the user account

Exchange Resources OU - I use this OU to manage all my exchange resources and objects which include external contacts, meeting rooms objects and exchange distribution groups. When you create new objects within exchange, locate them it into its appropriate OU.

Security Groups OU - Security groups allow use to define really granular security within Active Directory and integrated application and operating systems. We will create a number of different types of security groups, each with a different purpose and will detail the purpose of each of these groups and their naming standards later in this article. Security groups will be global objects within our domain and the following security group types will be used:

• AC_Application Control
• AD_Administrative Groups
• DB_Database Groups
• DG_Department Groups
• FA_Folder Access
• WG_Working Groups

Now we have covered all the global objects & OU's we will move onto the Site specific objects and OU's.

Site Specific OU's & Objects:

Location/City Folders OU - Each remote office or location will have its own OU and should contain the following sub-OU's:

• Desktops 
• Laptops
• Servers
• Users 

Feel free to adapt the OU design as you see fit to align with your organisation.

Next we will move onto security group design which allows us to define granular security controls throughout our domain.

----------------------------------------------------------------------------------------------------------

Security Group Design

We will use security group to provide granular control over our AD integrated systems while maintaining a naming standard that allows us to easily identify what each security group is used for.

Before we move onto the detail of each of the security group types we need to understand the design principals behind them. Please take a few moments to study the list below.

Security Group Design Principals

• There must be a variety of custom built security group types that offer different functionality (detailed below)
• Each security group must have limited function preferable a one to one mapping where possible.
• Security group must follow a defined and descriptive naming standard (detailed in the following sections)
• Security group must type must be appropriate for nesting requirements e.g. Domain Local, Global or Universal (explained in following section)
• Security group nesting is promoted but only to a limited depth to avoid complication (recommended maximum level 2 - 3 layers of nesting. Some articles state that nesting can cause complexity but this is because naming standards and limited group functions are not followed). If you stick with my design we will use nesting to our advantage without causing complexity.
• Group naming standards - All BLUE options are mandatory all PURPLE options are optional.
• Always add descriptive detail to any group you create so that anyone will understand the exact function of the group and its members.
• If a group is used to define group policy - list the group policies it is associated with in the NOTES section within the properties of the object.

Security Group Types

I generally recommend that security group types are set to "Domain Local" groups or "Universal" groups if necessary. Stick with Domain Local as your first choice but if nesting is limited for a specific group change it to a "Universal" group. Generally you will need to use "Universal" groups for any trusted or Trusting domains as you will be able to next "Universal" groups within "Domain Local" groups.I have based this recommendation by studding the group compatibility matrix form Microsoft and this group type is the most flexible for our requirements. Assess your requirements carefully before specifying your Security Group type to ensure that nesting within and across your domains will be possible.

the next topic that we will focus on will be the core of this design concept...security groups. the principal here is that security groups should have limited functions and should follow a strict naming convention. think about this!, if you have a single security group named IT Department and you assign this security group to multiple purposes will you fully understand the impact or adding or removing people from this group.. or what about when you have to delete the group or replace it for some reason,  will you know the impact of doing this... I bet the answer to this is probably not and this is the issue I have come across time and time again.  this is why I say that each security group should have a single defined purpose and it should be easy to find out exactly where a security group it used and understand its purpose.


we will start by looking and and understanding the different types of security groups I have incorporated into my design? by this I do not mean local,, global,, or universal groups but rather custom group types that I have designed. read carefully through the security group types and explanations of each below....

The defined security group functions that we will used are listed below. Each group function will be broken down and described in the necessary amount of detail in the following sections. Please note that you are not limited to the group functions I have listed for you, feel free to create your own or not use all of them - you have the freedom to customise the design as you wish.

Before we begin:
*Important note - I will cover the core concepts of naming standard definition only in the DG_Department Groups type however the same standards will apply to all Security Group functions. I have done this in order to eliminate repetition of how to use security groups in this design. Please make sure that you read and fully understand the naming and usage of the DG_Department Groups so that you can apply the design to other security groups types.

DG_Department Groups

Department Groups security groups are used primarily to assign individual user accounts to logical business departments. each user account allocated to an individual must be assigned to a department group - service accounts or other generic accounts should not be assigned to Department Groups.

There should be one department group for every department in your organisation. If you have the same departments at different locations the your should create a separate DG group for each department at each office location. Department groups can then be nested to include all members in a department in all office locations. An example will be provided later in this section.

DG_Department Group naming standard:

in general the naming standards that I follow have no spaces in them and have underscores for separation purposes where necessary. The blue letters are the front of the name, in this case "DG" are mandatory . All options in italics should be changes with values that reflect your environment. All Purple options are optional to include and blue is mandatory. Assess your environment to see which naming standard options you should include.

DG_<Domain>_<Location>_<DepartmentName>

the naming convention above provides us with the right amount of information to be able distinguish the exact purpose of any Department Group. Some of the options in the naming convention are not always necessary and should be used based on your requirements such as if you have multiple domains and multiple offices, for example we could drop the "<domain>" and "<location>" if we know they will not be used.

For example lets say that we have a multiple domain environment with trusts and also multiple offices in each domain, lets see how the naming convention will help us define our groups.


DG_ADPOC_LON_HumanResources

I would use all options if I have multiple domains and multiple offices in my organisation so that I can easily identify what the group applies to.

DG_LON_HumanResources
DG_GER_HumanResources
DG_GLOBAL_HumanResources

If I only had a single domain with multiple offices then I could use the example above.  bear in mind that you may at some point have multiple domains so this should be a design consideration. you can always add the domain option for new domains at a later stage.

as you can see in the example above I have Human Resources department staff at both London and Germany offices. to cater for this circumstance I have created a global human resource group into which I will nest all the office based human resource groups.
this will give me the flexibility to apply settings to human resource staff at a particular office or all human resource staff.

I have created the following DG groups for my domain. I have chosen not to use the <domain> option of the naming convention as I do not require this option for my example.

DG_LON_ITInfrastructure
DG_LON_ITNetworks
DG_LON_Finance
DG_LON_HumanResources
DG_LON_DatabaseAnalysts
DG_LON_BusinessAnalysts

Once I have set-up all my companies department groups in the format shown above I can then move onto the next security group type.

AD_Administration Groups

Administration Groups are used to define who has what administrative rights to which objects or components within your domain or enterprise. I find that I use this group type a lot and break down RBAC rights granularly using these groups.

Basically I mirror any defined or custom RBAC roles within my enterprise with AD groups and then apply these groups permissions within the component that I am applying permissions to. Sounds a bit complicated but it most certainly is NOT so lets run through a few examples so that you can get your head around it.

Most of us should be familiar with VMware vCenter so my first example will be to apply vCenter permissions using AD_Administrative Groups. Lets say that we need an group to assign administrative permissions to a group of  TEST VMs within a logical folder in vCenter called 'Test'. To achieve this I would simply create a group called "AD_vCenter_Test_Administrators" add the user accounts that should have administrative vCentre rights to these VM's and then assign this AD group the Administrator role at the Test folders level in vCenter - job done. I always updated the description field of the new AD group to relect its actual purpose although in some instances the naming standard will let you know.

Similarly is I need to assign VMUser rights to a specific folder in vCenter called "Test SQL" then I would create a new group called "AD_vCenter_TestSQL_VMUser" and assign this group the appropriate permission on the "Test SQL" folder within vCenter.

I can create AD group for any devices and software that I can set-up roles for administration using Active Directory integration.

Another example would be when I set-up delegation in Active Directory for my Service Desk team.

Lets say that we only want the service desk to be able to users to our London User OU only. We could set-up a group called "AD_ActiveDirectory_LondonUsersOU_ManageUsers". In the description on this group I can put more details about exactly what permissions this group has but the name should be descriptive enough to work out the basics.

The naming standard for AD group is a little less formalised as it needs to be able to meet your given requirement based on what you are trying to achieve. just make sure that all your groups follow a standard naming standard for any given component...

for example for your Active Directory delegation group above you wouldn't want to create a secondary group called "AD_GermanyUsersOU_Users_ActiveDirectory" as it would not match the naming of the first delegation group for Active Directory that we created. Consistency is your friend and mine...

AD_<Location>_<System>_<Scope>_<Permission>

Other examples of where you can use AD groups are, but not limited to:

Setting HP iLO permissions
Setting up Blade server permissions
Setting up Storage Admin permission
Setting up network device permissions
Setting up Local Admin membership permissions set by group policy on server or desktops
the list goes on....


Once implemented be sure to let the service desk understand the design so they can assign new accounts to the appropriate groups.

GP_Group Policy Filter

Active Directory group policy is a powerful tool that should be used to control your Windows environment.

When creating group policies you have the option of creating blanket policies and applying these to specific OU's. Providing you have not made any modifications to the default scope settings the group policy settings will apply to any applicable objects within the OU it is linked to. Generally this method of applying Group policy settings means that you have to create many OU's so that you can seperate which objects get specific settings - this leads to an messy Active Directory.

My preferred approach applying group policy settings is to keep the AD OU structure as defined above and then use the scope / Group Policy security permissions to define which objects any policy applies to. For instance, if I wanted to setup a group policy that configured a specific set of computers throughout all my office locations to have a longer timeout before the password protected screensaver kicked in, then I could create a new policy with the specific settings defined, link it to the domain root level and then create a new GP group Policy filter group. I would then add all the computers to this new GP group and then configure the scope settings within the properties of the new Group Policy object to only apply the policy to the new GP group. To do this I would remove the 'xxxx' group from the scope and replace it with the new GP_ group that contains the subset of computers. This is a better way of achieving the end result rather than creating a new OU at every office location and then applying the group policy to each of these OU's.

This concept should be applied to all group policy settings throughout your domain. Remember to always update the properties of any new GP groups you create and add notes of exactly what the groups purpose is and which group policy objects it is used in. This allows any future admins to understand how you have configured the environment and will improve your reputation (wow, the last sysadmin was really good!!)

Naming Standard:

GP_<Function>_<Permission>

e.g. GP_5MinScreensaverTimeout_Apply
e.g. GP_5MinScreenSaverTimeout_Block
e.g. GP_AllowLogonLocallRight_Apply
e.g. GP_AllowLogonLocallyRight_Block
e.g. GP_PCISecurityLockdown_Apply

You should adjust the size and complexity of each of the group policy objects based on the granularity of each of the GP groups you would like to create. For instamce if you want to be able to apply a 5 minute screen save setting easily and granularly to anyone then you would have a single group policy object dedicated to just this setting. Setup the scope to only apply to the 'GP_5MinScreensaverTimeout_Apply' group and also a deny setting to the 'GP_5MinScreenSaverTimeout_Block' - remove the authenticated users group so that the setting will only apply/or get denied to both the groups mentioned in this paragraph.

The same principle woul apply to any other group of settings that you would like to apply to a subset of users. If you want a group policy to apply to all users then you will not have to create any GP__ groups and just apply to authenticated users (default).

note - to deny your GP_ security group to have a policy applied , go into the security tab of the group policy object. Add you group to the list and then check the deny box. Don't forget to update the GP_ group description field and state which group policy it applies to and that it has deny box checked.

AC_Application Control

I use these groups if you need to give specific right a user but it is not necessarily RBAC (role based access controls). Applications would include web proxies where you may want to allow a group of users to have access to streaming media or something like end point security where you may want to allow a subset of users to be able to use USB ports on their computer.

Naming standard:

AC_<ApplicationName>_<PermissionType>

e.g. AC_BluecoatProxy_AllowEXEDownload

e.g. AC_Mcafee_AllowUSBReadWrite

Dont forget to update the properties of the new group object to include detailed information on the purpose of the new group.

DB_Database Control

Database groups are used to apply specific permissions to databases through active directory groups rather than local groups within the databases themselves. To use there groups you would need to have mixed mode or Active Directory authentication enabled on the database servers.

I usually tend to create groups for database admins and also database users where the database admins would llocate user groups limited rights to specific databases or tables within a datbase on any database server. Please speak to your your DBA's about these groups and work with them to find out how many groups they require and the associated level of rights for each group wich will help you define what the group names should be.

DB_Database Groups Naming Standard

DB_<DatacenterName>_<ServerName/CLusterName>_<DatabaseName>_<Permission>

Each of the options within “<>” are not mandatory, so you can pick the ones that apply to you and replace the options with values as per the example below:

e.g. we want to give SYSADMIN rights to a group of users to a database called “HR PAY” which is installed on database server HEXVSQL01 in the SUPERTRUST zone that is located in Datacenter 1. The name of this group will be:

DB_DC1_STR_HEXVSQL01_HRPAY_SysAdmin 

FA_Folder Access

Folder Access groups are used to assign NTFS permissions to folders. Managing NTFS permissions using generic groups nearly always ends in tears, especially when you want to change a group of membership of a group and don't know all the places it is applied, expecially when it comes to file and folder permissions. This is why I like to have one group per use, at any given time I can tell you exactly what that group is used for and who belongs to that group.

So lets look at how I use FA groups, firstly the naming standard which follows the format of other groups but with a slight difference:

Folder Access Naming Standard

FA_<Server/ShareName>_<TopLevelFolder>_<..>_<TargetFolder>_<Permission>

Permission Variables:
FC= Full Control
MOD = Modify
RWXD  = Read, Write, Execute. Delete
RX = Read, Execute
you can add your own variants as you need

So lets say we have a folder called "Confidential" located within a file server root share at the following location: "\\CorporateShare\CEO\Business\Confidential"

I would like to set custome security on this folder with the following permissions:

CEO = Full Admin Rights
CEO PA = Read Only

I would then create the following security groups:

FA_CorporateShare_CEO_.._Confidential_FC
FA_CorporateShare_CEO_.._Confidential_RX

I will open the advanced security option for the folder "Confidential" and then prevent folder form getting propogated security applied. Clear out the existing groups applied to the folder and add in your new groups, as created above, and assign each group the correct permissions. You may want to leave in the "Creator Owner" and "System" default permissions depending on your requirements but this is not necessary.

PA_Printer Access

Printer access security groups can be used to allocated permissions to printers. Use your imagination for the naming convention getting ideas form the above examples.

PA_<floor>_<PrinterName>_<Permission>

WG_Working Group

Working groups allow me to to group to gather a subset of user, computers or objects that have some sort of relation to each other but are not naturally fixed together.

An example of when I would use this if there was a project that a collection of people across multiple departments are involved with and need to be grouped together to apply any given settings or permissions for this role.

Lets say that we have a new project called "Project X" that the business is undertaking. Project X will involve a set of staff form the business.

I would create a group within the WG_Working Group  OU called "WG_ProjectX" and I would add all the staff working on this project to this group. I can then use this group to apply settings, permissions etc. to the working group for Project X very easily.

The Working Group option can be used as you see fit and provides a way of grouping things together that would otherwise not naturally be grouped together.

The naming convention for working groups are:

WG_<Domain>_<Location>_<GroupName>

As described in the DG_Departmenty Group section, the naming convention follows the format above. Text in BLUE is mandatory and test in ITALICS is variable. Text in PURPLE is optional and can be used at your discretion. Refer to the Department group for further clarification on how the naming convention options should be used and for information around group nesting usage.

==================================================================

Group Policy Configuration

One of the biggest benefits of Active Directory for me is the functionality of Group Policy within a Microsoft domain. It is important to configure your group policy settings in a way that is logical and easy to understand.
It is easy to get caught in the habit of creating an extra OU to apply a group policy but for me this complicates and messes up with our base AD OU design which should only change if absolutely necessary.

I find that their is a trade off between having few group policies that do allot or lots of group policies that do little. I try to strike a balance and group clusters of settings within a group policy object and have single group policy objects to apply bespoke settings that are out of the normal settings.

When I create group policy objects  I maintain a naming convention but not as strict as my group policy naming standards. Having a group policy naming standard allows me to sort my GP objects neatly and allows me to understand the base function of any GP object. For group policy names I usually put a prefix to the group policy name such as the ones that follow:

SSP_<policy description> (SSP = Server Security Policy)
DSP_<policy description> (DSP = Desktop Security Policy)
FWP_<policy description> (FWP =  Firewall Policy)
DSD_<policy description> (DSD = Desktop Software Deployment)
SSD_<policy description> (SSD = Server Software Deployment)

Some examples of the above follow (in your design you should have multiple group policy objects for each type):

SSP_Domain Controller PCI-DSS Security Settings

Contains the group policy settings to secure domain controllers to PCI-DSS requirements

DSP_General Windows 7 Desktop Lockdown Settings

Contains the general settings to lock down Windows 7 desktops

SFP_Exchange Server Firewall Policy

Contains server Windows firewall policy settings for Exchange Servers.

FWP_Desktops_Finance Department

Contains the finance department desktop windows firewall settings

DSD_Base Desktop Applications

If you use group policy to deploy applications in your organisation then your could group applications in a single group policy object. In the object above we have grouped all standard desktop applications included in our base build.

SSD_Tomcat Application

The group policy object above would be used to deploy Tomcat server to specific application servers

Now that we have designed our group policy setup standards we have to decide how we will deploy our group policy settings to subsets of computers in our OU design without adding new OUs and messing up our original structure.

I achieve this by using .... wait for it.... Security Groups!

GP_AllServers_Filter
GP_WindowsFirewall_Block

Lets say that we have all our


--------------------------------------------------------------------------------------

Once you have completed your design and configured it, it is then essential to train your service desk and Infrastructure teams, DBA's etc on how the new design works. This will ensure that they continue to follow the new naming standards and will know how to effectively use the new design principals to their advantage.