Microsoft 365 DSC: The Practical Guide to Configuration as Code for Your Tenant

To understand Microsoft 365 DSC, it helps to first know what PowerShell Desired State Configuration (DSC) is.

PowerShell DSC is a configuration management technology that’s been part of PowerShell since version 4. The core idea is very simple but powerful:

• You declare the state you want (for example, a registry key with a certain value, a Windows feature that must be installed, a service that must be running).
• DSC ensures and maintains that state on the target system.

The key here is that DSC uses a declarative approach, not an imperative one.

• Imperative (typical scripting): “Do this, then this, then that.” You describe steps.
• Declarative (DSC): “This setting should be X.” You describe the goal, and DSC figures out the steps and keeps it that way.

For example, for an on-prem server you might define that a certain registry key must exist with a specific value. DSC will:

1. Check the current state.
2. If the key/value is missing or wrong, create or update it.
3. Periodically re-check and fix it again if needed.

Microsoft 365 DSC takes this idea and applies it to your Microsoft 365 tenant configuration—Exchange Online, SharePoint Online, Teams, security and compliance settings, and so on.

Traditionally, Microsoft 365 administration has looked like this:

• You open the Microsoft 365 admin center (or SharePoint/Teams/Exchange portals).
• You click through pages of options.
• You manually set values for policies, limits, sharing settings, and other controls.

This works for a single small tenant, but it becomes painful when:

• You manage multiple tenants (e.g., for different regions, subsidiaries, or customers).
• You maintain separate environments (dev, test, production).
• Different admins occasionally tweak settings directly in the portal.
• Auditors ask, “So what exactly is your current configuration?”

Microsoft 365 DSC changes the workflow completely:

1. You define the desired configuration in code (PowerShell DSC format).
2. You deploy that configuration to your tenant.
3. Microsoft 365 DSC continuously monitors and enforces that configuration.

Instead of trying to remember who changed what, when, and where, you:

• Track changes in version control (for example Git).
• Use CI/CD pipelines (like Azure DevOps) to validate and deploy changes.
• Rely on automated drift detection to catch unapproved manual changes.

In my experience, once teams get over the initial “config as code” learning curve, they rarely want to go back to purely manual administration.

The core feature of Microsoft 365 DSC is the ability to deploy tenant configuration automatically.

You express your Microsoft 365 configuration as code. That configuration can cover a wide range of resources (depending on what you select), including:

• Exchange Online policies and limits
• SharePoint and OneDrive settings (like storage limits)
• Teams policies
• Security and compliance settings
• And more, depending on what resources you export or define

Once you have this configuration file, you use PowerShell DSC to apply it. During deployment, DSC ensures that:

• Each defined setting is applied with the specified value
• Resources that are missing are created if necessary
• Existing configuration is updated to match the desired state

A practical example from the transcript:

• The tenant initially has a storage limit set to 512 GB.
• The DSC configuration defines that the storage limit should be 1 TB.
• After applying the configuration, a refresh of the admin portal shows the limit updated to 1 TB—done entirely through DSC, without a single manual click.

That’s a small change, but scale that out to hundreds or thousands of configuration items and you can see the impact. No more hunting through portals trying to remember which checkbox controls what.

One of the most powerful aspects of PowerShell DSC—and by extension Microsoft 365 DSC—is the ability to detect and respond to configuration drift.

Configuration drift happens when the actual configuration of your tenant slowly diverges from what you originally intended. Common causes include:

• An admin making a quick change in the portal “just for this one case.”
• Emergency troubleshooting that never gets cleaned up.
• Lack of documentation or handover between teams.

With Microsoft 365 DSC:

• After deployment, DSC periodically checks (by default, about every 15 minutes) whether your tenant is still in the desired state.
• If something has changed, DSC can:
• Log or alert on the difference, or
• Automatically revert the change and bring the tenant back into compliance.

This is huge for security and compliance. For example:

• If someone relaxes a sharing policy manually, DSC can catch it.
• If a retention or DLP setting is altered, you’ll know.

To be honest, this alone makes DSC worth considering for any organization that’s serious about governance of Microsoft 365.

One of the most common challenges when moving to configuration as code is getting started. You might be thinking, “Our tenant is already configured. Do we have to re-create all of this by hand in code?”

The good news is: no, you don’t.

Microsoft 365 DSC can export the current configuration of a tenant into PowerShell DSC format. When you run an export:

1. Microsoft 365 DSC connects to the tenant using the credentials and authentication method you specify.
2. It reads the configuration for the selected Microsoft 365 resources.
3. It generates two files:
- One file with tenant-specific information (things like tenant ID, URLs, or other unique identifiers).
- One file with the actual DSC configuration (the reusable configuration as code).

You don’t even have to hand-craft the export command. There’s a helper site, `export.microsoft365dsc.com`, where you can:

• Select the resources you want to export.
• Pick the authentication method.
• Let the tool generate the export command for you.

You can then take that exported configuration and:

• Use it as a baseline for future environments.
• Clean it up, tweak it, and put it under source control.
• Use it as the foundation for automation and CI/CD.

Ask almost any admin what they think about writing configuration documentation and you’ll usually get the same reaction: it’s necessary, but not fun.

Microsoft 365 DSC turns your exported configuration into an automatic source of truth. Using the documentation cmdlets, you can convert any extracted configuration into:

• HTML reports
• Excel files
• JSON output

