Checksum Failed w/ multiple ConfigurationNames

DSC
1

Sorry if this was posted already, but I didn’t see it on the first few pages of posts.

Whenever I configure multiple ‘ConfigurationNames’ in the LCM config (metaconfig), I get this error when pulling, such as when running {Update-DSCConfiguration}:

PS C:\Windows\system32> Update-DscConfiguration -Wait -Verbose
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
PerformRequiredConfigurationChecks,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer KYLE-IPAM with user sid
S-1-5-21-3149736864-2278915772-2866003438-1107.
VERBOSE: [KYLE-IPAM]:                            [] Executing Get-Action with configuration 's checksum:
27CF2908BFD506C5C390EB5BDEE48601BF238F64C3E36384D6C55DAF88AB5184.
VERBOSE: [KYLE-IPAM]:                            [] Executing Get-Action with configuration 's checksum failed. Please
check the availability of pull server.
A generic exception occurred during the invocation of the Get-DSCAction cmdlet by Download Manager WebDownloadManager.
    + CategoryInfo          : InvalidResult: (root/Microsoft/...gurationManager:String) [], CimException
    + FullyQualifiedErrorId : GetActionException
    + PSComputerName        : localhost

VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 1.532 seconds

If I configure ConfigurationNames with @(‘test’) or @(‘test2’), it pulls the configuration and works perfectly. If I configure that same setting as @(‘test2’,‘test’) or @(‘test’,‘test2’), I get the above error.

Is this a valid configuration at this point? I also wasn’t sure what order they would be applied in, as I don’t believe DependsOn will work between configs, but I could be wrong. I was trying to test out those concerns when I was stopped by the previously mentioned error.

Just to be clear, all I’m changing is that one setting in the metaconfig.

In the meantime, I’m considering simply creating one large configuration with the whole per-node configuration style using configuration data variables. Running smaller configs would be nice, but have their own issues as well.

2

The order is non-deterministic, and you can’t control it. DependsOn should work, as the LCM combines all the MOFs before doing its prescan (which includes unwinding dependencies). And I’ve found a lot of reasons to not like partial configurations :(.

I do wonder if you’re on the latest bits. This WAS a known problem at one point, but I thought it’d been resolved. https://powershell.org/forums/topic/generating-mof-for-partial-configurations-using-configuration-names/ may be interesting to read.

3

Bits should be most recent. I just got setup in the past few days. I’m not sure what all controls what. I mean, there are the modules, WMF version, etc. I’ll post that now:

PS C:\DSC\Configs> get-host

Name             : ConsoleHost
Version          : 5.0.10586.117
InstanceId       : 3879c5c7-cda4-4cd3-bbe6-08a341a593ec
UI               : System.Management.Automation.Internal.Host.InternalHostUserInterface
CurrentCulture   : en-US
CurrentUICulture : en-US
PrivateData      : Microsoft.PowerShell.ConsoleHost+ConsoleColorProxy
DebuggerEnabled  : True
IsRunspacePushed : False
Runspace         : System.Management.Automation.Runspaces.LocalRunspace

Manifest 2.11.0.0 xActiveDirectory
Manifest 1.6.0.0 xComputerManagement
Manifest 2.3.0.0 xDscDiagnostics
Manifest 0.3.0.0 xPendingReboot
Script 3.10.0.0 xPSDesiredStateConfiguration
Manifest 1.1 PSDesiredStateConfiguration

I also thought partial configurations were different. I just went back to Partial Configurations documentation and realized I was mistaken. The current documentation says very little about ConfigurationNames, so I was trying to test it out.

“ConfigurationNames String An array of names of configurations to be pulled by the target node. These are used only if the node is registered with the pull server by using a RegistrationKey. For more information, see Setting up a pull client with configuration names.”

^
No mention of Partial Configurations. Now I know that they are intended to be used in tandem with Partial Configuration blocks.

https://msdn.microsoft.com/en-us/powershell/dsc/pullclientconfignames

No mention of Partial configs here either. It is not obvious at all that adding additional configuration names will result in an error due to additional requirements. You basically have to stumble upon the information, and put it together on your own.

I agree that there are downsides to Partial Configs at this point. I heard the biggest one is that they are only evaluated on the client, so debugging is more difficult.

I fear that some UX and design goals weren’t fully thought out in the early stages. I hope I’m wrong, but I have to say I was expecting something easier to manage. Hopefully once we get out of Experimental phases, this will be easier.

I’ve been working with Composite Resources, I think they’re called, so that will help make the massive configuration files a little more readable, but of course there are downsides to anything.

I think this can be considered closed. The error message should really mention you are missing a configuration requirement, instead of saying the Checksum failed. If it told me why it was failing, I wouldn’t even be here. :smiley face: