[gptalk] Re: GPO updates
- From: "Darren Mar-Elia" <darren@xxxxxxxxxx>
- To: <gptalk@xxxxxxxxxxxxx>
- Date: Tue, 30 Sep 2008 07:29:21 -0700
Mary-
I can't see any obvious reason why a reboot would have been required for
that subset of computers. Unless they had not, for some reason, run a
background refresh successfully in which case rebooting would have forced a
foreground refresh.
Darren
From: gptalk-bounce@xxxxxxxxxxxxx [mailto:gptalk-bounce@xxxxxxxxxxxxx] On
Behalf Of Winter.Mary
Sent: Tuesday, September 30, 2008 7:19 AM
To: gptalk@xxxxxxxxxxxxx
Cc: Winter.Mary
Subject: [gptalk] GPO updates
Alan,
Out of 6500 machines only 12 needed a reboot. That is what I'm questioning.
Thanks,
Mary
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 policies).
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
Note:
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:
