Recently, we faced an unlikely issue with a standard Windows task scheduler. We were upgrading a set of servers that included migrating some Windows task scheduler jobs to the new server. The new server had Windows 2012 R2 OS. The task scheduler in question was to run 4 times a day and consisted of invoking a batch file which in turn executed a Python script. We noticed that while the job itself was running successfully and the script was doing its part, there was one section of the script that was not working. The script was supposed to create a set of CSV files, zip these together and finally copy the files to a file share. It transpired that the files were not being copied. We checked firewall rules, permissions and all the known problem areas and everything seemed okay.
The issue seemed to be weird and no one had any answers - all the scheduled task options were correct. I decided to check this in another environment and did this with a PowerShell script which gave similar results. However, for the sake of an apple-to- apple comparison, I created a small Python script to copy files and tried out the same scenario on the same flavour of OS. Voilà! It also showed the same error. It got me to check all the options of the task scheduler and finally, I found the culprit.
In our case, the scheduled task was configured to run "whether the user is logged on or not". To achieve this, we had also added the user a/c under which the task was running to the security policy - "Logon as a batch job". If you select the option to run the job regardless of whether the user is logged on or not, there is an additional child option "Do not store password" to consider. If you select the check-box labelled "Do not store password" , Task Scheduler will not store the credentials supplied on the local computer, but will discard them after properly authenticating the user. When required to run the task, the Task Scheduler service will use the “Service-for- User” (S4U) extensions to the Kerberos authentication protocol to retrieve the user’s token.
Please see this link: https://technet.microsoft.com/en-us/library/cc722152(v=ws.11).aspx
It turns out that in Windows 2012 R2 (unsure if this is the case with other Windows flavours), if the "Do not store password" is chosen, the file copy task does not work. I am not sure why this is the case and there is no available literature to guide on this.
Make sure you do not choose the option "Do not store password", if there is any file copy task/module in your script. There could be other areas also which are impacted by the choice of this option, but we have so far only seen this impact.