[gptalk] Re: Understanding GP Processing

Hi John,

 

On the first question of reprocessing policies, there are two parts to Group
Policy processing. The first involves finding out what policies need to be
processed, the second is the actual work of applying the policies. The first
part always occurs. This involves:-

            1. Identifying all of the policies connected to the user's OU"s

            2. Identifying Filtering via security

            3. Processing any WMI filtering

 

This then gives a list of Policies that should be applied, plus the order
they will be applied.

 

It then goes through each CSE and processes these policies. i.e. Registry
Processing will decide whether the list of Policies (or their contents) has
changed and whether the "Process even if the Group Policy Objects have not
changed" Policy is set. If there has been no change to the list (or
contents) of policies and "Process even if the Group Policy Objects have not
changed" hasn't been set, it will not actually apply the Registry settings.
Note: There is a different policy setting for each Component of Group
Policy. 

 

So, you can see there will always be some processing of policies, but less
if there is no change to the list of policies applied.

 

If you are concerned about the overhead of policy processing, I think you
should extend the policy refresh time which defaults to around 90 minutes. I
consider this a relatively short time. If you extend it to 12 hours, the
advantage is that Group Policy processing will occur at logon and then at 12
hour intervals thereafter. So a user will have at most one GP processing
cycle per working day. The downside is that if you change a policy, it will
take up to 12 hours for logged on users to get the change. Generally this is
quite acceptable since Group Policy changes would normally not be an
emergency change and would normally be done overnight.

 

I also have concerns about not setting the "Process even if the Group Policy
Objects have not changed" policy, especially if you have local admins on the
workstations. If they inadvertently (or deliberately) override a policy
setting, it will stay wrong until the list of policies being applied (or
their contents) change. I would prefer to wear the hit of reapplying
Registry policies every time than have the situation that you can not
guarantee that policies are in place. The additional overhead can be offset
by increasing the reprocess time to 12 hours.

 

I am not sure if you have seen my free software on the net for looking at
the UserEnv log. http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml>
&f=pol_summary.shtml It makes it more intelligible by splitting the log into
its constituent parts and highlighting the time taken for each component.
You can check this out on your machines to see the time taken to actually
apply the Registry settings. You will normally find this is small compared
to the total time.

 

On the second question, I am not sure what you mean by a System restart. If
you reboot the client, machine Group policy reoccurs. When the user logs on,
User policy processing occurs. If you are talking about rebooting a server,
this has no effect on Group Policy Processing on client workstations.

 

On the third question... What is the next message that pops up in the
UserEnv Log? ! Think it relates to resolving which OU the user belongs to.
This obviously requires talking to a Domain controller which requires full
network connectivity established. It may be worth doing a GPUPDATE when the
user is fully logged on and see whether it is faster second time around. 

 

Alan Cuthbertson

 

 

 Policy Management Software:-

http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=pol_summary.shtml>
&f=pol_summary.shtml

 

ADM Template Editor:-

http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=adm_summary.shtml>
&f=adm_summary.shtml

 

Policy Log Reporter(Free)

http://www.sysprosoft.com/index.php?ref=activedir
<http://www.sysprosoft.com/index.php?ref=activedir&f=policyreporter.shtml>
&f=policyreporter.shtml

 

 

         

 

-----Original Message-----
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of John Bateman
Sent: Monday, 16 June 2008 12:23 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Understanding GP Processing

 

Thanks Darren.  I knew that log existed I'd just forgotten about it :P

 

One thing I'd like to clarify however is related to foreground/background

policy processing. I was reading this page

