The DSC configuration file is compiled to an MOF format by invoking the declared DSC configuration block inside the DSC configuration file. When this is done, it creates a folder and one or more MOF files inside it. Each MOF file is for a single target node, containing all the configuration information needed to ensure the desired state on the target machine.
It's important to understand before we get too far into explaining MOF compilation that defining a DSC configuration script does not mean that you have to compile it to an MOF right away. The two actions are separate because the MOF file is either copied to the target node or the DSC pull server, and the DSC configuration file is kept in the source control or another safe place.
Sometimes, compilation is not needed at all, as in the case of the Azure DSC tooling. All you need to do with Azure and DSC is copy the DSC configuration script, and Azure will handle the rest.
If at this point you are looking for the example code of what this looks like, the example workflow section has what you are looking for. We will continue explaining MOF compilation here, but if you want to jump ahead and take a look at the example and come back here when you are done, that's fine.
You can have only one MOF file applied to any target node at any given time. Why one MOF file per target node? That is a good question. Due to the architecture of DSC, an MOF file is the one source of truth for that server. It holds everything that can describe that server so that nothing is missed.
You might be thinking that if there can be only one MOF file per target node, does that mean you can have only one DSC configuration file? There are two answers to this question. You can either have one DSC configuration block applied to a target node, or you can use DSC partial configurations. With the one DSC configuration block, you can use the power of the PowerShell language (pun intended) to filter which target nodes to apply settings to or do complicated logic operations to decide whether software is installed or not.
With DSC partial configurations, you can have separate DSC configuration blocks to delineate different parts of your installation or environment. This enables multiple teams to collaborate and participate in defining configurations for the environment instead of forcing all teams to use one DSC configuration script to track. For example, you can have a DSC partial configuration for an SQL server that is handled by the SQL team and another DSC partial configuration for the base operating system configuration that is handled by the operations team. Both partial configurations are used to produce one MOF file for a target node while allowing either DSC partial configuration to be worked on separately.
In some cases, it's easier to have a single DSC configuration script that has the logic to determine what a target node needs installed or configured rather than a set of DSC partial configuration files that have to be tracked together by different people. Whichever one you choose is largely determined by your environment. We will cover this subject in more detail in Chapter 3, DSC Configuration Files.