Hybrid Azure AD join – Part two: automatic enrollment in Intune

Welcome to the second part of our Hybrid Azure AD join guide. If you have missed our first part, where we explain what Hybrid Azure AD join actually is and how to set it up, be sure to check it out here!

Before we start, make sure you set up Intune environment to accept automatic enrollment (licensing & MDM scope).

Let’s get right into it. Now that our W10 device is registered as a Hybrid Azure AD joined device, we can start doing stuff with it. In order to start managing this device via Intune, it must be enrolled first. This can be done manually but since we are professional computer geeks (and a bit lazy), we want this done automatically. Let’s start by testing this on a single device.

Testing for a single device

To give our Hybrid Azure AD joined device a trial by fire, we will edit its local group policies to automatically enroll into Intune.

First of all start by hitting Windows + R (opening the Run window) and type gpedit.msc.
To run this command, you need to be logged in as the administrator.

gpedit

We are now in the Local Group Policy Editor.
Go to Computer Configuration > Administrative Templates > Windows Components > MDM.
Here you will find two settings, of which we select the first one.
Set Enable automatic MDM enrollment using default Azure AD credentials to Enabled.

localgrouppolicy

enableMDM

As a result, enabling this will create scheduled task that will run every 5 minutes after creation.

Important note! For this created task to be succesful, you will need to log in with a licensed user. More specifically, an EMS licensed user (automatic enrollment requires an AzureAD + Intune license).

To see this task (and troubleshoot it if needed) we will open the Task Scheduler application.
In this app, go to Microsoft > Windows > EnterpriseMgmt. There you can find the task that you created.

taskscheduler

MDMtask

In the ‘Last Run Result’ of the task, you can find error codes that may appear when it tries to run.
If you get error 0x80180018, then you have a licensing issue. Either you didn’t log in to the correct user, or you have not assigned the license correctly.

licenses

To now check if the task has completed and did its job, we will go to the Intune portal.

Under Devices we are able to see our enrolled W10 (this can take a few minutes, so be patient).

intunelist

You can also see this by going to the Account settings of Windows. There, under Access work or school, you can see the synchronization with the Active Directory and Intune. If you can’t see the ‘Info‘ button, it means the device didn’t fully enroll yet.

accessworkorschool

Testing for multiple devices

Even though our first test was a success, we still have some work to do. The method we previously employed is not very useful in most scenarios. You still have to manually enable the local policy on each device, which is a tedious task.

This is why we are now going to do the exact same thing, but for a group of devices. If we would later add new devices to that group, then it would automatically enroll (which is the main goal of this guide). We’re not using local policies for this so we need to access our domain controller and create a GPO.

Edit the new GPO that you created and go to Computer Configuration > Policies > Administrative Templates > Windows Components > MDM. This is similar to the local policy we edited earlier.

If, like me, you don’t see the ‘Enable automatic MDM enrollment using default Azure AD credentials‘ setting (only ‘Disable MDM Enrollment’), do the following:

  • Search for Administrative Templates (.admx) for Windows 10’ in your preffered search engine.
  • Click the result that leads to the official Microsoft website (e.g. www.microsoft.com/en-us/download/…).
  • Download the .msi file from their website and run it (which will install the .admx files).
  • Go to the location where you just installed the Administrative Templates (default: C:\Program Files (x86)\Microsoft Group Policy\…\PolicyDefinitions)
  • Copy the .admx files + at least one or more language folders (based on what language your Domain Controller is)
  • Paste them in \\domain.com\sysvol\domain.com\Policies\PolicyDefinitions (change ‘domain.com’ to your own domain name)

You might have to create the folder PolicyDefinitions if it doesn’t already exist. If you already have a folder with .admx files in there, just copy the MDM.admx and the MDM.adml from the language folder and overwrite them with the existing ones.

Now you should be able to see the setting we mentioned before, Enable it.

***
UPDATE
In newer version you might see some extra settings in this GPO (User Credentials and Device Credentials). From what I have read, the User Credentials setting is the most similar to the one that is used here so I recommend using that.
***

Be sure to link this policy to the correct Organizational Unit in which your devices are located. You can then filter the GPO to only apply to the Computers group.

Open the Command Prompt and type gpudate /force to get your policies to apply faster.

After that, you can go back to our previous tests to check if a device enrolled properly (Intune portal or Access work or school).

Now you are able to unleash to power of Intune on your Hybrid Azure AD joined devices!
Stay tuned for future blogs on Intune, which are now more interesting than ever considering we just added new devices to manage and control.

