If you’re all being good little Windows opscoders, you’ll be using DSC. And if, like me, you’ve upgraded to WMF 5.0 (PowerShell 5.0), you may have noticed a few new warning messages popping up in your logs

You do look at your logs, right?

Good.

Well, you may have been seeing this little warning of late

WARNING: The configuration ‘ExampleDSCConfig’ is loading one or more built-in resources without explicitly importing associated modules. Add Import-DscResource –ModuleName ‘PSDesiredStateConfiguration’ to your configuration to avoid this message.

I’ve certainly been seeing it. It hasn’t done any harm. Nothing breaks, it’s just a warning. I’ll get round to fixing it eventually.

Well, in the last day or so, I rolled WMF 5.0 into my production server fleet – a couple of hundred servers all up – and today I’ve had developers asking me why their Octopus Deploy projects are generating warnings now. 

Sigh.

What’s going on here?

Well, WMF’s DSC handling is slightly more strict than you’ll have seen under PowerShell 4.0. With the 1.1 wave of PSDesiredStateConfiguration resources, we now have a need to be specific about what resources we’re importing, which means explicitly importing resources is now a best practice.

So OK, let’s do what the error message suggests. Let’s add that line and see what happens.

Multiple versions of the module ‘PSDesiredStateConfiguration’ were found. You can run ‘Get-Module -ListAvailable -FullyQualifiedName PSDesiredStateConfiguration’ to see available versions on the system, and then use the fully qualified name ‘@{ModuleName=”PSDesiredStateConfiguration”; RequiredVersion=”Version”}’.

Ah bugger. OK, no problem, there’s a way to fix this, and it’s not quite the way the error message suggests. Rather than creating a hashtable with your modulename and requiredversion, here’s the way to do it:

Import-DscResource -ModuleName "PSDesiredStateConfiguration" -ModuleVersion "1.1"

Under WMF 5.0, you will have 1.1 available, and this will prevent the warning, meaning your logs will be slightly less full of crap and your developers will be less confused. However, there’s one further problem.

For the next couple of days, I’ll be running a mixed fleet with both PowerShell 4.0 and PowerShell 5.0 machines. If I roll out that line of code and it hits a node with only PowerShell 4.0 installed, it’ll throw an error, because PowerShell 4.0 only has Module Version 1.0.

So for now, temporarily, I’ve had to suppress warnings, by setting my WarningPreference to SilentlyContinue.

$WarningPreference = "SilentlyContinue"
CompressionStep
Start-DscConfiguration ./CompressionStep -wait -Verbose -force 
$WarningPreference = "Continue"

This is emphatically not best practice, but it’ll keep things quiet for a day or two while all the older nodes in the fleet get cycled out of service. And then I can go back to strict mode and await the next time an upgrade confuses all my Octopus users.