Group Policy

Using Group Policy Preferences with Older Versions of Windows was doing some testing with a newly created GPO that used Group Policy Preferences (GPP) to add a user account to the local administrators group, and I noticed that the policy seemed to apply properly to all of my Server 2012 and 2008 systems but not on any Server 2003 machines.

I did some research and came across an article on Microsoft’s Group Policy blog that shined some light on my issue:

Group Policy Preferences Not Applying on Some Clients: Client-Side Extension, XMLLite

The gist of it is that I needed to install the proper Client-Side  Extensions (CSEs) for Server 2003. All of the links for the individual OSes and versions are in the MS blog post, but the specific one I needed is below.

CSEs for Windows Server 2003 with SP1 or later (32-bit)

You may also need to install XMLLite in addition to the CSEs, but to quote the post:

“XMLLite is not needed if:

· Your clients run Windows Server 2008 or Windows Vista.

· Your clients Windows XP and Windows Server 2003 clients run Internet Explorer 7 and/or the latest service packs.”

After installing the CSEs on my machines, they started processing the GPPs normally.

Drop Down

As a side-note for anyone interested; The GPP to add user accounts to local groups is located under Computer Configuration -> Preferences -> Control Panel Settings -> Local Users and Groups.

To modify a local group, right-click and select New – > Local Group, choose Update as the action, pick a group from the Group Name drop down menu, in my case Administrators (built-in) (make sure to use the drop down and not the ellipses button; see image), and then use the Add button at the bottom of the window to add either local or domain accounts to that group.

Most of the guides I’ve found suggest using Computer Configuration\Policies\Windows Settings\Security Settings\Restricted Groups to add users to the local administrators group, but this policy acts to replace any existing memberships rather than merge with them, so keep this in mind if you have Group Policy Objects linked at higher OUs which add users to the same groups. If you want to preserve the existing memberships, consider using GPPs to make the modifications instead.


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


WSUS Best Practices

Here’s a very good blog post I came across with some WSUS best practices for anyone else looking to implement WSUS for the first time or review your patching strategies.

Some highlights:

Consultants should take time to test the patches in a non-production environment prior to being deployed to production. This will help to gauge the impact of such changes. Ideally you will have the following patching groups:

1. UAT (UAT1, UAT2, etc)

2. Test Environment (Test1, Test2, etc)

3. Development Environment (Dev1, Dev2 etc)

4. Production (Prod1, Prod2, etc)

If you have clustered environment like SQL, Exchange and SharePoint then create Prod1, prod2 group and place each node on each group. “

System administrators should maintain a log, written or electronic, of all changes to the operating environment, to include hardware, system security software, operating system, and applications. Prior to any changes being implemented on a system, the system administrator should receive approval of stakeholders.”

A scheduled maintenance window must be agreed with business so that application outage and server reboot can maintain a respectable Service Level Agreement (SLA). If you have a large infrastructure with thousands of servers and many regions working round the clock then you must consider application dependencies. A patching schedule can be considered in between every Friday of every month at 6:00 P.M. Friday to 6:00 A.M Monday. Setup maintenance window in system center or deadline for WSUS to make sure patches are applied when you want instead of when patch is available. In this way you will have a complete control over change windows approved by change advisory board (CAB). Do not allow end users to update patches on their client machine according to their wishes and happiness! then user will never install any patch. “

Microsoft strongly recommends that you create the following backups before you install an update rollup, service pack and patch on Exchange and SQL:

  • A full backup of all databases on the server.
  • A full backup of transaction log and log backup
  • A system state backup of the server.
  • A snapshot of virtualized exchange server. Delete snapshot after successful patching and updating. “

Here are some other useful resources for WSUS:

WSUS Role Installation Fails on Windows Server 2012 R2

I was attempting to add the WSUS role on a Windows Server 2012 R2 system earlier this week and I ran into this error during the installation.

