A specified logon session does not exist

[poguec]

Using Windows 10 64bit in our office each time I try to create a schedule and it asks for my password when it tries to save I get the message "A specified logon session does not exist. It may already have been terminated". I read something about a local policy setting to change but that policy is enforced by corporate and can not be changed. I'm unable to create a schedule that runs. Any suggestions would be appreciated.

[cliffhanger]

If your corporate policy does not permit the storage of account passwords, then AFAIK in that case the only option left is to set up a Schedule(d Task) set to 'Run only when user is logged on', which might be useless for your needs (to run overnight, say) and/or insecure (leaving machine logged in while unattended, though user could Lock it - if he remembers...)

If 'Run only when user is logged on' would suffice for your needs, you should be able to simply click Cancel to the initial password prompt and the Schedule(d Task) will open with the 'Run only when user is logged on' option preselected, ready to set date & time. Note that you cannot switch that option off (and revert to 'whether logged on or not') without being prompted for the password again before that Schedule dialog will close. The result will be an error message and a Task that fails because 'no password' (or words to that effect, IIRC)

[poguec]

Thank you for the reply. Let me ask this then, when I check the Task Scheduler I can see the command used to run the task. What I've noticed if I try to make my own task and use the SYSTEM login so I don't have password issues it never runs. It's almost like there is some link needed between the program and Task Scheduler. Is there another way to run the command below that will actually run?

C:\Program Files (x86)\2BrightSparks\SyncBackFree\SyncBackFree.exe -m "Ircona"

[poguec]

cliffhanger, checking to see if you saw my reply asking about scheduling with the SYSTEM account?

[cliffhanger]

The main problem you have is that your profile[s] will almost certainly be stored by default in

C:\Users\USERNAME\AppData\Local\2BrightSparks\SyncBack\

but a Scheduled Task running under SYSTEM account calling SBF will (in the absence of any settings to the contrary) cause SBF to look for profiles under an equivalent C:\Users\SYSTEM\... location, which of course does not exist (and IIRC is calculated by SB using a WIndows Environment Variable that evaluates differently/wrongly for the SYSTEM account anyway).

There is a way to set SB to use the program folder for (common) profile storage*. However, there is no way to change the per-SB-user program settings to allow the SYSTEM account to store profiles in the program folder (ditto re log storage, set by default to C:\Users\USERNAME\AppData\Local\2BrightSparks\SyncBackFree\Logs\...) without logging in interactively as SYSTEM and running SB / making those storage-settings changes for the user involved - and of course, you cannot log in interactively under the SYSTEM account.

There is also the problem "Where would SB store the INI file (SETTINGS.INI per named user) containing these customized storage settings ?" AFAICS it would need to also use C:\Users\USERNAME\AppData\Local\2BrightSparks\SyncBack\ but as you could not log-in/run-SBF interactively as SYSTEM in order to create the per-user INI file anyway....)

Basically, SyncBack (any model) is not designed to be run under a SYSTEM (or similar) account. There may be other caveats I have not thought of or am otherwise unaware of.


* provided you can assign full write/change privileges for that folder to any account that will create or run profiles; if SB detects you do not have these privileges, SB will not permit you to choose that storage option

[poguec]

Thank you for the great explanation, completely cleared up why it wasn't working. Now I know not to continue down the SYSTEM account path and I can see about leaving the machine always logged in. Not ideal but better to have the schedule run than not.