Backing Up and Restoring Group Policy Objects

Inadvertently deleting a single GPO can wreak havoc on your domain. Imagine what happens when a bunch of GPOs are inadvertently deleted. Let's just say that the users are suddenly happy because they can do stuff they couldn't, and you're not happy because now they're happy. Ironic, isn't it?

An administrator inadvertently deleting a portion of a SYSVOL container of one Domain Controller will quickly damage your GPOs, and you'll need a way to restore.

Note	The Backup and Restore functions for GPOs only work within the same domain. However, you'll see in the Appendix how the GPMC can be used to "Backup" and "Import" a GPO to get the same effect between domains.

In our cases, if the policy settings inside the "Hide Settings Tab / Restore Screen Saver Tab" GPO were wiped out, the name of the GPO can surely help us put it back together. But the name alone might not be an accurate representation of what's really going on inside the GPO.

Then, there are still other questions: Where was this GPO linked? What was the security on the GPO? Who owned it?

All said and done, you don't want to get stuck with a deleted or damaged GPO without a backup. Thankfully, the GPMC makes easy work of the once-laborious task of backing up and restoring GPOs.

Tip	These techniques are valid for both Windows 2000 and Windows 2003 domains, as I stated in the Introduction. So, back up those GPOs today with the GPMC regardless of your domain structure!

Backing Up Group Policy Objects

When you back up a GPO within the GPMC, you also back up a lot of important data:

