Deploying Referenced Modules from Pull Server

I’m still somewhat a newby and trying to get my first Pull server working properly. The basic idea is to develop a module that will install our company’s product (a web-app with multiple databases and config files to be updated).

I have got as far as creating a DSC resource that runs well standalone (that is, the server pushes to itself) or in Push mode. The basic flow is 1) copy zip file; 2) unzip zip file; 3) set permissions for specific folders. I’m sure I’ll be modifying it in detail in the coming weeks, but getting these basics down is very important in setting the fundamentals for the rest of the steps.

The resource relies on the Carbon-Permissions module in order to set permissions, and obviously that works well in Push mode when I have already installed the module. However, when a client without the resources tries to pull the module from the pull server, I get the following error (via the Pull Client’s event log):
Error Message: Cannot find module Carbon_2.1.1 from the server http://tpz-dsc-pkg.topaz-dsc.private:8080/PSDSCPullServer.svc//Module(ConfigurationId=‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx’,ModuleName=‘Carbon’,ModuleVersion=‘2.1.1’)/ModuleContent.
Message ID: WebDownloadManagerModuleNotFound,Microsoft.PowerShell.DesiredStateConfiguration.Commands.GetDscModuleCommand
The Pull Server’s web.config clearly points to the Program Files location for Modules:

  [appSettings]
    [add key="MaxConcurrentRequests" value="10000" /]
    [add key="MaxRequestsPerTimeslot" value="10000" /]
    [add key="TimeslotSize" value="1" /]
    [add key="dbprovider" value="ESENT" /]
    [add key="dbconnectionstr" value="C:\Program Files\WindowsPowerShell\DscService\Devices.edb" /]
    [add key="ConfigurationPath" value="C:\Program Files\WindowsPowerShell\DscService\Configuration" /]
    [add key="ModulePath" value="C:\Program Files\WindowsPowerShell\DscService\Modules" /]
    [add key="RegistrationKeyPath" value="C:\Program Files\WindowsPowerShell\DscService" /]
  [/appSettings]

I have made sure that the module (both in .zip file format as well as trying to copy the 2.1.1 version in a custom-configuration deployment format) is available in the C:\Program Files\WindowsPowerShell\DscService\Modules folder, with contents as follows:
Carbon-2.1.1
…DscResources
…Carbon_Permission
…Carbon_+Permission.psm1
…Carbon_Permission.schema.mof
…Carbon.pds1
…Carbon.psm1
…Carbon.types.ps1xml
…Import-Carbon.ps1
…Carbon-2.1.1.zip
…Carbon-2.2.0.zip
(I know that’s a long-winded way of trying to show the folder structure. If there are any tips for this, I’d appreciate it :slight_smile: )

So, after a couple of hours of searching and reading blogs, book chapters and the like, I’m at a loss for trying to find out why I can’t deploy this resource, or at least how to stage it to ensure that it gets deployed.

Any ideas? (btw, if one is to configure PowerShell Gallery or Chocolatey as a default download site, that’s a possibility, but we are going to have customers who will be reluctant to opening their firewalls to downloading anything, so if we can serve up all that we need, that would be great).

I have found the article How to Deploy and Discover Windows PowerShell Desired State Configuration Resources in the PowerShell Blog.

Looks promising, although it seems to have been written for PowerShell 4. I will update with results (I only get to work on this in fits and starts).

Can you check if you have Carbon-2.1.1.zip.checksum file also available in the same folder?
Best way to diagnose is to look for the errors reported on the Pull Server in Odata and DSC pull server logs.
Get-WinEvent -LogName “Microsoft-Windows-Powershell-DesiredStateConfiguration-PullServer/Operational”
Get-WinEvent -LogName “Microsoft-Windows-ManagementOdataService/Operational”

After reading through the above-referenced article, I changed my Pull Server’s “C:\Program Files\WindowsPowerShell\DscService\Modules” folder to only contain the following:

  • Carbon_2.1.1.zip
  • Carbon_2.1.1.zip.checksum.

Note that I renamed the zip file from Carbon-2.1.1.zip. Don’t know if it made a difference but that seemed to be the naming convention.

I am using the Event Viewer to view the DSC Logs, and now I get the following error on the Client attempting to use the Pull Server (this is different from the original error I reported):
Job {F4798D66-37F1-11E6-80CC-000D3A128BE7} :
This event indicates that failure happens when LCM is trying to get the configuration from pull server using download manager NULL. ErrorId is 0x1. ErrorDetail is The PowerShell DSC resource C:\Program Files\WindowsPowerShell\Modules\Carbon\2.1.1\DscResources\Carbon_Permission does not contain the corresponding MOF file C:\Program Files\WindowsPowerShell\Modules\Carbon\2.1.1\DscResources\Carbon_Permission\Carbon_Permission.schema.mof.

On the Pull Server, the “C:\Program Files\WindowsPowerShell\Modules\Carbon\2.1.1\DscResources\Carbon_Permission” does contain the Carbon_Permission.schema.mof file.

