Home Made SCCM Videos: Log File Investigation Series Part 1

This is an continuation to previous video: 

http://cmxp.blogspot.sg/2016/01/home-made-sccm-videos-cmtrace-intro.html

In this episode I will touch on the workflow of a typical software distribution cycle, once we understand the workflow we can match the respective log file to the workflow which will be easier for administrator to troubleshoot any issues that arises from software distribution: 

Here's the blog that compliments the above video: 

http://cmxp.blogspot.sg/2015/10/log-file-investigation-part-7-software.html

I hope you guys enjoy this video!. :) 

Happy watching. 

SY 

Log File Investigation Part 8 (Software Distribution End To End Log Investigation)

With sweat and tears, the mapping is complete, now looking at it, it will definitely be easier to look at which log file. A thing to note the logs displayed here are based on application deployment not package based deployment. If it is package deployment it will be easier, Just replace the app log file with execmgr.log instead will do fine. 

Here's the diagram: 

And in case you want to re-read the whole series so far:

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-1.html

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-2.html

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-3.html

http://cmxp.blogspot.sg/2015/06/log-file-investigation-part-4.html

http://cmxp.blogspot.sg/2015/08/log-file-investigation-part-5-software.html

http://cmxp.blogspot.sg/2015/08/log-file-investigation-part-6-software.html

http://cmxp.blogspot.sg/2015/10/log-file-investigation-part-7-software.html

Happy reading! :) 

SY 

Log File Investigation Part 7 (Software Distribution End To End Overview)

Well, I certainly didn't see myself writing up to 7 parts of log file investigation series. While there is certainly no fan base, from time to time when I pass such workflow to friends and colleagues, it certainly helped them to cut short the log file hunt. 

So I thought, why not I do it for software distribution as well? Even though I did highlight on the previous series, part 7 & 8 will be more comprehensive. Here is a typical flow of software distribution. I try to be more generic and possible the below flow might differ from environment to environment. 

Here it is: 

Don't forget to check out the rest of the log investigation series blogs as well: 


http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-1.html

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-2.html

http://cmxp.blogspot.sg/2015/04/log-file-investigation-part-3.html

http://cmxp.blogspot.sg/2015/06/log-file-investigation-part-4.html

http://cmxp.blogspot.sg/2015/08/log-file-investigation-part-5-software.html

http://cmxp.blogspot.sg/2015/08/log-file-investigation-part-6-software.html

Happy reading! :) 

SY 

Using PowerShell To Check The OS Architecture

This post was actually inspired by the previous post: 

Using Batch File To Check The OS Architecture

I was thinking using Powershell instead, the previous batch file serves the purpose, check for that particular folder and wah la you got your program installed. But I want to tap on Powershell's advance feature to ensure that the machine is really on 64 bit OS to install. 

So here goes: 

$OSArchitecture = (Get-WmiObject -Class Win32_OperatingSystem | Select-Object OSArchitecture -ErrorAction Stop).OSArchitecture

if ($OSArchitecture -eq '64-bit')

{& path:\a.exe}

else

{& path:\b.exe}

The idea is to use Powershell to check on the OS architecture. The strings behind Win32_OperatingSystem can be found here

You will need to change the variable yourself for the software path. 

Afterwards you can deploy the a batch file to invoke the above Powershell script to install the programs. Make sure you add in the required installation parameters as well. 

In case you do not know how to use a batch file to run Powershell scripts you can take a look of my previous posts on simple scripting to get the job done: 

Clear CCMCache Contents

Using Batch File To Check The OS Architecture

Software inventory using PowerShell

Enjoy!

SY

Using Batch File To Check The OS Architecture

Today is a interesting day, whereby client wanted to deploy 2 versions Java (32 and 64 bits) to client machines.


One of the easier method is to use "Platform requirements" under Package:

and the other deployment method, choose "Requirements" under Application deployment to allow the package to detect the OS architecture of the client to install the appropriate version of the software.

The above method works fine, if you deploy just a 32 bit application, or you could exclude the OS versions. But you what if you have specific requirements that you need to deploy the 32 and 64 bits applications to respective OS? Well you could deploy two times or you use the following batch file to deploy: 

=====================================

@echo off

SET LogLoc=C:\LOGS

SET AppName=JAVA83_Install

IF NOT EXIST "%LogLoc%" (

MKDIR "%LogLoc%"

ECHO %DATE% %TIME% - %LogLoc% created >> %LogLoc%\%AppName%.log

) ELSE (

ECHO %DATE% %TIME% - %AppName% started >> %LogLoc%\%AppName%.log

)

IF EXIST "C:\Program Files (x86)" ("amd64/03-Java83.exe" /s) else ("x86/03-Java83.exe" /s)

ECHO %DATE% %TIME% - checking processor architecture - %CPUArch% >> %LogLoc%\%AppName%.log

ECHO %DATE% %TIME% - Starting JAVA 8 U31 Installation on %computername% >> %LogLoc%\%AppName%.log

SET ErrorCode=%ERRORLEVEL%

ECHO %DATE% %TIME% - Exit Code is - %ErrorCode% >> %LogLoc%\%AppName%.log

ECHO %DATE% %TIME% - Exiting Installation >> %LogLoc%\%AppName%.log

Exit %ErrorCode%

pause

=====================================

Copy and paste the above batch command, save as "CMD" or "BAT" . Change the files location and application name on the highlighted portion and deploy it under "Package" and you are good to go. 

This lead me to think, can I use Powershell to achieve it instead? :) 

Give you guys a update soon, hope you guys like it. 

Have fun. 

SY

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