(http://www.gpoguy.com/FAQs/Foreground-Background.htm) and have a few

questions:

 

1. When a user logs on for the first time it will always be slower as it

pulls down user policy and applies it. Subsequent logoff/logon of the same

user (assuming a static environment barring any changes in group

policy/group membership/WMI filters) will generally be faster as policy will

not be processed correct? Is there a limit for this? Assume no changes to

any of the above for months will policy totally process again unless invoked

via gpupdate?

 

2. Does a system restart force foreground user processing on the particular

client?

 

3. Back to the userenv.log. I am seeing a large gap (20+secs) between "Fast

link. Exiting" (PingComputer) and the first ProcessGPOs subroutine. This is

on a notebook. Could network drivers cause this? I also see quite a few

libmain routine starting (Anti-Virus, WMI). Could this also cause delays in

gp processing?

 

Cheers

 

-----Original Message-----

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On

Behalf Of Darren Mar-Elia

Sent: Wednesday, 11 June 2008 12:24 AM

To: gptalk@xxxxxxxxxxxxx

Subject: [gptalk] Re: Understanding GP Processing

 

John-

20 seconds is not unheard of for something like IE maintenance. You can

actually drill into the time taken within IE maintenance further by using

its trace log, which you should find for a given user under

%userprofile%\Application Data\Microsoft\Internet Explorer\brndlog.txt.

 

That file should show exactly what is happening during IE Maintenance

processing.

 

As for the other error, that looks very much like a DNS issue, where the

correct DNS names are not being found and the machine is defaulting to NTLM

authentication. Does this happen on more than one client ? If so, then I

would suspect DNS on the server side. If not, then something with this

client. Maybe run DCDiag from the client and see if it shows any issues. Or

try using netdom to test the client's secure channel connection to the

domain. Maybe you just need to re-join the machine to the domain.

 

Darren

 

 

-----Original Message-----

From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On

Behalf Of John Bateman

Sent: Tuesday, June 10, 2008 6:50 AM

To: gptalk@xxxxxxxxxxxxx

Subject: [gptalk] Understanding GP Processing

 

Hi,

 

As some of you may know I've been posting a lot lately, mostly in relation

to login times. I've been examining the userenv.log and am trying to

understand why certain extensions take longer to process. I am also seeing a

few errors which I'm not sure are causing an issue, are normal or maybe to

blame for the longer processing times. For instance here is part of a log:

 

USERENV(50c.bac) 08:55:35:513 ProcessGPOs: Processing extension Internet

Explorer Branding

USERENV(50c.bac) 08:55:35:513 ReadStatus: Read Extension's Previous status

successfully.

USERENV(50c.bac) 08:55:35:513 CompareGPOLists:  The lists are the same.

USERENV(50c.bac) 08:55:35:513 ProcessGPOList: Entering for extension

Internet Explorer Branding

USERENV(50c.bac) 08:55:35:513 UserPolicyCallback: Setting status UI to

Applying Internet Explorer Branding policy...

USERENV(50c.bac) 08:55:35:528 LogExtSessionStatus: Successfully logged

Extension Session data

USERENV(50c.bac) 08:55:40:787 ImpersonateUser: Failed to impersonate user

with 5.

USERENV(50c.bac) 08:55:40:787 GetUserNameAndDomain Failed to impersonate

user

USERENV(50c.bac) 08:55:40:803 GetUserDNSDomainName:  Domain name is NT

Authority.  No DNS domain name available.

USERENV(50c.acc) 08:55:41:394 PolicyChangedThread: Leaving

USERENV(50c.bac) 08:55:42:576 ImpersonateUser: Failed to impersonate user

with 5.

USERENV(50c.bac) 08:55:42:576 GetUserNameAndDomain Failed to impersonate

user

USERENV(50c.bac) 08:55:42:576 GetUserDNSDomainName:  Domain name is NT

Authority.  No DNS domain name available.

USERENV(330.4ec) 08:55:46:502 LibMain: Process Name:

C:\WINDOWS\system32\rundll32.exe

USERENV(654.674) 08:55:48:048 LibMain: Process Name:  C:\Program

Files\Novadigm\AXF\Bin\XFSrvcNT.Exe

USERENV(3e0.6e8) 08:55:52:580 LibMain: Process Name:

c:\windows\system32\wscript.exe

USERENV(50c.bac) 08:55:55:809 UserPolicyCallback: Setting status UI to

Applying your personal settings...

USERENV(50c.bac) 08:55:56:066 UserPolicyCallback: Setting status UI to

Applying your personal settings...

USERENV(50c.bac) 08:55:56:066 ProcessGPOList: Extension Internet Explorer

Branding returned 0x0.

USERENV(50c.bac) 08:55:56:066 ProcessGPOList: Extension Internet Explorer

Branding was able to log data. RsopStatus = 0x0, dwRet = 0, Clearing the

dirty bit

 

As you can see the Internet Explorer Branding policy started at 8:55:35:513

according to the log and didn't finish until 8:55:56:066. That's over 20

seconds to apply this extension and the policy which has the IEB settings

does not contain a great deal of IEB settings. 

 

This part here is also concerning:

 

USERENV(50c.bac) 08:55:40:787 ImpersonateUser: Failed to impersonate user

with 5.

USERENV(50c.bac) 08:55:40:787 GetUserNameAndDomain Failed to impersonate

user

USERENV(50c.bac) 08:55:40:803 GetUserDNSDomainName:  Domain name is NT

Authority.  No DNS domain name available.

 

A net helpmsg 5 indicates 5 is access denied, however I'm not sure in what

this means in this context. Can someone please shed some light on this

supposed error?

 

 

***********************

You can unsubscribe from gptalk by sending email to

gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by

logging into the freelists.org Web interface. Archives for the list are

available at http://www.freelists.org/archives/gptalk/

************************

 

***********************

You can unsubscribe from gptalk by sending email to

gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by

logging into the freelists.org Web interface. Archives for the list are

available at http://www.freelists.org/archives/gptalk/

************************

 

***********************

You can unsubscribe from gptalk by sending email to
gptalk-request@xxxxxxxxxxxxx with 'unsubscribe' in the Subject field OR by
logging into the freelists.org Web interface. Archives for the list are
available at http://www.freelists.org/archives/gptalk/

************************

Other related posts: