Feb 04, 2015

The problem

If you are backing up to/from a network share or a mapped network drive, you may run into a situation when the app doesn't "see" the location.

Case 1 - Running as Administrator

In 99% of cases this happens because the app is switched to run as Administrator. More specifically, it is caused by the fact that Windows maintains two user *sessions* for each logged in user. One session is for running apps with regular user rights and another – for the “run as admin”, elevated execution.

These sessions share the desktop, but each of them gets its own list of mapped drives and share connections. So mapping a drive in one doesn't make it automatically appear in another.

Case 2 - Running in Service mode

Similarly, if the program is switched to run in service mode, its engine runs as a system service under a different user account and therefore has no idea of which mapped drives a _desktop_ user may have setup.

The solution

A proper solution is to use explicit network paths instead of mapped drives, which have always been a second-grade citizen of Windows networking and file systems.

That is, use \\server\share\... for the path and, if needed, configure the username and password for accessing this share in backup settings -
https://bvckup2.com/support/forum/topic/413

The workarounds

For the Admin mode case there are also two workarounds:

1.  Apply a registry fix to keep network lists in sync between two sessions -
http://technet.microsoft.com/en-us/library/ee844140%28v=ws.10%29.aspx
( but in a typical Microsoft fashion it doesn't appear to always work )

2.  Issue “net use /persistent” from an elevated (admin) prompt to make a sticky drive mapping for the admin session.