Configuring target computers to use a Desired State Configuration Pull Server is a simple process, but the concepts can be very confusing when you first get started. In this article, I will demonstrate how to configure a target computer for a Pull Server then deploy a simple configuration; but I want you to pay particular attention to the target computer's Pull configuration and how this ties into the configuration stored on the Pull...
Server. The concept is unfamiliar for many IT pros and it is easy to make mistakes.
If you have been following along with the previous articles, use your test VMs to try it yourself.
Configuring the target computers for a Pull Server
Desired State Configuration (DSC) is designed to configure more than meets the eye. While I am focusing on Windows servers, I want to point out that the targets could easily be Linux servers, Windows clients, supported switches and more. This means that a DSC target might not be a member of an Active Directory domain. The moral of the story is that we can't issue a Group Policy to tell a target which Pull Server to use and what configuration file it should pull for its local desired state.
Instead, we solve this problem by ensuring every target contains a unique client piece of software that understands DSC. In our case, that's the Windows Management Framework 4 (WMF 4). Every target has a Local Configuration Manager (LCM) that can be set to get its configuration files from a specific Pull Server.
You can check the current settings of the LCM by using the
Focus on a few specific properties in the script above:
- ConfigurationID: This is currently blank, but will be replaced by the configuration identification that matches a configuration on the Pull Server. This is how the target downloads and applies the correct configuration.
- ConfigurationMode: Set to ApplyAndMonitor by default, this will apply a configuration. However, it will allow drift -- or someone to make changes to the configuration. This setting is often changed to ApplyAndAutoCorrect to prevent another administrator from making changes.
- RefreshMode: Currently set to PUSH, the target computer is waiting for us to push a configuration rather than attempting to pull one from a Pull Server. We will push a new LCM configuration that will change this to PULL and specify the HTTP(S) Pull Server URL.
There are other important settings, but this is enough to get started.
I need to push an LCM configuration to change the properties so that the target will start pulling new configurations from a Pull Server.
Lines 3 through 11 set up two very important mandatory parameters for the configuration to run properly. The first is $ComputerName, which specifies the target computers that should have their LCM configured by this script. The second is $guid. This will be assigned to the ConfigurationID in line 20. This defines which configuration file will be pulled from the Pull Server. The configuration Microsoft Operations Framework (MOF) file on the Pull Server must be named with the same global unique identifier (GUID) as the target. I know this sounds strange, but I will demonstrate why it is necessary.
There is a lot happening in the Node section of the script, but a few lines to highlight include the following:
- Line 6 sets the ConfigurationMode to ApplyAndAutoCorrect. As I mentioned earlier, this will prevent another admin from changing the pulled configuration later.
- Line 21 sets the RefreshMode to Pull so the LCM will start contacting the Pull Server for future configurations.
- Line 22 sets the type of pull mode that the target should use. In this case, WebDownloadManager for an HTTP(S) Pull Server.
- Line 23 through 25 sets the location URL of the Pull Server.
To run this configuration, I have some additional lines in the script. These will fill in the mandatory parameters and configure the target LCM for the Pull Server.
- Line 31 sets the list of target computers to receive the new LCM configuration. In this case, I'm using one of my test VMs named S1, but this could be a list of computers.
- Line 34 generates a GUID for the ConfigurationID. Remember, this long number will need to be the name of the configuration file on the Pull Server.
- Line 40 executes the
Setcmdlet for the target computer's LCM. All target computers will be configured for the Pull Server using the GUID specified.
After you run this script, check the Get-DSCLocalConfigurationManager on one of your target computers to verify the changes.
Creating a Desired State Configuration for the target computers
I'm going to create a very simple configuration for the target computers that is more about demonstrating the process than the actual configuration. The only thing the configuration file will do is install the Windows backup software. The configuration file, called 3.WindowsBackup.ps1.txt, is available as a download. I'm not going to go through the script in detail, because there are other resources that explain the components of this type of script. Once you run the script, you will have a folder called WindowsBackup with a file named S1.mof. We need to make some changes for the target computers to pull this configuration.
Naming and placing the configuration file
The following is a simple script that I use to rename the configuration file and put it in its correct location on the Pull Server. This script, called 4.UploadHTTPConfiguration.ps1.txt, is also available as a download.
- Line 3 and 4 get the target computer's GUID. I will then rename the S1.mof to that GUID number. The GUID connects the configuration on the Pull Server to the target computers.
- Line 8 grabs my local configuration MOF file.
- Line 9 sets the location for the new configuration file on the Pull Server and renames the file using the GUID. Notice in the example that my Pull Server name is DC.
- Line 10 performs the copy process.
- Line 13 generates a checksum on the new $GUID.mof file. This checksum is required. You will need to generate a new checksum if you make any changes to the configuration file.
Under the path of the Pull Server, C:\Program Files\WindowsPowerShell\DSCService\Configuration, you will notice my new configuration for the target servers.
Now you have the choice of either waiting 30 minutes for the target server to contact the Pull Server and execute the configuration or manually forcing the target server to contact the Pull Server with the following script:
Try it for yourself
Download a text file containing the example configuration used in this article. (3.WindowsBackup.ps1.txt)
Download a text file containing code used to rename the configuration file and put it in its correct location on the Pull Server. (4.UploadHTTPConfiguration.ps1.txt)
Notice the back tick characters at the end of the
Invoke-CimMethod cmdlet. This is all one line, but I broke it up so you could read it better. This forces the target computer's LCM to perform its required configuration checks.
Within a minute, you can check the target servers and the Windows Backup software should be installed. Go ahead and try to remove the software. You won't be able to.
The first few times you try the process described in this article, it can seem very confusing, but revert your VMs and try it again.
From here, you can start building your own configurations. In the next article, I'll discuss how to work with additional DSC resources.
Dig deeper on Microsoft Hyper-V management