Time goes on, and your boss is impressed at the speed with which you are able to provision new servers on demand and replace faulty ones as they break. He notices, however, that the response time drops off severely after you hand off the servers to the application team to install the company's custom software. After discussing it with the application team, you are cleared to codify the installation requirements and configuration for the company's application called Apollo and add it to your DSC configuration. Since you've already added the base installation requirements to the DSC configuration script, it's a simple matter to add the MSI installation steps for the Apollo application.

The Apollo application is only supposed to be installed on the app servers, so you need a way to tell DSC to not install it on any other target node. You can create a new Node statement and use the filtering capability of PowerShell, where the statement to select only the target nodes that have the "appserver" role defined is located:

Configuration PantheonDeployment
{
  Import-DscResource -Module xPSDesiredStateConfiguration
  Import-DscResource -Module xRemoteDesktopAdmin
  Import-DscResource -Module xTimeZone
  Import-DscResource -Module xComputerManagement
  Import-DscResource -Module xSystemSecurity

  Node ($AllNodes).NodeName{ <# ... #> }

  Node ($AllNodes.Where({$_.Roles -contains 'appserver'})).NodeName
  {
    xPackage ApolloPackage
    {
      Ensure    = 'Present'
      Name      = $Node.Apollo.Name
      ProductId = $Node.Apollo.ProductId
      Path      = $Node.Apollo.Source
      Arguments = $Node.Apollo.Arguments
    }

    Service ApolloService
    {
      Name      = 'apollo'
      State     = 'Running'
      DependsOn = @("[xPackage]ApolloPackage")
    }
  }

}

$data   = Join-Path $PSScriptRoot 'data_example_02.psd1'
$output = Join-Path $PSScriptRoot 'PantheonDeployment'
PantheonDeployment -ConfigurationData $data -OutputPath $output

You chose to use the newer xPackage DSC Resource from the PSGallery because it has a couple of newer bug fixes and parameters compared to the PowerShell v4 release. So now you have to add the xPSDesiredStateConfiguration module to your Import-DscResource statement. This choice means that you now have to copy out the xPSDesiredStateConfiguration module to all your target nodes before you push the new version of your DSC configuration script. You make a mental note to ask your boss about a DSC Pull Server again.

Your 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          = 'CONFIG='
        ConfigFilePath     = "$env:ProgramFilesApolloconfigapp.config"
        ConfigFileContents = "importantsetting=`$true"
      }
    }
  )
} 

Another choice you made was to extract the MSI package information out to your ConfigurationData block. You remembered the section of this book that explained how this allows you to increment the version number or change the package location without editing your DSC configuration. You used the $Node keyword to access the hashtable for each target node and access all the special MSI information the xPackage DSC Resource needs to operate.

Testing this out in your dev setup works out nicely, so you push out your new DSC configuration to your target nodes. DSC automatically tests each target node for compliance and only installs the Apollo application on the new target nodes that need it or the target nodes that have an outdated version. Upgrades of existing installs work because the Apollo developers followed MSI conventions for point releases and did not change anything that required a full uninstall of the previous version.