UpdateMetaConfig is not a valid value for GetActionResponse

Hi,

I try to install a DSC HTTPS Pull server environment with Partial configuration. Using ConfigurationNames.

But when I call the Update-DscConfiguration I get this :

In the Pull server Events log : Server response for ConfigurationName = DSCClient01 with Status = UpdateMetaConfig (Information)

In the Client Events log : Message UpdateMetaConfig is not a valid value for GetActionResponse. (error)

I think it is related to this bug :

https://connect.microsoft.com/PowerShell/feedback/details/1895618/enum-getactionresponse-on-pull-server-has-different-values-than-on-dsc-agent

Here are my scripts :

Pull Server config :

 
Configuration PullServer
{
    param(
            [Parameter(Mandatory)]
            [ValidateNotNullOrEmpty()]
            [string] $SSLCertThumbprint
    )

    Import-DscResource -ModuleName xPsDesiredStateConfiguration   
  

    node localhost
    {
        WindowsFeature DSCServiceFeature
        {
            Ensure = "Present"
            Name   = "DSC-Service"            
        }

        xDscWebService PSDSCPullServer
        {
            Ensure                       = "Present"
            EndpointName                 = "PSDSCService"
            Port                         = 443
            PhysicalPath                 = "c:\inetpub\PullServer"
            CertificateThumbPrint        = $SSLCertThumbprint                  
            State                        = "Started"
            AcceptSelfSignedCertificates = $true
            DependsOn                    = "[WindowsFeature]DSCServiceFeature" 
            ModulePath                   = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules"
            ConfigurationPath            = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration"
            RegistrationKeyPath          = "$env:PROGRAMFILES\WindowsPowerShell\DscService"
        }

        File RegistrationKeyFile
        {
            Ensure          = 'Present'
            Type            = 'File'
            DestinationPath = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
            Contents        = '67c4388b-6440-4afa-b787-910dad5610f0'
        }
    }
}

$SSLThumbprint = Get-ChildItem -Path Cert:\LocalMachine\My | where {$_.Subject -like '*dscqua01.*'} | select -ExpandProperty Thumbprint

PullServer -SSLCertThumbprint $SSLThumbprint -OutputPath C:\PullConfiguration

Start-DscConfiguration -Path 'C:\PullConfiguration' -Wait -Verbose

DSC Client LCM Config :

 
[DscLocalConfigurationManager()]
Configuration DscNodePartialConfig
{
    param(
            [Parameter(Mandatory)]
            [ValidateNotNullOrEmpty()]
            [string] $DscNodeName         
    )   

    Node $DscNodeName {
        Settings
        {
            RefreshMode          = 'Pull'
            ConfigurationMode    = 'ApplyAndAutoCorrect'
            ActionAfterReboot    = 'ContinueConfiguration'
            RebootNodeIfNeeded   = $false   
            DebugMode = 'ForceModuleImport'          
        }

        ConfigurationRepositoryWeb V2PullServer
        {
            ServerURL           = 'https://dscqua01.central.XXX.int/PSDSCPullServer.svc/'
            ConfigurationNames  = @('InitialConfig','DSCClient01')
            RegistrationKey     = '67c4388b-6440-4afa-b787-910dad5610f0'
        }

        ResourceRepositoryWeb V2PullServer
        {
            ServerURL         = 'https://dscqua01.central.XXX.int/PSDSCPullServer.svc/'
            RegistrationKey   = '67c4388b-6440-4afa-b787-910dad5610f0'
        }

        ReportServerWeb V2PullServer
        {
            ServerURL         = 'https://dscqua01.central.XXX.int/PSDSCPullServer.svc/'
            RegistrationKey   = '67c4388b-6440-4afa-b787-910dad5610f0'
        }
            
        PartialConfiguration 'InitialConfig'
        {
            Description           = 'Configuration for the Base OS'
            ConfigurationSource   = '[ConfigurationRepositoryWeb]V2PullServer'
            RefreshMode           = 'Pull'

        }        
       
        PartialConfiguration 'DSCClient01'        {
            Description           = 'Configuration for application'   
            ConfigurationSource   = '[ConfigurationRepositoryWeb]V2PullServer'         
            RefreshMode           = 'Pull'           
                      
        }

    }
}
DscNodePartialConfig -OutputPath C:\PullConfiguration\LCM -DscNodeName DSCClient01

Set-DscLocalConfigurationManager -ComputerName DscClient01 -Path C:\PullConfiguration\LCM -verbose

One of the partial config I need to update :

Configuration DSCClient01 {  

  param(
   [string]$Servername
  )
    Import-DscResource -Name xPackage
    Import-DscResource –ModuleName 'PSDesiredStateConfiguration'  
   
     
     $config = gc -Path "C:\PullConfiguration\apps\GFM\ServerConfigs\$Servername.json" | Convertfrom-json 
     #$config = Invoke-RestMethod  -Uri 'http://localhost/my.json' | convertfrom-json TODO: test with WebApi if needed / choosed

      Node $config.NodeName {  
      
        #Generate config for Apps/Msi type        
        foreach ($app in $config.Apps) { 
            xPackage $app.AppName {
                 Name = $app.PackageName
                 Ensure = $app.Ensure    
                 Path = $app.MsiPath 
                 ProductID = $app.ProductID     
                 Arguments = $app.Arguments               
            }
        }  
    }
}


function UpdateServerConfig{

    param(
    [string]$ServerName
    )

    $MofPath = "C:\Program Files\WindowsPowerShell\DscService\Configuration\"     

    #Regenerate the MOF config
    DSCClient01 -OutputPath $MofPath -Servername $ServerName
    New-DscCheckSum -ConfigurationPath $MofPath

  
    #Push the config to the server
    Publish-DscConfiguration  -Verbose -ComputerName $ServerName  -Path $mofpath -force 
    Update-DscConfiguration  -Verbose -ComputerName dscclient01 -wait 
}

UpdateServerConfig -ServerName DSCCLIENT01

PS Version :
Name Value


PSVersion 5.0.10586.51
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
BuildVersion 10.0.10586.51
CLRVersion 4.0.30319.34209
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

Is it a Bug in DSC or an error in my config ?

Thanks.

Just double-checking: your pull server and DSC client are both running the same version of PowerShell?

yes for both :

PSVersion 5.0.10586.51
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
BuildVersion 10.0.10586.51
CLRVersion 4.0.30319.34209
WSManStackVersion 3.0
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1

On Windows 2012R2 domain joined

Will see if I can reproduce this with the production preview. I don’t have a copy of the RTM handy from those few days before they pulled it off the download center. :slight_smile:

Edit: Nevermind, yes I do! Just found it in my downloads folder.

Problem solved. I use the AgentID as the ConfigurationID so i don’t need to manage Guid.

here is the link :

https://github.com/AesonDev/DSC-COnfig

But somehow the RegistrationKey is not needed…

Hi,

Copying what I wrote on your github for future reference.

You have mixed two things: AgentID and ConfigurationID.
Although both are GUIDs they serve different purposes and act with different parts of the script.

ConfigurationID is the old V4 method for Nodes registering with the Pull server. You have to set it yourself and manage it. You can set couple of nodes to have the same ConfigrationID which allows you to pull same configuration script to create matching nodes.
ConfigurationID works with PartialConfiguration blocks in the LCM script.

RegistrationKey is the new V5 method for Nodes registration with the pull server. You dont have to set it or manage it. By using a shared “secret” - that’s the Key you use in the LCM and in the txt file on the pull server, a node registers to the pull and the pull assigns it an AngentID which i unique to the each node.
RegistrationKey works with ConfigurationsNames.

So basically ConfigurationNames is the way to do “Partial Configurations” when you use the new method, a.k.a. RegistrationKey.

If you want to use the new RegistraionKey you use the ConfigurationNames, theres no point to use the PartialConfiguration blocks, that’s the old v4 way.
In this script you basically used the ConfigurationID so you don’t need the ConfiguratioNames in the LCM, that’s why it seems to be “working without RegistrationKey being needed”

ok Thanks. I’m working on it :slight_smile:

To add to Arie’s info:

Currently ConfigurationNames do not support multiple configurations despite the input being an array. You can effectively get around this with composite configurations, but that’s a topic for another day.

ok thanks. So the only possibility is see is to use the AngentID as ConfigurationID to avoid the need to manage GUID. Like in my first post on Github.

Is this a bug ? ( A array who can only contains 1 item ) Will this change before WMF5 going to production ? (I really plan to use this with nano server)

Thanks

@Justin - hopefulyl ill be done with my tests this week to verify how the ConnfigurationNames work. Are you sure about it not being supported ? have you read anything official on it ?

@Gaetan -

It would be wise to not use the term AgentID in this sense.

When you install windows, the local LCM has no AgentID. (you can see it in the Registry as it will have an empty value)

The first time you run a Get-DSCLocalConfgirationManager or similar query/update commands to the LCM, an AgentID is created (even with no other configuration is being pushed to the node).

