Traditionally Group Policy has been administered from the Group Policy Management Console. With literally thousands of options available to you in Group Policy it makes it a lot easier to administer using a GUI. However since the release of Windows Server 2008 there are Group Policy PowerShell commands available that can help make this process a lot easier.
The Get-GPO command retrieves all the information you require about a specific Group Policy Object (GPO). You can retrieve the GPO information based on GPO name, the GPO's GUID or, by choosing the -all switch, all of the GPOs in the domain. Although you may feel you can get all this information from the Group Policy Management Console (GPMC), the output also lists useful information you might normally miss, such as the owner of the GPO, the time it was created, the time it was last modified and whether everything is enabled or disabled. This is very useful when troubleshooting the creating and editing of GPOs within your network.
Although it is assumed that your GPOs are backed up as part of a System State backup it is also a good idea to back up Group Policy as a separate task, as this will make restoring GPOs much easier. Fortunately PowerShell allows you to do this by using the backup-GPO cmdlet. As with the Get-GPO command, you can specify your GPO to be backed up based on its name, GUID or using the blanket -all switch. The most useful part of this command is that it allows you to schedule a backup using a PowerShell script:
Backup-Gpo -Name CompanyGPO -Path C:\GPO-Backup -Comment "Monthly Backup"
The Restore-GPO cmdlet restores GPOs back to the domain specified. However if you are using the backup and restore GPO commands as a way of transferring Group Policy objects, you'll need to keep to the same version of the Windows Server 2008 operating system. Non-Windows Server 2008 R2 versions cannot restore Windows Server 2008 R2 GPOs.
The Resultant Set of Policy tool has been available in the GPMC for some time, and is a useful tool for logging and planning your Group Policy deployments. The PowerShell get- ResultantSetOfPolicy tool allows you to produce Group Policy reports very quickly, in HTML format. For example if you wanted to check the resultant policy settings for particular user on a particular computer you could run the following command and produce an HTML document with all of the information broken down:
Get-GPResultantSetofPolicy -user domain\domain.user -reporttype html -path c:\GPO-Reports\UserGPOReport.html
As with all of the cmdlets mentioned, an extra tool that PowerShell offers is the ability to script the command on a scheduled basis so you can monitor your Group Policy infrastructure more efficiently.
Set/Remove – GPLink
The GPLink cmdlet allows you to create and remove links between GPOs and organizational units. Although this may seem easy to achieve using the GPMC the cmdlet does also provide you with another handy admin tool. Say you require a GPO to run on a specific day once a month, and the rest of the month you don't want the GPO to apply at all. Using the GP link command you can schedule when a link is applied and then removed without having to do so manually. You can also use other GPO cmdlets in combination with GPLink and then use the pipe command to execute the remove-GPLink cmdlet, as in the example below which specifies a Group Policy or an inherited Group Policy and then removes the link:
(Get-GPInheritance -Target "ou=CompanyOU,dc=domain,dc=com").GpoLinks | Remove-GPLink
One reason a Group Policy application sometimes fails to apply is because the incorrect permissions have been set on the GPO. The Get-GPPermissions cmdlet produces a breakdown report of who exists in the GPO's Access Control List (ACL) and the permissions that have been applied. So if you wanted to view exactly who had permissions on a certain GPO, you can use the following cmdlet:
Get-GPPermissions -Name CompanyGPO -TargetName "Company" - TargetType Group
This would give you the following output:
Trustee: Domain Users
You could also get this information for all of the objects in the ACL, therefore including all admin and system groups as well. With such a simple output this makes it very easy to rule out any permission-based issues when applying GPOs.
ABOUT THE AUTHOR
Dave Leaver has worked in the IT industry for the last ten years as an IT support engineer. He currently works for an IT support company in Cheltenham, UK, supporting over one thousand users, spanning over forty companies. Leaver specializes in Microsoft system migrations and Exchange Server. Leaver has also been a network administrator for the NHS and several large construction companies throughout the UK.