Configuration data is handled by a module called Datum. In short, Datum provides easy access to a hierarchical data structure. Each layer can inherit from a higher layer, or overwrite settings from a higher layer. At the lowest layer, our DSC nodes, very few adjustments should be necessary.

Combining all layers through different merging rules will result in a Datum structure. You can navigate this structure like any other hash table, but it really shines in configurations, where you can simply look up values based on, for example, the environment and role your node is in. See the following code:

# ConfigurationData
# Data is used automatically during build
$configData = New-DatumStructure -DefinitionFile .DSC_ConfigDataDatum.yml

# While you can lookup everything with hard-coded values like the environment...
$configData.AllNodes.Dev.DSCFile01.LCM_config.Settings.ConfigurationMode

# Datum will automatically do the lookup for you!
# interactively (without the automatic node reference)
Lookup -PropertyPath LCM_Config/Settings/ConfigurationMode -Node DSCFile01 -DatumTree $configData

# fully automatic inside your DSC config!
configuration SampleDoNotCompile
{
    # Node reference is retrieved automatically through $Node
    # Data is retrieved depending on the environment and role of the node
    $domainName = Lookup Domain/DomainName
}

The structure you will want to choose must reflect your own environment, of course, but the following hierarchy has proved useful so far:

• Environment (not configured specifically in this scenario)
• Site (not in this scenario)
• Role
• Node

The environment should contain the least specific settings that are valid for the entire environment, that is, dev or prod. A site can be part of an environment. A site would be the location of the data centers in your environment, and would contain settings such as networking configurations that are site-specific.

The role describes the main functionality of a group of nodes. One such role might, for example, be file server or domain controller. While a file server will need a couple of shares and features, and might need to be part of a cluster, a domain controller needs to execute a DC promo, create a domain or forest, and create an Organizational Unit (OU), groups, and users.

The node itself should only contain very specialized settings, such as the node name, the last IP octet in case static addresses are used, and so on:

Configurations:
  - RegistryKeys
  - SecurityBase
  - WindowsFeatures

SecurityBase:
  SecurityLevel: 1

WindowsFeatures:
  Name:
    - -XPS-Viewer

In this project, we use YAML as the language to define our configuration data. You can also use JSON or PowerShell manifests (that is, hash tables) to define your data. YAML has the benefit of being easily readable by human beings, through indentation alone.

At every layer, you can choose which configurations (building blocks) you want to subscribe to. If a configuration requires no parameters, this is enough to add this configuration to your resultant MOF. Optionally, parameters can be passed as well. This can also be done at a lower layer.

For example, the File Server role might subscribe to a files and folders resource. Each file server node can then configure which shares it needs to create. The idea of overrides at each layer is very important and very useful.