Configuration "chicken and egg" problem

This topic contains 8 replies, has 3 voices, and was last updated by Profile photo of Jeff Pflum Jeff Pflum 2 years, 11 months ago.

  • Author
    Posts
  • #15301
    Profile photo of Jeff Pflum
    Jeff Pflum
    Participant

    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?

    Thanks...

  • #15302
    Profile photo of Don Jones
    Don Jones
    Keymaster

    That's what DependsOn is for. It keeps the later items from processing until earlier ones do. There are examples in The DSC Book.

    • #15305
      Profile photo of Matthew Hatch
      Matthew Hatch
      Participant

      If your using Composite resources, can you use DependsOn in one Resource for a configuration item in another?

  • #15306
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #15318
    Profile photo of Matthew Hatch
    Matthew Hatch
    Participant

    Makes sense, thanks

  • #15361
    Profile photo of Jeff Pflum
    Jeff Pflum
    Participant

    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".

    http://connect.microsoft.com/PowerShell/feedback/details/812943/dsc-cannot-set-dependson-to-a-nested-configuration

    Could this "bug" be the cause of the problem I am having?

  • #15362
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Yup. I'm hoping we'll see a fix in v5.

  • #15363
    Profile photo of Jeff Pflum
    Jeff Pflum
    Participant

    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?

  • #15412
    Profile photo of Jeff Pflum
    Jeff Pflum
    Participant

    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.

    Thoughts?

You must be logged in to reply to this topic.