I built a custom DCS resource for use in configuring IIS 7.5 using two cmdlets in the WebAdministration module - Get-WebConfigurationProperty and Set-WebConfigurationProperty. Have it working just fine.
But as part of my “one and only one” configuration definition for a server, I also intend to use the built-in “WindowsFeature” resource to install IIS as part of the “Web Server” role. The problem is that until this “WindowsFeature” is configured, the WebAdministration module doesn’t exist, so trying to apply the “one and only one configuration” that configures the “Web Server” role “WindowsFeature”, and then configures aspects of this installed feature fails.
Any idea on how to accomplish what I am trying to do?
I have a “top” configuration that contains three composite configurations: A, B, C. Both composite configurations B & C depend on composite configuration A. If I add a “DependsOn” line to both B & C that references A, I get an error that states:
"A parameter cannot be found that matches parameter name 'DependsOn'"
I see that Steve Murawski entered a “bug” on Microsoft Connect back on 1/31/2014 titled “DSC - Cannot Set DependsOn to a Nested Configuration”.
So to try and work around this problem I “flattened” out the composite resources placing their configuration definition in the “top” configuration file. The problem didn’t go away. I believe the cause of the problem is that I have written a “Custom DSC Resource” that uses the “WebAdministration” module, and because the IIS feature that installs this module doesn’t exist, the custom DSC Resource cannot be loaded. Here is the error:
Importing module Acme_WebConfigurationProperty failed with error - The specified module ‘WebAdministration’ was not loaded because no valid module file was found in any module directory.
I even added a ‘DependsOn=“[WindowsFeature]WebMetabase”’ line to configuration definitions that use “Acme_WebConfiguration” hoping that the IIS feature would be installed before my custom DSC resource was processed. But PowerShell seems to be loading the custom DSC resource, which then imports WebAdministration module, and fails.
The approach I am planning on taking for now is to create two separate “top level” configuration scripts. The first script is applied to configure server roles and features, which are defined as a composite DSC resource. The second script includes the same composite DSC resource to configure server roles and features, as well as additional composite DSC resources to configure additional aspects. The first script MUST be applied to a server first, and then the second script is applied.
I don’t feel this is a bad approach, and likely a common scenario where one group in an organization provisions a “base” server with a “base” server configuration .mof, and then another group takes the “base” server and builds on it by adding additional configuration, and therefore need to include the “base” configuration as well. Using “shared” composite DSC resources makes this possible.