Getting Started with Microsoft 365 DSC: Configuration as Code for Your Tenants

Before we zoom into Microsoft 365 DSC specifically, it helps to understand the underlying concept: Desired State Configuration (DSC).

PowerShell DSC has been part of PowerShell since version 4. It’s built around a declarative approach. That’s just a fancy way of saying:

> You declare what you want the configuration to be, not how to get there.

For example, in a traditional PowerShell script, you might write a series of commands:
- Check if a registry key exists
- If it doesn’t, create it
- Then set a value

With DSC, you instead say something like: “This registry key must exist, with this value.” Then DSC figures out the steps needed to make that true.

Key characteristics of PowerShell DSC:
- Declarative syntax: You specify the desired end state.
- Idempotent behavior: Applying the same configuration multiple times doesn’t cause problems; it just ensures the system matches the desired state.
- Continuous enforcement: DSC doesn’t just configure once and leave. It can periodically re-check and re-apply the configuration if things drift.

Now imagine applying that same model not to Windows servers or registry keys, but to Microsoft 365 tenants.

Microsoft 365 DSC takes the power of DSC and applies it to Microsoft 365 workloads. It’s:

• Open source and hosted on GitHub
• Led by Microsoft engineers, but actively maintained by the community
• Distributed via the PowerShell Gallery, so it’s easy to install and update

With Microsoft 365 DSC, you can:

• Represent your tenant configuration as code (configuration as code / infrastructure as code style)
• Automatically deploy those configurations to one or many tenants
• Monitor for configuration drift (when actual settings no longer match the desired ones)
• Auto-remediate configuration drift if you choose
• Export existing tenant configurations into DSC format
• Generate documentation (HTML, Excel, or JSON) from real tenant configurations
• Compare configurations between tenants or points in time
• Copy configurations from one tenant to another (for example, from production to test)

In my experience, this is game-changing once you manage more than a single simple tenant. Even for one complex tenant, the time savings and consistency benefits add up fast.

At the heart of Microsoft 365 DSC is the idea of configuration as code.

Instead of clicking around the Microsoft 365 admin center and guessing whether all settings are correctly aligned, you:

1. Describe your ideal tenant configuration in a DSC configuration file (PowerShell DSC syntax).
2. Check that file into source control (like Git or Azure DevOps Repos).
3. Apply it to your tenant using Microsoft 365 DSC.

This gives you:

• Version control: You can see who changed what, and when.
• Repeatability: You can deploy the same baseline to multiple tenants (test, staging, production, regional tenants, etc.).
• Auditability: Your configuration is explicit and reviewable as code.

Example benefits:
- Quickly align a new tenant with your organization’s security baseline
- Maintain consistent settings across dozens of customer tenants if you’re an MSP
- Reduce configuration mistakes caused by manual clicks in the portal

To be honest, once you get used to treating your tenant setup like code, going back to “click-only” admin feels surprisingly primitive.

Defining configuration as code is nice, but the real magic is what happens after deployment.

When you deploy a Microsoft 365 DSC configuration:

• DSC connects to your tenant
• It sets each defined parameter to the specified value
• It then continues to check periodically if the tenant still matches the desired state

By default, this drift check happens about every 15 minutes (you can adjust how it’s run in your environment).

If DSC detects that something has changed—for example:
- Someone increased a storage quota manually in the admin portal
- A security setting was disabled during troubleshooting and never turned back on

Then DSC can:
- Alert you about the configuration drift
- Optionally automatically fix the setting to match the desired state again

This gives you:

• Consistency over time, not just at the moment of deployment
• Protection against accidental changes in the portal
• A clearer line between "approved configuration" and "someone just tweaked something"

It’s a bit like cruise control for your Microsoft 365 configuration: you tell it the speed, and it keeps adjusting to match.

One question that often comes up is: “Do I have to write all the configuration from scratch?” Thankfully, no.

Microsoft 365 DSC includes an export capability that can:

• Connect to an existing tenant
• Read the current configuration for selected workloads and settings
• Generate a full DSC configuration file that represents that tenant’s state

Practically, this means you can:

• Use an existing well-configured tenant as your blueprint
• Export that configuration
• Tweak it as needed in code
• Then apply it to other tenants

There’s also a helper at export.microsoft365dsc.com where you can:

• Select which resources you want to export
• Choose your authentication method
• Generate the proper export command

This is super handy if you’re just starting and don’t want to memorize all the command parameters.

Let’s be honest: documentation is usually everyone’s least favorite part of the job, but it’s also one of the most important.

Because Microsoft 365 DSC can export a tenant into a DSC configuration, it can also take that exported configuration and turn it into human-readable documentation. With the appropriate cmdlets, you can generate:

• HTML reports – Nice for quick visual review or sharing with stakeholders
• Excel reports – Great for auditors, security teams, or compliance reviews
• JSON output – Useful for integrations or feeding into other tools

This means you can:

• Always have up-to-date documentation of your tenant configuration
• Re-generate documentation as often as you like (weekly, monthly, after major changes)
• Share consistent configuration snapshots with security, governance, or compliance teams

Instead of manually gathering screenshots and copying settings into Word, you just run a command and let the tool do the heavy lifting.

Another powerful capability is comparing configurations. You’re not limited to just exporting and deploying—you can also ask, “How different are these two configurations?”

With Microsoft 365 DSC, you can:

• Compare a tenant against a baseline blueprint (for example, your security baseline)
• Compare two tenants (such as test vs. production)
• Compare two points in time for the same tenant (e.g., month-to-month snapshots)

The tooling generates a delta report that highlights:

