Finally found the root cause of my issue. As stated earlier, it has nothing to do with waking NAS drives from hibernation. I created an AutoIt script that accessed the target drive on my NAS in every possible way it supports, then checked the drive status and if this would return 'ready' it would execute the FFS batch. But whether I used UNC drive paths or mapped drive letters, the script would always detect the target every time I ran it manually and would (almost always) fail when started as a scheduled task via Windows task scheduler.
The cause
It turned out to be caused by the task scheduler setting "Run with highest privileges", which effectively runs my .bat file or AutoIt script as Administrator (FFS needs to run with elevated privileges if it's set to use Windows volume shadow copy or copy NTFS metadata). And as Administrator, network resources that are perfectly accessible with my normal Windows user account, were unavailable as Administrator (check: issue 'net use' command with your normal user account, then repeat with a command prompt with elevated privileges).
The solution
Issue the 'net use' command in the .bat file before the FFS batch is executed:
@ECHO OFF
echo Attempting map of \\server\share to z: target drive:
echo.
net use z: /d
net use z: \\server\share
if exist "\\server\share" (
"C:\Program Files\FreeFileSync\FreeFileSync.exe" "C:\path\to\my.ffs_batch"
exit
) else (
echo Target drive not reachable. Sync not possible.
)
pause
exit
Apparently there is also a registry hack that makes mapped network shares 'stick' between accounts, including Administrator. I haven't tested this.
Links
http://social.technet.microsoft.com/Forums/windows/en-US/31c9eff2-ece3-4430-886d-19b54796e411/windows-7-run-as-administrator-loses-mapped-drives
http://support.microsoft.com/kb/937624
http://www.winability.com/how-to-make-elevated-programs-recognize-network-drives/
