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:

logoff script
When I click the show files button, I see that the file is indeed in the folder:


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:

group policy error
Searching on that error yielded the following MS page:

Which tells me that I can find info about debugging the error on this page:

Which has absolutely no information about how to debug this error.

Looking for any suggestions on where I should go from here.
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

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.
FWestonAuthor Commented:
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:

rsop error
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.
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.
Determine the Perfect Price for Your IT Services

Do you wonder if your IT business is truly profitable or if you should raise your prices? Learn how to calculate your overhead burden with our free interactive tool and use it to determine the right price for your IT services. Download your free eBook now!

FWestonAuthor Commented:
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.
It seems that you have block inheritance at the Domain Level, but it does not matter because you do not have any GPOs at the Sites:

GPSVC(3a4.594) 10:09:09:618 SearchDSObject:  <DC=lpgaoffice,DC=local> has the Block From Above attribute set

It seems that the Client is getting the GPO, has access and passed WMI filter:

GPSVC(3a4.594) 10:09:09:677 ProcessGPO:  ==============================
GPSVC(3a4.594) 10:09:09:677 ProcessGPO:  Searching <CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=lpgaoffice,DC=local>
GPSVC(3a4.594) 10:09:09:677 ProcessGPO:  Machine has access to this GPO.
GPSVC(3a4.594) 10:09:09:677 ProcessGPO:  GPO passes the filter check.
GPSVC(3a4.594) 10:09:09:677 ProcessGPO:  Found functionality version of:  2
GPSVC(3a4.594) 10:09:09:677 ProcessGPO:  Found file system path of:  <\\lpgaoffice.local\sysvol\lpgaoffice.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
GPSVC(3a4.594) 10:09:09:683 ProcessGPO:  Found common name of:  <{31B2F340-016D-11D2-945F-00C04FB984F9}>
GPSVC(3a4.594) 10:09:09:683 ProcessGPO:  Found display name of:  <Default Domain Policy>
GPSVC(3a4.594) 10:09:09:683 ProcessGPO:  Found machine version of:  GPC is 182, GPT is 182
GPSVC(3a4.594) 10:09:09:684 ProcessGPO:  Found flags of:  0
GPSVC(3a4.594) 10:09:09:684 ProcessGPO:  Found extensions:  [{0ACDD40C-75AC-47AB-BAA0-BF6DE7E7FE63}{2DA6AA7F-8C88-4194-A558-0D36E7FD3E64}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957D-509E-11D1-A7CC-0000F87571E3}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}{D02B1F72-3407-48AE-BA88-E8213C6761F1}][{827D319E-6EAC-11D2-A4EA-00C04F79F83A}{803E14A0-B4FB-11D0-A0D0-00A0C90F574B}][{B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A}{53D6AB1B-2488-11D1-A28C-00C04FB94F17}{53D6AB1D-2488-11D1-A28C-00C04FB94F17}]
GPSVC(3a4.594) 10:09:09:684
ProcessGPO:  ==============================

So one question?  Is the version of the GPO that you have when you open GPMC 182?  The reason I ask is because of this:

GPSVC(3a4.594) 10:09:10:626 ProcessGPOs: -----------------------
GPSVC(3a4.594) 10:09:10:626 ProcessGPOs: Processing extension Scripts
GPSVC(3a4.594) 10:09:10:627 CompareGPOLists:  The lists are the same.
GPSVC(3a4.594) 10:09:10:627 CheckGPOs: No GPO changes but couldn't read extension Scripts's status or policy time.
GPSVC(3a4.594) 10:09:10:627 ProcessGPOs: Extension Scripts skipped because both deleted and changed GPO lists are empty.
GPSVC(3a4.594) 10:09:10:627 ProcessGPOs: -----------------------

Also, check which DC you are getting GPOs from by logging into the computer and typing the following in the Start>Run "\\DomainName\Sysvol\"

Replace DomainName with your actual Domain Name.  Then Right-click on the DomainName folder, select Properties and then check which server shows Active in the DFS tab.  Once you do that, open GPMC, connect to that server and see if the GPO shows the script. (I know you say everything is replicating but just double-checking)

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
FWestonAuthor Commented:
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-945F-00C04FB984F9},CN=Policies,CN=System,DC=lpgaoffice,DC=local>
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\lpgaoffice.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}>
GPSVC(3a4.710) 10:21:31:334 ProcessGPO:  Found common name of:  <{31B2F340-016D-11D2-945F-00C04FB984F9}>
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-00C04FA372D4}{3060E8CE-7020-11D2-842D-00C04FA372D4}][{35378EAC-683F-11D2-A89A-00C04FBBCFA2}{0F6B957E-509E-11D1-A7CC-0000F87571E3}{D02B1F73-3407-48AE-BA88-E8213C6761F1}][{42B5FAAE-6536-11D2-AE5A-0000F87571E3}{40B66650-4972-11D1-A7CA-0000F87571E3}][{A2E30F80-D7DE-11D2-BBDE-00C04F86AE3B}{FC715823-C5FB-11D1-9EEF-00A0C90347FF}]

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\lpgaoffice.local\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\USER\Scripts\Logoff, I do see the script in that folder.

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?
FWestonAuthor Commented:
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-598944713-111032338-2933, dwTimeout = 30000, dwFlags = 0
GPSVC(3a4.710) 10:21:31:879 LockPolicySection called for user <S-1-5-21-1913465004-598944713-111032338-2933>
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-598944713-111032338-2933>
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.
jandelbasanalSystem AdministratorCommented:
Try renaming your scripts with short filename like "run.bat". See to it domain users or authentcated users have execute rights of the file.
FWestonAuthor Commented:
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.
FWestonAuthor Commented:
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.
FWestonAuthor Commented:
GlobalStrata came the closest by identifying the issue with the scripts processing.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Active Directory

From novice to tech pro — start learning today.