Intune Ends Windows MDM-Only DNS CNAME Auto-Discovery in January 2027: Admin Action Plan

In an advisory published by the Microsoft Intune Customer Success team on the Microsoft Community Hub and tracked in the Microsoft 365 Message Center as MC1509780, Microsoft confirmed that Intune will end support for DNS CNAME-based auto-discovery in Windows MDM-only enrollment scenarios beginning January 15, 2027 (or soon after, per the Message Center notice).

Before you choke on your morning coffee or start drafting an emergency change request for your entire Windows 11 fleet, take a breath. Microsoft is not killing off Windows MDM-only enrollment, nor is this change touching mainstream Microsoft Entra join or hybrid join deployments. However, if your environment still relies on legacy MDM-only workflows and an EnterpriseEnrollment DNS record to silently guide users to the right server, your help desk guides and onboarding scripts are about to need an overhaul.

What Exactly Is Changing on January 15, 2027?​

When a user enrolls a Windows PC directly into mobile device management without registering or joining the device to Microsoft Entra ID—a workflow known as Windows MDM-only enrollment—the Windows client needs to know where the management server lives. Historically, administrators configured a DNS CNAME record on their corporate domain (for example, EnterpriseEnrollment.contoso.com) that redirected enrollment traffic to Microsoft's Intune infrastructure, specifically EnterpriseEnrollment-s.manage.microsoft.com.

Because of that DNS alias, a user could simply enter their corporate email address, and Windows would extract the domain suffix, query the EnterpriseEnrollment CNAME record, and automatically locate the Intune discovery service without bothering the user for server details.

Beginning January 15, 2027, Microsoft Intune will stop supporting CNAME-based auto-discovery for these Windows MDM-only enrollment paths. Microsoft states that retiring this mechanism reduces reliance on DNS-based discovery and aligns the platform around a more consistent modern enrollment architecture.

Once the change takes effect, any Windows MDM-only enrollment workflow that does not already supply the server address automatically will prompt the user to manually type or paste the Microsoft enrollment server discovery URL:

[url]https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc[/url]

Asking an end user to accurately type a 66-character URL complete with a .svc extension is practically a guaranteed ticket generator for your Tier 1 support desk. That makes identifying whether you actually use this path the top priority between now and January.

Quick Summary: The Core Facts​

• Effective Date: January 15, 2027.
• Message Center Tracking: MC1509780.
• What Is Ending: Support for EnterpriseEnrollment DNS CNAME auto-discovery during Windows MDM-only enrollment.
• What Remains Supported: Windows MDM-only enrollment itself remains supported, and existing enrolled devices are completely unaffected.
• Fallback Requirement: If the enrollment experience does not automatically supply the server address, users must manually enter [url]https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc[/url].

Are You Actually Affected? Separating Modern Entra Flows from MDM-Only​

One of the biggest pitfalls with Microsoft Intune advisories is terminology overlap. Nearly every seasoned Intune administrator has seen or configured EnterpriseEnrollment and EnterpriseRegistration CNAME records at some point during initial tenant setup. In fact, Microsoft Learn's Intune documentation has long included a "CNAME Validation" test blade right inside the Microsoft Intune admin center under Devices > Device onboarding > Enrollment > Windows.

Does having an EnterpriseEnrollment CNAME record in your public DNS zone automatically mean your users will hit a wall in January 2027? No.

According to the Intune Customer Success team and Microsoft Learn documentation, your organization is only impacted if all three of the following conditions apply:

1. You actively use Windows MDM-only enrollment.
2. You have configured an EnterpriseEnrollment DNS CNAME record (such as EnterpriseEnrollment.contoso.com).
3. Your enrollment workflow actively depends on that DNS record to discover the Intune enrollment service.

By contrast, you are not affected if your Windows fleet exclusively relies on:

• Microsoft Entra join enrollment (formerly Azure AD join, including standard Windows Autopilot user-driven and self-deploying profiles).
• Microsoft Entra hybrid join enrollment (domain-joined PCs synced with Entra ID and enrolled via Group Policy or Configuration Manager co-management).
• Windows MDM automatic enrollment configured in your Entra ID tenant, where Microsoft Learn documentation notes the MDM server discovery is handled natively by default through Entra identity tokens rather than DNS CNAME lookups.

Why would an enterprise still use MDM-only enrollment on Windows in 2026? While Microsoft has spent years steering customers toward full Entra join or Entra registration ("Workplace Join"), MDM-only enrollment still pops up in niche scenarios: contractor or BYOD machines where organizations want basic MDM policy enforcement without registering a device identity in Entra ID, specialized kiosk or lab setups, or legacy "Enroll only in device management" links buried inside Windows Settings (Settings > Accounts > Access work or school > Enroll only in device management).