The settings inside the GPO
The permissions upon that GPO (that is, the stuff inside the Delegation tab)
The link to the WMI filterhowever, the actual filter itself is not preserved. (Again, I'll talk about WMI filters in Chapter 10.)

However, it's also important to know what won't be backed up:

Any WMI filters are contained within Active Directory. You must back them up separately. You can see one way to do this in the "Backing Up and Restoring WMI Filters" section later in this chapter.
IPSec settings aren't backed up via the GPMC backup and restore function. They are backed up during a Domain Controller's System State backup. But discussing backing up and restoring them is a bit beyond the scope of this book. My best suggestion: Manually document any GPOs with IPSEC settings.
GPO links aren't specifically backed up. Yes, you read that right. But before you panic, let me first explain how this is for your own protection. We'll examine this phenomenon in a little bit and try to make you a believer in why this is a good thing.

As you'll learn in Chapter 4, there are two parts of GPOs: the GPT (Group Policy Template) from Active Directory and the GPC (Group Policy Container) from within the SYSVOL. When a backup is performed, the GPT and GPC are wrapped up and placed as a set of files that can be stored or transported.

What's additionally neat is that contained within the backup is a report of the settings inside that GPO you just backed up. So, if someone backs up a GPO named "Desktop Settings" (again, a horrible name), you can at least see the report of just what is inside the GPO before you restore it to your domain.

To back up a GPO, you need "Read" access to that GPO, as shown earlier in an example back at Figure 2.16. You can start by locating the GPO node in the GPMC and right-clicking it. Select either "Back up All" or "Manage Backups ." For this first time, select "Back up All."

You then select the location for the backup (hopefully some place secure) and click Backup. You'll then see each GPO being backed up to the target location as shown in Figure 2.27. When you're finished, you can rest easy (or at least easier) that your GPOs are safe.

Figure 2.27: You can back up all your GPOs at once, if desired.

You can inspect the directories the backup produced if you like. You'll see a directory for each GPO, the XML file representing the GPT, and an XML report showing the settings. In the next section, you'll learn how to view the report (easily) by utilizing the "View settings" button (as shown in Figure 2.28).

Figure 2.28: You can see all backups or just the latest versions.

Note

In Chapter 4, we'll learn more about the underlying "nuts and bolts" of GPOs. Specifically, you'll learn that the underlying name of a GPO relies on a unique GUID name being assigned to the GPO. What isn't immediately obvious here is that the directory names produced by the backup (which take the form of GUIDs) are not the same GUIDs that are actually used for the underlying identification of the GPO. These are additional, unique, random GUID directory names generated just for backup. This seemingly bizarre contradiction becomes useful, when you read the next paragraph.

The backup is quick, painless, and rather reasonably sized . The best part about the backup facility is that it's flexible. When you choose to run your next backup, you can keep your backups in the same directory you just choose, and you'll keep a history of the GPOs, should anything change. It's the underlying random and unique GUID names for the directories that allow you to keep plowing more GPO backups right into the same backup directorythere's no fear of overlap. Or you can keep the backups in their own directory; it's your choice.

If you dare, go ahead and delete the "Hide Settings Tab / Restore Screen Saver Tab" GPO. You'll restore it in the next section (I hope).

Now that you've backed up the whole caboodle, it should also be noted that you can back up just a solitary GPO. Right-click the actual GPO (which is located only in the Group Policy Objects container) and choose Backup. In Chapter 7, you'll find a script that enables you to script and automate your backups.

Warning

Be sure the place in which you back up your GPOs is secure. You don't want the knowledge stored within the GPOs to possibly be used as an attack against you.

Restoring Group Policy Objects

The restore process is just as easy. It works for GPOs that were backed up in the same domain. Note that it's also possible to back up and restore between domains, but this is called a GPO Migration (see the Appendix).

When you restore a GPO, the file object you created in the backup process is "unrolled" and placed upon Active Directory. As you would expect, the following key elements are preserved:

The settings inside the GPO
The friendly name (which comes back from the dead)
The GUID (which comes back from the dead)
The security and permissions on that object (which come back from the dead)
The link to WMI filters (which comes back from the dead)

Note	Whomping a GPO doesn't delete any WMI filters associated with a GPO itself. Any WMI filters are stored in a separate place in Active Directory. It's sort of like the Jacuzzi next to the swimming pool.

The GPO does not have to be deleted to do a restore. For instance, if someone changed the settings and you want to simply restore the GPO to get an older version of the policy settings, you can certainly restore over an existing GPO to put a previously known "good" version back in play.

Restoring GPOs requires the following security rights:

If you want to restore on top of a GPO that already exists, you need Edit, Delete, and Modify rights, as seen back in Figure 2.16.
If you want to restore a deleted GPO, you need to be a member of the Group Policy Creator Owners security group.

You can start a restore by right-clicking the Group Policy Objects container and choosing "Manage Backups." You'll be able to select a location from which to locate your GPO backups; you might have multiple locations.

Warning: A deleted GPO's Links arenot restored!

Assuming you went ahead in the last example and deleted the "Hide Settings Tab / Restore Screen Saver Tab" GPO and are now ready to restore it, there is something you need to know before proceeding. That is, one critical item is missing: the Group Policy links to the GPO are not restored in this operation. The location of links is backed up, but upon a restore, the links are not restored. You might be scratching your head wondering why this is.

Let's examine a theoretical timeline.

On Day 0, a GPO named "Desktop Settings" is linked to two OUs named Doctors and Nurses.
On Day 1, the GPO is backed up
On Day 2, a fellow administrator unlinks the GPO from Doctors. Now, the GPO is linked only to Nurses.
On Day 3, someone deletes the whole GPO (and hence its links.)
On Day 4, someone recognizes this deleting and restores the GPO.
Here's the $50,000 question: Upon restore, where should the links be restored to?

Should the links be restored back to the last way it was just before the catastrophe on Day 3? Sure, that would be ideal, but how would the system know what happened between Day 2 and Day 4? As it is, on Day 4, the GPO is now linked only to Nurses, but how could the system know that now?

Should it link the GPO back to the original locations, as it was on Day 1? On Day 1, it was linked to Doctors and Nurses? But restoring those links back to the same location could be a catastrophic mistake. Clearly, on Day 2 an administrator unlinked it from Doctors for some good reason! Restoring the link back upon the Doctors could be detrimental to their health!

Instead, of restoring the links, the GPMC does the smartest thing it can do during a restore: not restore the links. That's rightby not restoring the links, it is ensured that you're not inadvertently relinking the GPO back upon some location in Active Directory that shouldn't have it anymore.

However, as stated, the backup process does record where the links were at the time of backup. To that end, you can easily see where the links were at the time of backup and, if desired, you can manually relink the GPO back to the locations you want. To see where a GPO had links upon backup time, here's what to do:

Right-click over the Group Policy Objects node and select "Manage Backups"
In the "Manage Backups" dialog, Ensure you're looking at the directory with the contents of the backup
Locate then select the GPO which was deleted
Then, click on the "View Settings" button (as seen in Figure 2.29).

Figure 2.29: You can locate GPOs with lots of characteristics.

A report will be generated that, among other things, shows you where the GPO was linked. Then, once the GPO is restored, you can manually relink the GPO where you need it to be linked.

If you've chosen to keep backing up the GPOs into the same backup directory, you can select the "Show only the latest version of each GPO" option, which shows you only the last backed-up version. If you've forgotten what is contained in a backup, simply click the backup name and choose "View settings." You can see these options in Figure 2.28.

When ready, click the GPO to restore, and then click Restore. It's really that easy.

Tip	You can also right-click the GPO itself (found only in the Group Policy Objects container) and choose "Restore from Backup," which in fact performs the same function. (See Chapter 7 for a script that will enable you to script and automate your restores.)

Backing Up and Restoring WMI Filters

As you read about WMI filters in Chapter 10 and learn what a pain in the tush they are to create, you'll be thankful that there's a mechanism that can back up and restore them. They are not backed up or restored in the process we just used. Rather, you must individually back up each WMI filter. Simply right-click the filter, and choose Export. To restore, right-click WMI Filters node and choose Import. Sometimes restoring a WMI filter adds excess and invalid characters to the query. Simply re-edit the query and clean up the characters , and you're back in business.

In the previous section, you saw that GPO links are not restored when the GPO is restored. The same is true for WMI filters: the WMI Filter links are not restored when the WMI filter is restored. Again, for information on how to automatically document this information, see Chapter 7.