Checksum Failed w/ multiple ConfigurationNames

Welcome Forums DSC (Desired State Configuration) Checksum Failed w/ multiple ConfigurationNames

This topic contains 2 replies, has 2 voices, and was last updated by

3 years, 3 months ago.

  • Author
  • #44828

    Topics: 2
    Replies: 18
    Points: 0
    Rank: Member

    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' =
    VERBOSE: An LCM method call arrived from computer KYLE-IPAM with user sid
    VERBOSE: [KYLE-IPAM]:                            [] Executing Get-Action with configuration 's checksum:
    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.

  • #44854

    Topics: 13
    Replies: 4872
    Points: 1,844
    Helping HandTeam Member
    Rank: Community Hero

    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. may be interesting to read.

    • #44871

      Topics: 2
      Replies: 18
      Points: 0
      Rank: Member

      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 xActiveDirectory
      Manifest xComputerManagement
      Manifest xDscDiagnostics
      Manifest xPendingReboot
      Script 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.

      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:

The topic ‘Checksum Failed w/ multiple ConfigurationNames’ is closed to new replies.