Is it possible to lazily evaluate features in Windows PowerShell Desired State Configuration?

Question

In Windows PowerShell Desired State Configuration, you can define features:

Node $MachineName { 
    # define the IIS Role 
    WindowsFeature IIS { 
        Name = “Web-Server” 
    }

    # define the SQL Role 
    WindowsFeature SQL { 
        Name = “SQL-Server” 
    }

    # require ASP.NET 4.5 
    WindowsFeature ASP { 
        Ensure = “Present” 
        Name = “Web-Asp-Net45” 
        DependsOn = "[WindowsFeature]IIS"
    }
}

Using this setup, not only ASP gets installed, but also the IIS and the SQL features. The IIS feature i can understand, since ASP depends on that. But the SQL feature is not defined as "Present", and is not required by another "Present" feature.

Is it possible to define these basic features (as a kind of repository) but only install the required features?

Answer 1

Yes and no.

First, I want to point out that DependsOn tells DSC which order to do things, and that's about as far as DSC understands it. It just lets you decide that some resource needs to be executed after one or more other resources.

Leaving out Ensure = 'Present' , if it works, is likely just defaulting to 'Present' ; there is no way to put a resource in there (without additional code), that doesn't get executed.

I'm not certain what you mean by a "repository" unless you just mean to have it present in the Configuration {} block for future reference or use.

What I mean by "additional code" is that you can control which resources get used when you generate your config from this script.

Stepping back a bit, the code block you have there is a configuration script which you must execute to generate an MOF file, which will then be the actual thing that gets applied to the node.

That script is in fact powershell so you can apply your logic as to what gets applied at that point (when the MOF is being generated). This happens in the context of the machine generating the MOF though, not on the target node, so you can't use any logic that requires code being run on the target at the time of configuration application.

DSC has some built-in stuff to facilitate this, through the use of the -ConfigurationData parameter and the automatic variables like $AllNodes and $Node .

I'd like to put some code here instead of just links and an explanation, but you really need to get a full sense of where and when these pieces fit together.

I think the most important takeaways are these:

• The configuration you write (as shown in your code block) is Powershell code and as such you can use logic to determine which resources are applied to which node.
• The execution of the configuration happens typically on a computer that is not the target node, before the target node is up or being configured, so consider the context of execution.
• Look at the ways that -ConfigurationData is used in Microsoft's examples.

Have a look at these:

• Separating Configuration and Environment Data
• Separating "What" from "Where" in PowerShell DSC
• Automatic variables in Desired State Configuration