Get best of the week

Which side are you on: Push and Pull in Desired State Configuration

We already described how to describe the configuration in Desired State Configuration (DSC) and disassembled the built-in Local Configuration Manager (LCM) agent to apply the configuration on the server. In the first part of the article, we walked step by step on the main features of the tool along with Evgeny Parfenov from DataLine .

Here we dive into the settings and features in the Push and Pull modes.



What we will tell:


  1. Differences between Push and Pull modes
  2. Push mode in detail
  3. Pull mode in detail

Differences between Push and Pull modes


In Push mode, we manually or by script start the process of applying changes to the server (locally or remotely). Local Configuration Manager (LCM) applies the configuration interactively.

In Pull mode, the scheduled LCM agent on the server compares its configuration with the configuration published in the shared configuration repository. If there are changes, the configuration is copied locally and applied.

The pros and cons of both modes of operation are quite obvious.
PushPull
+
  1. Cost. It does not require the installation of additional servers.
  2. Simple architecture. All configurations are stored locally in the form that is convenient for the administrator.
  3. Suitable for testing. Dsc
  4. DevOps Way. When deploying servers, it is very easy to automate and fits into the philosophy of Infrastructure as a Code.
  5. run-once .
  1. . .
  2. . DSC .
  3. Azure Automation State Configuration, Windows Server 2012R2+
–
  1. On-Premise c . , .
  1. , .
  2. On-Premise GPO, .
  3. — , .
Setting resources is also slightly different for different modes. As we remember, to use a resource, you need to install it locally and on the server.

In the case of using the Push mode, the administrator must first install all the necessary resources on the managed server and on the PC, from where the configuration will be submitted.

In Pull mode, the DSC agent on the managed server can independently install all the necessary resources from the Pull server; the administrator's task is to place them on the Pull server. However, we keep in mind that it is impossible to predict the application of the configuration in Pull mode, since the GPO is not a guaranteed delivery of settings.

Push mode in detail






The top- level process of writing and applying DSC configurations can be represented as follows: At the first stage ( Authoring ) we describe the configuration using any IDE that is convenient for us (Notepad, PowerShell ISE, Visual Studio Code and others). Upon completion, we compile the mof configuration files (the compilation process is described in our previous article ).

In the second stage ( Staging / Compilation ), we start applying the configuration from the compiled mof file using the Start-DSCConfiguration cmdlet . In the process, the management server transmits the LCM server .mof file, which must apply the configuration.
In this case, it is better to use the -Verbose switch . For complete control of the configuration process:

PS C:\windows\system32> Start-DscConfiguration -Path C:\EnvironmentVariable_Path\ -Wait -Verbose

# C 
VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' =
SendConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' =
root/Microsoft/Windows/DesiredStateConfiguration'.
VERBOSE: An LCM method call arrived from computer COMPUTER with user sid
S-1-5-21-SID.

#  
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]
VERBOSE: [COMPUTER]: LCM:  [ Start  Resource ]  [[Environment]CreatePathEnvironmentVariable]

#       (test)
VERBOSE: [COMPUTER]: LCM:  [ Start  Test     ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' does not exist.
VERBOSE: [COMPUTER]: LCM:  [ End    Test     ]  [[Environment]CreatePathEnvironmentVariable]  in 0.1320 seconds.
#      “Environment variable 'TestPathEnvironmentVariable' does not exist”

#       
VERBOSE: [COMPUTER]: LCM:  [ Start  Set      ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]:                            [[Environment]CreatePathEnvironmentVariable] Environment variable
'TestPathEnvironmentVariable' created with value 'TestValue'.
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]  [[Environment]CreatePathEnvironmentVariable]  in 0.0690 seconds.
VERBOSE: [COMPUTER]: LCM:  [ End    Resource ]  [[Environment]CreatePathEnvironmentVariable]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]
VERBOSE: [COMPUTER]: LCM:  [ End    Set      ]    in  2.1900 seconds.
#  

#  
VERBOSE: Operation 'Invoke CimMethod' complete.
VERBOSE: Time taken for configuration job to complete is 2.749 seconds

It can be seen that the engine checked the presence of the variable, did not find it and created a new one, according to the specified configuration:



In the third stage ( Execution ), the DSC agent LCM enters the game. It receives a mof file, checks it, places it in a folder $env:systemRoot/system32/configurationand launches a workflow of applying the configuration file:

  1. LCM receives, applies the configuration file. The file is renamed to pending.mof and placed in$env:systemRoot/system32/configuration
    • If the application of the configuration file fails, the pending.mof file remains, and LCM will try to apply it in the next cycle.
  2. If the current.mof file is already in the folder, then it is renamed to previous.mof
  3. If the application of the configuration file completes successfully, then LCM renames it to current.mof
  4. The current.mof file is copied to the backup.mof file

