partial-configurations.md

Partial Configurations

Honestly, we've already covered almost everything you need to know about partial configurations. In the chapter on Configuring the LCM, you saw how to tell the LCM to pull partials from a pull server, or to accept them as a push, or a mix of the two. You saw how to set up dependencies to control the order of partial configuration application. There's not a whole lot more to cover, really. The actual creation of a partial MOF is the same as creating any ordinary configuration; it's only a "partial" because a node is being told to use more than one of them. So, in this chapter, we'll kind of summarize the capabilities and cover the last couple of details.

The code samples in this chapter aren't meant to be real-world, runnable code. Partials can get a little complex, and so we've taken an oversimplified approach here so that we can get the point across.

Summarizing Partial Configuration Pros and Cons

We've covered this before, but to review briefly:

• Partials allow you to modularize chunks of your configuration, making it easier to have multiple contributors.
• Partials get combined and evaluated by the LCM, which means it's very difficult to detect potential conflicts ahead of time. This can make troubleshooting harder.
• Partials only work with v5 nodes, and if a Pull server is involved, it must also be v5.

We're presently in a kind of avoid-and-wait-and-see mode on partials. We'd prefer to have a configuration composed server-side and sent to the node, rather than the node having all the business logic needed to pull multiple items and combine them. Fellow MVP Steven Murawski wrote DSC Partial Configurations are the Devil's Workshop, which you might also find helpful.

Authoring a Partial Configuration MOF

Authoring a partial MOF is no big deal - it's exactly the same as authoring a "full" MOF. Period, full stop. Any legal MOF - including one generated by a configuration script - can be used as a partial. Nothing more to see here, move on.

Configuring the LCM for Partial Configurations

We covered this in "Configuring the LCM," and aside from the Authoritative bit, below, there's nothing more to say here.

Partial Configuration Dependencies

As you saw in the chapter on Configuring the LCM, one partial can depend upon another. However, that's an all-or-nothing affair. One partial cannot depend on just some things within another partial.

Partial Configuration Authoritative Resources

When you configure the LCM to get a partial, you can tell it a list of resources that only that particular MOF may contain. So, you might say, "grab this partial, and it's the only one that can contain WindowsFeature settings. If any other partial tries to use the WindowsFeature resource, explode." It looks like this:

...
PartialConfiguration Bob {
	RefreshMode = "Pull"
	ConfigurationSource  = @("[ConfigurationRepositoryWeb]MyPullServer")
	Description = "Something"
	ExclusiveResources = @("Script","WindowsFeature") 
}

This would allow only the Bob partial configuration to use the Script or WindowsFeature resources.

It's important not to treat this as a security thing. It's more of a "help our team not do the wrong thing, but don't stop us." Keep in mind that this "rejecting" of "unallowed" resources happens at the LCM, and the LCM's configuration can in fact be changed. Also keep in mind that, when you've got multiple people working on partial configurations and not talking to each other, you're basically just asking for trouble. Some kind of hard-to-troubleshoot conflict is eventually going to enter the situation. Partials shouldn't be used to rectify DSC's lack of native tooling, and this whole "authoritative resources" thing is essentially trying to do just that.

Also note that class-based resources can't be used as ExclusiveResources before WMF5.1.

Mix 'n' Match

It's possible to tell an LCM that some partials will be pulled, while others will be pushed. If you're going this route, you might do so because some configuration items (those being pushed) will be changed only rarely, while others (being pulled) may be updated more often. There's a good look at how to configure the LCM this way on PowerShellMagazine.com.

File Naming Details

In WMF 5.0, let's say you configured the LCM as follows:

PartialConfiguration Bob {
	RefreshMode = "Pull"
	ConfigurationSource  = @("[ConfigurationRepositoryWeb]MyPullServer")
	Description = "Something"
	ExclusiveResources = @("Script","WindowsFeature") 
}

In this case, the LCM will ask the pull server for a configuration named "Bob." The pull server - again, in WMF 5.0 - would look on disk for "Bob.mof" and "Bob.checksum.mof." The problem is that the pull server in Azure Automation stored files differently. It would use ConfigurationName.NodeName.mof instead. Chucking that nodename in there meant that the LCM couldn't request partial configurations from Azure Automation! So in WMF 5.1, the protocol was changed slightly, and either file naming convention is acceptable. Microsoft provides this example of an LCM configuration which uses both a local pull server and Azure Automation:

[DscLocalConfigurationManager()]
   Configuration RegistrationMetaConfig
   {
        Settings
        {
            RefreshFrequencyMins = 30
            RefreshMode = "PULL"            
        }

        ConfigurationRepositoryWeb web
        {
            ServerURL =  $endPoint
            RegistrationKey = $registrationKey
            ConfigurationNames = $configurationName
        }

        # Partial configuration managed by Azure Automation service.
        PartialConfiguration PartialConfigurationManagedByAzureAutomation
        {
            ConfigurationSource = "[ConfigurationRepositoryWeb]Web"   
        }

        # This partial configuration is managed locally.
        PartialConfiguration OnPremisesConfig
        {
            RefreshMode = "PUSH"
            ExclusiveResources = @("Script")
        }

   }