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:
- 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.
- 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:
- 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.