SCCM Software Distribution Troubleshooting

Software distribution failures in SCCM can stem from issues with content delivery, client health, or policy application. Effective troubleshooting requires knowing which reports to check and which client‑side logs provide actionable insights. This guide consolidates the most important steps, log references, and error codes to help administrators quickly diagnose and resolve deployment problems.

Note: This article lists the steps for troubleshooting SCCM software distribution (legacy package & program model).

Content Monitoring and Validation from Console

The article below provides details on content monitoring and validation from the console.

https://blogs.technet.microsoft.com/inside_osd/2011/04/06/configuration-manager-2012-content-monitoring-and-validation/

Reports

SCCM reports should be the first thing to check for the software deployment status. By looking into the report, you can determine the scope of failure, such as large-scale failure, location-specific failure or client-specific issues. A large-scale failure may be caused by an issue with a package or a program, while an issue can be related to a specific client if the deployment failure rate is low and limited to a few clients.

There are multiple reports available for each category.  All Software Distribution reports can be found in below folders under Monitoring > Reporting > reports.

· Software Distribution – Collections

· Software Distribution – Content

· Software Distribution – Package and Program Deployment

· Software Distribution – Package and program Deployment Status

As a Deployment Administrator, it’s advisable that you browse through all these reports and make yourself familiar with them so you can quickly refer to them whenever required. For Example, you can refer to “Package and program deployment status messages for a specified client and deployment” to check the deployment status of a specific deployment for a specific machine. While another report, “Status of a specified package and program deployment,” can be referred to know the overall status of a specific deployment.  

Log Files

Reviewing client-side logs is one of the most important steps to quickly identify any possible issue with deployment. There are a few log files that you should review when troubleshooting software distribution issues. A complete list of SCCM 2012 log files is available here. While log files can be viewed in Notepad, there is a tool, CMTrace, in Configuration Manager that will simplify the log review experience. This tool can be found under \tools folder. This tool can be used for real-time monitoring of the log file. You can find here more details about CMTrace and other tools that every Configuration Manager administrator should know.

Policyagent.log

When you make a change in the Configuration Manager console, the site server creates a policy to communicate the change to the client. The site server sends the policy to the management point, and the client polls for policy at the interval configured in the Computer Client Agent properties. The SCCM client takes appropriate actions as soon as a policy arrives. The Policyagent.log records policy download requests using the Data Transfer services. This log file helps to troubleshoot policy request problems.

The entries similar to the one below should be recorded in the log file policy download.

Download of policy CCM_Policy1, PolicyID=”ScopeID_D791533_4C64JH/Authlist_43b454f-aa453d”

If you do not see any activity in PolicyAgent.log for long time (may be couple of days), then check SCCM client health as it may not be healthy.

PolicyEvaluator.log

The PolicyEvaluator.log records the details of new policy settings. This log can help to troubleshoot policy override issues.

Execmgr.log

Execmgr.log provides the execution details of the advertised programs or updates their status. This log file provides brief details such as the command line for the executed program and the exit code. By looking into the error carefully, you can identify the issue quickly.

The Excemgr.log should include the following entry when a new policy for a package arrives on the client. The presence of such an entry helps you to determine whether you have the latest policy for the new package populating the client.

Policy arrived for parent package PKG00001 Program Test Program1

When a policy is updated for a program that the client received earlier, the following entries will be shown.

Policy is updated for parent package PKG00001 Program Test Program1

If the package is not available on the client machine, then you will see the entry for the package download request.

Requesting content from CAS for package PKG00001 version 1

The Execmgr.log shows download progress and completed status. The following entries should be included in the log when the package download starts until completion.

Program Test Program1 change to state STATE_ADVANCED_DOWNLOAD content in progress

Execution Request for Package PKG00001 program Test Program1 state change from NotExist to AdanceDownload

Mandatory Execution requested for program Test Program1 and advertisement ADV00001

Successfully raised SoftDistWaitingContentEvent event for program Test Program1

Execution Request for package PKG00001 program Test Program1 state change from WaitingDependency to waitingcontent

Execution Request for Package PKG00001 program Test Program1 state change from WaitingContent to NotifyExecutinon

The further entries should include the program path, the command line, and execution status.

Successfully selected content location C:\Windows\System32\CCM\Cache\PKG00001.1.System

Command line = “C:\Windows\system32\CCM\Cache\PKG00001.1.system\TestProgram1.bat

Raised Program Started Event for Advertisement: ADV00001, Package: PKG00001, Program: Test Program 1

Program Exit Code 0

Execution is completed for program test program1. The exit code is 0, The execution status is success.

CAS.log

The CAS (Content Access Service) maintains the local package cache and checks if it already has the content. If content is not present in the cache, then CAS instructs ContentTransferManager to initiate the download. CAS will be notified again once the download is completed. The details below should be found in CAS.log for each request.

Successfully created download request for content

Matching DP location found 0

