Author Posts

May 19, 2014 at 11:55 am

When the LCM checks the pull server to see if its configuration has changed, how does it do this?

Does it simply compare the checksum of its current configuration with the checksum on the pull server, and if different download and apply the updated configuration (uniquely identified by a GUID)?

Thanks...

May 19, 2014 at 12:02 pm

Yup. So if you don't generate a new checksum, it won't work. Plus, the checksum is used for an integrity check after the config is pulled.

May 19, 2014 at 5:15 pm

What Don said. I don't even want to admit how long it took me to figure that out when I started learning DSC. If there is a file on a Pull server, whether it's a Configuration .MOF or a Resource .ZIP file, if any changes whatsoever are made, you need a new Checksum or the changes will be ignored.

May 20, 2014 at 4:43 am

Thanks to all...

May 22, 2014 at 6:58 am

I updated a resource module .zip file and its associated .zip.checksum file on the pull server, but I didn't update its version number. The LCM on the client machine I am testing with isn't pulling down the updated resource, so applying a updated configuration, that depends on a new custom resource contained in the updated resource module, is failing.

So while the updated configuration was pulled because of the checksum change, the updated resource is not getting pulled even though its checksum has changed. Should it?

I have "AllowModuleOverwrite=True".

May 22, 2014 at 7:00 am

You've specified the required version of the resource module in the config?

May 22, 2014 at 7:22 am

The version number in the .zip file needs to match what is in the .psd1 file . As an example, if my Module is named xComputerManagement_1.2.zip, the ModuleVersion specified in xComputerManagement.psd1 also needs to be 1.2, otherwise it doesn't work (at least in my experience).

May 22, 2014 at 7:28 am

The module .zip file is "FMGlobalDSCResources_1.0_1.0.zip", and ModuleVersion="1.0" in the FMGlobalDSCResources_1.0.psd1 file.

I have included a version number in the name of the module containing my custom DSC resources so I can have more than one version of a module installed on a machine. This is why the .zip file has "_1.0_1.0" in the name.

May 22, 2014 at 8:31 am

I don't think that is going to work. If you rename FMGLobalDSCResources_1.0_1.0.zip to FMGlobalDSCResources_1.0.zip does it work? If you want to have more than one version of a module on a machine (which is a reasonable thing to want), why wouldn't you just name the next version of FMGlobalDSCResources to _1.1 instead of _1.0_1.0 ?

May 22, 2014 at 8:41 am

The module name is FMGlobalDSCResources_1.0, so the .zip file needs to be named FMGlobalDSCResources_1.0_1.0.zip. When it is, it successfully got pulled down the first time. When the file was named FMGlobalDSCResources_1.0.zip, it failed to be pulled.

What doesn't seem to work is updating the same .zip file as well as its checksum. Based on what the LCM writes to the event log on the client server doing the Pulling, it states it already has the resource, so doesn't appear it checks the checksum file to see if the zipped up resource module has changed.

May 23, 2014 at 4:48 am

Ok, that makes sense then. I am out of ideas at this point without being able to see everything for myself. I will keep thinking about it 🙂