CODEWITHSUNDEEP
azure-devopsazure-pipelinesazure-pipelines-release-pipeline
Simon_Weaver
Simon_Weaver

Reputation: 146000

VSTS Deployment to a deployment group from a UNC share

I am using visualstudio.com Teams Services to build and deploy an ASP.NET website to two Azure VMs.

I have a build which on completion triggers a release to my two servers in a deployment group. When you configure a Deployment Group for Visual Studio Team Services you create an agent that by default runs as NT AUTHORITY\SYSTEM.

If I publish my build artifacts to Azure (the server option) then everything works fine and deployment succeeds to both my VMS. However when using a file-drop I get the following error:

The artifact directory does not exist: \\MACHINE1\drop\RRStore\20170517.20. It can happen if the password of the account NT AUTHORITY\SYSTEM is changed recently and is not updated for the agent.

This is basically saying MACHINE2 cannot access \\MACHINE1\drop due to permissions. In windows I can bring up this folder just fine, but since the agent is running as NT AUTHORITY\SYSTEM it cannot access it.

I want to use a filedrop because my website is about 250MB (although in the meantime I am using the 'publish to server' option and deploying via team services.)

I am unclear how to give permissions to the file drop though as the agent is running as SYSTEM. I am running as a WORKGROUP and giving permissions to 'Everyone' does not seem to work.

What is the correct way to configure access to a VSTS drop folder so that the deployment agent can access it?

Few possible options:

Upvotes: 0

Views: 959

Answers (1)

zionyx
zionyx

Reputation: 2085

I have similar problems when deploying with VSTS. Instead I chose to:

  • Run VSTS agent on the deployment group VM as a local user with limited access.
  • Impersonate the account on the deployment group VM to test its access to the drop folder.
  • Save/cache a different credential to access the drop folder if applicable. (So the sensitive information stays on the VM.)
  • The cached credentials can be a different local user account created on the drop server just for this purpose.
  • Grant the local user access to various parts of the file system explicitly to limit access permission of this VSTS agent service runner account.

This should work in most cases. In fact, this same way is used in my VSTS, Jenkins and TFS instances. This should prevent you from setting up a domain to solve this problem.

This may not be the best practice, but at least it should get you started in the right direction.

Upvotes: 1

Related Questions