Which CNAMEs to use for Auto-discovery during MDM Enrollment
Published Oct 30 2018 11:13 AM 37.8K Views

First published on TechNet on Mar 04, 2017
We’ve had questions about the CNAME configuration required for Windows devices to automatically discover the MDM server for mobile device management (MDM). We’ve also had questions about the MDM server address users have to enter manually if prompted. This blog hopes to help you understand the requirements.

Device Enrollment


If you have iOS or Android devices, they don’t have to worry about auto-discovery or manual enrollment; as long as the Company Portal is installed, it knows how to find the right server to get the device enrolled.

Windows Device Enrollment -End User Experience


Unlike iOS and Android, Windows devices (Windows Phone 8.1, and 10 and Windows PCs 8.1 and 10) have UI built into the operating system to enroll a device for management. The user enters a corporate email address which matches the User Principal Name (UPN) set for user identity. The device tries to auto-discover the server and start the enrollment process.
Underneath the covers, here’s what happens when enrolling a Windows Phone 8.1 device:



In Windows Phone 8.1 it looks like this:





If there is no CNAME configured, the device enrollment server won’t be found, and the device presents a screen to allow the user to enter the server address.
IMPORTANT : The server address the user needed to enter used to be manage.microsoft.com , but due to the changes necessary to move to the new grouping and targeting structure, the FQDN to enroll a device to Microsoft Intune changed to enrollment.manage.microsoft.com . Both FQDNs can be used now, but support for manage.microsoft.com ended in February of 2017.



For more information about the MDM enrollment protocol, see https://msdn.microsoft.com/en-us/library/mt221945.aspx .

Windows 10 Automatic MDM Enrollment


If you are enrolling Windows 10 devices using automatic MDM enrollment, you don’t have to worry about configuring CNAMEs because the MDM server is configured by default when you enable automatic MDM enrollment. For more information, see https://docs.microsoft.com/en-us/intune/deploy-use/set-up-windows-device-management-with-microsoft-... .

Windows Device Enrollment -Configuring Auto-Discovery


To configure auto-discovery of the enrollment server, there has to be a CNAME record to point to the enrollment server.


Type Host name Points to TTL

CNAME EnterpriseEnrollment. company_domain.com EnterpriseEnrollment-s.manage.microsoft.com 1 hour




The company_domain in the FQDN should be the registered domain name(s) you are using for single sign on with the UPN. For example if users at Contoso use name@contoso.com as their email/UPN, the Contoso DNS admin would need to create the following CNAMEs.


Type Host name Points to TTL

CNAME EnterpriseEnrollment. contoso.com EnterpriseEnrollment-s.manage.microsoft.com 1 hour




If you have more than one UPN suffix, you need to create one CNAME for each domain name and point each one to EnterpriseEnrollment-s.manage.microsoft.com. For example if users at Contoso use name@contoso.com, but also use name@us.contoso.com, and name@eu.constoso.com as their email/UPN, the Contoso DNS admin would need to create the following CNAMEs.


Type Host name Points to TTL

CNAME EnterpriseEnrollment. contoso.com EnterpriseEnrollment-s.manage.microsoft.com 1 hour
CNAME EnterpriseEnrollment. us.contoso.com EnterpriseEnrollment-s.manage.microsoft.com 1 hour
CNAME EnterpriseEnrollment. eu.contoso.com EnterpriseEnrollment-s.manage.microsoft.com 1 hour




For more information, see https://docs.microsoft.com/en-us/intune/deploy-use/set-up-windows-device-management-with-microsoft-... .

Additional Endpoints Are Supported but Not Recommended


EnterpriseEnrollment-s.manage.microsoft.com is the preferred FQDN for enrollment, but there are two other endpoints that have been used by customers in the past and are supported. EnterpriseEnrollment.manage.microsoft.com (without the -s) and manage.microsoft.com both work as the target for the auto-discovery server, but the user will have to touch OK on a confirmation message. If you point to EnterpriseEnrollment-s.manage.microsoft.com , the user won’t have to do the additional confirmation step, so this is the recommended configuration.

Alternate Methods of Redirection Are Not Supported


Using a method other than the CNAME configuration is not supported. For example, using a proxy server to redirect enterpriseenrollment.contoso.com/EnrollmentServer/Discovery.svc to either enterpriseenrollment-s.manage.microsoft.com/EnrollmentServer/Discovery.svc or manage.microsoft.com/EnrollmentServer/Discovery.svc is not supported.

Registration vs Enrollment CNAMEs


Azure Active Directory has a different CNAME that it uses for device registration for iOS, Android, and Windows devices. Intune conditional access requires devices to be registered, also called “workplace joined”. If you plan to use conditional access, you should also configure the EnterpriseRegistration CNAME for each company name you have.


Type Host name Points to TTL

CNAME EnterpriseRegistration. company_domain.com EnterpriseRegistration.windows.net 1 hour




For more information about device registration, see
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-device-... .
Hopefully this information helps clarify the CNAMEs and FQDNs needed for auto-discovery.

7 Comments
Bronze Contributor

Even though the change to "-s" was implemented in 2017 (I missed it back then), some documentation agrees, like this, but others do not, like this.

 

Even the DNS checker in the admin portal warns of possible service issues and shows this. How can this possibly be at this point?

 

Capture.JPG

 

Copper Contributor

Will a "HSTS includeSubDomains" header break CNAME resolutions for Windows 10 Azure AD join, Outlook, Skype for Business etc. since the certificate mismatch? IE/Edge show a HSTS error and block access when using includeSubDomains on the above CNAMEs.

Copper Contributor

Hi I also still get the error Brian got in 2019. Has this not been resolved?

TroyQ79_0-1652185083193.png

 

Bronze Contributor

Take a look at the end of your record. What is outeniqua.co.za doing there? You might have configured your DNS entry incorrectly to include your domain. I don't think the checker is going to handle that necessarily, whatever it means.

 

The page still throws the error for us, or rather it would if I hadn't dismissed it long ago, which I must have done. When clicking on it now, it still thinks -s is wrong, even though both articles I linked in my first post now confirm that it's correct (back in 2019, one of the articles was in disagreement).

 

The checker just isn't that great in general. When Skype for Business (online) went away last year, three of its four DNS records became unnecessary (only one had relevance to Teams), so I deleted them. I now have three red marks on that page for having done that.

Copper Contributor

Hi Brian

 

Sorry I posted the wrong picture. the .outeniqua.co.za was removed. That was a copy and paste error on the first try. I was mostly talking about the -s at the end of EnterpriseEnrollment. Mine now works with EnterpriseEnrollment.manage.microsoft.com but not with EnterpriseEnrollment-s.manage.microsoft.com

 

Thanks again for your reply.

Bronze Contributor

Ah, OK.

 

Unless you find that users don't actually have to do the additional confirmation step mentioned in the article with a DNS entry not having -s, I would just use the -s and ignore the messaging in the checker. I think there's even a way to dismiss the outward appearance of the error in the UI.

Copper Contributor

Instead of having documentation referencing EnterpriseRegistration. company_domain.com can we stick to the domains allocated for this purpose? eg EnterpriseRegistration.example.com per Special-Use Domain Names (iana.org)

 

I stupidly copy pasted the company_domain.com in front of my domain as I didn't realise it was an example.

Version history
Last update:
‎Oct 30 2018 04:01 PM
Updated by: