Deep Dive SCCM Application Model Troubleshooting – Client End

Hello, I’m Nitin Chhabra. I worked as a Microsoft support engineer specializing in SCCM Application Deployment technology for several years. I am an SME in Application deployment, Software Update deployment and OSD.

This post will focus on the SCCM Application Deployment on the client side and continue my previous blog to dive deep into the SCCM Application Model Troubleshooting (Server Side).

The application model in SCCM is CI (Configuration Item) based, which provides us with a lot of flexibility in customization, planning, and rolling out software in an Enterprise environment. However, this flexibility can complicate troubleshooting a failed deployment.

This post will help you learn the client-side flow for application deployment. To understand each component’s functionality, let us take the “Notepad++” application deployment as an example.

Patch My PC
[sibwp_form id=2]
Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.1
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.1

Please follow my previous post to learn how to dive deep into a background process while creating an application on the SCCM console.

Index
Major Components Involved in SCCM Application Model Client-Side Troubleshooting
Policy Agent
CCM Messaging
MP Policy Manager
Data Transfer Service
Policy Evaluator
CI State Store
CI Store
CI Agent & CI Downloader
App Discovery
Expression Solver
App Intent Eval
CCM SDK Provider
CAS
App Enforce
Conclusion
Resources
Deep Dive SCCM Application Model Troubleshooting – Client End – Table 1

Major Components Involved in SCCM Application Model Client-Side Troubleshooting

The SCCM client will run the “Machine Policy Retrieval and Evaluation Cycle” to download the assigned policies to the machine. The Policy Agent is the component responsible for downloading the policy. We will discuss each component in detail.

Policy Agent

This component fetches the policies from the Management Point by building an assignment request. This request includes client GUID, Policy Source, NetBios Name, and Policy Type (machine or user). The log file associated with this component is PolicyAgent.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.2
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.2

CCM Messaging

Policy Agent will pass the control to CCM Messaging, which initiates a remote sync message for the Management Point. This component performs almost every communication from the SCCM client to MP. It initiates the BITS session to connect to MP; the connection is made on port 80/443 as per the client configuration.

Adaptiva

The log file associated with this component is CCMMessaging.log. If you have any connection issues with MP, like firewall port blocking, network packet drop, or MP host-name not being resolvable, you will see error messages in this log file.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.3
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.3

MP Policy Manager

On the Management point, the MP Policy Manager will service the client’s policy request by providing a new/updated set of policies.

After receiving a request from the client, this component fetches the policies from the SCCM Database (Primary/Secondary site database). The log file associated with this component is MP_Policy.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.4
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.4

If you scroll down this log after you see the client request, you will see the new policy details for the client. This includes Policy ID, which is your Deployment ID, Policy Type (Machine/User), Policy Category, etc.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.5
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.5

Data Transfer Service

Policy Agent will initiate Data Transfer Service to start the download of Policy from Management Point. All the download, which the SCCM client does, uses Data Transfer Service for that.

We will see the request initiation in PolicyAgent.log and the actual download details in DataTransferService.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.6
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.6
Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.7
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.7

Data Transfer Service will download the policy and place it in the “CCM\Temp” directory. DTS will check if the directory is present and create the same if not found.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.8
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.8

Policy Evaluator

After the policy is downloaded, the Policy Evaluator is initiated, compiling and applying the policy. This component is responsible for adding the evaluated policy in the actual config of the WMI(\\root\ccm\policy\machine\actualconfig).

The log file for this component is PolicyEvaluator.log. I have trimmed some of the lines in the log to focus on the pointers of interest.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.9
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.9

Once the policy is evaluated, the CI (Configuration Item) components activate and process the application’s deployment on the client machine.

CI State Store

This is the first component triggered after the policy is successfully compiled. It further initiates CCMSqlCE to check the details of the CI. Each client machine maintains a small database for application CIs, known as ccmstore.sdf, which is located in the client’s install directory.

CCMSqlCE is the component that helps in opening a session with this DB and getting the required information. The associated log file is CIStateStore.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.10
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.10

CI Store

This component works in conjunction with the CI State Store and lists information about CI. It checks whether the application deployment is for the user or the system. The associated log file is CIStore.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.11
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.11

CI Agent & CI Downloader

