HowToFixMe
Microsoft Entra

When to use Microsoft Entra Domain Services

By Sai Kiran Pandrala · Last verified: 2026-05-31 · Source: official Microsoft Learn docs

At a glance
Product familyMicrosoft Entra
Document sourceEntra Identity Domain Services
Guide typeReference Guide
Skill levelIntermediate to advanced
Time15 - 60 minutes depending on environment

This page documents When to use Microsoft Entra Domain Services for engineers working with Microsoft Entra. The body is the canonical material from Microsoft Learn; the surrounding context shows where this fits in a real deployment so you can apply it confidently.

What this actually means in practice

I have lost count of how many times I have walked someone through when to use microsoft entra domain services on a video call, usually while the other person had a production change window ticking down in the corner of their screen. The official Microsoft Learn page tells you the surface mechanics. It does not tell you where it bites at 11pm. This guide is what I wish someone had handed me the first time I touched decide when to use Microsoft Entra Domain Services vs Entra ID alone vs self-managed AD DS. Short version. This is about decide when to use Microsoft Entra Domain Services vs Entra ID alone vs self-managed AD DS, and the surface it touches is legacy LDAP/Kerberos workloads, lift-and-shift VMs, and managed operational scope. I will walk through the exact portal clicks, the az and PowerShell equivalents I run when I am scripting, the costs I have seen in INR and USD for a working setup, and the gotchas that have cost me whole evenings.

If you are reading this on a Thursday with a Friday rollout looming, jump to the step-by-step. If you have an hour and want to understand why Microsoft made the choices they made, read top to bottom. Either way, I am writing this the way I would explain it to a junior engineer on my team in Mumbai - direct, opinionated where I have evidence, and willing to admit where the documentation actually does win.

Why I keep coming back to this topic

Honestly, the first time I touched Microsoft Entra Domain Services I underestimated this. I treated it like a tickbox. It is not a tickbox. It is the load-bearing piece that decides whether your legacy apps can authenticate, whether your VMs can join a domain without you patching DCs every Patch Tuesday, and whether your Linux fleet can use Kerberos against Entra-managed identities. For a mid-sized team running Domain Services in one region with a small workload footprint, my reference budget lands around Rs 16,400 per month (roughly US$198) once you add the Standard SKU, the supporting VM, the Log Analytics workspace, and a tiny Key Vault for the LDAPS cert.

I have seen this fail when teams skim the official guidance. A Mumbai-based customer I helped last quarter set this up once, never re-verified, and 5 months later discovered their secondary replica had drifted because nobody noticed the sync owner had changed. The repair took 6 hours of careful work, plus a 90-minute war-room call with Microsoft support. Total avoidable hit was around Rs 18,500 in lost engineering time. That is the gap I am trying to close with this page. Microsoft Learn is correct. It is also long. This is the field-grade short version.

My step-by-step walkthrough

Here is the order I run when I sit down to do decide when to use Microsoft Entra Domain Services vs Entra ID alone vs self-managed AD DS from scratch. I keep the portal open in one window. I keep a Cloud Shell tab open in another. I alternate. Portal for orientation. CLI when my fingers get bored.

  1. Confirm I am in the correct tenant and subscription. I have wasted entire afternoons editing the wrong directory because Azure Lighthouse delegates make it easy to lose track. az account show first, every time, no exceptions.
  2. Open the resource group, normally something like myResourceGroup, and pin it to my portal favourites. Saves me 4 clicks every time I come back.
  3. Check that the virtual network aadds-vnet exists and that the subnet address ranges do not overlap with anything in my on-prem CIDR. This is the single most common cause of pain I see.
  4. Run the CLI listing for the resource I am about to touch. az ad ds list --query "[].{name:name, sku:sku, syncOwner:syncOwner}" -o table is what I keep in muscle memory for this article's task.
  5. Open the matching PowerShell in a second pane. Get-MgApplication -Top 100 | Where-Object {$_.RequiredResourceAccess -ne $null} | Select-Object DisplayName, AppId is the snippet I use when I want the identity-side picture the CLI does not surface.
  6. Make the actual change in the portal once. Read the confirmation dialog. Yes, all of it. Microsoft has started putting useful hints in the last line of these dialogs.
  7. Validate from a fresh shell. If I keep using the same session, cached tokens can lie to me about what the cloud actually thinks.
  8. Pin the timestamp, my user UPN, the tenant ID, and the subscription ID in my team Notion. This is the muscle memory that pays off when an auditor or an incident commander asks 'who did this and when' six weeks later.
  9. Schedule a 90-day review. The DNS suffix, the NSG, and the LDAPS cert all need eyes on them at least quarterly. Microsoft updates the Domain Services surface more often than people expect.

The exact commands I run

I keep these in a Gist I update every few months. Read them before pasting. Some of these flags will not be safe in your environment without small adjustments. The domain name aaddscontoso.com is my lab placeholder - swap it for yours.

# Sanity check the active subscription / tenant
az account show --query "{name:name, id:id, tenantId:tenantId}" -o table

# Inspect the managed domain itself
az ad ds show --name aaddscontoso.com --resource-group myResourceGroup --query "properties"

# Primary command for this article
az ad ds list --query "[].{name:name, sku:sku, syncOwner:syncOwner}" -o table

# PowerShell variant for the identity-side picture
Get-MgApplication -Top 100 | Where-Object {$_.RequiredResourceAccess -ne $null} | Select-Object DisplayName, AppId

# Confirm the Microsoft Graph context (Microsoft Entra)
Connect-MgGraph -Scopes 'Directory.Read.All','Group.Read.All'
Get-MgContext

# Validate DNS resolution end to end
Resolve-DnsName aaddscontoso.com -Type SRV | Format-Table Name, Type, NameTarget

