Jtdylktuy

Mapped drives are a User Interface concept and are not available to background tasks like that. Access the target via UNC and make sure that the user that the task runs as has access to the target.

In my case all i had to do was uncheck the run with highest privileges flag but im running the task in on the same user as the user who mapped the drive.

Try using:

pushd \machineshare

within a batch file of your scheduled task. Network shared drives are only available from a user-run environment. "pushd" will allow it to be run in the context of the script.

When you're done use:

popd \machineshare

to unmap the drive.

Reference: https://blog.adrianbanks.co.uk/windows/2007/03/08/accessing-network-file-shares-from-a-command-prompt.html

Another option is just to use the full network path, as Robocopy supports them. i.e. robocopy c:temp \serversharetemp

Or better yet, run the backup on the server itself. Create a domain admin account just for the backup process. Feed robocopy the password from a text file that only domain admins can access.

Years ago I created several .cmd scripts that would backup essential files for every system on the network this way. The only external program that I used was Cgywin's Grep command, and a command prompt smtp mail sender.

I made one script that would scan the network for systems. It would create a text file of all the system names, and alert me via email of any new systems that it found. (I had a config file that it would parse for systems to skip.) Each new system had a backup directory created for it and an backup configuration file placed in it. The user could modify this file and list any directories that needed backed up. They could also specify the time for their backups so it wouldn't happen when they were in the office. I ran this script on the server every 5 minutes, as it took no processing time and I like the security feature of alerting me when a new system was plugged into the network.

Another script would parse all of the individual backup configuration files and schedule a task to run a backup on that system. This was run daily at 12:01am.

Finally the backup script would parse the config file that was passed to it by the scheduler and using robocopy would copy all of the files. I had full error checking on the config files since users would edit them, and I would get emails on any problems.

The users could read their backup files, but could not delete the backup. This provided some protection from damage from a possible disgruntled employee.

Probably something much more elegant could have been made in .vbs or powershell, but I am not really a programmer. My programming classes included Cobal and JCL. I remember I copied the scripts when I left, but who knows where they are now.

echo Get-Date >> c:mount_nfs_log.txt

net use X: \sharefolder password /user:domainuser>> c:mount_nfs_log.txt 2>&1

Creating this powershell script, scheduling the job as SYSTEM and setting it to run on reboot allowed me to use drive letters in my scripts since UNC isn't an option due to a headache of other issues.

Try changing the "start in" location to "c:". This seemed to fix it for me so maybe the system was preventing the cmd.exe from executing from the default windowssystem32 as a security feature.

I had same issue trying to access r:/xxxfilename.txt with a windows mapped drive r:servershare when calling a script from windows task scheduler.


I solved using //server/share/xxxfilename.txt

Please notice the back slash converted to forward slash.

Now my bash cygwin script runs in windows task scheduler and cygwin shell.
Note: "net use" command can access the map drives in shell but shows
Unavailable R: when I run this command in Windows task Scheduler.

I overcame the problem by changing the option "Run Whether user is logged on or not" to "Run only when user is logged on". Try this it may help you.

As another user noted, setting the option to "Run Whether user is logged on or not" to "Run only when user is logged on" does seem to work. You can then use either the mapped path (e.g. Z:) or the server path (e.g. \ServerNamePath).

Of course, if you use this option, then you have to do as it says and ensure that you have logged into the server as a user with access to the relevant drive. I remember being at an older company with a number of jobs setup like this. One day someone "signed out" of the main jobs server, not expecting that that would have any kind of impact as they weren't shutting down the machine in any way...

Also, these days, Windows likes to do a lot of self invoked system reboots. So use this solution at your own risk.

Also note that if you make the mapping in the script and the password contains % then it has to be written %% for the script to work from the taskscheduler but % to work from commandprompt

one can use following commands, to be added in the batch script itself, to run Batch script from windows schedule task to get dir,file copied onto the local system using Windows schedule task;
net use Y: "\xxxxxxxxx
cd /d Y:

net user /d Y: /Y

Thanks , i think that using "start in c:" solved my problem i will be tracking this issue to confirm is solved.

I was having the same issue , if i clicked directly on batch it ran flawlessly but not under scheduled task.