284449 (1) [Avatar] Offline
#1
I've been trying to test and evaluate different methods of applying multiple configurations to a node, then audit them long term. I'm aware of different options including partial configurations, dot-sourcing, and composite configurations. I created 2 unique dsc configurations for a node, one installed sql, one installed the docker service, and applied them successfully. Perhaps not real world realistic, but just a test. I then wanted to audit the node for both groups of changes. I found that test-dscconfiguration only reads one .mof, the current.mof on the node. I also know that partial configuration .mofs are created on the node, and then combined there, vs a script containing dot-sourced scripts is combined on the sending server, as other types of dsc scripts are. I wanted to both perform multiple, separate configurations, without having to combine everything into one large, monolithic configuration script, and also get be able to run one test-dscconfiguration command and return one audit result, without having to combine multiple test-dscconfiguration commands using -referenceconfiguration. I was unable to get partial-configurations to work, so I turned to dot-sourcing the separate dsc scripts within one, and removing the configuration and node separations in the lower level scripts. I found that the separate scripts worked fine standalone, but the sql script throws an error when dot-sourced. I see you did not discuss dot-sourcing in your book. Why is that? Don't you regard dot-sourcing as a viable option? The only discussion of DSC dot-sourcing I've found so far is in Don Jones' book, and it's extremely bare-bones.
richard.siddaway (71) [Avatar] Offline
#2
DSC is working as it should. The current MOF is the one that will be applied/tested/re-applied or anything else when you invoke one of the DSC cmdlets. As we say in the book use nested/composite configurations