First published on CloudBlogs on Sep, 15 2016
Howdy folks, We receive pretty regular feedback about how the split between our cloud identity systems — work/school accounts in Azure Active Directory and personally owned Microsoft accounts (formerly known as "Live ID" accounts) - can make for some pretty confusing user experiences. In particular, we know many of you have pretty strong feelings about this one particular screen:

Some of the recurring feedback we're hearing:
  1. Developers want to know how to build apps that support both account types.
  2. IT Pro want to know if it's ok to ask employees to create Microsoft accounts using their work email addresses or to bulk provision accounts for them.
  3. Users and employees want to know why they have two accounts with the same email address?
All of these issues are the result of Microsoft having two giant cloud scale identity systems built by different parts of the company. Luckily we've combined those teams and together we are hard at work address these issues. Releasing our new combined Microsoft Authenticator apps for iOS and Android back in August was the first major deliverable from those efforts. This post shares the details of the next set of work we've done to address this confusion. It's written by Ariel Gordon, the PM in my team who's driving the work to converge sign-in/sign-up experiences between our two identity systems. As always, we would love to receive any feedback or suggestions you have! Best regards, Alex Simons (Twitter: @Alex_A_Simons ) Director of Program Management Microsoft Identity Division ----------- Hi everyone, If you follow this blog you know we're doing a lot of work behind the scenes to build a converged identity service that will bring together Azure AD and Microsoft account. It's a complex area and lots of work remains to be done. Today I'd like to tell you about some of the steps we've taken this week to address the overlap between our consumer and enterprise identity systems.

What do we mean by overlap?

Many users have two or more accounts with Microsoft. A personally-owned Microsoft account (formerly known as Live ID) used to access Skype, Office or OneDrive; and an organizational account (in Azure AD) used to access business services such as Office 365 or Power BI. We know from our telemetry data that just over 4M people have a personal Microsoft account with a work/school email address as a username. Why? Our research shows four main drivers:
  1. Some users prefer to use their work email to sign up for everything, out of convenience. This could be Microsoft apps or services, Amazon, eBay, etc.
  2. A handful of Microsoft business services, like MSDN, don't support Azure AD yet and require the use of personal Microsoft accounts
  3. IT departments are asking employees to create personal Microsoft accounts with their work email addresses, or in some rare cases bulk-create these accounts for the employees.
  4. Some students were given a personal Microsoft account when their school switched from the old live@edu program to Office 365.
And when these users' organization has an Azure AD tenant, they may have two Microsoft identities with the same email address.

Why this is bad

Whatever the cause, having a personal Microsoft account with a work address as a username is fraught with issues for end-users and IT departments alike. For example:
  • Users might think that their personal Microsoft account is business-compliant and that they're in compliance when they save business document to their OneDrive
  • Users who leave an organization generally lose access to their work email address. When they do, they may not be able to back into their personal Microsoft account if they forget their password. The flip side is that their IT department could reset their password and get into the personal account of former employees.
  • IT departments have a false sense of account ownership and security. But users only need to roundtrip a code to their work email address once, and can rename their account at any time in the future.
The situation is particularly confusing for users who have two accounts with the same email address (one in Azure AD & one Microsoft account). For example, they are often confronted with this message:

Based on these learnings we've decided to make an important change to how Microsoft account are created.

Blocking Microsoft account sign-up with work email address

Starting today, we're blocking the ability to create a new personal Microsoft account using a work/school email address, when the email domain is configured in Azure AD. What does this mean? If your organization uses Office 365 or other business services from Microsoft that rely on Azure AD, and if you've added a domain name to your Azure AD tenant, users will no longer be able to create a new personal Microsoft account using an email address in your domain. This sign-up block has been running in limited Preview for a hand full of organizations and is now active for all domains names that are configured (DNS-verified) in Azure AD. No action is necessary to enable the block.

What does experience look like?

If you try to sign up for a Microsoft consumer app with a work or school email address, you'll see the message below.

However, if you try to sign up for a Microsoft app that supports personal and work/school accounts , you should see the message below:

To reiterate, this logic will only trigger for an email address in a domain that's registered in an Azure AD tenant. If you don't get one of the error messages above, it means that the app you're signing up for or the domain name of your email are part of an exception list.

Short term exceptions

Unfortunately, there's still a small number of Microsoft business services that don't support Azure AD. The good news is that we're making good progress. For example, Windows Dev Center finished their integration last winter and now supports both personal Microsoft accounts and Azure AD accounts. We're working with other teams such as MSDN and Brand Central to help them add support for Azure AD. Based on feedback we received during the preview, we will not block the ability to use a work email address to sign up for these business services. This is a short-term compromise that's consistent with our main goal of preventing accidental use of work/school email address to sign up for personal Microsoft account.

What about existing accounts?

The sign-up block described here only prevents the creation of new accounts. It has no impact on users who already have a Microsoft account with a work email address. If you are already in this situation, we've made making it easier to rename a personal Microsoft account. This support article provides simple step-by-step guidance. Renaming your personal Microsoft account means changing the username, and does not impact your work email or how you sign in to business services such as Office 365. It also doesn't impact your personal stuff—it just changes the way you sign in to it. You can use another (personal) email address, get a new @outlook.com email address from Microsoft, or use your phone number as a new username. Note: if your IT department asked you to create a personal Microsoft account with your work/school email, for example to access Microsoft business services like Premier Support, then talk to your admin team before renaming your account.

Conclusion and recommendations

