The author of the article is Mikhail Glazyrin, system and network engineer, Khabarovsk Airport

Hello. Today I would like to talk about the most rarely used features in System Center Configuration Manager - inventory and reporting.

I don’t even know why it happened, but from experience, administrators who installed SCCM in their infrastructure rarely use these two functions. Of course, the killer features of SCCM are the automation of system deployment and software installation. In third place in terms of popularity is the management of the corporate antivirus System Center Endpoint Protection. About the inventory and monitoring in SCCM, many people know at the level of "seen in the management console, but never clicked." It even goes to the point that particularly careless (and I will explain below why) administrators generally disable the inventory functionality in the SCCM client's default policy to supposedly speed up the load and reduce the load on client systems. I’ll say right away that the load from inventory using Configuration Manager tools is an order of magnitude lower than using some other common products (for example, the same Everest). Inventory takes place solely on a schedule, and not every download or every user login, thereby not slowing down the load on client machines.

In this article, we will configure SCCM to proactively monitor the status of hard disks in client machines, but first - a few words about the inventory.
')
More specifically - about the hardware inventory. SCCM has a software inventory based on the collection of information about files and their availability; it will not be discussed in this article. The hardware inventory is all built on WMI, so you can collect any parameters that are available for querying through this interface. SCCM comes standard with many predefined classes covering most needs for collecting information about client machines. Of course, it is not necessary to collect them all. To configure the inventory information, in the SCCM console, open Administration -> Client Settings, properties Default Client Policy -> Hardware Inventory -> Set Classes. Here you can choose what you want to build using SCCM, up to the parameters of the WMI classes. You can assign different inventory policies to different device collections, for example, to enable the collection of battery and power information only for a collection of mobile devices. Such granularity saves the space occupied by the SCCM site database, reduces the load on client machines and, which is important for me personally, corresponds to the best practice “necessary sufficiency”.

Life story

Once the technical support department of our company was puzzled by the possibility of centralized SMART data collection from client machines. Unfortunately, the search did not reveal an acceptable solution in terms of convenience and centralization, and we turned to the tools built into Windows. Windows systems of all currently relevant versions have the SMART data collection functionality from the drives installed in the system. Unfortunately, the system analyzes the information on how and what parameters I could not find, but what is important for us now is that the result of this activity is a WMI parameter, which can be read with the help of SCCM. By the way, this is the same parameter that is responsible for the output of such a familiar window to many:



However, the average user simply closes the window, without giving it any meaning. We will collect this status from all of our computers in order to finally know where to replace the disk.

It is in the root \ wmi namespace , the class is called MSStorageDriver_FailurePredictStatus . A query to this class returns parameters, including the system name of the disk device and its health (part of the output is omitted):

PS C:\Windows\system32> Get-WmiObject -namespace root\wmi -class MSStorageDriver_FailurePredictStatus Active : True InstanceName : SCSI\Disk&Ven_ATA&Prod_WDC_WD5003AZEX-0\4&15828421&0&030000_0 PredictFailure : False Reason : 0 Active : True InstanceName : SCSI\Disk&Ven_ATA&Prod_OCZ-VERTEX3\4&15828421&0&050000_0 PredictFailure : False Reason : 0 ... 

In this output, we are interested in the PredictFailure parameter. We will assemble it by simply adding a new class in the Hardware Inventory Classes window. The procedure of adding has no difficulties. As a result, we obtain the following picture:



After passing the next inventory cycle on a schedule, our parameter will appear in the computer resources:



Of course, it would be quite possible to stop at this, but why, if you can go to the end and force SCCM to send us information about computers with problem disks?

To do this, we use the functionality of generating reports.

Reporting in SCCM works entirely on the basis of SQL Server Reporting Services (and the SCCM management console in the Monitoring -> Reporting section is actually a front-end to simplify working with them). "Out of the box" immediately after installing the product, we get a fairly large number of various, and most importantly, useful reports. They can be used in a one-time mode, and create a subscription. In the latter case, they can be received by mail (useful for obtaining regular information about the state of the infrastructure on certain parameters), or laid out on a network drive (for example, if you need to have at hand an up-to-date registry of any information).

To edit reports you need SQL Server Report Builder . Before modifying a standard report, it is a good idea to first save it under a new name so that you can return to it if necessary. To upload statistics on potentially problematic hard drives, we will have to create a new report from scratch. Yes, I am ready to admit that creating a report from scratch is not a very trivial procedure: you will need knowledge in the area of ​​writing SQL queries and the structure of the SCCM database. And if the information on the first in abundance, then on the second it is not so much.

You can go the way of cheating and somewhat simplify your life by first creating a request through the interface available in the section Monitoring -> Queries.



Then you can just see its source code in the request properties:



This is the place where the main problem scares people from creating reports in SCCM. After all, queries are written in SQL-like language WQL, and reports work directly from the database, and they don’t know about any WQL. If you try to insert such a query directly into the Report Builder, it is reasonable to say that he does not know what SMS_R_System and SMS_G_System are . Everything will become much easier if you know that these objects are views in the SCCM database. Moreover, objects beginning with SMS_R_System correspond to species whose name begins with v_R , and objects SMS_G_System correspond to v_GS . Thus, it is sufficient to simply convert the WQL query to SQL. In our example, SMS_G_System_MSSTORAGEDRIVER_FAILUREPREDICTSTATUS will become v_GS_ MSSTORAGEDRIVER_FAILUREPREDICTSTATUS . In general, if you have any doubts - do not be afraid to open the SCCM database in the SQL Management Studio, everything will become much clearer. All objects, parameters and properties are clearly there:



After you have written a request, it is simple to make a report using the Report Builder wizard.



After that, you can request our new report directly from the SCCM console:



Of course, you can subscribe to the new report in the same way as to any other. It should be remembered that it makes little sense to automatically generate a report more often than we collect new data from client machines. Our technical support department receives this report by mail every week from Monday morning as an attached PDF file.