Missing “UserType” attribute in Azure AD


navigate to this website Over the years, I’ve created multiple labs, so that I can test different scenarios. One of my first “cloud only” Azure AD labs was created back in 2012. Two weeks ago, I wanted to use this lab to test a new Conditional Access scenario that one of my customers needed.

http://www.hawkerucc.org/monaxinja/3491 Long time ago, I also created an “ i loved this All Users” group, that was based on direct membership, so I thought it was a good idea to replace that group with a new and “ Visit Website shiny” dynamic group based on the “ http://sport-hippique.nl/malynok/5269 UserType” attribute.

http://theeasybreezyway.com/?parkyw=conocer-gente-playa&9d3=50 So, I created the following group, and started to redeploy all my policies to the new group.


But the policy didn’t get applied. At least not to my test user.

I checked the group and for some reason my test user wasn’t added as a member to the new dynamic group. By checking the properties of the user, I learned that the http://www.tsv-warthausen.de/prikotre/3418 Source was “Unknown” and the blog link User Type was “blank”.


I then pulled a list of all the users in my test lab (Get-AzureADUser), and two user accounts didn’t have a “UserType” specified. All other users was ok.


I fixed the users by setting the “UserType” to “Member” by running the following PowerShell command:

look at here Set-MsolUser -UserPrincipalName username@contoso.onmicrosoft.com -UserType Member

This fixed both the missing “UserType” and the “Source”.

I finally found this article that says “UserType” (Guest/Member) was first introduced on August 31st 2014.


So basically, this means that all you Azure AD User accounts that was created before this date might be affected by this issue. You can identify the creation date by running the following PowerShell command:

my response Get-MSOLUser -All | Select DisplayName, UserPrincipalName, WhenCreated


Like we would expect, the 2 users with the missing “UserType” property where both created before August 31st, 2014.


As you can guess this will most likely be an issue for many customer, so I contacted Microsoft Support, that said they will escalate this to find a solution that will help other customers fixe this.

Meanwhile… If you have an Azure AD that was created before August 2014, and want to use this attribute you might want to check the state of the user settings, and fix it yourself (the documented fix here is fully supported).


About Author

My name is Ronni Pedersen and I'm currently working as a Cloud Solution Architect at EG A/S in Denmark. My primary focus is Enterprise Client Management solutions, based on technologies like AzureAD, Intune, EMS and System Center Configuration Manager. I'm is also a Microsoft Certified Trainer and Microsoft MVP in Enterprise Mobility.


  1. Thank you Ronni – here I am in late 2018 (4 years after you wrote this) and I have this exact issue – seems like it has never been fixed.

    • You might have had this issue for a long time, and I don’t think they will change/fix this for existing tenants, as it might have some consequences to your environment. But this just my guess…

Leave A Reply