Issue with configuration name received into PS5 handler

[majst32]

I'm using the most current version on the nuget feed - 0.5.1.54. When I have the tug server running, I update my target node's LCM with the pull server information, and a configuration name of "testConfig1" similar to the LCM registration in the samples. The LCM registers successfully, but when I look at the debug messages on Tug or the json that was saved from the registration, the ConfigurationNames setting is "Null".

I tried to deploy a config also, and I find the same occurring on that action (the configurationName is Null, so it doesn't do anything.). The messages are: 2017-01-25 19:48:45.2681|0|TRACE|Tug.Server.Providers.Ps5DscHandler|Resolved requested configuration name as [] 2017-01-25 19:48:45.3150|0|WARN|Tug.Server.Providers.Ps5DscHandler|No configuration name specified for agent [3c4ea76d-e182-11e6-8748-00155d7cc820]

Also, Tug doesn't return an error in this case - I get a message from the LCM saying "Updated configuration not found on pull server so no action taken", but no error.

[ebekker]

@majst32, can you share your LCM config script (redacted with anything sensitive)?

[majst32]

[DSCLocalConfigurationManager()]

Configuration LCM_Pull {

Node localhost {

    Settings {
        ConfigurationMode = 'ApplyAndAutoCorrect'
        RefreshMode = 'Pull'
        }

    ConfigurationRepositoryWeb Configs {
        ServerURL = 'http://tug:5000'
        AllowUnsecureConnection = $True
        RegistrationKey = '2ca7e87a-ac77-4b9a-9ddd-e19bffd75d8b'
        ConfigurationNames = @("TimeZoneConfig")
        }

    ResourceRepositoryWeb Modules {
        ServerURL = 'http://tug:5000'
        AllowUnsecureConnection = $True
        RegistrationKey = '2ca7e87a-ac77-4b9a-9ddd-e19bffd75d8b'
        }
}

} LCM_Pull

[majst32]

Also:

get-DSCLocalConfigurationManager | Select-Object -expandproperty ConfigurationDownloadManagers

Returns: ResourceId : [ConfigurationRepositoryWeb]Configs SourceInfo : C:\Users\administrator\Documents\LCM_Pull.ps1::12::9::ConfigurationRepositoryWeb AllowUnsecureConnection : True CertificateID : ConfigurationNames : {TimeZoneConfig} RegistrationKey : ServerURL : http://tug:5000 PSComputerName :

[ebekker]

What version of Windows is this run on? Also what version of PS?

[majst32]

The target node is Server 2016, PS 5.1.

[concentrateddon]

@majst32 run a Wireshark trace, if you can. If you look at "v2 node was given new config to pull - it was pulled applied and reported - no module download.pcapng" in the References folder here, go to packet 14. If you look at the JSON object, you should see a "ConfigurationNames" key. That should be an array of one item. If you can validate that the LCM is sending it the same way in your scenario, then its ight be easier for @ebekker to validate that ASP.NET is intercepting the information correctly.

[majst32]

It appears to me to be the same. I added the wireshark trace from my target server to Tug, "Issue 58 Registration with Tug Server", packet 23 shows "Configuration Names": ["TimeZoneConfig"]. However, I notice now that I have some trace messages in the Tug server that say the Config name is TimeZoneConfig, and others say the config name is Null. It almost looks like it's registering it twice, but the first is TimeZoneConfig and the second is Null... then I look at the JSON saved by the registration and it says Null. I'm adding "Issue 58 Tug Server Log.txt" to the references folder.

[concentrateddon]

Definitely appears to be a hiccup somewhere in the ASP.NET code. The data is definitely in the first chunk of JSON in the log. The it runs Register-TugNode, writes the JSON to disk, and the JSON is then missing that information.

[ebekker]

OK, figured out the issue -- it's because the LCM is configured with individual ConfigurationRepositoryWeb and ResourceRepositoryWeb settings -- in all of my testing, I only used the former, which defaulted to using the server settings for both Config and Resource endpoint. But when you configure individual config and resource server endpoints, the LCM registers with the server twice (as it should), because it may be communicating with completely different servers.

Anyway, when the LCM registers with the resource server, it doesn't send a Config name, which make sense since the resource server doesn't need to care about that, but Tug is just looking at the message and is not discriminating between a config server registration and a resource server registration and simply does an update of its local registration info, which means it wipes out the config name.

[ebekker]

And of course when you define a ReportServerWeb settings block, you get 3 separate LCM registration messages.

[ebekker]

I believe this issue has been addressed. You can upgrade to the latest version from the prerelease feed and give it a try. Please note, I've moved and updated the instructions for installing/upgrading from the prerelease NuGet feed to a wiki page.

If you follow the directions for upgrading, you should be able to get the latest changes (please let me know if the directions are incorrect or unclear in the wiki page).

HOWEVER, because the fix is actually in the PS Cmdlets script, you won't automatically get the fix after the update. The updated script will be deployed to a samples sub-directory, and you can pull in the changes from there to your running BasicTugCmdlets.ps1 script.