Background tasks on Win32 default to running in a security context that doesn't allow access to network resources, even if the task is "run as a user" that normally has access to network resources.
Some background task runners support some customization of the security context to use (such as different levels of "impersonation") but I'm not sure even that would allow you to bypass this security restriction.
| [reply] |
> any ideas as to why this behaves so badly?
System commands can be troublesome, especially on Windows. Usually, it is better to avoid them unless there is no other way. In this case, Win32::NetResource would likely work much better.
Anima Legato .oO all things connect through the motion of the mind
| [reply] |
| [reply] |
Hi,
I do run as the same user interactively as I set as the owner of the scheduled task. I wrote the value of the scalar value of the `net use ...` command (which I mistook as the error code), and have modified it to write out the $? value, which I see now is equal to 512. Any ideas with this new tidbit?
Thanks,
Matt
| [reply] |
Update on this problem: the drive mount is now working in this scheduled task after my administrator bounced the server on which I was having problems. The consensus around here was that the drive was not mapping because some old, conflicting mapping or credentials were cached. Thank you to everybody for their help. Matt
| [reply] |