1
00:00:03,090 --> 00:00:04,380
So I'm on my windows.

2
00:00:04,380 --> 00:00:07,340
Client that I've been using to process group policy.

3
00:00:08,280 --> 00:00:11,430
And I'm going to go ahead and bring up the event viewer.

4
00:00:12,460 --> 00:00:18,130
So I got a little shortcut here to get to the event viewer just by typing event viewer And if I expand

5
00:00:18,130 --> 00:00:23,680
the Windows Logs, I can look at the system and application logs and see what group policy gives me

6
00:00:23,710 --> 00:00:24,040
here.

7
00:00:25,010 --> 00:00:29,720
What you'll notice when I click on the system log is that immediately in the right, near the top,

8
00:00:29,930 --> 00:00:33,530
I've got a couple of events that show an event source of group policy.

9
00:00:34,480 --> 00:00:40,270
And the first one tells me that this client was unable to apply folder redirection because the user

10
00:00:40,270 --> 00:00:42,040
must be processed by the user.

11
00:00:42,040 --> 00:00:42,700
Log on.

12
00:00:43,670 --> 00:00:47,330
So essentially it's telling me what I had previously reported through.

13
00:00:47,330 --> 00:00:53,240
RCMP has been surfaced as kind of a general high level event with a source of group policy in the system

14
00:00:53,240 --> 00:00:53,660
log.

15
00:00:54,550 --> 00:00:59,710
And then it tells me that the settings for my user were processed successfully and that new settings

16
00:00:59,710 --> 00:01:03,070
from nine group policy objects were detected and applied.

17
00:01:04,040 --> 00:01:09,290
So it's kind of giving the, again, high level status to tell me, hey, group policy worked when my

18
00:01:09,290 --> 00:01:11,660
user account processed at the last time.

19
00:01:12,560 --> 00:01:19,370
If I go into the application event log, you'll see that I get more client side specific errors or information.

20
00:01:20,340 --> 00:01:25,950
So in this case, folder redirection tells me that it's been delayed until the next log on because group

21
00:01:25,950 --> 00:01:28,800
policy log on optimization is in effect.

22
00:01:29,800 --> 00:01:35,530
This is a fancy way of saying that that I'm set to do asynchronous foreground processing and folder

23
00:01:35,530 --> 00:01:38,440
redirection needs a synchronous foreground cycle.

24
00:01:39,420 --> 00:01:44,280
So it's basically waiting for that next log on to make it's to make itself known to me.

25
00:01:45,260 --> 00:01:46,610
This event right above it.

26
00:01:46,610 --> 00:01:52,790
SCC ally I happen to know is the client side extension for security policy and it's just giving me a

27
00:01:52,790 --> 00:01:58,760
general message that security policy has processed successfully for this particular computer or user.

28
00:01:59,730 --> 00:02:06,060
Now these are useful logs to have because in the case of, for example, security policy, if it doesn't

29
00:02:06,060 --> 00:02:10,920
work successfully, it's going to throw an error message and it's going to give me some information

30
00:02:10,920 --> 00:02:12,210
about why it didn't work.

31
00:02:13,210 --> 00:02:17,290
So that's been helpful in the past I found for troubleshooting.

32
00:02:18,190 --> 00:02:23,710
So if you think about it this way, the application event log has a lot of the client side expanse,

33
00:02:23,860 --> 00:02:25,330
client side extension.

34
00:02:26,320 --> 00:02:28,330
General lag information in it.

35
00:02:29,330 --> 00:02:33,650
The system log has sort of that roll up for the whole group policy cycle.

36
00:02:34,610 --> 00:02:38,240
And then if we go down under applications and services logs.

37
00:02:38,240 --> 00:02:39,560
Microsoft Windows.

38
00:02:40,520 --> 00:02:44,990
And scroll down here until we get to the GSA screw policy operational.

39
00:02:45,970 --> 00:02:47,920
There's the operational log.

40
00:02:48,830 --> 00:02:54,590
And it's telling me in reverse time order what's happened step by step during group policy processing

41
00:02:54,590 --> 00:02:55,490
on this machine.

42
00:02:56,470 --> 00:02:58,140
So as an example.

43
00:02:58,150 --> 00:02:59,020
Here we go.

44
00:02:59,050 --> 00:02:59,740
I've got.

45
00:03:00,710 --> 00:03:06,980
The last event shows that the next policy processing for my account will be attempted in 95 minutes.

46
00:03:07,980 --> 00:03:10,670
So this is that random background interval.

47
00:03:11,640 --> 00:03:16,950
It's telling me exactly when it's going to be executed, which is nice information to have.

48
00:03:17,900 --> 00:03:21,480
And if I step back through the operational log you'll see I have.

49
00:03:21,500 --> 00:03:27,440
Telling me that it completed policy processing for my user account in 1/2 and it tells me how long each

50
00:03:27,440 --> 00:03:29,120
client side extension took.

51
00:03:30,120 --> 00:03:35,760
So it's giving me a lot of the same information I got from the RCMP data, but it's giving me an event

52
00:03:35,760 --> 00:03:38,220
by event detail in a lot of detail.

53
00:03:39,180 --> 00:03:44,670
So really useful for kind of walking through and seeing what's going on on a step by step basis with

54
00:03:44,670 --> 00:03:47,040
group policy processing on this system.

55
00:03:47,960 --> 00:03:53,930
And really, I think this is the as I mentioned, you start off with the RCMP data and if it can't point

56
00:03:53,930 --> 00:03:58,790
the way, then the event logs are the next best thing in terms of trying to solve the problem.

57
00:03:59,710 --> 00:04:04,750
The final step, which is definitely more of an advanced step, but I am going to cover it a little

58
00:04:04,750 --> 00:04:08,470
bit here is using trace logging to figure out what's going on.

59
00:04:09,440 --> 00:04:14,780
So let's go ahead and dive into trace logging a little bit and I'll tell you where it comes in handy

60
00:04:14,780 --> 00:04:17,120
and the kinds of information that it provides.