ConfigMgr 2012–Application Model–Internals–Part I

By now it is widely known that one of the major shifts in ConfigMgr 2012 is the new application model.  There is a lot of documentation about using the application model and creating the different elements associated – but I haven’t seen anything that pulls the covers back and discusses the internals of the application model.  This blog post will begin a series that will discuss the internals that take place when building a generic application on the site serve and, ultimately, deployment on the client.  This series will be divided into several parts as follows

Part I (this article) discusses mainly database changes that take place when an application is created.
Part II will focus on the internals of client side operations as the application is installed.

When you think application model, think configuration items (CI).  CIs were first introduced in ConfigMgr 2007 and were key to the function of DCM, delivering drivers through OSD and, most widely used, software updates.  In truth, CI’s all work through a similar engine defined at it’s core by DCM (now compliance settings in ConfigMgr 2012).  Other CI functions bolt on top of this core to deliver added functionality – such is the case with software updates.  The beauty of this is – if you understand the ‘behind the scenes’ function of CIs in ConfigMgr 2007 software updates, you are a long way down the road to understanding CIs in relation to every other component that uses them.  If you don’t understand the internals of CIs but would like to then take a look at my three part series on Software Updates available here Part I, Part II and Part III.

OK, cool - but why all the talk about ConfigMgr 2007? This post is about the application model in ConfigMgr 2012!!! Right you are. The reason for the mention of ConfigMgr 2007 and the CI function there is that the application model in CnfigMgr 2012 now makes use of the base CI framework introduced in ConfigMgr 2007 and expands upon it to make it useful for application delivery! We will soon see those components in action.

This blog post will NOT walk through the creation of applications and associated components except where relevant to illustrate ‘behind the scenes’ concepts. To start our discussion I have created a single generic application to install a very simple executable. The details really don’t matter except to say that this initial pass at the application does not define any dependencies, any supercedence or any rules – just a plain vanilla application has been created as shown.

So, the application was created – but what actually happened behind the scenes as a result of the application creation?  Let’s walk through it. 

SMS Provider
Start of Tangent
I’ll start with some trivia?  When you do work in the console – like creating an application – does the console directly write information to the database?  When I ask this question about 90% of the time the answer I hear is YES!  In truth, the answer is NO.  There are some very focused places in which activity in the console works directly against a database but in all others the console doesn’t even connect to the database directly.  Instead it connects to SMS Provider in WMI.  All of this activity can be seen in the SMSProv.log.  In our case, when working through the wizard to answer various questions and then clicking ‘OK’ to commit the application, the SMS Provider is integrally involved.  If you examine the SMSProv.log while working though the wizard you will find this to be true but note that the SMSProv.log is one of the busiest logs on the site server as it records all console activity.  With multiple consoles in operation at once information could be hard to track down.  Further, if you have multiple SMS Providers (possible in ConfigMgr 2012), you have to check the correct log to see activity for your session.  End of tangent

Lets take a quick look at some of the activity in the SMSProv.log while the application was being created.  Note that this discussion is NOT intended to be an exhaustive treatise on the SMS provider.  As already alluded to, the SMS provider plays a role in almost all console activity so the SMS provider discussion is not limited to just application creation.  When talking about applications, however, the SMS Provider must be a part of our focus. 

The log snips below are edited to show some representative relevant entries.

Snip 1
CExtProviderClassObject::DoCreateInstanceEnumAsync (SMS_Application)
<edited>
Execute WQL =select CI_ID from SMS_Application where IsLatest=1 and IsHidden=0 and LocalizedDisplayName='Vanilla application'
Execute SQL =select all SMS_Application.CI_ID from fn_ListApplicationCIs(1033) AS SMS_Application where ((SMS_Application.IsLatest = 1 AND SMS_Application.IsHidden = 0) AND SMS_Application.DisplayName = N'Vanilla application')
<edited>
CExtProviderClassObject::DoCreateInstanceEnumAsync (SMS_ApplicationTechnology)
<edited>
Execute WQL =SELECT CI_ID, ModelName FROM SMS_ApplicationTechnology WHERE CIType_ID = 25 AND IsLatest = 1
Execute SQL =select all SMS_ApplicationTechnology.CI_ID,SMS_ApplicationTechnology.ModelName from fn_ListDCMCIs(1033) AS SMS_ApplicationTechnology where (SMS_ApplicationTechnology.CIType_ID = 25 AND SMS_ApplicationTechnology.IsLatest = 1)

Snip 2
PutInstanceAsync SMS_Application
CExtProviderClassObject::DoPutInstanceInstance
<edited>
Updating SDM content definition.
<edited>
Added Content 40374 to package : 'CAS00024'.

There are a lot of lines added to the SMSProv.log during the process of creating an application.  I chose the ones above to illustrate a couple of concepts.  First, if you look through the SMSProv.log you will never see a query statement inserting any information to the database.  Yet, the SMS Provider is responsible for adding information about the application to the database.  How is that done?  More on that shortly.  Second, the SMS Provider is a really good place to see not only the WQL query statements used to retrieve information as the console activity takes place but also you will see their SQL equivalents.  This is really useful for tying together information in WMI as it relates to the database.  And, before you ask, translation in reverse isn’t shown – and translation in reverse really doesn’t make a lot of sense in the world of ConfigMgr – though it would sometimes be useful for you and I trying to sort out how to translate a SQL query to the WQL equivalent! 

Back to the first point.  If the SMS Provider is responsible for adding information to the database, but there are no WQL insert statements to get that done – how does it work?  Glad you asked.  You will notice the first line of the log snip 1 above is calling a method called DoCreateInstanceEnumAsync against the SMS_Application namespace.  This method is code that specifically is used to create a new instance in a WMI class, in this case the class is SMS_Application.  Half way through log snip 1 you will see an insert called again but this time against the SMS_ApplicationTechnology class.  These types of references are found throughout the SMSProv.log and specifically indicate that something is being added to WMI.  We don’t use queries to do that, we use methods.  Some methods are internal and some methods are defined right on the class.  From the log information above we know two of the key classes related to applications – SMS_Application and SMS_ApplicationTechnology.  Reviewing these classes reveals that one has methods defined and the other doesn’t.  When present, the methods are useful for interacting with the information stored in the class.  Working through these classes using WBEMTEST we can see the detailed information stored there as shown.  Note that configuration item (CI) 45367 in the SMS_Application class represents the application we just created – and you will see this again later.  This is your first indication that a created application is defined as a CI.  Note that the CI 25 is the one of interest on the SMS_ApplicationTechnology class.  We will see how these are all related when we get into the database.  Just know for now that information about these CI’s is stored in WMI as well.

SMS_Application class

SMS_ApplicationTechnology class

That’s enough on the provider – just wanted to make sure we touched on it because it is integral to application creation.  At this stage, the application has been added to WMI and, through the SMS Provider, the database.  How can we figure out the changes that happened in the database?  We could go in directly and search through the thousands of entries that exist in the key table(s) of interest or we could make things easy on ourselves and take advantage of information added to the log for another component that kicks in right after information is added to the database.  I prefer to take the easy route so lets jump ahead to the SMS Database Monitor (SMSDBMON) component.

SMS Database Monitor
The SMSDBMON is a component whose main job in life is to watch for changes to happen in key tables in the database and react to them accordingly.  The action that is taken will be specific to the data that has been added to the database.  The SMSDBMON watches for updates to packages, deployments, applications and more and, when such changes happens, will flag other related components in the system to wake up and begin to process the changes that have just happened.

As we walk through the SMSDBMON component realize that it is reflecting changes that have already been made.  So, in essence, we are jumping ahead to see what those changes were so we can go back and review the changes.  Just makes things easier.  Another way to say this, even if the SMSDBMON component were to have been stopped the changes still would have happened since the changes happen as the result of SMS Provider processing.

Start of Tangent
Another trivia question comes to mind.  Assume the database changes were made and, for some reason, the SMSDBMON component were not functional.  Would child sites that are part of the ConfigMgr 2012 hierarchy receive the database updates?  The answer will reflect your understanding of another key change in ConfigMgr – ConfigMgr database replication.  Assuming the above scenario, the application definition WOULD be replicated to child site databases as a result of ConfigMgr database Replication. Note that I call this ConfigMgr database Replication because the process of replicating is driven by ConfigMgr and not the SQL Replication engine itself.  End of tangent.

If we take a look at the SMSDBMON.log after committing the new application we will see some interesting activity as shown in the log snip below.

Snip 1 RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45367 ][168608]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45367 ][168609]
RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45368 ][168610]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45368 ][168611]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45368 ][168612]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45368 ][168613]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45367 ][168614]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45367 ][168615]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45367 ][168616]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45367 ][168617]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45368 ][168618]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45367 ][168619]
RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45369 ][168620]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45369 ][168621]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45369 ][168622]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45369 ][168623]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45369 ][168624]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45369 ][168625]
RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45370 ][168626]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45370 ][168627]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45370 ][168628]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45370 ][168629]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45370 ][168630]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45370 ][168631]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45368 ][168632]
RCV: INSERT on RBAC_ChangeNotification for Rbac_Sync_ChangeNotification [440 ][168633]
RCV: INSERT on PkgNotification for PkgNotify_Add [CAS00024 ][168634]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168608]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168609]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [168610]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [168611]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [168612]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [168613]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168614]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168615]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168616]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168617]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [168618]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [168619]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [168620]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [168621]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [168622]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [168623]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [168624]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [168625]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [168626]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [168627]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [168628]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [168629]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [168630]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [168631]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [168632]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\440.RBC [168633]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\distmgr.box\CAS00024.PKN [168634]

Note, the PKN and RBC files listed, as well as additional processing of the CIN files will be covered in part II

Reviewing the log snip shows a few items of interest.  First, recall I asked you to remember the CI entry referenced abopve when discussing the details of WBEMTEST.  The CI of interest there had an ID of 45367 and there was also a CI with an ID of 25.  We see CI 45367 in the log snips above and will see CI 25 show up again shortly - but we also see three additional values – 45368, 45369 and 45670.  We can infer, then, that 4 total CIs were added to the database by our addition of the single application.  Remember that this application was generic, having none of the additional bells/whistles possible during definition.  This is important as we will build on this as we progress. 

Also note that from this log section we see two key tables mentioned – CI_ConfigurationItems and CI_ConfigurationItemRelations_Flat.  I’ve mentioned already that the job of SMS Database Monitor is to watch various key tables and flag additional action by related components as a result of additions.  By inference we can know that these are two key tables that serve as the starting point for defining CIs– there are a number of other CI_ tables that will tie related to these with CI_ConfiguartionItems being the most important.

We also see that as a response to changes in these tables, SMSDBMON responds by creating flag files in the specified paths that will serve to ‘wake up’ threads to do additional processing of the added information.  We will walk through each of these components shortly but, now that we have gleaned this information from the SMSDBMON log, we will back up and review the changes made to the database when saving the application.

Database Changes
As with any discussion of the database, appropriate cautions apply. First, it is NOT SUPPORTED to make any changes directly to the database. If database changes are needed you should be working with Microsoft support directly. Second, this information is presented for understanding and education only and in no way suggests that you should be or need to be working directly in the database.  

That said, lets start our exploration with a few SQL queries.  Since we know both the key table names and the CIs related it makes our queries a bit easier – and, believe me, you WANT to make querying the CI_ConfigurationItems table easier as if you have software updates enabled and have synchronized the update catalog, there will be a TON of entries in this table.  The result set for the query is wide so the result shown below is wrapped to show all columns.

A few interesting columns here that we will see again as the discussion continues. 

CI_ID – This is the unique ID assigned to a CI.  This is the ID that will be used to correlate information in other tables back to this one.
ModelID – This ID is a tie to the internally defined model used to implement the CI. 
CIVersion – The version of the current CI.
SDMPackageDigest – Defines the action to be taken by the CI
CIType_ID – There are various types of CI.  This ID references a table where the types are contained
IsHidden – Defines whether or not the CI is hidden
IsTombstoned – Defines whether or not the CI is eligible for deletion
IsUserDefined – Defines whether the CI has been defined by a user
IsEnabled – Defines whether the CI is enabled
IsExpired – Defines whether the CI is expired
IsLatest – Defines whether the CI is the latest available
SourceSite – Defines the which site was used for defining the CI.  CIs are ‘owned’ by the source site but are not limited to that site.  In ConfigMgr 2012 all information is replicated throughout the hierarchy – even to peer primary sites.  This is a change from Configuration Manager 2007.

Reviewing the entries we see a few things – first, CI 45367 defines the application itself and CI 45368 defines the Deployment Type associated with the application.  You can tell this from the name defined under CI_UniqueID.  This makes sense so far as every application needs at least one Deployment Type.  If other Deployment Types had been specified they would be visible here as additional CIs.  We also see CI 45369 and 45370 are for Required Application and Prohibited Application definitions, respectively. 

If we want to further validate what is being seen all we need to do is select the SDMPackageDigest URL and we will see some additional detail confirming we are looking at the right CI.  Note that the SDMPackageDigest is just that, an abbreviated form of the SDM Definition.

CI 45367 SDMPackageDigest – in the body of this definition we see the name of the application we just created.

CI 45368 SDMPackageDigest – in the body of this definition we see various settings for the deployment type, including the content included in the source directory.

CI 45369 and 45370 are system defined CI’s.  Their SDMPackageDigest info is shown below for completeness but is beyond the scope of this discussion.

45369

45370

OK, so we have explored the 4 CIs that were created as a result of creating the application.  What else can we learn?  What about the other table that was listed in the SMSDBMON log?  Knowing that the CI_ID is a key to exploring these tables we can query against the CI_ConfigurationITemRelations_Flat table and look specifically for the same CI_ID’s we just saw.  This table is one that maps relationships between difference CIs.so the CI values we just used will actually appear in the FromCI_ID column.  The CIs related to our application will show up in the ToCI_ID column.  The RelationID is a unique value for each relationship formed.

We see that some of the relationships are simply our four CIs relating to each other but in this list we see several additional CIs – specifically 18, 74 and 84, showing as related items for each of our newly created CI’s.  If we query the CI_ConfigurationItems table for these new CI’s and review the SDMPackageDigest value for each we better understand their purpose.

We can tell by the CI_UniqueID that these are system defined CI’s.

Windows/All_Windows_Client_Server SDMPackageDigest

GLOBAL/NativeHostingTechnology SDMPackageDigest

GLOBAL/ScriptDeploymentTechnology

This CI defines that the application deployment type configured is to be installed using the Script method – which is selected on the initial page of configuring the deployment type.  There are also CI’s to define MSI, App-V and other deployments.

Also interesting from our relationship query results is the RelationType value.  The CI_RelationTypes table defines what the various types of relationships can be.  We will see that as various relationships – such as rules, dependencies or supercedences – are added to an application the relationship mapping will increase.  Looking back at the relationships mapped on our application CI’s created we find relationship types 0, 7, 9, 11 and16 in use.  If we query the CI_relationshiptypes table we see how those are defined.  Note, a relationship ID of 0 means no relationship is in place.

In the CI_ConfigurationItemRelations_Flat table we also see a column called relationdepth.  This value simply defines how many layers deep a relationship spans. 

OK, one other item to cover before a change is made to the application we just created.  Back to the CI_ConfigurationItems table we see a column called CI_Types.  This column defines the type of CI being defined.  As mentioned before, there are various types of CI’s possible in the system, all use a common framework.  For the application we just created there are several CI_Types listed – 10, 21 and 24 with 24 listed twice.  To find out what these configuration items are simply query the CI_CITypes table to see the list.

Having fun yet?  OK, lets go make a modification to the application.  We will start with something simple, like just adding some text to the comments field.

OK, comment added.  Notice that with the addition we are at version 2 of the application.  With this in place lets see what has changed.  We have already talked about the SMS Provider so I won’t rehash that.  Let’s take a look at the SMSDBMON log again – we see it looks similar but different.

