[gptalk] Re: Random machines not applying policies

  • From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Mon, 28 Jan 2008 10:28:52 -0800

Well, the History keys are not part of the user profile but I don't see any
obvious reason why these keys would get corrupted by script processing.
Synchronous scripts should run one after the other, but I don't know the
answer to whether they wait for all child processes to end before going to
the next script-my guess is not. However, unless the scripts are writing to
the history keys, I don't see that as an issue.


From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of ca11235
Sent: Monday, January 28, 2008 9:15 AM
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Re: Random machines not applying policies


Thanks Darren, 


Sorry for the very slow reply - been a bit busy :)  

I agree with you on the profile corruption approach - but what would cause a
profile to corrupt?  Can the application of GPs corrupt a profile? Is it
possible that the script CSE didn't complete properly for a couple of
successive GPs (GP1 gets applied, runs associated logon script, then GP2
comes in, but GP1's script hasn't finished properly...)

The policies are set to applied synchronously, but I'm not too sure if the
scripting side of this is truely synchronous - the script is kicking-off
other vbs and exe files - will the script CSE wait untill all "child
processes" have completed fully?



On 09/01/2008, Darren Mar-Elia <darren@xxxxxxxxxx> wrote: 


The only thing I can think of that would cause an inability to read the
History keys would be permissions issues on those keys or some kind of
corruption or bad data being written to those keys, but I must admin I've
never seen that. Have you tried putting some logging into your logon script
to see what error is getting returned when the script runs? Or check out
this article on script troubleshooting: 






From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of ca11235
Sent: Wednesday, January 09, 2008 4:00 AM 
To: gptalk@xxxxxxxxxxxxx
Subject: [gptalk] Random machines not applying policies 


Hi Guys,


I've a number of users (XP SP2) running in a pilot.  They all use normal
user machines and apply the same policies as the rest of the standard
users/machines, but in addition, they have one extra user policy applied
which runs an additional logon script (mapping to a dfs share). 


A few of the users have had problems with the dfs mapping and, on
examination via GPMC Policy Results, I find that they have problems reading
policy history ("Windows cannot read the history of the GPOs from the
registry") and event 1047 is logged.  This seems to have started happening
after linking in the new policy.  The fix seems to be to clear the history
keys (per MS article 319006) or sometimes a gpupdate /force works, but this
isn't going to be practical in the live environment.  Does anyone know WHY
this is happening - what would cause an otherwise OK user/workstation to
fail to read GP history info? 


Thanks for any help







Other related posts: