Checksum Failed w/ multiple ConfigurationNames

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

Viewing 1 reply thread
  • 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: 18
      Replies: 4872
      Points: 1,903
      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:

Viewing 1 reply thread
  • The topic ‘Checksum Failed w/ multiple ConfigurationNames’ is closed to new replies.