So while it’s pretty well recorded that for DSC v4 the proper format for your zip file was modulename_version.zip, there’s surprisingly little clarifying the format in 5.0.
It clearly unzips uniquely to allow you to have multiple versions on a server (by adding version to the folder path), but I don’t see it mentioned anywhere if the format of the file needs to change (using AzureAutomation i drop the version and just zip the module name, for example).
Do we continue to follow the 4.0 model? Do we simply zip the modulename.zip now like I do with Azure automation? If the later is the answer, how do we make multiple versions available for pulling if we decide to leverage that feature in our configurations? Just bunch all the various versions into their own folder and zip them up together?
Hopefully an easy question … just I’ve found the “what’s new” documentation for WMF5 to be … poor. updating everything to 5.0 is a bit more of an overhaul than I expected.
Agree on that.
Even without AzureAutomation, for example my Pull server, has in the Modules folder a sub folder ResourceA and underneath 2 folders with versions 1.0 and 2.0 and i just use -ModuleVersion in all my scripts.
This is for MS modules that i download from github, so i suspect it would be the same for custom resources.
If you still have PS 4.0 infrastructure that depends on pull/push mechanics you have already implemented then id say you still have to use the 4.0 model. If youre just starting then i will go with the new model.
Say you have a resource in your pull server that was made for 4.0 thus conforming to the structure and naming, just create a new pull server for 5 RTM.
In either way you can not use more then one version of a resource in a single conffiguration.
https://msdn.microsoft.com/en-us/powershell/wmf/dsc_sxsresource
Arie H.
SO to be clear: I’m upgrading things to 5.0 preview in the QA lab to prepare for the RTM release (any day now). I’ve already pretty much documented:
- New Pull-Server needs to be built. the service has simply changed too much.
- Configurations need to be updated at least to include version information on the import-module statement. ISE complains about syntax errors if it sees multiple module versions without a specific version being specified, and composite configurations will not work at all
- New MOF files needs to be generated. 4.0 and 5.0 don’t line up 1:1, and just pointing your upgraded nodes at the same-old-mof won’t work right.
- modeul.zips need to be updated as well … I’m assuming.
- In order to leverage AgentID, the LCM needs to be re-registered. I can’t find any information to support the notion that I might be able to setup a meta.mof with pull information for the registration ID. So I still need to test that.
It’s that #4 I’m looking at. Luckily DSC makes building pull-servers a fast process, and I just need a little exploration around re-configuring the LCM on all the nodes (replacing our internal GUID database with the new AgentID model will be a little work but is doable), I’m just looking at the dscservice/modules directory now.
I’m assuming I need to rezip/checksum all those modules because everything else needed to be refreshed. Just looking for clarification as opposed to trial and error.
(basically the plan is simple enough: build a side-by-side pull servers and start swinging machines over as we update … once all nodes are checking into the new WMF5 pull server we will retire the old one).
Hi James,
1.As far as the docs I’ve read indicate, v4 pull servers can support v5 clients, as the LCM version is now 1.0,2.0. But a new pull server is what I started with, if only to remove the compliance website and open a new reporting website.
-
Yes. Also have to get used to not using Get-DscResource -ModuleName xSqlPS but rather Get-DscResource -Module @{ModuleName=‘xSqlPS’; RequiredVersion=‘1.0.0.0’} for specific version commands.
-
Yes you will, and there’s a very good example in the wmf 5\ps 5 docs on how to set the meta configuration for client to register to a pull server. Works very nice.
As for 4, as much as I like AgentID and the benefits of friendly name mof files and more, I wouldn’t discard of the GUIDs yet. At the moment afaik, using the registration key method doesn’t support partial configurations, you still need ConfiguratioID a.k.a. GUIDs.
Using AgentID does allow you to use new setting called ConfigurationNames, which as far as I understand it, is the equivalent of the PartialConfiguration, but I’m still in the process of testing that.
As I’m just about to start tests in my environment, I can’t yet comment on the zipping, but definitely new checksums as the content has changed.
Converting an existing GUID based system might actually require you to redesign your configurations to smaller parts, you can then use in ConfigurationNanes.
Take care,
Arie H.
Well partial configurations are evil … so I’m not worried about that 
rebuilding around AgentID is pretty easy for me … I wrote a function that updates friendly name configs to GUID name based on a relationship stored in a csv file, so I don['t have to change anything … just stop calling that function. Pretty easy actually.
That said, my initial testing has been a glorious failure. Stood up a new Pull server, and ran a new meta config to point one of my servers at it. It logs that it successfully registered it’s agentID with the pull server, but on the pull server itself, I can’t find any evidence that it worked. Furthermore the nodes themselves fail to pull anything, they just log error 4252 4131 every 30 minutes with no info. The actual details is just “NULL” so theres no hint on what’s actually going on :/.
Considering how easy 4.0 was to setup, I’m right now taken by surprise how much I’m struggling to get 5.0 working properly.
Hehe well I have to use partial configurations to some degree as different people/departments contribute, so im just wrapping what they write into a global workflow and trying to implement pester to test their code before adding it to the workflow.
I suspect the lack of pulling from the nodes relates to your other question in the forum. Youll have to use ConfigurationNames and have a matching mof name on the pull server.
My main problem with getting v5 to work was actually UrlScan that was installed on the webserver that had the PUT verb blocked initially so the nodes couldn’t register correctly with the pull server.