With the release of Windows Server 2012 R2 and Windows 8.1, Microsoft provided a new way of ensuring that your devices are at a good configuration state. This new method uses PowerShell to ensure that required roles and features are enabled, registry settings are correct, files are in place, and a whole host of other management tasks. Note that this only works on Windows Server 2012 R2 and Windows 8.1.
With DSC, administrators can write a PowerShell script and execute it on machines. The script will check all of the listed configurations, and correct any that are wrong. It can also continuously execute, ensuring that the device stays within its configuration and does not drift. This can be vital on things like web servers, where they can be automatically spun up in VM’s to handle an increase in traffic. It can also be beneficial on client machines where there is no central management solution. DSC can be used to ensure that anti-virus is always running, and that the computer is up to date.
These configurations come in as Management Object Format (MOF) files. These files can be written in Notepad, though using PowerShell makes it easier, as PowerShell can interpret things for you.
Push/Pull
There are two methods for delivering the DSC files. With the Pull method, clients of the service have to “pull” the files from a central server, meaning that they start the connection instead of the server. Most of the time this is done with a scheduled task that performs a compliance check. If the client is found to be out of configuration, the client requests the new configuration from the pull server and applies it.
Push is the exact opposite – the server “pushes” the configurations to clients. These pushes can be started by running the Start-DscConfiguration cmdlet on the server and specifying a computer name by using the -computername parameter. This is for immediate application. The push server will also send the configurations on a schedule.
Both of these methods require an IIS server to host the configurations. The clients request the configurations by communicating with a URL.
Creating and Deploying a Configuration
Creating configurations is actually pretty easy. There is a common format that is similar to other things in PowerShell. First, we state our configuration, then execute it. A configuration works very similar to a function. To turn on IIS, here is what we do:
configuration IIS_Install {
node localhost {
WindowsFeature IIS {
Ensure = “Present”
Name=”Web-Server”
}
}
}
IIS_Install -output “.”
There are a few things going on here that you need to be aware of. First, we specify the name of our configuration (IIS_Install) in the same manner that you specify the name of a function. Next is node. This the device that the configuration will apply too. I am using localhost, but you can also use a variable filled with device names, or type in a remote computer.
Next we have the resource provider “WindowsFeature”. This is one of the many configurations you can make. Files, registry settings, process, etc. all of a different resource provider name. Next, I am enabling IIS, so I give “WindowsFeature” a name (this can be any name you want, and intended to help you find it in the configuration).
Next, we want to ensure that the role is present. If you want the configuration to ensure that the role is NOT present, replace this with “absent”. Next, the name is the actual role or feature name. This corresponds to the values that you see if you look at roles and features using the Server Manager PowerShell module, or dism.
Finally, we want to output the MOF file, so we execute our configuration. This does not apply the configuration to the host that you are working on. It only builds the MOF file. I outputted the configuration with the same name as the PowerShell script and in the same directory, hence the “.”.
Another helpful option that would go with Ensure and Name would be Source. You can specify the source location of the installation files, if necessary. It would like:
Source=”D:\sources\sxs”
The source is not needed for IIS, but it is needed if you want enabled something like .NET 3.5/2.0.
To apply the configuration, run:
Start-DscConfiguration -wait -verbose –computername localhost –path <path to MOF>
You can change localhost to a machine or set of machines to execute the configuration remotely. Also, the path parameter points to a folder, not a file. This command will execute any MOF’s in the directory. The wait parameter instructs the PowerShell session to wait for the configuration to be applied before moving on. This can be helpful you are applying multiple configurations, or have this as part of a larger script. The verbose parameter will output everything to the screen.
Detect Configuration Drift
As I stated in the beginning of this post, these configurations can be used to control configuration drift, ensuring that your devices are all within your desired configuration. One way to tell if a device is out of configuration without actually bringing it back into configuration is to run this command:
Test-DscConfiguration -CimSession localhost
Again, to run against a remote machine or group of machines, change localhost. This command will either return “true” if the device is within its configuration, or false if it is out of configuration.
Disclaimer
All content provided on this blog is for information purposes only. Windows Management Experts, Inc makes no representation as to accuracy or completeness of any information on this site. Windows Management Experts, Inc will not be liable for any errors or omission in this information nor for the availability of this information. It is highly recommended that you consult one of our technical consultants, should you need any further assistant.
