Time goes on, and your boss is impressed with the speed at which you are able to provision new servers on demand and replace faulty ones as they break. He/she 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 not to 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 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 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 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 hash table 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 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 installations work because the Apollo developers followed MSI conventions for point releases and did not change anything that required a full uninstallation of the previous version.