SCCM client log files located under c:\windows\ccm\logs have a huge list of log files. This can be daunting for beginners to think about which logs should they be checking in various scenarios such as application deployment, package deployment, task sequence, hardware/ software inventory, software metering etc.
If we know the correct set of log files required for specific component, this will help us analyse and troubleshoot the issue.
I will also be sharing few SCCM tips and tricks to read the log files efficiently. Using below mentioned techniques will help you analysing the logs more easily with least efforts.
- Dividing SCCM client logs into multiple sections
- How to read SCCM log files efficiently
- Tips for troubleshooting Operating System Deployment logs
Dividing SCCM client logs into multiple sections
I will be breaking down the list into specific sections to understand it properly. There will be few log files which will be commonly used for:
- Application / Deployment type log files
- Package Deployment log files
- Task Sequence log files
- Hardware inventory / Software Inventory
For Application log files, here I am specifically talking about application model on configuration manager which consists of application and Deployment type. These are the most of important log files related to application deployment:
For in-depth explanation upon Application / Deployment type log files, check the link Track SCCM Application deployment through client log flow
For Package log files, I am specifically talking about log files related to package & programs created on Configuration manager. Following are the useful log files related to package deployment:
For in depth explanation upon Package / Program log files, check the link Track SCCM Package deployment through client log flow
Task Sequence log files
The Foremost important log file for task sequence is smsts.log. The location of this log is c:\windows\ccm\logs, however when the task sequence is running the location would be c:\windows\ccm\logs\SMSTSlog\smsts.log. Once the task sequence execution is completed smsts.log will be moved to its original location ie. c:\windows\ccm\logs and SMSTSlog folder will be deleted. Smsts.log is the master log file consists of everything task sequence steps are supposed to do. But this doesn’t mean that you should only be checking this log file. This is the complete list of log files related to task sequence:
- Smsts.log – This is a master log file. This log file will only create when executing a task sequence. The location of smsts.log can have several location. Before applying Operating system step – you can find the location as
x:\windows\temp\smstslog (Before OS install)
c:\_SMSTaskSequence\Logs\smstslog (After OS install and before SCCM client install)
c:\windows\ccm\logs (After OS install and SCCM client install)
You may check smstslog log location and how to copy logs for more details
- Appenforce.log – Check this log file if you wanted to see and verify Application installation issue. I would say AppEnforce.log is the master log file related to application installation.
- AppDiscovery.log – Appdiscovery is the companion log file to AppEnforce component which discovers the application. If application is not discovered then only Application installation will trigger.
- AppIntentEval.log– AppIntentEval component is responsible for checking the dependencies such as if any application setting is having dependency to install other application. This component will forward the request to AppEnforce so that all the components / applications can be installed.
- Execmgr.log – Execmgr component is a master log file for package / program deployment for legacy packages. This is a pretty much straight forward log file unlike various App logfiles for Application deployment.
- cas.log – To access the content CAS component is creatd. This log file is applicable for both application and package deployment. It performs 2 tasks:
- To locate the content on DP using CAS Job– locationservices.log is further responsible for this
- To download content – ContentTransferManager.log is responsible for this
- LocationServices.log – Location Services will list number of DP’s where content is located and handover the job to CAS
- contenttransfermanager.log– Content download will be handled by this component as Content Transfer Manager job was created by cas
- datatransferservice.log – Data Transfer Service component comes into action to download the content and once downloaded, it will transfer back the information to contenttransfermanager component.
How to read SCCM log files efficiently
Log files can be opened with notepad, however the format will not be nice. You will not be able to see color coding of any error message. All the content will be in a format which will not be easy to read.
Benefits of using cmtrace tool
Using cmtrace tool to read the log files comes with so many benefits which we will be discussing below.
- With cmtrace – log files are easy to read
- Cmtrace reads the log files in live scenario, so as when the log files are updated, content opened with cmtrace will also keep on updating to show current data unlike notepad where you need to re-open the file again to get latest data.
- With cmtrace, its easy to find error code or exit code. Color coding like yellow (for warning) and read (for error) makes life very simple to detect and analyse the error.
- Cmtrace allows you to filter the log file to look for specific lines only.
- Cmtrace is having highlight feature so as specific keywords you are looking for will be highlighted within the logs.
Location of cmtrace tool
CMtrace.exe is inbuilt tool which comes as part of Configuration Manager installation.
- You can find the tool under c:\Program Files\Microsoft Configuration Manager\Tool\cmtrace.exe.
- You can also find this tool (cmtrace.exe) on client side where Configuration client is installed. The location will be c:\windows\ccm\cmtrace.exe
Cmtrace vs notepad
You can see the comparison of log files when opened with notepad vs cmtrace.
While opening smsts.log with cmtrace, we can see how neatly the content is organized with each and every content on different line along with component name, date/time and thread name displayed.
Cmtrace is such a great tool that it is not limited to configuration manager logs but it has been widely used by administrator from various other fields.
Cmtrace is so rich in features that can help SCCM administrators to troubleshoot in various ways. Let’s discuss on few of the tips and tricks for cmtrace to check the logs.
Combine multiple files together using cmtrace
Rather than checking each and every log files separately, you can combine multiple log files together so as to check the log flow from not only multiple log files, but from various different components (log files).
For example: you can combine all together smsts.log, AppEnforce.log, AppDiscovery.log,CAS.log,ContentTransferManager.log.
For this, open cmtrace and go to File > Open. While location c:\windows\ccm\logs selected, click on Merge selected files and select multiple log files (Use Ctrl key to select multiple log files) and click Open.
We can see multiple log files are merged together and all selected log files and components are visible which makes troubleshooting easy.
Search for specific keyword to look for success / failure
Searching for specific keyword for monitoring success for each step is very crucial. Press Ctrl + F or Tools > Find to open Find window, search for “exit win32” and click on “Find”
The reason I have used “Exit win32” is that it shows success or failure for each task sequence step or each application / packaging installation step. Just keep on pressing F3 to search the exit win32 code.
Message was captured:
“Successfully completed the action (Partition Disk 0 – UEFI) with the exit win32 code 0”.
Exit code 0 means success, if 3010 – again success but reboot required.
Use filter feature in cmtrace
Filtering few keywords can be very handy for troubleshooting to see filtered words. For example, let’s use “exit win32” as filter will show list of all steps with success / failure code.
Click on Tools > Filter to open Filter settings. Check “Filter when the Entry Text” select drop down menu as Contains with text “exit win32”.
This displays list of all steps showing “exit win32” with exit code 0 which means success. If any step would have failed, it would be in red color with different error code number.
Use Highlight feature in cmtrace
Searching for specific keyword will highlight with yellow background color. Go to Tools > Highlight and search for a string, let’s say “windows”. All the lines with keyword “window” will be highlighted as yellow.
Default highlighter color is yellow, if you wanted to change the color, go to File > Preference and specify “Use this color for highlighting log entries” and select color of your choice
Look for Error Code
This is one of the best cmtrace tool features to look for error code. Once you see any error message, just press Ctrl + L to bring Error Lookup window. Type the error code (let’s say 0x80070002) and you will see cmtrace has translated the error code into readable format ie. “The system cannot find the file specified” such as Green color
Misc other settings
You may also Pause the log file in a scenario where deployment is running and you are watching the log file, and you don’t wanted to go further as log file will keep on scrolling to last line. Hence, pause it to take your own time analysing the content.
Tips for troubleshooting Operating System Deployment logs
This is one of my preferred way, I hope other experts might also be doing it. Just thought of sharing this. As we know task sequence may consist of several steps, sometimes it could be 100’s of steps, and if task sequence fails, it could be overwhelming to go through the logs.
Hence, the best way to look into the logs is to combine all smsts.log & historical smsts.log (it could be in format smsts_.log or smsts-yyyymmdd-hhmmss format) using merge feature. Once combined, scroll to the last line. Press Ctrl + F to search for “Exit win32” and search backwards by clicking Direction “Up”.
By this way, you will stumble upon error very soon, may be at first go because task sequence would have failed at the step which is at the end and scrolling from last in upwards direction will take you to the error much more quicker rather than starting from top.