DSC pull server registration key and WMF version

DSC
1

Hey all,

I’m finally getting around to creating a pull server, following the instructions here https://msdn.microsoft.com/en-us/powershell/dsc/pullserver, and under the “Registration Key” section it says "Note: Registration keys are not supported in PowerShell 4.0. "

This is a dumb question, but does that mean only the pull server needs WMF 5.0 or does it also mean that any nodes communicating with the pull servers also need WMF 5.0 to use the registration key?

Thanks!

2

You only need that key if the client is in Confihuration Names mode. If the client isn’t, then it can use a 4.0 pull server.

3

There are 2 ways for LCM to interact with the Pull Server. You can find more details about this here - https://github.com/PowerShell/PowerShell-Docs/blob/staging/dsc/pullClient.md

If you are using ConfigurationNames in the metaconfig, you need WMF 5.0
If you are using ConfigurationID in the metaconfig, WMF 4.0 should work . (Though you can use ConfigurationID in WMF 5.0 as well)

4

So if you have a WMF 5.0 Pull Server, do the managed nodes pulling from it need to be WMF 5.0 as well? Does this very by resource? What’s the compatibility matrix here between nodes and pull server?

Thanks!

5

If I understood the logic correctly its works well both ways.

You can have a WMF 4.0 Pull Server supplying configurations to a node that has WMF 5.0 installed.
That’s visible on the LCM of that node, you’ll see it supports v1.0 and v2.0.
Using this will enforce you to use only ConfigurationID as the means for the LCM to know what configuration to ask for.

I haven’t tried a WMF 5.0 pull server supplying configurations for a node that has WMF 4.0 installed
but since the LCM on that node will only support V1.0, id say it should work as long as the configurations you write
and the resources you work with support 4.0. One thing that would definitely not work in this scenario is the ReportingServer
and allowing Push mode nodes to report to it.

Naturally WMF 5.0 on Pull will work best with WMF 5.0 on nodes allowing you the choice between ConfigurationID
and ConfigurationNames+RegistrationKey.
That by itself isn’t a reason to upgrade to WMF 5.0, but doing so on the nodes allows MUCH greater PowerShell security
that should be the decisive factor in upgrading it on all nodes.

6

A good reason to upgrade to WMF 5.0 is the presence of Reporting. Reporting (introduced in WMF 5.0) gives a rich set of diagnostic data that helps in identifying issues when things go wrong. Reporting works with both Push and Pull mode.