Troubleshooting Tips & Examples–ConfigMgr.

Troubleshooting Site Components
These can give you good information on what is going on in your environment.  You should be checking in on these regularly.  Navigate here:  Monitoring \ Overview \ System Status \ Site Status and Monitoring \ Overview \ System Status \ Component Status and check each component on each page has a nice green check mark next to it, indicating there are no issues.


Here, is an example of one I have an error with:


Seems I have a problem with SMS_AD_SYSTEM_DISCOVERY.  Normally, in my case, one of my sites has had a power cut or an issue with a switch meaning the Data Center cannot contact the server to run a discovery – these sorts of errors usually sort themselves out within 24-48hrs.  To find out what’s going on under the hood I will right click the troublesome component and select to Show Messages and in this case I want to look at Error Messages.  I will chose to look over the ones for the last week.


I can see from this that all errors are the same, they all relate to the same geographical location and that of the two possible causes “The domain controller is inaccessible” is the most likely cause.  I  then prove through testing that the domain controller is contactable so in this particular case I will kick off a system discovery and then check back in shortly to see if the component status has updated to OK.

The theory here is the same for all faults.  You can look in the logs by checking the messages.  You can select to view from a specific time frame and narrow down what the issues may be, undertake some testing (in the case above simple network connectivity testing) and then see if this fixes the issue.  It is also possible to immediately reset the counts of errors and restart the component which should immediately reset the component status to OK so you can monitor to see if the error comes back however I’m not overly fond of that method but I’ll leave that decision up to you.  To do this you would simply right click and chose to reset counts.  Thereafter right click again and select Start > Configuration Manager Service Manager you would then find your component and cycle it or stop & start.

Obviously each task within ConfigMgr has a log, depending on what you’re doing and what you’re troubleshooting will determine what log to look at.  You should by now be using CMTrace to examine your logs.  This tool is really useful if you want to drill down in the log and not get lost in the ‘white noise’ that spews into it.  For those unaware it finds certain keywords in the log file (.log) such as “error”, “failure” or “warning”) and highlights them accordingly.  You can drill through the log file and narrow down where and issue might be. 

Top tip! – Don’t just read the highlighted lines.  Lines that are NOT highlighted around where the error is can also give you clues as to what's happening

Specific Error (Distribution Point): The package data in WMI is not consistent to PkgLib
I have an ever increasing distribution point collection at my place of work.  We have to place one in each geographical site we support and as that number grows so does the amount of DP’s I have to manage.  I use Distribution Point groups to create groups of DP’s I can distribute content to and therefore once I add on a new DP and it is created successfully, it is added to the group and the corresponding content is distributed down.  Simple huh?  Well I’ve noticed a trend happening just recently that’s weird on one or two distribution points.  The content fails to validate and I’m seeing a yellow triangle on the Distribution Point Configuration node.

My first port of call was to trigger a validation process, you can do this by running smsdpusage.exe.  If you look in your task scheduler list, under configuration manager, you will see that this event is triggered at certain intervals, mine is every day at 23:00.


This task runs:

So we can always run this manually and have a look at the results later on.

Content still showing as error processing?  OK then perhaps we need to turn to PowerShell for this one. I found a cool script (see references Link 3) that I’ll paste here:

   1: $WMIPkgList = Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib | Select -ExpandProperty PackageID | Sort-Object
   2: $ContentLib = (Get-ItemProperty -path HKLM:SOFTWARE\Microsoft\SMS\DP -Name ContentLibraryPath)
   3: $PkgLibPath = ($ContentLib.ContentLibraryPath) + "\PkgLib"
   4: $PkgLibList = (Get-ChildItem $PkgLibPath | Select -ExpandProperty Name | Sort-Object)
   5: $PkgLibList = ($PKgLibList | ForEach-Object {$_.replace(".INI","")})
   6: $PksinWMIButNotContentLib = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq "<=" } 
   7: $PksinContentLibButNotWMI = Compare-Object -ReferenceObject $WMIPkgList -DifferenceObject $PKgLibList -PassThru | Where-Object { $_.SideIndicator -eq "=>" } 
   8: Write-Host Items in WMI but not the Content Library
   9: Write-Host ========================================
  10: $PksinWMIButNotContentLib
  11: Write-Host Items in Content Library but not WMI
  12: Write-Host ====================================
  13: $PksinContentLibButNotWMI
  16: #Foreach ($Pkg in $PksinWMIButNotContentLib){ Get-WmiObject -Namespace Root\SCCMDP -Class SMS_PackagesInContLib -Filter "PackageID = '$Pkg'" | Remove-WmiObject }
  17: #Foreach ($Pkg in $PksinContentLibButNotWMI){ Remove-Item -Path "$PkgLibPath\$Pkg.INI"}

Notice I have commented out the bottom two lines, so you can run the script and confirm before you take any action.  When you run this is will tell you which package ID are problematic.

Once this has been run and anomalies cleared up you can try a content validation again.  Should this fail you can start to examine which packages are problematic from the results of the script.  Sometimes editing the application to create a new version number will force a correct sync through on the DP, sometimes you’ll need to be brutal and pull the package from every DP and re-create another one.  But eventually, following the steps above this should be cured.  Just a word of advice, be patient!

Specific Error (Software Update Point): WSUS Configuration Manager failed to configure upstream server settings on WSUS Server

Noticed this one appearing every so often on my SUPs too. An error appears on a few components like so..


If you look at the logs for the SMS_WSUS_CONFIGURATION_MANAGER you will see lots of instances of Error Message ID 6600 which states


To solve this you simply follow the solution, crack open IIS and if you drill down to Application Pools you should notice that the WSUSPool has stopped.  Simply start it again and then wait for things to sort themselves out. 


I hope this has been useful for you.

Thanks for reading.

Link 1 – Troubleshooting Content, by Peter Daalmans
Link 2 – Content Validation, by Peter van der Woude
Link 3 – Content Validation Issues in SCCM 2012, by Jos Lieben