Managing local administrators via Windows 10 MDM

This week is all about managing local administrators via Windows 10 MDM by using restricted groups. There has been many requests for a post like this after I wrote this post about creating local user accounts. And I have to admit that this post has been on my backlog for a long time. Better late than never, I think. Also, I’m definitely not the first to write about this subject, but I do think that I have some new insights that can be really helpfull. In this post I’ll start with an overview of the options for configuring local administrators on Azure AD joined (and Microsoft Inune managed) devices and reasons for using restricted groups, followed by the steps for configuring restricted groups. I’ll end this post by looking at the end-user experience.

Tip: When using Windows 10 version 20H2 or later, use the method as described in this post.


When discussing the local administrators on Azure AD joined devices, it’s often about the Global administrator role and the Device administrator role. These roles are by default local administrator on Azure AD joined devices. Users can be added to the Global administrator role like any other administrator role. Adding users to the Device administrator role, however, is a different configuration. Users can be added by configuring additional local administrators on Azure AD joined devices. These two roles have one thing in common and that is that those roles apply to all Azure AD joined devices. No exceptions. However, there might be scenarios in which it’s required to limit the local administrators on a device, or scenarios in which it’s required to differentiate the additional local administrators for different groups of devices.

Another option to manage local administrator on Microsoft Intune managed devices – which are often also Azure AD joined – is by using restricted groups. For this it’s possible to use the RestrictedGroups section in the Policy CSP. That contains a single node that can be used for adding local administrators (or for adjusting any other existing local group). When specifically looking at managing local administrators, make sure to keep the following in mind:

  • By using restricted groups, the provided local administrators will replace the existing local administrators.
  • By using restricted groups, which is a configuration node of the Policy CSP, the provided local administrators will be reapplied, within 8 hours, when changed by the user (behavior starting with Windows 10, version 1903).
  • The default local Administrator account must be part of the custom configuration, as it’s required for applying a custom configuration.
  • Every Azure AD joined device contains two SIDs (one representing the Global administrator role and one representing the Device administrator role) that are by default part of the local administrators.

Note: By default, on Azure AD joined devices, the user joining the device to Azure AD is also local administrator on the device.


By knowing the available configuration options and the different configurations it’s time to look at the configuration steps. The five steps below walk through the configuration. Throughout those configuration steps, I’ll provide the required information regarding the OMA-URI and the XML-value that should be configured.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles to open the Windows | Configuration profiles blade
  2. On the Windows | Configuration profiles blade, click Create profile to open the Create a profile blade
  3. On the Create a profile blade, provide the following information and click Create to open the Create profile blade
  • Platform: Windows 10 and later
  • Profile type: Custom
  1. On the Create profile blade, select Settings to open the Custom OMA-URI Settings blade
  2. On the Custom OMA-URI Settings blade, click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade)
  • Name: Provide a valid name
  • Description: (Optional) Provide a valid description
  • OMA-URI: ./Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership
  • Data type: Select String
  • Value: The value should be an XML. That XML should contain a groupmembership-element and that groupmembership-element should contain an accessgroup-element. That accessgroup-element contains the local group that should be adjusted and that accessgroup-element contains member-elements that contain the users that should be added to the local group. For an example see the XML below.

Note: The RestricedGroups section can be used to add members to any local group on a device.

	<accessgroup desc = "Administrators">
		<member name = "Administrator" />
		<member name = "AzureAD\" />
		<member name = "AzureAD\" />
		<member name = "S-1-12-1-2091167666-1329275207-1706997396-915002206" />
		<member name = "S-1-12-1-2447031348-1225114094-1633491097-1064162478" />

End-user experience

Now let’s end by having a look at the end-user experience. The best place to look is in the Properties of the Administrators group. That group should reflect the provided configuration, as shown in Figure 4.

This configuration is the most common to be used when the primary user of the device is not a local administrator. A method to provide additional support to the end-user, without the requirement of adding that specific account as a local administrator on all devices.

