What’s not to love about Group Policy! It can configure printers, set permissions, and deploy software. What can’t it do? To start, Central Reporting like SCCM….
In most environments, we don’t need pretty pie graphs like those above (if anything, we just need more pies). What is needed is a simple method of seeing when a GPO is not applying correctly. This method should let you see if the issue is with multiple machines or just a single device. What follows below, while very rudimentary, is the poor man’s central group policy monitoring tool.
Deciding What to Monitor
We all know that Group Policy processing can be broken down into specific chunks called Client Side Extensions (CSEs).When a specific CSE fails, a warning is normally written to the event log. As an example, Group Policy Printers will record its warnings under Event ID 4098. In fact, every Group Policy Preference will record it’s warning under event ID 4098. If you looked under the Application event log, you might see something like this:
Now that you know where to look for common errors, you will want to keep a list of CSEs to monitor. In our environment, application installs, Printers, and Drive Mappings are the most important items that we control with Group Policy. Because of this, I monitor just these CSEs.
Creating the Group Policy Objects
Create a new GPO named Event Forward: CSE Errors. Because you may extend the Event Forwarding concept to include other issues (like NetLogon Errors and BSODs), it is important to add an accurate suffix (like CSE Errors).
Edit the GPO and create a new scheduled task. Do this under Computer Configuration/Preferences/Control Panel Settings/Scheduled Tasks. This first scheduled task will monitor errors related to Group Policy Software Installation. Name it GPSI Failed Event ID.
For the user account, use a domain account that has the ability to log on as a batch job. This setting can be configured at Computer Configuration/Policies/Windows Settings/Local Policies/User Rights Assignment. For simplicity, I stick this setting within my Event Forward GPO.
Defining Your Triggers
There are 9 specific events that to monitor if you are concerned about GPSI errors. To get started, select the Triggers tab on your scheduled tasks and select New. Under Begin the Task, change from On a Schedule to On an Event.
For the Log, choose System and select Application Management Group Policy as the Source. Finally, set the Event ID at 101. Create 8 more triggers and increment the Event ID up by 1. Your final trigger should look for Event ID 109. Here is what your final triggers list should look like:
Ready? Set? Action!
Under Actions, select New and change the Action type to Send an e-mail. As a note, this feature is deprecated on Windows 8 and has been supplemented by the send-mailmessage PowerShell cmdlet. For an example of the cmdlet, see this article.
Specify a From and To Email. In our organization, we have a dedicated alert email account for these situations. Set the subject to GPSI Failure: %ComputerName% . Finally, set the text to eventvwr %COMPUTERNAME% /c:”System” . Specify your SMTP server and press OK.
Finally, head to the Settings tab and check “Allow task to be run on demand.”
What’s the End Result?
After linking the GPO and letting your machine perform a background GPUpdate, you should start receiving email alerts if an error occurs. These alerts will specify the Group Policy issue and the computer name. You can test your scheduled tasks by adding a trigger for a normal event.
To stop your Inbox from being flooded, you can create a rule in Outlook to move these messages to another folder. Whenever you make a Group Policy Software Installation change, you will receive email alerts if the application failed to install. By copying the subject, you can view the specific events in Event Viewer. Now just use this GPSI troubleshooting guide to fix the problem!