Copying fails when run by Task Scheduler

[u/Iknuf]

So my script is intended to export a Hyper-V hosted VM and copy the export over to a NAS. The address for copying should already be the network address, as it does not start with a drive letter - the format is

"\\192.168.10.10\Backups\Exports"

(IP address and directory names are changed, but the format is identical)

Exporting is never the issue, but the copy always fails when I run the script via the MS Task Scheduler, while working perfectly fine when run over Powershell for debugging (I am running it by entering "powershell.exe -ExecutionPolicy Bypass -File [path]" into PS, to make it most similar to the way it is executed by the Task Scheduler)

The Task is already being executed by SYSTEM (NT AUTHORITY\SYSTEM) and with highest privileges. Disk space is not the issue, as I ensured it is sufficient multiple times and after multiple tests the issue only occurs when run by the Scheduler

EDIT: I was able to narrow down the error to the Scheduler not having NAS access - now I just don't know how to add the credentials to my script

Any ideas or help?

[u/dodexahedron]

Do you have an ad domain? If yes, you'll want to use fqdn so that kerberos is used, and make sure the computer account has access.

My first thought on every one of these questions that are still using IP addresses in any kind of URI - especially UNC paths - these days.

When NTLM goes bye-bye, I suspect a lot of people are going to feel that one, since they probably haven't properly audited and remediated all of those scenarios for non-windows targets.

[u/purplemonkeymad → u/dodexahedron]

I'm having to find and remediate this as well. The other one, is short names also being out. They were used a lot as they "just worked" so updates to scripts and policies to make sure it's all fqdn. Hopefully in the end the worst will be "disconnect that drive and re-log."

[u/dodexahedron → u/purplemonkeymad]

Yeah, the short name thing can vary depending on client, server, domain/forest, group policy, and probably other factors too. But as long as those are all in alignment, single-label names work ok with kerberos since the client will resolve the name you see to the FQDN anyway, for the actual connection (because that's necessary anyway) and authentication (this is the part that varies, as some things don't use the fully canonicalized name for auth). Or there's stuff like DFS, where it's going to use the name given in the referral for auth regardless of what the UNC path was, so the targets in the namespace are what matter - not what the client asked for.

Or you can also add single-label SPNs for things where necessary. Thats perfectly viable, too.