Author Posts

November 20, 2014 at 8:02 am

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 🙂

November 20, 2014 at 9:35 am

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.

November 20, 2014 at 10:23 am

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.

November 20, 2014 at 11:01 am

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.

November 20, 2014 at 11:07 am

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.