A few weeks pass and you get an escalation call from the application team that your "DSC stuff" broke their application. A few minutes of investigation using the xDscResourceDiagnostics module shows successful DSC executions that detected configuration drift and corrected it. After showing this to the application team, they eventually admit that they updated the configuration file used by the Apollo application with different values without telling you since they were used to deploying the application themselves.

Since you had set the LCM to ApplyAndAutoCorrect, DSC detected the content difference in the file specified in $Node.Apollo.ConfigFilePath and changed it back to the value you specified in $Node.Apollo.ConfigFileContents in the DSC configuration data file, like it was designed to do. The application team didn't think that DSC would change the file; they thought it was a one-time-only installation tool. You explain that DSC is a configuration management tool that works for the life of the server and is not just for the initial installs. In the after-action reports, it was decided that all the engineering teams would learn enough about configuration management and DevOps practices to avoid mix-ups like this in the future.

This decision marks a turning point in the company. The applications and systems teams start moving toward declarative configuration files that are kept up-to-date as things change instead of having to keep the information in their head all the time. They become less concerned with golden images and special servers and instead focus on how to automate the steps outlined in the Word document for a release. This reduces the time spent on deploying the applications on new or existing servers and the time spent on figuring out why one server has a different setting than another one. Less time fighting fires and more time doing valuable work for the company starts to pay off in new features being deployed more quickly and bug fixes being patched sooner.

The continued success of using DSC in your environment has finally convinced your boss to allocate an instance for a dedicated DSC Pull Server. You refer back to Chapter 6, Pulling DSC Configurations, and use it to create a DSC configuration script to set up a DSC Pull Server. You even used the functions there to add a new step to your DSC configuration script that will handle copying the versioned DSC Resource module archive files for you to the new Pull Server.

Next on your list is renaming the MOF files for all the target nodes with ConfigurationId and creating the new checksum files for each one. You make a note to wrap that in a simple PowerShell function to be invoked after compiling the MOFs when you have some free time.

Now that you have your MOFs named with their ConfigurationId, you have to point them to your new DSC Pull Server. You can do this by adding the DSC Pull Server URL to the existing ConfigurationData hash. In total, only two files are touched: the DSC configuration script and the DSC configuration data file:

Configuration PantheonDeployment
{
  <#
  Import-DscResource -Module...
  #>

  Node ($AllNodes).NodeName
  {
    LocalConfigurationManager
    {
      ConfigurationId           = $Node.ConfigurationId
      RefreshMode               = $Node.RefreshMode
      ConfigurationMode         = $Node.ConfigurationMode
      AllowModuleOverwrite      = $Node.AllowModuleOverwrite
      RebootNodeIfNeeded        = $Node.RebootNodeIfNeeded
      CertificateId             = $Node.CertificateId
      DownloadManagerCustomData = @{
        ServerUrl = $Node.PSDSCCPullServer;
      }
    }
    <#
    ...
    #>
  }
}

We could have split this into another DSC configuration script, but keeping these parts together means it's kept up-to-date along with any new target nodes or changes to the ConfigurationData hash automatically.

Our updated ConfigurationData hash looks like this:

@{
  AllNodes = @(
    @{
      NodeName        = 'app01'
      ConfigurationId = 'ab2c2cb2-67a3-444c-bc55-cc2ee70e3d0c'
      Roles           = @('appserver')
    },
    @{
      NodeName        = 'app02'
      ConfigurationId = '8e8f44e6-aaac-4060-b072-c9ae780ee5f7'
      Roles           = @('appserver')
    },
    @{
      NodeName             = '*'
      RefreshMode          = 'Push'
      ConfigurationMode    = 'ApplyAndAutoCorrect'
      AllowModuleOverwrite = $true
      RebootNodeIfNeeded   = $true
      Apollo   = @{
        Name               = 'Apollo'
        ProductId          = '{e70c4829-91dc-4f0e-a404-4eba81f6feb9}'
        SourcePath         = 'http://build.pantheon.net/apollo/packages/releases/apollo.1.1.0.msi'
        Arguments          = ''
        ConfigFilePath     = "$env:ProgramFilesApolloconfigapp.config"
        ConfigFileContents = "importantsetting=`$true"
      }
    }
  )
}

After compilation, we can run Set-DscLocalConfigurationManager against the resulting metadata generated and update all our target nodes at once.

Now that you have the target nodes set up and talking to the DSC Pull Server, you sit back and relax until you remember your boss wanted a report to show that all your target nodes are in compliance. You refer back to Chapter 6, Pulling DSC Configurations, and use the PowerShell functions there to set up a PowerShell script that queries the DSC Pull Server and outputs the status to a .csv file, and then e-mail it to your boss every week. He can then open it up in a spreadsheet program and check how things are working out.