Software Updates–INTERNALS! (MMS 2011 session)–part II

In part II of this discussion we will review CI’s and SDM packages.  Our discussion is focused on software updates but the concepts we will discuss also apply to DCM, NAP and OSD – all components that are built on the CI and SDM objects.

First, some definitions.

CI – A CI is short for Configuration Item.  A configuration item generically is a discrete unit of configuration to assess for compliance. They can contain one or more elements and their validation criteria, and they typically define a unit of configuration you want to monitor at the level of independent change.

SDM Package – A SDM package is short for Service Definition Model.  You may also hear the SDM Package described as using the SML – service modeling language.  SDM Packages link together with CI’s and further describe how to effect whatever configuration it is that we wish to evaluate or implement.

OK, it helps to actually see the CI and SDM package in the database so let’s take a look.

In the database the CI’s and SDM Package components are all contained in tables beginning with CI_.  I won’t attempt to go through every one of these tables but will take a look at the highlighted ones to help our understanding of CI’s and SDM Packages.  Before we go further, a disclaimer.  What I am about to show in the database is for education purposes only. There is nothing here that you should ever attempt to change. I’ve never had to make any changes here and if attempted these changes likely would corrupt your database entries – so don’t try it!  

I’ve mentioned already that while our focus is software updates that the concepts discussed here apply to any component that makes use of CI’s and SDM packages – and I’ve already listed those components.  You can also see this in the CI_Types table.  We see that our software updates are represented by a CIType_ID of 1, 8 or 9.  This may vary from database to database so always check this table to know for sure before digging deeper into tables.  You will also notice CITypes listed here from other components – type 2, 3, 4 and 5 are for DCM, type 6 is for OSD and type 7 is generic.

OK, on we go.  In the database there are many tables that are used to describe categories of data – such as the discovery tables, the hardware inventory tables and, in our case, the CI tables.  In general, each group of tables will have one master location where data is stored and then several other tables that further describe the data and relate back to the master table (thus the very concept of a relational database!).  For CI’s the master table is CI_ConfigurationItems.  This is a very large table and the bulk of the content that is found here will be software updates – but will also include DCM data, OSD data, etc.  In the snip below CI_ID 44456-44749 all represent software updates – you can tell by looking at the CI_UniqueID column.  CI_ID entries 1-11 represent DCM CI’s – again, see the different format in CI_UniqueID.  Looking further at the CI_UniqueID we can see CI_ID 3 and 4 are security CI’s, 9 is an application CI and 7, 11 are cloned CI’s meaning they were copied from another CI source in the console.

When attempting to query this table you can get lost unless you know what you are looking for.  In the next  query I am specifically pulling out the CI representing our software update discussed in Part I of this series.  The result set displayed tells us a ton – we can see the CI_UniqueID maps exactly to the Unique Update ID we traced in part I of this series.  We also see in the modelname column that the portion after the / – SUM_eb confirms also that this is a software update management (SUM) CI model and also corresponds to our unique update id (see the eb portion just at the end of model name – if you expand this column all the way you will see the rest of the string is exactly the CI_UniqueID).  We also learn that the SDMPackage that our CI is linked to is 65002 – we will take a look at that in just a second but notice at the far right we have the SDMPackageDigest column.  This is a truncated representation of what we will see when we look at the specific SDM entry shortly.

There is also a good amount of information visible for the CI if you continue to scroll to the right but that’s enough for our discussion here.

OK, so if we click on the SDMPackageDigest entry we will see a new screen open with details of our update and how to implement the configuration on our clients.  Remember, this is just the Digest – there is a ton more that is not revealed here.  We see the DisplayName for the update and Description defined here.  We also see that in order to scan for this update we need to use the highlighted scan tool (6C6DE…).  If you review part I of this post you will see the request for this scan tool reflected in the logs.  We also see the command line that will be used to install the update.  Have you ever noticed that in ConfigMgr you cannot enter the command line for update install?  You could do so in SMS 2003 ITMU but not ConfigMgr.  That doesn’t mean the command line isn’t stored and executed – it clearly is here – just that you can’t change it.  The only options for modifying update application are the options selectable in the console.

We will stop there for the CI itself – lets examine the full SDM package. The following query pulls out the specific SDM package associated with my CI.  From the initial results we can see that the SDM Package refers back to our update (take a look at the end of SDMPackageName)

If we continue to scroll to the right we see that here we have the full SDMPackageXML (not just the digest). 

If we click on the SDMPackageXML we get a screen full of information.  We see some of the elements from the digest plus a ton more.  I won’t go through the XML here – feel free to read through it if you have insomnia!  But it does illustrate how much definition is behind each one of our CI/SDM packages.

OK – so does the information shown here simply remain in the database?  No – if it did there would be no instructions for the client to use when asked to install or deal with these CI’s.  In part I of this discussion I walk through the logs and show how there are three components that need to be downloaded for an update – the CI, the SDM package and the update itself.  The CI is downloaded and stored in WMI on the client and the update itself is stored in the client cache – again, illustrated in part I of this discussion. The SDM package definitions are downloaded to tye SDMAgent\TypeStore folder on a client as shown.  Notice that for every GUID there is a .SDM extension and a .LAT extension.  The .SDM file contains the definition from the database and the .LAT file is the Last Access Time for the particular SDM package.  This .LAT file is used to determine when the .SDM package has aged out of the systems sufficiently to warrant being deleted.  This is not something you should ever have to touch but just an FYI. Also note that the specific software update GUID is not seen in the list of files – which makes finding the specific .SDM package a bit of a challenge here.  You can find it though – in my case it happens to be the .SDM file at the top. 

And there you have it – the CI and SDM system end to end.  Hope this helps your understanding of the back end processes!

Comments

• Anonymous
  April 16, 2011
  I found these two articles very informative.  Thanks for your efforts.