Why We Built Our Own Microsoft 365 Management Platform Instead of Using DSC

When we started building Optimize365, the obvious question came up: should we use Microsoft365DSC? It's open source, maintained by Microsoft engineers, and already handles hundreds of Microsoft 365 resources. Why reinvent the wheel?

After months of testing and evaluation, we made the difficult decision to build our own solution from the ground up. Here's why.

Let's Be Fair: Microsoft365DSC Does Some Things Really Well

Before we get into the problems, it's worth acknowledging what Microsoft365DSC does well. The team behind it has put in serious work, and for certain use cases, it's genuinely useful.

The export functionality is legitimately helpful. If you need to take a snapshot of your tenant configuration or document what's currently set up, Microsoft365DSC can do that pretty well. For MSPs managing multiple clients, being able to quickly export and compare configurations across tenants has real value.

The configuration as code approach is also fundamentally sound. The idea of defining your tenant state in a declarative way and letting automation handle the details makes sense. And for basic drift detection, where you just want to know if something changed, it works reasonably well.

So why not use it? Because when you dig deeper, the problems start stacking up.

The Coverage Problem: It's Always Playing Catchup

Microsoft 365 is a moving target. New features ship constantly, settings get added, APIs change. And Microsoft365DSC is always behind.

We spent time going through the GitHub issues, and it's the same pattern over and over. Someone opens an issue saying "Hey, can you add support for [new Teams feature]?" or "These Intune properties are missing" or "The mobile app management resources don't exist yet." Sometimes these requests sit open for months. Sometimes they get added, but by then there are five new features that aren't covered.

One particularly telling issue we found: someone tried to export all their Intune configurations and noticed that none of their 110 custom Windows policies showed up. The export ran successfully, but the output file was basically empty. That's not a tool you can rely on for production security management.

For Optimize365, this is a non starter. Our customers need complete visibility into their security posture. Missing 20% or 30% of the settings isn't acceptable when you're trying to maintain compliance or catch security drifts.

The Granularity Problem: Building Blocks That Don't Make Sense

This is the big one. This is really why we couldn't use Microsoft365DSC even if the coverage was perfect.

Microsoft365DSC resources are designed at the wrong level of abstraction. They group settings together in ways that seem logical from a DSC perspective but don't match how you actually need to manage Microsoft 365 in production.

Here's what happens in practice: you want to modify one specific security setting. But that setting is part of a larger resource that includes ten other settings. So you have two choices. Either you manage all ten settings together as a unit, or you don't manage any of them.

Let's say you want to enforce MFA for admin accounts but leave other authentication policies alone. The resource might bundle MFA settings with session timeout settings, password policies, and guest access controls. Now you're forced to either take ownership of all those settings or none of them. There's no middle ground.

This creates a bizarre situation where managing one thing means you might accidentally overwrite something else. And if two different teams or tools are trying to manage different aspects of the same resource, you get into drift wars where changes keep reverting because the resources overlap.

When we were designing Optimize365, we knew this couldn't work. MSPs need surgical precision. They need to fix a specific security gap without touching anything else. They need to apply a baseline to some settings while leaving others under manual control. The coarse granularity of Microsoft365DSC makes that impossible.

The Platform Problem: Building on Shifting Sand

Even if we could live with the coverage and granularity issues, there's a bigger problem lurking underneath: PowerShell DSC itself is being deprecated.

Microsoft announced that PowerShell DSC will be discontinued sometime in 2027. They've released DSCv3 as the replacement, which is a complete architectural redesign. Different platform, different approach, different everything.

We found a GitHub issue from October 2024 where someone asked the obvious question: what happens to Microsoft365DSC when the underlying platform goes away? The answer is... unclear. The maintainers are looking at either migrating to DSCv3 or moving to something called CloudConfigurationManager. Either way, it's a massive undertaking that would require rewriting most of the codebase.

That's a lot of uncertainty to build a business on. Imagine investing months into integrating Microsoft365DSC, training your team, building automation around it, and then having to rip it all out in two years because the platform changed.

For a tool like Optimize365 that MSPs depend on for daily operations, that kind of instability isn't acceptable. We need a foundation that's going to be here in five years, not a question mark.

The Operational Reality: It's Harder Than It Looks

Beyond the architectural issues, there are practical problems that make Microsoft365DSC tough to operate at scale.

Authentication is a constant headache. The GitHub issues are full of people struggling to get service principal authentication working correctly. Permissions are complex and often require Global Admin rights, which creates security concerns. And because it's built on multiple underlying PowerShell modules (Exchange, Teams, SharePoint, etc.), you're dealing with dependency management across a dozen different components.

The project also has a policy of introducing breaking changes twice a year. That means twice a year, you might need to update your configurations, change how you call certain resources, or rewrite scripts. For internal IT teams with one tenant, that's manageable. For MSPs managing hundreds of clients, that's a maintenance nightmare.

And then there are the bugs. Resources that report drift when nothing changed. Exports that randomly fail. Settings that won't apply even though the syntax is correct. Most of these eventually get fixed, but when you're running a production service, "eventually" isn't good enough.

What We Built Instead

So we built our own platform. It wasn't a casual decision. Building from scratch meant months of development, reverse engineering Microsoft APIs, testing edge cases, and creating our own resource definitions. But it gave us something Microsoft365DSC couldn't provide: complete control.

Fine Grained Control

Every setting in Optimize365 can be managed independently. Want to fix one conditional access policy without touching others? Done. Need to enable a specific security feature while leaving everything else as is? No problem. This granularity is what MSPs actually need in the field.

Complete Coverage

We don't wait for someone else to add support for new features. When Microsoft releases something, we integrate it. Our platform continuously scans for misconfigurations, vulnerabilities, and security drifts across all client tenants. Not most settings. All of them.

One Click Remediation

This was a major design goal. Identify a security gap and fix it with one click. No scripting required, no configuration files to edit, no deployments to manage. Just click and it's done. This is only possible because we control the entire stack and can optimize for this workflow.

Security Baseline Mapping

Optimize365 automatically maps client environments to compliance frameworks like CIS, NIST, and Microsoft's own security baselines. This gives MSPs actionable remediation steps, not just a dump of configuration data. You can see exactly what needs to be fixed and why.

MSP Focused Design

Everything is built for multi tenant management from day one. Single dashboard for all clients. Automated tenant onboarding. PSA integration. Project scoping tools that generate SOWs with time estimates. User impact analysis before you make changes. These features exist because we built specifically for how MSPs work, not as an afterthought.

The Tradeoff Was Worth It

Building our own platform was expensive. It would have been much faster to wrap Microsoft365DSC and ship something. But we would have inherited all its limitations, and our customers would have paid the price.

Microsoft365DSC is a solid tool for what it is. If you need to export tenant configurations, document your setup, or do basic drift detection, it's worth looking at. The open source community behind it is dedicated, and they're doing good work within the constraints they have.

But for building a professional security and posture management platform that MSPs stake their reputation on, it wasn't the right foundation. The incomplete coverage, coarse granularity, and platform uncertainty created too many compromises.

So we built something better. Something designed from the ground up for how MSPs actually work. Something that gives you complete control over every setting without the abstraction layers getting in the way. Something stable that won't require a rewrite when Microsoft deprecates the underlying platform.

That's Optimize365. If you want to see what fine grained Microsoft 365 management actually looks like, book a demo and we'll show you.