Hey GS! I’m going to put a caveat up front, I’m still working through some of the hairy bits of composites myself. I don’t have all the answers yet. However, I’ve found there are 3 major differences between using a composite and just re-using the same code in multiple configs.
- Reporting
This applies more to desktops than servers, but it might still be useful to some people. When a composite is compiled, the resourceID is updated to include the name of the composite. If you use the file resource (MyFile) inside an “xCriticalConfigs” resource, it would have a resourceid of [file]MyFile::xCriticalConfigs. If you were using a reporting solution, you could split out on the “::” and use the composite’s name as a category. This way, you can determine whether a noncompliant system is missing a “nice-to-have” setting, or if it’s missing a critical configuration, like your security agents or something similar.
- Testing
If you keep your composites small, they’re easier to run tests against. If you created a testing suite for each composite, it would help you catch issues before they even make it to your testing environment. Below is a mocked-up Pester test, one that ties into item 3.
Describe “Testing Resource” {
Load and run the DSC composite resource
It “Should deploy license file”{}
It “Should install agent” {}
It “Should disable download feature” {}
#etc
}
- Parameterization
You can add parameters to a composite, which allows you to control how something is done. For example, look at software management through Chocolatey. It requires that you deploy a license file, install the agent, configure several features, and then register/unregister nuget repositories to control what locations the agent can use to install software. In your desktop environment, you want to enable the self-service feature for non-admins and register the desktop software repository. For servers, you of course do not want to enable non-admins to install software. You could type out the separate DSC statements in every DSC script and edit them slightly depending on desktop/server, but that would be error prone and time consuming. Instead, a better option is to use a composite with a -Type parameter. I included something I mocked up to show what it would look like:
Configuration ChocoAgent {
Param
(
$Type
)
Import-DSCResource -ModuleName cChoco
Use file resource to install license file
Use cChocoInstaller to install agent
Disable download progress feature to fix overload issues in WinRM
switch ($Type)
{
“Desktop”
{
Register desktop repos
Disable non-admin access to public repositories
enable self-service
}
“Server”
{
Register server repos
Disable public repositories entirely
Apply FIPS mode
etc
}
}
}