Permissions required to deploy to Azure from Dynamics 365 lifecycle services
Having spent a lot of time recently figuring out the integration between Microsoft Lifecycle services, Azure DevOps and Azure one of the main challenges was removing the user account who had set it all up and link it all together and replace it with a service account.
One area that we kept getting stuck on was the deployment of new Lifecyle services (LCS) dev and test environments to the azure subscription, there was an error between LCS and Azure DevOps:
“User ‘[email protected]’ does not have administrator level privilege to agent pool ‘Default’. Please try again with an account with administrator level privilege or contact support if the issue persists. Follow this link for more information - https://go.microsoft.com/fwlink/?LinklD=817307”
After calls with support and a bit of trial and error the fix was to give administrator permissions on the default build pool to the account at the organisational level (not the project level - that didn’t work).
This goes against the principal of ‘Just Enough Administration’ and seems over the top, but having tried giving the user lots of different permissions at the project level, only organisational level ones fixed the issue.
Setting the correct permission
Steps to grant permissions (note UI will likely be different as they release frequent updates, this is how it’s done as of Oct 2019)
Login to Azure DevOps (formally VSTS) with the organisation owner account (or one that is member of the group set for organisation owner).
Click on Organisational Settings at the bottom left side with the correct organisation selected.
- Select Agent Pools, Click on Default pool
Click on Security then the Add button
Find the user, change the role to Administrator and click Add
The error should now be fixed and you should now be able to deploy to the connected Azure subscription via LCS.
This took a while to sort out especially as the organisation was set up with a user as the owner who happened to be away, so this will be changed to a group to prevent this happening again. The permissions required for the seem excessive and hopefully the LCS team will fix this to at least be project specific or I guess the think it behind it could be because you set up a separate organisation just for your LCS work, at the moment this looks to be the best solution.