So I'm on my windows.
Client that I've been using to process group policy.
And I'm going to go ahead and bring up the event viewer.
So I got a little shortcut here to get to the event viewer just by typing event viewer And if I expand
the Windows Logs, I can look at the system and application logs and see what group policy gives me
here.
What you'll notice when I click on the system log is that immediately in the right, near the top,
I've got a couple of events that show an event source of group policy.
And the first one tells me that this client was unable to apply folder redirection because the user
must be processed by the user.
Log on.
So essentially it's telling me what I had previously reported through.
RCMP has been surfaced as kind of a general high level event with a source of group policy in the system
log.
And then it tells me that the settings for my user were processed successfully and that new settings
from nine group policy objects were detected and applied.
So it's kind of giving the, again, high level status to tell me, hey, group policy worked when my
user account processed at the last time.
If I go into the application event log, you'll see that I get more client side specific errors or information.
So in this case, folder redirection tells me that it's been delayed until the next log on because group
policy log on optimization is in effect.
This is a fancy way of saying that that I'm set to do asynchronous foreground processing and folder
redirection needs a synchronous foreground cycle.
So it's basically waiting for that next log on to make it's to make itself known to me.
This event right above it.
SCC ally I happen to know is the client side extension for security policy and it's just giving me a
general message that security policy has processed successfully for this particular computer or user.
Now these are useful logs to have because in the case of, for example, security policy, if it doesn't
work successfully, it's going to throw an error message and it's going to give me some information
about why it didn't work.
So that's been helpful in the past I found for troubleshooting.
So if you think about it this way, the application event log has a lot of the client side expanse,
client side extension.
General lag information in it.
The system log has sort of that roll up for the whole group policy cycle.
And then if we go down under applications and services logs.
Microsoft Windows.
And scroll down here until we get to the GSA screw policy operational.
There's the operational log.
And it's telling me in reverse time order what's happened step by step during group policy processing
on this machine.
So as an example.
Here we go.
I've got.
The last event shows that the next policy processing for my account will be attempted in 95 minutes.
So this is that random background interval.
It's telling me exactly when it's going to be executed, which is nice information to have.
And if I step back through the operational log you'll see I have.
Telling me that it completed policy processing for my user account in 1/2 and it tells me how long each
client side extension took.
So it's giving me a lot of the same information I got from the RCMP data, but it's giving me an event
by event detail in a lot of detail.
So really useful for kind of walking through and seeing what's going on on a step by step basis with
group policy processing on this system.
And really, I think this is the as I mentioned, you start off with the RCMP data and if it can't point
the way, then the event logs are the next best thing in terms of trying to solve the problem.
The final step, which is definitely more of an advanced step, but I am going to cover it a little
bit here is using trace logging to figure out what's going on.
So let's go ahead and dive into trace logging a little bit and I'll tell you where it comes in handy
and the kinds of information that it provides.