[gptalk] Re: Random machines not applying policies
- From: ca11235 <ca11235@xxxxxxxxxxxxxx>
- To: gptalk@xxxxxxxxxxxxx
- Date: Mon, 28 Jan 2008 17:14:51 +0000
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?
Cheers,
col
On 09/01/2008, Darren Mar-Elia <darren@xxxxxxxxxx> wrote:
>
> Colin-
>
> 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:
>
>
>
> http://www.microsoft.com/technet/scriptcenter/topics/gp/extension2.mspx
>
>
>
> Darren
>
>
>
> *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
>
>
>
> Colin
>
>
>
>
>
>
>
Other related posts:
