After a couple companies merge, we had to build up an AZ DevOps solution from scratch for the new business entity. Unfortunately, at that time we added some users from various companies under their original email addresses (reason: reuse of their VS subscriptions).
Now we need to migrate these users in Azure DevOps from their old bill.smith#oldcompany.com to their new bill.smith#newcompany.com without losing their work and settings. Afterwards the users should be able to log in with their new emails and see everything as if they would log in with their old addresses.
Any ideas how to solve this problem?
You need to open a support case and they can help you out. You get a excel file to map users between the domains and they can map them over in one go.
jessehouwing is right, if you want to migrate data to new Azure DevOps users, you need submit a support ticket here.
But there are something you need pay attention and get ready first:
Do not add them (bill.smith#newcompany.com) to Azure DevOps Service or let them logon to Azure DevOps Service. At this point
Azure DevOps Service support needs to migrate/transfer the users.
Provide a mapping list of users (old user > new user) to Azure DevOps
Service Support.
Azure DevOps Service will transfer identities to the new users. This should add the new account to Azure DevOps Service, assign work items to the new account, assign the Azure DevOps Service license to the new account , and remove the old account from Azure DevOps Service.
Related
We are evaluating Azure DevOps Server 2022, specifically using the Git repositories function. We require an on-premise solution due to some compliance requirements, which is why we aren't using Azure DevOps Services (cloud).
Something I can't wrap my brain around is application of new permissions. We configured some AD security groups and added to the appropriate DevOps groups. We have groups for Collection admins, project admins, build admins, and contributors. Everything looks great until we add a user to one of the groups. It seems the Azure DevOps server doesn't see membership changes until after an unspecified amount of time, sometimes as much as 24 hours.
My question is, why wouldn't group memberships be seen and applied with Azure DevOps immediately, and is there a process to force DevOps to check for and sync/refresh group memberships? Anything I find via a Google search always references Azure AD sync-related configurations, whereas our implementation is strictly on-premise using ADDS, not Azure AD.
Restarting the server and any related services.
TFS/Azure DevOps Server use a background synchronization job, scheduled every hour, to look for changes in Active Directory (or the local machine workgroup if the server is not domain joined). So, changes you make to local or Active Directory groups do not get reflected in TFS/Azure DevOps Server immediately. Instead, TFS/Azure DevOps Server will synchronize those groups regularly (by default every hour).
You can force the job to run using any of these techniques: How to synchronize TFS users with AD.
It could be that you still do not see the user or name listed in the UI even if synchronization is working. The synchronization job does not automatically create a user profile in the database for every user or group in the database, to avoid useless growth in big enterprises.
In such a case, the first time you use a new AD account (user or group), you must refer to it uses DOMAIN\account syntax so that TFS/Azure DevOps Server look up in AD on the fly and insert a profile record in the database for the account.
Further Troubleshooting Mr. Hinsh has a good troubleshooting guide if you still have troubles. It's still applied to Azure DevOps Server.
we use a devops artifact feed to store our packed/shaded java binaries inside a private project. Now we would like to allow access to certain artifacts for externals.
We will promote these artifacts to a custom view (#public-releases) and want to allow access to this view for certain customers only (s.t. they can use it in their automation).
Is it possible to have some kind of service-account/service-principal to assign read-permissions in devops?
I know it the other way round (give devops access to azure ressources via service connections), but now I want to permit access to Devops Feeds.
How would I create such a User? We have azure AD connected, so maybe that is an option?
Is it possible to have some kind of service-account/service-principal
to assign read-permissions in devops?
No, no such design.
Service principal of Azure Active Directory concept can not be managed as an account in DevOps side(DevOps doesn't have such account type, only internal service principal, no AAD service principal).
As you know, service principal of AAD can manage access to services in azure portal. This is the usual usage. Another usage is Authenticate with Azure Active Directory (Azure AD) tokens, this approach can be used to manage PAT of DevOps, but anyway you end up needing to access the feed based on a legitimate account under the DevOps concept.
We've been told by Microsoft support that Azure DevOps Services supports tenant restrictions. While we have tenant restrictions enabled on a number of other services, it does't seem to apply to DevOps. Not only can we still log in to organizations outside of our tenant, we can also log in to our own organization and, if our corp email is added as a user in that org, the organization also shows up. I'd expect that our users would be blocked from logging into or accessing any external orgs.
I'm a little confused about why this isn't just working as expected and despite them saying Azure DevOps Services supports tenant restrictions, I'm not finding much documentation to back that up.
Have you been able to migrate to Azure DevOps Services and ensure that your users are only able to access orgs within your own tenant? How?
Azure DevOps Service supports the Azure Active Directory (Azure AD) tenant policy to restrict users from creating an organization in Azure DevOps. This policy is turned off, by default. You must be an Azure DevOps Administrator in Azure AD to manage this policy.
Check following link for more details:
https://learn.microsoft.com/en-us/azure/devops/organizations/accounts/azure-ad-tenant-policy-restrict-org-creation?view=azure-devops
Notice:
This policy is supported only for company owned (Azure Active
Directory) organizations. Users creating organization using their
personal account (MSA or GitHub) have no restrictions.
https://devblogs.microsoft.com/devops/policy-support-to-restrict-creating-new-azure-devops-organizations/
We finally received a more concrete answer to this question from Premier Support. Sounds like this wasn't entirely clear internally either. Azure DevOps Services supports TRv1 which provides tenant restrictions from client to proxy, but does not support TRv2 tenant restrictions which provides server to server restrictions. TRv1 will prevent you from authenticating against an org outside your tenant directly but does nothing to prevent the background authentication that happens if your account is configured to be able to access a secondary tenant's org. The server to server connection strips off the header information necessary to restrict you from accessing the secondary tenant. While this feature may be on their radar there is no expectation or firm timeline for it's release at this time.
I have created an organization on Azure DevOps with my email id ( created by me) which is the same as my email id associated with my azure subscription.
I want to create an organization with the name and URL what I created with my personal account in Microsoft associated account.
I deleted one which I created and tried creating by login as a Work Account, however, I get an error organization already exits.
How can I get it resolved?
Azure DevOps can be linked to an Azure Active Directory. In your situation, I strongly suggest you do the following steps to link it and transfer the ownership to your work account:
Make sure you can fully control both your work account and your personal Microsoft account.
Link your existing Azure DevOps organization to your Azure Active Directory.
Add your work account as an administrator in your Azure DevOps organization.
Transfer the ownership of the organization to your work account.
Kick your personal account out.
Here are some tips:
You can link existing Azure Active Directory like this:
You can change the ownership of your Azure DevOps organization like this:
Backup solution
Of course, you can delete the entire Azure DevOps organization and recreate it. To delete it, make sure all your data is safe. And press the Delete button in the Overview settings.
After deleting it and you can re-create a new organization with the same name using your work account.
I was playing around to learn the feature and concept on Azure DevOps services.
And I created one Azure DevOps Organization using my MSA account and connected it to my Azure Active Directory (as I have a pay-as-you-go subscription using my MSA account).
I then disconnected it from Azure Active Directory so it (forced) logged me out of the Azure DevOps portal. I was thinking that I will disconnect and connect it back to AAD. But apparently that's not how it works... and I found out in a very rude way.
After that I was unable to login to the Azure DevOps service portal using my MSA ID. And here is the error page:
I was able to somehow get over the issue by creating a new org using the organization list link provided on the error page.
But now my question is, I do see my old DevOps Organization on Azure
DevOps Service portal which I am unable to access. Its sort of orphaned Org and just hanging there. Now how do I get rid of
it or delete it?
what is happening is that azure devops is not able to sync up with your AAD. The reason it is showing "not authorized error" is because it can't identify whether the same tenant is trying to connect(when you're logging in) to the project and the project is in the AAD parallely, so that is creating the miscommunication between your tenant, AAD and devops organisation.
Sign out, and then open your browser in a private session and sign in to your organization with your Azure AD, MSA or work credentials.