Pull server multiple module paths?

This topic contains 5 replies, has 3 voices, and was last updated by  Ryan Young 3 years, 4 months ago.

  • Author
  • #20706

    Ryan Young

    Hey guys, I'm trying to add more "module paths" to my DSC Pull server. This is so that I can have other admins modify our "in house stuffs" in a folder that's not in programfiles. It'll let me make that logical split between stuff that is built-in/local to the DSCPull, and for the targets.

    Here's the config, I'm not sure what I'm doing wrong:

            xDscWebService PSDSCPullServer
    Ensure                  = “Present”
    EndpointName            = “PSDSCPullServer”
    Port                    = 8080
    PhysicalPath            = “$env:SystemDrive\inetpub\wwwroot\PSDSCPullServer”
    CertificateThumbPrint   = “AllowUnencryptedTraffic”
    ModulePath              = “$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules;$env:SystemDrive\CieCustomDSC\Modules”
    ConfigurationPath       = “$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration;$env:SystemDrive\CieCustomDSC\Configuration”
    State                   = “Started”
    DependsOn               = “[WindowsFeature]DSCServiceFeature”

    Powershell throws me this error when I try and run start-dscconfig:

    The PowerShell provider MSFT_xDSCWebService threw one or more non-terminating errors while running the Set-TargetResource functionality. These errors 
    are logged to the ETW channel called Microsoft-Windows-DSC/Operational. Refer to this channel for more details.
        + CategoryInfo          : InvalidOperation: (:) [], CimException
        + FullyQualifiedErrorId : NonTerminatingErrorFromProvider
        + PSComputerName        : dyul1dsc001.cie.caesarsint.com

    Thanks 🙂

  • #20710

    Don Jones

    You only get one path for the pull server's ModulePath.

    But I think there might be some confusion about what this path does. This isn't the PSModulePath that PowerShell uses to find modules; the Pull Server's path is where **zipped-up modules live so that target nodes can download them**. You'd never include your Program Files path in that, because those modules aren't in the correct form (a zip file) for pull clients to download.

  • #20714

    Ryan Young

    Hmm yeah I was wondering about that. I grabbed that from someone with a guide on the net and didn't think twice about that detail. Is it acceptable to use a UNC path to a fileshare for this or is it best practice to keep the modules locally on the pull server?

    The confusion on my part sort of strings from the fact that I'm looking into creating composite resources, I found Steve's script to create the function New-DscCompositeResource, and I'm trying to makeup a process that other less involved techs can use to deploy configurations to servers. I want them kind of staying out of program files and working more in a structure that is "in house" on a folder I created on the systemdrive.

  • #20717

    Don Jones

    Local is better.

  • #20719

    Dave Wyatt

    If you're using DSC, you don't have to worry about that. The local configuration manager will download modules from the pull server and place them in the default location of \WindowsPowerShell\Modules .

    If you're talking about deploying modules for use other than DSC, that's different. While you technically _can_ use a network location for that, I wouldn't recommend it. It can cause big performance penalties for tab completion if you have module auto-loading enabled.

  • #20721

    Ryan Young

    I gotcha. There's talk about putting multiple DSC pull servers, one for each environment, rather than doing things centrally with one. Hence why I'm trying to write out a process that simplifies things and having the pull server use a network share could have 'centralized' sources a bit for things like modules. But point is definitely well taken that there can be a network toll for doing this, I'll work around it.

You must be logged in to reply to this topic.