In this post I’m going to highlight a few issues I came across configuring a Desired State Configuration pull server.
Certificates
For security reasons it is recommended to use HTTPS for your pull server. Since I was doing it in a lab I used a self signed certificate for testing but for production you should be using proper certificates. Turns out Active Directory Certificate Services is a convenient way to manage it inside you organisation, I’ll do a post about it later on. The self signed certificate I created in IIS won’t be trusted but this is not usually a problem when testing a web app since you can tell the browser to load the page anyway but for service calls you can’t do that. You have to import the certificate into the Trusted Root Authority of the Local Computer certificate store.
After I created my pull server I wanted to test the URL by browsing to it. This was on a 2012R2 server with IE11 but it kept on showing “Page cannot be displayed” even after I added the URL to trusted sites and clicked on continue anyway when prompted about the invalid certificate. In the end I switched to Chrome and I was able to confirm the service URL was responding.
Creating The Pull Server
You can configure a pull server manually by creating the website and app in IIS but I found the xPSDesiredStateConfiguration module way easier to use. The documentation does a good job of explaining the procedure but I want to emphasise you have to store the certificate you are using in the ‘CERT:\LocalMachine\My’ location even if you have it imported into Trusted Root Authority already.
Configure LCM For Pull
There are quite a few settings you can configure on your LCM, I found this reference very handy. After you create the LCM configuration and generate a meta MOF file you can configure the LCM by calling Set-DscLocalConfigurationManager. To confirm the current LCM status on a machine you can use Get-DscLocalConfigurationManager.
Pull DSC Configurations
In your pull server configuration you will see a ConfigurationPath setting specifying where you store your NamedConfig.MOF configuration files and a ModulePath setting specifying where you can store any extra Modules required by your configurations. One thing that caught me out was the nodename in a named configuration file must be the same as the configuration which is also the named configuration specified in the LCM config.
After you create or update a configuration you have to create a new checksum for it using the New-DscChecksum command. By default it doesn’t overwrite existing checksum files even if the configuration MOF has hanged, you have to specify -Force to overwrite the existing checksum files.
You can force a machine to update its configuration from the pull server by calling Update-DscConfiguration, instead of waiting the default 30 minutes.
Troubleshoot Configurations
To see what is happening with the applied configurations use Get-DscConfigurationStatus to see the latest one or add the -All flag to see all of them.
You can find the DSC event logs at Applications And Service Logs ->
Microsoft -> Windows – Desired State Configuration but the Debug and Analytic logs will be disabled. To switch them on run:
wevtutil.exe set-log “Microsoft-Windows-Dsc/Debug” /q:true /e:true wevtutil.exe set-log “Microsoft-Windows-Dsc/Analytic” /q:true /e:true
And to show them in the event viewer select “Enable Show Analytic and Debug Logs” from view menu in the event viewer. Remember to switch them back off again if you are in production.
There is also a Diagnostics Helper module to make troubleshooting and tracing easier. The analytics and debug logs will have multiple entries per action, the helper will find the related entries and consolidate them.
Don’t forget about the IIS access logs for the Pull server to troubleshoot access problems.
