HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler\@

1. It can backup your local GPO to a GPMC formatted backup. Which means you could backup a local GPO and then use GPMC to import it into a domain-based GPO.
2. It can take a GPMC backup of GP settings and import them into a local GPO on a machine.
3. It can restore a local GPO to its default state.

These are three great features for managing the local GPO. Let’s take a look at how to use each. For backing up the local GPO, the syntax is simple:

From a command shell, I simply type:

cscript LocalGPO.wsf /path:c:\gpbackups /export

Where c:\gpbackups is a path to where I want to store my backup and /export tells the script to export my local GPO settings.

Now if I want to import a GPMC backup into my local GPO, the syntax is even easier. I simply provide the path to the GUID-Named folder that GPMC creates under the backup directory when you back up a GPO, like this:

cscript LocalGPO.wsf /path:C:\gpbackups\{42ADD8FE-EDF6-479B-92C6-557343D8D091}

And, to restore a local GPO to its default config:

cscript LocalGPO.wsf /restore

Pretty easy to use and this script seems to support every OS from XP to Win7. A couple of caveats however. In looking at the script, Microsoft is only supporting Administrative Templates and Security Policy within these backup and restore operations (understandable given the ship vehicle for this thing). So if you have other policies like Scripts or IE Maintenance within your local GPO, it won’t be captured. Also, the script does not appear to deal with the multiple local GPOs feature supported in Win Vista and above. So if you have per-user local GPOs, they are not captured–only the default local GPO.

That being said the script does provide some good basic functionality as well as a good instructional document on how to capture and reset security settings from the local GPO (which are essentially stored in the local SAM rather than on the file system as in domain-based GPOs).

Hope this proves useful to you!

Darren

Darren

Note that within the policy, you can choose to remove all regular shares (i.e. those that the user creates), all hidden, non administrative shares (i.e. shares created by the user using the $ hidden marker) and admin shares (e.g. c$, admin$, etc.)

Obviously, you’ll want to use this feature carefully, especially when removing built-in administrative shares that are often used by remote management tools. But, the ability to remove user shares is especially useful in preventing your users from creating a peer-to-peer file sharing network under your nose, with little or no access controls!

Enjoy!

Darren

Darren

To make matters worse, querying this class has a very annoying side effect that I just learned about, and that is documented in this KB article (http://support.microsoft.com/kb/974524). Here’s the issue. When you query this class, the way the provider works is that it actually performs a Windows Installer “reconfiguration” on every MSI package on the system as its performing the query! You can see the effect of this in the application event log with dozens of Windows Installer messages showing each installed application being reconfigured. A reconfiguration includes validating the application’s install, up to and including doing an MSI repair if there is an inconsistency found between the package and the original MSI file. This was particularly irritating in one case where I had set a policy to disable a service that was installed on the system, but whenever a Win32_Product query ran, it would “repair” the application that had originally installed that service, thus re-enabling the service! Not good.

So, the lesson here is, avoid using Win32_Product at all costs–it stinks! Also note that the Item-level targeting filter for MSI packages in Group Policy Preferences DOES NOT use this problematic class, so you’re safe there.

Darren

Microsoft makes decisions about where to store GP settings for each policy area (e.g. registry, security, folder redirection, etc.) based on the amount and type of data they need to store. In some cases, like registry policy, the settings are stored in files in the SYSVOL part of the GPO, called the Group Policy Template, or GPT. In other cases, liked the new Wired and Wireless policies that were first introduced in Server 2008, those settings are stored in the AD part of the GPO, called the Group Policy Container, or GPC. In order to store these settings in AD, Microsoft often introduces new schema classes and attributes to AD to accomodate the setting types. In fact, that is exactly what was happening here.

The user was creating the GPO settings in a version of AD that contained these newer schema extensions, and then tried importing those backed-up GPOs into a version of AD that did not. The result was the failure they saw. All it took to resolve was to update the Server 2003 AD schema to at least the Server 2008 version, and the import worked. There was no need to upgrade their DCs to accomodate the newer settings–all that was needed was the proper schema extensions and all was well (of course, they still need clients that can process those newer settings–in this case Vista and greater).

Problem solved!

Darren

But lets say I create a GPO from GPMC using Windows 7, and set some GP Preferences settings or some of the new “Advanced Audit Configuration” options, then try to backup that GPO from XP or Server 2003’s GPMC. In that case, neither the GP Preferences nor the Audit settings will be backed up because those policy areas do not exist in XP or Server 2003 (from a GPMC perspective–its true that XP and Server 2003 can process GP Preferences settings, but they cannot manage them).

The bottom line is, as always, if you introduce newer versions of Windows into an environment and plan to leverage newer policy areas, its always best to manage GP from those newer versions of GPMC, since GPMC is backwards-compatible but not forwards-compatible!

Darren

Darren

I am honored and happy to be an MVP for another year. I look forward to another year of community contributions!