Create a Windows Security Baseline Group Policy Object with Microsoft Security Compliance Manager (SCM)

Security Compliance Manager (SCM) is a tool that I find extremely useful, especially when preparing for a new Windows OS deployment. And best of all, it’s free!

Included in SCM are Microsoft’s recommended baseline security configurations for just about all of their current Operating Systems, including both desktop and server OSes, as well as some of their flagship applications such as Internet Explorer and Office. You can review and modify these configurations directly in SCM, export the configuration to a GPO Backup folder (as well as to a .cab or .xlsm), and then use that export to create a Group Policy Object to be applied to the appropriate systems in your domain.

I recently used this tool to create a security baseline GPO for Windows Server 2012 R2, so I’ll provide you with the basic steps that I used as a reference.

Please take note that even though the baselines included in SCM are Microsoft’s recommended configurations for security hardening, many of the settings have the potential of having a negative impact on your systems’ performance  and/or your ability to manage them. Because of this I highly recommend taking the time to carefully review and research each setting within a baseline to make sure it will not conflict with any existing policies or procedures in your environment, and making changes as needed.

  1. Download and install Security Compliance Manager 3.0.
  2. In the left pane, expand Microsoft Baselines.
  3. Expand the desired operating system or application version and then select a role. In my case I chose Windows Server 2012 and the basic Member Server Security Compliance role.


  1. With the role selected, click on the Duplicate button in the right pane under the Baseline section.


  1. Give the duplicate configuration a new name and modify the description if you wish and then click Save.
  2. Your duplicate configuration will show up at the top of the left pane under Custom Baselines, above Microsoft Baselines. Click on it to open the configuration.


  1. Take some time to carefully review the configuration settings included in the baseline in the center of the window. You can make changes as needed by clicking on the setting and then modifying the options shown.


  1. When you’re finished making any necessary changes, export the configuration by clicking on the GPO Backup (folder) link in the right pane. Be sure to save it somewhere accessible from the system where you manage your domain group policies.


  1. Open up the Group Policy Management console and connect to your domain.
  2. Under Forest -> Domains -> MyDomain -> Group Policy Objects, create a new Group Policy Object and name it according to your organization’s GPO naming convention. If you don’t have one, I recommend basing the name off of the baseline configuration you created to distinguish it and make it easier to find, e.g. Windows Server 2012 Security Baseline.
  3. Once created, right-click on the new GPO and click Import Settings…


  1. When the Import Settings Wizard appears click Next >.
  2. If you’re attempting to import the configuration settings into an existing GPO rather than with a newly created one, I recommend using the next screen to create a backup of the GPO first. Otherwise, since there are no existing settings to overwrite, click Next > to continue.
  3. Browse to the location of the GPO Backup folder that you exported from SCM earlier and then click Next >.


  1. The wizard should detect the baseline in the backup folder and list it in the next window. Click on it and then click Next >.


  1. You may get a warning that the backup contains UNC paths. Select Copying them identically from the source and then click Next >.


  1. Click Finish to complete the import.

And there you go, you now have a Group Policy Object containing the recommended baseline security settings for your product. From here you can begin linking the GPO to your OUs as needed. I would highly recommend using security filtering and/or a WMI filter to make sure the GPO is only applied to a few select test systems until you’ve gauged how the new settings will impact your environment.

To use my recent experience as an example, I created a security group in Active Directory named Windows Server 2012 GPO Testing, added a single test server to this group, and then added the group to my baseline GPO’s Security Filtering (make sure you also remove Authenticated Users). To be extra careful, I also created a new WMI filter to only return Windows Server 2012 R2 Member Servers and added this to my GPO as well. These help to ensure that my policy will only be applied to servers which are members of my security group, are running Windows Server 2012 R2,  and are not domain controllers, regardless of the OU that I link the policy to in my Active Directory structure.

If you want to create your own custom WMI filter, the process is very simple.

  1. Open the Group Policy Management console and expand Forest -> Domains -> MyDomain -> WMI Filters.
  2. Right-click the WMI Filter container and click New.
  3. Name the new filter appropriately. In my case, I named it Windows Server 2012 Member Server ONLY. Add a description to help others know exactly what your filter does.
  4. Click the Add button to create a new query.
  5. You can leave the namespace as root\CIMv2 and then enter your custom query. To find and return only Windows Server 2012 R2 Member Servers, I used the following query:

select * from Win32_OperatingSystem where Version like “6.3%” and ProductType=”3″

  1. When finished click Save.
  2. You can now use this filter for any GPO that you wish, simply by using the drop-down at the bottom of the Scope tab (same place where you set Security Filtering)


For some help creating your own WMI filters, check out the links below.

Create WMI Filters for the GPO

Operating System Version Numbers



Rebuild the Windows WMI Repository

For my first technical post, I’ll try to keep things relatively quick and simple.

Rebuilding the WMI Repository is something that’s pretty well documented in various outlets, including Technet, but it’s been so useful to myself and many of my colleagues that I’d like to share it here.

As mentioned in the linked article: “The WMI Repository “%windir%System32\Wbem\Repository” is the database that stores meta-information and definitions for WMI classes; in some cases the repository also stores static class data as well. If the Repository becomes corrupted, then the WMI service will not be able to function correctly.”

In my personal experience, rebuilding the WMI repository has come in most handy when repairing the SCCM 2007 client after it stops working properly on Windows 7 systems, so if you’re an SCCM Admin and can’t figure out why some of your clients aren’t receiving advertisements, consider giving this a try. I imagine this could also be useful when troubleshooting issues for almost any application or service that relies on WMI. However, please keep in mind that this is generally recommended AS A LAST RESORT because, again from said article, “Deleting and rebuilding the repository can cause damage to the system or to installed applications”, so proceed with caution.

To repair the local WMI repository in Windows:

  1. Open an elevated command prompt
  2. Type net stop winmgmt and hit Enter. This stops the WMI service. (Side note: I’ve had instances where the WMI service is unable to stop after running this command. If this is the case, open the Services applet and set the Windows Management Instrumentation service Startup Type to Disabled and reboot the computer before proceeding)
  3. Use Windows Explorer to navigate to: %systemroot\system32\wbem
  4. Delete or rename the Repository folder (I usually like to add .old to the end of the folder name, so Repository.old)
  5. Return to the elevated command prompt and enter: net start winmgmt (Set the Startup Type back to Automatic for the WMI service first if you disabled it previously)
  6. Enter: cd /d %windir%\system32\wbem
  7. Re-register the dlls by entering: for %i in (*.dll) do RegSvr32 -s %i
  8. Reboot the system

These steps might differ a little bit from what you might find elsewhere, but this process has always worked well for me and my colleagues.

The Technet article that I referenced previously also lists some additional commands that you can run to verify and repair the WMI repository automatically on Windows Vista and above, but I haven’t tested them myself so I can’t vouch for their effectiveness. Those commands are:

  • winmgmt /verifyrepository  checks the WMI repository for consistency
  • Winmgmt /resetrepository – resets the WMI repository back to its initial state after the OS was first installed

So there you have it. This post didn’t turn out nearly as short and concise as I hoped, but this trick is something that I always keep well documented and close at hand, so I hope someone else is able to find it useful.