What is Group Policy?

Group Policy is a tool that is available to administrators that are running a Windows 2000 or later Active Directory Domain. It allows for centralized management of settings on client computers and servers joined to the domain as well as providing a rudimentary way to distribute software.

Settings are grouped into objects called Group Policy Objects (GPOs). GPOs are linked to an Active Directory organizational unit (OU) and can be applied to users and computers. GPOs cannot be applied to groups directly, though you can use security filtering or item-level targeting to filter policy application based on group membership.

That's cool, what can it do?

Anything.

Seriously, you can do anything that you want to users or computers in your domain. There are hundreds of pre-defined settings for things like folder redirection, password complexity, power settings, drive mappings, drive encryption, Windows Update, and so on. Anything that you can't configure via a pre-defined setting you can control via scripting. Batch and VBScript scripts are supported on all supported clients and PowerShell scripts can be run on Windows 7 hosts.

Professional tip: You can actually run PowerShell startup scripts on Windows XP and Windows Vista hosts as well as long as they have PowerShell 2.0 installed. You can make a batch file that calls the script with this syntax:

powershell Set-ExecutionPolicy RemoteSigned
powershell \\\\server\share\script.ps1
powershell Set-ExecutionPolicy Restricted

The first line allows unsigned scripts from remote shares to be run on that host and the second line calls the script from the batch file. The third line sets sets the policy back to restricted (the default) for maximum security.

How are Group Policy Objects applied?

GPOs are applied in a predictable order. Local policies are applied first. There are policies set on the local machine via gpedit.msc. Site policies are applied second. Domain policies are applied third, and OU policies are applied fourth. If an object is nested inside of multiple OUs, then the GPOs are applied at the OUs closest to the root first.

Keep in mind that if there is a conflict, the last GPO applied "wins." This means, for example, that the policy linked at the OU that a computer resides in will win if there is a conflict between a setting in that GPO and one linked in a parent OU.

Logon and Startup Scripts seem cool, how do those work?

A logon or startup script can live on any network share as long as the Domain Users and Domain Computers groups have read access to the share that they are on. Traditionally, they reside in \\domain.tld\sysvol, but that's not a requirement.

Startup scripts are run when the computer starts up. They are run as the SYSTEM account on the local machine. This means that they access network resources as the computer's account. For example, if you wanted a startup script to have access to a network resource on a share that has the UNC of \\server01\share1 and the computer's name was WORKSTATION01 you would need to make sure that WORKSTATION01$ had access to that share. Since this script is run as system, it can do stuff like install software, modify privileged sections of the registry, and modify most files on the local machine.

Logon scripts are run in the security context of the locally logged on user. Hopefully your users aren't administrators, so that means that you won't be able to use these to install software or modify protected registry settings.

Logon and startup scripts were a cornerstone of Windows 2003 and earlier domains, but their usefulness has been diminished in later releases of Windows Server. Group Policy Preferences gives administrators a much better way to handle drive and printer mappings, shortcuts, files, registry entries, local group membership and many other things that could only be done in a startup or logon script. If you're thinking that you might need to use a script for a simple task, there's probably a Group Policy or preference for it instead. Nowadays on domains with Windows 7 (or later) clients, only complex tasks require startup or logon scripts.

I found a cool GPO, but it applies to users, I want it to apply to computers!

Yeah, I know. I've been there. This is especially prevalent in academic lab or other shared computer scenarios where you want some of the user policies for printers or similar resources to be based on the computer, not the user. Guess what, you're in luck! You want to enable the GPO setting for Group Policy Loopback Mode.

You're welcome.

You said I can use this to install software, right?

Yep, you can. There are some caveats, though. The software must be in MSI format, and any modifications to it must be in an MST file. You can make an MST with software like ORCA or any other MSI editor. If you don't make a transform, your end result will be the same as running msiexec /i <path to software> /q

The software is also only installed at startup, so it's not a very fast way of distributing software, but it's free. In a low-budget lab environment, I've made a scheduled task (via GPO) that will reboot every lab computer at midnight with a random 30 minute offset. This will ensure that software is, at a maximum, one day out of date in those labs. Still, software like SCCM, LANDesk, Altaris, or anything else that can "push" software on an on-demand basis is preferable.

