I am trying to set up a deployment agent on a server.
The process is failing with the message "No agent pool found with identifier 61".
Looking at the logs I can see the following
INFO DeploymentGroupAgentConfigProvider] Found deployment group Web Servers with id 23
INFO DeploymentGroupAgentConfigProvider] PoolId for deployment group 'Web Servers' is '61'.
This would suggest the server is connecting as it can find the deployment group id but not that of the pool.
This ties in with the fact that although I can see the relevant Deployment Group in DevOps, I cannot see the corresponding Deployment Pool.
My account is registered as a collection administrator which I would have thought would be enough to give me visibility of everything.
Also a colleague, who is also a collection administrator, CAN see the Deployment Pools which I can't.
Anyone got any idea why that might be?
When Googling for help on Deployment Groups and Pools, I found loads of information about Build Agents but not Deployment Agents and Pools.
Does anyone have a definitive resource for giving guidance on Deployment Groups and Pools, how they relate, how they differ and how they are administered?
Thanks
Link to the Deployment group documentation.
Deployment group is basically a specialized agent pool, only usable with classic release definitions, and provide some extra functionality, like which deployment group agent to use in which stage. You can't use them with multistage yaml-pipelines, which is good to keep in mind.
Not sure how you are installing and configuring you agent as you are not seeing the actual deployment groups, but there is a specific switches in the agent installation command for deployment groups:
.\config.cmd --deploymentpool --deploymentpoolname "WebAppDemo-deployment-group-1" --agent $env:COMPUTERNAME --runasservice --work '_work' --url 'https://dev.azure.com/myorg/
Which might explain your errors. When creating a new deployment group, it inherits some groups from the azdo project, so maybe check if you are part of those: Contributors, Deployment Group Adminstrators, Project Administrators, Release Adminstrators. Can't remember how the agent configuration authenticates if you are not using a PAT-token, but I'd guess that you basically can't authenticate in the agent config with those deployment group switches unless you rights to that group, or someone who has the rights have created a PAT-token for you.
If you do get rights to the deployment group, you can find an autogenerated installation script for agents there. I never got it to work out of the box back in the days (*, but you can at least copy the config command from there and run it manually.
*) When Azure DevOps Server was launched, haven't really used deployment groups in three years, so my info might be a bit outdated.
#JakkaK
Thanks for the response.
I have seen the Deployment group documentation page you referenced however I believe we have taken everything on that into account so I was looking for alternatives to get other view points.
In terms of security I have added myself to
Contributors
Deployment Group Adminstrators
Project Administrators
Release Adminstrators
The agent installation command/switch combo I used was
.\config.cmd --gituseschannel --deploymentgroup --deploymentgroupname "My Deployment Group" --agent $env:COMPUTERNAME --runasservice --work '_work' --url 'https://MyOrg.co.uk/tfs/' --collectionname 'MyCollection' --projectname 'My Project';
I tried the agent installation command/switch combo suggested and got the message
Access denied. <<User>> needs Manage permissions for pool "My Deployment Pool" to perform the action. For more information, contact the Azure DevOps Server administrator.
Given that I am in all the Security Groups listed about this makes no sense.
One thing I have noticed is that, when creating a Development Group the Development Pool name defaults to "Project Name-Development Group Name".
The Project portion of the Deployment Pool I am trying to connect to indicates to me that the Project Name has been altered since the Deployment Group was created.
ie
The project is called "BBB Project Name"
The Deployment Pool which, as I have stated above appears to be set by a default format, is called "AAA BBB Project Name-Development Group Name".
i.e. the project looks like it has been renamed from "AAA BBB Project Name" to "BBB Project Name".
You'd like to think that relationships were by identifiers rahter then names but I'm wondering if that would cause this issue.
Related
In the documentation page Create and manage agent pools, there's a table listing the different security roles related that are available for agent pools.
It's divided to "Roles on an agent pool in project settings" and "Roles on an agent pool in organization settings".
In the "Roles on an agent pool in project settings", there's a role "User":
Members of this role can use the project agent pool when authoring pipelines.
I can't understand what this means.
First, it's not very clear what it means to "Author a pipeline".
Let's assume that it means creating a build definition. If so, then in order to "author" a pipeline a user must be in the "Build Administrators" group, and the "Build Administrators" group is automatically assigned a "Administrator" role on each agent pool in the project:
Turns out so, that if you have the permissions to author a pipeline (again, assuming that it means creating a build definition), you're automatically assigned an "Administrator" role on that agent pool.
Can someone explain?
Author a pipeline means that when creating a pipeline you could use this agent with the user role on the agent pool in project settings. For example, when you first run a yaml pipeline using this agent, you need to have user permission to permit it:
In order to create a pipeline, users do not need to be in "Build Administrator". Give user Edit build pipeline and Queue builds permission by setting pipeline permission in Pipeline >> Manage security button. Then user can create pipelines and save any changes to a build pipeline, including configuration variables, triggers, repositories, and retention policy. Please refer to Pipeline permissions reference.
Thanks to #JaneMa-MSFT, I realized that I can allow the user to create pipelines without being a member of the "Build Administrators" - one easy way is to assign it as a member of the "Contributors" group, which by default has permissions to create pipelines, so it is a possibility to be able to "author" a pipeline, and yet not have "User" role on the agent pool.
So what I found out is, that it doesn't really matter who "authored" the pipeline - i.e. created it. The effect of being a "User" on that agent pool (in the project level) is the ability to permit the pipeline to use that agent pool. By the way - if that agent pool is marked as "Grant access permissions to all pipelines" - this role doesn't have any meaning for that pipeline!
I am having a hard time understanding how the Agent Pool security for a Team Project works or is populated. I think I am missing a basic construct.
I would like to grant the following access rights at the Project Level:
Contributors - role: User
Project Mini Administrators (custom group) - role: Administrator
Here is what I did:
From Project settings, I clicked on Agent Pools and then the Security button.
I added the two above referenced groups.
If I then click on one of the Agent Pools listed on this screen and select Security, I can see that Inheritance is on but my new groups are not listed for the selected Pool.
What am I missing? If a Contributor or Project Mini Administrator go to a Build Definition in the Team Project and attempt to drop down the Agent list, they do not see any of the Agents; as if they had no security to the Agents. If I manually add the to all of the Agents individually, they things work as expected. Its almost as if the inheritance chain from the Agent Pool Security to the Agent is not propagating.
As per Documentation, there is (was) and All Agents node that would assign the selected user the specified role for all agent pools.
With the new layout of portions of the project settings UI, this node is accessed via the Security button on the Agent Pools landing page where all pools for the project are listed.
Role assignment for a specific pool should happen from the security view of that pool.
Looking at the Agent Pool security for the entire organization will show you the older UI that is more consistent with the vocabulary of the documentation.
I provided feedback for this problem on Microsoft's Developer Community site. Microsoft confirmed that this was an issue and is working on a fix.
I get following error when trying to save a release pipeline on Azure dev. What exact permissions do I need to ask from my administrator?
Access denied. <<user id>> needs Use permissions for pool Default to perform the action. For more information, contact the Azure DevOps Server administrator.
I found granting Admin to a pool very confusing (and time-consuming to resolve) but I think I can explain how I got it to work for my org. This is a further explanation, based upon what #Leo Lui-MSFT said, as that was not quite clear enough for me.
My problem: I wanted to give a user access to update a pool that the user had not created (ie, was not an Owner).
Attempted solution: Making the user Admin on the pool did not let the user do that.
Successful solution: I had to go to https://dev.azure.com/my-org/_settings/agentpools > Security > Add . I then added the user and assigned the Admin role.
This has the side effect of giving the user Admin on every pool in the org (which was not what I wanted to do). If this is not your desire then go into the pool you do not wish to grant Admin access to, set Inheritance off and then remove the user from that pool.
This feels wrong, to me. I should have been able to make a user an Admin of a single pool without granting org-wide Admin over all pools.
Also as all pools seem to be created with Inheritance defaulted to true then to remove that user as an Admin from all other pools could be time-consuming and when more pools are created then I would need to remember to turn inheritance off.
That is my experience. If I have missed something please let me know.
What exact permissions do I need to ask from my administrator?
You need ask the User permissions from administrator.
When we go to Project Settings->Agent pools->The Agent Name->Security:
Check the document Security of agent pools for some more details.
Roles are also defined on each organization agent pool, and
memberships in these roles govern what operations you can perform on
an agent pool.
The All agent pools node in the Agent pools tab is used to control the
security of all project agent pools in a project. Role memberships for
individual project agent pools are automatically inherited from those
of the 'All agent pools' node. By default, the following groups are
added to the Administrator role of 'All agent pools': Build
Administrators, Release Administrators, Project Administrators.
So, you should ask User permissions from your administrator, or add your account to one of the groups mentioned above, then try it again.
I used -e AZP_POOL=XXX parameter when docker run to solve the same issue, even my account is an administrator.
Check if you are entering the pool name correctly. If you pressed 'Enter' to keep the default name for the pool, it does not work, you need to specify the correct name for the agent pool
I had similar problem with a Pipeline:
Error: Access Denied: 0000000d-0000-8888-8000-000000000000 needs the following permission(s) on the resource /Organizations to perform this action: Read Organization resources
I created again service connections and change this in the pipeline:
I think this user was delete from active directory.
(I realize this question is regarding DevOps but DevOps Server / TFS may have different interface but encounter the same issue)
In TFS or DevOps Server, you have to be added to Team Foundation Administrators group through TFS Admin Console only. To do that:
Access Team Foundation Server Administration Console via Server > Application Tier > Group Membership > Team Foundation Administrators > Properties > Add user.
You should have an organization level access to get rid of the error message you are getting.
If you've created the organization you will be the owner of the organization, you should have all the admin access to do whatever your pipeline need.
otherwise, Select the organization -> Go to organization settings -> agent pool [left plane] -> security [right top] -> add a new user with your name with admin role
Try the same with project level settings.
I have an Azure DevOps release pipeline which deploys a resource group. I have switched the service connection that is assigned to the Create Resource Group task to a different service principal, and now deploying the resource group (after deleting it) succeeds, but I can no longer see it in the portal. Previously, the RG made me a Contributor implicitly without me having to do anything. I am the owner of the release pipeline.
Why does changing the service principal that deploys the resource group give the resource group a different set of role assignments and how do I control the set of role assignments applied to the resource group when it is created so that I am made an Owner? I don't inherit any Owner permissions from the susbcription because I'm not an admin user, any permissions I have - which I still have against an identical resource group - were assigned directly to the RG on its creation, but I can't see how that happens.
you dont have enough permissions. it doesnt have to do anything with Azure Devops. Azure Devops doesnt assign any permissions to the created resource group to the pipeline owner (or anybody else).
one reason why that might happen - you filtered out the subscription the resource group is in. (like tom mentioned in the comment)
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:
Set up a domain (I tried doing this but then I need a new network interface and it sounds klunky)
Continue using teamservices to deploy the artifacts (or reduce the website size!)
Save to a storage account, but again I'm not sure how to configure that.
Run as a different user account
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.