# Microsoft365DSC: tenant configuration as PowerShell Desired State Configuration

> Microsoft365DSC turns Microsoft 365 tenant settings into PowerShell DSC configurations you can deploy, extract and monitor. It fits teams already running DSC or CI pipelines, and it fails loudly on tenants without the right Defender for Office 365 licensing.

**Microsoft365DSC/Microsoft365DSC** — Manages, configures, extracts and monitors Microsoft 365 tenant configurations

- Repository: https://github.com/Microsoft365DSC/Microsoft365DSC
- Website: https://microsoft365dsc.com/
- Stars: 2,402 · Forks: 681
- Language: PowerShell
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft365dsc-microsoft365dsc

## The drift problem Microsoft365DSC was built for

A Microsoft 365 tenant accumulates settings from many places. Someone toggles a sharing policy in SharePoint, an admin edits a conditional access rule in Entra, another person adjusts an anti-phish threshold in Exchange Online. None of those changes leaves a diff, and none of them is reviewed. Microsoft365DSC exists to make those settings declarative: you write them down, the module compares the written state to the live tenant, and you decide whether to deploy or to report. The README describes the scope as automating "the deployment, configuration, reporting and monitoring of Microsoft 365 Tenants via PowerShell Desired State Configuration." That sentence is the whole product. It is aimed at the administrator who already thinks in configuration files and pipelines, not at the admin who clicks through the Microsoft 365 portal. If you never wanted a source of truth for tenant settings, this module will feel like overhead rather than relief.

## How the DSC compilation and remote API calls fit together

The architecture follows standard PowerShell DSC. You write a configuration script, PowerShell compiles it into a MOF file, and a Local Configuration Manager on a machine or in a container applies it. Microsoft365DSC supplies the resources that the compiled configuration references. The README is explicit that the agent "can communicate back remotely to Microsoft 365 via remote API calls (therefore requires internet connectivity)." That detail matters more than it looks. The DSC agent is not a passive local enforcer; it is an outbound client that authenticates to Microsoft Graph, Exchange Online and the other workloads on every consistency check. The repository layout reflects the breadth: topics cover azuread, exchangeonline, intune, sharepoint, teams, powerplatform and securityandcompliance, and there are per-workload integration pipelines in .github for AAD, EXO and INTUNE. The module also ships a resource generator and a Modules directory, which is how the resource set is kept current as Microsoft changes its APIs. The practical consequence is that a run is only as reliable as the network path and the credentials between your agent and Microsoft's endpoints.

## Installing the module and exporting a tenant configuration

The README gives two lines for installation, and they do different jobs. The first pulls the module from the PowerShell Gallery; the second updates it to the latest available build. Run them from a machine with internet connectivity, as the README states.

```powershell
Install-Module -Name Microsoft365DSC -Force
Update-M365DSCModule
```

After that, the common first task is extraction rather than deployment: read the current tenant and write it out as a configuration you can review. The related searches around this project are dominated by that verb, Export-M365DSCConfiguration, which is the cmdlet the module exposes for it. The README does not spell out the export parameters, so check the official site at Microsoft365DSC.com and the documentation under docs/ before running it against production. Expect the export to require authentication to each workload it touches, and expect a long first run on a large tenant. Once you have the exported file, the normal DSC path applies: compile it, apply it from an agent, and let the Local Configuration Manager report drift on subsequent runs.

## The licensing trap that looks like a module bug

This is the sharpest limitation in the README, and it is worth reading twice. Six resources require Defender for Office 365 Plan 2: EXOAntiPhishPolicy, EXOSafeAttachmentPolicy, EXOSafeLinksPolicy, EXOAtpPolicyForO365, EXOAtpProtectionPolicyRule and EXOMalwareFilterPolicy. Microsoft 365 E5, Office 365 E5, and E3 with the Defender for Office 365 Plan 2 add-on support them. Plain Microsoft 365 E3 and Office 365 E3 do not, because E3 includes only Exchange Online Protection. The failure mode is the problem. Instead of a licensing message, you get parameter errors such as "A parameter cannot be found that matches parameter name 'EnableTargetedDomainsProtection'." That reads like a version mismatch or a typo in your configuration. It is neither. The README's own advice is to check licensing before assuming a configuration or module bug. Two checks are provided. The Graph one lists subscribed SKUs, and the Exchange Online one is a functional test: if Get-AntiPhishPolicy with the -Advanced parameter succeeds, Defender for Office 365 is active.

```powershell
Connect-MgGraph -Scopes "Organization.Read.All"
Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -like "*E5*" }
```

```powershell
Connect-ExchangeOnline -AppId <AppId> -CertificateThumbprint <Thumbprint> -Organization <Organization>
Get-AntiPhishPolicy -Identity "Office365 AntiPhish Default" -Advanced
```

If your tenant is E3-only and you need those six resources, Microsoft365DSC is the wrong tool until the licence changes. No amount of configuration editing will fix it.

## Telemetry, and the opt-out you should decide on deliberately

Microsoft365DSC sends telemetry by default. The README says it captures the names of resources where drift was detected and the types of exceptions thrown by errors in the various modules. It states that no sensitive data is captured, but it also states that App Insights records the city where the telemetry entries originated. That is a real disclosure about administrator location, however coarse, and it is the kind of detail a regulated tenant will want reviewed rather than assumed. The opt-out is a single command, and the README gives it directly.

