How to effortlessly convert MOF files to Microsoft's DSC JSON format

Still shipping MOF files around like it’s 2016? You’re not alone.

PowerShell's DSC configuration documents are still widely used today. You write up your Configuration block in your .ps file, define your resources, and feel pretty good about your declarative piece. But then you hit that familiar miserable step.

Compile it to .mof.

That compilation step has always felt slightly awkward to me. You wouldn't typically hand-edit .mof file. Let alone that you're going to stuff it into version control and think, this is a pretty clean file.

Still, it's a necessary artifact that gets generated and consumed. Many environments still rely heavily on those MOF files. They're inevitably going to be pushed to nodes. But what if you want that format to play with Microsoft's DSC engine?

In this blog post, I will show you a simple command I developed to convert your existing .mof files to the new format, which is JSON. At the end of the blog post, you'll also learn about Microsoft's DSC extensibility model and directly execute it against the engine.

The Problem: MOF isn't dead

Before we take a look at the command, let's look at the current problem. In classic PowerShell DSC, everything today still becomes a .mof file. You still author your configuration documents in PowerShell, and that gets compiled to this Managed Object Format (MOF). Those mof files are well understood by the Local Configuration Manager (LCM)

Now, to be fair, I mentioned "miserable" in the intro, but MOF isn't that "bad."

It still does what it does today, but it was just designed in a different time.

They weren't very developer-friendly artifacts. At this time, they will be pretty noisy in pull requests to be reviewed (nor should they be). Let alone that you're going to manually modify them.

Moving on to Microsoft DSC. Microsoft DSC's engine expects something totally different. Under the cover, it works with the JSON format. JSON fits in many ecosystems these days, and making Git diffs compared to MOF will be a bit better, let's say.

But it isn't completely "dead" yet. Microsoft DSC doesn't have an LCM as of today. If you're relying on the LCM functionality today, you would still need MOF. That's for now. However, it doesn't mean your configurations can't evolve towards the newer JSON-based model.

Convert MOF to JSON

So instead of rewriting the compiled configurations from scratch, I took a different path.

What if you could just take the raw .mof file and transform it into JSON, including the nitty-gritty things Microsoft DSC expects?

If you look at the core of an MOF file, it contains all the elements you're going to need for transformation:

instance of WinGetPackage as $WinGetPackage1ref
{
ModuleVersion = "1.12.440";
 Ensure = "Present";
 Source = "winget";
 ModuleName = "Microsoft.WinGet.DSC";
 ResourceID = "[WinGetPackage]GitHubDesktop";
 SourceInfo = "::4::5::WinGetPackage";
 Id = "Microsoft.PowerShell";

 ConfigurationName = "Package";

};
instance of OMI_ConfigurationDocument


                    {
 Version="2.0.0";


                        MinimumCompatibleVersion = "1.0.0";


                        CompatibleVersionAdditionalProperties= {"Omi_BaseResource:ConfigurationName"};


                        Author="Administrator";


                        GenerationDate="02/19/2026 04:05:09";


                        GenerationHost="DEVBOX";


                        Name="Package";


                    };

This raw example shows the module name (Microsoft.WinGet.DSC), the resource name (GitHubDestkop), and the relevant properties. There's some additional data that isn't going to be relevant for Microsoft DSC (OMI_ConfigurationDocument).

So my idea became simple.

1. Parse the MOF
2. Get the resource definitions
3. Transform it into Microsoft's DSC format

That's where Convert-MofToDsc command was born. It leverages an open-source library (Kingsland.MofParser) that handles the heavy-lifting. The only thing I had to do was get it into the right format.

As you can see, it clearly maps all the resource definitions (and properties) directly to Microsoft's DSC format. It even includes the stable $schema element in there. You can pick this up into a variable or output it to a file and give it to dsc config <operation> command.

When should you use this?

Before you think, let's use this tool "into production." But hold it right there. This tool isn't a replacement for MOF. It acts more as a bridge between old and new.

You would use this command when you're probably operating in an environment where classic PowerShell DSC exists, but you're starting to experiment with Microsoft DSC. Here are also some other realistic scenarios:

You have an existing MOF repository

There are many out there that have huge chunks of MOF files still in their estate. You want to see if a migration is possible and what that would look like if an LCM becomes available (in Microsoft DSC).

Rewriting all those MOF files is going to be a burden. That's where you can use this command for, so it becomes:

• You still compile your MOF files as usual
• You gradually use Convert-MofToDsc to see the new document format
• You test it against dsc config

You're modernizing DSC

If you still depend on the fully fletched LCM enforcement, MOF stays in the picture. But if you don't rely on it and want to create your own orchestrator, this command lets you run both worlds side-by-side.

You simply want the output

Maybe you're just curious how the new format looks. Without fiddling too much, you can just run this command and instantly start to understand what the output would look like.

Bonus tip: extensibility model

Before closing the blog post, here's one more interesting part about Microsoft DSC that classic PowerShell DSC doesn't have: the extensibility model.

This extensibility model allows you to run a .mof file against dsc config <operation> --file <.mof>. See it as a sort of plugging for custom handlers. You can see this by introducing an extension file (*.dsc.extension.json) with a small wrapper script (convert-mof.ps1):

{
  "$schema": "https://aka.ms/dsc/schemas/v3/bundled/extension/manifest.json",
  "type": "DSC.Transitional/MofToDsc",
  "version": "0.1.0",
  "description": "Converts MOF configuration files to valid DSC configuration documents.",
  "import": {
    "fileExtensions": ["mof"],
    "executable": "pwsh",
    "args": [
      "-NoLogo",
      "-NonInteractive",
      "-NoProfile",
      "-Command",
      "./convert-mof.ps1",
      {
        "fileArg": "-Path"
      }
    ]
  }
}

Inside the wrapper script, you can use the same command to transform the output:

[CmdletBinding()]
param(
    [Parameter(Mandatory)]
    [string]$Path
)

$ErrorActionPreference = 'Stop'

Convert-MofToDsc -Path $Path

If you add this to your PATH environment variable, you can list it out using dsc extension list:

When I'm running dsc config get --file localhost.mof, it perfectly accepts the file and runs the underlying resource:

Wrap up

The module is available in the PowerShell Gallery and can be installed using:

Install-PSResource -Name DscSchemaBuilder

Once you install it, you can start converting existing .mof files and experimenting with the extensibility model. There's no additional setup needed.

This module doesn't replace .mof files, it just gives you other options. If you're still relying on LCM, nothing changes. You can keep going. But if you're exploring the new Microsoft DSC executable, this will give you that easy bridge.

If you want to explore deeper into Microsoft DSC, I'm covering everything in my book "The DSC V3 Handbook."