“The request to add or remove features on the specified server failed. the operation cannot be completed because the server that you specified requires a restart.”

After several subsequent reboots and attempts to add the role I continued receiving this same error, so I started doing some research. I got several hits and this appears to be a fairly common issue with Server 2012, specifically when choosing to use the Windows Internal Database (WID).

The issue is that WID relies on the NT SERVICE\MSSQL$MICROSOFT##WID account to start the service, and this account must have Log on as a service rights on the system.

Generally I don’t think this would be an issue, and if it is you should be able to simply use the local Group Policy editor (gpedit.msc) or a domain GPO to grant this account Log on as a service rights by using the following policy setting:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service

Open the Log on as a service setting, check the box to Define these policy settings, and then add NT SERVICE\MSSQL$MICROSOFT##WID

However, to maintain security compliance as we move to Server 2012 R2, a domain Group Policy was recently created using Microsoft’s Security Compliance Manager (I may write a separate post on SCM later) and applied. As part of the Windows Server 2012 Security Baseline, Microsoft adds NT SERVICE\ALL SERVICES to the Deny log on as a service security policy. So because ALL SERVICES is being denied, even after adding MSSQL$MICROSOFT##WID to the Allow log on as a service policy locally, the WSUS role still failed to install for me.

To finally get the WSUS role installation to complete, I had to modify this new domain Group Policy and remove the ALL SERVICES account from the Deny log on as a service policy first, then add NT SERVICE\MSSQL$MICROSOFT##WID to the Log on as a service policy setting locally on the server.

For some more details and a few screenshots of the initial troubleshooting and resolution to this issue, check out one of the blog posts that I came across during my research. WSUS Role failed on Windows server 2012 with error…

You may notice that the blog I linked as well as many others I came across recommend just adding NT SERVICE\ALL SERVICES to the Log on as a service setting. Since Microsoft’s baseline security settings for Server 212 specifically DENIES log on as a service access to ALL SERVICES, I opted to only add the account explicitly required by WID to avoid opening up any more security vulnerabilities than I had to.

I’ll need to go back and take another look at our Server 2012 security policy to see if there’s another way around this while still denying log on as a service access to unneeded service accounts. I guess the easiest (and maybe best) thing to do would be to avoid using WID all-together and instead use a SQL Server instance.

That also leads me to another interesting topic that I’ll probably write another post about down the road. I’m installing WSUS with WID for now for the sake of time, but I may migrate it over to a SQL Server once I can. For a preview of that job, check out Migrate Windows Internal Database to SQL Server.

Links in this post:



Recreate the Local Group Policy Cache in Windows

Happy Monday!

This is something I ran into a while back and has come in handy on several occasions.

For those who may be unaware (as I was before stumbling upon this trick), Windows maintains a local cache of all the group policy settings that are applied to that particular system. This cache can occasionally become corrupt or de-synchronized with the domain controller, which can cause a variety of issues including failure to apply new group policy settings or changes to existing policies.  When this occurs, the quickest and easiest way that I’ve found to correct it is to clear and recreate this local cache.

To clear the local GPO cache, make sure you can view hidden files and folders and perform the following:

  1. Browse to C:\ProgramData\Microsoft\Group Policy\History (Windows 7 / Server 2008)
  2. Delete all of the contents under the History folder
  3. Open the command prompt and run GPUpdate /force
  4. Reboot the system

I initially came across this while troubleshooting a Windows 7 client that was flat out refusing to apply new Group Policy settings. After ruling out the new GPO itself by checking it for content errors, verifying that it was linked up to the proper OU in Active Directory,  the link order was correct, and security filtering properly configured, I turned to the client for additional troubleshooting. A GPResult confirmed that the new GPO wasn’t being read and, other than some generic group policy errors, the Event Logs proved inconclusive. So I eventually turned to the web and come across this article on the Windows Server TechNet forums where someone mentioned attempting to clear the local GPO cache, which worked like a charm.