Download completed for content

Location services.log

The LocationServices.log records attempt to find management points and distribution points.  This log file can help to troubleshoot scenarios where the client cannot find a management point or distribution point.

ContentTransferManager.log

ContentTransferManager is the one who determines how the content should be downloaded. When a package is to be downloaded from a distribution point using BITS, the download request is handed over to DataTransferService.log:

Datatransferservices.log

The DataTransferServices.log records all Background Intelligent Transfer (BITS) communication for policy or package download. The entries related to package download can be found here.

Deployment Errors

The Execmgr.log records the success or failure information for all advertisements. The information below can help troubleshoot the issue.

Exit Code

The Excecmgr.log records the exit code for all deployments. By understanding the exit code, you can move forward with troubleshooting in the right direction.  For all success deployment, the exit code will be 0.

Execution is completed for program test program1. The exit code is 0, the execution status is success.

To know the description of common exit codes, you can use the ‘net Helpmsg’ command from the command prompt.

For Example, the deployment failed with Exit Code 1. As you see in the screenshot below, the error code 1 error description is ‘Incorrect Function’. Most probably, the issue is with the command line you have provided in the program. So, you need to re-validate the command line.

Exit code net helpmsg

Another example:

net helpmsg 1619

In fact, by understanding the error code and its description, you can quickly move towards the next troubleshooting steps for SCCM deployments.

You may not get the details of all exit codes using the above command. However, you can refer to Microsoft Documentation System Error Codes for a complete list of error codes. There are custom error codes for Software Distribution, which can be found here.

Program Failed with Runtime Exceeded Error:

The most common issues that lead to the above failure reasons are as follows.

1. The “Maximum allowed run time” set in program properties is too short for the installation to complete. The default time is 120 minutes, and it should be fine with most of the deployment.

SCCM program maximum allowed run time

2. The program is not a silent install, and it’s waiting for user input. This may happen due to error messages popping up if install is not completely silent. If it’s a silent install, then try to install manually with the same command line that is used in the package program.

3. There may be an issue with the installation package, which might get stuck in the middle. Try to install the package manually to identify any possible issues with the package.

4. Select the “Allow users to interact with this program” checkbox in program properties and deploy to the test machine, check if you are getting any prompts during installation.

The program is waiting for the service window availability

Maintenance Windows provide administrators with a way to define a period of time that limits when changes can be made on the system that are members of a collection. You will see similar details in Execemgr.log when a Service window is not available. You can also refer to ‘ServiceWindowsManager.log’ for more specific information about Maintenance Windows.

Successfully raised SoftDistWaitingForServiceWindowEvent event for program Test Program1

Execution Request for advert ADV00001 package PKG00001 program Test Program1 state change from Ready to WaitingServiceWindow execmgr

To check all Maintenance Windows available for a client, you can refer to the “Maintenance Windows Available to a Particular Client” SCCM report.

Program waiting for content for a long time

If you are seeing the message below for a long time, then there may be an issue with package download. However, review DataTransferServices.log to check if the download is in progress.

Execution Request for package program state change from WaitingDependency to waitingcontent

Refer to the article below to know the details about Content Monitoring and validation

The article below provides good details about basic content deployment troubleshooting

Program failed with Exit Code 1603 – A fatal error occurred during installation

The error code 1603 is a generic Windows Installer error code. This error indicates that a problem occurred during installation, and there can be various reasons behind the failure. The error code 1603 is the most difficult to troubleshoot. The best option to troubleshoot error 1603 is to use MSI verbose logging. You need to re-run the setup with verbose logging enabled. You can follow the similar steps listed below.

Generate a verbose log using the command. This command will create a verbose log file, which offers a lot of information about the installation.

Msiexec /i \setup.msi /l*v c:\temp\msi.log

Open the log file in a text editor such as Notepad and review carefully. The article below describes a few tricks that you can use to quickly identify the failure reason from the verbose log.

https://blogs.msdn.microsoft.com/astebner/2005/08/01/how-to-locate-the-cause-of-error-code-1603-in-a-verbose-msi-log-file/ ·

Error: Software Distribution Site Settings for the client are missing from WMI

The above error indicates that the client has not yet received the software distribution site setting. This may happen due to the following reasons

  • Check if the client is healthy. You can review ccmexec.log to know client health status.
  • An issue with WMI, try to stop the WMI service, rename %windir%\system32\wbem\repository folder and start WMI again.
  • The client has not received the policy from Management Point. Check PolicyAgent.log to know if new policies are coming.
  • Check locationservices.log to know if the client is able to locate a Management Point.

References

Troubleshooting SCCM Software Distribution

Troubleshooting Configuration Manager

Microsoft Press eBook

Related Posts:

Subscribe to Techuisitive Newsletter

Be the first to know about our new blog posts. Get our newsletters directly in your inbox and stay up to date about Modern Desktop Management technologies & news.

Scroll to Top