Day 30: Enabling Highly Standardized Web Farm Configuration with PowerShell DSC (Part 2)

Welcome to Day 30 of the “100 Days of DevOps with PowerShell”! For background on our goals in this series, see Announcing the “100 Days of Devops with PowerShell” Series here at SCC. If this is the first time you are viewing an article of the series and you are new to DevOps and PowerShell DSC, I encourage you to read through the previous installments, particularly Day 1.

Objectives for this Post

One of the core tenants of DevOps is highly standardized configuration.  In this article, we will build on the info in part 1 of this series within a series (Day 20: Enabling Highly Standardized Web Farm Configuration with PowerShell DSC (Part 1)) to reduce DSC configuration effort in enterprise scenarios. Here in part 2, you will learn how to generate MOF files for groups of servers in the same role, such as members in a web farm. The scenario in this post will demonstrate:

  • Developing a single configuration script to create a Configuration MOF files for multiple nodes from a single script
  • Packaging the necessary DSC modules so the nodes can download them from the DSC Pull Server automatically (with help from Scott’s Day 21 article on the topic)
  • Deploying a .NET web site and application (including site content) to all nodes in the web farm, including:
    • Install the IIS role
    • Install ASP.NET 4.5
    • Stop the default web site
    • Copies in the FourthCoffee website content to the managed node
    • Creates and starts a new website containing FourthCoffee content

At the end of this post, you will then have everything you need to easily adapt this sample to your environment for maintaining application configurations hosted on your enterprise web farms.

Demo Environment

In this example, I have three servers:

  • – My DSC Pull Server
  • – Managed Node (web server #1)
  • – Managed Node (web server #2)

We have a web farm of two in this example. The higher the server count in your web farm, the more effort you save.

Step 1: Download the Necessary Module(s)

Start by downloading the xWebAdministration DSC module from the TechNet Gallery at

TIP: In the \xWebAdministration directory created by extracting the contents of the zip file download, find the TechNetDocumentation-xWebAdministration.docx file, which contains everything you need to implement the sample .NET website, Fourth Coffee Bakery.

IMPORTANT: This article assumes you have your DSC Pull Server in place.I suspect you have already been working with PowerShell DSC, so you should download the xPSDesiredStateConfiguration module. If not, revisit Day 1. If you want to take the enterprise approach, read day 1 and then fast forward to Day 6 and configure an HTTPS DSC Pull Server for best security (links below)

If you have downloaded the necessary DSC modules and have setup your DSC Pull Server, you are ready to proceed.

Step 2: Package Modules for Download to Managed Nodes

As Scott explained in Day 21, one of the most powerful aspects of pull mode is the fact that you can package the DSC modules so the nodes download them automatically as needed, saving more configuration effort. This is the enterprise approach and will eliminate the need to manually copy these modules to server2 and server3 after you install on server1. If you have never packaged a module before, you should review “Day 21 – Deploying Modules via Pull Server” and package the xPSDesiredStateConfiguration and xPSDesiredStateConfiguration modules.

The end result of packaging these modules (on server1, our DSC Pull Server) should look like this.


Step 3: Create Configuration Files for the Nodes

In Day 20, we created a configuration that would perform the following steps on server2:

  • Install the IIS role
  • Install ASP.NET 4.5
  • Stop the default web site
  • Copies in the FourthCoffee website content to the managed node
  • Creates and starts a new website containing FourthCoffee content

This time, we will create a single configuration that will generate Configuration MOF files for multiple servers with like configuration.

You will run this configuration script from the DSC Pull Server (server1 in this example).

IMPORTANT: This is the part where we deviate from Microsoft samples in a very important way. Be sure you extract the contents of the FourthCoffee website from xWebAdministration\Examples\ and place it in the folder shown in the code snippet below (C:\Program Files\WindowsPowerShell\Modules\xWebAdministration\BakeryWebsite). Share that directory as BakeryWebsite (so it will be accessible remotely by nodes via \\Server1\BakeryWebsite or the server of choice in your environment. I gave all my nodes read permissions to the site content share).

Step 3a: The Configuration Script

This is the script that will be used to generate the Configuration MOF files. This is very similar to the configuration script in part 1 (day 20), except for line 7, which is a placeholder supporting generation of Configuration MOF files for multiple nodes (web farm members in this case).


Step 3b: The Configuration Data File

This file (ContosoWebsite_ConfigurationData.psd1) is the common configuration file, which in this case contains the configuration info for the FourCoffee website, including content. We will pass this file into the configuration script shown in step 3a when we generate the Configuration MOF files. We’ll save this file as ContosoWebsite_ConfigurationData.psd1. Remember the directory to which you save the file, as you will need the full path to the file in the next step.

Two important items to note:

  • Each node in the web farm is represented in the file. You will need one entry for each server hosting the website in your web farm.
  • Notice SourcePath is a UNC path so all servers in the farm retrieve the site content from the same “gold” copy of the site.


Step 3c: Create the Configuration MOF

Running the following one-liner will create the Configuration MOF for both server2 and server3. If you had 10 servers in the farm, a Configuration MOF would be created for every node in the farm. Notice the value you are passing with the -ConfigurationData parameter is the full path to the ContosoWebsite_ConfigurationData.psd1 file from step 3b.


Step 3d: Rename Configuration MOFs, Copy to Pull Server and Create Checksum

Then, we use the usual snippet to generate the guid, rename the Configuration MOF files for server2 and server3, move to the appropriate folder and generate the checksum file. You will need to run once for each farm server / Configuration MOF.

NOTE: We’ll extend this step to reduce effort even further in part 3, configuring all nodes in a single run.

Step 4: Configure Pull Mode on Node

This snippet is going to set or update the local configuration on You will need to repeat the steps for each node in the farm. Remember to change the guid for the server each time you run (line 1) and server name (lines 6 and 22).

You can run this script from the pull server or locally on the web farm nodes.

NOTE: We’ll extend this step also to reduce effort even further in part 3, configuring all nodes in a single run.


Step 5: Force Node to Evaluate Configuration

Run this snippet on the managed node ( to force the node to evaluate its configuration and retrieve and apply its configuration mof file, just to test the configuration. If it works on the first, the other nodes should pick up their updated MOF within a few minutes.

The server should download it’s new configuration mof, read its contents and perform the following steps:

  • Install the IIS role
  • Install ASP.NET 4.5
  • Stop the default web site
  • Copies in the FourthCoffee website content
  • Creates and starts a new website containing FourthCoffee content

True to PowerShell DSC functionality, all nodes you configure to retrieve this file will re-apply the configuration every few minutes in accordance to the intervals you configured enabling highly standardized server configuration.


That’s all for this installment. I hope you’re learning more each week about the many tasks and comprehensive scenarios that can be implemented with PowerShell DSC. Please leave questions, comments and suggestions in the Comments section below this article.

Previous Installments

To see the previous installments in this series, visit “100 Days of DevOps with PowerShell”.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.