This gives you a quick way to:

• Share the configuration with management, auditors, or peers.
• Review key settings at a glance.
• Keep documentation current, because it’s generated right from the actual tenant configuration.

In my experience, this alone can save hours during audits or handovers. No more “I think this is still accurate” Word documents buried in SharePoint somewhere.

Another underrated capability of Microsoft 365 DSC is its support for comparison and reporting of differences.

Using the Delta report cmdlet, you can take two exported configurations and generate a detailed discrepancy report. This shows you exactly where the configurations do not match.

There are two very useful scenarios here:

1. Comparing two different tenants
For example:
- Dev vs Test
- Test vs Production
- Regional or customer-specific tenants

You can check whether a tenant still complies with your security baseline or global blueprint.

2. Comparing the same tenant at two points in time
For example, you might export the configuration monthly and then compare:
- Last month vs this month
- Before vs after a large migration or rollout

This way you get a clear, structured report of:

• Which settings changed
• What the old vs new values are

Instead of trying to guess what went wrong after an incident, you have a change history in a format that’s easy to review.

Once you’re able to export and apply configurations, another obvious scenario opens up: cloning a configuration from one tenant to another.

You can:

1. Export the configuration of a source tenant (for example, your well-configured production tenant or a reference baseline tenant).
2. Import and apply that configuration to a target tenant.

This is particularly useful when you want to:

• Stand up a new tenant quickly with a known-good configuration.
• Spin up a test tenant that mirrors production as closely as possible.
• Bring multiple tenants into alignment with a central baseline.

Of course, in practice you’ll often adjust certain tenant-specific values, but having a full-fidelity starting point is a massive time saver compared to reconfiguring everything manually.

By representing your Microsoft 365 tenant configuration as code, you immediately unlock a bunch of benefits:

• Version control: Store your DSC configurations in Git (or another VCS). You get history, diffs, and the ability to roll back.
• Code review: Changes to tenant configuration can go through pull requests, approvals, and review—just like application code.
• Automated validation: Use CI pipelines to lint, test, or validate configurations before deployment.
• Controlled deployment: Use CD pipelines to gradually roll out changes to dev, test, then production tenants.

The transcript references using Azure DevOps and a white paper that explains how to implement CI/CD with Microsoft 365 DSC and Azure DevOps. That’s where you can find more concrete examples and scripts.

From a governance perspective, this moves you from “we hope nothing gets misconfigured” to “we have a repeatable, auditable process.”

Once DSC is deployed, it doesn’t just walk away. It keeps watching.

Typical operational model with Microsoft 365 DSC looks like this:

1. DSC periodically checks the actual state of the tenant.
2. It compares that to the desired state in the configuration file.
3. If there’s a difference, it can:
- Log the discrepancy
- Trigger an alert through your monitoring system
- Optionally, automatically correct the configuration

Whether you enable auto-correction depends on your risk appetite and change control policies. Some organizations prefer to:

• Start with monitor-only mode to understand how often drift occurs and where.
• Then enable auto-correction for non-critical settings.
• Keep manual approval for sensitive changes.

Either way, DSC gives you visibility and choice. You’re no longer blind to quiet, accidental changes made in the admin UI.

Another important aspect: Microsoft 365 DSC is open-source and hosted on GitHub.

That means you can:

• Inspect the actual code used to manage your tenant.
• Raise issues or ask questions if you run into problems.
• Contribute new functionality or bug fixes via pull requests.

In practice, this community-driven model tends to accelerate support for:

• New Microsoft 365 features and services.
• Additional resource types.
• Improvements to export, documentation, and comparison logic.

It also gives you a more transparent view of what’s happening when you apply configurations—no hidden magic, just scripts and resources you can read.

First, you’ll want to install Microsoft 365 DSC from the PowerShell Gallery. From there, you can:

• Run a simple export against a test tenant.
• Inspect the generated DSC configuration file.
• Generate HTML or Excel documentation from that export.

At this stage, don’t worry about perfect CI/CD pipelines. Just focus on understanding:

• What kinds of resources can be exported.
• How configuration is represented in DSC format.
• How the documentation output looks and how it might help you.

Next, pick a scope that’s meaningful but manageable. For example:

• A security baseline for a particular service (like Exchange Online or SharePoint).
• A single tenant that you want to standardize.

Use export to get the current configuration, then refine it into your baseline configuration:

• Remove items you don’t want to manage via DSC yet.
• Adjust values to match your organization’s standards.
• Commit that configuration to source control.

Apply this baseline to a test tenant first. Make sure the changes that DSC applies are exactly what you expect. This is also a good moment to demonstrate the capabilities to stakeholders—especially the ability to:

• See changes clearly
• Apply them consistently
• Avoid manual misconfigurations

Once you’re comfortable with basic exports and deployments, you can:

• Enable periodic checks to detect drift.
• Decide whether to start with alert-only mode or allow auto-correction for certain settings.
• Begin integrating Microsoft 365 DSC into an Azure DevOps pipeline (or your preferred CI/CD platform).

The white paper mentioned in the transcript (accessible via `aka.ms/M365DSCWhitePaper`) provides:

• Updated scripts
• Detailed guidance
• Best practices for using Microsoft 365 DSC with Azure DevOps

Over time, you can expand the set of resources you manage via DSC and gradually move more of your Microsoft 365 configuration under automated control.