chrisism
commented
7 years ago Thanks for your input. Why don't you let the agent run under a local user or domain user that has access rights? At my current company we have a custom domain user that is allowed just enough and we have configured the agent to run under that context. I would advise against using "Network service" or any of the default user contexts for the service. It is easier to set the rights on a folder to a specific user. That being said, I will have a look in how I can achieve this.
ygeelen-tb
@chrisism thank you for your great work on this task. We're experiencing a minor issue.
We do local deployments by installing the VSTS Agent locally on the target machine. The agent runs under the built-in Windows service account "Network Service". It seems that we need to grant the "Network Service" user Modify rights on the target deployment folder for Robocopy task to work? Otherwise we get an Access Denied error.
Although this is a fix, we don't like this security-wise. And we'd like to avoid doing a "net use" command because this requires converting the target deployment folder to a network share which requires extra configuration work and slows down the deployment.
Perhaps you could include 2 parameters in the task so the credentials to run robocopy under can be chosen independent of the credentials the VSTS Agent runs under? Or if you have a better idea?