Issue:
"The user doesn't have access to the variable groups added to this pipeline or they are not found. IDs: 3"
When this happens:
Migrating a Pipeline in "Json" format from "Azure DevOps On-premise 2020" towards "Azure DevOps Cloud".
When saving all changes is complaining that no access for the user towards "Variables Groups" that seems to be counter-intuitive because those were created with my user while doing the Import, i.e did create the same "Variables and Values" for the consumption of the Pipeline
Solutions Offered and Applied:
Some documentation indicated to do the next:
"So you just need to add "Project Collection Build Service(xxx)" account as Administrator role for the variable group."
I followed this and added the "Project Collection Build Service" from "read" to "Administrator" but the same error output is presented.
This is not definitively an answer, but one thing to check is whether or not access is allowed to all pipelines:
I don't see that checkbox in your screenshot. If Allow access to all pipelines is not set, or not settable, Microsoft recommend manually queueing a build - if there's a resource authorization error, you should be able to select it and authorize access to the pipeline that's being executed.
State:
Solved
Solution Details:
It seems MS/Azure DevOps hashed each link to a variable group dependant on the Collection, so when migration takes place the current links migrated are completely useless,
The right action would be in that sense to undo the links are re-create them from scratch again.
This will save a lot of time for other folks with the same issue, enjoy!
Related
In Azure DevOps, we are trying to start a deploy to an environment. According to the policy, one approver must approve this.
After a person has given approval, the deploy is not started and Azure Devops keeps saying that at least 1 approver must approve. See the screenshot below, which shows that contradictory information is given. (A second approver also opened the page, by the way, but did not have the option to give approval... Probably because it was already given and so all approval requirements are met.)
We also tried changing the configuration, such that not one person in the list but rather a person in a group had to give approval. The same problem occurred, as seen in the screenshow below.
Does anyone know what could be wrong here? The information from Azure DevOps is contradictory with itself.
(Interesting detail is that this has worked until recently. We have no idea why it's suddenly broken.)
Please Click the "TST" resource to check the advanced setting, check if enable the "Allow approvers to approve their own runs".
And try to remove it and create a new "Approvals and checks" and to check if it works.
For more information, you could refer to approvals.
I would like to allow all members of the organization in Azure DevOps to view all projects (become Readers).
I tried to set up a group rule on the organization settings page.
Group: "Project Collection Valid Users"
Access level: Stakeholder
Projects: Selected them all, and picked Readers for each one.
After that I clicked on Add.
Now, when I try to view the rule I just made with "Manage rule", the project settings have been cleared.
If I select the projects again, and pick Readers, then save, the same thing happens.
Why do the settings disappear?
Also, if I do "Re-evaluate Rules", it runs for a bit. But none of the existing users regardless of their Access level have gotten Reader access to any project.
However, using "Manage user" -> Group rules, the group rule is listed.
So the group rule is applied but the project settings are not working for some reason? How do I fix this?
I chose a different group from AD instead of "Project Collection Valid Users" and now it seems to work as expected.
Using "Project Collection Valid Users" in this context seems to bring some bugs or unexpected behaviour.
I've had a standalone Azure Devops Organisation (call it MyOrg1) for quite a while, and I've recently linked it to my Azure Active Directory, and set my Azure AD user myname#my-azure-ad as the organisation owner.
This seemed to work ok. I can go directly to the URL dev.azure.com/MyOrg1, and see all my projects etc. All good so far.
The problem is that if instead I go directly to dev.azure.com, and login as my Azure AD user, it doesn't seem to recognise that this user is already associated with an existing devops account. It instead prompts me with the "Get started with Azure DevOps" screen with the option to "Continue".
If I choose "Continue" it then creates a new Organization for me like "[myname]1234".
So far this is mostly just a nuisance, but not a huge problem. However the more significant problem is that in Visual Studio, I'm not able to see MyOrg1. It will only list the new organisation "[myname]1234". If I attempt to manually add the server URL "dev.azure.com/MyOrg1" it won't work, and doesn't seem to recognise that the user myname#my-azure-ad has access to this organisation.
It shows the message "To access an Azure DevOps account, login using the picker above". The picker already shows my user myname#my-azure-ad
In the MyOrg1 organization settings, I can see that my account is definitely listed as the organisation owner, and I can see that my Azure AD is definitely linked.
I can't figure out what could be wrong. Everything looks correct, but it just doesn't work.
Just in case it makes a difference, organisation MyOrg1 is in a different region to my Azure AD. I can't really see why that would matter though, since it seemed to link it just fine.
I managed to correct the issue by doing the following...
Create a new Global Admin user account in AAD
Add this user to the DevOps organisation and set as owner
Remove my original myname#my-azure-ad from the DevOps org
Re-add myname#my-azure-ad to the org and re-assign as the owner
The only thing I can conclude is that because myname#my-azure-ad was originally added to the org before the org was linked to the AAD that this must have messed something up.
In the Azure DevOps project I'm currently working on, I am unable to use the # mention feature and am not able to assign work items to other users because no users are ever found. I am aware that you should be able to search for other users if they don't initially show-up in the drop-down list, but searching always returns "No identities found".
Other members of my team that have elevated permissions than I do can use these features because they are able to search for any other user in the same Azure DevOps project. My project administrator gave-up trying to figure-out why these features won't work for me.
Is there a setting in the Azure DevOps Project Settings Permissions that enables or disables the ability to view other user names?
Here is an example of me trying to look-up my own name to assign a bug to myself without success:
And here is an example of me trying to #mention a user in a bug discussion section without success:
* Update *
When my project administrator gives me project administrator rights, I am able to #mention others. Obviously, that isn't the desired user level for a non admin like myself.
I was trying to follow this tutorial here from official Microsoft Docs in order to give in a specific user group a role.
https://learn.microsoft.com/en-us/azure/active-directory/role-based-access-control-configure
I want that role to be applied on subscription level. First, the screenshots are outdated and they are not represent the current portal. Second, the current portal seems to be unable to find the user groups through the search.
After searching and changing a lot of things I had realized that the issue wasn't on my action but on Azure portal. I gave up the portal and I started trying PowerShell and it works as it is expected to work.
https://learn.microsoft.com/en-us/azure/active-directory/role-based-access-control-manage-access-powershell
Therefore, save your time and use PowerShell instead of portal in case that you want to set a role in a user group. Again, there is no specific command as far as it concerns subscription level access. You need to modify a bit the one for Resource Groups and add -Scope. Your final command should be this:
New-AzureRmRoleAssignment -ObjectId $userGroupId -RoleDefinitionName 'Reader' -scope '/subscriptions/{Change_To_Subscription_ID}'