Putting the user you run the task under in a built-in local group like Backup Operators on the target server might do the trick ( don't have a test bed to test this, but if unsure start with local admin on both servers and then use elimination). And the event log message seems to point towards the fact that it needs the seBackupPrivilige ( which probably really means it wants to change the objects Owner). I've seen more anecdotal evidence of permissions behaving differently interactively compared to from a Scheduled Task. It was suggested that this policy might be relevant but it's disabled so I don't think it is: Network access: Do not allow storage of passwords and credentials for network authenticationĬomputer Configuration\Windows Settings\Security Settings\Local Policies\Security Options So, going via WebDAV, my credentials are being used, whereas going via CIFS they are not.Ĭan anyone elucidate why the copy is failing and if there is any workaround? Any next steps for testing? I have got it to work by hard-coding credentials in the batch file but obviously that's not really acceptable.
#WINDOWS 10 BACKUP SCHEDULER WINDOWS#
If I use a different server, a Windows Server 2016 box running IIS and WebDAV, then the task runs fine via the Task Scheduler.
The credentials are a Domain user account in Active Directory. The client is Windows 10, and the server is Windows 2008 R2. When the command fails I can see an Audit Success Anonymous Logon logon event, an Audit Failure entry which looks like the Anonymous Logon is trying to use SeBackupPrivilege: A privileged service was called.Īnd then an Audit Success Anonymous Logon session destroyed. On the server side I have checked the Security Event log. "Do not store password" is not checked - but I tried checking it just for completeness and it doesn't change the behaviour. I also tried changing the "Configure for" option - again with no effect. I have tried both with and without "Run with highest privileges" set - doesn't seem to change anything. The General Options on the Scheduled Task properties are to run with my domain user account and to "Run whether user is logged on or not". The first command succeeds (and incidentally demonstrates that the scheduled task is running with my identity) but the second command fails, presumably because it isn't using the right credentials to connect.Īfter the task is run, error.txt is empty and output.txt contains "Access is denied." There is no useful information in the task history - just Action Completed and a Last Run Result of (0x1) because the copy failed.
When I run it from Task Scheduler, it fails. When I run this from an interactive login, it works fine, because I have domain credentials which give me access to the share. I have a simple task, which for the purposes of testing, consists of a batch file with two lines: whoami >result1.txtĬopy \\server\share\test1.txt C:\Users\xxx\Documents > output.txt 2> error.txt
0 kommentar(er)
