FWeston
asked on
Group policy user logoff script not running
I am trying to implement a user logoff script using group policy. My domain is at the Win2008 R2 functional level if it matters.
I have edited my default domain policy under User Config > Policies > Windows Settings > Scripts. I added a logoff script, which looks like this:
When I click the show files button, I see that the file is indeed in the folder:
\\mydomain.local\sysvol\my
I also verified that the script has replicated to all of the domain controllers and is accessible in the above folder on each DC. The permissions on the file are set as default, where authenticated users and users both have read and execute permissions.
If I manually go to a PC, open the run dialog box, and browse to that script, it runs fine.
I have manually refreshed the group policy on my PC (Windows 7 x64, which I am using to test the logoff script) by running gpupdate /force to ensure I have the latest GP settings applied, then I have tried logging off and rebooting, but the script does not run.
The script is a simple batch file that echoes the current date and time to a text file on the C: drive so I can tell when it has been run. When I run the script manually, it updates the text file, but when I logoff, the text file does not get updated.
As I understand, the script should be running in the context of the logged on user, but just to be sure this was not a permissions issue, I have assigned the everyone group full control of the text file that the script is supposed to update.
I have run gpresult /v and attached the output as gp.txt. I noticed that I don't see any logon or logoff scripts under the user configuration in the output.
In event viewer, I also see the following error, and this also occurs on the command line when I run gpupdate /force:
Searching on that error yielded the following MS page:
http://technet.microsoft.com/en-us/library/cc727303%28v=ws.10%29.aspx
Which tells me that I can find info about debugging the error on this page:
http://technet.microsoft.com/en-us/library/c08b40aa-2fca-4ab1-aa2a-1589ba7f5420
Which has absolutely no information about how to debug this error.
Looking for any suggestions on where I should go from here.
I have edited my default domain policy under User Config > Policies > Windows Settings > Scripts. I added a logoff script, which looks like this:
When I click the show files button, I see that the file is indeed in the folder:
\\mydomain.local\sysvol\my
I also verified that the script has replicated to all of the domain controllers and is accessible in the above folder on each DC. The permissions on the file are set as default, where authenticated users and users both have read and execute permissions.
If I manually go to a PC, open the run dialog box, and browse to that script, it runs fine.
I have manually refreshed the group policy on my PC (Windows 7 x64, which I am using to test the logoff script) by running gpupdate /force to ensure I have the latest GP settings applied, then I have tried logging off and rebooting, but the script does not run.
The script is a simple batch file that echoes the current date and time to a text file on the C: drive so I can tell when it has been run. When I run the script manually, it updates the text file, but when I logoff, the text file does not get updated.
As I understand, the script should be running in the context of the logged on user, but just to be sure this was not a permissions issue, I have assigned the everyone group full control of the text file that the script is supposed to update.
I have run gpresult /v and attached the output as gp.txt. I noticed that I don't see any logon or logoff scripts under the user configuration in the output.
In event viewer, I also see the following error, and this also occurs on the command line when I run gpupdate /force:
Searching on that error yielded the following MS page:
http://technet.microsoft.com/en-us/library/cc727303%28v=ws.10%29.aspx
Which tells me that I can find info about debugging the error on this page:
http://technet.microsoft.com/en-us/library/c08b40aa-2fca-4ab1-aa2a-1589ba7f5420
Which has absolutely no information about how to debug this error.
Looking for any suggestions on where I should go from here.
pclinuxguru
Last I checked Logon/Logoff scripts are supposed to be VBS scripts. I could be wrong. I seem to recall trying bat files in their and in the end I converted my script to a vbs script and it started working.
ASKER
I tried removing the .bat file from the list of logoff scripts and replacing it with a functionally identical .vbs file, but still have the same problem.
I ran a RsOP on my computer and got some more info. When I look at the properties of the user settings under the RsOP data, I see the following:
So it would seem that there is a file not found error, but it doesn't tell me what file is causing the problem.
I also followed the instructions at this url to enable the group policy debug log, however when I open the log, it appears to be encoded weirdly because it is very hard to read. When I open it in ultraedit, it looks like hex. When I take it out of hex mode, I can read the file, however there are spaces between each and every character in the file, which makes it difficult to read.
I will attach the log file here.
gpsvc.log
I ran a RsOP on my computer and got some more info. When I look at the properties of the user settings under the RsOP data, I see the following:
So it would seem that there is a file not found error, but it doesn't tell me what file is causing the problem.
I also followed the instructions at this url to enable the group policy debug log, however when I open the log, it appears to be encoded weirdly because it is very hard to read. When I open it in ultraedit, it looks like hex. When I take it out of hex mode, I can read the file, however there are spaces between each and every character in the file, which makes it difficult to read.
I will attach the log file here.
gpsvc.log
I have seen kix, vbs, bat, cmd, ps1, wsf and more running from GPOs.
I suggest taking another gpsvc.log and posting it here. Before before you capture it, make sure you delete the previous gpsvc.log, then reboot the computer and a minute after you login, copy the gpsvc.log. The current gpsvc.log has multiple group policies runs so it is a bit difficult to see when is the problem happening.
Another question is, how many times you have that GPO linked in the environment? It seems that is linked in several places, some with Block Inheritance enabled.
I suggest taking another gpsvc.log and posting it here. Before before you capture it, make sure you delete the previous gpsvc.log, then reboot the computer and a minute after you login, copy the gpsvc.log. The current gpsvc.log has multiple group policies runs so it is a bit difficult to see when is the problem happening.
Another question is, how many times you have that GPO linked in the environment? It seems that is linked in several places, some with Block Inheritance enabled.
ASKER
Here is the revised gpsvc.log you asked for.
The policy is only linked once at the domain root level. As far as I know, block inheritance is not enabled anywhere.
gpsvc.log
The policy is only linked once at the domain root level. As far as I know, block inheritance is not enabled anywhere.
gpsvc.log
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Well, I think that section is the computer policy. Just so you know, I rebooted the computer, stepped away for a few minutes, then didn't log on again until 10:21, which as I understand is when the user policy would apply. Since the script is part of the user policy, I think the section we have to look at is this, right?
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: Searching <CN={31B2F340-016D-11D2-94
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: User has access to this GPO.
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: GPO passes the filter check.
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: Found functionality version of: 2
GPSVC(3a4.710) 10:21:31:327 ProcessGPO: Found file system path of: <\\lpgaoffice.local\sysvol
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found common name of: <{31B2F340-016D-11D2-945F-
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found display name of: <Default Domain Policy>
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found user version of: GPC is 58, GPT is 58
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found flags of: 0
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found extensions: [{3060E8D0-7020-11D2-842D-
In GPMC, when I pull up details for Default Domain Policy, I see:
User version: 56 (AD), 56 (sysvol)
Computer version: 182 (AD), 182 (sysvol)
So it looks like the version numbers are matching up.
When I look at the DFS properties, it indicates that ANTARES is the active server. When I go to the path: \\antares\sysvol\lpgaoffic
Quick question - when I look at the scripts.ini file under that policy's folder, under the logoff section, it just has the script name with no path. I assume that GP automatically knows that for logoff scripts it has to look in the logoff folder, and that doesn't have to be a more qualified path, right?
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: Searching <CN={31B2F340-016D-11D2-94
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: User has access to this GPO.
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: GPO passes the filter check.
GPSVC(3a4.710) 10:21:31:326 ProcessGPO: Found functionality version of: 2
GPSVC(3a4.710) 10:21:31:327 ProcessGPO: Found file system path of: <\\lpgaoffice.local\sysvol
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found common name of: <{31B2F340-016D-11D2-945F-
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found display name of: <Default Domain Policy>
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found user version of: GPC is 58, GPT is 58
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found flags of: 0
GPSVC(3a4.710) 10:21:31:334 ProcessGPO: Found extensions: [{3060E8D0-7020-11D2-842D-
In GPMC, when I pull up details for Default Domain Policy, I see:
User version: 56 (AD), 56 (sysvol)
Computer version: 182 (AD), 182 (sysvol)
So it looks like the version numbers are matching up.
When I look at the DFS properties, it indicates that ANTARES is the active server. When I go to the path: \\antares\sysvol\lpgaoffic
Quick question - when I look at the scripts.ini file under that policy's folder, under the logoff section, it just has the script name with no path. I assume that GP automatically knows that for logoff scripts it has to look in the logoff folder, and that doesn't have to be a more qualified path, right?
ASKER
Looking through the log a bit more, this seems to be the key area where I am having issues:
GPSVC(3a4.710) 10:21:31:878 ProcessGPOs: Processing extension Scripts
GPSVC(3a4.710) 10:21:31:878 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3a4.710) 10:21:31:878 CompareGPOLists: One list is empty
GPSVC(3a4.710) 10:21:31:879 GPLockPolicySection: Sid = S-1-5-21-1913465004-598944
GPSVC(3a4.710) 10:21:31:879 LockPolicySection called for user <S-1-5-21-1913465004-59894
GPSVC(3a4.710) 10:21:31:879 Sync Lock Called
GPSVC(3a4.710) 10:21:31:879 Writer Lock got immediately.
GPSVC(3a4.710) 10:21:31:880 Lock taken successfully
GPSVC(3a4.710) 10:21:31:880 Taking console lock with timeout 30000.
GPSVC(3a4.710) 10:21:31:880 Sync Lock Called
GPSVC(3a4.710) 10:21:31:880 Writer Lock got immediately.
GPSVC(3a4.710) 10:21:31:880 Lock taken successfully
GPSVC(3a4.710) 10:21:31:881 ProcessGPOList: Entering for extension Scripts
GPSVC(3a4.710) 10:21:31:881 UserPolicyCallback: Setting status UI to Applying Scripts policy...
GPSVC(3a4.710) 10:21:31:881 GetWbemServices: CoCreateInstance succeeded
GPSVC(3a4.710) 10:21:31:883 ConnectToNameSpace: ConnectServer returned 0x0
GPSVC(3a4.710) 10:21:31:953 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(3a4.710) 10:21:32:015 ProcessGPOList: Extension Scripts returned 0x2.
GPSVC(3a4.710) 10:21:32:016 ProcessGPOList: Extension Scripts was able to log data. RsopStatus = 0x0, dwRet = 2, Clearing the dirty bit
GPSVC(3a4.710) 10:21:32:017 Releasing console lock.
GPSVC(3a4.710) 10:21:32:017 UnLockPolicySection called for user <S-1-5-21-1913465004-59894
GPSVC(3a4.710) 10:21:32:017 UnLocked successfully
GPSVC(3a4.710) 10:21:32:017 ProcessGPOs: Extension Scripts ProcessGroupPolicy failed, status 0x2.
So, Extension Scripts ProcessGroupPolicy failed, but not sure how to further debug this.
GPSVC(3a4.710) 10:21:31:878 ProcessGPOs: Processing extension Scripts
GPSVC(3a4.710) 10:21:31:878 ReadStatus: Read Extension's Previous status successfully.
GPSVC(3a4.710) 10:21:31:878 CompareGPOLists: One list is empty
GPSVC(3a4.710) 10:21:31:879 GPLockPolicySection: Sid = S-1-5-21-1913465004-598944
GPSVC(3a4.710) 10:21:31:879 LockPolicySection called for user <S-1-5-21-1913465004-59894
GPSVC(3a4.710) 10:21:31:879 Sync Lock Called
GPSVC(3a4.710) 10:21:31:879 Writer Lock got immediately.
GPSVC(3a4.710) 10:21:31:880 Lock taken successfully
GPSVC(3a4.710) 10:21:31:880 Taking console lock with timeout 30000.
GPSVC(3a4.710) 10:21:31:880 Sync Lock Called
GPSVC(3a4.710) 10:21:31:880 Writer Lock got immediately.
GPSVC(3a4.710) 10:21:31:880 Lock taken successfully
GPSVC(3a4.710) 10:21:31:881 ProcessGPOList: Entering for extension Scripts
GPSVC(3a4.710) 10:21:31:881 UserPolicyCallback: Setting status UI to Applying Scripts policy...
GPSVC(3a4.710) 10:21:31:881 GetWbemServices: CoCreateInstance succeeded
GPSVC(3a4.710) 10:21:31:883 ConnectToNameSpace: ConnectServer returned 0x0
GPSVC(3a4.710) 10:21:31:953 LogExtSessionStatus: Successfully logged Extension Session data
GPSVC(3a4.710) 10:21:32:015 ProcessGPOList: Extension Scripts returned 0x2.
GPSVC(3a4.710) 10:21:32:016 ProcessGPOList: Extension Scripts was able to log data. RsopStatus = 0x0, dwRet = 2, Clearing the dirty bit
GPSVC(3a4.710) 10:21:32:017 Releasing console lock.
GPSVC(3a4.710) 10:21:32:017 UnLockPolicySection called for user <S-1-5-21-1913465004-59894
GPSVC(3a4.710) 10:21:32:017 UnLocked successfully
GPSVC(3a4.710) 10:21:32:017 ProcessGPOs: Extension Scripts ProcessGroupPolicy failed, status 0x2.
So, Extension Scripts ProcessGroupPolicy failed, but not sure how to further debug this.
Try renaming your scripts with short filename like "run.bat". See to it domain users or authentcated users have execute rights of the file.
ASKER
The current script name is test.vbs, so I would think that is short enough. Authenticated Users and Users had read and execute, I added domain users with the same permissions and will give that a shot. At this point, I think my next step will be to remove all script settings from the default domain policy, create a new policy and put it in there to see if that makes any difference.
ASKER
I ended up removing the logoff script settings from the default domain policy, then I created a new GPO and added the logoff script there, and this solved the problem.
When I run gpupdate /force, I still get an error about the scripts extension failing, so I assume that there must be some sort of corruption in the default domain policy. However, since other settings in that GPO are still working fine, I am just going to leave it as is with the understanding that we still have an error but that the error is not causing any adverse effects.
Thank you all for your help.
When I run gpupdate /force, I still get an error about the scripts extension failing, so I assume that there must be some sort of corruption in the default domain policy. However, since other settings in that GPO are still working fine, I am just going to leave it as is with the understanding that we still have an error but that the error is not causing any adverse effects.
Thank you all for your help.
ASKER
GlobalStrata came the closest by identifying the issue with the scripts processing.