This topic contains 8 replies, has 3 voices, and was last updated by
May 16, 2014 at 11:08 am #15301
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?
May 16, 2014 at 12:20 pm #15302
That's what DependsOn is for. It keeps the later items from processing until earlier ones do. There are examples in The DSC Book.
May 17, 2014 at 5:43 am #15305ParticipantPoints: 0Rank: Member
If your using Composite resources, can you use DependsOn in one Resource for a configuration item in another?
May 17, 2014 at 5:47 am #15306
So, config "A" is the top-level composite. It includes "B" and "C" configs.
Config "A" contains item 1, 2, and 3. Number 2 is actually config B, Number 3 is actually config C.
Item 1 can depend on item 2. But item 1 can't depend on an individual item within config B.
Does that make sense? You can't depend on something INSIDE a "child" config, but you can have one item depend on the entire "child" config.
May 18, 2014 at 3:43 am #15318ParticipantPoints: 0Rank: Member
Makes sense, thanks
May 19, 2014 at 5:40 am #15361
So here is what's not working...
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".
Could this "bug" be the cause of the problem I am having?
May 19, 2014 at 5:49 am #15362
Yup. I'm hoping we'll see a fix in v5.
May 19, 2014 at 6:38 am #15363
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.
If that's the case, any idea how to solve?
May 20, 2014 at 4:58 am #15412
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.
The topic ‘Configuration "chicken and egg" problem’ is closed to new replies.