```powershell
Set-M365DSCTelemetryOption -Enabled $False
```

The honest reading is that this is a reasonable default for a community-driven Microsoft project, and an easy one to turn off. What the README does not document is what happens to already-sent telemetry, how long it is retained, or whether the opt-out is per-user or per-machine. If those questions matter to your organisation, treat the default as something to switch off before the first run rather than after.

## Where Microsoft365DSC stops being the right answer

The module assumes you have a DSC host. That is the constraint that disqualifies most teams. If you have no machine or container running a Local Configuration Manager, Microsoft365DSC gives you an extraction tool and nothing else. You can still export a tenant to a file and diff it by hand, but you lose the deploy and monitor halves of the product, which are the reason it exists. Two other cases deserve a direct answer. First, tenants on E3 without the Defender add-on cannot deploy the six resources listed above, so a configuration that includes them will fail in a way that is hard to diagnose. Second, the module's domain is broad (Azure AD, Exchange, Intune, SharePoint, Teams, Power Platform, compliance) and that breadth means each area gets less depth than a workload-specific tool. If your entire problem is Intune policy comparison, a narrower tool will be easier to reason about. Microsoft365DSC is strongest when the tenant as a whole is the unit of configuration.

## Microsoft365DSC compared with EntraExporter and UTCM

The related searches point at two alternatives worth naming. EntraExporter is narrower by design: it exports Entra ID configuration so you can inspect it, and it does not attempt to deploy or continuously monitor a tenant through DSC. If your goal is a readable snapshot of directory objects, EntraExporter is the smaller tool for the smaller job. Microsoft Unified Tenant Configuration Management (UTCM) comes from Microsoft itself and is a service rather than a PowerShell module; it is aimed at configuration management inside the Microsoft 365 admin surface, not at a DSC agent on your own infrastructure. The difference in approach is where the state lives and who runs the comparison. Microsoft365DSC puts the desired state in your repository, runs the comparison from your agent, and reports through DSC. A hosted service puts that machinery on Microsoft's side. Neither is strictly better. A team with an existing DSC pipeline and a preference for keeping configuration files in its own source control will find Microsoft365DSC fits; a team that wants no agent to maintain will prefer the hosted route.

## Maintenance cost, release cadence and the MIT licence

The release history shows a fast cadence: 1.26.909.1 on 2026-09-11, 1.26.902.1 on 2026-09-03, and 1.26.819.1 on 2026-08-20. The last push to the Dev branch was on 2026-09-28, and the repository is not archived. That cadence is a double-edged fact. It means fixes for changed Microsoft APIs arrive quickly, and it means the version you pin will age. Treat the module as a dependency you upgrade on a schedule rather than install once. The README points contributors at the Dev branch and says master holds the latest release, with Dev periodically merged into master and published to the PowerShell Gallery; Update-M365DSCModule is the command that pulls a newer build. The licence is MIT, which is permissive and places few obligations on how you redistribute or embed the module. That is a statement about the licence text, not legal advice; if you ship the module inside a commercial product, have your own counsel read the LICENSE file and the notices for any bundled dependencies. The README does not document a rollback procedure for a bad deployment, so plan how you would revert a tenant change before you make one.

## Conclusion

Adopt Microsoft365DSC if your team already runs PowerShell Desired State Configuration or a CI pipeline and wants tenant settings expressed as code that can be extracted, deployed and monitored. Do not adopt it if you have no DSC host and no appetite for maintaining one, or if your tenant is E3-only and you need the Defender for Office 365 resources. Verify three things first: that your DSC agent can reach Microsoft 365 APIs over the internet, that your licensing covers every resource in your configuration, and that you have decided whether to keep telemetry on. The README's own escape hatch is Set-M365DSCTelemetryOption -Enabled $False, and the licence check is Get-MgSubscribedSku | Where-Object { $_.SkuPartNumber -like "*E5*" }.

## FAQ

### What is Microsoft365DSC?

It is a PowerShell module that manages, configures, extracts and monitors Microsoft 365 tenant configurations through PowerShell Desired State Configuration. The README describes its purpose as automating the deployment, configuration, reporting and monitoring of Microsoft 365 tenants.

### How do I use Microsoft365DSC?

You install it from the PowerShell Gallery, write or export a DSC configuration, compile it to MOF, and apply it from an agent whose Local Configuration Manager can reach Microsoft 365 APIs over the internet. The README directs new users to Microsoft365DSC.com for getting-started documentation.

### What is an alternative to Microsoft 365 DSC?

EntraExporter exports Entra ID configuration for inspection but does not deploy or monitor a tenant through DSC. Microsoft Unified Tenant Configuration Management is a Microsoft-hosted service rather than a PowerShell module you run on your own agent.

## Sources

- [License: MIT](https://github.com/Microsoft365DSC/Microsoft365DSC/blob/Dev/LICENSE)
- [Microsoft365DSC/Microsoft365DSC on GitHub](https://github.com/Microsoft365DSC/Microsoft365DSC)
- [Project website](https://microsoft365dsc.com/)
- [README](https://github.com/Microsoft365DSC/Microsoft365DSC/blob/Dev/README.md)
- [Releases](https://github.com/Microsoft365DSC/Microsoft365DSC/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft365dsc-microsoft365dsc