How to avoid common GPO backup and restore problems
Group Policy Objects help admins maintain control of the enterprise environment, but it takes some planning to understand how to properly protect and recover GPOs to avoid trouble.
Group Policy usage is ubiquitous in corporate networks, but few admins have a solid understanding of all the moving parts and how to protect them in case of disaster.
Group Policy Objects -- often called GPOs -- may be the only tool used to manage user and computer accounts. Many admins count on this service to work, but problems can affect any tool. Microsoft built Group Policy to operate with little maintenance, but GPOs can be finicky to manage. Corruption of GPO settings and conflicts between policy changes made by multiple admins are commonplace. To avoid a breakdown of this critical management tool, you should have a solid understanding of the GPO backup and restore process.
What is Group Policy and what are Group Policy Objects?
Group Policy is a core feature of Microsoft Active Directory (AD) that manages configuration settings for users and computers in a Windows domain. Group Policy has been around since Windows 2000. Since its introduction, Group Policy Objects have seen incremental improvements, but the major concepts of GPOs remain unchanged. Admins use GPOs to apply settings to a set of resources, including users, computers, security settings, groups, organizational units (OUs) and AD sites, or to an entire domain. Group Policy can configure around 12,000 individual settings.
You configure a Group Policy Object to hold the settings to deploy. This new policy applies to the place in the AD tree structure where you link the GPO. Most times, you link policies to a specific OU or to the entire domain and then security groups in AD limit which users or computers receive the policy. All this occurs inside a central management tool called the Group Policy Management Console, commonly referred to as the GPMC. Each policy is its own object, hence the name Group Policy Object.
Admins use GPMC to configure and analyze Group Policy settings, but the policies created from the console live in the SYSVOL folder on the domain controllers. Those settings apply to users and their computers at login and then refresh in the background throughout the day. The settings managed via the Group Policy Management Console are registry key values in the Windows OS.
The registry is a giant collection of settings that control various aspects of how the Windows OS and installed applications operate. Admins use GPMC to configure settings that change the values for the corresponding keys in the registry and lock those values down to keep users from tampering with them.
Why Group Policy reliability is critical to the enterprise
The Group Policy Management Console is a Microsoft Management Console snap-in and is a GUI tool that controls the configuration of the Windows OS via policies. The policies are a collection of settings that relate to specific registry keys, but GPMC offers a safer and more elegant way to manage those settings and deploy them to a fleet of computers.
Microsoft included Group Policy with AD, so there is no added cost to use the Group Policy Management Console, regardless of the size and scope of your environment. GPMC controls and configures hundreds of thousands of computers, all from a single console. I cannot underscore enough Group Policy's importance and impact in the enterprise configuration management space.
How to back up Group Policy Objects
In a typical corporate environment, there can be many Group Policies used to manage the environment. Microsoft recommends only 20 to 30 Group Policies, but it is commonplace to see many more GPOs in use in the real world. At my current employer, we have about 90 Group Policies to manage about 25,000 computers.
You can back up GPOs individually or as a complete set. Each Group Policy is a combination of files and folders, and each Group Policy has a distinct set of files, depending on what settings are in use. You cannot just copy the files. This screenshot shows the Group Policy folder and file structure generated by the tree command.
How to back up Group Policy Objects with GPMC
You can perform backups either with the Group Policy Management Console GUI tool or with PowerShell.
In GPMC, right-click on a GPO, and choose Back Up. This invokes a backup wizard that prompts you for a backup location and an optional comment.
This backup process stores each GPO in its own folder. Microsoft expects you to interact with GPO backups either using the Group Policy Management Console or PowerShell, even though you can access the folder with the backup data. This screenshot shows the backup folder, which does not have the Group Policy name in the folder structure.
Each iteration of a GPO backup has a globally unique identifier (GUID) as its name. Microsoft uses these GUIDs as the GPO backup ID. Some restore operations need the GPO backup ID to work correctly, which can be a challenge to understand. The file structure generated by the tree command shows a visual layout of the files and folders in the GPO backup folder.
The Group Policy backup folder and file structure is similar to the original Group Policy folder structure. However, there are additional XML files with the GPO files in a new parent folder called DomainSysVol. A simple file copy isn't enough to back up a Group Policy. The two XML files created during the backup contain all the information related to the GPO, such as the domain it came from and other data needed for the restore process.
To back up all GPOs is a nearly duplicate process as a single file backup. Right-click on the Group Policy Objects folder, and select Back Up All.
You then see the same window we saw in the single GPO backup method. You select the location and add an optional comment.
Once the backup completes, you receive a summary report of the backup process.
Each backed-up GPO lives in its own folder. Each folder has the same GUID for a name and contains additional subfolders and files needed for the restore.
How to back up a Group Policy Object with PowerShell
The other option to back up GPOs is to use PowerShell. PowerShell invokes the same engine as the Group Policy Management Console for backups, and the file structure is also the same.
The following PowerShell command is an example of how to back up a single GPO:
backup-gpo -name "Test GPO" -path C:\gpobackup\PowerShellBackup\ -comment "single file backup"
To back up all GPOs, use the -All parameter:
backup-gpo -All -path C:\gpobackup\PowerShellBackup\AllGPOs\ -comment "Backup All GPOs"
How to restore Group Policies with GPMC
Both methods to restore GPOs have potential pitfalls that make the process harder than it should be. The best option is to use each in tandem. First, let's look at how to restore a GPO with GPMC.
Right-click the Group Policy Objects folder, and select Manage Backups. This opens a window showing the summary of stored backups.
The interface shows a lot of useful info, but it can be frustrating to use. You cannot see all backups for all locations in one view. For example, notice the Backup location drop-down at the top of the window. If you made backups to multiple folder paths as I did in my examples, then you need to select the folder location before you can see the backups in that location and the comments that were added during the backup process.
The screenshot also shows three backups, which came from the Back Up All GPOs option. You can't restore all files at once. If I needed to restore all my GPOs, then that would require three separate restores. That's easy in my lab but not great in my corporate environment, where I have more than 90 GPOs in use.
There is a checkbox for version control at the bottom of the restore window. If checked, then you only see the latest backup, regardless of how many backups of the GPO exist. You can sort by backup timestamp and pick a specific GPO backup to restore.
Performing a GPO restore in GPMC takes two clicks. Select the GPO, click Restore and then confirm the operation. The system shows a summary window when the restore process finishes, which only takes a few seconds. However, be aware of one major challenge: If you restore a deleted GPO, the links to the GPO will not be restored.
The screenshot shows the test GPO, which is linked to the US-Raleigh OU. In the security filtering section, I have added Domain Admins.
If I delete the GPO and perform a restore operation, then the link to the US-Raleigh OU is gone and not restored. There would be no issue if I restored a GPO over an existing one.
How to restore a Group Policy with PowerShell
PowerShell makes it easy to restore a single GPO. I only need the name of the GPO and the GPO backup folder. The Restore-GPO cmdlet reads the information in the folder and finds the correct file to restore. The following command restores the GPO:
Restore-GPO -Name "Test GPO" -Path C:\GPOBackup\PowerShellBackup\
Restoring a GPO from a previous version is a more challenging task and one that might not make sense until you read more.
First, the good news is we can use PowerShell to restore backups made by the Group Policy Management Console. The inverse is also true: We can restore backups created by PowerShell with GPMC. This is important to know because it is extremely difficult to restore different versions of GPOs via PowerShell without careful planning.
For example, let's look at the syntax needed for a restore:
Restore-GPO -BackupId 0fc29b3c-fb83-4076-babb-6194c1b4fc26 -Path "PATH-to-your-backup"
To restore a different version of a GPO rather than the latest version, you need the backup ID of the version wanted. At first glance, that doesn't seem too difficult, but I want to highlight a problem that isn't immediately obvious.
When I performed the backups in earlier examples, I had to pick the backup folder. The backup process can only send the backups to the folder I specify. It doesn't have a method to create folders. In the example that backed up all the GPOs, the result was three subfolders inside a parent GPO backup folder. The subfolder names were GUIDs, which are also the backup IDs for each GPO.
If I had to back up 90 GPOs, I would end up with 90 subfolders for each backup job. If I perform backups of 90 GPOs on 10 consecutive days and the same folder for the output, then I would have 900 subfolders in my GPO backup folder. All I would have to work with is GUIDs, and no GPO names would be visible. This screenshot shows six folders, which represent two backups of three GPOs, with an example of how the multiple backups appear in the GUI.
Now, the challenge of doing a restore for alternate versions becomes clear: How do you find the right GUID for the backup job you need? There is a possibility, but it is arduous and not a realistic way to work.
Find the GPO name of a GPO backup file
For this example, I use File Explorer to find the GPO backup folder. With File Preview enabled, I can see the file contents in the preview pane. When I click on the GPReport file, I see the "friendly" name of the GPO in the preview pane. This screenshot shows all the relevant info with the friendly name of the backup highlighted in yellow.
Finding the right backup ID is difficult if all the backup files are in the same folder. You can locate the correct backup ID by looking at the Created Time value in each GPReport file. If that's the correct date, then you can use the GUID of the folder's name as the backup ID. You could also look at the timestamp on the GPReport file and see if it's the correct date, but timestamps can change, which makes them unreliable.
I could also use PowerShell to find all the GPReport.xml files and then parse each file to retrieve the file creation timestamp, GPO ID, GPO backup ID and GPO Name. This would require writing some custom code that is trickier than it sounds.
The easiest solution is to save each day's backup files to a new folder. This would reduce the effort to find the correct backup ID to just one day's worth of data. You could automate a way to create the folder structure before the backups start and then change the backup path to the correct folder for each day.
Use GPMC and PowerShell to make each one better
The GPO backup and restore process works best when you use the Group Policy Management Console and PowerShell together, which addresses the shortcomings of each tool.
We start with a method to run backups on an interval. Most admins run backups on an automated schedule. If you think back to the GUI backup process, it was missing a key feature: a scheduler. This requires invoking the GUI backup wizard to take a backup, which most admins would not prefer. However, PowerShell makes this task much easier with a script that automates the entire process: scheduling the task, creating daily folders and running the backup job.
When it comes time to do restores, using PowerShell to restore the most recent backup is quick and easy. But it can be a complex challenge to restore alternate versions of GPOs using PowerShell if you don't know the GPO backup ID. The GUI handles the restore process for alternate versions rather nicely. It can recognize the different backup versions and display the info inside the restore application rather than having to browse for the information in the folders.
Learning to work with multiple tools is a key administrative skill
While Microsoft provides many administrative tools that work well enough, there are shortcomings to get around. But, when used together, the tools give IT pros everything they need to create a comprehensive backup strategy. Take some time to set up your backup and restore process. Build automation to handle the daily backups. Test and document the restoration process, and share with your colleagues. You'll thank yourself down the road if disaster strikes.