2BrightSparks Help and Support

Elevation

Basically, elevated processes like SyncBackPro and SyncBackSE cannot see drives that are mapped by non-elevated processes.

For example, if you map drive X: to \\server\share\ in Windows File Explorer then SyncBackFree (which does not run elevated) can see and use drive X:. However, SyncBackPro and SyncBackSE, when run elevated, cannot. Windows security does not allow elevated processes to see drives mapped by non-elevated processes and vice-versa.

The following KB articles explains this in more detail and provides solutions:

https://help.2brightsparks.com/support/solutions/articles/43000335854

Scheduling

If your profile uses a network drive mapped/assigned to a drive letter (a drive on another computer that is available over the network and you've assigned it to a drive letter on your computer) then you may receive an error saying the drive does not exist when the profile is run in a schedule. This happens because such mapped drive letters are not re-assigned automatically (assuming you used the option to Reconnect On Login or equivalent) until you log in to Windows via the console (manually).

'Logging in as a batch job' (which is how Windows Scheduled Tasks work) does not re-create network drive mappings, even for the same user. If the Scheduled Task runs when the user is also logged-in via the console, it may work via Schedule also (reports vary...), but is virtually certain not to work via Schedule if that same user is not also logged-in via the console.

To avoid this, either login to Windows on reboot or use a UNC path instead of a drive letter, e.g. \\server\share\folder\. UNC stands for Universal Naming convention, and it lets you use server and folder names instead of drive letters to access the destination drive. For example, setting the destination to \\2brightsparks_corp\backups\franks_backup\ would eliminate the problem associated with referring to that destination as drive "M:".  Of course, the destination folder must be defined as "shared".