It is also worth noting that an IT administrator asked in the Microsoft Community Hub comments whether this deprecation affects Mobile Application Management (MAM) enrollments. As of publication, Microsoft has not posted an official reply to that comment, and the advisory's scope is explicitly restricted to Windows MDM-only enrollment. Furthermore, per Microsoft Learn documentation, EnterpriseRegistration CNAME records (EnterpriseRegistration.windows.net) are a separate mechanism used by Microsoft Entra ID for device registration and Conditional Access—not the EnterpriseEnrollment MDM discovery record targeted here.

Should You Delete Your DNS CNAME Records?​

When an IT pro hears "end of support for CNAME auto-discovery," the natural instinct is to tidy up the DNS zone file and delete EnterpriseEnrollment.yourdomain.com. Hold your horses.

In the advisory's FAQ, Microsoft specifically addresses whether administrators need to remove their EnterpriseEnrollment DNS record. Rather than telling admins to delete it, Microsoft advises organizations to review their broader environment and DNS requirements, noting that this retirement only affects the use of that record for Windows MDM-only enrollment auto-discovery. If other platforms, legacy validation checks, or third-party tools in your environment still check for that record, deleting it prematurely could cause unnecessary headaches. Leave the DNS record intact unless you have verified nothing else touches it.

A Step-by-Step Action Plan for Windows Administrators​

With roughly three months on the clock before the January 15, 2027 cutoff, administrators have a comfortable runway to audit their environments and prevent onboarding surprises after the New Year holiday freeze. Here is how to tackle it systematically:

1. Audit Your Enrollment Pathways and DNS​

Check your public DNS zones for an EnterpriseEnrollment.<yourdomain> record pointing to EnterpriseEnrollment-s.manage.microsoft.com (or the .us / .cn sovereign cloud equivalents documented on Microsoft Learn). Next, inspect your Intune device inventory and enrollment restrictions to see whether users are actually enrolling Windows endpoints via the "MDM-only" path rather than Entra join or Entra registration.

2. Test the "No-CNAME" User Experience Now​

You do not have to wait until January 2027 to see what your users will experience. Using a test domain without an EnterpriseEnrollment CNAME record (or a test network environment where that specific DNS query is blocked), walk through your organization's exact Windows MDM-only enrollment workflow.

• Observe whether your provisioning tool or enrollment prompt already pre-populates the server URL.
• Verify the exact screen where Windows prompts for the MDM server address, and test completing the enrollment using [url]https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc[/url].

3. Overhaul Internal Documentation and Onboarding Kits​

If you confirm that your users rely on manual MDM-only enrollment, audit every piece of instructional material in your organization that assumes DNS will magically find the server. Microsoft recommends updating:

• Internal user self-enrollment guides and PDFs.
• Help desk troubleshooting scripts and Tier 1 knowledge base articles.
• Device deployment and provisioning documentation.
• Day-one employee and contractor onboarding packets.

Make sure the URL [url]https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc[/url] is provided in a copy-pasteable format in digital onboarding emails rather than trapped inside a flat screenshot where users are forced to type it by hand.

4. Re-evaluate Why You Are Using MDM-Only Enrollment​

Finally, treat this change as an architectural health check. From an industry best-practice standpoint, Windows MDM-only enrollment without a backing Microsoft Entra device identity is increasingly a relic of the early Windows 10 era. Without an Entra device identity, you lose out on device-based Conditional Access policies, seamless Single Sign-On, and modern Windows Autopilot provisioning. If your team is only using MDM-only enrollment out of institutional inertia—someone wrote a guide in 2018 tellings users to click "Enroll only in device management" and nobody ever changed it—now is the ideal time to migrate those onboarding workflows to standard Microsoft Entra join or Entra registration with automatic MDM enrollment enabled.

Section Summary: Admin Checklist​

• Do not panic: Existing enrolled PCs and Entra-based enrollments will keep humming along without interruption.
• Verify impact: Check if any active workflows use Windows MDM-only enrollment combined with EnterpriseEnrollment DNS records.
• Update guides before January 15, 2027: Ensure help desk staff and end-user documentation include the full discovery.svc URL wherever manual entry will be required.

How is your organization handling Windows onboarding heading into 2027? Have you completely retired MDM-only enrollment in favor of Entra Join and Autopilot, or do you still have contractor and BYOD edge cases that will need the manual discovery URL? Drop your thoughts and deployment strategies in the WindowsForum community discussion below!