Desired State Configuration (DSC) is one of the most important and powerful feature of Powershell 4.0. The primary objective of DSC is two fold
- To evaluate the current state of the environment
- To bring the environment back to the predefined configuration
DSC consists of resources that can be tracked for above purposes. The resources could be anything that you want to configure within the Operating system like processes, services, files etc. Some of the out-of the box resources include
- Process etc.
Also, there are two different models through which DSC tries to achieve its objectives
- Push model
- Pull Model
In Push Model, the Server designated as desired state configurator tries to push the configuration information to the designate target servers where as in Pull model the target servers tries to connect to a designated server to get its environment checked and reconfigured if there are deviations.
Having both the models within DSC architecture helps in managing different heterogeneous environments that might just be not possible simply with only having the push model.
In this Series we would understand more details about DSC as well as create a new type of resource. We will also use this resource to configure the target environment.
In the first part of this series we will first create a new Configuration that would describe the expected configuration for the target servers.
Though the configuration is written within a Powershell host, it does not look much like Powershell. It looks more like a nested block of name value pairs. In version 4.0 of Powershell, new capabilities has been added in terms of newer keywords that help in writing the configuration file.
Also, newer design time capabilities been added into Powershell ISE that can detect configuration and figure out errors if any. One of the errors that I have come across has been that while creating new DSC resources, if the name of the resource is same as that of one that already exists, red wriggled lines starts appearing on the ISE.
Another capability added by Powershell is that while executing the configuration file, instead of generating output on the host, it generates a folder at the current user’s home directory with the same name as the name of the configuration and creates one Management Object Format (MOF) file for each node. This MOF file is generated by Powershell that would eventually be used for configuring the target servers and is named with name of the Node.
Therefore you can see that a lot of changes and extensions have been done within the overall Powershell environment to accommodate DSC.
Another point to note is that DSC is dependent on WinRM for pushing configuration information to the target servers. You will find WMI namespace available within Root/Microsoft/Windows/Desiredstateconfiguration and all the related classes.
Even when you defined your resources, these gets added to this namespace.
Now, let’s see a sample Configuration written in Powershell ISE
In the above sample, we can see there are some new keywords that makes the configuration possible.
The first top image is the actual configuration file and the bottom second image is for reference to understand the semantics of a configuration file.
Configuration defines the overall declarative script. It acts as the root or start of the configuration. It is very similar to the semantics of a workflow of a function i.e. you can invoke this configuration by calling it by its name.
Node defines the target server on which the configuration related to it will be applied.
Resources are the most important part of the configuration file and they refer to the actual Configuration Items (CI) that you would like to monitor, evaluate and may be change its state after comparing with the desired state. Some of the resources that come out of the box with System Center 2012 R2 Eval are mentioned above. You should provide the name to a resource that should be logical to represent the actual resource that it might refer to.
Another important concept are the parameters within the resources section. In the above example couple of parameters are mentioned. Name refers to the actual resource that is available within the OS. In the above example, we have named one of the resource as XPS because there is a windows feature called “XPS-Viewer” available.
Ensure refers whether this configuration intents to make this resource available or not available. Ensure has 2 possible values: Present and Absent.
Present means that if the resource is not available it would be provisioned and made available whereas Absent means that if the resource is available it would be de-provisioned and made disabled.
Please note that the meaning of parameters could change depending on the type of resource. System Center 2012 R2 eval is consistent in its naming and usage.
In the next post we will look at some of the internals of the configuration we created above.