Graphically, the workflow can be represented as follows:



To manage different configuration files, there is the Remove-DSCConfigurationDocument cmdlet, which allows you to delete specific documents if this is necessary for some reason. However, nothing prevents us from removing them manually.

Pull mode in detail


Pull mode is more difficult to deploy and configure, but it greatly simplifies the process of managing servers that are connected to it.

The general scheme will look something like this:



Pull mode requires the deployment of a Pull server. In fact, it is a regular web server, which can give clients mof files and resources that may be required when applying configurations from mof files. The latter greatly simplifies the process of managing and configuring servers, since the task of delivering the necessary resources lies with the client. The Pull server at the same time acts as a repository \ resource repository.

Pull-server can provide access to resources and configuration files through two protocols:

  1. SMB. . DFS-R. , , . SMB , Kerberos.
  2. Http\https. . IIS.

Pull server installation can be done through the regular resources that the DSC development team offers. More details can be found here . Or use community-driven solutions: here or here .

The workflow for further work with the pull server is as follows:

  1. We configure clients (LCM) to work with a pull-server.
  2. We upload resource files to the pull server.
  3. We prepare client configuration files (writing and compilation) and files with checksums.
  4. Enjoy the result.

Configuring clients (LCM) to work with a pull server

To do this, use the following LocalConfigurationManager (v5) settings : Settings

block :

  • CertificateID - indicates the fingerprint of the certificate to protect logins / passwords transmitted in the configuration.
  • ConfigurationID - contains the client GUID. Only those configurations that contain its GUID in the configuration file name will be applied to the client. The setting is left for compatibility with older versions of the pull server. It is better to use the RegistrationKey setting.
  • RefreshMode - to work with Pull servers, specify Pull in this setting.

Block ConfigurationRepositoryWeb:

  • AllowUnsecureConnection - allow \ not allow connection without authentication.
  • CertificateID - indicates the fingerprint of the certificate on the client, which will be used in the process of mutual authentication with the server.
  • ConfigurationNames - an array of configuration names that will be applied to the client.
  • RegistrationKey - a secret generated on the server, which is used by the client to register on the server.
  • ServerURL - URL of the Pull server with configurations.

ResourceRepositoryWeb block :

  • AllowUnsecureConnection - allow \ not allow connection without authentication.
  • CertificateID - indicates the fingerprint of the certificate on the client, which will be used in the process of mutual authentication with the server.
  • RegistrationKey - a secret generated on the server, which is used by the client to register on the server.
  • ServerURL - URL of the Pull server with resources.

ReportServerWeb block :

  • AllowUnsecureConnection - allow \ not allow connection without authentication.
  • CertificateID - indicates the fingerprint of the certificate on the client, which will be used in the process of mutual authentication with the server.
  • RegistrationKey - a secret generated on the server, which is used by the client to register on the server.
  • ServerURL - URL of the Pull server with reports.

Uploading resource files to the Pull server

After applying the new settings on LCM, which will teach him how to use the Pull server, you can upload resource files to the server . Resources are uploaded to the server in the form of zip files (the folder with the resource is packaged in zip). Rule for naming such a file:

{ModuleName}_{Version}.zip

The default file location $env:PROGRAMFILES\WindowsPowerShell\DscService\Modules. When installing the Pull server, this folder can be overridden. In addition to the file with the resource folder packed in zip, you must also place the file with the checksum of this packed resource in the same place. For example, like this:

New-DscChecksum -Path .\xPSDesiredStateConfiguration_8.4.4.0.zip

Placing client configuration files on the Pull server

It is important to note here that we can use two client operation modes in this case (actually two and a half): the client from the server will receive the configuration using ConfigurationID , or the client will use the configuration name - ConfigurationName . If it is necessary to apply several configurations, then all of them can be specified in the ConfigurationName, but you will have to configure LCM to work with partial configurations.

When using ConfigurationID, it must be emphasized that the mof configuration file that will be applied to the client will contain a GUID (it is contained in the ConfigurationID). In the case of using ConfigurationName, the mof-file will contain the configuration name, which we will specify in ConfigurationName. In both cases, in addition to the mof file, the configuration checksum file will also be placed there:

New-DscChecksum -Path '.\' -Force

In conclusion


We looked at two ways to apply changes to the server in Push and Pull modes. We went over the features of use and tried to explain all the nuances that may arise when working with these modes in DSC. If you still have questions - let's discuss in the comments. And if you didn’t have enough visibility, come to our online meeting on May 28: we’ll analyze the systems of unified communications and communication facilities (setting up uploading Exchange logs in Elastic, Microsoft Endpoint Manager for managing iOS, Android and Windows 10) and talk in more detail about the limits of applicability PowerShell Desired State Configuration. You only need to register .

More articles:


All Articles