If you are planning to use PowerShell Desired State Configuration on a larger scale you need to take a step back and think about the design of your node configurations. In this post I will give you some hints how to approach this.
If you are using push mode for PowerShell Desired State Configuration you will be dearly missing that modules can be dynamically loaded when they are needed. The following example demonstrates how to deploy all resources from the current wave. It only uses resources contained in PowerShell 4.0.
In a previous post I described how to inject the meta as well as the node configuration. As it is, the Local Configuration Manager (LCM) does not create the scheduled tasks necessary to apply, monitor and correct the configuration. In this post I will explain how to make sure that LCM kicks off.
Many resources for Desired State Configuration require credentials to successfully execute the specified task. For example, if you are copying files or directories using the file resource, the Local Configuration Manager needs appropriate credentials to access the source location. This is a crucial requirements when the configuration is applied on a workgroup host and the source location is inaccessible by the system account. In this post, I will explain how to use credentials in the configuration.
When learning about DSC you will likely read dozens of articles and try to make sense of them. I will give you a head start and point you to the most helpful articles that I have used in the past.
In large environments, you will need to automate the meta configuration necessary to kick off the local configuration manager. Microsoft has published a lengthy article about injecting a meta as well as a node configuration into VMs and VHDs. I will present a such easier method fully integrated and supported by the LCM. This article only describes which location can be used to inject MOFs.
I have invested quite some time into learning about PowerShell Desired State Configuration (DSC). After reading many posts about DSC, I am still missing a comprehensive example that discusses working with configuration data. I will present two variants of the same example to demonstrate how parameters can be passed to a DSC configuration. In addition I will provide some thoughts about advantages and disadvantages of both methods. The content is closely related to separating configuration and environment data.
When you are using SQL Server Mirroring to implement high availability for the XenApp database, you may see that a site upgrade fails while moving from XenApp 7.5 to 7.6.
When you are tracing issues in Remote Desktop Services (RDS), you will have to look for events across several event logs. This makes it very hard to bring the individual events in the appropriate order to analyze the issue at hand.
When I started working with Desired State Configuration (DSC), I decided to use a pull server because I do not want to touch every machine. Configuring a pull server is a one time configuration identical on all machines. Unfortunately, I stumbled across a problem with my German locale which required fixing in the DSC module responsible for setting up the pull server in IIS.