Now that we have covered both how deployments work (push and pull) in DSC and the workflow (authoring, staging, and execution) for using DSC, we will talk about how the execution happens on a target node.
The LCM is the PowerShell DSC engine. It is the heart and soul of DSC. It runs on all target nodes and controls the execution of DSC configurations and resources, whether you are using a push or pull deployment model. It is a Windows service, but is part of the WMI service host, so there is no direct service named LCM for you to look at.
The LCM has a large range of settings that control everything from the scheduling of executions to how the LCM handles configuration drift. LCM settings are settable by DSC itself, although using a slightly different syntax. This allows the LCM settings to be deployed just like DSC configurations, in an automatable and repeatable manner.
These settings are applied separately from your DSC configurations, so you will have configuration files for your LCM and separate files for your DSC configurations. This separation means that LCM settings can be applied per server or on all servers, so not all your target nodes have to have the same settings. This is useful if some servers have to have a stricter scheduler and control over their drift, and others can be checked less often or be more relaxed in their drift.
Since the LCM settings are different from DSC settings but describe how DSC operates, they are considered DSC metadata. You will sometimes see them referred to as metadata instead of settings, because they describe the entirety of the process and not just LCM-specific operations. These pieces of information are stored in a separate MOF file than that which the DSC configuration block compiles to. These files are named with the NodeName field you gave them and appended with meta.mof as the file extension. Any time you configure the LCM, the *.meta.mof files will be generated.
Common settings that you will configure are listed in the following table. There are more settings available, but these are the ones that are most useful to know right away:?
The LCM comes with most of these settings set to logical defaults to allow DSC to operate out of the box. You can check what is currently set by issuing the following Get-DscLocalConfigurationManager Cmdlet:
PS C:Examples> Get-DscLocalConfigurationManager ActionAfterReboot : ContinueConfiguration AllowModuleOverwrite : False CertificateID : ConfigurationID : ConfigurationMode : ApplyAndMonitor ConfigurationModeFrequencyMins : 15 Credential : DebugMode : {NONE} DownloadManagerCustomData : DownloadManagerName : LCMCompatibleVersions : {1.0} LCMState : Idle LCMVersion : 1.0 RebootNodeIfNeeded : False RefreshFrequencyMins : 30 RefreshMode : PUSH PSComputerName :
An important setting to call out is the LCM ConfigurationMode setting. As stated earlier, this setting controls how DSC applies the configuration to the target node. There are three available settings: ApplyOnly, ApplyAndMonitor, and ApplyAndAutoCorrect. These settings will allow you to control how the LCM behaves and when it operates. This controls the actions taken when applying the configuration as well as how it handles drift occurring on the target node.
When the ApplyOnly mode is set, DSC will apply the configuration and do nothing further unless a new configuration is deployed to the target node. Note that this is a completely new configuration, not a refresh of the currently applied configuration. If the target node's configuration drifts or changes, no action will be taken by DSC. This is useful for a one-time configuration of a target node, or cases where it is expected that a new configuration will be pushed at a later point, but some initial setup needs to be done now. This is not a commonly used setting.
When the ApplyAndMonitor mode is set, DSC behaves exactly like ApplyOnly, except after the deployment DSC will monitor the current state for configuration drift. This is the default setting for all DSC agents. It will report back any drift to the DSC logs or Pull Server, but will not act to rectify the drift. This is useful when you want to control when change happens on your servers, but reduces the autonomy DSC can have to correct changes in your infrastructure.
When the ApplyAndAutoCorrect mode is set, DSC will apply the configuration to the target node and continue to monitor for configuration drift. If any drift is detected, it will be logged and the configuration will be reapplied to the target node to bring it back into compliance. This gives DSC the greatest autonomy to ensure your environment is valid and act on any changes that may occur, without your direct input. This is great for fully locked down environments where variance is not allowed, but must also be corrected on the next scheduled run and without fail.
While the ConfigurationMode mode determines how DSC behaves with regard to configuration drift, the RefreshMode setting determines how DSC gets the configuration information. At the beginning of this chapter, we covered the push and pull deployment models, and this setting allows you to change which model the target node uses.
By default, all installs are set to the push RefreshMode, which makes sense when you want DSC to work out of the box. Setting it to the pull RefreshMode allows the LCM to work with a central Pull Server.
Configuring the LCM is done by authoring an LCM configuration block with the desired settings specified. When compiled, the LCM configuration block produces a file with the extension meta.mof. Applying the meta.mof file is done by using the Set-DscLocalConfigurationManager Cmdlet.
You are not required to write your LCM configuration block in a file; it can, alternatively, be placed inside the DSC configuration file. There are several reasons to separate them. Your settings for the LCM could potentially change more often than your DSC configuration files, and keeping them separated reduces changes to your core files. You could also have different settings for different servers, which you may not want to express or tie down in your DSC configuration files. It's up to you how you want to organize things.
Compiling the LCM configuration block to MOF is done just like a DSC configuration block, by invoking the name of the LCM configuration you defined. You apply the resulting meta.mof file to the target node using the Set-DscLocalConfigurationManager Cmdlet.
An example LCM configuration is as follows, saved as ExampleLCMConfig.ps1. We could have put this inside a regular DSC configuration file, but it was separated for a clearer example, as shown:
#Declare the configuration Configuration SetTheLCM { # Declare the settings we want configured LocalConfigurationManager { ConfigurationMode = "ApplyAndAutoCorrect" ConfigurationModeFrequencyMins = 120 RefreshMode = "Push" RebootNodeIfNeeded = $true } } SetTheLCM
To compile this configuration into a MOF file, you execute the following configuration file in the PowerShell console:
PS C:Examples> .ExampleLCMConfig.ps1 Directory: C:UsersJamesDesktopExamplesSetTheLCM Mode LastWriteTime Length Name ---- ------------- ------ ---- -a--- 5/20/2015 7:28 PM 984 localhost.meta.mof
As you can see from the output, a localhost.meta.mof file was created inside a folder named for the configuration, as a SetTheLCM folder. The filename reminds us again that the LCM settings are considered DSC metadata, so any files or operations on LCM get the "meta" moniker.
Looking at the contents of the MOF file, we can see the same syntax as the MOF file generated by the DSC configuration file. You will keep seeing this standardized approach reused over and over again during our use of DSC, the importance of which we explained in Chapter 1, Introduction to PowerShell DSC.
Let's have a look at the following snippet:
/* @TargetNode='localhost' @GeneratedBy=James @GenerationDate=05/20/2015 19:28:50 @GenerationHost=BLUEBOX */ instance of MSFT_DSCMetaConfiguration as $MSFT_DSCMetaConfiguration1ref { RefreshMode = "Push"; ConfigurationModeFrequencyMins = 120; ConfigurationMode = "ApplyAndAutoCorrect"; RebootNodeIfNeeded = True; }; instance of OMI_ConfigurationDocument { Version="1.0.0"; Author="James"; GenerationDate="05/20/2015 19:28:50"; GenerationHost="BLUEBOX"; };
We then execute the LCM configuration by using the Set-DscLocalConfigurationManager cmdlet:
PS C:Examples> Set-DscLocalConfigurationManager -Path .SetTheLCM -Verbose VERBOSE: Performing the operation "Start-DscConfiguration: SendMetaConfigurationApply" on target "MSFT_DSCLocalConfigurationManager". VERBOSE: Perform operation 'Invoke CimMethod' with following parameters, ''methodName' = SendMetaConfigurationApply,'className' = MSFT_DSCLocalConfigurationManager,'namespaceName' = root/Microsoft/Windows/DesiredStateConfiguration'. VERBOSE: An LCM method call arrived from computer BLUEBOX with user sid *********************. VERBOSE: [BLUEBOX]: LCM: [ Start Set ] VERBOSE: [BLUEBOX]: LCM: [ Start Resource ] [MSFT_DSCMetaConfiguration] VERBOSE: [BLUEBOX]: LCM: [ Start Set ] [MSFT_DSCMetaConfiguration] VERBOSE: [BLUEBOX]: LCM: [ End Set ] [MSFT_DSCMetaConfiguration] in 0.0520 seconds. VERBOSE: [BLUEBOX]: LCM: [ End Resource ] [MSFT_DSCMetaConfiguration] VERBOSE: [BLUEBOX]: LCM: [ End Set ] in 0.2555 seconds. VERBOSE: Operation 'Invoke CimMethod' complete. VERBOSE: Set-DscLocalConfigurationManager finished in 0.235 seconds.