May 30, 2017 at 17:57SCCM Inventory
At the word “inventory”, an ordinary person recalls a situation when you come to the store and see a sign on a closed door and think that you have to go through several more houses, and in the worst case, blocks to buy what you need. An unusual person working with Microsoft System Center Configuration Manager, at the mention of this word, presents a bunch of problems related to the reliability of the results. We’ll talk about their solution under the cut.
I give the floor to the author.
Hello colleagues. Each administrator working with the Microsoft System Center Configuration Manager (hereinafter ConfigMgr) daily uses the Inventory functionality. This is the basic functionality that collects data about a managed environment and in the future it is used to build collections, queries, reports. Despite the apparent ease of setting up and using the inventory functionality, ConfigMgr administrators are faced with constant problems with the reliability of the results. The purpose of the article is to give a full understanding of how the inventory works, how to identify and how to solve problems. In fact, I will try to consider as much as possible "what is under the hood."
Before we go deeper, we need to discuss a small disclaimer. ConfigMgr works both with Windows operating systems, and with Linux / Unix (using nanoWbem), with mobile systems. ConfigMgr was originally developed as a product for managing Windows OS, therefore, for full technical coverage in the article we will consider only clients running Windows. If you are interested in understanding how the inventory for Linux / Unix works, write in the comments and think about writing an article. Now let's move on to the most interesting.
ConfigMgr has two different types of inventory - hardware inventory ( in the Russian-language documentation - an inventory of equipment) and software inventory ( respectively, an inventory of software). In the article I will use English-language names. The key point here is that, in essence, "the name does not match the content." And this is the reason for one of the main mistakes of administrators. In fact, hardware inventory is a WMI inventory, and software inventory is a file inventory (collection of file properties by a given mask). That is why the list of installed ConfigMgr software is collected through hardware inventory - this information is in WMI classes (partly in default, partly in ConfigMgr client WMI classes).
In practice, more used and more critical for the successful completion of everyday tasks - hardware inventory. Therefore, in this article we carefully consider it.
To use this functionality, it is necessary that the client settings (client settings -> Hardware inventory) on the Primary site side be “enable”, the schedule is set, WMI classes are selected, the information from which must be collected (some classes are enabled by default). A full description of WMI classes is available on MSDN .
ConfigMgr uses the Configuration.mof file located in \ inboxes \ clifiles.src \ hinv, which indicates the WMI provider and WMI classes used. When a client accesses a server on a schedule (to a management point), it downloads a policy to which this file is attached and compiles it locally. After that, based on the schedule, the ConfigMgr client starts the hardware inventory process (hereinafter referred to as hinv).
Here you need to make a small digression. ConfigMgr client consists of an engine and agents, each of which is responsible for a specific functionality. At the same time, the ConfigMgr client uses trigger codes (the list can be viewed here) to start any actions with their agents. To start the hinv agent, use the trigger code {00000000-0000-0000-0000-000000000001}.
The following sequence of actions will occur on the client:
1. Launch hinv on a schedule . The inventoryagent.log will have the following entry:
ReportType - type of the report sent to the Primary site (Delta or FULL). FULL - the report will contain all the information that is collected (by default it is sent during the first inventory). Delta - a report that contains only changes since the previous hinv. Using the Delta report allows you to reduce the size of information sent over the network.
2. Data collection from WMI :
Upon completion of the WMI survey, a report is generated that indicates how many WMI classes were not found on this machine. This means that these classes were specified in the client setting for collection, but are absent on this client. This information helps to understand if there is any requested data on the client.
3. An xml file is generated for sending to the management point. The file is generated in the% WinDir% \ CCM \ Inventory \ Temp folder:
4. The xml file is sent to the management point and deleted (by default) .
If you need to save xml (during the identification and solution of any problems), then you need to create a special "secret" file ARCHIVE_REPORTS.SMS .
The hinv runtime is stored on the client in WMI: root \ ccm \ invagt \ C00000000-0000-0000-0000-000000000001. Accordingly, if you want to force Full inventory to start, you just need to delete the record with the date of the previous hinv - ConfigMgr will automatically start FULL hinv.
Further actions will take place at the management point:
5-7. Management point receives a hinv report and processes it . Then forwards to the Primary site.
7 *. If the Management Point is installed outside the Primary site , the MP File Dispatch Manager component (MPFDM.log) will be used.
Actions on the Primary site side:
8. The Data Loader component (responsible for hinv processing) detects new * .mif files in its inboxes \ auth \ dataldr.box and moves it for further processing to the inboxes \ auth \ dataldr.box \ process \ folder.
9-10. When processing an mif file, data is written to the ConfigMgr database.
9*. If the file was rejected during mif processing, then the file is moved to the inboxes \ auth \ dataldr.box \ bad folder and stored for 14 days. After 14 days, ConfigMgr deletes it automatically. Accordingly, the information does not enter the database and this causes a decrease in reliability, which affects the entire functionality of ConfigMgr.
When moving mif files to bad, ConfigMgr creates subfolders using the type of processing error as the name of the folders. For instance:
A detailed description of the reasons for rejecting mif files and how to deal with it is described in the article Umair Khan (Support Escalation Engineer Microsoft Support) . I definitely recommend this article to anyone who works with ConfigMgr of any version.
Based on my experience, I can add that in Russian-language environments (where Cyrillic is used) there is another reason for the rejection of mif files - a mismatch in the dimension of the ServicePack00 field in the dbo.INSTALLED_SOFTWARE_DATA and dbo.INSTALLED_SOFTWARE_HIST tables. By default, the dimension of ServicePack00 (dbo.INSTALLED_SOFTWARE_DATA) is 255 (nvarchar), and the dimension of ServicePack00 (dbo.INSTALLED_SOFTWARE_HIST) is 8 (nvarchar). As a result, when ConfigMgr, while processing the mif file, tries to move the data to the HIST, they may not pass due to the dimension and mif is rejected. The correction option is to change the dimension of the field in the HIST table. But, it must be taken into account that you can make any changes to the ConfigMgr database on the production server only after thorough testing and this can lead to serious failures.
ConfigMgr administrators must constantly monitor the accumulation of rejected mif files. To do this, you can use the operational monitoring systems available in the organization or the Inbox Monitor utility .
The hardware inventory itself is stored in the ConfigMgr database as a large number of views. Current hardware inventory is stored in view starting with v_GS, historical data is stored in views starting with v_HS. Detailed information with a description of all views is available here . Using this information, you can easily get the required reporting with minimal effort.
I hope this article will help ConfigMgr administrators better understand the hinv process and give a clear understanding of how to look for and fix failures that occur during the operation of this functionality.
Andrey Petrov is an IT specialist with 15 years of experience, specializing in Infrastructure Support, Cloud Computing and DevOps.
Previous article on this topic: How not to get confused in the abbreviations SCCM [Crib] .
I give the floor to the author.
Hello colleagues. Each administrator working with the Microsoft System Center Configuration Manager (hereinafter ConfigMgr) daily uses the Inventory functionality. This is the basic functionality that collects data about a managed environment and in the future it is used to build collections, queries, reports. Despite the apparent ease of setting up and using the inventory functionality, ConfigMgr administrators are faced with constant problems with the reliability of the results. The purpose of the article is to give a full understanding of how the inventory works, how to identify and how to solve problems. In fact, I will try to consider as much as possible "what is under the hood."
Disclaimer
Before we go deeper, we need to discuss a small disclaimer. ConfigMgr works both with Windows operating systems, and with Linux / Unix (using nanoWbem), with mobile systems. ConfigMgr was originally developed as a product for managing Windows OS, therefore, for full technical coverage in the article we will consider only clients running Windows. If you are interested in understanding how the inventory for Linux / Unix works, write in the comments and think about writing an article. Now let's move on to the most interesting.
Let's move on to inventory
ConfigMgr has two different types of inventory - hardware inventory ( in the Russian-language documentation - an inventory of equipment) and software inventory ( respectively, an inventory of software). In the article I will use English-language names. The key point here is that, in essence, "the name does not match the content." And this is the reason for one of the main mistakes of administrators. In fact, hardware inventory is a WMI inventory, and software inventory is a file inventory (collection of file properties by a given mask). That is why the list of installed ConfigMgr software is collected through hardware inventory - this information is in WMI classes (partly in default, partly in ConfigMgr client WMI classes).
In practice, more used and more critical for the successful completion of everyday tasks - hardware inventory. Therefore, in this article we carefully consider it.
To use this functionality, it is necessary that the client settings (client settings -> Hardware inventory) on the Primary site side be “enable”, the schedule is set, WMI classes are selected, the information from which must be collected (some classes are enabled by default). A full description of WMI classes is available on MSDN .
ConfigMgr uses the Configuration.mof file located in \ inboxes \ clifiles.src \ hinv, which indicates the WMI provider and WMI classes used. When a client accesses a server on a schedule (to a management point), it downloads a policy to which this file is attached and compiles it locally. After that, based on the schedule, the ConfigMgr client starts the hardware inventory process (hereinafter referred to as hinv).
Here you need to make a small digression. ConfigMgr client consists of an engine and agents, each of which is responsible for a specific functionality. At the same time, the ConfigMgr client uses trigger codes (the list can be viewed here) to start any actions with their agents. To start the hinv agent, use the trigger code {00000000-0000-0000-0000-000000000001}.
The following sequence of actions will occur on the client:
1. Launch hinv on a schedule . The inventoryagent.log will have the following entry:
Inventory: Opening store for action {00000000-0000-0000-0000-000000000001} ...
Inventory: Action = Hardware, ReportType = Delta, MajorVersion = 1, MinorVersion = 5
ReportType - type of the report sent to the Primary site (Delta or FULL). FULL - the report will contain all the information that is collected (by default it is sent during the first inventory). Delta - a report that contains only changes since the previous hinv. Using the Delta report allows you to reduce the size of information sent over the network.
2. Data collection from WMI :
....... ... ............................
Upon completion of the WMI survey, a report is generated that indicates how many WMI classes were not found on this machine. This means that these classes were specified in the client setting for collection, but are absent on this client. This information helps to understand if there is any requested data on the client.
Collection: 55/63 inventory data items successfully inventoried.
Inventory: Collection Task completed in 67.422 seconds
Inventory: 8 Collection Task (s) failed.
3. An xml file is generated for sending to the management point. The file is generated in the% WinDir% \ CCM \ Inventory \ Temp folder:
Inventory: Temp report = C: \ SMS_CCM \ Inventory \ Temp \ 1870d2e7-631c-49e3-87f2-60b90bc1d410.xml InventoryAgent
Inventory: Starting reporting task. InventoryAgent
Reporting: 88 report entries created. InventoryAgent
Inventory: Reporting Task completed in 0.937 seconds InventoryAgent)
4. The xml file is sent to the management point and deleted (by default) .
Inventory: Successfully sent report. Destination: mp: MP_HinvEndpoint, ID: {CF597D3C-8D61-47FC-8292-9711F5AC8430}, Timeout: 80640 minutes MsgMode: Signed, Not Encrypted
If you need to save xml (during the identification and solution of any problems), then you need to create a special "secret" file ARCHIVE_REPORTS.SMS .
The hinv runtime is stored on the client in WMI: root \ ccm \ invagt \ C00000000-0000-0000-0000-000000000001. Accordingly, if you want to force Full inventory to start, you just need to delete the record with the date of the previous hinv - ConfigMgr will automatically start FULL hinv.
Further actions will take place at the management point:
5-7. Management point receives a hinv report and processes it . Then forwards to the Primary site.
7 *. If the Management Point is installed outside the Primary site , the MP File Dispatch Manager component (MPFDM.log) will be used.
Actions on the Primary site side:
8. The Data Loader component (responsible for hinv processing) detects new * .mif files in its inboxes \ auth \ dataldr.box and moves it for further processing to the inboxes \ auth \ dataldr.box \ process \ folder.
9-10. When processing an mif file, data is written to the ConfigMgr database.
9*. If the file was rejected during mif processing, then the file is moved to the inboxes \ auth \ dataldr.box \ bad folder and stored for 14 days. After 14 days, ConfigMgr deletes it automatically. Accordingly, the information does not enter the database and this causes a decrease in reliability, which affects the entire functionality of ConfigMgr.
When moving mif files to bad, ConfigMgr creates subfolders using the type of processing error as the name of the folders. For instance:
InvalidMachine, NonExistentRow, MissingSystemClass, InvalidFileName, ExceedSizeLimit
A detailed description of the reasons for rejecting mif files and how to deal with it is described in the article Umair Khan (Support Escalation Engineer Microsoft Support) . I definitely recommend this article to anyone who works with ConfigMgr of any version.
Based on my experience, I can add that in Russian-language environments (where Cyrillic is used) there is another reason for the rejection of mif files - a mismatch in the dimension of the ServicePack00 field in the dbo.INSTALLED_SOFTWARE_DATA and dbo.INSTALLED_SOFTWARE_HIST tables. By default, the dimension of ServicePack00 (dbo.INSTALLED_SOFTWARE_DATA) is 255 (nvarchar), and the dimension of ServicePack00 (dbo.INSTALLED_SOFTWARE_HIST) is 8 (nvarchar). As a result, when ConfigMgr, while processing the mif file, tries to move the data to the HIST, they may not pass due to the dimension and mif is rejected. The correction option is to change the dimension of the field in the HIST table. But, it must be taken into account that you can make any changes to the ConfigMgr database on the production server only after thorough testing and this can lead to serious failures.
ConfigMgr administrators must constantly monitor the accumulation of rejected mif files. To do this, you can use the operational monitoring systems available in the organization or the Inbox Monitor utility .
The hardware inventory itself is stored in the ConfigMgr database as a large number of views. Current hardware inventory is stored in view starting with v_GS, historical data is stored in views starting with v_HS. Detailed information with a description of all views is available here . Using this information, you can easily get the required reporting with minimal effort.
I hope this article will help ConfigMgr administrators better understand the hinv process and give a clear understanding of how to look for and fix failures that occur during the operation of this functionality.
about the author
Andrey Petrov is an IT specialist with 15 years of experience, specializing in Infrastructure Support, Cloud Computing and DevOps. Previous article on this topic: How not to get confused in the abbreviations SCCM [Crib] .