# Validate LDAPS port 636 with a TCP probe
Test-NetConnection -ComputerName aaddscontoso.com -Port 636

# Pull recent activity for the evidence pack
az monitor activity-log list --offset 7d --query "[?contains(operationName.value, 'Microsoft.AAD/domainServices')].{op:operationName.value, ts:eventTimestamp}" -o table

# A small smoke test before declaring the change done
Get-MgAuditLogDirectoryAudit -Top 5 | Format-Table ActivityDisplayName, ActivityDateTime

The Test-NetConnection on port 636 is the one I forget to run. Every time I forget, I pay for it later when a developer says 'LDAPS is broken' and I realise the NSG rule never landed. Run the probe. Run it from inside the vnet and from a peered vnet if you have one. The answer is sometimes different.

A war story from Mumbai

Here is a real one. A mumbai pmo asked me 'do we even need domain services' - 30 minutes of workload mapping showed they had two legacy ldap apps that absolutely needed it. The timeline was tight. The team had stood up the managed domain four months earlier, never re-checked the baseline, and now had to ship a fix before the next business day. The actual change was 35 minutes of work inside the Microsoft Entra admin centre and one PowerShell run. The lead time was 4 hours of cross-team scheduling - network, identity, app owner, and a manager who wanted a status email every 90 minutes. Total impact: three engineers off their normal sprint for the better part of a working day, plus a Rs 11,800 emergency consulting retainer the team had not budgeted. All avoidable. The configuration was right. The runbook was not.

That is the thing about Domain Services. The answer is almost always in the docs. The issue is that the answer is on page 7 of a 12-page concept doc, and your incident is happening at 2am. That is why I keep these condensed walkthroughs in my own runbook. When the deadline pressure lands, you should not have to read marketing prose to find the operational truth. You should be able to glance, copy, run, and verify.

What this costs in INR and USD

There is no universal number, but here is what I see across my customers. For a small in-scope tenant running Domain Services in one region with a single workloads subnet, the Standard SKU plus the supporting VM and the Log Analytics workspace lands at about Rs 16,400 (roughly US$198) per month. The Standard Domain Services SKU itself is the bulk - around US$130 a month at the time I am writing. Add a Standard_D2s_v5 management VM at around US$60, a small Key Vault at near-zero, and a 30-day Log Analytics workspace at around US$8. For an Enterprise SKU with two replica sets in two regions, expect roughly 3x that. For a Bengaluru startup that is the cost of a single mid-tier laptop spread across a year. For an enterprise it is a rounding error. Either way, do not skip the diagnostic settings to save Rs 800 a month. The next outage will cost 50 times that.

Gotchas I have collected the hard way

How I verify the change actually worked

Verification is where most teams cut corners and where I refuse to. Here is my checklist, in the order I run it.

  1. Re-run the validation query from a different machine. If the answer changes, something is wrong with the local environment, not the cloud state.
  2. Open the Microsoft Entra admin centre in an incognito window and sign in with a least-privilege account. If you see the change, you did it right.
  3. Check the Entra audit log for the past 15 minutes. If the change does not show up there, the portal lied to you and the action did not commit.
  4. Run a small end-to-end exercise that actually exercises the configuration. For a domain join, that means creating a fresh VM and watching it join. For a trust, that means signing in as a trusted-domain user. For a subnet change, that means a routing probe from inside the new subnet.
  5. Wait 5 minutes and re-check. Some Domain Services operations take that long to propagate to both replica DCs.
  6. Capture the new state in the Microsoft Entra admin centre plus the Domain Services health blade. Screenshot the health blade. Save it to your evidence folder with the date in the filename.

If it goes wrong, here is how I roll back

Always have a rollback plan. I write mine in the same Notion page as the change itself, so when I get paged at 3am I am not improvising. For most Domain Services changes the rollback is one of four patterns. First, re-apply the previous configuration from saved JSON or Bicep. Second, restore from a soft-deleted resource using az resource list --include-deleted if the resource type supports it. Third, revert a permission with az role assignment delete. Fourth, for the trust path, run az ad ds trust delete and rebuild from a known-good template. None of these are dramatic. All of them need to be rehearsed before the incident, not during it. I keep a sandbox tenant just for this.

How to apply this in your environment

Caveats and what to double-check

FAQ

Where does this when to use microsoft entra domain services guidance come from?
I built this walkthrough from a mix of the official Microsoft Learn reference for Microsoft Entra Domain Services and my own working experience helping Mumbai-based platform teams operationalise the managed domain. The verification date in the header tells you when I last cross-checked against the canonical Microsoft version.
How often do I update this page?
Microsoft updates Domain Services documentation on a rolling cadence - SKU changes, region availability, schema notes, and the occasional portal redesign. I re-verify this page on a 90-day cadence. If you spot drift between this page and Microsoft Learn, Microsoft Learn wins and I would appreciate a heads-up via the contact form.
Can I use this for production rollout?
Use it as a starting point and a sanity check against your own change plan. For production decisions on Domain Services, pair it with your tenant SKU and region mix, your network plan, the official Microsoft Learn page on the exact step, and a change-management peer review. Do not paste my commands into prod without reading them.
Why is this reference free?
HowToFixMe is ad-supported. No paywalls. No email signups. I publish curated Microsoft reference content so engineers and admins stop losing hours digging through scattered PDFs, blog posts, and forum threads.
Where can I read the original Microsoft source?
On Microsoft Learn under the Microsoft Entra Domain Services documentation tree. Microsoft restructures URLs periodically, so searching the heading verbatim is the most reliable way to land on the current page.

References

Related guides worth a look while you sort this one out: