Windows Management Framework v4 included a new feature; Desired State
Configuration. This is the second in a series of articles describing Desired
State Configuration with the intent on giving a sip instead of a fire hose to
get you into it.
In the previous post I made an attempt to introduce all of the moving parts
of Desired State Configuration. This is an introduction to the basics of the
ability it brings and I am going to describe how it works by walking through a
very basic sample.
Just to avoid confusion, I am going to follow the pattern that you see in
many of the blogs, with a lot of words around it. That said, it is rare to find
a discussion of the MOF document itself. Most articles focus on generating the
MOF configuration and then applying it. But I want you to be clear that there
is a separation.
In my sample I am working in the PowerShell ISE instead of a console. It is
still just a PowerShell session running in my security context.
I am going to assume that you know what localhost is (the machine where I am
executing commands).
First of all, I have a PowerShell script (a series of commands) that creates
a configuration in memory, writes that configuration to a MOF document, and then
applies that configuration to localhost. MSFT refers to this configuration as
configuration
data at this point. It is not a configuration until it is written to the
MOF.
Here is the sample that relates to this article:
Lets first look at
lines 2 - 14. The special function 'configuration' is being used to declare a
configuration named 'sample' surrounded in brackets.
Within the configuration 'sample' is one node element, it is named
'localhost'. This node specifies the computer(s) the configuration applies
to. It must match / resolve to a computer name for the configuration to be
applied. I could quickly get complex here and I am consciously trying to avoid
that. Lets just keep this to the local computer at the moment*.
Within the node is a state of a DSC Resource. In this case the File resource
which is built-in. I named this File state 'citrixFolder' (each defined state
has a name, I will mention more about that later).
The File resource has parameters. I have defined that ensure is 'present'
(it exists), the type as 'Directory' (so that it does not think I am defining a
File), and the path. If I stated this I would say: "ensure that a directory
named 'EasyButton' exists at the path C:\ProgramData\Citrix\EasyButton"
I then close each element of the configuration.
On line 17 I call the configuration named sample - the same way you would
call a function.
What this does is generate a folder .\sample and within that a MOF document -
.\sample\localhost.mof (note the '.\' in the path. Since I did not define a
literal path for the output).
If I look at localhost.mof, I can see how this looks in the MOF format.
You can see that it
was generated by me, and my workstation is named scooter, as well as the time
and date, and the configuration that I defined for the node localhost.
Now, lets apply this configuration - make it a reality. That is where line
20 of the sample script comes into play.
I start the DSC Configuration engine and tell it to apply the configurations
found at .\sample to the computer localhost. I force the action, I request
verbose output, and I want to wait. Verbose is handy to show you what is
happening. Waiting makes the configuration run within the session, instead of
off on a job thread. Useful for debugging.
As you
can see from the verbose output the first thing that happens is that the current
state is evaluated. Then the local configuration manager decides if it needs to
make a change. In this case the test of "is the directory
C:\ProgramData\Citrix\EasyButton present" returned false. So the Set is called
to make that change. The change returns a success and the local configuration
manager moves on.
The behavior of the local
configuration manager can be modified as well. Since a configuration can be
applied (make the changes), or applied and enforced (make the changes and be
sure nothing changes), or applied and monitored (make the changes and toss an
event if something changes). More about that later.
* I am sure that some of you could imagine multiple node names, or multiple
node elements (one big document defining multiple nodes) with the same document
fed to them all. Then only the configuration that matches the computer name is
applied.
No comments:
Post a Comment