Urgent inventory. Or I want to know everything
I wanted to share with the habrosobschestvomu a couple of ways to take inventory of equipment quickly and effortlessly. This article gave me a push, but as a supporter of the UNIX-way, I’ll tell you ways to do the same and even more without having to surround yourself with a homogeneous network of identical workstations or bind to one technology.
We want to make a census of the available equipment, depending on the requirements of the management or our own impulses to have comprehensive information about our properties.
I will not claim to be an exhaustive guide, but I will tell you a couple of quick ways.
We want to get information about the stuffing of the organization’s system blocks, for example, to draw up a modernization plan. Have you heard of the Windows integrated SYSTEMINFO command? And she is very useful. It will give you information about the entire system in a digestible form:
Simple and clear.
But do not run all over the company by running the console and copying the output of the command to the textbook on any ball. In our company, this is impossible in principle, politicians are forbidden for users to run CMDs, and when using Run on behalf of, all environment variables fly into the cloud. What to do? YOUR ATTENTION PS-TOOLS !
More specifically, its utility psexec.exe. But not a PSEXEC is a single person alive, the output to the screen is not enough for us, we would also save all this disgrace, and preferably with comfort.
Everything is very simple:
Next, open cmd and write:
ip-list.txt is a text with ip-addresses.
-d - means that psexec will not wait until the command is executed, but simply launch systeminfo as a daemon and disconnect from the client.
-n 12 is the waiting period for the client to respond (in general, it is more correct than the SERVER, but it’s not confusing for long), I have 12 seconds. If during this time it fails to connect, then psexec will miss it. For empty IP it is not necessary, but for all network printers, etc. psexec may try to connect for a long time and tediously.
When the script runs, in \\ share \ audit \ we’ll get a bunch of text-writers named after the computers on the network. What to do next with them, I'll tell you later.
This method is good for everyone and is fast and simple, but it has its drawbacks.
And when the report of the integrated utility is no longer enough, the AIDA64 from FinalWire comes to the rescue. this is the same EVEREST only already purchased by another company and to which the historical name was returned.
In principle, you can get by buying the Business Edition and installation on all stations. then allow them to exchange information and connect to each other on a port of some kind, then rivet the reports from a nice interface. But, firstly, it is not true, and secondly, with the automation of the process, there may be a hitch.
I do Extreme Edition, everything is the same but without network reports.
To begin to taste the fruits of automation you need a few simple operations.
Now using the same psexec.exe, we’ll send a simple script that will run AIDA on the workstations with the parameters we need:
Parameter / R <path> - means that Ida will not display the report on the screen, but will add it along the specified path. % computername% is the cmd environment variable and on each computer where we run Aida it will correspond to the computer name. You can use any other variable, but this is most convenient.
The / TEXT parameter will predetermine the type of report being created and automatically substitute the desired file extension, so after% computername% there is no need to put .txt (% computername% .txt) otherwise we get % computername% .txt.txt
The / CUSTOM parameter makes AIDA understand where to get the list of necessary report components.
That's all. We run this line in the CMD and see how very detailed reports are included in the ball that include full information around the periphery.
I added the execution of this script (without the psexec part) to Startup Scripts in the domain policies.
It would not be correct without some improvement, as a result, the script in the policies looks like this:
Due to this, when booting, every computer on the network checks whether it has sent a report and if not, then it does it, and if so, it does nothing.
And in order to retrieve the data for one or more machines, I simply delete or transfer the relevant entries and after a while I have fresh info.
Attention: on some exotic hardware platforms (which AIDA does not recognize), program development causes crashes and even crashes, a rarity, but it does occur. Therefore, it is better to do reports manually on critical workstations and servers. Fully launching AIDA64 in graphics mode, then the computer does not generate errors, and AIDA simply does not start.
I save the reports in a simple text form as I use bash scripts to analyze and analyze them, and the report storage ball is stored on a linux machine. Therefore, if I want to find out about all the machines: their name, ip and mac, the amount of installed memory, then something like this is done:
This is the simplest processing, but when I learn how to parse XML in any language, of course I will switch to reports in this format.
You can also discuss the possibility of remote inclusion of workstations, and the management of computers over the network is not the last question. But nothing more universal than Wake On Lan has not yet been invented, and the variety of means of remote control is so great that it does not fit into the framework of this article. Moreover, this is a matter of taste.
UDP: Neuronix prompted OCS NG + GLPI. A beautiful and convenient server for * nix with support for graphs and reports + client parts for all possible operating systems. I, however, have problems with clients under Windows 7, but it is possible from the unnatural curvature of the hands. The solution is stationary, you need some server.
UDP2: Yes, AIDA64 is paid, but the trial will be enough for us, as far as the console usage is concerned is unlimited.
UDP3: Solution with AIDA64 fully portable . To throw off everything you need on a flash drive, use relative paths in scripts, and upon arrival at any company, you only need a computer and admin rights.
What do we want?
We want to make a census of the available equipment, depending on the requirements of the management or our own impulses to have comprehensive information about our properties.
I will not claim to be an exhaustive guide, but I will tell you a couple of quick ways.
Method one, at no cost.
We want to get information about the stuffing of the organization’s system blocks, for example, to draw up a modernization plan. Have you heard of the Windows integrated SYSTEMINFO command? And she is very useful. It will give you information about the entire system in a digestible form:
: VIRTUAL-PC : Microsoft Windows 7 : 6.1.7601 Service Pack 1 7601 : Microsoft Corporation : : Multiprocessor Free : virtual : : ****************** : 12.03.2011, 5:28:25 : 15.02.2012, 13:21:15 : innotek GmbH : VirtualBox : X86-based PC (): - 1. [01]: x64 Family 6 Model 15 Stepping 11 Genuin eIntel ~2574 BIOS: innotek GmbH VirtualBox, 01.12.2006 Windows: C:\Windows : C:\Windows\system32 : \Device\HarddiskVolume1 : ru; : en-us; () : (UTC+04:00) , , - : 631 : 248 : . : 1 655 : : 1 056 : : 599 : C:\pagefile.sys : *********** : \\SERVER (): - 54. : - 2. [01]: Intel(R) PRO/1000 MT Desktop Adapter : DHCP : IP- [01]: 192.168.16.170 [02]: Intel(R) PRO/1000 MT Desktop Adapter : 2 DHCP : IP- [01]: 192.168.19.1 [02]: ****::25e7:a222:dc08:**** Simple and clear.
But do not run all over the company by running the console and copying the output of the command to the textbook on any ball. In our company, this is impossible in principle, politicians are forbidden for users to run CMDs, and when using Run on behalf of, all environment variables fly into the cloud. What to do? YOUR ATTENTION PS-TOOLS !
More specifically, its utility psexec.exe. But not a PSEXEC is a single person alive, the output to the screen is not enough for us, we would also save all this disgrace, and preferably with comfort.
Everything is very simple:
- We create a ball with recording rights to everyone, and then you never know what the trimmed rights are at workstations (sic! It is stations, because we are not interested in the rights of users of these stations, we will do everything on our own behalf). Well, for example, \\ share \ audit \
- We draw a file in our aypishnikami. The fact is that psexec, for unclear reasons, does not understand address ranges of the type 192.168.0.1-192.168.0.254 or 192.168.0.0/24. Of course, you can deceive him and slip him like, but this is not stable and harmful, I will explain below why. I use OO Calc to create a list of IP addresses. As a result, we get a textbook (.txt) with something like this:
192.168.0.1 192.168.0.2 ... 192.168.0.254
192.168.16.255 - broadcast and do not need to use it. Also from the list you can exclude the addresses of equipment and servers to which you do not want to connect. You can use the list with the names of computers, but I do not.
Next, open cmd and write:
psexec.exe @c:\ip-list.txt -d -n 12 systeminfo > \\share\audit\%COMPUTERNAME%.txt ip-list.txt is a text with ip-addresses.
-d - means that psexec will not wait until the command is executed, but simply launch systeminfo as a daemon and disconnect from the client.
-n 12 is the waiting period for the client to respond (in general, it is more correct than the SERVER, but it’s not confusing for long), I have 12 seconds. If during this time it fails to connect, then psexec will miss it. For empty IP it is not necessary, but for all network printers, etc. psexec may try to connect for a long time and tediously.
When the script runs, in \\ share \ audit \ we’ll get a bunch of text-writers named after the computers on the network. What to do next with them, I'll tell you later.
This method is good for everyone and is fast and simple, but it has its drawbacks.
- Here the information is only on the contents of the system box and a little bit on Windows.
- Although the installed programs are stored inside the system unit, nothing is displayed about them either.
- Even on the inside, there is little information, for example, there is nothing about the type of RAM, only volume. And the processor is lit very poorly.
Want to know everything
And when the report of the integrated utility is no longer enough, the AIDA64 from FinalWire comes to the rescue. this is the same EVEREST only already purchased by another company and to which the historical name was returned.
In principle, you can get by buying the Business Edition and installation on all stations. then allow them to exchange information and connect to each other on a port of some kind, then rivet the reports from a nice interface. But, firstly, it is not true, and secondly, with the automation of the process, there may be a hitch.
I do Extreme Edition, everything is the same but without network reports.
To begin to taste the fruits of automation you need a few simple operations.
- Repeat preparation steps for Systeminfo
- We put AIDA64
- Copy the folder with the installed AIDA64 from the Program Files somewhere on the public ball. For example \\ share \ audit \ aida
- In AIDA go to the master reports
')
Item "user selectable" - And here we choose the information we need.
The main thing is not to overdo it. Too many of the selected items will significantly load client machines, besides, there will be a huge, excessively excessive report, about 1Mb of textual information. - We press further and select the desired type of report. I recommend TEXT or XML, they are easier to parse.
Then click Finish and get a report on our machine. The aida64.rpf file will appear in the program folder. We copy it in the same place where we have the executable file: \\ share \ audit \ aida .
My file looks like this:ReportProfile="Custom" ProfileFile="\\share\audit\aida\aida64.rpf" ReportFormat="txt" ( , ) RemoteReportFolder="C:\Users\***\Documents\AIDA64 Reports" ( , ) RemoteReportFileName="$HOSTNAME" ( , ) InfoPage="Computer;Summary" InfoPage="Computer;Computer Name" InfoPage="Computer;DMI" InfoPage="Computer;Sensor" InfoPage="Motherboard;CPU" InfoPage="Motherboard;CPUID" InfoPage="Motherboard;Motherboard" InfoPage="Motherboard;Memory" InfoPage="Motherboard;Chipset" InfoPage="Motherboard;BIOS" InfoPage="Operating System;Operating System" InfoPage="Server;Share" InfoPage="Server;Opened Files" InfoPage="Display;Windows Video" InfoPage="Display;GPU" InfoPage="Display;Monitor" InfoPage="Storage;Logical Drives" InfoPage="Storage;Physical Drives" InfoPage="Network;Windows Network" InfoPage="Software;Installed Programs" - Done!
Now using the same psexec.exe, we’ll send a simple script that will run AIDA on the workstations with the parameters we need:
psexec.exe @c:\ip-list.txt -d -n 12 \\share\audit\aida\aida64.exe /R \\share\audit\%COMPUTERNAME% /TEXT /CUSTOM \\share\audit\aida\aida64.rpf Parameter / R <path> - means that Ida will not display the report on the screen, but will add it along the specified path. % computername% is the cmd environment variable and on each computer where we run Aida it will correspond to the computer name. You can use any other variable, but this is most convenient.
The / TEXT parameter will predetermine the type of report being created and automatically substitute the desired file extension, so after% computername% there is no need to put .txt (% computername% .txt) otherwise we get % computername% .txt.txt
The / CUSTOM parameter makes AIDA understand where to get the list of necessary report components.
That's all. We run this line in the CMD and see how very detailed reports are included in the ball that include full information around the periphery.
In domain
I added the execution of this script (without the psexec part) to Startup Scripts in the domain policies.
It would not be correct without some improvement, as a result, the script in the policies looks like this:
if not exist \\share\audit\%COMPUTERNAME%.txt ( \\share\audit\aida\aida64.exe /R \\share\audit\%COMPUTERNAME% /TEXT /CUSTOM \\share\audit\aida\aida64.rpf ) else exit Due to this, when booting, every computer on the network checks whether it has sent a report and if not, then it does it, and if so, it does nothing.
And in order to retrieve the data for one or more machines, I simply delete or transfer the relevant entries and after a while I have fresh info.
Attention: on some exotic hardware platforms (which AIDA does not recognize), program development causes crashes and even crashes, a rarity, but it does occur. Therefore, it is better to do reports manually on critical workstations and servers. Fully launching AIDA64 in graphics mode, then the computer does not generate errors, and AIDA simply does not start.
Parse received logs
I save the reports in a simple text form as I use bash scripts to analyze and analyze them, and the report storage ball is stored on a linux machine. Therefore, if I want to find out about all the machines: their name, ip and mac, the amount of installed memory, then something like this is done:
iconv -f cp1251 ./*.txt | egrep -i " | ip| mac| | " This is the simplest processing, but when I learn how to parse XML in any language, of course I will switch to reports in this format.
Lyrics
You can also discuss the possibility of remote inclusion of workstations, and the management of computers over the network is not the last question. But nothing more universal than Wake On Lan has not yet been invented, and the variety of means of remote control is so great that it does not fit into the framework of this article. Moreover, this is a matter of taste.
UDP: Neuronix prompted OCS NG + GLPI. A beautiful and convenient server for * nix with support for graphs and reports + client parts for all possible operating systems. I, however, have problems with clients under Windows 7, but it is possible from the unnatural curvature of the hands. The solution is stationary, you need some server.
UDP2: Yes, AIDA64 is paid, but the trial will be enough for us, as far as the console usage is concerned is unlimited.
UDP3: Solution with AIDA64 fully portable . To throw off everything you need on a flash drive, use relative paths in scripts, and upon arrival at any company, you only need a computer and admin rights.
Source: https://habr.com/ru/post/138400/
All Articles