In this article, I will describe in depth how a package and program is created. Why the older package and program process and not the newer application model? The application method may come next, but mostly I wrote this to share the information with a peer and because it is more depth than most articles I see on the subject.
I will describe the process from the time the Configmgr admin creates the package in the console up until the time when the newly created package a program(s) are distributed, distribution of a package warrants its own article at this depth. Specifically I will show how the different Configmgr components are involved, what logs are written to, what you should see in the logs, as well as some additional details like the inboxes, files created for processing and additional details that are not typically discussed. If you are new to Configmgr, this is not a good article to start with as I assume there is some basic understanding of Configmgr terminology and its process.
First will be some of the basics of WMI in case you are unfamiliar with the underlying technology. If you already know this then you can skip ahead to the process breakdown portion below under Package Creation Process.
WMI
I think most people that work with Configmgr have an idea of what WMI is. I often hear about ‘rebuilding the WMI repository’. And for a while I didn’t really understand WMI but then I started to look into it and realized there was a lot I didn’t know, and things I thought I knew, were wrong. Because it plays such a large role in Configmgr I will start with it.
WMI was included in SP4 for NT4.0 back in ’98 and has grown since then. The essential idea around WMI was to provide a single consistent way to collect and manage the details of Windows-based computers. If you want to know what video card is installed, ask WMI. If you want to know if a file exists, ask WMI. If you want to know what time zone a computer is set to, ask WMI. In WMI speak anything you can query for information or perform operations on is considered a managed resource or a managed object (I prefer the term managed object). If WMI can talk to it, it is a managed resource. WMI also provides a single and consistent scripting method to get at this information instead of relying on multiple tools and scripting languages. WMI scripts are also very easy to repurpose by changing just a few lines of the script, sometimes less.
How WMI works I think is where some people get confused and things go off the rails after that. IMO that is mostly because the terms used are more akin to a programmer than a sysadmin, which is why most of the definitions in here for WMI link to MSDN instead of TechNet.
I think Shrek described it well, it is an onion with many layers, I think he was talking about WMI. I will start by describing the architecture at a very high level and go deeper later.
Top level would a script or application that needs to access WMI, sometimes called a WMI consumer. I will use Configmgr in this scenario to help explain things. Assuming the computer is a Configmgr client, the Configmgr client would be considered the top level or the WMI consumer.
Middle level would be the WMI Infrastructure. I know, but I wasn’t consulted on the terms. The WMI Infrastructure would be considered the core of WMI and it has many parts that I will explain below, but to keep things simple at this point let’s say the WMI Infrastructure is what the Configmgr agent communicates with when it is requesting the computers hardware inventory. It sits as a middle man between the Configmgr client (consumer) and the bottom layer of the WMI architecture.
The bottom layer of the WMI architecture is the managed object that the Configmgr client is requesting information from. Managed objects can be hardware like a NIC or Video card, but they can also be objects such as a process or service.
Arguably, the most important aspect of WMI from a Configmgr admin’s perspective are the providers. WMI providers like the SMS Provider. A provider sits between a managed object and WMI. When WMI makes a request it hands that request to the managed objects provider. Providers have classes, and providers classes can have properties and methods. Some providers classes have no methods and lots of properties, others have no properties and lost of methods. When you want WMI to do something with a managed object, that is when you need a method. When you want WMI to pull some data about that managed object you are querying a property. If you right-click on a file and select properties from the menu you get details about that file like size, name, modified date, so on. If you right-click on a file and select delete, that is similar to a method, you are carrying out an action against that object, not just looking at its properties.
To summarize. WMI providers sit between a managed object and handle messages between the object and WMI. Providers can have classes and methods. If you want to change the managed object, you need to call a method. If you want to get data about the managed object you need to call a property.
WMI providers consist of a .DLL and a .MOF file. They are stored in the %WINDIR%\System32\Wbem directory. The .MOF files contain the providers classes along with other details like namespace. The .MOF file gets compiled and stored into WMI’s repository when the computer starts. Which is likely another source of confusion when people read about WMI. WMI does not store information about the managed object in the repository. Just so it is clear, WMI does NOT store details about hardware or software in its repository. The providers .DLL file contains the code to dynamically pull data about a managed object when WMI requests it. The WMI consumer (script or app) then receives that data.
To complete the whole WMI picture. The WMI infrastructure is a component of the OS. It has three distinct parts. The WMI service, the WMI repository, and the WMI providers. The WMI infrastructure sits between the managed object, and the WMI consumer.
Here is a short video explanation of a WMI query. It doesn’t reflect the data being sent back to the consumer.
CIMOM (Common Information Model Object Manager) – The WMI service (winmgmt.exe). We all know what a service is right?
CIM (Common Information Model) – The WMI repository. It stores all the providers classes WMI knows about. When the computer first boots it reads all the .MOF files where the classes are defined and builds the repository.
Class – In WMI classes are stored in the repository (CIM) and defines how the provider can query data and perform operations of a managed object.
Managed Resource or managed objects a logical or physical component that WMI can interact with. In the context of WMI, this is an object it can manage (communicate with). A NIC, hard driver even an application, are examples of a managed object.
Method – is what the provider uses to perform actions on the managed object. More specifically, this is how the provider executes the functions stored within the code stored in its corresponding .DLL. If you need to modify a class then you need a method.
MOF (Managed Object Format) – A file that contains a providers classes, methods, properties, namespace, everything. CIM Studio is a good tool to learn about .MOF files and what you can do with them. Also one of the two files or pieces that make up any provider, the other half is the .dll file. You can download it for free as part of the WMI admin tools.
Namespace – This is how the WMI repository (CIM) groups similar WMI classes and instances. A list of the WMI Namespaces created by Configmgr can be found here along with an example WMI consumer on how to list all the namespaces and classes. Configmgr server WMI namespace is root\sms\site_<site code>
Property – By querying a managed objects state or configuration details you are accessing the property of the object where that data is stored.
Provider – Is the last stop between WMI and the managed object. It requests information and passes instructions to the managed object. Consists of two files a .DLL and a .MOF file. Files are located in the %WINDIR%\System32\Wbem and %WINDIR%\SysWOW64\wbem folders.
WMI Architecture – Also made up by three separate parts, including the WMI Infrastructure. (1) Consumers (2) WMI Infrastructure (3) Managed resources.
WMI Class – see Class.
WMI Consumer – something that is trying to consume WMI data or requesting WMI to do something. Another example of programmer-speak. It is a script or an app (Configmgr client) that trying to do something with WMI.
WMI Infrastructure – Made up by three separate parts of WMI (1) CIMOM (2) CIM (3) WMI Providers. When combined they make up the WMI Infrastructure.
WMI Provider – Sits between the managed object and CIMOM, see Provider below. Is a COM object that monitors managed objects for WMI.
WMI Repository – see CIM.
WMI Service – see CIMOM. …\wbem\winmgt.exe
The WMI command line tools mofcomp.exe and Winmgmt.exe are located in the provider folders %WINDIR%\System32\Wbem and %WINDIR%\SysWOW64\wbem.
SMS Provider WMI schema reference for Configmgr
How to extend the Configmgr hardware inventory in 2012
How to configure WMI permissions for users
How to backup and restore WMI’s repository
Now that we have that out of the way and it is all clear let’s move on to package creation. I will first describe this and then cover each step in more depth to make the details easier to pull out if you are just looking for information on a particular step.
Step 1 – The Configmgr admin first creates a package in the Configmgr console.
Step 2 – The SMS provider queries the SMS_PDF_Package class in WMI for the package name to ensure one doesn’t exist with the selected name.
Step 3 – The SMS Provider creates a new instance of the SMS_Package class in MWI with the new packages names by calling the method DoPutInstanceInstance.
Step 4 – For each program created in a package the SMS Provider creates a new instance of the SMS_Program class in WMI using the DoCreateInstanceEnumAsync method.
Step 5 – The SMS Database Notification Monitor (SMS dbmon) notices inserts/updates to the following tablesSMSPackages_G and PkgNotification.
Step 6 – The SMS dbmon then drops a flag file into the hman.box inbox folder.
Step 7 – Then the SMS dbmon creates a flag file in the distmgr.box inbox folder.
Step 8 – Next the Distribution Manager takes a snapshot of the package from the source directory that was specified by the Configmgr admin during the package creation.
Step 9 – SMS Distribution Manager then makes a package definition file.
Step 10 -The SMS Distribution Manager requests that RDC (Remote Differential Compression) creates a signature and hash of the package.
Step 11 – The SMS Distribution Manager creates version .1 of the package.
Step 12 – Then the SMS Distribution Manager notifies other sites that the package has been created.
Component: SMS_PROVIDERS
Log file: smsprov.log
Steps 2 – 4
The SMS provider queries the SMS_PDF_Package class in WMI for the package name to ensure one doesn’t exist with the selected name.
ExecQueryAsync: START select PDFID from SMS_PDF_Package where Name =’ConfigMgr 2012 Toolkit R2’~
Execute WQL =select PDFID from SMS_PDF_Package where Name =’ConfigMgr 2012 Toolkit R2’~
Execute SQL =select all SMS_PDF_Package.PDFID from PDF_Package AS SMS_PDF_Package where SMS_PDF_Package.Name = N’ConfigMgr 2012 Toolkit R2’~
The SMS Provider creates a new instance of the SMS_Package class in MWI with the new packages names by calling the method DoPutInstanceInstance
? PutInstanceAsync SMS_Package
? CExtProviderClassObject::DoPutInstanceInstance
Processed insert instance notification for: SMS_Package.PackageID=”MSC0000B”~
For each program created in a package the SMS Provider creates a new instance of the SMS_Program class in WMI using the DoCreateInstanceEnumAsync method.
CExtProviderClassObject::DoCreateInstanceEnumAsync (SMS_Program)
Component: SMS_DATABASE_NOTIFICATION_MONITOR
Log file: smsdbmon.log
Steps 5 – 7
The SMS Database Notification Monitor component watches specific tables in the database. When it sees changes to these tables it carries out various operations. In the case of a package and program being created when it sees the inserts and updates to the two tables listed below it will drop a file in each components inbox folder to wake that components thread up and process the new information. When the component has completed the actions the file in the inbox is deleted. When someone is referring to a component having a backlog what they are usually talking about is a large number of files in the components inbox that are not being processed or have been moved to the retry folder and are waiting to be processed again.
The SMS Database Notification Monitor (SMS dbmon) notices inserts/updates to the following tables SMSPackages_G andPkgNotification
RCV: INSERT on SMSPackages_G for SMSPackages_G_Avail_iu
RCV: INSERT on PkgNotification for PkgNotify_Add
The SMS dbmon then drops a flag file into the hman.box inbox folder
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\hman.box\10328.RBC
Then the SMS dbmon creates a flag file in the distmgr.box inbox folder
SND: Dropped C:\Program Files\Microsoft Configuration Manager\inboxes\distmgr.box\MSC0000B.PKN
The PKN file kicks off the process of the Distmgr taking a snapshot of the package contents, creates a signature, calculates a hash of the package snapshot and begins the transfer to the distribution point(s).
Component: SMS_DISTRIBUTION_MANAGER
Log file: distmgr.log
Steps 8 – 12
Next the Distribution Manager takes a snapshot of the package from the source directory that was specified by the admin during the package creation
Taking package snapshot for package MSC0000B from source \\cm1\temp
SMS Distribution Manager then makes a package definition file
Writing package definition for MSC0000B
The SMS Distribution Manager requests that RDC (Remote Differential Compression) creates a signature and hash of the package
~Successfully created RDC signatures for package MSC0000B version 1
Creating hash for algorithm 32780
The hash for algorithm 32780 is 2507231264A95B2C547F087EF62FFB2E8054F9164B8842DCBB51A6057FD10201
The RDC signature hash for algorithm 32780 is 60EDF1EDA3BC93E165CC8E9FB9CE77EA82FB264CE2E45E3E1A00840368EFF94A
Each package will have a package ID created automatically. The package ID will start with the site code followed by a number sequence, for example MSC00001, would be the first package, after it reaches 9 it will then use alphanumeric numbering starting with A, for example this package is MSC0000B.
The package version is indicated by adding a .n after the package ID, MSC0000B.1
The hash of the package is stored in a .ini file within the root of DataLib folder, as an example, MSC0000B.1.INI.
[Info]
Hash=2507231264A95B2C547F087EF62FFB2E8054F9164B8842DCBB51A6057FD10201
HashAlgorithm=32780
To see the hash for each file within the same package you can open the corresponding package ID folder and each file will have a .ini file, viewing the ini file will display that particular files calculated hash.
[File]
Attributes=00000020
Size=5664768
TimeModified=130869880833496560
Hash=9CC8085253117D1B938EFB87DB73F175F1B2D657083ADC963904DAD5B8008E1C
The DataLib folder is located within the content library (<Configmgr Install Directory>\SCCMContentLib )
The SMS Distribution Manager creates version .1 of the package
~Adding these contents to the package MSC0000B version 1.
Then the SMS Distribution Manager notifies other sites that the package has been created
A program for package MSC0000B has been added or removed, therefore it needs to be replicated to all child sites.
Package MSC0000B is new or has changed, replicating to all applicable sites.
After this the process moves on to distribution, which involves different components and really needs its own article. Hopefully, this is useful and should not change much in v.Next (due next month). Feel free to ping me with any questions.
Anthony Clenendon Anthony is a consultant with ITS Partners, with a focus primarily on Configuration Manager. You can read more about his expertise at his personal blog at configmgr.com.
These Stories on Microsoft
