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.
Long time ago, I also created an “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 “shiny” dynamic group based on the “UserType” attribute.
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 Source was “Unknown” and the 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:
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.
https://cloudblogs.microsoft.com/enterprisemobility/2014/08/15/prepping-for-new-management-features/
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:
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.
Conclusion:
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).
/Enjoy.
8 Comments
Great post Ronni! Somebody forgot to fix this at Micrososft 🙁
Excellent! You are a superstar! 🙂
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…
Thanks, found this informational..even in 2019.
Looks like even accounts when migrated from on-prem after that date may also have this issue.
(WhenCreated: 2015-03-25 22:28)
Hi Ronni!
Just used you guide. Thanks a lot saved my day
See you out there
You’ll need to update this blog as the Set-MsolUser command has been deprecated, and now need to use Set-AzureADUser.
Correct Daniel Wilkins – the following sequence of commands worked for me:
1) First Run Windows PowerShell with Admin rights
2) Then run: Connect-AzureAd and login with your Global Administrator account
3) Then get overview with command: Get-AzureADUser -Top 100
4) Then add member usertype for the affected accounts with the following command:
Set-AzureADUser -UserPrincipalName username@contoso.onmicrosoft.com -UserType Member