SCCM Inventory
At the word “inventory”, an ordinary person recalls the situation when, when he entered the store, you see a sign on the closed door and you think that you will have to go through several more houses, and at worst quarters, to buy what you need. An unusual person working with Microsoft System Center Configuration Manager, at the mention of the word, presents a bunch of problems associated with the reliability of the results. About their decision we will talk under the cut.
I give the word to the author.
Hello colleagues. Each administrator working with Microsoft System Center Configuration Manager (hereinafter referred to as ConfigMgr) daily uses the inventory functionality (Inventory). This is the basic functionality that collects data about the managed environment and in the future it is used to build collections, queries, reports. With the seeming ease of setting up and using the inventory functionality, ConfigMgr administrators face constant problems with the accuracy of the results obtained. The task of the article is to give a complete 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 the “what is under the hood”.
')
Before we go deep, you need to discuss a little disclaimer. ConfigMgr works with both Windows operating systems, and Linux / Unix (using nanoWbem), with mobile systems. ConfigMgr was originally developed as a product for managing Windows OS, so for full technical coverage in the article we will consider only customers running Windows. If there is an interest in understanding how inventory works for Linux / Unix - write in the comments, think about writing an article. We now turn to the most interesting.
ConfigMgr has two different types of inventory - hardware inventory ( in Russian documentation - hardware inventory) and software inventory ( respectively, software inventory). In the article I will use English-language titles. 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 essence, hardware inventory is WMI inventory, and software inventory is file inventory (collection of file properties using a given mask). That is why the list of installed software ConfigMgr collects through hardware inventory - this information is in the WMI classes (partly in the default, partly in the ConfigMgr client WMI classes).
In practice, hardware inventory is more used and more critical for the success of everyday tasks. Therefore, in this article, we closely examine it.
To use this functionality, it is necessary that the client settings (client settings -> Hardware inventory) on the Primary site side be set to “enable”, a schedule is set, WMI classes are selected, information from which must be collected (some of the classes are enabled by default). A full description of the WMI classes is on MSDN .
ConfigMgr uses the Configuration.mof file located in \ inboxes \ clifiles.src \ hinv, which specifies the classes used by the WMI provider, WMI. When a client on a schedule accesses the server (to the management point - management point), it downloads the policy to which this file is attached and compile it locally. After that, based on the schedule, the ConfigMgr client starts the hardware inventory process (hereinafter referred to as hinv).
Here it is necessary to make a small digression. ConfigMgr client consists of an engine (engine) and agents, each of which is responsible for a specific functionality. At the same time, the ConfigMgr client uses trigger codes (you can see the list here ) to launch any actions with its agents. To run the hinv agent, use the trigger code {00000000-0000-0000-0000-000000000001}.
The following sequence of actions will occur on the client:
1. Run hinv on a schedule . In inventoryagent.log will be the following entry:
ReportType - type of report sent to the Primary site (Delta or FULL). FULL - the report will contain all the information that has been collected (the default is sent at the first inventory). Delta is 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. Collect data from WMI :
Upon completion of the WMI survey, reporting is generated, which 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 not on this client. This information helps to understand whether there is any requested data at all 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 the xml (during the identification and solution of any problems), then you need to create a special "secret" file ARCHIVE_REPORTS.SMS .
The hinv execution date is stored on the client in WMI: root \ ccm \ invagt \ C00000000-0000-0000-0000-000000000001. Accordingly, if you need to force Full inventory, you just need to delete the record with the date of the previous hinv - ConfigMgr will automatically run FULL hinv.
Further actions will take place at the management point:
5-7. Management point receives the hinv report and processes it . After that, it sends to Primary site.
7 *. If the Management Point is installed outside the Primary site , then the MP File Dispatch Manager component (MPFDM.log) will be used.
Actions on the Primary site:
8. The Data Loader component (Responsible for hinv processing) detects new * .mif files in its inboxes \ auth \ dataldr.box root folder and moves it for further processing to the inboxes \ auth \ dataldr.box \ process \ folder.
9-10. When processing the mif file, the data is written to the ConfigMgr database.
9*. If the mif file was rejected during processing , 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 in the database does not fall and this is the reason for reducing the reliability, which affects all the functionality of ConfigMgr.
When moving mif files to bad, ConfigMgr creates subfolders using the type of processing error as the folder name. For example:
A detailed description of the reasons for the rejection of mif files and how to deal with this 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 versions.
Based on my experience, I can add that in Russian-speaking environments (where Cyrillic is used) there is another reason for the rejection of mif files - the discrepancy between the dimensions of the ServicePack00 field in the dbo.INSTALLED_SOFTWARE_DATA and dbo.INSTALLED_SOFTWARE_HIST tables. By default, the ServicePack00 dimension (dbo.INSTALLED_SOFTWARE_DATA) is 255 (nvarchar), and the ServicePack00 dimension (dbo.INSTALLED_SOFTWARE_HIST) is 8 (nvarchar). As a result, when ConfigMgr, when processing the mif file, tries to move the data to the HIST, it may not pass because of the dimension and the mif is rejected. The correction option is a change in the dimension of the field in the HIST table. But, it is necessary to take into account that any changes in the ConfigMgr database on the production server can be made only after thorough testing and this can lead to serious failures.
ConfigMgr administrators should constantly monitor the process of accumulating rejected mif files. For this, you can use operational monitoring systems available in your organization or the Inbox Monitor utility.
The hardware inventory itself is stored in the ConfigMgr database as a large number of views. The actual hardware inventory is stored in a 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 obtain the required reports with minimal effort.
I hope this article will help ConfigMgr administrators to better understand the hinv process and will give a clear understanding of how to find and eliminate 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 [Cheat Sheet] .
I give the word to the author.
Hello colleagues. Each administrator working with Microsoft System Center Configuration Manager (hereinafter referred to as ConfigMgr) daily uses the inventory functionality (Inventory). This is the basic functionality that collects data about the managed environment and in the future it is used to build collections, queries, reports. With the seeming ease of setting up and using the inventory functionality, ConfigMgr administrators face constant problems with the accuracy of the results obtained. The task of the article is to give a complete 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 the “what is under the hood”.
')
Disclaimer
Before we go deep, you need to discuss a little disclaimer. ConfigMgr works with both Windows operating systems, and Linux / Unix (using nanoWbem), with mobile systems. ConfigMgr was originally developed as a product for managing Windows OS, so for full technical coverage in the article we will consider only customers running Windows. If there is an interest in understanding how inventory works for Linux / Unix - write in the comments, think about writing an article. We now turn to the most interesting.
Let's go to inventory
ConfigMgr has two different types of inventory - hardware inventory ( in Russian documentation - hardware inventory) and software inventory ( respectively, software inventory). In the article I will use English-language titles. 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 essence, hardware inventory is WMI inventory, and software inventory is file inventory (collection of file properties using a given mask). That is why the list of installed software ConfigMgr collects through hardware inventory - this information is in the WMI classes (partly in the default, partly in the ConfigMgr client WMI classes).
In practice, hardware inventory is more used and more critical for the success of everyday tasks. Therefore, in this article, we closely examine it.
To use this functionality, it is necessary that the client settings (client settings -> Hardware inventory) on the Primary site side be set to “enable”, a schedule is set, WMI classes are selected, information from which must be collected (some of the classes are enabled by default). A full description of the WMI classes is on MSDN .
ConfigMgr uses the Configuration.mof file located in \ inboxes \ clifiles.src \ hinv, which specifies the classes used by the WMI provider, WMI. When a client on a schedule accesses the server (to the management point - management point), it downloads the policy to which this file is attached and compile it locally. After that, based on the schedule, the ConfigMgr client starts the hardware inventory process (hereinafter referred to as hinv).
Here it is necessary to make a small digression. ConfigMgr client consists of an engine (engine) and agents, each of which is responsible for a specific functionality. At the same time, the ConfigMgr client uses trigger codes (you can see the list here ) to launch any actions with its agents. To run the hinv agent, use the trigger code {00000000-0000-0000-0000-000000000001}.
The following sequence of actions will occur on the client:
1. Run hinv on a schedule . In inventoryagent.log will be 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 report sent to the Primary site (Delta or FULL). FULL - the report will contain all the information that has been collected (the default is sent at the first inventory). Delta is 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. Collect data from WMI :
……
<! [LOG [Collection: Namespace = \\. \ Root \ cimv2; Query = SELECT __CLASS, __PATH, __RELPATH, UUID FROM Win32_ComputerSystemProduct; Timeout = 600 secs.] LOG]!>
<! [LOG [Collection: Namespace = \\. \ Root \ ccm \ invagt; Query = SELECT __CLASS, __PATH, __RELPATH, Domain FROM CCM_ComputerSystem; Timeout = 600 secs.] LOG]!>
... ............................
Upon completion of the WMI survey, reporting is generated, which 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 not on this client. This information helps to understand whether there is any requested data at all 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. Inventoryvent
Reporting: 88 report entries created. Inventoryvent
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 the xml (during the identification and solution of any problems), then you need to create a special "secret" file ARCHIVE_REPORTS.SMS .
The hinv execution date is stored on the client in WMI: root \ ccm \ invagt \ C00000000-0000-0000-0000-000000000001. Accordingly, if you need to force Full inventory, you just need to delete the record with the date of the previous hinv - ConfigMgr will automatically run FULL hinv.
Further actions will take place at the management point:
5-7. Management point receives the hinv report and processes it . After that, it sends to Primary site.
<! [LOG [Hinv Retry: ******************* Start of Task ******************* *] LOG]!>
<! [LOG [Hinv: Loaded class definition map; DB policy timestamp = 2016-12-28 08: 07: 10.000] LOG]!>
<! [LOG [Hinv: Normalized DB policy timestamp: 20161228080710.000000 + 000.] LOG]!>
<! [LOG [Hinv Sax: loading C: \ CM2012CB \ inboxes \ auth \ dataldr.box \ HinvAttachmentYNWMKIXC.xml] LOG]!>
<! [LOG [Delta report from client ****, action description = Hardware] LOG]!>
<! [LOG [Hinv Task: Translate report attachment to file "C: \ CM2012CB \ inboxes \ auth \ dataldr.box \ HCJ91LAV.MIF" returned 0] LOG]!>
7 *. If the Management Point is installed outside the Primary site , then the MP File Dispatch Manager component (MPFDM.log) will be used.
Actions on the Primary site:
8. The Data Loader component (Responsible for hinv processing) detects new * .mif files in its inboxes \ auth \ dataldr.box root folder and moves it for further processing to the inboxes \ auth \ dataldr.box \ process \ folder.
9-10. When processing the mif file, the data is written to the ConfigMgr database.
9*. If the mif file was rejected during processing , 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 in the database does not fall and this is the reason for reducing the reliability, which affects all the functionality of ConfigMgr.
When moving mif files to bad, ConfigMgr creates subfolders using the type of processing error as the folder name. For example:
InvalidMachine, NonExistentRow, MissingSystemClass, InvalidFileName, ExceedSizeLimit
A detailed description of the reasons for the rejection of mif files and how to deal with this 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 versions.
Based on my experience, I can add that in Russian-speaking environments (where Cyrillic is used) there is another reason for the rejection of mif files - the discrepancy between the dimensions of the ServicePack00 field in the dbo.INSTALLED_SOFTWARE_DATA and dbo.INSTALLED_SOFTWARE_HIST tables. By default, the ServicePack00 dimension (dbo.INSTALLED_SOFTWARE_DATA) is 255 (nvarchar), and the ServicePack00 dimension (dbo.INSTALLED_SOFTWARE_HIST) is 8 (nvarchar). As a result, when ConfigMgr, when processing the mif file, tries to move the data to the HIST, it may not pass because of the dimension and the mif is rejected. The correction option is a change in the dimension of the field in the HIST table. But, it is necessary to take into account that any changes in the ConfigMgr database on the production server can be made only after thorough testing and this can lead to serious failures.
ConfigMgr administrators should constantly monitor the process of accumulating rejected mif files. For this, you can use operational monitoring systems available in your organization or the Inbox Monitor utility.
The hardware inventory itself is stored in the ConfigMgr database as a large number of views. The actual hardware inventory is stored in a 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 obtain the required reports with minimal effort.
I hope this article will help ConfigMgr administrators to better understand the hinv process and will give a clear understanding of how to find and eliminate 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 [Cheat Sheet] .
Source: https://habr.com/ru/post/329792/
All Articles