Log File Investigation Part 3 (Package Deployment Log Reading)

Welcome back to the returning episode of...

Ok not funny :P In this part 3 of the investigation series, I put more focus on Package deployment. IMHO, this portion is more catered like a transition portal for those packages that were created in CM 2007 to move to CM 2012.

This can be still useful, but moving on we should be adopting application deployment approach as application is more application aware and the deployment follow the users rather than their machines. (CM 2012 onward is more user centric)

As usually here are the following log file we will look into: 

1. CAS: Content Access service. Maintains the local package cache on the client.
   
   
2. Execmgr: Records details about packages and task sequences that run on the client.

The above definition was taken from: https://technet.microsoft.com/en-sg/library/hh427342.aspx#BKMK_ClientOpLogs

Strictly speaking, execmgr log file alone will do fine, why I add in a CAS log file, is because sometimes, your customer or boss could ask you how long it takes for a package of 500 mb or more to get delivered to the client machine and which ccmcache folder it will stored? That is why I throw in the CAS log file.

Now, the location of the CCM logs:

CAS log:

What the above literally means is that at the stated point of date and time (because of the length, I trimmed the date and time on the far left) the client has detected a deployment, it will attempt to download from SCCM server, and download the items to the folder that is created in CCMCache folder, in this example the folder name is ‘2’.

At the end of the log file you will see that the content is successfully save with the Content ID. That is why, I mentioned in part 2 that it will be better to turn on the header view with Package and Content ID so that you know what you are looking at: http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-2.html

 Next we will look at Execmgr.log file:

You could do some comparison with CAS log file, both files should be updating almost at the same, what the log is trying to tell you is that it receives a deployment and it is ready to get the package to be installed after the download is complete it will go to the CCMCache folder execute the script in folder 2, the system will actually decide whether it has pass the command line or not, should your script installation parameter is wrong it will not go ahead, and if the installation parameter is correct then it will pass the command and gives you a program exit code of 0.

Happy investigating! J

SY

Log File Investigation Part 2 (Application Deployment Log Reading)

Ok, back at my last article here: http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-1.html

I mentioned that there is 57 log files just in a client folder alone. But when I ran through my lab this morning I realise it was, it was a test for you guys to spot my mistake, but obviously I fail this test myself as well :P 

My bad, well, this is more painful than I thought, 74 log files. So which log file to begin with?

http://en.wikipedia.org/wiki/CSI:_Cyber#/media/File:CSI-Cyber-Logo.jpg 

The above picture flash into mind, whenever we need to start a trace software distribution.  I think it would be easier if we know the flow. Take note my workflow could be easily improvise, you may have your own flow, but this is something I have used most of the time, and it works well for me. 

It will be definitely very time consuming, if you do not know which log file to trace and look at.

In the second part of the investigation series, I will explore Application and Package deployment log files, if I have the time I will explore Software Updates (Security Updates) as well. Today I will put emphasis on Application deployment.

There will be always be an argument on using packages vs applications. The argument itself is already worthy for a page of blog. Maybe I find some time to sit down and set out the differences. Meanwhile SCCM Team Blog has written a nice article between the differences of two features back in 2012: http://blogs.technet.com/b/configmgrteam/archive/2012/03/31/introducing-the-application-catalog-and-software-center-in-system-center-2012-configuration-manager.aspx

Right let us start with the action shall we? In my lab I have deployed 7-Zip as application.

You could do a right click on the header in the deployment tab, turn on Deployment and Package ID. Trust me it will be very useful in tracing your stuff when you investigate your log file later.

Next we go to our client machine to check the deployment flow and status. For those who don’t know the path of the client log files:

C:\Windows\CMM\Logs 

Next we zoom in two log files: 

1. AppDiscovery: Records details about the discovery or detection of applications on client computers.
2. AppEnforce: Records details about enforcement actions (install and uninstall) taken for applications on the client.

Description of the log files are taken from: https://technet.microsoft.com/en-sg/library/hh427342.aspx#BKMK_AppManageLog

First, AppDiscovery log will allow you to see that the application that deployed. What it will do is that it will detect the version for the target machine. If the target machine has the product, it will proceed to uninstall it and install with the current version.

Next, AppEnforce log will let you see where is your file placed in the ccmcache folder, and how it execute the installation command. (msiexec.exe command and parameter) and the exit code for the program installation is recorded in here. Remember, exitcode: 0 will be your most pleasing code. 

Have fun investigating! :) 

SY

Log File Investigation Part 1 (CMTrace Tool Introduction)

A lot of time SCCM administrator face a daunting task software distribution related task. So I thought, it would be nice to share my log reading experience (you might probably know it already) here, and this will also act a constant reminder for myself to follow the steps. 

But in this first part of the blog, let us just have a fairly short introduction of the things we need for a typical troubleshooting process. You might already know, but I will list it anyway: 

1) CMTrace executable: This is a must have and most administrator would have know it by know. Use to be SMS Trace: 

So the useful part of this utility that I often use most is highlight and error lookup tool: 

Select the option "Highlight" under Tools, and think of a keyword to put in. 

For this example, I used "program" and CMTrace will highlight any line that contains the keyword "Program" as shown here

This will actually help you to zoom in the log file faster. 

Next will be the error lookup option (CTRL+L) this serves as a error code dictionary however base on personal experience not ALL the error codes can be found here, but this is a good place to start with: 

Not all error codes are reflected here, I am showing you the common ones, some description are very generic, like the one you see above is 1603, fatal error could be anything, you will need to source for the root for the error, chances are, corrupted installation files or in my experience the machine did not meet the software installation pre-requisites thus you see this error. 

To finish off part 1. Here is a place you cannot afford to miss: 

https://technet.microsoft.com/en-sg/library/hh427342.aspx

Yes, that's right, after all it is log file we are after. Over the years, MS has done a great job in categorising the logs, in SCCM 2012, they categorise the logs in server and client portion and so on. 

But there is this mind boggling question. Look at the client side log files. Client side alone is around 57 log files. So erm...which file do we start with to look at? 

Till then, part 2 will explain more....:) 

SY

Clear CCMCache Contents

Re-editing this old post from former blog, you could deploy it as a batch file to your SSP (Self-Service Portal) in SCCM Application Catalog page and allow the user to clear the content on their own instead of:

Here is the PS command, I added a "Force" parameter to it: 

#Removes the contents of CCMCACHE folder 

Remove-Item -Path C:\Windows\CCMCahce\* -Force -Recurse

Save the above PS commands as XXXX.PS1

The batch file that is required to run the above PS command: 

@ECHO OFF

SET PSScriptDir=%~dp0

SET PSScriptPath=%PSScriptDir%RemoveCCMCacheContents.ps1

PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& '%PSScriptPath%'";

pause

Make sure you save the above as XXXX.CMD

Save both files in the same directory (Less than 3KB) and you are ready to go!

Have Fun :) 

SY

My First Post...again :P

I will share a lot of random stuff that comes into my mind most of them are SCCM stuff, else it will some random stuff that I find it awesome that is related to Microsoft technologies.

My next to do list is learn and use PowerShell even more...and hmm...more to come :P

It is only when we share, we get to learn even more. :)

SY