ConfigNames being awfully quiet ...

[justin-king]

Playing with configNames and running into a bit of a pickle: the nodes appear to quietly do nothing. Bit of a journey but Ill give you the cliff’s notes:

After upgrading to WMF5.0 production preview, I started down the a (very) simple configname test: I took one of my existing mofs that was working in a “Traditional configurationID” format, renamed it and regenerated the checksum.

I then attempted to reconfigure a single node to see if I could get it to read this “friendly name”. So I pushed a “faux” config then deleted all the modules as I wanted to see them get pulled again. This way the client was silently “consistent” with my little dummy config.

I then configured the following configuration:

{ 
        Settings
        { 
            RefreshMode = "PULL";
            RebootNodeIfNeeded = $true;
            AllowModuleOverwrite = $true;
            RefreshFrequencyMins = 30;
            ConfigurationModeFrequencyMins = 60; 
            ConfigurationMode = "ApplyAndAutoCorrect";
        }

        ConfigurationRepositoryWeb ConfigurationManager
        {
            ServerURL = 'https://dsc.lab.contoso.com:8080/PSDSCPullServer.svc'
            RegistrationKey = '***'
            ConfigurationNames = @("configtest")
        }

}  

On first run, applying the configuration failed. Repeat attempts would allow it to succeed, but nothing would seem to work properly. Luckily 5.0 RTM got released, so installing that over-the-top I then applied this little command gem below (thanks release notes):

mofcomp $env:windir\system32\wbem\DscCoreConfProv.mof

Bingo. I could now set-dsclocalconfiguration and pass. If I check event logs I can see the registration work, and an agentID get assigned. I appear to be in the clear.

That said, nothing appears to happen. Every 30 minutes, as per the configuration, I see a local update parse in the eventlogs, but I see the old “faux” config come back as consistent. NO modules are ever grabbed … no new config is ever downloaded.

Setting the ConfigurationID and renaming the mof to match instantly works as expected.
I’m guessing I’m missing something in the LCM configuration? But what? Again, the operationlog shows regular polling as configured, but whenever i get-dscconfiguration it continues to show my old push.

[system]

Sounds like your on the right track.

Do you have the thumbprint for the secured site in your LCM config? Here’s one of mine as an example

	Settings {
	
		AllowModuleOverwrite = $True
        ConfigurationMode = 'ApplyAndAutoCorrect'
		RefreshMode = 'Pull'
		ConfigurationID = "" # Setting to blank - but can leave a guid in - won't matter
        }

        ConfigurationRepositoryWeb DSCHTTPS {
            ServerURL = 'https://DSC.company.pri:8080/PSDSCPullServer.svc'
            CertificateID = $Thumbprint
            AllowUnsecureConnection = $False
            RegistrationKey = "1234567"  
            ConfigurationNames = @("RoleSNMP") 
        }

[system]

Oh, and I should have asked if your pull server is Core or the graphical.

[justin-king]

I saw your thread about it being graphical … so i preemptively made BOTH the pull server and node full installs … probably overkill … but gave it a go.

Though the thumbprint … is that thumbprint NOT what is used for decryption of credentials … is that supposed to be for identifying the pull server? If so then that’s an omission right there… I didn’t have any credentials in the sample mof so i didn’t put any thumbprint in at all.

Updated that and made no difference. operation logs say it’s contacting the pull server correctly but it always shows with blank configIDs … like so:

Job {5BA6C850-DF4C-11E5-80C5-00155D013217} :
Attempting to get the action from pull server using Download Manager WebDownloadManager. Configuration Id is . Checksum is . Compliance status is true.

I’m assuming it shouldn’t be trying to use a configurationID … instead looking for a specific ConfigurationName. At anyrate it’s null (can’t use both a configID and a registationID) and thus nothing gets pulled.

[system]

So, do this – start with a pull server that has the GUI – there might be an issue with core. If your pull server is secured (using a certificate) as it should be – even in a lab environment – then you need the thumbprint of the certificate in the LCM configuration. As an example, I include my entire LCM config below. It gets the thumbprint — but I’m wondering why if this is the case, your GUID based config works – your url for the lcm starts with HTTPS…so I’m assuming a certificate(SSL).

So, this isn’t the best way, but here my LCM con gif get the cert from a pull server on a computer called DC:

Note line 36:

