How Group Policy Impacts Logon Performance #3: WMI Filters & ILT

This article is based on my Citrix Synergy 2015 session and is the third in a mini-series on Group Policy performance. All measurements by uberAgent on Windows Server 2012 R2 with Citrix XenApp 7.6 in a steady state. Please start reading with the first article.

Filtering

Group Policy offers four ways to control where the settings defined in a Group Policy Object (GPO) are applied:

  • Organizational units (OUs)
    • Group user/computer objects in OUs
    • Link GPOs to OUs
  • Security
    • Change GPO security so that the GPO applies to specific groups
    • Required permissions: read + apply group policy
    • Works not only for users, but also for computer accounts
  • WMI filters
    • Specify a WMI query
    • The GPO is applied only if the query returns true
    • Applies to entire GPOs
  • Item-level targeting (ILT)
    • Specify targeting criteria
    • A setting is applied only if the criteria match
    • Applies to individual settings (in case of registry settings: can also apply to a collection of settings)
    • Available for Group Policy Preferences (GPPs) only, not for Policies

Out of these four, two are interesting in terms of performance: WMI filters and item-level targeting. We are going to dedicate the rest of this article to them.

How to Measure WMI Query Performance

The execution time of WMI queries can be measured easily by executing the query through the PowerShell cmdlet Measure-Command. For increased accuracy we let the query run a thousand times. The command looks like this (the actual WMI query is bold):

Measure-Command
{for($i=0; $i -lt 1000; $i++)
{Get-WmiObject -query “SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > ‘7000’“}}
| select TotalMilliseconds

Execution Time of Popular WMI Queries

Query Execution (ms) Description
SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > ‘7000’ 17 Require at least Windows 7
SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = ’64-Bit’ 18 Require 64-bit Windows
SELECT * FROM Win32_Keyboard WHERE Layout = ‘00000407’ 8 Require German keyboard layout
SELECT * FROM Win32_ComputerSystem WHERE Name LIKE ‘vpc-%’ 7 Computername starts with a certain prefix
SELECT * FROM Win32_Product where Name like ‘%Adobe Reader%'” 11740 Require Adobe Reader to be installed

As the data in the table above shows, the exuction time of WMI queries is not so bad: 10-20 ms per GPO (remember: WMI filters apply to an entire GPO) typically do not significantly delay logon duration. However, there are exceptions. Most notorious is the Win32_Product WMI class. In a nutshell, do not use it unless you do not care about performance at all.

WMI Query Optimization

A not so well-known optimization is ask WMI for one specific attribute only instead of requesting all fields a class can store. In other words: replace the wildcard with an attribute that is guaranteed to have a value. With that small change the execution times for most queries drop by approximately 50%:

Query Execution (ms) Description
SELECT BuildNumber FROM Win32_OperatingSystem WHERE BuildNumber > ‘7000’ 9 Require at least Windows 7
SELECT OSArchitecture FROM Win32_OperatingSystem WHERE OSArchitecture = ’64-Bit’ 8 Require 64-bit Windows
SELECT Layout FROM Win32_Keyboard WHERE Layout = ‘00000407’ 8 Require German keyboard layout
SELECT Name FROM Win32_ComputerSystem WHERE Name LIKE ‘vpc-%’ 4 Computername starts with a certain prefix
SELECT Name FROM Win32_Product where Name like ‘%Adobe Reader%'” 11640 Require Adobe Reader to be installed

Performance Impact of WMI Filters

To evaluate which impact WMI filters have on Group Policy processing performance I created 100 GPOs with a single GPP registry value each. Then I compared:

  • No WMI filter
  • WMI filter on each GPO, returning true (I used the filter “SELECT Name FROM Win32_ComputerSystem WHERE Name LIKE ‘Citrix-%’
    “)

The result:

Group Policy - WMI filter performance

As you can see in the graph above adding a WMI filter to a GPO prolongs processing time for that GPO by about 9 ms. That is more or less the execution time of the WMI query we determined earlier. This tells us two things:

  1. You can gauge the overhead a WMI filter adds to your GPO processing time by timing the filter’s query independently with PowerShell
  2. WMI filter performance is much better than commonly believed