How often is it applied?

Clients refresh their Group Policy Objects every 90 minutes with a 30 minute randomization. That means that, by default, there can be up to a 120 minute wait. Also, some settings, like drive mappings, folder redirection, and file preferences, are only applied on startup or logon. Group Policy is meant for long-term planned management, not for instant quick-fix situations.

Domain Controllers refresh their policy every five minutes.

A quick note on Group Policy Preferences: If you want to use these settings but have Windows XP SP2 or Windows XP SP3 workstations, these will first need to install Group Policy Preference Client Side Extensions for Windows XP (KB943729).

Computers Container vs Computers OU

There is a default Computers container under the domain root in Active Directory (AD), that is often mistaken for an Active Directory organizational unit (OU). This is actually a Container, and is NOT an OU. Since this is not actually an OU, group policies do not apply to objects within this container. The exceptions to this rule are group policies applied at the domain level. These will be the only policies applied to objects in the Computers container.

By default, computer objects joined to the domain, that are not pre-staged, go to the Computers container.

So if you are wondering why your policy isn't applying, check to make sure the object in question, is in the correct location in AD.

Backing up GPOs

You can back GPOs up using the Group Policy Management Console (GPMC).

1. Open Group Policy Management and double-click Group Policy Objects in the forest and domain containing the Group Policy object (GPO) that you want to back up.
2. To backup a single GPO, right-click the GPO, and then click Back Up. To backup all GPOs in the domain, right-click Group Policy Objects and click Back Up All.
3. In the Backup Group Policy Object dialog box, in the Location box, enter the path to the location at which you want to store the GPO backup(s), or click Browse, locate the folder in which you want to store the GPO backup(s), and then click OK.
4. In the Description box, type a description for the GPO(s) that you want to back up, and then click Backup. If you are backing up multiple GPOs, the description will apply to all GPOs you back up.
5. After the operation completes, click OK.

The great thing about backing up Group Policies, is that it has built-in version control. Meaning, you can use this procedure multiple times and it will keep track of the changes between policies. You can then restore to a specific version of a policy.

You could even set up a scheduled task to run a PowerShell script that uses the Backup-GPO command to automate backups.

You would still want to backup (using a conventional backup method) the folder you are backing up the GPOs to.

Came here looking for a simple Powershell script that you can add to Scheduled Tasks to backup your GPOs? Don't have AGPM from the MDOP pack?

Here you go.

First one does a rotating daily backup for the day of the week. You'll need to create the folder path ahead of time for each folder (Sunday/Monday/etc.) I didn't use New-Item since I figured why deal with a Test-Item and New-Item each time when these are really static folders after day 1. You'll need the AD Powershell Modules available on the server you run it on.

# GPOBackupScriptDayOfWeek.PS1
# This script Backup all GPOs and save it to a folder based on the day of the week
# It runs as an automated task on SERVER and we keep a one week rotation on disk


Import-Module grouppolicy 
$date = get-date
$dayofweek = $date.DayofWeek
#Remove current backup from the folder (to alleviate space issues down the road since it won't overwrite each time)
Remove-Item \\SERVER\GPO_Backup\$dayofweek\* -Recurse -Force
#Backup current GPOs to the folder
Backup-Gpo -All -Path \\SERVER\GPO_Backup\$dayofweek

Same thing here, but this time it's for a Monthly. Again, create the folders ahead of time as January, February, etc.

# GPOBackupScript.PS1
# This script Backup all GPOs and save it to a folder each month on the first of the month
# It runs as an automated task on SERVER and we keep a one year rotation

Import-Module grouppolicy 
$month = get-date -Format MMMM
#Remove current backup from the folder (to alleviate space issues down the road since it won't overwrite each time)
Remove-Item \\SERVER\GPO_Backup\$month\* -Recurse -Force
#Backup current GPOs to the folder
Backup-Gpo -All -Path \\SERVER\GPO_Backup\$month