[DSCLocalConfigurationManager()]
Configuration LCM_ConfigName
{
param
(
[Parameter(Mandatory=$true)]
[string]$ComputerName,

        #[Parameter(Mandatory=$true)]
        #[string]$guid, <------------------------Dont need this anymore

        [Parameter(Mandatory=$true)]
        [string]$ThumbPrint

    )      	
Node $ComputerName {

	Settings {
	
		AllowModuleOverwrite = $True
        ConfigurationMode = 'ApplyAndAutoCorrect'
		RefreshMode = 'Pull'
		ConfigurationID = "" # Setting to blank - but can leave a guid in - won't matter
        }

        ConfigurationRepositoryWeb DSCHTTPS {
            ServerURL = 'https://DSC.company.pri:8080/PSDSCPullServer.svc'
            CertificateID = $Thumbprint
            AllowUnsecureConnection = $False
            RegistrationKey = "1234567" # <----------- We Need this 
            ConfigurationNames = @("RoleSNMP") # <----------- We Need this - only one role!
        }
}

}

$Thumbprint=Invoke-Command -Computername dc {Get-Childitem Cert:\LocalMachine\My | Where-Object {$_.FriendlyName -like “wild”} | Select-Object -ExpandProperty ThumbPrint}

Create the Computer.Meta.Mof in folder

LCM_ConfigName -ComputerName s2 -Thumbprint $Thumbprint -OutputPath .\

[system]

Well thats crap – let me try again

https://gist.github.com/anonymous/bb5f809ac4c87ab8ee1e

[justin-king]

OK, I’m basically going to rebuild my pull server and install on a full install like you suggested. We’ll see where it gets me, but yes its odd: configurationID works instantly. Another option may be to start wit ha fresh node thats never been reconfigured just to see …

[justin-king]

Sorry about being slow on the updates, but as we technically have working configurations using GUIDs the priority on this is a little low. That said here’s the configuration I’m using to standup a new pull server, see if it looks “right” to you guys out there:

Biggest note: the compliance server settings are a carryover from WMF4.0 (specifically the dsc book)… it seems to be mysteriously gone from the WMF5.0 documentation … don’t know if it’s still needed or if everything can just default over the main pullserver ports now. I’m leaving it in because I do have some (admittedly simple) reports I’ve managed to get from it that I’d like to keep using.

Configuration V2PullServer
{
    param(
            [Parameter(Mandatory=$false)][string] $NodeName = $env:ComputerName,
            [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][string] $SSLCertThumbprint
        )

    Import-DscResource -ModuleName xPsDesiredStateConfiguration
    Import-DscResource -ModuleName xWebAdministration

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

        WindowsFeature WinAuth 
        { 
            Ensure = "Present" 
            Name   = "web-Windows-Auth"             
        } 

        xDscWebService PSDSCPullServer
        {
            Ensure                       = "Present"
            EndpointName                 = "PSDSCService"
            Port                         = 8080
            PhysicalPath                 = "$env:SystemDrive\inetpub\PullServer"
            CertificateThumbPrint        = $SSLCertThumbprint
            ModulePath                   = "$env:ProgramFiles\WindowsPowerShell\DscService\Modules"
            ConfigurationPath            = "$env:ProgramFiles\WindowsPowerShell\DscService\Configuration"
            State                        = "Started"
            DependsOn                    = "[WindowsFeature]DSCServiceFeature"
        }

        xDscWebService PSDSCComplianceServer
        {
            Ensure                       = "Present"
            EndpointName                 = "PSDSCCompliance"
            Port                         = 9080
            PhysicalPath                 = "$env:SystemDrive\inetpub\ComplianceServer"
            CertificateThumbPrint        = "AllowUnencryptedTraffic"
            State                        = "Started"
            IsComplianceServer           = $true
            DependsOn                    = @("[WindowsFeature]DSCServiceFeature","[WindowsFeature]WinAuth","[xDSCWebService]PSDSCPullServer")
        }

        WindowsFeature WebManagementTools
        {
            Ensure = "Present"
            Name = "Web-Mgmt-Console"
            DependsOn = "[xDSCWebService]PSDSCPullServer"
        }

        File RegistrationKeyFile
        {
            Ensure           ='Present'
            Type             = 'File'
            DestinationPath  = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
            Contents         = '********-****-****-****-************'
        }
    }
}


$SSLThumbprint = "****"
              
V2PullServer -SSLCertThumbprint $SSLThumbprint
Start-DscConfiguration -wait -verbose .\V2PullServer -force

Ill run this on a full install as suggested.

[silent-steel]

HI Justin,

Couple of notes:

1. You dont need

Import-DscResource -ModuleName xWebAdministration

theres no usage to this module

2. The removal of PSDSCComplianceServer is well documented, weird you didnt find it.

