7

If I nest DSC configurations in a single file like this, it works fine:

Configuration Secondary {
    Param ($SomeParameter)

    Environment Test {
        Name = $SomeParameter
        Value = "12345"
    }
}

Configuration MyConfiguration {
    Node localhost {
        Secondary TheSecondary {
            SomeParameter = "TestEnvVar"
        }
    }
}

MyConfiguration

Start-DscConfiguration .\MyConfiguration -Wait -Verbose

I want to split my configuration in to two separate files. One will dot-source the other to include the configuration.

Secondary.ps1:

Configuration Secondary {
    Param ($SomeParameter)

    Environment Test {
        Name = $SomeParameter
        Value = "12345"
    }
}

Primary.ps1:

. .\Secondary.ps1

Configuration MyConfiguration {
    Node localhost {
        Secondary TheSecondary {
            SomeParameter = "TestEnvVar"
        }
    }
}

MyConfiguration

Start-DscConfiguration .\MyConfiguration -Wait -Verbose

For some reason this doesn't pick up the parameter passed in to the secondary configuration and so results in the error:

Could not find mandatory property Name. Add this property and try again.
    + CategoryInfo          : ObjectNotFound: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : MI RESULT 6
    + PSComputerName        : localhost

It seems very strange that it works when in the same file but not when dot-sourcing. I thought that dot-sourcing was basically the same as including code in the same file. What am I missing here?

Richard
  • 826
  • 2
  • 8
  • 20

3 Answers3

5

If you want to reference a configuration from another configuration that is not defined in the same file, you need to use the composite resource pattern.

In a module, you'll create a DscResources folder. In that folder, you'll create a module to hold your composite configurations. The composite configuration will be defined in a file with the extension .schema.psm1. The file will require a module manifest pointing to the schema.psm1 file as the root module.

For more detail and an example, check out the PowerShell team blog - http://blogs.msdn.com/b/powershell/archive/2014/02/25/reusing-existing-configuration-scripts-in-powershell-desired-state-configuration.aspx

Steven Murawski
  • 1,570
  • 3
  • 14
  • 25
  • The downside to this approach is that the modules need to be "installed" in the Modules dir of the remote machines. Changes to the nested configuration mean they need to be re-distributed, and the DSC WMI Provider restarted (so that the module is reloaded). Instead, I'm trying an outer PS script that coordinates different Configurations – Peter McEvoy Jul 21 '15 at 16:29
  • 1
    @PeterMcEvoy Composite configurations only need to be deployed where the configuration documents (the MOF documents) are being generated. Typically, this would be in some sort of build pipeline. Nodes applying those MOF documents would not need the modules with composite resources unless they also contained actual resources applied to the node. – Steven Murawski Jul 21 '15 at 17:44
  • Ahh.... now that's a lightbulb moment.... – Peter McEvoy Jul 22 '15 at 07:08
3

Splatting the parameters helps - following amended Primary.ps1 should work:

. .\Secondary.ps1

Configuration MyConfiguration {
    Node localhost {
        $params = @{ SomeParameter = "TestEnvVar" }
        Secondary TheSecondary @params
    }
}

MyConfiguration

Start-DscConfiguration .\MyConfiguration -Wait -Verbose
mgr32
  • 183
  • 4
0

Per this answer, it excepts parameters in following format:

Node localhost {
    Secondary TheSecondary -SomeParameter "TestEnvVar"
}

Just for information.

Der_Meister
  • 113
  • 6