Azure DevOps: How to manage VM agents when multiple projects deploy to the same virtual machine

Question

I'm experimenting with multistage Azure pipelines, deploying to Windows virtual machines. Since multistage pipelines don't support deployment groups I'm using environments. Although adding a VM resource to an environment is very similar to adding a target to a deployment group, I notice the naming conventions are slightly different.

When the PowerShell script runs to create an agent that is the target of a deployment group, the Windows service that's created is named vstsagent.{organisation name}.{project name}.{target VM name}. That makes the Windows service name unique to each project.

When the PowerShell script runs to create an agent that is the resource of an environment, the Windows service that's created is named vstsagent.{organisation name}..{target VM name} by default. That means by default all projects in the same organisation that deploy to the same VM will use the same Windows service name for the agent.

I have frequent problems when I already have a VM agent set up for project and want to add a resource to a second project in the same organisation that points to the same VM.

When the PowerShell script runs on the VM to create the second agent it recognises there is already a service with the same name, vstsagent.{organisation name}..{target VM name}, on the server, and tries to replace it. This fails about 25% of the time. In that case I've tried to manually remove the existing Windows service, using .\config remove from PowerShell, then re-run the second agent's PowerShell script. The PowerShell script appears to run without error, and says it has registered the agent. However, now if I try to run the pipeline in either the first or second project it fails, saying "Unable to deploy to the virtual machine '{target VM name}' as the machine is offline.". So I end up with two projects I can no longer deploy.

Deploying several projects to the same VM must be relatively common. What is the best way of dealing with this situation, where the PowerShell script trying to create a second agent fails to replace the existing agent? Is there some way to force the script to just use the existing agent without trying to replace it? Or, in the Azure DevOps GUI when adding a resource to an environment, is there some way to specify that I want to reuse a resource/agent from another project?

Answer 1

I can reproduce the same issue. You can report this issue to Microsoft development team.

Currently you can manually change the agent name as a workaround before you run the installation scripts.

The agent name was set to VM's name by default --agent $env:COMPUTERNAME. You can change the dafault agent name. eg. --agent $env:COMPUTERNAME-SecondProject. See below:

.

This will solve the service name confliction, for a new service name will be created.