Monitoring Application Deployment Failures in Configuration Manager


Background

One of the key features of System Center Configuration Manager is Application deployment. Most of our enterprise customers have invested heavily in their administrative time and skills in managing the deployment of applications to thousands of machines within their environment.

 

The Scenario

With numerous applications deployed to collections, my enterprise customer found difficulty in tracking application failures across their environment. The issue they encountered was that most reports they attempted only provided the ability to report on the application deployment creation date. This is a limitation when applications are created and deployed months ago but remain active in a large environment.

 

The Solution

After much deliberation, we concluded that the customer needed the ability to report on machines that failed their application deployment in the last week (or timeline they specified) regardless of when the application deployment was initially created.

With their objectives in mind we put together the below solution for use in their environment, at their discretion of course:
•    Using a set of application deployment report(s) support the administrators in monitoring failed application deployments.
•    And lastly, they needed a means to remove direct membership of machines in the collections targeted by application deployment on a weekly basis.

 

The Implementation

 

1.    App Portal - Application deployment failure report

•    Administrators initiate their monitoring\troubleshooting of failed application deployments for their environment by reviewing this report.
•    By default, the report is configured to provide a list of machines that last attempted to install an application in the past 7 days. The timeline can be modified with the report parameters.
•    This report provides an overall view of application failures, most importantly the report provides:
1-    information on when a machine last attempted the installation of an application
2-    error code of the failed deployment
•    Top 5 Application Failures: Administrators can easily identify the top 5 applications that failed deployment and focus their remediation efforts.
•    Count of error codes: Administrators can easily identify the top 5 errors across applications.
•    List of Failed Applications: Administrators can identify the machine name, collection name, error code and most importantly the last time a machine attempted to install an application in the Enforcement Time column.

image

 

2.    App portal – Application deployment status

•    This is a widely available report that provides overall information on the application deployment status. The limitation with this report however is that it only provides information to administrators for application deployments created within specified date range specified in the input parameters.
image

 

3.    Remove machine direct membership from collections (weekly\monthly):

The customer required a method to remove machines with direct membership from multiple collections that are targeted with applications and decided that they would incorporate a PowerShell script to achieve this on a weekly\monthly basis.

The best approach for the customer was to populate an input text file where they can manage the names of Application Portal collections they chose to target. The PowerShell script would be scheduled by Task Scheduler.

 

•    PowerShell Script to remove direct membership from collection:

#############################################################################
#
# Purpose : This script removes collection direct membership from a list
#
#############################################################################

# Load Configuration Manager PowerShell Module
Import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')

# Get SiteCode
$SiteCode = Get-PSDrive -PSProvider CMSITE
Set-location $SiteCode":"

# Define Input File
$script_parent = Split-Path -Parent $MyInvocation.MyCommand.Definition
$inputfile = $script_parent + "\InputFile.txt"
$list = get-content $inputfile

# Define Logfile Parameters
# Logfile time stamp
$LogTime = Get-Date -Format "dd-MM-yyyy_hh-mm-ss"
# Logfile name
$Logfile = $script_parent + "\CMRemDirectMem_"+$LogTime+".log"
Function LogWrite
{
Param ([string]$logstring)
Add-content $Logfile -value $logstring
}

# Remove Collection Direct Membership
ForEach ($CollectionName In $list)
{
Remove-CMDeviceCollectionDirectMembershipRule -CollectionName $CollectionName -ResourceName * -Force -ErrorAction SilentlyContinue
LogWrite "$LogTime | $CollectionName"
Echo "$LogTime | $CollectionName"
}

•    The PowerShell script uses an InputFile.txt to specify application deployment collections.
•    The InputFile.txt will need to be created in the same folder as the PowerShell Script as the script will reference the parent folder.
•    An output logfile is created as the PowerShell script executes.

image

•    Example of the Task Scheduler configuration created for the Basic Task Action tab:

image


Program/script:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Add Arguments (optional):
"D:\SOURCES\PowerShell\Collections_RemoveDirectMembership\Collections_RemoveDirectMembership.ps1"

 

4.    App portal – List of collections modified

Once the PowerShell script has executed, the below report is scheduled to run. This report records the list of collections that were modified by the PowerShell script. I have included the Date input parameters with a default offset of 1 day.
image

 

5.    App portal – List of machines in collection with direct membership

This is the second report also scheduled to run after the PowerShell script. This report displays the list of machines that still have direct membership. If this occurs, Administrators can troubleshoot further.
image

 

The Conclusion

Monitoring of Application Deployment for most organizations is a time-consuming task therefore in creating a process that is easy to follow, it will always benefit administrators allowing them to monitor and maintain large environments. I hope the information shared in the above scenario is helpful.

The reports can be downloaded below.

RDL

Note, I have split the reports into SSRS 2016 or later and SSRS 2014 or earlier. The SSRS 2014 reports do not contain any charts displayed in the screenshots above.

 

Disclaimer – All scripts and reports are provided ‘AS IS’
This sample script is not supported under any Microsoft standard support program or service. This sample script is provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of this sample script and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of this script be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use this sample script or documentation, even if Microsoft has been advised of the possibility of such damages.

Comments (5)

  1. Anton Masyan says:

    which version of ssrs do you use? ssrs 2017?

      1. Anton Masyan says:

        hm, okay, because ssrs 2014 can’t upload these rdl’s.

        1. I have updated the RDL download to include SSRS 2016 or later and SSRS 2014 or earlier. All charts have been removed for SSRS 2014 or earlier reports to prevent import errors on older versions of SSRS.

          1. Anton Masyan says:

            nice, awesome, thanks.

Skip to main content