Hello, I’m Nitin Chhabra I worked for several years as a Microsoft support engineer specialized 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 client-side and is in continuation of my previous blog for dive deep into the SCCM Application Model Troubleshooting (Server Side).
The application model in SCCM is CI (Configuration Item) based, which provides us a lot of flexibility in terms of 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 the functionality of each component, lets us take an example of “Notepad++” application deployment.
Please follow my previous post to deep dive in 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 the download of the assigned polices to the machine. Policy Agent is the component which is responsible for downloading the policy. We will discuss each component in detail.
This component fetch 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.
Policy Agent will pass the control to CCM Messaging, which initiates a remote sync message for the Management Point. Almost every communication form the SCCM client to MP is performed by this component. 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. In case you have any connection issue with MP like firewall port blocking, network packet drop or MP host-name not 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.
This component after receiving a request from the client fetches the policies from the SCCM Database(Primary/Secondary site database). The log file associated with this component is MP_Policy.log.
If you will scroll down this log after you see the client request, you will see the new policy details for the client. This include 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 most all the download, which the SCCM client does, it 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 “CCM\Temp” directory. DTS will check if the directory is present and create the same if not found.
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.
This component works in conjunction with CI State Store and list the information about CI. It checks the application deployment is for the user or for 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 SCCM client) will process the SDM packages which are downloaded for the CI’s.
Note: SDM (Service Definition Model) package is build using the SML (Service Definition Language).
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 deployment type to determine the status of the application. The log file associated with this component is AppDiscovery.log.
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 mark the application as not discovered and trigger App Intent Eval component.
App Intent Eval
This component will evaluate the intended state of the application and also check for any requirement, supersedence, dependency defined in 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 details of the deployment.
Now lets 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 CI Agent job is created for the client machine. All the CI transitioning from evaluation then download and finally enforcement is logged by DCM agent. 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 as mentioned above will be repeated for App Discovery, Expression Solver, App Intent Eval.
Once the application is not found installed, CAS (Content Access Service) is called to download content for the application.
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 is able to find the content in the local cache it will use the same after matching the content version with the required one. Else we would see a CTM (Content Transfer Manager) job is created which further creates a DTS (Data Transfer Service) job to start the download of the data from the Distribution Point.
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 keep the 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 back to App Enforce which will check if the defined code is listed as success in the Application configuration.
If the application installation is succeeded, App Discovery is triggered to detect the Application on the machine, which completes the Enforcement. After this, a state message is raised mentioning the compliance of the deployment.
This completes the enforcement of the application. At each step of enforcement a state message is raised, which help us in reporting the deployment compliance.
I hope you will find this post interesting and helpful in day to day troubleshooting.