So a common misconfiguration I see is how customers configure the Mobility (MDM and MAM) in the Azure Resource Manager Portal. Where Azure AD join will still operate without this being configured, you will have inconsistent results leveraging Intune or other 3rd party MDM if this is not configured correctly.

Configure an MDM provider (Windows 10) | Microsoft Docs

First: head over to Azure Active Directory and Mange select Mobility (MDM and MAM). Here you're going to find your MDM Provider information. Azure Active Directory gives you the ability to define MDM Providers and Even control Multiple MDM providers for a single tenant. Let's jump into some of the configurations.

Azure Active Directory is configured for Microsoft Intune by default. If you select the + Add application option you'll see other options. You'll find many cloud providers supported natively as well as the ability for providers not listed using the On-premises MDM application. So as you can see this gives you quite a bit of flexibility. But simply having an MDM defined doesn't do anything for you, it’s the assignment which is where the real lifting happens.

In this case we are going to use the default MDM Intune as an example and understand a little better what does what. As shown in the screenshot below you will find two sections for the Intune application MDM & MAM. For the other 3rd Party providers you will only find MDM, this is because MAM stands for Mobile Application Management which is a product of Microsoft Intune. Now many enterprise get a little confused here and Microsoft is not the most clear here as to what pertains to what.

First you should configure the MAM user scope only if you are not using the MDM user scope for example your organization has chosen to only leverage MAM policies for BYOD Corporate Data Access and has chosen not to use any MDM, or You have MAM policies configured, but will be leveraging a 3rd party MDM for Device Management.

Second if you are using Intune as your Primary MDM, you do not target both MDM & MAM to the same users this will cause enrollment failures especially during Autopilot. Users targeted to the MDM user scope will receive both MDM and MAM policies.

So what does assigning users to the MDM user scope do? When assigned to a user this carries as part of the Azure Active Directory profile as registered MDM providers and is provided when you authenticate to Azure and leverage services like Azure AD Join Enrollment. Azure AD Enrollment or Registration will automatically enroll the device into the MDM defined in this section.

You have the option to target All under MDM user scope or select Some. If I'm working with a customer and we are onboarding all users onto Intune even in a controlled form I will generally recommend All as the best option, this make Intune Auto Enrollment available for all users

So below you will see three URLs defined, Terms of use, discovery, and compliance. These fields are pretty self-explanatory, and are prepopulated in most application. In this case they are prepopulated for Intune, but you can always use the Restore default MDM URLs link in the window if you have an overzealous admin making changes without thinking. Like I said earlier these are passed as part of your Azure Active Directory profile if you make a change to one of the URLs then that revised URL will be passed to your users and provided during Authentication.

So where can I see where these are being published or If they are published correctly. One method is on any Azure AD Join or Hybrid Join Windows workstation. Using the dcregcmd /status command

Troubleshoot using the dsregcmd command - Azure Active Directory | Microsoft Docs

DSREGCMD is used for troubleshooting Azure AD Device Join and Registration issues. In another blog I will cover Hybrid Azure AD Join this tool is one we use when validating auto enrolment to Hybrid Join. In this case we are going just want to validate the tenant details.

Below is an example of the tenant details from the DSREGCMD command. You will notice the MdmUrl, MdmTouUrl, and MdmComplainceUrl are all the same as listed above, these are past during authentication. If you did not assign the Mdm user scope to the user, you will see these 3 fields blank, or if you have MDM & MAM assigned to the same user you could see the MdmUrl be the same as the discovery URL for MAM and this will cause enrollment failures for Intune. So its always a best practice to validate as your testing your environment.

Be sure to validate your Mobility Configuration this will be extremely important for things like Autopilot and Automatic MDM enrollment for Azure AD Join.