1

Currently we have several GPOs linked on top of 200+ computer objects, which are getting filtered via WMI (query for operating system).

There seems to be some kind of race condition, as this GPOs sometimes get applied and sometimes they dont.

Anyway... we could trace this back to WMI instabilities why I would like to switch to Security filtering based on AD groups (ServerW2012, ServerW2008 and so on).

My migration path looks as follows:

1) Create AD groups and add computer objects accordingly

2) Add AD groups to ACLs of respective GPOs and remove "Authenticated Users"

3) Remove WMI Filter

The GPOs are making use of several CSEs, synchronous/asynchrous, Securits CSE, and so on. I am concerned about stability, because if this change goes wrong 200+ computer objects would be affected.

Is this a feasible migration path? Any experiences to share? Thanks

Matthias Güntert
  • 2,358
  • 11
  • 38
  • 58
  • What are these WMI instabilities you speak of? I'd be more interested in fixing that than having to manage security groups for something WMI filtering was designed to do. If WMI is broke, you're going to have bigger issues than just group policy processing. – twconnell Jun 13 '17 at 19:32
  • The defined WMI query reads the content of a system environment variable which sometimes seems be ready to read (API) and sometimes not. This results in wired behaviour like GPO gets applied but not _all_ of the content of the GPO... specifically settings handled by the security CSE. – Matthias Güntert Jun 13 '17 at 19:37
  • In general I agree to your approach, but too much time has already been lost to no avail. – Matthias Güntert Jun 13 '17 at 19:39
  • It sounds like your WMI filter may be the issue. Can you provide an example? The most common way to filter by OS is to select the ProductType out of the Win32_OperatingSystem WMI class. There should never be a race condition with this method. If there is, I need to know about it. See this [List of OS Version Queries for WMI Filters](http://www.nogeekleftbehind.com/2016/01/19/os-version-queries-for-wmi-filters/) for some examples. – twconnell Jun 13 '17 at 20:23
  • 1
    Just remember to allow domain computers or auth. users to read the GPOs in delegation tab. There was some patch a while back that used that as a determination on who can read the GPOs (and therefore apply them). By default the security groups assigned (with security filtering) are delegated read access. – Ijustpressbuttons Jun 13 '17 at 21:01
  • @twconnell the first one is `select * from Win32_Environment WHERE Name="SYSTYPE" and variablevalue="CORP-VM"` and the second one in the same query `select * from Win32_OperatingSystem WHERE Version LIKE "6.3%" and ProductType="3"` – Matthias Güntert Jun 14 '17 at 06:30
  • To be clear, both of these wmi filters are set on the same problem GPO? Like you said, only the environment variable filter is the issue, so perhaps there is another way to identify the CORP-VM servers. In this case, security group filtering could do the trick. Policies that are using the Win32_OperatingSystem WMI class filter, and no other filters, should not be experiencing the race condition issue. – twconnell Jun 14 '17 at 06:58

1 Answers1

1

  1. Create AD groups and add computer objects accordingly.

  2. Add AD groups to ACLs of respective GPOs and remove "Authenticated Users" Apply Group Policy permission.

  3. The computers would need to be restarted or klist purge run to refresh the computer group memberships.

Is there a way to refresh computer group membership without rebooting?

  1. Link new group policy.

  2. Remove WMI Filter.

Greg Askew
  • 34,339
  • 3
  • 52
  • 81
  • Thanks for your reply. You are basically repeating my before mentioned migration path. I was hoping to get an answer regarding experiences. After some thinking I came to the conclusion the risk is to high and I am going to make copys of the GPOs having set a WMI filter, add the AD groups to the ACLs, exclude this group from the original ones, and then move the computer objects piece by piece into the new "structure".. I can't risk any unplaned outage – Matthias Güntert Jun 13 '17 at 19:42