DEV.co
Open-Source DevOps · Microsoft365DSC

Microsoft365DSC

Microsoft365DSC is a PowerShell module that uses Desired State Configuration to automate deployment, configuration, and monitoring of Microsoft 365 tenant settings across Azure AD, Exchange Online, Teams, SharePoint, Intune, and other M365 services. It allows organizations to define and enforce consistent configurations as code rather than manual portal clicks.

Source: GitHub — github.com/Microsoft365DSC/Microsoft365DSC
2.3k
GitHub stars
665
Forks
PowerShell
Primary language
MIT
License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

FieldValue
RepositoryMicrosoft365DSC/Microsoft365DSC
OwnerMicrosoft365DSC
Primary languagePowerShell
LicenseMIT — OSI-approved
Stars2.3k
Forks665
Open issues116
Latest release1.26.701.1 (2026-07-02)
Last updated2026-07-07
Sourcehttps://github.com/Microsoft365DSC/Microsoft365DSC

What Microsoft365DSC is

A PowerShell DSC resource provider that compiles M365 configurations and executes them via Local Configuration Manager (LCM) agents, communicating with M365 APIs remotely. Supports extraction, drift detection, and reporting across 10+ M365 workloads; includes unit and integration test coverage with CI/CD pipelines.

Quickstart

Get the Microsoft365DSC source

Clone the repository and explore it locally.

terminalbash
git clone https://github.com/Microsoft365DSC/Microsoft365DSC.gitcd Microsoft365DSC# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

Multi-tenant Configuration Governance

Organizations managing multiple M365 tenants can codify policies (security baselines, Teams settings, SharePoint permissions) and enforce consistency across environments using version-controlled DSC configurations.

Drift Detection and Compliance Reporting

Continuous monitoring of M365 tenant configuration drift against desired state; automated reports on security/compliance deviations (e.g., MFA policies, data loss prevention rules, retention policies).

Infrastructure-as-Code for M365 Setup

Automate initial tenant provisioning, post-acquisition integrations, or large-scale configuration changes (e.g., Teams policies, Exchange mail flow rules) without manual portal navigation.

Implementation considerations

  • Agents must run on Windows with PowerShell 5.0+ and internet connectivity to M365 APIs; plan network access and credential management (service principal, app registration scopes).
  • Authentication requires Azure AD/Entra ID service principal or delegated permissions; review required API scopes per workload (AAD, Exchange, Teams, SharePoint, Intune) and least-privilege assignments.
  • Configuration compilation and LCM pull/push cycles introduce latency; set realistic enforcement intervals based on org change velocity and risk tolerance.
  • Telemetry is enabled by default (sends drift resource names and error types); review privacy/compliance requirements and disable if needed via Set-M365DSCTelemetryOption.
  • Testing requires access to non-production M365 tenant or isolated test subscriptions; integration tests shown in CI/CD pipelines run against live service endpoints.

When to avoid it — and what to weigh

  • Non-Windows/PowerShell Environment — If your infrastructure relies primarily on non-Windows agents or lacks PowerShell 5.0+ runtime, LCM execution becomes difficult; Linux/Mac agents require Windows containers or remote execution setup.
  • Real-Time Reactive Automation — DSC is pull/push-based configuration management, not event-driven automation; if you need immediate, reactive responses to M365 events, consider event-driven workflows (Azure Logic Apps, Power Automate) alongside or instead.
  • No M365 API Access or Air-Gapped Networks — Module requires direct outbound HTTPS connectivity from agents to M365 APIs; cannot operate in fully air-gapped environments without proxy/relay setup.
  • Simple One-Off Changes — For occasional manual adjustments, DSC introduces overhead; best suited to repeated, versioned deployments rather than ad-hoc tweaks.

License & commercial use

MIT License (permissive OSI-approved license permitting use, modification, and distribution with attribution; no commercial use restrictions).

MIT License permits commercial use without explicit permission. However, no warranty is provided; deployment in production M365 environments requires internal testing, support plan decisions (community vs. Microsoft support engagement), and compliance review with your org's legal/procurement teams.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

SignalAssessment
MaintenanceActive
DocumentationAdequate
License clarityClear
Deployment complexityModerate
DEV.co fitGood
Assessment confidenceHigh
Security considerations

Agents store M365 credentials (service principal secrets) locally; secure credential storage (Windows DPAPI, Azure Key Vault integration) and agent access control are critical. Telemetry captures drift resource names (not values) but includes location data via App Insights; disable if privacy-sensitive. API scope assignments should follow least-privilege; overly permissive service principals increase blast radius. No explicit security audit data provided; assess using STIG/CIS benchmarks if required for gov/finance workloads.

Alternatives to consider

Azure Policy (Regulatory Compliance)

Native Azure service for M365/Entra ID policy enforcement and compliance reporting; no agent infrastructure needed; limited to Azure native resources and lacks some workload coverage (e.g., Exchange, Teams detailed settings).

Power Automate / Azure Logic Apps

Event-driven cloud-native automation for reactive M365 workflows (e.g., approval chains, notifications); easier for non-PowerShell teams but lacks declarative state management and DSC idempotency.

Manual PowerShell Scripting + Change Management

Lower overhead for small orgs or one-off changes; no agent infrastructure but sacrifices version control, idempotency, and drift detection benefits of DSC.

Software development agency

Build on Microsoft365DSC with DEV.co software developers

Schedule a technical review with your infrastructure and M365 teams to assess fit for your automation, compliance, and governance needs. Start with a non-production tenant POC to validate PowerShell, API permissions, and LCM integration.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

Related on DEV.co

Explore the category and the services that help you build with it.

Microsoft365DSC FAQ

Does Microsoft365DSC support non-Windows agents?
No direct support. DSC relies on Windows LCM. Linux/macOS can call PowerShell remotely or in containers, but requires additional setup and is not natively supported.
Can I use this without a service principal or app registration?
No. Module requires Azure AD service principal or delegated user credentials with sufficient API scopes to manage M365 workloads; define scopes per workload (AAD, Exchange, Teams, SharePoint, Intune) based on intended automation scope.
Does DSC prevent manual changes in the M365 portal?
No. DSC detects drift but does not block portal changes; enforcement depends on LCM refresh intervals and remediation logic in configurations. Manual changes will be reverted on next compliance check if configuration specifies otherwise.
What is the learning curve for PowerShell/DSC?
Requires intermediate PowerShell skills and understanding of DSC concepts (resources, configurations, LCM). Teams familiar with Infrastructure-as-Code principles and PowerShell will ramp faster; new adopters should allocate time for POC and training.

Software development & web development with DEV.co

Adopting Microsoft365DSC is usually one piece of a larger software development effort. As a software development agency, DEV.co provides software development services and web development expertise — pairing senior software developers and web developers with your team to design, build, and operate open-source devops software in production.

Ready to Evaluate Microsoft365DSC?

Schedule a technical review with your infrastructure and M365 teams to assess fit for your automation, compliance, and governance needs. Start with a non-production tenant POC to validate PowerShell, API permissions, and LCM integration.