Working with the PowerShell Desired State Configuration, Part 2: Implementation and Troubleshooting
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Working with the PowerShell Desired State Configuration, Part 2: Implementation and Troubleshooting
In Part 1 of this Windows PowerShell Desired State Configuration (DSC) mini-series, we explored the basic theory behind DSC. More importantly, we created a simple DSC configuration script called EnforceScripts.ps1 (shown in Figure 1) that performs the following actions:
- Create a directory on the target node.
- Copy PowerShell script files from the DSC server to the target node.
)
Figure 1 Our example DSC configuration script.
Running the configuration performs the following actions:
- Create a directory with the same name as the configuration container in the script.
- Create Managed Object Format (MOF) files for every target node referenced in the config script call.
I have a small lab, so I targeted my script at my Windows Server 2012 R2 member server named adfs1. Figure 2 shows the MOF file.
)
Figure 2 Our MOF file is ready to be applied to the target node. Each node can have only one MOF applied to it at a time.
Starting a DSC Configuration
Let's refresh our memories as to the DSC command list:
Get-Command -Module PSDesiredStateConfiguration | Select-Object -Property CommandType, Name
CommandType Name
----------- ----
Function Configuration
Function Find-DscResource
Function Get-DscConfiguration
Function Get-DscConfigurationStatus
Function Get-DscLocalConfigurationManager
Function Get-DscResource
Function New-DscChecksum
Function Remove-DscConfigurationDocument
Function Restore-DscConfiguration
Function Stop-DscConfiguration
Cmdlet Invoke-DscResource
Cmdlet Publish-DscConfiguration
Cmdlet Set-DscLocalConfigurationManager
Cmdlet Start-DscConfiguration
Cmdlet Test-DscConfiguration
Cmdlet Update-DscConfiguration
On dc1, our DSC management server, we'll use the Start-DSCConfiguration cmdlet to apply the adfs1.mof configuration to the target node adfs1.company.pri:
Start-DSCConfiguration -Path 'C:\Placescripts' -Wait -Verbose
I added the -Verbose optional switch to instruct PowerShell to give us as much detail as possible as it works its magic. The -Wait optional switch locks the PowerShell session until the operation completes.
We can verify that the configuration "took" on the adfs1 host simply by examining whether (a) the new C:\scripts directory exists; and (b) the contents of C:\scripts match what's on the server:
Get-ChildItem -Path \\dc1\psscripts
Directory: \\dc1\psscripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/11/2015 10:49 AM 39 hello-world.ps1
-a---- 6/11/2015 10:49 AM 41 howaya-world.ps1
Get-ChildItem -Path '\\adfs1\c$\scripts'
Directory: \\adfs1\c$\scripts
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 6/11/2015 10:49 AM 39 hello-world.ps1
-a---- 6/11/2015 10:49 AM 41 howaya-world.ps1
Awesome! It looks like DSC is working. Now we'll turn our attention to customizing the type of DSC enforcement we want, as well as tweaking target node settings.
Working with the Local Configuration Manager (LCM)
The Local Configuration Manager (LCM) is the underlying "engine" that powers DSC on Windows computers. We use Get-DSCLocalConfigurationManager to view the LCM properties of local or remote systems.
For instance, let's examine the adfs1 LCM from our dc1 management server by implementing Common Information Model (CIM) sessions and Windows PowerShell remoting. For brevity, I'm showing only partial, relevant output here:
$session = New-CimSession -ComputerName 'adfs1' Get-DscLocalConfigurationManager -CimSession $session ActionAfterReboot : ContinueConfiguration ConfigurationID : caa3357b-7ec4-417d-b9d4-a5c508edbc56 ConfigurationMode : ApplyAndAutoCorrect ConfigurationModeFrequencyMins : 15 LCMState : Idle RebootNodeIfNeeded : False RefreshMode : PUSH PSComputerName : adfs1
Let me draw your attention to some of the more important LCM properties:
- ConfigurationMode: The ApplyOnly option applies the configuration, after which the node never again checks its compliance. ApplyAndMonitor reports compliance discrepancies to a log file, but doesn't take corrective action. ApplyAndAutoCorrect detects and correct DSC compliance violations during update cycles.
- RefreshMode: In push mode, configurations are pushed from the management server to the target node. In pull mode, the target node periodically queries the DSC management server for changes.
- ConfigurationModeFrequencyMins: This value, which defaults to 30 (minutes), represents the frequency at which the DSC configuration is enforced on the target node.
Setting up a DSC pull server is beyond the scope of our current discussion. Therefore, we'll use push mode in this example. You may want to adjust the ConfigurationModeFrequencyMins property depending on (a) your need for repeated compliance checking, and (b) your tolerance for extra network traffic.
We can use Get-DSCConfigurationStatus to get a quick peek at the system's compliance status and configuration mode:
Get-DscConfigurationStatus Status StartDate Type Mode RebootRequested ------ --------- ---- ---- --------------- Success 2015/07/15 12:52:11 Consistency PUSH False
I like to put my LCM directives within the configuration script itself. Check out the highlighted lines in Figure 3.
)
Figure 3 It's convenient to configure the target node's LCM directly from its DSC configuration script.
Run the configuration script again to generate an updated MOF file. You'll find that the LCM settings are stored in a separate file named nodename.meta.mof.
Next, run Start-DSCConfiguration to push the new configuration to the target node.
Testing and Troubleshooting
Let's verify that the DSC auto-correction works by first deleting the C:\scripts folder and its contents from the adfs1 target node:
Remove-Item -Path 'C:\scripts' -Recurse -Force
You can either wait until you reach your ConfigurationModeFrequencyMins value, or you can run Start-DSCConfiguration again on the management server. (If we had configured the node in pull mode, we could run Update-DSCConfiguration on the target to have it query the DSC management server.)
On my system, the C:\scripts folder and its contents arrived on the node as expected, after 15 minutes.
DSC jobs are actually PowerShell job objects. Thus we can use Receive-Job to get details on DSC configuration status. For example, I ran Update-DSCConfiguration on my adfs1 target node. (Remember, I just stated that the UpdateDscConfiguration command won't work when we're in push mode. I'm attempting to run the command because I want to test how my DSC system responds to trouble.)
Update-DscConfiguration Id Name PSJobTypeName State HasMoreData Location -- ---- ------------- ----- ----------- -------- 10 Job10 Configuratio... Running True localhost
Then we view the job object:
PS C:\> Get-Job Id Name PSJobTypeName State HasMoreData Location -- ---- ------------- ----- ----------- -------- 10 Job10 Configuratio... Failed True localhost
Uh oh. The update failed. I wonder why? Let's investigate (showing only partial output here):
Receive-Job -Name Job10 -Keep No attempt was made to get a configuration from the pull server because LCM RefreshMode is currently set to Push.
To view the DSC logs, open Event Viewer and browse to the following path:
Applications and Services Logs/Microsoft/Windows/Desired State Configuration
Figure 4 shows the previous error's event log entry.
)
Figure 4 PowerShell DSC writes to the Windows event logs.
The Microsoft Developer Network (MSDN) website has a great article on DSC troubleshooting if you need to go further.
Before we end this discussion, I want to address how you can reset a target node's DSC configuration. Let's imagine that we target five member servers such that DSC enforces the installation of the Windows Backup feature.
We can remove the configuration by deploying a new DSC configuration to the hosts that simply doesn't include the appropriate resource references. DSC resources that aren't specified in a configuration script are implicitly out of scope and ignored by the target nodes.
If you don't mind the manual work, you can also delete all MOF files from the target node with the following path:
C:\Windows\System32\Configuration
Next Steps
By now you should have a solid understanding of how Windows PowerShell Desired State Configuration prevents configuration drift on Windows Server systems. Going forward, I challenge you to try the following procedures to extend your understanding:
- Deploy a pull server and configure a target node to pull a configuration from it.
- Create a DSC configuration script that references two or three different resources as well as the LCM.
- Search the Internet to see what other PowerShell community members have done to make their DSC work more efficient and effective.
Thanks very much for reading. Share your DSC experiences and questions in the comments section. Happy PowerShelling!