https://msdn.microsoft.com/en-us/powershell/dsc/pullserver
or
https://msdn.microsoft.com/en-us/powershell/wmf/dsc_repository

should lead you to the new way to create a reporting site through the use of xPSDesiredStateConfiguration

3. As noted in a differnt reply on this forum, use the -ModuleVersion at the end of the import-module

4. Unless i misread, remember that using RegistrationKey method of node registration to the pull server, requires you to use the ConfigurationNames as in Jasons post, but note that your not limited to one value, its an array

5. Change WindowsFeature WebManagementTools dependency to the first features, and add a DependsOn for the File resource as the DSCService folder doesnt exist until the DSCServiceFeature is actually installed

[justin-king]

You’re right … the xwebadministration is an artifact from when I was making some IIS changes before, not strictly needed and I just forgot to cut that out.

As for compliance server being “well documented” we may have to agree to disagree there: you gave me two links and the word “compliance” appears exactly once across both documents. The part I find confusing is that “IsComplianceServer” still exists, yet isn’t actually called out in the sample script provided in the link.

Is it deprecated? Does it just default to $true which is why it’s not called out? can the compliance server exist on the same listening port as the rest of the pull services thus we should ignore the original DSC handbook that had it setup on a unique port? The original compliance server had problems unless windows auth was installed … is this still true?

We have very different definitions of “well documented” is what I’m getting at.

[silent-steel]

Hi,

If you read again, I didn’t state that the compliance server is well documented, just that the removal of it is. Tiny difference, yet sorry if I wasn’t clear on that.

On the first link, you would see that the creation of the compliance server does not existing any more. True it might be an “overlook” for the sake of a smaller example. In comes the second link, the ReportingWeb is the replacement for compliance sever. It’s a different website, as was the compliance server.
So yes it has been deprecated and I think there a either mva movie with Jeffery talking about it or a YouTube movie talking about the new things in v5 that states its being removed, been some time since I’ve seen it.

Your keen eye about the IsComplianceServer is in place as I’ve not seen any reference to why its still there in the LCM if its not needed. I suspect it was left there unintentionally, but maybe others can verify and comment about it.

The one thing I do know about the reporting site is that it has to be on the same node your pull server is as it relies on the same devices.mdb file and I believe win with is still needed iirc.

[justin-king]

Hmmm I wonder if me installing it is forcing the pull server to NOT function with configuration names …

… you may have cracked the case …

…Ill likely test this theory tonight.

[justin-king]

OK I"m following up to confirm:

Setting up a pullserver with “IsCompliance = $true” will break ConfigurationNames from working properly and essentially “lock” it to paying attention to COnfigurationID only.

I also had to install on server in “full” (no core) as Jason mentioned.

So thanks to tips from BOTH Jason and Arie as it took both tweaks to get my pull server working predictably.

EDIT: Below is the final sever pull configuration I had to use. Now lets see how the new reporting service json file looks …

Configuration V2PullServer
{
    param(
            [Parameter(Mandatory=$false)][string] $NodeName = $env:ComputerName,
            [Parameter(Mandatory=$true)][ValidateNotNullOrEmpty()][string] $SSLCertThumbprint
        )

    Import-DscResource -ModuleName xPsDesiredStateConfiguration

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

        WindowsFeature WinAuth 
        { 
            Ensure = "Present" 
            Name   = "web-Windows-Auth"             
        } 

        xDscWebService PSDSCPullServer
        {
            Ensure                       = "Present"
            EndpointName                 = "PSDSCService"
            Port                         = 8080
            PhysicalPath                 = "$env:SystemDrive\inetpub\PullServer"
            CertificateThumbPrint        = $SSLCertThumbprint
            ModulePath                   = "$env:ProgramFiles\WindowsPowerShell\DscService\Modules"
            ConfigurationPath            = "$env:ProgramFiles\WindowsPowerShell\DscService\Configuration"
            State                        = "Started"
            DependsOn                    = "[WindowsFeature]DSCServiceFeature"
        }

        WindowsFeature WebManagementTools
        {
            Ensure = "Present"
            Name = "Web-Mgmt-Console"
            DependsOn = "[xDSCWebService]PSDSCPullServer"
        }

        File RegistrationKeyFile
        {
            Ensure           ='Present'
            Type             = 'File'
            DestinationPath  = "$env:ProgramFiles\WindowsPowerShell\DscService\RegistrationKeys.txt"
            Contents         = '****'
        }
    }
}

[silent-steel]

Thanks for the update, should probably relay that info to MS on DSC Github so they will fix it.

Meh, you forgot to take note of 3rd and 5th points