logoff script created in gpedit.msc does not run
-
Wednesday, June 27, 2012 8:39 AM
I have a logoff script created with gpedit.msc
It runs a .bat file.
However it only works if I first open gpedit.msc or console.mscIf I log onto the PC without opening gpedit.msc and log off again the script fails to run!
This has only been an issue since I moved to Windows 7 Pro - it ran every time in XP.
The PC is not part of a domain.
All Replies
-
Wednesday, June 27, 2012 9:39 AMSorry, can't tell without seeing the script.
-
Wednesday, June 27, 2012 9:39 AM
Hey
take a look at this: http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/96ad0c1a-9a30-4763-8784-763afab89dc0
-
Wednesday, June 27, 2012 4:04 PM
Hey
take a look at this: http://social.technet.microsoft.com/Forums/en-US/ITCG/thread/96ad0c1a-9a30-4763-8784-763afab89dc0
Looks like the same problem but no fix/resolution. -
Wednesday, June 27, 2012 4:05 PM
Sorry, can't tell without seeing the script.
"C:\Program Files\SyncToy 2.1\SyncToyCmd" -R "Docs - WHS"
"C:\Program Files\SyncToy 2.1\SyncToyCmd" -R "OtherDocs - WHS" -
Wednesday, June 27, 2012 4:19 PMModerator
Does this script require elevated permissions?
Have you tried scheduling this script using the task scheduler instead of trying to get it to work using a logoff script?
Bill
-
Wednesday, June 27, 2012 4:27 PM
I have a logoff script created with gpedit.msc
It runs a .bat file.
However it only works if I first open gpedit.msc or console.mscIf I log onto the PC without opening gpedit.msc and log off again the script fails to run!
This has only been an issue since I moved to Windows 7 Pro - it ran every time in XP.
The PC is not part of a domain.
You fail to say if you are in a domain. You fail to say which policy you are editing with GPEdit.
If in a domain there is every possibility that the domain policy is superceeding your policy. When you logon domain policy is applied. Your run GPEdit and set the logoff script. You logoff. When you log back on the domain policy is once again applied.
Without more accurate inforamtion it is not possible for any of use to tell exactly what is happening.
The link that was posted is about another issue of using the registry to set policy. The answer to that thread is that the registry items set the logoff script but are not changing the policy keys. The policy keys are being reapplied the next time the policy engine runs which is at logon in non-domain connected machines. It is every 30 minutes on domain workstations and 5 minutes on DCs unless policy has changed this.
Re-analyze your issue and post the missing information and, perhaps, we can figure this out.
¯\_(ツ)_/¯
-
Wednesday, June 27, 2012 8:22 PM
Sorry, can't tell without seeing the script.
"C:\Program Files\SyncToy 2.1\SyncToyCmd" -R "Docs - WHS"
"C:\Program Files\SyncToy 2.1\SyncToyCmd" -R "OtherDocs - WHS"In parallel to JRV's highly relevant domain questions: You should insert some test code into your script that is simple and unlikely to be affected by permissions, e.g. like so:
"C:\Program Files\SyncToy 2.1\SyncToyCmd" -R "Docs - WHS"
"C:\Program Files\SyncToy 2.1\SyncToyCmd" -R "OtherDocs - WHS"
if not exist c:\Logs md c:\Logs
echo %date% %time% >> c:\Logs\Script.txt -
Thursday, July 05, 2012 6:24 PM
I've been trying various suggestions from above - thanks for these.
Responses...
The Windows 7 PC is not part of a domain (I mentioned this in my first post)
The test code from Oberwald indicates that the logoff script is being run at all times which means that the problem is with the SyncToy commands?
However the SyncToy commands work fine if the bat file is double clicked or if gpedit.msc is run before the user logs off.
The logoff script is set up from...
Local Group Policy > User Configuration > Windows Settings > Scripts (Logon/Logoff) > Logoff
No Script parameters have been set.
I did investigate running the bat file from Task Scheduler however these is no trigger for "log off" in this tool.
-
Thursday, July 05, 2012 7:07 PMModerator
Sorry, I don't know the explanation for what you are experiencing. I would recommend testing on a different Windows 7 machine (I would recommend a "stock" install with no other software installed) and see if you can reproduce the behavior using a basic shell script (batch file) that contains the following command:
echo %DATE% %TIME% >> C:\Logs\Test.txt
(Create the C:\Logs directory first and make sure it's writable.) If this behavior is 100% consistent and reproducible, then it is possible you have encountered a bug.
In any case: If your shell script (batch file) works when you run it manually, then you don't really have a scripting question.
Bill
- Proposed As Answer by Bill_StewartMicrosoft Community Contributor, Moderator Friday, July 06, 2012 8:24 PM
- Marked As Answer by IamMredMicrosoft Employee, Owner Tuesday, July 10, 2012 6:45 AM
-
Thursday, July 05, 2012 10:14 PM
Ther re differences in teh way XP and Win7 operate and hwo the logoff is managed. YOu need to tell us what is in your bacthch. It is not likely that you can touvh another macihine during logoff. ANd it is not likely that teh logoff is not getting executed.
What is interesting is that you say if you start mmc then the logoff script runs. This does nto make musch sense. Nothing is being changed. GP is passive on a non-domain pc. It is just a script that sits in a folder on the PC. Is that script in the logoff folder?
The script should be here: c:Windows\System32\GroupPolicy\User\Scripts\Logoff
ON Workgroup manchines you do not need to set a policy. Any script located in this folder will be executed at logoff.
I don't know what 'console.msc' is.
¯\_(ツ)_/¯
- Edited by jrvMicrosoft Community Contributor Thursday, July 05, 2012 10:18 PM
-
Friday, July 06, 2012 6:47 AM
¯\_(ツ)_/¯
"YOu need to tell us what is in your bacthch."
See post above Wednesday, June 27, 2012 4:05 PM
"It is not likely that you can touvh another macihine during logoff. ANd it is not likely that teh logoff is not getting executed."
Indeed as the logs indicate that the logoff script IS being executed but some of the commands in it are not.
"Is that script in the logoff folder?" The script should be here: c:Windows\System32\GroupPolicy\User\Scripts\Logoff"
That is where it lives and I can confirm that all commands are only executed if gpedit.msc is run.
"I don't know what 'console.msc' is."
When I tried setting the logoff policy via MMC I accessed it that way. However I do not use that method now, I use gpedit.msc
-
Friday, July 06, 2012 9:32 AM
You still have not posted the script. Without the script this is just guesswork.
You have already seen that the script is working. Something is wrong in your script. Running msc is just a misdirection. Post the script.
¯\_(ツ)_/¯
-
Friday, July 06, 2012 3:02 PMModerator
jrv,
The OP did post the script (see post above dated Wednesday, June 27, 2012). It's a pair of SyncToyCmd commands. The problem the OP is seeing is that the script executes only if he opens the gpedit.msc console first before logging off. If he opens gpedit.msc during that logon session, the logoff script runs. If he does not open gpedit.msc during that logon session, the logoff script does not run. (spile1: Is this description correct?)
This is why I suggested to create a simple logging script that appends the date and time to a file so we can see exactly when it executes.
In any case: If the OP runs the script from a command prompt window, it executes fine, so we don't really have a scripting problem but rather a peculiar local group policy processing problem.
Bill
- Edited by Bill_StewartMicrosoft Community Contributor, Moderator Friday, July 06, 2012 3:02 PM
-
Friday, July 06, 2012 4:42 PM
That is the current situationjrv,
The OP did post the script (see post above dated Wednesday, June 27, 2012). It's a pair of SyncToyCmd commands. The problem the OP is seeing is that the script executes only if he opens the gpedit.msc console first before logging off. If he opens gpedit.msc during that logon session, the logoff script runs. If he does not open gpedit.msc during that logon session, the logoff script does not run. (spile1: Is this description correct?)
This is why I suggested to create a simple logging script that appends the date and time to a file so we can see exactly when it executes.
In any case: If the OP runs the script from a command prompt window, it executes fine, so we don't really have a scripting problem but rather a peculiar local group policy processing problem.
Bill
-
Friday, July 06, 2012 5:00 PMModerator
Hi,
In other words, your problem is not that the script doesn't work but rather it does not run under the conditions it seems it should (as logoff script). This is a standalone GPO processing problem, not a scripting problem. I would suggest you post in a GPO-related forum to see if they have any ideas.
Bill
-
Friday, July 06, 2012 7:05 PM
We have not heard what is fainiling only that the script is failing. if those are the oly two lines and the scri pis executing then it would be necessary to add logging to th4e script.
As far as I can remember SyncToy was never intended to be run as a logoff script.
Some warnings:
- Both 32-bit and 64-bit versions of SyncToy2.1 are available as a single self-extracting archive executable which runs all of the required setup components when launched. The 64-bit version is targeted to 64-bit versions of Windows, e.g. Windows XP x64 Edition, Windows Vista 64-bit editions and Windows 7 x64 Edition.
- The 32-bit version may be installed and run on a 64-bit version of Windows as well.
- Simultaneous side-by-side installation of the 32-bit and 64-bit versions on the same machine is not recommended or supported.
- SyncToy 2.1 supports quiet installation by an Administrator user on the target machine. The steps for this are as follows. Please download the self-extracting archive executable and save locally. Extract files from the archive to a target directory. You'll notice 3 MSI files in the set of extracted files. Each of the 3 MSIs can be run in quiet mode using the MSI command line utility (msiexec.exe). The order in which the MSIs need to be installed is: Synchronization.msi, ProviderServices.msi, SyncToysetup.msi.
- SyncToy 2.1 depends on components of the Microsoft Sync Framework 2.0 which are included in SyncToy setup. Installing SyncToy along with these dependent components requires the use of an account with Administrator privileges on the target machine. If the Microsoft Sync Framework 2.0 components are already installed on the target machine, SyncToy can be installed from a non-administrator user account.
- The SyncToy application will stop working if any of the dependent components are uninstalled, which can be fixed by re-running the full install package on the target machine.
- If SyncToy 2.1 is installed using an account which is different than the one that was used to install previous versions of SyncToy, then the previous version will not be uninstalled. In this case, it is recommended that users uninstall the previous version using the previously used user account before installing SyncToy 2.1
- If uninstalling SyncToy 2.1, the same user account must be used which was used for installation.
¯\_(ツ)_/¯
-
Friday, July 06, 2012 7:09 PMModerator
Hi jrv,
It's not the script itself that is failing. The script works. The problem is the inconsistency of when it executes. If you open gpedit.msc during the logon session, the script runs at logoff (as expected). If you do not open gpedit.msc during the logon session, the script does not run at logoff (not expected).
So in other words the problem is not with the script but rather with when the script is being executed by the local group policy engine. Thus the question isn't a scripting question but rather a "why doesn't logoff script execute consistently in standalone GPO" question.
Bill
-
Friday, July 06, 2012 7:46 PM
Bikk - yes. I see that. I have been trying to get the OP to see that as well but I am stuck so I'm with you: it is not a scripting issue.
¯\_(ツ)_/¯
-
Friday, July 06, 2012 9:06 PM
Well thanks for your tips all even though it didn't reolve the issue. I'll see if I can find an alternative forum.
For the record, I tried creating the script in VBS but same thing - it executes the SyncToy command when run but only from GPO (logoff) when GPEDIT.MSC is run.
On another forum it was suggested that I add %comspec% /k file.bat" in front of the batch file but that didn't work either.
-
Friday, July 06, 2012 9:21 PMModerator
Hi,
This is a peer-to-peer support forum with no guarantees of any answers. Sometimes there isn't an answer, or the answer is "this is a known problem with no known workaround at this time."
Bill
-
Saturday, July 07, 2012 7:37 AM
After further investigation of the SyncToy logs I've found the following:
*** Failed to execute folder pair PC - WHS. Could not locate folder \\MyServer\Users\Share\.
It would therefore appear that the connection to the server is being lost before the logoff script completes.
Why running gpedit.msc causes the connection to remain I don't know.
My next step is to map the server shares to a letter to see if that retains the server connection so that the synctoy command can complete.
-
Saturday, July 07, 2012 12:33 PM
It i s fairly clear the running gpedit only causes teh logoff to take just enough longer to allow for the launching of SYntToy.
In a logoff script teh system has begun its shutdown. One of teh first things it does is to close all network connections. If you are licky enought tolaucnch a program that causes one of those connetions to have open files then the shutdown will wait for the file to be freeed becuse it will also be assking you to shutdown the program. Place an Excel file on the same share an open it with Excel and you will see that that also should allow the SyncToy to run.
Runnig programs during logoff is not allowed unless theose programs are completely local and do not have or try to input or output from the console. Any cpmplex process is not guaranteed to run correctly.With a slower OS and machine you were lucky to get SyncToy to work. It is notlikely that you will that it to work with Win 7.
None of this has anything to do with scripting. It is an issue that you shopuld post in the Windows 7 forum to see if anyone has found a kludge to allow this to happen.
If you are trying to use SyncToy to backup files to a network share then you should probly use 'Offline files' instead. Offline files can be set to sync only at logoff. logon or both. This will be done by the system and will occur automatically during the logoff phase.
SyncToy is really intrended to sync to devices like notpads and phones and not as a method of backing up a copy of your files.
¯\_(ツ)_/¯
-
Saturday, July 07, 2012 12:43 PM
.png)
