Group Policy Objects

This section of the document will briefly discuss Organisational Units and Group Policy Objects.


Group Policy Objects or “GPO” are what makes AD such a useful tool; it’s a policy that defines specific settings, access and login scripts that run against a user or PC when they login to your domain. By implementing a stringent array of policies, an IT department is able to:

  1. Reduce the manpower to configure computers;
  2. Reduce the costs involved in configuring users devices (wages, downtime being the two major concerns) and;
  3. Allows a uniform approach to new-user devices, and allows automated deployments with no intervention.

To successfully implement Group Policies, there needs to be a strong understanding of the business, and an organised OU approach. For my company, I believe the approach should be as follows:

--- root domain
----- site location
------- dealership/business unit
--------- department(s)
--------- computers
--------- security units
--------- disabled accounts
----- site location
------- dealership/business unit

Now, of course, this setup is for my company; yours would vary. The key OU structure I intend is to have a computerdisables accounts, and security unit OU nested under the Organisational Units, for clarity.

For those unsure of what an OU is, it can be defined as:

In computing, an organizational unit (OU) provides a way of classifying objects located in directories, or names in a digital certificatehierarchy, typically used either to differentiate between objects with the same name (John Doe in OU “marketing” versus John Doe in OU “customer service”), or to parcel out authority to create and manage objects (for example: to give rights for user-creation to local technicians instead of having to manage all accounts from a single central group). Organizational units most commonly appear in X.500 directories, X.509 certificates, Lightweight Directory Access Protocol (LDAP) directories, active directory (AD), and Lotus Notes directories and certificate trees, but they may feature in almost any modern directory or digital certificate container grouping system.

Essentially, thing of them as “containers” used to store other items; users, groups and computers in this instance. Whilst you can apply policies to OUs, they serve little other purpose apart from manageability of a directory.

OUs are useful to sort and contain objects within your Active Directory. Use an approach that suits the needs of your GPOs.

Local Group Policies

A local group policy is just that; local to the PC you’re using. Managing several Local Group Policies on a machine can get rather messy, as well. When thinking about Local GPOs, it is important to remember the process in which they are applied.

The order of precedence for GPOs are as follows:

  1. Local Group Policies are applied on the PC;
  2. Site Based Policies are applied, and will overwrite local if any settings conflict;
  3. Domain Policies are applied, and will overwrite both the above policies if conflict is there and;
  4. OU Policies are applied, and will overwrite all above if any conflict is there.

Meaning if locally the users homepage was set to http://intranet/ and the OU defined it as https://intranet.localdomain.com.au/index.html then the homepage would be the latter of the addresses.

Whilst in a small environment (≯ 10) it may be justifiable to implement local policies, but using a more centralized, manageable tool such as Domain Policies will be more effective.

GPOs are applied in hierarchy. Local policies are rather useless, and are overwritten by all other defined policies.

Domain Group Policies

Domain GPOs are where it’s at! These policies are applied across the domain by targeting GPOs enabled against the Domain, by referencing users or security groups (or even PCs if needed).

Policies applied against the Domain (usually done on an administrative server or Domain Controller) are directly related to Active Directory Users and Computers (ADUC!). Generating a policy allows it to be linked to an OU, security group, user or computer.

After creating a script or Windows Setting, you link the GPO to a security group, user or PC to ensure it replicated across any device they use on the domain. This is rather handy as it is not tied to the current PC.

This is the screen for a 2003 or later DC

Linking Existing GPO

There are several benefits of maintain your GPOs through Group Policy Management;

  1. Allows you to propagate the same policies across an array of users and computers with ease;
  2. Allows you to enable or disable a policy at will;
  3. Allows you to edit the policies remotely if there an issue and;
  4. Allows you to view and diagnose issues in a centralized manner.

Domain GPOs allow for easier controller, flexibility and manageability for the IT department!

Example Group Policies

Let’s assume your clients work with a lot of sensitive data, and are always leaving their computers unlocked. Of course, client confidentiality should be their utmost priority, but they’re complacent.

If we open up gpedit.msc on our PC and navigate to: User Configuration > Administrative Templates > System > Power Management we are able to define whether their computer must prompt for a password after entering sleep, as follows:

We can then do an inverse by going to: Computer Configuration > Administrative Templates > System > Power Management > Sleep Settings and define when we want the PC to enter sleep mode:

It is important to remember, a single GPO may have an array of settings applied under it. This means, both these settings can be applied in the same GPO option if we are to deploy it through the Domain GPEdit console. n

Testing Group Policies and Gathering Group Policy Results

Group policies are never reliable if you’ve not got the ‘basics’ right; that is, a functional domain-joined PC receiving Group Policy updates at certain intervals.  To test the functionality of Group Policy, the first step would be to perform RSOP on the user PC to see if they receive any updates, or detect conflicts:

Once done generating results (the (Not Responding) is sadly expected), you will be brought back to a similar screen (gpedit.msc) where you can see the user’s policies being applied. If you are still unsure, you can perform a Group Policy update as follows:

gpupdate /force && shutdown -f -r -t 0

RSOP should then be re-run on reboot, to see the results. If you are still not sure the results, you can check:

$Dir = (Test-Path C:\tmp)
$User = $env:USERNAME
 If ($Dir -eq $True) {cd C:\tmp}
  else {
   mkdir C:\tmp
   cd C:\tmp
 }

gpresult.exe /h report-$user.html

This should highlight the winning policies, losing policies and any errors in processing policies. Lastly if all else fails, check the event log for errors against Group Policy.