These changes are part of bigger investments we're making to converge our identity systems. We'll share more details later this year. If you're an IT pro , do not bulk create personal Microsoft accounts for your employees. We've helped many customers through hard usability and security problems because they had done this. If you're configuring Windows devices for your employees, you should take advantage of the self-service set up and automatic MDM enrollment we've built into Windows 10 using Azure AD. If you're an IT pro , don't ask your employees to create personal Microsoft accounts with their work email address. It creates confusion about who owns the associated content and resources. We understand that there are still a few Microsoft services that require creating personal accounts with a work email address, and as mentioned above we're working hard to address this and have short-term exceptions in place. If you're an end user who has created a personal Microsoft account using your work email at of convenience, please consider renaming your account . If you're an app developer , you should probably support both personal and work accounts from Microsoft. Check out this post to learn more about the work we're going to converge our identity stack s. As always, keep the feedback coming and let us know about other issues and scenarios you'd like us to address. Thanks Ariel Gordon (Twitter: @askariel ) Principal Program Manager Microsoft Identity Division
Occasional Visitor

It is mentioned that using a work email address to sign up for services like MSDN will not be blocked.

So how do you go about signing up for these then? Because everytime we try the message is given that you can't use a work email address to sign up.

Occasional Visitor

I second the post above. I understand what Microsoft is trying to do here, but I don't think that all systems are ready for it yet. I just had a tech come to me and said the he couldn't create a Microsoft Account for a client that we sell Office Perpetual license to that you have to register with a Microsoft Account. The site won't let you use a Work Account and it won't let us setup a Microsoft Account for them. So... what do we have to do... Go and create an Outlook.com account and forward the emails.


This is not acceptable in my book. 

Occasional Visitor

I have several customers who's employees have somehow setup a microsoft personal account with their work email address.  It's causing all kinds of problems with MS apps like outlook and onedrive etc.  I'm trying to figure out how this is happening, because none of them have any idea how or recollection of doing so. .  I know that a new Windows 10 machine will try to push you into a microsoft account, however for all these employees I look at their MS account and see no devices attached to it.  Any ideas? 

Frequent Contributor

It wouls be great to be able to get a report to see which users in your Office 365 tenant actually have a personal account with their work email. They probably experience all kinds of confusion so would be great to get this report so we can reach out to them and help them with their situation.

Occasional Visitor

OK, this story about live.com and AD side being separate doesn't seem to be entirely accurate anymore? I just changed my identity on account.live.com (the "personal" side?) to a secondary mail address. Unfortunately, this ALSO changed my primary identity on account.azure.com. If this is (now?) the same identity behind the scenes -- why not show them as one customer identity (billing????) on the front side?? Wow, this is my third attempt at onboarding my SMB on Microsoft but I will give up in disgust again. PLEASE fix your identity management mess. 

If the user has already accepted the invitation and is unable to login to PartnerCenter, the account may be linked to a personal account:


To resolve the issue, the user will need to rename the personal account (if there are no concerns). There is also a need to clean the up the accounts in the backend. The user will need to be removed from Partner Center and the Azure portal and re-invited to the engagements.


See below for the steps shared with user x@y.com:


              1) Admin user to login to PC account->Users

                                           a. https://partner.microsoft.com/en-us/dashboard/account/usermanagement

              2) Remove user (x@y.com) by clicking on the remove link

              3) Invite user to PartnerCenter

                                           a. Admin user to login to PC account->Users->Add new user

                                           b. Select invite users and enter x@y.com

                                           c. Grant additional permissions(Collaborate->Manager)

                                           d. Submit

              4) If they see the error “User already exists”

                                           a. Global admin user to login to http://portal.azure.com->AAD->Users

                                           b. Remove user (x@y.com) from the AAD tenant

                                           c. The Global admin needs to delete this user completely.

                                           d. Invite user from Partner Center (go to step #3).


When the user accepts the invitation sent to x@y.com. The user will be added to PartnerCenter and also will be added to the AAD tenant (z.onmicrosoft.com).


Note, the above instructions will need to be updated for specific users.

Occasional Visitor

I would love to understand how you use NLA with AAD if the local machine is not domain joined.  It seems like in the Microsoft account case, it is easy out of the box - ie, if the remote machine has NLA turned on, is not AAD domain joined and has the Microsoft account added to it and that account is in either administrator or remote desktop users group, then it can accept a connection from that account from a local computer where the user enters those credentials to connect.


In AAD, this use case is soul crushing - at least for me.  Here is my example:  

I have added Guest user from don.quixote@windmill.com (which is an AAD tenant)  to the AAD tenant holygrail.com   

I have made don.quixote@windmill.com a global admin on holygrail.com


So, on the one hand, Windows 10 tells you how unsecure turning of NLA is - but if I turn it on, then unless the local machine is also domain joined, I am unable to connected to a remote machine that is AAD joined from a local machine that is not with NLA on - but would greatly appreciate any help with the specific procedural documentation as to how the local and remote machines need to be configured to enable this use case. 



Can AAD tenant holygrail.com  guest user don.quixote@windmill.com log into a Windows 10 machine which is joined to holygrail.com as guest user don.quixote@windmill.com  ?


because this use case does not work for me so would appreciate either no this doesn't work in Windows 10 and despite the terabytes of documentation on Azure B2B, it isnt referring to this core feature that is soul crushing me or ….Yes and here is the procedure other than what I have done above.... much appreciated.


I understand that it is possible that the functionality you see with Microsoft accounts and Windows 10 is more complicated when trying to accomplish that with AAD - not sure, because there is almost ZERO documentation out there that hints at this issue - but for example, when you add a Microsoft account to a machine - it shows up everywhere a local account does in terms of being a "user" you can add to groups, etc.  but an AAD account doesn't work that way - you need to add it to groups via command line and again, only when the machine is domain joined and you can only add "users" of the AAD tenant, not guest users of an AAD tenant to an AAD domain joined machine - at least that is my experience.