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.