Item-Level Targeting

Item-level targeting (ILT), available for Group Policy Preferences only, can be used to reduce the number of GPOs by combining settings for different sets of users and different types of machines.

A Microsoft blog article says ILT is not inherently harmful and recommends not to run the following ILT evaluations that must work over the network against Active Directory to be evaluated:

  • OU
  • LDAP query
  • Domain
  • Site

Computer security group membership evaluation, however, is fast. Make sure to have installed KB2561285 on Windows Vista and Windows 7, though.

Grouping

ILT comes with an unnecessary architectural limitation: if you have a GPO with many settings with identical ILT filters, that one filter is run once per setting. The engine is not clever enough to realize that it already knows the answer from the previously applied setting. It would be nice to be able to apply ILT filters to groups of settings. That is possible (groups are called collections), but unfortunately only for registry values.

Performance Impact of Item-Level Targeting

To evaluate which impact GPP item-level targeting has on Group Policy processing performance I created 1 GPO with 100 GPP environment settings. Then I compared:

  • No ILT
  • ILT for computer name on each setting
    “)

The result:

Group Policy - item-level targeting performance

The overhead per ILT filter is small: only 2 ms in my test lab. But keep in mind that ILT filters are applied per setting. If you have many settings, you may have many ILT filters, too.

WMI Filters vs. Item-Level Targeting

Execution times for the actual filter queries are not too far apart. However, WMI filters are invoked only once per GPO while item-level targeting may be invoked many times per GPO (increasing total runtime).

WMI filters are stored in Active Directory while ILT filters are stored as files in SYSVOL. If a WMI filter returns false the GPO’s CSE settings files need not be fetched. In order to run ILT filters all CSE settings files need to be fetched because the filters are defined in them.

Continue reading with part 4 of this series.

,

5 Responses to How Group Policy Impacts Logon Performance #3: WMI Filters & ILT

  1. Peter van der Laarse January 19, 2016 at 20:23 #

    Interesting posts. Thank you for that.
    1 Question. What is your opinion about the combination of a Roaming user profile folder, a Home folder with offline files enabled, Folder redirection to the home folder. Both the profile folder and Home folder are on a DFS namespace. In the AD user object the profile and home path are \\domain\dfsdata\profiles\%username% and \\domain\dfsdata\Home\%username%.
    We experience issues on slow links like WiFi.

    Regards,
    Peter

    • Helge Klein January 19, 2016 at 23:17 #

      I am not exactly a big fan of Offline Files (see my related articles). I have found them to be unreliable. Even worse: when you have a problem not even Microsoft can help you, because they do not really understand it either. My recommendation: stay away from Offline Files.
      As to roaming profiles and folder redirection: they have their individual merits and problems, but at least they are stable.

      • Peter van der Laarse January 20, 2016 at 14:01 #

        I read your blog “Windows Offline Files Survival Guide”. The DFS design flaw section. http://blogs.technet.com/b/askds/archive/2011/12/14/slow-link-with-windows-7-and-dfs-namespaces.aspx
        The question is if dfs namespace is the right location for the user profile”and the homeshare when working on a slow network like Wifi.

        If the latency is to slow, can this result in a long “waiting for the user profile service” because the DFS location in not available yet?
        We see this behaviour also with 2 other DFS share which are mapped to drive letters L and X during logon. After logon those drives apear with a red cross. After a while I can open the drives.
        I can imagine that the same behaviour happens when you logon on a slow link and the DFS profile and home share are not available.

        Besides that, our homeshare is also Offline available and contains the redirected folders.

    • Dennis December 14, 2016 at 10:18 #

      Make sure you use FQDN (\\domain.com\dfsdata\profiles\%username%) if using roaming profiles, folder redirections, offline folders and such.

  2. Harold January 21, 2016 at 14:27 #

    Microsoft has stated several times not to use WIn32_products for WMI filters:
    http://blogs.technet.com/b/askds/archive/2012/04/19/how-to-not-use-win32-product-in-group-policy-filtering.aspx
    http://support.microsoft.com/kb/974524

Leave a Reply to Peter van der Laarse Click here to cancel reply.