• Which settings don’t match
• Which values changed
• Where your baseline and actual tenant differ

Practical scenarios:

• Checking whether all subsidiaries or customer tenants still comply with your corporate or MSP baseline
• Confirming that a test tenant and production tenant are aligned (except for intentional differences)
• Investigating what changed after an incident by comparing recent and older exports

This is especially useful for security baselines. You can define the baseline once, then regularly compare all tenants against it and focus only on the discrepancies rather than manually reviewing everything.

Once you can export and apply configurations, you can basically clone configurations across tenants.

Typical workflow:

1. Export configuration from Tenant A (for example, your production tenant).
2. Adjust sensitive or tenant-specific values if needed (domain names, URLs, etc.).
3. Apply that configuration to Tenant B (for example, a test tenant, or a newly provisioned environment).

Use cases:

• Testing changes: Copy production configuration to a test tenant, then experiment safely.
• New tenant provisioning: Quickly onboard new business units or customers with a known-good configuration.
• Lab and training environments: Keep lab tenants close to real-world setups.

This ability to move from “this tenant looks good” to “this is our code-based standard that we can reuse” is a huge maturity step for many organizations.

When you store your Microsoft 365 DSC configurations in a Git repository, you can:

• Track changes over time
• Review changes via pull requests
• Enforce approvals before configuration updates go live
• Roll back to previous versions if needed

This is standard DevOps practice for application code and infrastructure-as-code templates, and there’s no real reason Microsoft 365 configuration should be treated differently.

In my experience, even simple practices like code review for configuration changes can drastically reduce accidental misconfigurations that impact security or compliance.

With CI/CD, you can automate:

• Validation of configuration (syntax checks, maybe custom policy checks)
• Test deployments to non-production tenants
• Production deployments once checks pass

For example, a typical flow using Azure DevOps and Microsoft 365 DSC might look like:

1. Admin proposes a configuration change by editing the DSC file and creating a pull request.
2. Automated checks run (linting, tests, maybe even a dry-run or drift analysis).
3. A lead signs off on the change.
4. A pipeline applies the configuration first to a test tenant.
5. If all good, another pipeline (or stage) applies it to production.

There’s even a dedicated whitepaper (mentioned in the transcript) that explains how to set up CI/CD with Microsoft 365 DSC and Azure DevOps, including updated scripts and guidance. If you’re serious about bringing DevOps practices into your Microsoft 365 management, that’s worth a deep dive.

One nice aspect that’s easy to overlook: Microsoft 365 DSC is free to use and open source.

You can:

• Install it from the PowerShell Gallery
• Explore the code on GitHub
• Raise issues, ask questions, or even contribute improvements

Because it’s community-driven (with Microsoft engineers involved), it evolves pretty quickly:

• New resources and settings get added over time
• Bugs are fixed openly
• You can influence the roadmap through feedback and contributions

If you discover a missing setting you really need, you’re not stuck waiting endlessly—you can either request it or, if you’re comfortable with PowerShell, contribute it yourself and submit a pull request.

Imagine you have a tenant where the storage limit for a particular Microsoft 365 workload is currently set to 512 GB. You’ve decided that the new standard should be 1 TB, and you want this change to be enforced consistently.

The traditional way:
- Log into the admin portal
- Navigate through several pages
- Change the setting from 512 GB to 1 TB
- Hope no one changes it back later

The DSC way:

1. In your DSC configuration file, you set the value for that storage limit to 1 TB.
2. You apply the configuration to the tenant.
3. DSC connects, notices the current setting is 512 GB, and updates it to 1 TB to match the desired state.
4. When you refresh the admin portal, you see the value has changed to 1 TB—no portal clicks required.
5. Going forward, if someone changes it back manually, DSC can detect the drift and either alert you or reset it back to 1 TB.

It’s a small example, but it captures the core idea: you change the code, not the portal, and the environment follows.

Now, scale that idea:

• Dozens of settings instead of one
• Multiple workloads (Exchange Online, SharePoint Online, Teams, security, compliance, etc.)
• Multiple tenants instead of just one

With Microsoft 365 DSC:

• Your configuration file becomes the single source of truth for how tenants should be configured.
• Applying changes becomes a matter of updating code and running (or triggering) a deployment.
• Repeated, manual portal work gets replaced by automated, predictable behavior.

This doesn’t eliminate the need to understand the admin portal or the services, of course. But it does help you enforce your decisions consistently and safely, which is where a lot of organizations struggle.

If you manage Microsoft 365 for a single organization (maybe with multiple tenants, maybe just one but fairly complex), Microsoft 365 DSC helps you:

• Standardize security and compliance settings across environments
• Reduce human error from manual changes in the portal
• Simplify audits with automatic documentation and configuration exports
• Track changes over time via Git and configuration comparisons

You gain a more controlled, predictable, and auditable Microsoft 365 environment.

If you run Microsoft 365 for many customers, the value can be even greater:

• Define a baseline configuration for all customers.
• Apply it to each tenant and enforce it continuously.
• Run delta reports to spot customers who drift away from the baseline.
• Use exports and documentation generation to provide tangible reports of configuration and security posture.

This can also become part of your service offering—configuration as code and drift monitoring are strong value-adds when customers care about security and consistency.

From a security or compliance perspective, Microsoft 365 DSC offers:

• A way to codify security baselines (rather than keep them in PDFs or spreadsheets only)
• Ongoing verification that tenants still comply with those baselines
• Easier investigation of changes via point-in-time exports and comparisons

It’s not a silver bullet, but it can close a major gap between “we have a policy” and “we actually enforce and monitor that policy in real environments.”