It’s also good to keep in mind that starting with Windows 10, version 1903, the settings of the Policy CSP actually refresh. When, for whatever reason, the configuration of the local administrators was adjusted, the configuration will refresh within 8 hours. The next device check-in will take care of that.

Another place for verifying the configuration, would be to look at MDM Diagnostic Report. That report will show an overview of the RestrictedGroups setting configuration.

More information

For more information about managing local administrators, refer to the following articles:


56 thoughts on “Managing local administrators via Windows 10 MDM”

  1. Hey Peter,

    Awesome article, thanks for providing us with the information. Maybe this is obvious to some but I have one question. If one would want to add multiple different restricted groups with different groups as members, would that require one new configuration profile per restricted group? Or should it work like this (with one single XML and one Device Configuration Profile)? Having multiple OMA/URIs in the same profile leads to conflict (which is logical).

  2. Hi Peter

    Many thanks for another very informative article.

    Anyway, I have set this up for a client using the restricted groups CSP.

    Can you confirm the following:

    User enrolls device and becomes local admin on the device
    RestrictedGroupsCSP deployed with and Azure AD Admin in the XML
    This then removes the user who enrolled the device from local admin group
    Should admins wish to install software NOT deployed by Intune they can elevate when the standard user is logged on

    Info appreciated

    • Hi Stuart,
      That’s possible, but feels a bit wrong. If you don’t want the user to be local administrator, I would look at an Autopilot profile that creates a standard user.
      Regards, Peter

  3. Hi Peter

    I understand what you are saying, but these are existing / in use / live devices that could NOT be wiped.

    Does this validate my approach?


    • Hi Stuart,
      Yes, I think that it makes sense in that scenario. Just keep in mind that I haven’t tested that scenario. I assume that nothing breaks, but I would advise to carefully test that.
      Regards, Peter

  4. Hey Peter,

    Awesome stuff. If I have an Endpoint Protection policy in place that renames the Administrator account, should I use that newer name in this policy? or could I even use the admin SID? Thanks!

    • That’s actually a really good question, Jesse. I haven’t tested that specific scenario. My guess would be the SID, but that depends a bit on what the CSP is checking for. I am curious what configuration you will end with.
      Regards, Peter

      • So on my first attempt, the policy was applied after the endpoint protection, and using the newer name worked (one was assigned to machine group, the other user group). I just re-enrolled an Azure AD join machine with both policies assigned to the autopilot device group, and that seems to have worked as well. This is also nice because you don’t have to worry about restarting or CSP refresh interval for the policy to hit.

        This is also really great because now you’re not bound to the Azure device settings guid and only being able to add individual users. Thank you again for the awesome post!

  5. Peter,

    Have created the policy (multiple times all day really) as indicated by both you and MS and every time it will not apply. DeviceManagement Event Logs indicates that Windows was unable to parse the requested XML data. Do you have any idea what this could be?

    Running the latest Win 10 build.


    data type: String

    Row value:

    I have simplified it to just one of the built-in accounts, same issue.

  6. Hi Peter,
    I’m having the same issue as Rob above. I’m using

    Errors in event viewer are :

    MDM PolicyManager: Merge string, Area: (RestrictedGroups), Policy: (ConfigureGroupMembership), EnrollmentID requesting merge: (18dcffd4-37d6-4bc6-87e0-4266fdbb8e49), Result:(0x800705B9) Windows was unable to parse the requested XML data….Event ID 806

    MDM PolicyManager: Merge string, Area: (RestrictedGroups), Policy: (ConfigureGroupMembership), EnrollmentID requesting merge: (18dcffd4-37d6-4bc6-87e0-4266fdbb8e49), Result:(0x800705B9) Windows was unable to parse the requested XML data.. …Event ID 821

    Any ideas? I’m stummped.

  7. Hi Peter
    I think the brackets may be causing the config to not go through. I’ll try again. I also added a link to an image of the config. Thanks!



  8. Dear, very good information.

    This question is not directly related to your post but I need to implement this and maybe you can help me.

    I want to restrict that only one user can login to a device.

    My scenario is as follows:

    I have 10 user and 10 Windows 10 devices

    Everyone in Azure AD as “Azure AD Join”

    Thank dear

  9. Peter, thanks for your answer.

    Yes, that’s my idea but how can I do it ????

    I was trying through this:

    Name: Test
    Description: Test
    OMA-URI: ./Device/Vendor/MSFT/Policy/Config/UserRights/AllowLocalLogOn
    Data Type: String

    but I’m not sure it’s okay.

    I want each user to be able to log in to a specific device

  10. Hello Peter … here is the value … please comment me, and urgent … Thank you very much.

    My value….:”””””” “””

    • Hi Pablo,
      I think you’re using a combination of characters in your value that is blocked on my blog. Could you try a picture?
      Regards, Peter
      PS: When it’s really urgent I would advice to either contact Microsoft, or to hire somebody.

  11. This CSP Policy is OS language dependent.
    It works fine with english operative system.
    I´ve been 3 days working on it and it did only worked when I used the spanish name of administrators group and local administrator user
    Administradores and Administrador.
    404 event id

  12. Hi Peter, thanks for the article.

    Is there any way to keep the primary user in the local administrator group?

    Our requirement is:
    1. keep the enrolled user as local admin (added by Autopilot)
    2. add some AzureAD groups (SIDs) to local Administrators as well.

    We#’re running Win10 2004 on all our devices.

  13. Dear Peter, a pleasure to greet you, first of all I want to thank you for the excellent information you share with us.

    In relation to the example that you would give on Monday for @Florian on a previous comment … I am also interested as I am implementing the same scenario. What do you recommend?

  14. Hello Peter,

    I can see some people are using this OMA URI ./Device/Vendor/MSFT/Policy/Config/RestrictedGroups/ConfigureGroupMembership

    But in your article, you are using the next one.

    Is there any issue? or both are correct?

  15. I am getting this error on 7% of my machines: MDM PolicyManager: Merge of policy did not complete successfully, Policy: (ConfigureGroupMembership), Area: (RestrictedGroups), Result:(0x800705B9) Windows was unable to parse the requested XML data..


  16. Dear Peter, What if I have Windows devices in English and Spanish? My policy affects the administrators group and has the administrator user as a member, but it does not apply correctly to my devices in Spanish. Is there a way to do it so that it applies to both? I have used the SID and it works fine for the administrator group name but I still have the problem with the administrator member

  17. This might be a dumb question. But does this apply if you want to add one user, say the user using the computer to the local admins group on just that machine ? My scenario is we have multiple offices about 140 computers. We need the users who are assigned to the machines to be added to the local group so they can install software. They don’t need full admin rights just enough to install programs. But we dont want these users added to groups on all devices just their specific devices. These are not on prem domain joined and are only azure ad joined.

  18. Hi Peter,

    Used your guide and the policy has worked great. However we have a few devices that require their old local admin credentials and so I created a group for them. In the assignments I’ve selected “All Devices” but to exclude the group I mentioned earlier.

    This worked well for a couple months but recently (2-3 months) the policy has started to apply to the excluded group. Would you have any idea why this is happening?

  19. Hello – We have multiple Azure AD joined devices from AutoPilot deployment. We would like to add a non domain/Azure account into the local admin group (e.g.: localcomputer\account1 ). Is this possible? And if so, is it possible without the password for that account being visible in Azure (or other places if applicable)?

  20. (seems the post lost the xml, added spaces to try and keep it)

    A little follow up, I’ve been hitting the brick wall on getting this to apply to my Dev/Test devices (20H2).

    I had tried both ways (older and modern) OMA-URI with the relevant XML. Results were red errors in event log and nothing useful in the diag report.

    What eventually worked for me was to drop the open and close tags that wrap around the <Accessgroup desc = " tags.

    After that, the local admins was populated as expected and the diag report was correct.

    Older (up to/inc 2004)

    Newer (20H2->)


Leave a Comment

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