It is interesting to note that the error does not reference the “C:\Program Files\WindowsPowerShell\DscService\Modules” folder, but seems to be looking for the file in the Windows Powershell folder.

On the Pull Server, the ManagmentOdataService/Operational log did not show any errors.
The DesiredStateConfiguration-PullServer/Operation log had the following items of interest (from command Get-WinEvent -LogName “Microsoft-Windows-Powershell-DesiredStateConfiguration-PullServer/Operational” | Format-Table -
Property Message -Wrap) :

  • Module repository C:\Program Files\WindowsPowerShell\DscService\Modules is not found.
  • The client with raw URL /PSDSCPullServer.svc/Module(ConfigurationId=‘246f7467-a596-408a-8bba-bb37c9789551’,ModuleName=‘Carbon’,ModuleVersion=‘2.1.1’)/ModuleContent specified ProtocolVersion = 2.0 in the Http Request header.
    Get operation processsed for 246f7467-a596-408a-8bba-bb37c9789551.
    Returning module Carbon.

Those folders exist and I have verified that even “Users” have Read permissions, so there should be no reason that I can see that it cannot find them.

From pull server logs, pull server didn’t report any error.
Can you extract the zip file from pull server (C:\Program Files\WindowsPowerShell\DscService\Modules\Carbon_2.1.1.zip" and verify that the zip file contains Carbon\2.1.1\DscResources\Carbon_Permission\Carbon_Permission.schema.mof. This seems odd that pull client was able to download and install the module but failed to discover the schema.

Nitin - thank you for your continued time and attention. Hopefully you’re getting something out of this too (other than my immense gratitude and the satisfaction of helping someone else, that is).

The path in the zip file is as follows (notice that it is missing the “2.1.1” folder:
Carbon\DscResources\Carbon_Permission\

It contains both Carbon_Permission.psm1 & Carbon_Permission.schema.mof.

So, following your hint, I checked the installed path on the Pull Server, which is this:
C:\Program Files\WindowsPowerShell\Modules\Carbon\2.1.1\DscResources\Carbon_Permission

Comparing the two, notice that the installed version has the path “…Carbon\2.1.1\DscResources…” whereas the zip file skips the .2.1.1\ folder. Also, I double checked the error message on the Pull Client, and it does indicate that it is looking for the “2.1.1” folder.

To test this, I extracted the archive, added in a 2.1.1 folder to make it look like the installed version, re-zipped and recreated the checksum.

Unfortunately, the test was not successful and I continue to get the same error from the Pull client:
ErrorMessage">The PowerShell DSC resource C:\Program Files\WindowsPowerShell\Modules\Carbon\2.1.1
\DscResources\Carbon_Permission does not contain the corresponding MOF file C:\Program
Files\WindowsPowerShell\Modules\Carbon\2.1.1\DscResources\Carbon_Permission\Carbon_Permission.schema.mof

The “Carbon” folder is getting created on the Pull Client in “C:\Program Files\WindowsPowerShell\Modules” but nothing else. Could something be wrong with the .zip file or the extraction mechanism? (I used the original zip file from Carbon, downloaded from bitlocker. I created my modified zip file using 7Zip, as I have read that there have been issues with using the built in Windows archiver).

Out of time on this for now, but will come back to plug away some more in a few hours. I’m encouraged that we’ve moved from not finding the module to not being able to extract/install it. That’s something.

It could be something to do with how the Zip file was created. Can you use the cmdlets from xPsDesiredStateConfiguration module to create zip of the modules.

install-module xpsdesiredstateconfiguration
import-module 'C:\Program Files\windowspowershell\modules\xPSDesiredStateConfiguration\3.10.0.0\DSCPullServerSetup\PublishModulesAndMofsToPullServer.psm1'
Publish-ModuleToPullServer -Name xPsdesiredStateConfiguration -OutputFolderPath E:\Temp\ -ModuleBase 'C:\Program Files\windowspowershell\modules\xPSDesiredStateConfiguration' -Version 3.10.0.0

That is the closest we have been - it is now pulling and unzipping the package. I had tried using other compression alternatives, such as Windows, 7zip & WinRAR, but seemingly the engine it wants to use to unzip is the best to zip it up with in the first place. Unfortunately, the directory structure it is creating is incorrect (…\Carbon\2.1.1\2.1.1.…), but it is now definitely something that I can work with.

I’ll update further once I’ve had a chance to try a few scenarios (basically different packaging options).

So, I finally had a chance to finish this up, and we have SUCCESS!
Using Publish-ModuleToPullServer, you have to make sure that the ModuleBase path DOES NOT have a version folder. So pointing the ModuleBase to my original Carbon installation was incorrect, as it has a version folder in it: C:\Program Files\WindowsPowerShell\Modules\Carbon\2.1.1.

To correct, I used the version download from Carbon itself, extracted it and repackaged it using Publish-ModuleToPullServer. This created a proper zip file that extracted nicely and installed the module. PowerShell recognizes the module, so that must be it.

Thank you again for your input. What I’m not sure of is whether or not the behavior of Publish-ModuleToPullServer is a defect.