Print Friendly, PDF & Email

19 comments on “Hybrid Azure AD join – Part two: automatic enrollment in Intune”

  1. Nicolai says:

    Amazing guide! Fixed all the issus i had with implementing Intune on our company domain!

  2. shalini Toppo says:

    Hi sam,

    I just joined my devices to domain and Azure AD connect is configured so its now Hybrid AAD joined.
    and Intune is set to auto enrollemnt.
    But my device in not appear in Intune’s all devices.
    I just want to know the other methods to enroll in MDM (other than GPO).

    1. Sam Teerlinck says:

      Thanks for your reply!

      When you have a Hybrid AD environment it is recommended to use a GPO (if possible).

      There are also other methods to enroll.
      Microsoft has an official list of all methods here:
      https://docs.microsoft.com/en-us/intune/enrollment/windows-enrollment-methods

      You can see which one fits best for your particular situation.

  3. Naveen Pandey says:

    Hi Sam,

    Once windows 10 device is hybrid azure ad joined and enrolled in Intune, can we remotely wipe or reset it from Intune?

    1. Sam Teerlinck says:

      Hello Naveen,

      Yes! This is possible.
      You can remote Wipe, Restart and Sync these devices.
      https://docs.microsoft.com/en-us/intune/remote-actions/

  4. Mario Serra says:

    Hello Sam,
    once the devices are in hybrid mode, how do I manage users? For exambple, if i need to change the alias or another attribute what can i do?

    1. Sam Teerlinck says:

      Hi Mario,

      This will depend where the user was created. A user that was created in the on-prem AD will mostly be manageable in on-prem only. You will see that trying to add an alias etc. in the Microsoft portal will give you a notification that this can only be done in the on-prem AD. If you go to Azure Active Directory in portal.azure.com, and then open the Users blade, you can see the ‘Source’ of the User which will tell you where to manage it (there it will say Windows Server AD/Azure Active Directory).

      1. Mario Serra says:

        Thank you for reply, i understand that the users with Windows Server AD soure i must manage on prem. But in AD i don’t have the attibutes, i must extend my AD schema? For Microsoft support i must have also exchange on prem? If yes what module i must install?

        1. Sam Teerlinck says:

          The attributes could indeed be hidden, but should be available to change there. Enabling Advanced Features would be step one: (https://docs.secureauth.com/display/KBA/Enable+Active+Directory+Advanced+Features)
          I don’t understand the second part of your question, but Exchange On-Prem is not mentioned in this article. So you would be better off asking that in a more appropriate blog/forum.

  5. COSTIN HUREZANU says:

    Hello Sam,

    You mentioned that, when one computer is enrolled by editing the local policies, the user who performed the changes must have an Intune license.
    What about for multiple devices? The user who create the GPO must have Intune licence assigned? Is this the case when the DEM account must be used?

    Many thanks for your article,

    Costin

    1. Sam Teerlinck says:

      Hi Costin,

      Great questions! I’ll do my best to answer them all:
      Most of this will all depend on how your Intune is set up.

      First of all, it is not necessary for the user who creates the GPO to have any kind of license/role other than local domain admin.
      It is only when you log in to devices that are affected by the GPO, that you will have to check licenses, roles and enrollment settings.

      You can check how your Intune is set up and how enrollment is managed, change/select who can enroll devices here.
      Since you are enrolling them with a GPO, they are considered as shared devices (see this link, and scroll down to the Important notification). There are also multiple available settings to set the enrollment amount maximum and only some apply to Hybrid Azure AD, so it can get complicated quite quickly. The maximum amount has also changed multiple times, but if I remember correctly it used to be a maximum of 5 per user and was increased to 15 at some point (someone correct me if I’m wrong). But again, since they are GPO enrolled ‘shared devices’, the limit will probably be higher. Also keep in mind that the user that enrolls the device will be considered it’s primary user. Which should generally be the user that the device has been assigned to (mainly to prevent confusion in the portal).
      The Device Enrollment Manager account can enroll a lot of devices but does give the enrolled device some restrictions (more info here).

      After that, make sure you have assigned the correct license(s) to the user so they can enroll.

      1. COSTIN HUREZANU says:

        The problem I face right now (and I cannot understand why) is that, despite the device performing the Hybrid Join flawlessly, its status in Azure AD is:
        – Joint type: Hybrid Azure AD Joined
        – Owner: N/A
        – MDM: None

        See, my expectations were that the user logged onto that computer during the Hybrid Join will become its “Owner”, as long as the license it’s assigned (“the user that enrolls the device will be considered it’s primary user”). But it is not the case.
        Further question then: maybe the GPO must enable device registration using “User credentials” instead of “Device credentials”? What’s happening when there are multiple user profiles already on the computer (i.e. a technician who installed the computer and then the assigned user), both with license?
        I just doesn’t seem right to me. What do I miss?

        Once more, thank you for your amazing article!

        1. Sam Teerlinck says:

          First of all sorry for the late reply, these last weeks have been quite chaotic.

          If your Hybrid Azure AD join is nog giving any issues, then I think the problem might be with your Intune enrollment settings. Maybe the user you are trying to enroll with does not have permission to actually enroll devices in Intune? Also try checking the Event Logs, maybe there you will find some more information about what is going wrong during the enrollment/hybrid join (you can find the troubleshooting guide with event logs etc. here). I have also never had to use user credentials GPO’s for my Hybrid joins… But about your question with multiple licensed users: To my knowledge, the first licensed user to log in to the device when the GPO is active will enroll the device. So profiles of other users will not matter there, even if they have a license. Afterwards you can switch between users and their settings will migrate with them, but the owner/primary user will always be the person who enrolled it (recently Microsoft made it available to change the primary user, check it out here).

          Hope this helped, I would appreciate it greatly if you could post your solutions here when you get them! Thanks in advance!

  6. Richard Colebeck says:

    Hi Sam,
    Thanks for your blog, they validate how things ~should~ be working. However, like @Costin I’m stuck on the MDM GPO with regards to “User” or “Device” credentials.
    If my GPO is set to User, after a gpupdate /force, I’m notified about a “change my admin has made” (not exact wording as I don’t have that handy) and it prompts me to enter credentials (I use an account that has an Intune license) and the device is registered in MDM with that user being the primary user.
    If my GPO is set to Device, after a gpupdate /force, there is no notification and Event 76, Auto MDM Enroll: Device Credential (0x0), Failed (Unknown Win32 Error code: 0x8018002a) is logged in Event Viewer\Applications and Services Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin event log.

    Any insight on User vs Device credentials?

    Cheers,
    Richard…

    1. Sam Teerlinck says:

      First of all sorry for the late reply, these last weeks have been quite chaotic.

      I personally do not have any experience with the new user/device credentials, though I have heard that the user credentials is the most similar to the one I am using here. In my experience, if the logged in user has the correct permissions and the correct license… your device should enroll without problems. Concerning your error (0x8018002a), after some quick research I found that it is probably Multi-Factor Authentication that is causing some problems. These are the two sources that I have found:

      AUTOENROLLMENT FAILS WITH UNKNOWN ERROR 0x80180001 & 0x8018002a
      Troubleshooting co-management: Auto-enroll existing Configuration Manager-managed devices into Intune

      Hope this helped, I would appreciate it greatly if you could post your solutions here when you get them! Thanks in advance!

  7. Darry says:

    Hello Sam,

    I have this situation:

    – System becomes Hybrid Azure-AD joined
    – System not configured to enroll into Intune MDM
    – System taken off on-premises network & using a normal home Internet connection
    – On-premises user account synced to Azure AD, but never logged into this system before. Account has EMS license

    Can the user log into the system using their Azure User Principal Name?

    Thanks.

    1. Sam Teerlinck says:

      Hi Darry,

      If during setup of Hybrid join you have used the same domain that you use locally to log in and all your Azure users have the same mail address/UPN, I don’t think there should be a problem. If the users have the same UPN as before (when they only worked locally) but now in Azure, you should be able to authenticate without problems (if I’m not mistaken)… Be sure to check what authentication method is used with your AD Sync (see this link) and enable single sign-on for your organization.

  8. jonatan says:

    Hello Sam,
    Excellent article, thank you.
    However i have a little problem with the deployement of the GPO.
    When the gpo is deployed via the server to the user pc, if the user in the receiving computer is a standard user (NOT admin) the gpo does not create the task to enroll the computer to intune
    However, if the user in the receiving computer is a local administrator of the computer, then the GPO which was deployed from the server is able to create a task for automatic intune hybrid enrollement.
    As i understand it, a gpo should deployed from the server should be able to run with administrative privileges.
    Do you have any idea on why this may be or if you already had this problem?

    Thank you in advance

Leave a Reply

Your email address will not be published. Required fields are marked *