Microsoft365DSC or Tenant Configuration Management API ?

[Erylis21]

Hello,

After reading the UTCM/TCM transition article, I would like to clarify the long-term positioning of Microsoft365DSC versus the Tenant Configuration Management APIs.

From the documentation, I understand that TCM is the new Microsoft-supported Graph-based approach for snapshot/export and drift monitoring, while Microsoft365DSC still exists as the PowerShell DSC-based solution with broader configuration management capabilities.

Could you clarify the recommended direction for new adopters?

More specifically:

• Is Microsoft365DSC expected to remain a standalone solution, or is there a roadmap to progressively align it with / build on top of TCM APIs?
• Should new projects still start with Microsoft365DSC today for full configuration management scenarios?
• For customers already invested in Microsoft365DSC, should TCM be seen as a complementary option for snapshot/monitoring, or as the long-term replacement once feature parity is reached?

Thank you.

[FabienTschanz]

@Erylis21 Microsoft365DSC will continue to be developed by the community and stay under the Microsoft organization, at least for the foreseeable future. Of course I don't know what's going to happen in 5 years, nobody knows. But the intentions in the project are clear: Leverage what we've built and remain on top of handling Microsoft 365 configuration using Desired State Configuration.

For now, there is no roadmap to start "migrating" to cover the TCM APIs. The project will stay focused on building an independent, free version that can be used by anybody, with no dependencies to a Microsoft product. However, the project will start to adopt technologies from TCM, as long as they are available open-source (for example the entire TCM schema is available here.

Right now, Microsoft365DSC has a much bigger coverage than TCM, especially when it comes to Intune. M365DSC can also target delegated authentication scenarios, which TCM cannot do, under no circumstances. Using the schema, we can make sure that M365DSC supports the same (or even more) properties and resources than TCM. This means that we will stay up to date with our configuration.

TCM is still in public preview. If you need something right now, then you should take a closer look at M365DSC. Once TCM is generally available and you are confident that it supports your scenarios, then go for it. There is even a configuration converter from M365DSC to TCM (see https://github.com/Microsoft/M365DSC-to-TCM/), so switching from M365DSC to TCM would be a piece of cake.

For customers already adopting M365DSC, really it's up to them. There will most likely be some restrictions on resources or licenses included. M365DSC doesn't require anything to do that, but if your company is okay with the requirements for TCM once GA and everything is known, then you must decide for yourself if it's worth to invest in switching the technology. Many companies created workflows around M365DSC and they would need to be revised once they are switching to TCM. But of course, the entire infrastructure for TCM is much "simpler and cleaner" because it's built into the Graph API. Whether it's a long-term replacement or not, it all depends on the use cases. Having custom configuration documents with built-in logic, delegated access requirements or other things, it's always dependent on the custom and specific requirements from each company and their policies.

One funny note: TCM was adapted from M365DSC probably back in October 2024. At least the public schema documentation indicates it's from back then. Currently during public preview, there are several issues with the schema like missing or already obsoleted properties, unsupported resources and more. But I'm sure that Microsoft will fix them sooner or later.

I'd encourage you to try both of them out, taking a look at the different capabilities, what's supported and what is not, and then make a cost/effort analysis whether one or the other is better for the purpose you intend to use it for.