Visual Studio Team Services and Personal Microsoft Accounts

Visual Studio Team Services and Personal Microsoft Accounts

10/5/2016 Update - Due to the unexpectedly high impact to many corporate VSTS accounts backed by Personal Microsoft accounts, VSTS accounts are temporarily exempted from the scenario described below. Personal Microsoft accounts created from VSTS invite links or on can now be created even if they have the same sign-in name as a Work or School account. This is temporary! Some time in 2017, Personal Microsoft accounts will be permanently blocked if the sign-in name is already in use by a Work or School account.

Please use this extra time to plan your move to one of the 3 options below, and if you are setting up a new VSTS account, please use one of the 3 options below from the start.


Jeff here from the Windows SDK team. I am on temporary assignment to the VSTS group, so this blog post is something a little different.

Microsoft operates two cloud-scale identity systems: Personal Microsoft accounts and Azure Active Directory (AAD).
1. Personal Microsoft accounts (formerly called Live ID). These accounts are meant to be created, managed and used by individuals and are bound to Microsoft’s consumer Terms and Privacy policy.
2. Work or school accounts in Azure AD. These are typically created by IT departments for their users (employees or students). They’re meant to be used to access corporate owned resources such as Office 365 services. They are governable by IT (meaning that IT gets to control and audit the use of these accounts).

When you create a Personal Microsoft account, you either get a new email address from Microsoft (,, etc.) or you can use your own email address or phone number as a sign-in name. Some users have created a Personal Microsoft account with their Work or School email address as a sign-in name. If their organization uses Office 365 or any other business service from Microsoft that relies on Azure AD for authentication, these users will end up with two Microsoft identities with the same sign-in name. When logging on with one of these “Dopplegangers” you may see this dialog:

Starting on 9/15/2016, Microsoft blocked being able to create new Personal Microsoft accounts using a Work or School email address of a domain that’s configured in an Azure AD or Office 365. There are several problems that can arise when you have duplicate Personal/Work or School accounts with the same sign-in name. It is always confusing which account you need or are using, and in some situations it is not possible to choose the correct account. To address these problems, Microsoft no longer lets you create accounts that overlap. This is explained in this blog. Previously created Personal Microsoft accounts will continue to work, though.

Trying to create a duplicate account throws the error: "You can't sign up here with a work or school email address."Error

Impact to Visual Studio Team Services

VSTS has been greatly impacted by this change. Many VSTS accounts are “Personal Microsoft account backed,” this means that you can only logon to VSTS using a Personal Microsoft account. Many businesses have been adding users to Personal Microsoft account backed VSTS accounts by inviting VSTS allows you to invite any user, whether or not the account already exists. In this scenario, the VSTS admin invites a new corporate user,, and they receive the email in their corporate inbox. After receiving the email invite, they are prompted to create a Personal Microsoft account when they try to access VSTS, if needed. Many VSTS administrators assume users will be able to create the new Personal Microsoft account, but since 9/15/2016 this has been blocked. Previously invitees to VSTS successfully created Personal Microsoft accounts with their address, however new invitees may not create a Personal Microsoft account that duplicated the sign-in name of their Work School account.

One of the VSTS program managers shared this with me, as to why using a Personal Microsoft account version of (Work or School account) isn't secure.

"Using a corporate email address to create a personal Microsoft account does not make [it] more or less governable than using a personal email address, but it creates a expectation/perception of governability that has hurt enough customers that we've decided to stop that practice. 

Unlike user accounts in Azure AD,  IT pros have no administrative control of personal Microsoft accounts, regardless of the email address those accounts were created with. They can’t prevent users from changing the account username and they can’t prevent users from continuing to use those accounts after they leave the organization. They can't apply policies to them. They can't delete them. They can't exert any control over what applications are accessed by these accounts. They can’t audit usage and can't validate to authorities any particular use of those accounts. They can’t ask Microsoft to release control of these accounts or of account data."

Now that new duplicate Personal Microsoft accounts are blocked, the only ways for new users to access VSTS are:

1)      Invite users using a real Personal Microsoft account email account (@Hotmail, @Outlook).

2)      Invite users using an email account NOT associated with Azure/O365 (@Gmail, @Yahoo). These users will still need to create a Personal Microsoft account, if they haven’t already.

3)      Create a link between your Azure/O365 AAD and VSTS.

To use options 1 and 2 you need to be OK with @Hotmail, @Gmail, etc. accounts in your VSTS account list. Options 1 and 2 are the easiest, no planning needed.

If you need your VSTS users to only use their corporate email accounts, then you need to use option 3. Option 3 is the more difficult, and requires some thought and planning. Information on linking an AAD and VSTS can be found here.

Some things to watch out for if you link your AAD and VSTS.

1)      External accounts. When you link VSTS and an AAD, only users in the AAD can access VSTS. Corporate users will be fine, but if your VSTS account had any @Hotmail, etc. accounts you will need to add them to your AAD. (When adding a user, choose ‘User with an existing Microsoft Account’.)

2)      Guest accounts. When a VSTS account is backed by Personal Microsoft accounts, there is no concept of guest users, only when you link an AAD to your VSTS account does this show up. Corporate users in the AAD will be members so they are OK, but there are several gotchas with using external Personal Microsoft accounts (guests) with a VSTS account. You can see the user type in the new Azure portal (


  1. Guests can’t search the AAD to add new users VSTS. See this blog for more information and how to use PowerShell to change Guests to Members. Please note: the error message has changed recently, instead of one about AAD guests searching the directory, you will receive the error, “No identities found.”
  2. A guest can’t be assigned ownership of a VSTS account. A guest can still own it, if they owned it before the AAD was linked and you then added their account to the AAD. You could also use PowerShell to switch them to a guest in the AAD (but shouldn’t.)
  3. Guests can be denied all access. There is an option on the settings tab for a VSTS account, External Guest Access. It is set to allow by default, if you set it to deny then no guests can access VSTS. It is possible to have an AAD with only guests in it and in this case no one will be able to access VSTS. You would need to use PowerShell to flip the VSTS owner to be a member, then logon to VSTS and set guest access back to Allow.


Skip to main content