The following forum(s) have migrated to Microsoft Q&A (Preview): Azure Active Directory!
Visit Microsoft Q&A (Preview) to post new questions.

Learn More

Cannot elevate my Azure AD domain account to administrator in Autopilot provisioned computers RRS feed

  • Question

  • I have no idea why my thread got moved to TechNet Windows Server forum when it doesn't involved any Windows Server. As far as I can tell it's an Azure AD/Intune/Windows 10 operational relationship.


    When I first tested out Windows Autopilot + Microsoft InTune following the steps in

    I was able to successfully join a Windows 10 Enterprise VM operating in my home computer (Hyper-V), but the deployment profile initially defined new users as standard. I was thus unable to perform any admin-level activities (e.g. System properties config sections)

    On a second Windows 10 Vm operating within our company Hyper-V server, the deployment profile was adjusted to let new user be administrator type. My colleague tested the Autopilot process on that VM. Subsequently, I signed into that VM as well, but noted that I being the second user was considered a standard user as well.

    My colleague (global administrator for Azure AD) adjusted the domain devices settings, enabling the [Additional local administrators on Azure AD joined devices] policy and declared my user account as part of that group.

    It's been nearly 24 hours and the policy does not appear to have flowed through to the computers despite multiple sync attempts. When signed in as my account, I still get challenged for administrator credentials. Are there still additional configuration steps we missed? Or does this particular policy take an awfully long time to sync and take effect?

    Furthermore, with the second VM, I noticed that my account setup procedure isn't fully complete and am not sure why.

    • Edited by icelava Friday, November 29, 2019 8:24 AM post details
    Tuesday, November 26, 2019 10:18 AM

All replies

  • Hello Icelava, I had originally moved it to Windows 10 as windows autopilot falls under the Windows domain, see the URL breakdown below:

    I'll take a look into this further to see what might be causing this issue, Is the aad domain account originally provisioned in the cloud? If so, Windows Autopilot might not support cloud users being elevated to administrator accounts yet, but I'll need to look into it more to see.

    Tuesday, November 26, 2019 6:08 PM
  • Yea correct, that's Windows (10) client deployment. It's not Windows Server deployment. The thread got moved under Windows Server. We aren't dealing with any Windows Server here.

    At that stage of configuration, we're already way passed initial Autopilot setup? This has more to do with later configuring Azure AD device settings to define which users get to be local administrator in those devices - what the Azure role is referred as "Device administrator" I believe.

    That policy is supposed to take at most four hours and a sign-out, but hasn't worked as advertised. The computers' local administrator group do include those tell-tale Azure AD SIDs (i.e. global admin, device admin). Which leads me to suspect somehow my membership with that role/group has not been set in stone despite declaring so in the Azure AD portal?

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    • Edited by icelava Monday, December 2, 2019 9:06 AM grammar
    Tuesday, November 26, 2019 8:07 PM
  • We added another colleague into the [Local administrators on Azure AD joined devices] role, and he didn't turn out to be an administrator on that computer either after sign-in.


    On further check with the setup progress of his account, he also had the same show-stopper similar to mine.

    I guess there is something gone wrong with this particular computer/OS at a lower level.

    When we sign into another test VM, both of us are regarded as administrators. Although there is a slight difference; my AAD account is explicitly defined in the local Administrators group, while my colleague is not. I suppose he has privileges via the Device administrator group. I thought my case should've also been like that.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    • Edited by icelava Tuesday, December 3, 2019 9:15 AM update
    Monday, December 2, 2019 9:07 AM
  • Interestingly, today when I sign in with my AAD account to the test VM that had already recognised us as administrators, it reverted to the "Setting up your device for work" phase. It gets stuck at Security polices stage; strangely similar to our problems with the original test computer.

    The only change I applied to the computer last evening, was a device rename. The computer, while signed in as local admin user, restarted itself to effect the change. I then signed in as local admin again to witness the changed name.

    The original test computer was also renamed, but I signed into that (as standard user) before the rename. And my colleague signed in for the first time after the rename. Are there perhaps some nasty consequences that happen with devices renamed by Intune?

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Wednesday, December 4, 2019 10:34 AM
  • If you're still having an issue here, please email AzCommunity[at]microsoft[dot]com and I can enable a one time free support ticket. Please provide your Azure Subscription GUID and a reference to this thread. And hopefully we can get you on the right path again soon. 

    Please see :

    On how to get a subscription GUID.


    In addition to that once you are able to resolve your issue with the support engineer, please post your response on this thread so that future readers will be able to benefit from your solution. 

    • Proposed as answer by Frank Hu MSFT Tuesday, December 10, 2019 11:00 PM
    Tuesday, December 10, 2019 11:00 PM
  • Hey Frank,

    We have already requested issue tickets from both Azure AD and Intune support team; apparently the techsupport/CRM systems are separated and isolated for Azure and Intune, and lack any integration and workflow between them, forcing us to communicate separately with different support personnel.

    Anyway it's been weeks now and there's not even a single clue why such behaviour is happening.

    The melody of logic will always play out the truth. ~ Narumi Ayumu, Spiral

    Wednesday, December 11, 2019 7:35 AM