Graham- Yes, the client will check both the versionNumber attribute in AD as well as the version number in SYSVOL in GPT.INI. First it checks that both versions are identical--indicating that the GPC is in sync between AD and SYSVOL. Then, the client uses its GPO History, held in HKLM and HKCU at SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\History to determine if the GPO version is greater than the last time it was processed. Note that the keys under the History key are organized by CSE GUID.
Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Sunday, January 04, 2004 10:57 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] group policy processing of IE settings Darren, thanks for mail back it would seem "good luck" to be most appropriate !!! one qu - GPO processing by CSe is dependent in some part on changes to a previously applied GPO i assume this is a simple check of the version number (gpt.ini) of that on the server against that previously applied and that the version number is of the GPO and not sections of the GPO how do we see from the client the version of the GPO(s) that have been applied - i assume they are written to the registry somewhere ? GT ----- Original Message ----- From: "Darren Mar-Elia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, January 02, 2004 6:35 PM Subject: RE: [ActiveDir] group policy processing of IE settings Happy New Year Graham- Yes, I think KB306915 is incorrect as near as I can tell. I can understand why MS put those values in the spot they did. That policies subkey under HKLM guarantees that any settings underneath are not "tattooed" when the policy is removed, so it makes sense that they would want to put as many settings here as possible. It is curious, however, that they are basically duplicates of the values found in the GPExtensions subkey. I suspect that the gpextensions values are used by the extensions themselves to control other processing behavior. In regards to your IE problem, yes, the IE maintenance uses the same mechanism as the IEAK, although as I understand it, not all IEAK policies are supported in Group Policy. If you look in the GPT (in sysvol) for a given GPO with IE Maintenance policy set, you will find the familiar install.ins file. I am not surprised that userenv.log logging doesn't yield much detail, since the IEAK stuff is marching to its own tune, so to speak. If it truly is the same mechanism, then you might look for the brndlog.txt file, which is used to log configuration events in the IEAK. I don't have a handy machine to look for that right now, but if you find it, let me know. KB article # 192472 describes troubleshooting in the IEAK, which probably applies to a degree in GPO. Good luck, Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Friday, January 02, 2004 6:22 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] group policy processing of IE settings Darren, thanks for the mail back (and perhaps a sanity check !!) and Happy New Year to you it would seem appropriate to say. i assume that we are then agreed then that the "running config" of the CSE that processes the IE mainteance settings is in fact the values in; hklm/software/policies/microsoft/windows/grouppolicy and that KB306915 is in fact incorrect ?? fact - we have the "IE maintenance policy processing" policy enabled with "process even if GP objects have not changed" and this has set the reg value as above to 0 from which it seems i can assume (!! ??) that the client will process i have not as yet tried setting the NOGPOLISTCHANGES under the 'gpextensions" key to 0 as yet - didn't think that we would need to do this IF this does needs to be applied begs the question of what (if any) policy value enables this. however we are experiencing inconsistent behaviour of setting of the "automatic configuration script address" value. on the premise that we are always processing the IE maintenance settings are you able to offer suggestions on how to further debug. it would seem the "ultimate" debug is logged activity of the application of the given reg values into the registry (hkcu/software/microsoft/windows/currentversion/internet settings/autoconfigurl) have tried setting the extensiondebuglevel value for the CSE to 2 in the hope that the CSE logs its activity somewhere so i can see the reg value being applied. - NO JOY HERE !! gpresult.exe does not give us any information other than "additional information is not available for this type of policy setting" !! - chocolate tea cups comes to mind ! qu - i don't know to much on the concept of IE branding but i do know of it as a pre-group policy method of is it possible that the affected hosts have some legacy of this installed - KB306915 seems to suggest that "install.ins" which as i understand is generated by IEAK still comes into play even when using GP to configure IE also am not finding good information on the policy "disable external branding" - ??? apologies for the essay but i attempt to fill you in on as much of that which i have tried - what should be easy is proving to be quite the opposite - it would seem to be made all the more difficult by the lack of debug information ?? don't know if you follow the Usenet location of msnews.microsoft.com/microsoft.public.win2000.grouppolicy but here i have an ongoing thread with MSFT - this seems to have run its course. help in the further debug of this will be most gladly received GT ----- Original Message ----- From: "Darren Mar-Elia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, December 31, 2003 6:02 PM Subject: RE: [ActiveDir] group policy processing of IE settings Graham- Well, this is pretty wild. My initial response was based on my long-held belief that MS followed their own documentation. Silly me. If you read this article that talks about how to implement a callback function for your own CSE (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/policy /policy/processgrouppolicyex.asp), it clearly talks about the Winlogon key as being the place to put these values--and indeed NOGPOListChanges is shown on my XP machine in that spot with a value of 1. However, you are absolutely correct that the Admin. Template policy makes the change in the other location. I only had to look at the underlying ADM file to see that that is so. The docs also note that when the value is 0 (not 1), that is when the CSE processes a GPO regardless of changes, which is what you want. The reason that key didn't show up on my machine was that I hadn't set that policy as of yet. Once I set it, voila. So, if that value is set to 0, you should be processing IE Maintenance policy each time processing happens--foreground or background. If that is still not solving your problem, then let us know. Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Wednesday, December 31, 2003 4:13 AM To: [EMAIL PROTECTED] Subject: Re: [ActiveDir] group policy processing of IE settings Darren, thanks for the mail reply. this was my initial view - but google searches on "nogopolistchanges" seem to lead to apparently contradicting info; http://www.tburke.net/info/regentry/topics/GPRef.htm seems to go directly against that which is documented under Q306915 and other technotes that suggest the configuration of the CSE is under the registry key with "gpextensions" fact of the matter (which i would be glad for your confirmed observation on) is that when the policy is enabled via the policy editor the registry key under gpextensions is NOT set to 1 when the policy is applied in fact the other reg value (which i am not sure why you don't have on your system ? - win2k professional / SP3) is modified to reflect the policy settings as i see it i have no confidence that the "running config" of the GP clients is such that IE maintenance policies are being applied irrespective of update ?? seem to exhausted offers from the MS newsgroup so me thinks am in for a rough ride on this one !!! GT ----- Original Message ----- From: "Darren Mar-Elia" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, December 30, 2003 5:51 PM Subject: RE: [ActiveDir] group policy processing of IE settings Graham- Generally speaking, when you need to change CSE processing behavior, its typically done where the CSE is registered, which is under hklm/software/microsoft/windows nt/current version/winlogon/gp extensions/. I don't have the 1st reg key you listed on my machines, so I'm not sure where that comes from. If you don't want to futz with making these registry changes, the NoGPOListChanges option is the same as the Administrative Template policy called "Process Even if the Group Policy objects have not changed". You can set this for the IE Maintenance CSE by going into the GPO namespace under: Computer Configuration|Administrative Templates|System|Group Policy|IE Maintenance Policy Processing. Darren -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Tuesday, December 30, 2003 7:22 AM To: [EMAIL PROTECTED] Subject: [ActiveDir] group policy processing of IE settings not sure if this list accepts issues relating to the configuration of Internet explorer using Group policy - if not apolgoies but would nonetheless be v glad for assistances on the apparently inconsistent behaviour w.r.t the setting of the auto-configuration script value. definites i can confirm; 1. the internet maintenance processing policy is enabled - (see later) 2. the IE maintenance is in policy (NOT preference) mode the observed behaviour is that despite the autoconfig script value being set by policy, in some cases this particular policy is not being applied - seems similar to that documented by KB306915 i think the issue seems to evolve around the setting of the registry value "NOGPOLISTCHANGES" for the client side extension that processes the internet explorer maintenance settings - in short the one that ends in "00C04F86AE3B" the policy that is applied to the computer has the "Internet Explorer Mainteance processing" policy enabled with the "process even if the GP objects have not changed" set. this is verified by the result of gpresult.exe and the values set in the registey key; hklm/software/policies/microsoft/windows/grouppolicy/GUID....AE3B however KB306915 / KB216358 seem to allude to a registry value of the same "nogoplistchanges" name but under a different key; hklm/software/microsoft/windows nt/current version/winlogon/gp extensions/GUID...AE3B not sure how these two keys are related - if at all ?? KB306915 seems to suggest the enabling of the IE maintenance policy is configured using the value under the latter key my testing would go against this and that in fact it sets the former key help in the debug of this will be v gladly received GT List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/