Close Menu
    Facebook X (Twitter) Instagram
    Trending
    • Successful Adoption of a “Cloud First” Strategy
    • Speaking at Nordic Virtual Summit
    • Workplace Ninja User Group Denmark February Meetup
    • Workplace Ninja User Group Denmark Meetup – May 2022
    • Workplace Ninja User Group Denmark Meetup – April 2022
    • Speaking at Modern Endpoint Management Summit 2022
    • Speaking at Nordic Virtual Summit 2022 – 3nd Edition
    • CoLabora Recordings – January 2022
    RONNIPEDERSEN.COM
    • Home
    • Enterprise Mobility
      • Configuration Manager
      • Identity and Access
      • Information Protection
      • Intune
    • Cloud and Data Center
      • Data Center Management
      • Group Policy
      • Enterprise Security
      • Hyper-V
      • PowerShell
    • Guides
    • Webcasts
    • Links
    • About
      • Contact me
      • Disclaimer
    RONNIPEDERSEN.COM
    You are at:Home»Enterprise Mobility»Missing “UserType” attribute in Azure AD

    Missing “UserType” attribute in Azure AD

    11
    By Ronni Pedersen on October 30, 2017 Enterprise Mobility, Identity and Access, Intune, PowerShell

    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.

    SNAGHTML15204371

    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”.

    SNAGHTML1520a642

    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.

    SNAGHTML1520fc70

    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

    clip_image007

    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.

    • Tweet
    • Share 0
    • +1
    • LinkedIn 0

    Related

    Ronni Pedersen
    • Website
    • Facebook
    • X (Twitter)
    • LinkedIn

    My name is Ronni Pedersen and I'm currently working as a Cloud Architect at APENTO 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.

    Related Posts

    Speaking at Nordic Virtual Summit

    Workplace Ninja User Group Denmark February Meetup

    Speaking at Modern Endpoint Management Summit 2022

    11 Comments

    1. Peter Selch Dahl on November 1, 2017 09:14

      Great post Ronni! Somebody forgot to fix this at Micrososft 🙁

      Reply
      • Stellan Rönnkvist on August 15, 2018 14:47

        Excellent! You are a superstar! 🙂

        Reply
    2. Bob on October 5, 2018 18:14

      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.

      Reply
      • Ronni Pedersen on October 15, 2018 06:58

        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…

        Reply
    3. Tanya on February 13, 2019 19:53

      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)

      Reply
    4. Stefan B. Christensen on April 30, 2019 16:01

      Hi Ronni!

      Just used you guide. Thanks a lot saved my day

      See you out there

      Reply
    5. Daniel Wilkins on January 21, 2020 12:36

      You’ll need to update this blog as the Set-MsolUser command has been deprecated, and now need to use Set-AzureADUser.

      Reply
      • Thomas Lassen on April 9, 2020 02:25

        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

        Reply
    6. Adam Wheewall on December 8, 2020 17:10

      I guess MS couldn’t be bothered to fix, it’s 3 years later and the problem persists. Just ran into this issue, so thanks for this page. Much appreciated.

      Reply
    7. Sam on November 30, 2021 16:30

      You can knock them all out at once with this, as long as you are sure none of them are pre-2014 guests:

      Get-MSOLUser -All | Where-Object -Property UserType -EQ $null | Set-MsolUser -UserType Member

      Reply
    8. JB on January 4, 2022 05:53

      Still helpful, over 4 years later. Thanks!

      Reply
    Leave A Reply Cancel Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.

    Follow
    APENTO

    Follow APENTO here:

    Subscribe to Blog via Email

    Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    About
    My name i s Ronni Pedersen and I'm currently working as a Cloud Architect at APENTO in Denmark. My primary focus is Endpoint Management and Security, based on Microsoft technologies. I'm also a Microsoft Certified Trainer and a dual Microsoft MVP in both Security and Windows.
    Recent Posts
    • Successful Adoption of a “Cloud First” Strategy
    • Speaking at Nordic Virtual Summit
    • Workplace Ninja User Group Denmark February Meetup
    • Workplace Ninja User Group Denmark Meetup – May 2022
    • Workplace Ninja User Group Denmark Meetup – April 2022
    Archives
    TOP POSTS
    • SCCM: Failed to Get Client Identity (80004005)
    • Setting OSDComputerName using CustomSettings.ini
    • How to change the default BitLocker encryption method and cipher strength when using the Enable BitLocker task in ConfigMgr 2007
    • Deploying Office 2016 using the Click-to-Run Deployment Tool
    • Integrate Jamf Pro with Microsoft Intune
    RECENT COMMENTS
    • Sebi on Prepare for Co-Management: Migrate Intune Devices without user affinity
    • Vadim P on SCCM: Failed to Get Client Identity (80004005)
    • TM on Active Directory Based Activation in an multi domain environment
    • unkown on Setting OSDComputerName using CustomSettings.ini
    • TJ Scott on Setting OSDComputerName using CustomSettings.ini
    DISCLAIMER
    The content on this website is presented "as-is" with no guarantees. The use of scripts from this website is at your own risk. Always test before putting something in production! Opinions expressed are my own.
    © 2025 ThemeSphere. Designed by ThemeSphere.

    Type above and press Enter to search. Press Esc to cancel.