The Name property of the resource in the output shown in Figure 4-6 becomes the dynamic keyword. This is valid to any DSC resource. The PSDesiredStateConfiguration module takes care of loading all the dynamic keywords. In fact, in PowerShell ISE, inside the Node block, if you type the first few letters of a DSC resource name and press the Tab key, you should be able to auto-complete resource names present on the local system.
So, to reconstruct our example, let us add the WindowsFeature resource to the configuration script.
Configuration WebsiteConfig { Node localhost {
WindowsFeature WebServer1 {
} } }
Adding a resource script block is the same as Configuration or Node script blocks. We use the resource dynamic keyword, WindowsFeature in the preceding example, followed by an identifier and a script block. If you refer back to Figure 4-6, there are sets of properties associated with each resource. Using these properties, we can define what needs to be configured for the resource being managed. In this case, using the WindowsFeature resource properties, we can specify what Windows role or feature needs to be configured. An easy way to see all the properties and the syntax for any DSC resource is to use the -Syntax switch parameter of the Get-DscResource cmdlet (see Figure 4-7).
Get-DscResource -Name WindowsFeature -Syntax
Figure 4-7. WindowsFeature resource syntax
The syntax shown in Figure 4-7 should be familiar. The properties enclosed within the square brackets are optional properties, and the rest are the key or mandatory properties. In the case of the WindowsFeature resource, we must at least specify the name of the role or feature we want to configure. The Ensure property is set by default to Present, and therefore, the WindowsFeature resource tries to install the role or feature specified, using the Name property.
Tip
■
when using the powerShell iSe, another way to see the syntax for any dSC resource is to right-click the resource
keyword,
WindowsFeaturein this example, and select the Start intellisense option in the context menu. another way
to see valid property names is to type an invalid property name inside the
Resourcescript block. when you move your
mouse over the red wigley in the iSe, it shows a pop-up message with valid property names.
To reconstruct the example, we have to add the required properties to the resource definition. In our example, we must install the web server role, which is indicated by Web-Server.
Configuration WebsiteConfig {
As I mentioned earlier, the Ensure property is set by default to Present, so we need not specify that explicitly in the resource definition. Within a Node script block, we can specify any number of resource definitions, whether similar resources or different, as long as the values specified for the key properties of the same resources are different.
For example, the following example is invalid, as we are specifying the same value for both WindowsFeature resource definitions. In addition, remember that the resource identifiers are resource names and must be unique. This is indicated using the strings WebServer1 and WebServer2 in the following example.
Configuration WebsiteConfig {
However, the following example, in which we specify different values for the Name property, is valid, and using this configuration script, we can configure both the Web-Server role and the Web-Asp-Net45 feature.
Configuration WebsiteConfig {
When using multiple resources inside a Node block, DSC also lets us specify the dependencies among the resources. Each DSC resource has a DependsOn property added to its list of properties. Using this property, we can specify what DSC resources must be configured before configuring the resource in which the DependsOn property is specified. For example, if we want to first ensure that the Web-Asp-Net45 feature is installed before attempting to install the Web-Server property, we can use the DependsOn property as a part of the WebServer1 resource definition.
The following example demonstrates this.
Configuration WebSiteConfig
We will delve into the DependsOn property and its use in Chapter 5, when we talk about the built-in DSC resources. We will see several examples that leave you with a better understanding of this property and its use.
If you have followed the examples shown in this section and tried what we discussed, congratulations! You have authored your first DSC configuration script. But this is not sufficient to make changes to the target systems. The configuration script we have seen so far is just a method to declaratively specify the configuration changes we intend to make. It is also possible to add multiple Node blocks in a configuration script and use parameters such as a usual PowerShell script. We will see all this in Chapter 6. In the example at the beginning of this chapter, we had a resource block for the Website resource. This is not a built-in resource. It is a custom DSC resource. We will learn more about custom resources in Chapter 9.
We now have to translate that into a format that the DSC Local Configuration Manager or the DSC Engine can understand. This is the Managed Object Format (MOF) representation of the configuration script.
We can generate the MOF representation of the configuration script by simply loading the configuration into memory and then calling the configuration. Take a look at the following example:
Configuration WebSiteConfig
In the preceding example, we added the name of the configuration at the end of the configuration script and saved it as a .ps1 file. Now, when we execute this PowerShell script, it generates the MOF file and stores it in a folder that has the same name as the configuration (see Figure 4-8).
Figure 4-8. Generating the MOF file for the configuration script
Note that it is not necessary to save the configuration script. You can simply author the configuration script in the ISE script editor and press the F5 key to run the script. It will have the same impact as saving and then executing the .ps1 file. As you can see in Figure 4-8, running the configuration creates a folder with the same name as the configuration and stores an MOF file with the node name as the file name, followed by a .mof extension. You can open this MOF file in your favorite text editor and verify its contents. This is how it looks on my system, with the preceding configuration script. If you have executed the same configuration as we saw in the example, your MOF file shouldn’t be much different from what I have here, except for the first few lines, in which the GeneratedBy, GenerationDate, and GenerationHost properties are shown, and the last few lines, in which an instance of the OMI_ConfigurationDocument class is specified. These are auto-generated using system environment variables when the MOF is generated, and it is not currently possible to change them from PowerShell.
/*
@TargetNode='WSR2-1'
@GeneratedBy=Ravikanth
@GenerationDate=05/06/2014 14:11:12
@GenerationHost=Home-Desk
*/
instance of MSFT_RoleResource as $MSFT_RoleResource1ref {
ResourceID = "[WindowsFeature]WebServer1";
DependsOn = {
"[WindowsFeature]ASP"
};
SourceInfo = "C:\\Scripts\\WebSiteConfig.ps1::5::9::WindowsFeature";
Name = "Web-Server";
ModuleName = "PSDesiredStateConfiguration";
ModuleVersion = "1.0";
};
instance of MSFT_RoleResource as $MSFT_RoleResource2ref
As you see in the above MOF for the configuration script, for each WindowsFeature resource definition inside the Node block, we see an entry specified as the instance of the MSFT_RoleResource class. This is true for any other resource in DSC. For any of the resources in the configuration script, the MOF will contain the instance of the implementing class for the same resource. You will also notice that the ModuleVersion specifies the version of the module that implements the resource.
You can use the -OutputPath parameter of the configuration to specify an alternate location for storing the MOF file, instead of using the default location, which is the working directory in which the configuration was executed. To do this, add the -OutputPath parameter next to the configuration name at the end of the script. For example, replace the last line of our configuration script with the following:
WebSiteConfig -OutputPath C:\DSCMofs