The ‘Unknown Errors’ have been resolved, however I am still seeing problems with a group profile aborting if there is a second instance of SyncBack running. The group profile concerned contains two profiles, as below.
The profiles abort and the error is ‘The profile is already running or is due to run’, however this is NOT a case of a scheduled task attempting to run a profile that is already running, instead what appears to be happening is that the profile is being simultaneously being started multiple times. The following is the group logs, as you can see there are several occurrences where there two group log files with exactly the same timestamp, with would indicate that the group is being run simultaneously.
The group is set to run the two profiles sequentially, however if I reconfigure the group to allow the two profiles to be run in parallel then instead of aborting the profiles run successfully, although as you can see one profile is running in the same process as the user interface and the other profile is running in a different process.
Unfortunately the reason I have this group is because I do not want these profile to running at the same time so this isn’t a solution.
I can reproduce this problem by clicking on a notify icon created by a scheduled task and performing any action such as displaying a log file or even just clicking on the 2BrightSparks icon to visit the website. This instance will not exit once the profile has finished. When the group profile runs as a periodical task it is a highly likely it will abort as described above. I am fairly sure that I seen this problem when a group profile starts during a normal run of a scheduled task (possibly a very slow email backup) without any user interaction to stop the scheduled task from exiting, however I cannot reproduce this at will. Even so accidentally clicking the wrong icon by mistake should not create a situation which will cause profiles to fail.
With regard to WTS and Session 0, on my system schedule tasks are NOT running in session 0 but they are running in session 2 which is my desktop session. If the scheduled task where running in session 0 (as they do on a different system I have running SyncBackSE V5), then they would be invisible to the user (as stated in the documents you referenced), and therefore you would not see any additional icons in the notification area or open the user interface (otherwise Session 0 Isolation would be broken).
After some investigation it turns out that if the ‘Do not store password. The task will only have access to local resources’ checkbox is left clear that the task will run in the user session, if it is selected then it will run in session 0. So the issues I was seeing with the notify icon not being displayed for my group profile was in fact a difference in this setting.
However after changing my schedule tasks so that they run in session 0 they are failing with ‘Scan Failure’ and ‘Network Failure’ with the reason given in the log file user name/password failures, this can happen even after the scan has started so the this would seem to indicate that the user name and password are good. I have been seeing this problem with SyncBackSE V5 for a long time, which is one of the reasons I am looking to upgrade to a current version, so this is not a new issue with V7.
Andrew.
The profiles abort and the error is ‘The profile is already running or is due to run’, however this is NOT a case of a scheduled task attempting to run a profile that is already running, instead what appears to be happening is that the profile is being simultaneously being started multiple times. The following is the group logs, as you can see there are several occurrences where there two group log files with exactly the same timestamp, with would indicate that the group is being run simultaneously.
The group is set to run the two profiles sequentially, however if I reconfigure the group to allow the two profiles to be run in parallel then instead of aborting the profiles run successfully, although as you can see one profile is running in the same process as the user interface and the other profile is running in a different process.
Unfortunately the reason I have this group is because I do not want these profile to running at the same time so this isn’t a solution.
I can reproduce this problem by clicking on a notify icon created by a scheduled task and performing any action such as displaying a log file or even just clicking on the 2BrightSparks icon to visit the website. This instance will not exit once the profile has finished. When the group profile runs as a periodical task it is a highly likely it will abort as described above. I am fairly sure that I seen this problem when a group profile starts during a normal run of a scheduled task (possibly a very slow email backup) without any user interaction to stop the scheduled task from exiting, however I cannot reproduce this at will. Even so accidentally clicking the wrong icon by mistake should not create a situation which will cause profiles to fail.
With regard to WTS and Session 0, on my system schedule tasks are NOT running in session 0 but they are running in session 2 which is my desktop session. If the scheduled task where running in session 0 (as they do on a different system I have running SyncBackSE V5), then they would be invisible to the user (as stated in the documents you referenced), and therefore you would not see any additional icons in the notification area or open the user interface (otherwise Session 0 Isolation would be broken).
C:\Windows\system32>tasklist /fi "IMAGENAME eq SyncBackPro.exe"
Image Name PID Session Name Session# Mem Usage
========================= ======== ================ =========== ============
SyncBackPro.exe 5340 Console 2 8,420 K
SyncBackPro.exe 1560 Console 2 3,208 K
After some investigation it turns out that if the ‘Do not store password. The task will only have access to local resources’ checkbox is left clear that the task will run in the user session, if it is selected then it will run in session 0. So the issues I was seeing with the notify icon not being displayed for my group profile was in fact a difference in this setting.
However after changing my schedule tasks so that they run in session 0 they are failing with ‘Scan Failure’ and ‘Network Failure’ with the reason given in the log file user name/password failures, this can happen even after the scan has started so the this would seem to indicate that the user name and password are good. I have been seeing this problem with SyncBackSE V5 for a long time, which is one of the reasons I am looking to upgrade to a current version, so this is not a new issue with V7.
Andrew.