LOGbinder Blog

Updates, Tips and News   RSS Feed  

«  | In-depth How To's for... »

Using Site-linked GPOs for Targeting Windows Event Collectors Prevents Forwarder Health Analysis

Wed, 22 Nov 2017 10:12:47 GMT

For the most part WEC allows you to control event forwarding from the collector but there is one setting in group policy: Group Policy Management Editor\Default Domain Policy\Computer Configuration\Policies\Administrative Templates\Windows Components\Event Forwarding\"Configure target Subscription Manager setting Enabled

This setting is like the bootstrapper for Windows Event Collection.  When computers out in the domain apply group policy and see this setting, they now know which collector(s) to start checking in with regularly to find new/updated subscriptions.

In larger environments with regional data centers we often setup local collectors so that we keep event forwarding traffic local – computer in a given region send events to the local collector.  That makes total sense but the possible problem arises with how you do this with group policy.

You may have Sites already defined in Active Directory that correspond to each region of computers and their local collector.  Active Directory allows you to assign GPOs to Sites and then each computer physically in that site will apply the policies in that GPO – a seemingly convenient way to configure computers based on their location. 

The problem arises when you try to assess the health of WEC subscriptions.  Before you can determine if all computers are actively forwarding events for a given subscription you need to know which computer should be sending events.  Supercharger’s Deterministic forwarder health analysis automates this process for you.  By default, when you specify Deterministic mode on a subscription, Supercharger looks at the groups assigned to that subscription, enumerate the computer accounts there-in and uses that as the baseline for the computers that should be sending events.  Then Supercharger compares that list to the list of computers WEC says are currently sending events.  (This is a simplified description, click here for more information). 

But sometimes we encounter environments where the customer has specified an all-encompassing group like Domain Computers which includes, well, all computers in the domain – probably many more times the number of computers in the region of that collector.  WEC doesn’t care: only those computers in that group which also apply the GPO pointing to a given collector will subscribe and start sending events.  But we obviously can’t use the group’s membership to perform health analysis.

For this reason, we added an alternative method to Deterministic health analysis that allows you to specify a custom LDAP filter.  This allows you to use most any attribute available on computer accounts to determine the baseline list of computers that should be sending events.  For instance, if your computer naming convention prefixes computers with region you could use that.  Or maybe department or description on the computer account provides the appropriate criteria – or a combination of fields.  The bottom line is you specify an ldap filter that produces the right set of computers for that collector and assign it to each subscription on the collector.

Here’s the gotcha – look at the attributes available on computer accounts in AD – there’s nothing for Site because it's not static.  Whenever a computer boots up it compares it's IP address to Site definitions in AD to determine which Site it's in.  So, you can't specify an LDAP filter where "site=Detroit" for example. 

If you want to use deterministic health analysis for accurate diagnosis of which computers are sending events and which ones where forwarding is broken for some reason you need an OU or some other criteria in AD that can be specified in an LDAP filter. 

If there’s no such data on your computer accounts you might consider creating a Startup script in the same GPO that causes each computer to update a selected attribute on its computer account in AD with its current site.  You’d need to make sure to delegate Write access that attribute on computer accounts.  The script would need to query Windows for its current site and then update the appropriate field on its computer account. 

Failing that, if you have a good idea of the number of computers that should be sending events you can use Arbitrary instead of Deterministic.  Or simply use Empirical instead of Deterministic.

 

Comments disabled

powered by Bloget™