Once the client has validated the details of the CIs, the CI Agent is triggered to download the complete content of the CI and related SDM packages. The CI Agent will create a job for the CI Downloader to start the CI download, which further uses the Data Transfer Service to perform the actual download. The log files associated with these components are CIAgent.log and CIDownloader.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.12
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.12
Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.13
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.13

Data Transfer Service downloads the CI content in a staging directory (C:\Windows\ccm\CIDownloader\Staging)

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.14
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.14

Once CIs are completely downloaded, the TransitionState will be updated, and the same is listed in CIAgent.log. Policy Platform client (a prerequisite of the SCCM client) will process the SDM packages downloaded for the CI’s.

Note: The SDM (Service Definition Model) package uses the SML (Service Definition Language).

App Discovery

After the CI’s of the application are downloaded and processed, the App Discovery component takes the command to detect the application on the client machine. It initiates the Expression Solver component, which will run the detection logic defined in the deployment type to determine the status of the application. The log file associated with this component is AppDiscovery.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.15
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.15

Expression Solver

This component runs the detection logic defined in an Application deployment type. Depending on the detection logic evaluation, it gives a Boolean output value (True/False). The log file for this component is ExpressionSolver.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.16
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.16

Once we have the result from Expression Solver(which is set to False), App Discovery marks the application as not discovered and triggers the App Intent Eval component.

App Intent Eval

This component will evaluate the application’s intended state and check for any requirement, supersedence, or dependency defined in the Application. The log file associated with this component is AppIntentEval.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.17
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.17

The output from the APP Intent Eval will be given to the CI State Store and CI Agent and added to the CCMStore.sdf. After this, the CI Agent sets the TransitionState to “CompletedSdmMethodInvocation.”

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.18
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.18

The steps mentioned above will happen when the machine gets the policy for a new application. Till now, we have not started any installation from the Software Center.

We will see the deployment details if we connect to the client machine’s WMI and check the CCM_ApplicationCIAssignment class.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.19
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.19

Now let’s trigger the application install from the Software Center and study the components involved.

CCM SDK Provider

CCM SDK Provider will mark the initiation of the install from the Software Center, and the CI Agent job is created for the client machine. All the CI transitioned from evaluation, then download, and finally, the DCM agent logged enforcement. The associated log file is CCMSDKProvider.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.20
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.20

After this, we will see the App Discovery is triggered again to check the application state on the machine, so the same process mentioned above will be repeated for App Discovery, Expression Solver, and App Intent Eval.

Once the application is not found installed, CAS (Content Access Service) is called to download content for the application.

CAS

Content Access Service is the component responsible for providing the application’s content. It starts a job for Content Transfer Manager according to the DP location received from the client machine’s boundary. The log file for this component is CAS.log.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.21
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.21

If the CAS can find the content in the local cache, it will match the content version with the required one. Otherwise, a CTM (Content Transfer Manager) job would be created, which would then create a DTS (Data Transfer Service) job to start downloading the data from the Distribution Point.

App Enforce

Once the content is downloaded, this component is triggered, which starts the application’s enforcement or initiates the installation. However, it will check whether the application is already installed before installing. This is confirmed using App Discovery, and the above cycle repeats again.

Finally, the command line is triggered using the account type(system/user) mentioned in the deployment type. App Enforce keeps track of the command’s exit code. Based on the exit code, the application is marked as successful or failed. AppEnforce.log will list the activity performed by this component.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.22
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.22
Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.23
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.23

After the application installation, the exit code is returned to App Enforce, checking if the defined code is listed as a success in the Application configuration.

App Discovery is triggered to detect the Application on the machine if it succeeds, which completes the Enforcement. After this, a state message is raised mentioning the deployment’s compliance.

Deep Dive SCCM Application Model Troubleshooting - Client End - Fig.24
Deep Dive SCCM Application Model Troubleshooting – Client End – Fig.24

Conclusion

This completes the application’s enforcement. At each enforcement step, a state message is raised, which helps us report deployment compliance.

I hope you will find this post interesting and helpful in day-to-day troubleshooting.

Resources

We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.

Author

Nitin Chhabra has worked as a Microsoft support engineer specializing in SCCM Application Deployment technology for several years. He is considered an SME in Application, Software Update, and OSD deployment.

2 thoughts on “Deep Dive SCCM Application Model Troubleshooting – Client End”

  1. Excellent writeup. These kinds of deep dive into the full process flow of SCCM functionality are incredibly useful, and very much appreciated.

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.