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 "<strong>SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > '7000'</strong>"}}
| select TotalMilliseconds

Execution Time of Popular WMI Queries

As the data in the table above shows, the execution 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%:

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:

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:

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.