Having further investigated the ‘Scan Failure’ errors when running a scheduled task in session 0 this is what appears to be happening. Firstly the only time that the scheduled task runs in session 0 is if the ‘Do not save password’ option is selected (at least this is the case on the Windows 7 system I am using *** ).
When the profile starts it attempts to login to the server using the Windows username and password this fails as the password is not known, it would then appear the SyncBack is attempting to login using the username and password set in the SyncBack profile, this is successful. If the connection to the server is lost, such as in the way described in the previous post, then an attempt to log back into the server is made but again using the Windows username and password which of course fails, the profile then fails with the ‘Scan Failure’ error. It would appear that to fix this issue SyncBack needs to attempt to login again with the username and password stored in the profile.
The ‘Network Failure’ error that I was seeing from the second profile in the same group as the profile failing with the ‘Scan Failure’ was in fact because there was no username and password set in the second profile. This was not a problem if the first profile succeeded as the second profile would inherit the connection from the first profile (as would any other running profile), of course when the first profile fails there is no connection to inherit. Setting the username and password in the second profile enables to successfully login into the server if required.
In my configuration the systems involved are in a workgroup, whether this problem is the same for a domain I do not known, my understanding is that different SMB authorisation mechanisms are used so it is possible that it isn’t.
Andrew.
*** I just checked a Windows 8.1/SyncBackSE V5 system and the behaviour is appears to be different, on this system the ‘Do not save password’ setting has no effect where the schedule task runs and on this system is will run in session 0 if the ‘Run whether user is logged on or not’ is set. This is definitely different to the Window7 system I have using to evaluate SyncBackPro V7.
When the profile starts it attempts to login to the server using the Windows username and password this fails as the password is not known, it would then appear the SyncBack is attempting to login using the username and password set in the SyncBack profile, this is successful. If the connection to the server is lost, such as in the way described in the previous post, then an attempt to log back into the server is made but again using the Windows username and password which of course fails, the profile then fails with the ‘Scan Failure’ error. It would appear that to fix this issue SyncBack needs to attempt to login again with the username and password stored in the profile.
The ‘Network Failure’ error that I was seeing from the second profile in the same group as the profile failing with the ‘Scan Failure’ was in fact because there was no username and password set in the second profile. This was not a problem if the first profile succeeded as the second profile would inherit the connection from the first profile (as would any other running profile), of course when the first profile fails there is no connection to inherit. Setting the username and password in the second profile enables to successfully login into the server if required.
In my configuration the systems involved are in a workgroup, whether this problem is the same for a domain I do not known, my understanding is that different SMB authorisation mechanisms are used so it is possible that it isn’t.
Andrew.
*** I just checked a Windows 8.1/SyncBackSE V5 system and the behaviour is appears to be different, on this system the ‘Do not save password’ setting has no effect where the schedule task runs and on this system is will run in session 0 if the ‘Run whether user is logged on or not’ is set. This is definitely different to the Window7 system I have using to evaluate SyncBackPro V7.