Update: After viewing my blog post I realized all the images I imbedded are too big for the little bit of space I get, so you'll see tons of links below... sorry for that.
After a little discussion on the email list about the MIFs that pointed pointed to an article that referenced the execmgr.log, I figured I'd do a little post on the execmgr.log.
The execmgr.log log records all advertisements that run. Below is a snip from the log file for a successful install execution of program that was advertised to a computer. It has been santized to not give out site specific information. I'll begin discussion of the log below the image.
This log snip takes you from the computer receiving the policy through the successfull running of the advertisement. The tool I used in the example to view logs is trace32, which can be found in the ConfigMgr 2007 Toolkit.
The ConfigMgr log files are very detailed and describe in plain english (most of the the time) what's happening. A lot of the lines of the log are self explanatory, but we'll take a look at a few.
Line 4: "Requesting content from CAS for package [packageID] version 8
What you want to do when you see "CAS" in a line is take a peak at the cas.log on your client system. What the cas.log logs is the Content Access Service, maintains the local package cache. In this case, if we look at the cas.log during that timeframe we see the following:
What the above cas.log shows us is where the package will be run from or downloaded from , depending the settings of the package. As you can see in the log it gets the content name and size. It'll request to get the locations where it it can download the file from, once it gets this information it'll pick one. Now, let's go back to the execmgr.log
After line 4 and 5 ConfigMgr will verify the package and that it is available. As you can see in the log, this was an optional program. Once the advertisement is run, we'll see the program that is being executed. In our case it shows us the script that is being executed, in line 12 of the snip.
You'll notice in the next line that state change for the program changes from NotExist to NotifyExecution.
Make note of the first warning line, line 16. for this install this error doesn't affect us at all, since scripts do not contain a resource section. Which is what error code 1812 means, so this is expected behavior. To get the exact definition of error code 1812, I used functionality in trace32 to look it up: to look up error codes in trace32, press ctrl + L and an error lookup box will appear, enter in your error code and click lookup. Please note, not every error code definition will be available in trace32, if trace32 doesn't have the definition, google the error code.
In line19 it shows you the commandline that will be run. In our case Windows know .vbs needs to be run by WScript, so it uses that executable. We also specified in our package to run the program from the DP, so it lists our working directory as one of our DPs.
In line 22, you'll see "Raised Program Started Event..." that means that your program is now executing.
NOTE: lines 23-25 can be ignored in this example that is a different test package. I left them in there so you can see that multiple actions can and do take place as once in the configmgr client.
Line 26: Is the line we always want to see, "Program exit code 0" This means the program executed successfully.
In the next couple lines you'll see it raise the success event and then in the las t line it will write out that the execution status is Success.
Now, we've just walked through a successful advertisement run. But now you ask, what other logs are out there that had a hand in this. Well, let's look a few:
ccmexec.log, what it does: records activities of the client and the SMS Agent Host Service
What's going on in it during the process we just walked through, well here's a snip.
This log line was writting 9:23:23 AM.
We run in native mode, you will see entries in the ClientAuth.log:
If you see copious errors in the ClientAuth.log like, "There are no certificates in the 'MY' store." You likely do not have a certificate for your computer. But that's a post for a different day, moving on.
The client also needs to know what server is it's site, this is logged in the clientlocation.log.
We also have the Data Transfer Service active at this time, which records all BITS communication. Though there isn't much activity here, since we ran the package from the DP.
Also, there's activity in the locationservices.log, which logs the service getting the MPs and DPs.
Now you ask how many logs can there be, and my answer is more.
Our next log is the PolicyAgentProvider.log, which records policy changes:
We also have the scheduler.log, which records schedule tasks for client operations, you'll see mention of the program.
Are there more? Yes, there are... but I waited too long to decide to do this and the logs rolled over so screen shots are not available.
But this should get you started on using log files to troubleshoot software deployment errors.
So now you ask, are there professional flow charts out there to troubleshoot client issues. Yes, there are. You can begin to access them them at http://technet.microsoft.com/en-us/library/bb632812.aspx
As always there's a lot more out there, but I hope this helps you as you troubleshoot.