[gptalk] GPO updates

  • From: "Winter.Mary" <Mary.Winter@xxxxxxxxxxxxxxx>
  • To: <gptalk@xxxxxxxxxxxxx>
  • Date: Tue, 30 Sep 2008 09:19:26 -0500

Out of 6500 machines only 12 needed a reboot.  That is what I'm

From: "Alan & Margaret" <syspro@xxxxxxxxxxxxxxxx>
Subject: [gptalk] Re: GPO updates
Date: Tue, 30 Sep 2008 07:38:22 +1000
Hi Mary,
 I am not sure what you exactly did, but it may be because some parts of
GPO processing only occur at Logon (or reboot in the case of machine
It does not re-occur with each subsequent reapplying of policies.

Darren can probably be more specific..
Alan Cuthbertson
Hello List,
I have a scenario that puzzles me.   I recently updated my Workstation
Local settings GPO to enable the Guest account and rename it.  I also
included a vbs script to change the local Administrator password to
startup scripts.   I linked that policy on Tuesday afternoon after
testing with a pilot group, with no reported problems.  I created
another GPO that runs a vbs script on startup that changes the password
of the new admin account.   While I was testing it I got an error saying
that I was missing a 'then'.  Since it was an exact copy of the script
that went out on Tuesday with the exception of the ending 3 numbers of
the SID, I knew that wasn't true.  I looked at it again and decided not
to run it through the encode.vbs script I was using.  I added the vbs
script as startup instead of the vbe and it worked as expected.  
After testing I linked this new GPO Friday afternoon.

In order to test this change I filtered the GPO with my machines and
added the new ID and the Administrators group to the security settings
for logon locally.  I also had co-workers login with the new account for
testing.  After testing of the script I linked the GPO.  I forgot about
adding the new ID to test.  Since I set the new GPO to be at the end of
the flow of precedence it overwrote the setting that allows my corporate
clients to logon locally in the main Workstation Local GPO.  I was aware
of the problem within 2 hours.  I unlinked the new policy and removed
the logon locally setting and left the vbs script in startup.  I added
the new ID to the corporate GPO security setting.  I linked the new GPO.

This happened on Friday night.  I still have clients that get the
message that they can not logon locally on Monday.  My question; why
didn't the updated GPOs overwrite the ones that went out 2 hours earlier
with no problems? The clients who still get the error have to reboot
their PCs in order to get the corrected GP.
There are only a few but it is a few too many.  

Thanks in advance for any help provided.

Mary Winter
We Energies - IT Services
Client Device Integration

The co-workers who tested for me did not see the problem because their
IDs are in the local Administrators group.  I was not aware that their
regular IDs were in the group.  I am aware that I could have added the
ID to main GPO, was not thinking straight. 

Other related posts: