Hope this post finds you in good health and spirit. In this 2 part series, we will discuss application deployment in SCCM 2012 which will be applicable to newer versions of SCCM too. In this series, I will discuss server side in part one and then client side in part two. So, lets start our discussion.
Note: Application model is based on Configuration Items (CI). CI was introduced in CM07 and apart from application deployment its key for software updates and OSD.
I have already discussed about the process of creating and distributing application in my last blog. In case if you have not checked yet, you may find it here:
Here is quick summary.
- Changes made on SCCM console are written to database by SMS Provider. Here is detail about SMS Provider: https://technet.microsoft.com/en-us/library/bb680613.aspx. SMS Provider activities are recorded in SMSProv.log. When an application is added SMS Provider will run WMI query to write the data in database. You may view SMSProv.log for details.
- Changes to database are picked by SMS Database Monitor component which does additional job to wake up other components as per requirement. You need to check smsdbmon.log for detail.
- Distribution manager component will write the application on DPs. Check distmgr.log for details.
Ok. Its time to check the logs and peep in the details.
When you want to check multiple logs and in reference to time, its very hard to toggle between them. In CMTrace tool you can add multiple logs and then chick on merge. You will have single console and logs will be merged. You can filter them too. I will use same trick to show you all the required logs discussed above.
Select multiple logs is CMTrace and the select merge selected file. Then click open.
I have selected distmgr, policypv (to check policies), smsdbmon and smsprov logfiles.
Filter the log in reference to time for clarity and to filter out extra information. I knew the time when I created application so will check logfiles after that time. Click OK.
Isn’t it interesting? Now your logfiles are interleaved and you can easily check them in one console. You can also find the flow of action in reference to time.
Great! So let’ start checking the logs.
SMS Provider will add lot of information in log during application creation. We will concentrate on the lines which are important to understand the concept. As in figure below, SMS Provider has called a method DoCreateInstanceEnumAsync against “SMS_Application” class. This method creates instance in WMI class. SMS Provider will keep on adding various instances as you scroll down log file. “SMS_Application” class holds important significance so I will show you information inside it too.
To open WMI classes and namespaces, we can use various tools. One of them is WBEMTEST which is there by default in OS. To open, go to run and type wbemtest.exe. There are multiple namespaces and classes defined for SCCM. You may check the list here.
In namespace windows, type root/sms/site_<sitecode> and connect.
Click on Enum Classes, select recursive (it will show even the sub folders) and then OK. Now you will be able to see all the classes. Browse down and double click on SMS_Application. Click on Instances and you will be able to see all the instance of application in your environment. For me, it shows 2 instances as I have deployed 2 applications.
Double click on these instances to see the details (property) of application.
Note down CI_ID. We need it later to dig down. For me its “16778445”.
So, till now we have checked how SMS Provider has created class and how information about application is written in database. You may note that SMS Provider runs WMI and SQL statements to do so. I have highlighted those lines in log snapshot above.
Keep on scrolling down the merged log we had created before.
Entry of SMS Database Monitor
As discussed above, SMS Database Monitor tracks the database change and wakes up related components. You can see in your log that once SMS Provider will finish its job, SMS Database Monitor will start working. Activities are logged in smsdbmon.log.
Do you remember “16778445” entry in log. That’s right. Its the CI id we had found for our application.
CI_ConfigurationItems and CI_ConfigurationItemsRelations_Flat are two key tables where Update and Insert operations are run.
Well, but as I scroll down I find 3 more CI id entry for 16778446, 16778447 and 16778448. Why single application is making 4 entries? To answer, we need to run query on our database. I have used SQL Management Studio for query.
We can see their reference to different SDMPackageDigest. You can click on link to see the content. CIType_ID is next column whose value can tell you CI type. We can find them by running query.
Ok. So now we know why we have 4 CI_Id in our log.
Keep on rolling the log. SMS Database Monitor will drop .CIT file in policypv.box to wake up Policy Provider. It will also drop .PKN file in distmgr.box to start Distribution Manager component.
Entry of Policy Provider and Distribution Manager
I have already discussed work of Distribution Manager component in detail in my previous post. To summarize, it creates hash and compresses the application and distributes them to DPs. But which all client will get application? That’s defined via deployment. Once you have deployed an application, policy provider comes in play. It will create policy regarding the deployment. Once client will poll its MP for policy, MP fetches the policy from database and provides it to client. This is how, client come to know that it has a policy for application deployment and starts the process. More about it in second post where we will discuss client side of application deployment in detail.
Wow! Here we complete server side of application deployment.
See you soon with part 2 where we will wrap up this series by discussing client side. Till then good bye and “Happy Holi” in advance.
Here is link for part two: