Summary: Microsoft Scripting Guy, Ed Wilson, talks about using a configuration data file to apply DSC to multiple servers.
Microsoft Scripting Guy, Ed Wilson, is here. Hmmmm…I guess the Charlotte weather person does not know how to predict the weather in Germany. The Scripting Wife and I hopped aboard a train to Halle for a nice day of strolling the old town square, sitting in outdoor cafes, sipping tea, and taking pictures. Dude, it began to storm, so we decided to stay on the train and go somewhere else. That is the cool thing about a rail pass—especially when you have two batteries for your laptop and five devices in your backpack. It makes for a great day of writing and playing with Windows PowerShell.
I am listening to Bach today on my Zune, and we have a nice work table—so it is like having a window office. We are dry, and they have great tea and coffee service on the train. Anyway, I decided to fire up a bunch of virtual machines and play around with remotely configuring servers with DSC.
Note Today is the sixth day in a series of blog posts about Desired State Configuration.
- Intro to PowerShell 4.0 Desired State Configuration
- Using PowerShell 4.0 DSC Parameters
- Specifying PowerShell 4.0 DSC Configuration Data
- Using PowerShell 4.0 DSC to Control Configuration Drift
- Configure SMB Shares with PowerShell DSC
Today I talk about creating folders and SMB shares on multiple remote servers by using a configuration data file.
Just the steps
- Create one configuration data file.
- Create one configuration that uses $node to obtain machine-specific information.
- Ensure remote servers have the required resource files.
- Use the DependsOn keyword to specify things that must happen first.
- Specify a single output folder.
- When running the configuration, ensure that you specify the configuration file.
- Specify the folder that contains the configuration MOF files when running Start-DscConfiguration.
That may sound like a lot of steps—but really it is not, and they all go pretty quickly. The tricky part is making sure that I get the configuration data file correct, and that I correctly address the configuration by property name because tab expansion does not seem to work for this process.
Create a configuration data file
Oh no…not a configuration data file. Dude, dude, dude! That sounds like it is going to be waaaaaayyyyy tooooooo complicated. OK. Maybe my reaction was not quite that bad, but it was nearly that bad. I mean, I have to pretty much hand type the thing, so it has to be tough. Right? Well, not necessarily.
There are two key points here:
- I can use my Windows PowerShell ISE to create the configuration data file. I just have to remember to save it as a .psd1 instead of going with the default of .ps1.
- In the end, it is simply an array of hash tables.
Note We have been working with hash tables in Windows PowerShell since before version 1 shipped. If you do not know about hash tables, stop and read my Hey, Scripting Guy! series about hash tables. But really, they are no more complicated than @{ propertyname = value }.
What do my remote servers need?
If I am going to create a number of file shares on remote servers, I need to have the following:
- The name of the remote server (node name)
- The name of the share
- The source for my files
- A destination for the files that will live on the remote server
- Description for the share
Each of these becomes an element in a hash table. The hash table is shown here:
@{
NodeName = "*"
ShareName = "ScriptedShare"
SourcePath = "\\dc1\Share"
DestinationPath = "C:\scripts2"
Description = "DSC created SMB Share"
},
Now, I said I have an array of hash tables. Therefore I have two more hash tables. These define the role of my server. In this instance, they are SMB, but I am making stuff up, so they could be DHCP servers, DNS servers, clustered servers, SQL Server servers, or whatever I want. I can then use Windows PowerShell to parse the Role information and really customize stuff. Here are my two hash tables:
@{
NodeName = "S1"
Role = "smb"
},
@{
NodeName = "S2"
Role = "smb"
}
);
That really and truly is about it. I have an array of hash tables. The complete configuration file is shown in the image that follows:
Simplify the script
With the detail information inside of the configuration data file, I can now create a much simpler script that will read the configuration data file when it comes time to create the MOFs.
Inside my configuration, I need to import only a single DSC resource. This is because the File DSC resource is native to Windows PowerShell 4.0 DSC. The xSmbShare resource comes from the DSC Resource Kit Wave 2.
Note You can read about the DSC Resource Kit Wave 2 on the Windows PowerShell Blog. You can download the DSC Resource Kit from the Script Center Repository.
Now the really cool stuff comes into play. I do not need to specify a hard-coded node name. I can use the automatic $AllNodes variable to work with all nodes from the configuration data file. In the following command, I use the $AllNodes variable to address all the nodes. Then I use the simplified where syntax to filter with a script block for roles that are equal to SMB. Next, I return only the NodeName property.
Node $AllNodes.where{$_.Role -eq "SMB"}.NodeName
Specify the configuration data file
When I call the configuration, to create the MOF files, I specify the path to my configuration data file. I also like to specify the output directory so I can call Start-DSCConfiguration to apply my configuration to all my remote servers. Here are the two lines of script that do that:
SmbShare_FromConfigurationData -ConfigurationData c:\scripts\ShareConfigData.psd1 -OutputPath C:\SMBConfig
Start-DscConfiguration -Path C:\SMBConfig -wait –Verbose
When I run the script, it creates two MOF files, and then applies the DSC to the two remote servers. This is shown in the following image:
That is all there is to using a configuration data file to help to configure multiple remote servers using DSC. DSC Week will continue tomorrow when I will talk about more cool 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