Group policy basics for Essentials
Kudos to Kevin Weilbacher for noticing this….. if you want to set up exactly the same Group policy organizational unit structure on your Essentials boxes…. steal from this KB:
re-create the MyBusiness OU manually. To do this, follow these steps:
- Open Active Directory Users and Computers.
- Right-click the domain name object. In the shortcut menu, point to New…, and then click Organizational Unit. Type MyBusiness to name the new object.
Note Type MyBusiness as one word.
- In the MyBusiness OU that you created in step 2, create the following OUs:
- Distribution Groups
- Security Groups
- In the Computers OU that you created in step 3, create the following OUs:
- In the Users OU that you created in step 3, create the following OU:
After you finish these steps, you should have a structure that resembles the following:
Collapse this imageExpand this image
Essentials has the same group policy, the same GPMC, it just doesn’t have prebuilt OU structure.
There is never a case where the default (flat) Active Directory (AD) tree makes great sense in terms of Group Policy or organizing anything as the AD tree is intended to be used. For a domain/forest where no attempt is going to be made to use Group Policies, the default tree can work as-is to apply the two built-in AD policies known as Default Domain Security Policy and Default Domain Controller Security Policy. Therefore, default arrangement isn’t something broken that you must fix, rather it’s just absent basic organizational design. To not use Group Policies means you are not taking advantage of some powerful management options.
For any organized use of Group Policies, a tree structure makes more sense than nothing done default, and if you are familiar with it, you could apply policy in the manner SBS standard introduced. The first priority you are addressing is to collect the objects you are most focused upon managing into a single location in the AD tree, an Organization Unit (OU) for your business/organization specific objects. You should be aware that you should not attempt to rearrange any of the existing or default “tree” objects of OUs or containers, many of these are “hardwired” path locations critical to baseline operations of AD. Therefore, creating your own top level OU to organize your own company assets also assures that you have the freedom to arrange your assets without harming the “hardwired” structure that the AD tree defines in a new AD Forest.
A common question is whether you should create a new AD tree, or remove an existing AD tree created by someone else or by a product design such as the SBS Standard platform design. In fact, for a domain that originated in SBS Standard design, there’s nothing wrong with continuing to use the SBS defined OU locations, it really has nothing specifically to do with SBS other than a couple of useful policies that SBS introduced. It’s more important to understand the Group Policies being used than to be concerned about the tree itself, but the relationship between tree design and points where Group Policies apply is part of the design of Group Policies.
Here are some guidelines to be aware of in modifying the AD tree or using Group Policies.
Critically Important Requirements
- DCs must be located in the Domain Controllers container, deviation from this causes problems in standard Directory Services processing.
- Do not create OUs below Domain Controllers container, deviation from this causes problems in standard Directory Services processing for having anything other than DCs in this location.
- Default user and security group objects created by Windows as the default accounts should remain in the default Users container. This makes sense not only because some applications require this to be true, it makes sense not to move these objects into your “managed” company tree design. Your company specific users and security groups will be easier to manage and identify if you don’t clutter up the handful you need and use by mixing all the built-in and default accounts. I can make sense to locate “application specific” security groups or user accounts (think: SQL related objects installed by the SQL application) in either a separate OU within your tree, or let them flow into the default OU for Users if you don’t care to organize them or track them.
Recommended Design Guidelines
- Create a company/organization level on the root establishes a top-level single point location for everything other than DCs. This is the most basic and common sense thing to do.
- Example of the structure being discussed here:
The tree above is sufficiently flexible to use minimal or very sophisticated Group Policy management. Dividing a multi-site company by site, then with the other OUs below each site would be the next most common advance in a tree design.
- Create a tree that organizes your users, computers and security groups. The location of Security Groups objects has no significance in Group Policy, therefore, you can create an OU for Security Groups, or separate them by type (Distribution Lists vs Security Groups), but you can choose whatever makes sense to you.
- If you use multiple “sites”, it generally makes sense to organize the site location identity below the Company Org if you are managing users and computers that are homed to those locations on a semi-permanent basis. It’s not wrong to create a top level (immediately below Organization name) as Users OU and a Computers OU with the sites below each, but as you can see immediately, that causes these “site specific branches” to be split from one another and generally makes less sense to manage a site reference this way than by physical locations, then object type.
- A simple organization plan would prefer a separate location for workstations (user desktops) vs member servers. Many policies you apply to desktop computers might not make sense for laptops in a well-managed organization.
- If you use Terminal Servers (RDP), you generally would prefer to have an OU specific for these that separates them from any other types of servers. This helps with applying Loopback Policies, and extremely valuable policy processing concept for multi-session RDP servers.
- User account and Computer account objects are the only Group Policy enabled objects, and a policy will by default apply to any object that exists in the OU where the policy is applied, or for all OU containers further below that branch (sub-tree) of the OU where the policy is applied.
(and if you need advice about migration, Jeff is your man)