If you’ve read my last two blogs, you probably have a good understanding of Microsoft System Center Configuration Manager (SCCM) and the monitoring workspace in the SCCM console, SCCM log files and CMTrace. In this blog, I wanted to walk you through a specific SCCM troubleshooting scenario. Read my SCCM troubleshooting 101 blog to learn more.
In this case, I created a simple package with a single program that I deployed to a collection.
When I open Software Center on the client to install the program, it fails.
In this case, the error seems to be pretty clear, but let’s dig into the logs to be sure. First, we are deploying a package and program, so we need to look at the execmgr.log.
We can see from the execmgr.log that the content for this program is not available on the distribution point. I am pretty confident that I distributed the content for the package, but to be sure let’s look at the SCCM console. Content Distribution status is shown in the Monitoring workspace and in the Distribution Status | Content Status node.
The content for our package is on the distribution point, but why does the client think that it is not available? We know from the Technical Reference for Log Files in Configuration Manager that the cas.log on the client has information about content being downloaded to the client cache. Let’s look at the cas.log for more information.
No warnings or errors are highlighted, but we do see an interesting log entry: “The number of discovered DPs (Including Branch DP and Multicast) is 0.”
If a client cannot discover a distribution point, there is a good chance it relates to boundaries. Based on the information in the logs so far, let’s investigate the configuration of boundaries in the environment. My lab is very simple, so I have a single boundary and a single boundary group.
After looking at the boundary groups again, the problem with the program deployment is definitely a configuration issue. The Lab – Content boundary group does not have a site system designated for content.
I added the distribution point to the boundary group and tried the deployment again. This time it was a complete success.
This is just one example of using log files and the Monitoring workspace in the SCCM console to troubleshoot and resolve errors. Hopefully this provides a foundation for any SCCM troubleshooting you need to do. If you are still having trouble with SCCM and troubleshooting errors, BDO Digital’s Microsoft System Center team has extensive experience with SCCM and is ready to help you with all of your troubleshooting needs.
This blog, is part of a three part series. Below are additional SCCM 101 troubleshooting blogs:
Part I - SCCM Troubleshooting 101: Overview
Part II - SCCM Troubleshooting 101: Log Files