When a node registers to a pull server, that AgentID changes to a new one. This is done only the first time ever that a node registers and the pull server records that GUID in its database. So if you already registerd the node to the v5 pull server, the value in ConfigurationID isnt considered. I think Justin has come up with that in his tests and had a post about it in the past weeks

If what Justin said about it not being supported even though its an array and numerous example scripts form MS show diferent values in that parameter and my test show the same then yes thats a bug and we should open a uservoice ticket for that.

WMF5 is production ready from late last year.

Your DSC Client LCM Config script should look like this:

 
[DscLocalConfigurationManager()]
Configuration DscNodePartialConfig
{
    param(
            [Parameter(Mandatory)]
            [ValidateNotNullOrEmpty()]
            [string] $DscNodeName         
    )   

    Node $DscNodeName {
        Settings
        {
            RefreshMode          = 'Pull'
            ConfigurationMode    = 'ApplyAndAutoCorrect'
            ActionAfterReboot    = 'ContinueConfiguration'
            RebootNodeIfNeeded   = $false   
            DebugMode = 'ForceModuleImport'          
        }

        ConfigurationRepositoryWeb V2PullServer
        {
            ServerURL           = 'https://dscqua01.central.XXX.int/PSDSCPullServer.svc/'
            ConfigurationNames  = @('InitialConfig','DSCClient01')
            RegistrationKey     = '67c4388b-6440-4afa-b787-910dad5610f0'
        }

        ResourceRepositoryWeb V2PullServer
        {
            ServerURL         = 'https://dscqua01.central.XXX.int/PSDSCPullServer.svc/'
            RegistrationKey   = '67c4388b-6440-4afa-b787-910dad5610f0'
        }

        ReportServerWeb V2PullServer
        {
            ServerURL         = 'https://dscqua01.central.XXX.int/PSDSCPullServer.svc/'
            RegistrationKey   = '67c4388b-6440-4afa-b787-910dad5610f0'
        }
            
    }
}
DscNodePartialConfig -OutputPath C:\PullConfiguration\LCM -DscNodeName DSCClient01

Set-DscLocalConfigurationManager -ComputerName DscClient01 -Path C:\PullConfiguration\LCM -verbose

I think the PartialConfiguration blocks are not even used if its a pull server that was registered via RegistrationKey, but i cant tell for sure as i havent tested that. Perhaps Justin or others will have more to say on it.

The Partial config script is not the correct one for this way of working. You do not push it to the node. In fact you dont use the server name in any way. The idea with v5 is to allow you to have friednly name mof files.

So

 #Push the config to the server
    Publish-DscConfiguration  -Verbose -ComputerName $ServerName  -Path $mofpath -force 
    Update-DscConfiguration  -Verbose -ComputerName dscclient01 -wait 

should be removed.

Once you run the creation of the mof file and the checksum and both are movd to the configuration folder on your pull server, the node will automatically fetch the configuration and apply it.

Since you used friendly names for ConfigurationNames, thats should also be the name of the mof files. So the

      param([string]$ServerName)

change to something like

     param([string]$Component)

and at the end use

UpdateServerConfig -Component DSCCLIENT01

for exmaple.

Its not longer a mindest of a server as in v4, but a Role notion.

@arie it’s bubbled up a few times on this very forum . I’ve not done deep testing on it myself, but here’s a sample where someone defined it and Don said he’s never seen it work:

https://powershell.org/forums/topic/multiple-configurationnames/#post-34313

The fact that it’s an array implies it will someday … but not today.

Also, in your sample script you specify unique report repositories but specify the same URL for all. If you truly wish to use a single server you don’t need to specify each configuration block uniquely. I ran into this one a little while ago :slight_smile:

Hmm, interesting. Because Daniel didn’t supply all the scripts in full, I’m going to to assume the issue is there and not in the ConfigurationName usage. Even Don’s reply is more suggestive then decisive.

Guess I have to push my tests. I’ll update later.

As for the the three repositories blocks, I copied the original script and didnt change it because of Erics’ reply in this :

https://powershell.org/forums/topic/reportserver-or-complianceserver/

If you look at my reply, which I also commented on the github repo for the docs, you have to use that block if you want the node to report. It sounds like a silly design overlook if that’s the case, which is why I asked Eric to reconfirm this.

If you noticed a different behavior, which seems to align more to how I think it should work, then that’s good. Just need a confirmation from Eric and see what my tests produce

Interesting … Ill have to test the reporting … I was merely going off the MSDN site which states you don’t have to specify it unless you want reports in a custom location.

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

“By default, the client node gets required resources from and reports status to the configuration pull server. However, you can specify different pull servers for resources and reporting.”