Summary: Microsoft Scripting Guy, Ed Wilson, talks about using DSC in Windows PowerShell 4.0 to control configuration drift.
Microsoft Scripting Guy, Ed Wilson, is here. Today we have a very important topic. I am going to talk about controlling configuration drift. This (for me anyway) is one of the big deals about Windows PowerShell Desired State Configuration (DSC) in the first place. This is because when a server is configured, changes immediately begin to take place. Even with nearly perfect change control, things still end up going askew.
Using DSC simplifies troubleshooting, and it can also conduct remediation. Needless to say, it is cool. By the way, I will be speaking at the Windows PowerShell Summit in Bellevue, Washington. There are still a few seats available. It is a great chance to come up to speed on topics like DSC.
Note Today is the fourth day in a series of blog posts about Desired State Configuration. Portions of these posts are excerpted from my book, Windows PowerShell Best Practices, which is published by Microsoft Press.
- Intro to PowerShell 4.0 Desired State Configuration
- Using PowerShell 4.0 DSC Parameters
- Specifying PowerShell 4.0 DSC Configuration Data
Today we’ll talk about controlling configuration drift.
Because Windows PowerShell Desired State Configuration is idempotent, you can run the same configuration script multiple times without the fear of creating multiple resources or generating errors. Therefore, if the same configuration runs multiple times, if the configuration has not drifted, no changes are made. If the configuration has drifted, you can easily bring the server back into desired state.
You do not need to worry about modifying the configuration script to correct only detected errors. In fact, you do not even need to worry about configuration drift. You just run the same configuration, and you can be ensured that the server is brought back into state. In the situation where a server must match the DSM state, you can use the Task Scheduler to run Start-DscConfugration on a regular interval that matches the specific urgency of the required checks.
Another way to check for configuration drift is to use the Test-DscConfiguration function. The way to do this is to create a CIM session to the remote servers with a configuration that requires checking. Do this from the same server that was originally used to create the DSC to assure access to the MOF files. After the CIM session is created, pass it to the Test-DscConfiguation function. This technique is shown here:
PS C:\> $session = New-CimSession -ComputerName server1, server2 -Credential iammred\administrator
PS C:\> Test-DscConfiguration -CimSession $session
True
True
The SetServicesConfig.ps1 script creates two configuration MOF files—one for each server that is specified in the node array. This is shown here:
SetServicesConfig.ps1
Configuration SetServices
{
node @('Server1', 'Server2')
{
Service Bits
{
Name = "Bits"
StartUpType = "Automatic"
State = "Running"
BuiltinAccount = 'LocalSystem'
}
Service Browser
{
Name = "Browser"
StartUpType = "Disabled"
State = "Stopped"
BuiltinAccount = 'LocalSystem'
}
Service DHCP
{
Name = "DHCP"
StartUpType = "Automatic"
State = "Running"
BuiltinAccount = 'LocalService'
}
}
}
SetServices -OutputPath C:\ServerConfig
Start-DscConfiguration -Path C:\ServerConfig
The image that follows illustrates running the configuration and using CIM to verify that the configuration is still intact.
DSC Week will continue tomorrow when I will talk about more cool Windows PowerShell DSC stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy