If like me you’ve been a keen user of Visual Studio Online since it first came into existence way back in 2012 you’ve probably gotten used to using it with Microsoft Accounts (you know, the ones everyone writes “formerly Live ID” after), and when, in 2014, Microsoft enabled the use of Work (or Organisational) Accounts you either thought “that’s nice” and immediately got back to writing code, or went ahead and migrated to Work Accounts.
If you are yet to cutover your Visual Studio Online (VSO) tenant to use Work Accounts, here are a few tips and gotchas to be aware of as part of your switch.
The VSO owner Microsoft Account must be in Azure AD
Yes, you read that correctly.
Azure Active Directory supports the invitation of users from other Azure AD instances as well as users with Microsoft Accounts (MSAs).
If you haven’t added the MSA that is currently listed as “Account owner” on the Settings page of your VSO tenant (https://yourvsotenant.visualstudio.com/_admin/_home/settings) to the Azure Active Directory instance you intend to use for Work Account authentication then you will have problems.
For the duration of the cutover you also need to have the account as an Azure Co-admin. This is because the directory connection process for VSO which you perform via the Azure Management Portal assumes that the user you are logged into the Portal as is also the Account owner of your VSO tenant. If this isn’t the case you’ll see this error:
HTTP403 while loading resource VS27043 from visualstudio : User “email@example.com” is not the account owner of “yourvsotenant”.
Users with MSAs that match their Work Accounts are OK
Many organisations worked around the use of non-Azure AD accounts early on by having users create MSAs with logins matching Work Accounts. As I previously blogged about, it isn’t always possible to do this, but if you organisation has then you’re in a good state (with one draw back).
After you cut over to Azure AD, these users will no longer be able to use their MSA and will have log out and then log back in. When they do so they will be required to select whether they wish to use the MSA or the Work Account for access, which, while painful is hardly the end of the world.
On the upside, the existing Team Project membership the user had with their old MSA is retained as their user identifier (UPN / email address) hasn’t changed.
On the downside the user will need to create new Alternative Credentials in order to access Git repositories they previously had access too. Note that you can’t reuse the old Git credentials you had.
In summary on this one – it is quite a subtle change, particularly as the username is the same, but the password (and login source) changes. Expect to do some hand holding with people who don’t understand that they were not previously using an Azure AD-based identity.
Don’t forget they’ll need to change their Visual Studio settings too by using the ‘Switch User’ option on the bottom left of the “Connect to Team Foundation Server” dialog as shown below.
Don’t delete MSAs until you have mapped user access
Seems simple in hindsight, but deleting an MSA before you know what Team Projects it has access to will mean you can no longer determine which projects the new Work Account needs to be added to.
The easiest way to determine which groups to assign Work Accounts to is to switch to the VSO Admin Security Page (https://yourvsotenant.visualstudio.com/DefaultCollection/_admin/_security#_a=memberOf) and open the User view which will show you Team Project membership. Then for each MSA view the groups it is a member of and add the new Work Account to the same. This is maybe a time to pull access from old projects nobody really uses any more ;).
TFSVC – new user = new workspace
Ah yes, this old chestnut :).
As the Work Account represents a new user it isn’t possible to reuse a previous workspace which does mean… re-syncing code down into a new workspace on your machine again.
The tip here (and for Git also) is that you need to plan the cutover and ensure that developers working on the source trees in your tenant either check-in pending changes, or shelve them for later retrieval and re-application to a new workspace.
Get external users into Azure AD before the cutover
If you need to continue to have MSA logins for customers or third party services, make sure you add them to Azure AD prior to the cutover as this will make life afterwards so much easier.
If you have a large number of developers using MSAs that can’t be disrupted then you should consider adding their MSAs temporarily to Azure AD and then migrate them across gradually.
So there we have it, hopefully some useful content for you to use in your own migration. Do you have tips you want to share? Please go ahead and add them in the comments below.