reusable configuration

Hi community

Hope someone can help me. I read a lot about nesting configurations, partial configurations, reusing configurations, modules, resources and so on.
But I cannot find a solution for my problem.

Ok, here we go. This is just one example, I have lots of identical problems with other modules and properties. This is a more a conceptual problem.

I’d like to configure several IIS websites for several customers for several different applications in several environments (hope you get it).
I use the xWebAdministration Module.
We have company standards on how a website has to be configured. E.g. we have defined, that every applicationpool must be recycled at 2 am. (restartSchedule = @(‘02:00:00’)).
(We have hundreds of such settings. And it’s not just IIS websites.)
So this setting will be part of the “CompanyIISWebsite” Composite Resource in the “CompanyDSCCompositeResource” Module (tried it this way for now).
Now, let’s say I have a faulty application which needs another recycle during the day.

So if I define this setting in the “application specific” part of my configuration, I get an error:

Composite Resource:

Configuration CompanyIISWebsite {
    param(
        [string]$WebSiteName,
        [string]$WebRoot
    )
    Import-DscResource -ModuleName xWebAdministration

    xWebAppPool CreateWebAppPool
        {
            Name   = $WebSiteName
            Ensure = "Present"
            State  = "Started"
            restartSchedule = @('02:00:00')
        }

    #other configuration
}

Application Configuration:

Configuration applicationA {

    #Import module with "CompanyIISWebsite" resource
    Import-DscResource -ModuleName CompanyDSCCompositeResource

    Node $AllNodes.NodeName
	{
        #Create website according to company standards
        CompanyIISWebsite applicationA
		{
            WebSiteName = $ConfigurationData.WebConfig.WebSiteName
            WebRoot     = $ConfigurationData.WebConfig.WebRoot
        }

        #Additional settings for this application
        xWebAppPool AdditionalRestartSchedule
		{
            Name   = $ConfigurationData.WebConfig.WebSiteName
            Ensure = "Present"
            State  = "Started"
            restartSchedule = @('02:00:00','12:00:00')
        }
    }
}

I understand that this configuration gives the following error, because of how LCM works:

PS C:\DSC\applicationA> .\applicationA.ps1
Test-ConflictingResources : A conflict was detected between resources
.... 
Resources have identical key properties but there are differences in the following non-key properties: 'restartSchedule'. Values
'System.Object[]' don't match values 'System.Object[]'. Please update these property values so that they are identical in both cases.

From my expectations, the value should be overwritten (or added). If I cannot override properties, I can’t find a way to create a modular/hierarchic and reusable configuration.
One solution could be that I pass every possible value to the CompanyIISWebsite resource. But this would result in a lot of effort and a big overhead, because I don’t know which setting I’m going to use in the future.

Somehow no one else seems to have this kind of problem. Seems to me as nobody uses DSC in such an environment as I work.
Maybe DSC is not the right tool for our goal or I just cannot see the solution. Or I don’t fully understand the concept. We are somewhere in between Configuration Management and Application Deployment.
I also played with Ansible and this seems more my way to go with the task and role concept. But I’d really like to go the Microsoft way.

Any suggestions or links would be great. Thank you very much.

Regards
Jeans

My understanding of DSC is that you can only have one value per setting if not DSC blows up. This is why composite and partial configs can be dangerous and infuriating as the error does not manifest till the LCM evaluates the whole document.

You would need need a different composite for the situation of the extra restart.

Thanks for your response.
As we have tons of “a bit different” applications, we really like to reuse existing code.
It does not make sense to have hundreds of config files, but they all are 40% the same, just with different parameters.

Maybe I’m wrong but it seems DSC is only suitable (efficient) for two types of scenarios:
a) you have few servers with small configurations (1 AD, 1 Exchange, 1 IIS etc.)
b) you have many servers, but they all have the same configuration (webfarm)

Can someone proof me wrong please? :slight_smile:

Regards
Jeans

You could look at parameters for certain aspects like reboot times if you know all the other settings will be the same.

I ran into a similar problem with security groups. I wanted to add a member of the Administrators group in a composite resource that every machine got. Then in another composite that only a subset of machines got, I wanted to add another member to Administrators. This created an error because the key of the Group resource is the name of the group you’re changing - Administrators in this case.

What I ended up doing was creating my own resource module that had a key that was really just a made-up description that I made unique across all composite resources, to avoid key name collisions. Then the other parameters were the group name and the member you wanted to ensure was present or absent. I wish I didn’t have to make a custom resource that duplicated existing functionality, but it wasn’t too hard to do, and it’s worked quite well for us since.

I think the root cause here is we need a solution to manage configuration data. I definitely recommend looking in to the Datum project. It is the latest development on the configuration data hierarchical management solution originally published in the powershell.org GitHub dsc repo. This wouldn’t resolve using the same resource in two places, it would move the resolution from the configuration script out to data management.

We are tracking a UserVoice item as priority for Azure Automation.
https://feedback.azure.com/forums/246290-automation/suggestions/14816814-provide-configuration-data-management-for-dsc

Thanks for all your suggestions.
I’ll definitely have a look at the Datum project.

Oh, thanks for the shout out Michael!

I keep an example of a DSC ‘control Repo’ leveraging Datum in another project:

Datum is not yet released to the PSGallery, but thanks to PSDepend you can grab it from from github directly: git clone; then .build.ps1 -ResolveDependency

If you’re not behind a proxy (if you are, it can be a bit more involved).

Working on documentation, but the day job has priority.
Feel free to post issues on GitHub for questions & bugs.