Get free, quick, easy and simple system information from a variety of PCs on the network

In the process of any IT specialist, there are times when you need to get information about the system. Sometimes you need to collect some one or a number of system parameters from multiple workstations and quickly process them. The more quickly the information will be obtained, the better of course. In this article I want to introduce the powershell module, with which you can quickly get almost any information about the system. For example: I was able to collect information about the amount of RAM from several hundred workstations, spending a little more than twenty seconds to do it!

On the Internet, you can find a large number of powershell scripts that receive this or that information about the system. As a rule, these are small scripts or functions that use wmi. For one workstation, they perform their task superbly, but if there are many computers, then problems occur.

The main disadvantage is that the collection of information is synchronous, the script does not proceed to the next computer until it works on the current one. As a result, to learn information from the entire PC fleet, at best, you can wait a very long time, at worst, the scenario may hang and never end.

I wanted to make some kind of universal tool. devoid of the above disadvantage. For ease of use, the powershell module was written, which currently contains one Get-Systeminfo function.
')
Today, the function allows you to get a lot of different information about the system. In fact, it contains a large collection of scripts and can be easily expanded by adding new scripts.

Main features of the function

• Multithreading
• You can use the DCOM and WSMAN protocols to connect to a remote computer
• Working with the pipeline (for example, in a domain, you can query a list of computers using the Get-Adcomputer cmdlet with the -filter parameter; piping the result of its execution, Get-Systeminfo, we will receive information from all computers in the domain)
• Easy scalability

I will not consider the technical aspects of how the module works. Instead, I will try to clearly explain how to use and how to expand the functionality.

How to use the Get-SystemInfo function

When working with the Get-Adcomputer cmdlet, I noticed the Properties parameter. He allowed to expand the standard output of the command with the properties that were listed after it. This concept was taken as a basis. For example, in order to request information about the processor model and RAM, after the Properties parameter, you need to list, separated by commas, the properties that we want to see as a result of the execution.


For grouping properties, switch parameters are used. You can use several switch parameters and the Properties parameter


During the work of the function, two global variables $ Result and $ ErrorResult are created. The first one contains computers from which it was possible to obtain information. The second contains the computers on which errors occurred.

These variables are convenient to use after the function has completed. For example, using the standard Where-Object cmdlet, you can select from all the results those that meet certain criteria.

More detailed information and examples can be obtained by running the command Get-Help Get-Systeminfo -Examples after installing the module

configuration file

The Get-Systeminfo function has a configuration file located in the config folder. It is a powershell script containing the basic settings. The presence of this file will allow you to make changes to the function without editing the main code of the module. In order to expand or remove unnecessary functionality - you just need to change this file.
The main variables in the file.

$ Defaultinfoconfig determines what information will be obtained when the function is run without any parameters. By adding or removing properties from an array, you can customize what information will be obtained.

$ Functionconfig contains a hash table. Where the key is the property that will be specified in the Properties parameter, and the value is a string in the style of the powershell parameters. The following parameters are allowed in the string: Class, Query, Property, Script, FormatList

$ ManualNamespace contains a hash table, where the key is a class, and value is the namespace in which the class is located. Changes to the table need to be made in the event that the class necessary for the work does not belong to the root \ cimv2 namespace.

$ Switchconfig contains a hash table: the key is the name of the switch parameter, and the value is an array of properties.

How to expand the features of the function

Suppose you need to add the ability to get the name of the OS. This requires 4 steps.

1. Come up with a name that will uniquely characterize what we want to get. In this case, call OsCaption.
2. Make changes to the function parameter block by editing the Systeminfo.psm1 file. You need to change [ValidateSet ()] for the Properties parameter, adding the name invented in the first step.
3. Modify configuration file. Since the name of the OS can be obtained through wmi object class Win32_OperatingSystem (property caption)
   
   
   Spoiler

   
   
   
   you need to add a row of the form $ Functionconfig to the hash table
   
   OsCaption='-Class Win32_OperatingSystem -Property Caption'
4. If powershell is running and the module has been loaded: you must restart the console, or execute Remove-Module Systeminfo

Having executed four simple actions, we received new functionality.


It is not always possible to get the necessary information directly from the wmi object. Sometimes for obtaining information it is required to process objects of several classes. For these cases, you need to write a script.

All module scripts are stored in the Scripts folder. You can refer to them using the Script parameter in the $ functionconfig hash table. That is, if in the previous example a script was needed and it needed objects of several classes to work, then the row for the hash table would take the following form

 OsCaption='-Class Win32_OperatingSystem,Win32_ComputerSystem -Script Scriptfolder\oscaptionscript.ps1' 

After the Class parameter, you need to list the objects of which classes are required for work. In the script, they will be accessible through variables with the same name — in this example, it is $ win32_operatingsystem and $ win32_computersystem. In addition, in all scenarios there are three service variables — $ Computername, $ Protocol, and $ Credential.

The script for the module is no different from the usual, except that you do not need to use Get-Wmiobject, since wmi objects are already available through the corresponding variable. For the Dcom protocol, you need to take into account that all information must be obtained via wmi. You will not be able to use get-process get-services cmdlets and the like. This is due to the place of execution of scripts. In the case of the Dcom protocol, all scripts are executed where the Get-Systeminfio function is running.

If the Wsman protocol is used to connect, the scripts are executed on the computer from which we receive the information, so there are no restrictions: you can use any cmdlets. The remaining nuances of using the configuration file can be understood by studying it in detail. Now there are many examples.

The module was tested on the second and fifth versions of powershell, but most likely it will work on all others. I recommend using version 5, as there was a function of auto add-on, which greatly facilitates the work.