Hello, I’m Nitin Chhabra. I worked for several years as a Microsoft support engineer specializing in SCCM Application Deployment technology. I am SME in Application deployment, Software Update deployment, & OSD.
This post will focus on the SCCM Application Deployment on the client-side and continues my previous blog to dive deep into the SCCM Application Model Troubleshooting (Server Side).
Introduction
The application model in SCCM is CI (Configuration Item) based, which provides us a lot of flexibility in customization, planning, and rolling out software in an Enterprise environment. However, this flexibility brings in complexity while troubleshooting a failed deployment.
This post will help you in learning the client-side flow for application deployment. To understand each component’s functionality, let us take an example of the “Notepad++” application deployment.
Please follow my previous post to deep dive into a background process while creating an application on the SCCM console.
Major Components Involved in SCCM Application Model Client-Side Troubleshooting
The SCCM client will run the “Machine Policy Retrieval & Evaluation Cycle” to start downloading the assigned policies to the machine. Policy Agent is the component that is 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, Policy Type (either machine or user), etc. The log file associated with this component is PolicyAgent.log.
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.
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.
MP Policy Manager
On the Management point, MP Policy Manager will service the policy request raised by the client by providing the 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.
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.
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 actual download details in DataTransferService.log.
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.
Policy Evaluator
After the policy is downloaded, Policy Evaluator gets initiated, which compiles and applies 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.
Once the policy is evaluated, the CI (Configuration Item) components come into action and process the deployment of the application on the client machine.
CI State Store
This is the first component that is triggered after the policy is successfully compiled. This component further initiates CCMSqlCE to check the details of the CI. Each client machine maintains a small database for application CI’s, known as ccmstore.sdf, which is located in the install directory of the client.
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.
CI Store
This component works in conjunction with CI State Store and lists the information about CI. It checks the application deployment is for the user or the system. The associated log file is CIStore.log.
CI Agent & CI Downloader
Once the client has validated the details of the CI’s, CI Agent is triggered to download the complete content of CI and related SDM packages. The CI Agent will create a job for CI Downloader to start the CI download, which further uses the Data Transfer Service to perform the actual download. The log file associated with these components is CIAgent.log and CIDownloader.log.
Data Transfer Service downloads the CI content in a staging directory (C:\Windows\ccm\CIDownloader\Staging)
Once CI’s 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: SDM (Service Definition Model) package is built using 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.
Expression Solver
The purpose of this component is to run the detection logic defined in an Application deployment type. It gives a Boolean output value (True/False) depending upon the detection logic evaluation. The log file for this component is ExpressionSolver.log.
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. AppIntentEval.log is the log file associated with this component.
The output from the APP Intent Eval will be given to CI State Store and CI Agent, and the same is added in the CCMStore.sdf. After this, the CI Agent set the TransitionState to “CompletedSdmMethodInvocation.”
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.
If we connect to the WMI of the client machine and check the CCM_ApplicationCIAssignment class, we will see the deployment details.
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.
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 that is responsible for providing the content of the application. It starts a job for Content Transfer Manager as per the DP location received from the boundary of the client machine. The log file for this component is CAS.log.
If the CAS can find the content in the local cache, it will match the content version with the required one. Else we would see a CTM (Content Transfer Manager) job created, which further creates 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 enforcement of the application or initiates the installation of the application. However, before starting the installation, it will check whether the application is already installed or not, this is confirmed using App Discovery, and the same cycle listed above repeats again.
Finally, the command line is triggered using the account type(system/user) as mentioned in the deployment type. App Enforce keeps track of the exit code of the command. As per the exit code, the application is marked as successful or failure. AppEnforce.log will list the activity performed by this component.
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 the application is succeeded, which completes the Enforcement. After this, a state message is raised mentioning the compliance of the deployment.
Conclusion
This completes the enforcement of the application. At each step of enforcement, a state message is raised, which helps us report the deployment compliance.
I hope you will find this post interesting and helpful in day-to-day troubleshooting.
Resources
- Deep Dive SCCM Application Model Troubleshooting
- SCCM Inbox File Types Extensions and Associated Components
Excellent writeup. These kinds of deep dive into the full process flow of SCCM functionality are incredibly useful, and very much appreciated.
Great article with nice details. Excellent!