If your Windows MDM-only enrollment guide says “type your work email and Windows finds the server,” it has an expiry date. Microsoft announced on October 15, 2026 in Message Center post MC1509780 and on the Intune Customer Success blog that “Starting January 15, 2027, … Microsoft Intune will end support for CNAME-based auto-discovery in Windows MDM-only enrollment scenarios.” The Message Center text adds “or soon after” to the date.
After that, Microsoft says users “may need to enter the Microsoft enrollment server URL if it’s not already provided by the enrollment experience”:
https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svcNothing breaks on devices that are already enrolled. The work is finding which of your domains still carry the record, which enrollment flows lean on it, and which documents need the URL added. I haven’t tested the post-change prompt; it isn’t live yet. Everything below comes from the Microsoft pages linked inline.
Quick checklist
- List every UPN suffix your users sign in with.
- For each one, query
EnterpriseEnrollment.<domain>for a CNAME (script below). - For each domain that has one, find out whether anyone still enrolls Windows devices MDM-only against it.
- Add the enrollment server URL to those guides, help desk scripts and onboarding packs.
- Test one MDM-only enrollment now, entering the URL by hand, so you know what users will see.
- Leave the DNS records alone for now (see “Don’t delete the records yet”).
What changes and what doesn’t
From the blog post and MC1509780:
| After January 15, 2027 | |
|---|---|
| EnterpriseEnrollment CNAME discovery for Windows MDM-only enrollment | No longer supported |
| Windows MDM-only enrollment itself | Still supported |
| Devices already enrolled | Not affected |
| Microsoft Entra join and Microsoft Entra hybrid join enrollment | Microsoft says you likely aren’t affected if you use only these |
| What the user sees | A prompt for the enrollment server URL, when the enrollment experience doesn’t already supply it |
Microsoft’s own FAQ answers the obvious question, “Will every user need to enter the enrollment service URL?”, with “Not necessarily. Some enrollment experiences may already provide enrollment server information.” So expect the prompt in some flows and not others, and test yours.
The affected organization, in Microsoft’s words, is one where all three are true: you use Windows MDM-only enrollment, you have configured an EnterpriseEnrollment DNS CNAME record, and your enrollment process depends on that record to discover the enrollment service.
Why your tenant probably has these records
The Enable autodiscovery of Intune enrollment server page on Learn still tells you to create them if you’re not using automatic enrollment. It lists two records per domain:
| Host name | Points to | Purpose on that page |
|---|---|---|
EnterpriseEnrollment.company_domain.com | EnterpriseEnrollment-s.manage.microsoft.com | Intune enrollment server discovery |
EnterpriseRegistration.company_domain.com | EnterpriseRegistration.windows.net | Microsoft Entra device registration |
The same page says to create one EnterpriseEnrollment CNAME for each UPN suffix, so a tenant with contoso.com, us.contoso.com and eu.contoso.com needs three. It also says EnterpriseEnrollment.manage.microsoft.com and manage.microsoft.com work as targets but make users acknowledge a confirmation message. Older records may point at either of those.
Microsoft’s announcement is about the EnterpriseEnrollment record only. Learn describes EnterpriseRegistration as the CNAME Microsoft Entra ID uses during device registration, and says to configure it for each company name if you plan to use Conditional Access. I’m auditing both below because they usually sit side by side, but only the EnterpriseEnrollment result tells you about this change.
Audit DNS across your domains
This script reads both records for every domain you give it. It only does DNS lookups with Resolve-DnsName, which takes -Type CNAME. I haven’t run it against a real tenant’s domains for this article.
# Read-only DNS audit. Not executed against a production tenant for this article.
$Domains = @('contoso.com', 'us.contoso.com', 'eu.contoso.com') # your UPN suffixes
$Results = foreach ($Domain in $Domains) {
foreach ($Prefix in 'EnterpriseEnrollment', 'EnterpriseRegistration') {
$Name = "$Prefix.$Domain"
try {
$Record = Resolve-DnsName -Name $Name -Type CNAME -DnsOnly -ErrorAction Stop |
Where-Object { $_.Type -eq 'CNAME' } | Select-Object -First 1
[pscustomobject]@{ Domain = $Domain; Record = $Prefix; Name = $Name; Target = $Record.NameHost; Found = [bool]$Record }
}
catch {
[pscustomobject]@{ Domain = $Domain; Record = $Prefix; Name = $Name; Target = $null; Found = $false }
}
}
}
$Results | Sort-Object Domain, Record | Format-Table -AutoSize
$Results | Export-Csv -Path .\enrollment-cname-audit.csv -NoTypeInformationTo build the domain list, start from the verified domains in your tenant and the UPN suffixes your users really have. If a resolver returns nothing for a name you know exists, check from outside your network too; split-brain DNS can hide a public record.
You can also check one domain at a time in the Intune admin center. Learn gives the path: Devices > Device onboarding > Enrollment > Windows tab > Enrollment options > CNAME Validation, then enter the domain and choose Test.
Read the results
- EnterpriseEnrollment found, MDM-only enrollment in use on that domain: you’re in scope. Update the guides and test before January 15, 2027.
- EnterpriseEnrollment found, every Windows device joins through Microsoft Entra join, hybrid join or automatic enrollment: Microsoft says you likely aren’t affected. Learn’s CNAME page also says that with MDM automatic enrollment, “you don’t have to worry about configuring CNAME records.” Confirm nobody (contractors, a lab, a kiosk team) still uses Access work or school to enroll MDM-only before you close the ticket.
- No EnterpriseEnrollment record: per Learn, users are already “prompted to manually enter the MDM server name” today, so the experience shouldn’t change much for those domains.
What users will see
Today, with the record in place, the blog says “the user doesn’t need to provide the enrollment server information.” After the change, “If the enrollment service URL isn’t already provided by the enrollment experience, the user will need to enter it when prompted. Enrollment can then continue using the Microsoft enrollment service URL.”
Put the full URL in your guide exactly as Microsoft gives it: https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc. The older Learn text names the server as enrollment.manage.microsoft.com; I’d still give users the full URL from the announcement so they can paste it. I don’t have a screenshot of the new prompt, and I won’t describe its wording until it ships.
Government cloud tenants: the Learn page lists different names for US government environments (for example enrollment.manage.microsoft.us), and the announcement doesn’t give a government URL. Check with Microsoft before updating those guides.
Don’t delete the records yet
Microsoft’s FAQ answer to “Do I need to remove my EnterpriseEnrollment DNS record?” is to review your environment and DNS configuration requirements, because “This change only affects use of the record for Windows MDM-only enrollment auto-discovery.” It does not tell you to remove it. Learn’s CNAME page covers more than Windows, and the EnterpriseRegistration record is separate. My recommendation: leave both records until you’ve confirmed nothing else in your estate uses them, then decide.
Update these documents
Microsoft lists internal enrollment guides, help desk procedures, device deployment instructions, provisioning documentation and user onboarding materials. Add the URL, a line saying when users might be asked for it, and a contact for help. Brief the help desk before the date, since the first call will likely be someone stuck at the prompt.
If you’re moving away from MDM-only enrollment entirely, see Windows Autopilot: the complete guide and Autopilot re-enrollment error 0x80180014 for related enrollment issues.
FAQ
When does Intune stop supporting EnterpriseEnrollment CNAME auto-discovery?
Starting January 15, 2027, or soon after, for Windows MDM-only enrollment, per MC1509780 and the Intune Customer Success blog.
Are already enrolled devices affected?
No. Microsoft says existing enrolled devices remain enrolled and aren’t affected.
What URL do users enter?
https://enrollment.manage.microsoft.com/enrollmentserver/discovery.svc, when the enrollment experience doesn’t already provide it.
Does this affect the EnterpriseRegistration CNAME?
The announcement only names the EnterpriseEnrollment record. Learn describes EnterpriseRegistration as the record Microsoft Entra ID uses for device registration.
Sources
All retrieved 2026-10-26.
- Preparing for end of support for CNAME auto-discovery in Windows MDM-only enrollment, Intune Customer Success blog, Microsoft Tech Community, published October 15, 2026: date, scope, user experience, FAQ.
- Microsoft 365 Message Center MC1509780, “Intune ending support for Windows MDM-only enrollment CNAME auto-discovery” (read through the public archive at mc.merill.net because the admin center needs a sign-in): “or soon after”, act-by date.
- Enable autodiscovery of Intune enrollment server, Microsoft Learn: record names and targets, one record per UPN suffix, CNAME Validation path, EnterpriseRegistration purpose, government names.
- Resolve-DnsName, Microsoft Learn.