原文连接

https://deploymentparts.wordpress.com/2015/08/14/how-to-track-an-installation-through-client-log-files/?tdsourcetag=s_pctim_aiomsg

If you ever need to track a software deployment on a client, you’ll have a bunch of log-files where you find answers. During a software deployment (and download) the following client log-files is invoked in the following order:

1. AppDiscovery.log

2. AppIntentEval.log

3. AppDiscovery.log

4. CAS.log

5. ContentTransferManager.log

6. DataTransferService.log

7. ContentTransferManager.log

8. CAS.log

9. AppEnforce.log

10. AppIntentEval.log

The log-files can be found on the client C:\Windows\CCM\Logs. When tracking the deployment, two identifiers are needed; the unique ID of the applications Deployment Type, and the ContentID. The first can be found up front, while the latter can be found in AppDiscovery.log.

Credit due: Adam Pazik wrote a great article which inspired to this post.

How to get the Unique ID used for tracking (the long version)

When tracking an installation, the unique ID of the applications deployment type is used. If you just want to get that one, skip to the end of this section. If you want to know more, read on..

Everything in ConfigMgr has a unique ID, and the same goes for both Applications and their Deployment Types. The unique ID for Applications (CI_UniqueID) looks like this:

ScopeId_9D808D91-5ABE-48AC-908B-ADA69B7208CE/Application_f9d92c28-d4b6-40f6-bf9e-9c50a0db9856/4

The ScopeId_ part is the Authoring Scope, which is unique to the site server, the Application_ part is unique to the application, and finally the “/4” indicates that this is the fourth revision of the application (each time you change something in the Console, the revision increases). If you are interested, you can determine the Authoring Scope using this PowerShell code:

This would produce “{9D808D91-5ABE-48AC-908B-ADA69B7208CE}” in my test environment, which you can see matches the ScopeId part of the applications Unique ID.

Similar the applications deployment type also has an unique ID:

ScopeId_9D808D91-5ABE-48AC-908B-ADA69B7208CE/DeploymentType_fbfe859a-4810-4ba2-b86d-2013c62f586e/5

The same goes for the ScopeId_, DeploymentType_ and revision part. If you want to retrieve all Unique ID’s for an applications deployment type (say “Reader 11.0.12”), you can use the following code:

This will produce the following output:

Now, when tracking an installation the unique ID of the deployment type is used, but without the revision part (eg ScopeId_9D808D91-5ABE-48AC-908B-ADA69B7208CE/DeploymentType_fbfe859a-4810-4ba2-b86d-2013c62f586e). If you want to retrieve just that, you can use the ModelName property of SMS_DeploymentType instead of CI_UniqueID. The ModelName is actually the desired configuration management model name for the configuration item, but it gives just what we need. Change the previous PowerShell code slightly, and you get:

This gives us the unique part ScopeId_9D808D91-5ABE-48AC-908B-ADA69B7208CE/DeploymentType_fbfe859a-4810-4ba2-b86d-2013c62f586e we can use to track the installation in the ConfigMgr client log files.

Time to follow the white rabbit…

In the example shown here, an application has been deployed to a collection in which the computer is a member. Now, from the top down:

PolicyAgent.log: Tell the client that it have stuff to do

First the client needs to know that it has new application assignments. The client determines this during its machine policy cycle, which runs each 60 minute by default. You can also trigger this by running the Machine Policy Retrieval & Evaluation Cycle from the ConfigMgr Client, or from the ConfigMgr Console using Client Notification > Download Computer Policy. You can verify that the machine policy is started using PolicyAgent.log:

And further down the line, you can see it is told to get the policy for the application:

AppDiscovery.log: Is the application already installed?

All applications (not packages) in ConfigMgr 2012 contains detection methods, to determine if the application is installed. The detection method(s) run before and after an application is installed. This can be tracked in the AppDiscovery.log file, using the Deployment Type’s Unique ID. You can notice that AppDiscovery is Performing detection of app deployment type Reader 11.0.12 and Did not detection app deployment type Reader 11.0.12 (which is tracked using the unique id).

A note on the side: If the detection method does not work properly, and the ConfigMgr client was unable to verify that the application was properly installed (using the detection method), you will get a return code of 0x87D00324 in Software Center on the client.

Also, you will see that if an application is deployed to a computer, which already has the application installed (as determined by the detection method), the installation files will never be downloaded to the computer. This is a nice consequence of the Application Model in ConfigMgr 2012.

AppIntentEval.log: Does the application have any dependencies?

AppIntentEval.log now takes over, and determines if there are any required dependencies to the application:

AppDiscovery.log: Lets continue and get the content

Back in AppDiscovery.log we see that the installation should continue, and which content should be used for the installation (the Content Id):

The Content Id Content_049f55eb-9172-4b84-890d-332a3a735a59 is now used to track the content download.

CAS.log: Do the client already have the content?

The CAS (Content Access Service), which maintains the local package cache, checks if it already has the content. In this case the content is not present in the cache:

If the content already was in the client cache, CAS.log would write the following instead:

CAS.log now instructs ContentTransferManager.log to initiate the download.

ContentTransferManager.log: Who should download the content?

ConfigMgr 2012 normally uses BITS to download content from the distribution point. However, ConfigMgr 2012 also supports Alternative Content Providers (such as 1E Nomad) to handle the content download. ContentTransferManager.log is the one who determines how the content should be downloaded. In this case, the download request is handed over to DataTransferService.log:

DataTransferService.log: Downloading the content

In DataTransferService.log it is possible to track the complete download process.

ContentTransferManager.log: Notified of download complete

Following the chain back to the surface, we see that ContentTransferManager.log is notified:

CAS.log: Notified of download complete, again

Which in turn notifies CAS.log:

AppEnforce.log: Installing the application

Now we have the installation files, it is time to start the installation. AppEnforce.log reveals the details of this:

Here you can see all the good installation stuff, as well as the second check using the detection method of the Application.

AppIntentEval.log: Final check

Finally, the AppIntentEval.log reveals that the application is installed (Current State = Installed):

This concludes this small walk through of the client log-files used when deploying software.

Now, what would be really cool is that if one wrote a PowerShell script to track the files log-files! Perhaps some day..