SMS Database Monitor – version 2
RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45654 ][171990]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45367 ][171991]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45654 ][171992]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45654 ][171993]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45654 ][171994]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45654 ][171995]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45654 ][171996]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45654 ][171997]
RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45655 ][171998]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45369 ][171999]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45655 ][172000]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45655 ][172001]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45655 ][172002]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45655 ][172003]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45655 ][172004]
RCV: INSERT on CI_ConfigurationItems for CINotify_iud [45656 ][172005]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45370 ][172006]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45656 ][172007]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45656 ][172008]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45656 ][172009]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45656 ][172010]
RCV: INSERT on CI_ConfigurationItemRelations_Flat for CI_ConfigurationItemRelations_Flat_From_iud [45656 ][172011]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45370 ][172012]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45369 ][172013]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45367 ][172014]
RCV: UPDATE on CI_ConfigurationItems for CINotify_iud [45368 ][172015]
RCV: INSERT on PkgNotification for PkgNotify_Add [CAS00024 ][172016]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171990]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [171991]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171992]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171993]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171994]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171995]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171996]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45654.CIN [171997]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45655.CIN [171998]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [171999]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45655.CIN [172000]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45655.CIN [172001]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45655.CIN [172002]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45655.CIN [172003]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45655.CIN [172004]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45656.CIN [172005]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [172006]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45656.CIN [172007]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45656.CIN [172008]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45656.CIN [172009]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45656.CIN [172010]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45656.CIN [172011]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45370.CIN [172012]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45369.CIN [172013]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45367.CIN [172014]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\objmgr.box\45368.CIN [172015]
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\distmgr.box\CAS00024.PKN [172016]    

The first thing to notice is that we have the original 4 CIs being referenced again – 45367, 45368, 45369 and 45370.  In addition there are four additional configuration items being processed – 45654. 45655. 45656.  What?  Looks like processing was done on the original 4 CIs but three additional CIs were added?  Why?  And why 3 instead of 4.  Let’s plug all of this into the original query and find out.

Ah, so some things start to come clear.  If we examine the result we see the latest three CIs are all version 2.  We also see that with version 2 we cause version 1 CIs to become expired, as reflected in the IsExpired column, and also cause version 1 CIs to be shown as no longer the latest version, as shown in the IsLatest column.  Note that theCI defining the deployment type is still valid because we didn’t change anything related to the deployment type, just the main application definition.

With just this simple exercise we see that changes to an application do NOT cause existing CIs to be overwritten.  Instead, additional CIs are added and the previous versions are marked expired.  Why preserve information in this way?  Glad you asked.  If you recall one of the new features of the application model is the ability to track revision history and, if needed, cause a previous version to be restored, as shown for our application.  This feature would not work if previous CIs were deleted.

Pretty cool, huh?  Just a bit more to show in the database and we will wrap up part I of our discussion. 

We have seen what takes place behind the scenes when creating a basic application.  So what happens when we configure some of the additional settings in the application?  To find out lets create a dependency relationship so that our test application depends on another that itself has two levels of dependencies.  We will also create a rule on our application, as shown.

Requirement

Dependency – 4 levels nested

What changed in the database as a result?  New versions of CI’s were added and others expired – also additional relationships between CI’s have been established.  We will review the later by returning to our SMSDBMON log to pull the updated CI values.  This time the updated CI’s are 45657, 45658, 45659 and 45660 = a complete set of 4.  Why?  Because we just changed the deployment type as well.  So what do the relationships look like?

We see some familiarity here but we also see additional relationships have been added.  Specifically, we see relationships to CI’s 2, 101, 105 and 109 and we also see two new Relation Types involved – 10 and 13.  We also see increases in the depth of our relationships in the relationdepth column.  Lets wrap up by taking a look at these.  Working through the same queries as above but focused on the new related CI’s we see the first one, CI_ID 2 is a relationship to an out of the box requirement rule while the other three are relationships to the defined application dependencies.

CI 2

CI 101

CI 105

CI 109

And, finally, the new CI Relation Typles listed, 10 and 13, map to AppDependency and GlobalConditionReference, as shown from the query displayed earlier in the article.

So, there you have it – a whirlwind tour of some (but definitely not all) of the database in relation to new and updated applications.  Stay tuned for part II!

Comments

• Anonymous
  July 14, 2012
  Wonderful article, as always, Steve! This level of detail can be handy when troubleshooting or scripting. I see you refer to "ConfigMgr SQL replication". Is that official terminology? I was under the impression we should refer to it as "ConfigMgr database replication" (deemphasizing the SQL bit)

• Anonymous
  July 22, 2012
  Great point - and it's not official documentation.  I like 'ConfigMgr database replication' better for the reason you specified.  Updated the article.

• Anonymous
  November 12, 2012
  Fun yes :). When are the pending sequels out ...

• Anonymous
  November 18, 2012
  Just posted part II.  That may be it for the series.  Not sure yet.

• Anonymous
  April 17, 2013
  Many thanks!

• Anonymous
  July 11, 2013
  Great Article!!