Czasem (koniec roku to dobry pretekst) ktoś zadaje administratorom pytanie "a co tak naprawdę mamy w naszej sieci?". Administratorzy nie kochają takich pytań, głównie dlatego, że kojarzą im się z wędrówką od biurka do biurka, papierowymi arkuszami do wypełniania i przepisywaniem wszystkiego w ładne tabelki dla szefostwa.
Administrator szanujący swój czas i wiedzę skorzysta z automatu. Jest takich wynalazków wiele, pracujących na najróżniejszych zasadach, z bardzo różnymi cenami i możliwościami. Ale może by tak użyć wyłącznie tego, co już jest w systemie? Przecież jest PowerShell. Prostym skryptem (znacząco milszym niż rozwiązania vbs z ubiegłego wieku) można dowiedzieć się tego, co jest w danym momencie potrzebne.
Do sięgania do zdalnych maszyn dobrze nada się WMI. Metoda ta dostępna jest od Windows 2000 i mimo, że całkiem skuteczna – jest mało popularna w świadomości administratorów. Tymczasem ma ona dwie niepodważalne zalety:
- Działa na zdalnych komputerach
- Potrafi naprawdę głęboko sięgnąć po informację
Pierwsza zaleta uwolni administratora od wysyłania maili z cyklu "proszę o uruchomienie skryptu z załącznika i przesłanie mi wyniku", druga zaś pozwala odkryć rzeczy, które wydają się całkiem solidnie schowane. Szybkość i ilość kości RAMu, pojemność baterii, obroty wiatraków, numery seryjne twardych dysków itd. A do tego oczywiście zupełnie "zwykłe" rzeczy takie jak udziały sieciowe, usługi systemowe itp.
Żeby zapytać o coś używając WMI i PowerShella należy wydać polecenie:
Get-WMIObject –ComputerName <nazwa_komputera> Nazwa_klasy_WMI
Oczywiście administrator bywa leniwy, więc robienie tego komputer po komputerze nie jest najlepszym podejściem. Zakładając, że mamy plik tekstowy z nazwami komputerów do sprawdzenia (nazwijmy go machines.txt) możemy użyć powershellowego polecenia Get-Content. W takiej sytuacji, polecenie przyjmie postać:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Nazwa_klasy_WMI
O nazwach klas będzie jeszcze za chwilę, ale na razie można dla testów spróbować z Win32_Product.
Jak widać ,coś jest zwracane, wygląda nawet jak lista zainstalowanego oprogramowania ale... jakoś jest tak skromnie z tymi informacjami. To już urok PowerShella, że jak mu administrator nie powie wprost, co jest dla niego ważne, to PowerShell spróbuje odgadnąć sam. Wystarczy poprosić "daj mi wszystko co wiesz" i od razu informacji jest o wiele więcej:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Select-Object *
Oczywiście zamiast gwiazdki (oznaczającej wszystkie właściwości danej klasy) można samodzielnie wymienić te właściwości, które są szczególnie interesujące. Na przykład:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Select-Object Caption, InstallDate
Otrzymaną w ten sposób listę można filtrować (na przykład nie wyświetlać oprogramowania zawierającego w swojej nazwie słowo "Microsoft") przy pomocy polecenia Where-Object:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Where-Object {$_.Caption –notlike '*Microsoft*'} | Select-Object Caption, InstallDate
Składnia polecenia Where-Object wymaga nieco wprawy, ale znając operatory like i notlike można dość prosto zmodyfikować na własne potrzeby powyższy przykład. Można oczywiście zamiast filtrować po nazwie użyć właściwości Vendor, która pokazuje aplikacje Microsoftu nawet, jeżeli ich nazwa nie zawiera bezpośrednio tej informacji.
Dla administratora te parę linijek na ekranie to rzecz cenna, ale co z szefostwem?Są to zwykle ludzie nadzwyczaj odporni na piękno PowerShella... Dla nich istnieją polecenia ConvertTo-Html. Wygenerowana na ekranie tabelka może być w HTMLu, dzięki czemu można ją wkleić do maila albo pokazać komuś nie-informatycznemu. Użycie jest bardzo proste: wynik wygenerowany przez poprzedni przykład należy przekazać (używając | jak to w PowerShell) do wspomnianego powyżej ConvertTo-HTML.
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Where-Object {$_.Caption –notlike '*Microsoft*'} | Select-Object Caption, InstallDate | ConvertTo-Html
Działa? Działa… tylko wynik pojawia się na ekranie. PowerShell tak właśnie robi, jeżeli administrator jasno nie powie, co ma się z wynikiem stać. Więc powiedzmy – oddajmy go kolejnemu powershellowemu mechanizmowi, który zapisze go do pliku:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Where-Object {$_.Caption –notlike '*Microsoft*'} | Select-Object Caption, InstallDate | ConvertTo-Html | Out-File c:\test\oprogramowanie.html
Plik powstał, tabelka się otwiera w przeglądarce, ale jeszcze może razić niektórych estetów. Dlatego, warto zrobić sobie zmienną $naglowek zawierającą parę wskazówek na temat formatowania:
$naglowek = "<style>"
$naglowek = $naglowek + "BODY{background-color:pink;}"
$naglowek = $naglowek + "TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}"
$naglowek = $naglowek + "TH{border-width: 1px;padding: 0px;border-style: solid;border-color: black;background-color:green}"
$naglowek = $naglowek + "TD{border-width: 1px;padding: 0px;border-style: solid;border-color: black;background-color:yellow}"
$naglowek = $naglowek + "</style>"
Nie należy ani trochę ufać moim sugestiom estetycznym i lepiej spróbować z własnymi ulubionymi kolorami.
Teraz wystarczy powiedzieć, że polecenie generujące HTML ma użyć naszego nagłówka.
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Where-Object {$_.Caption –notlike '*Microsoft*'} | Select-Object Caption, InstallDate | ConvertTo-Html –head $naglowek | Out-File c:\test\oprogramowanie.html
I gotowe. Plik z inwentaryzacją oprogramowania dla szefa zrobiony w parę minut. Jeżeli szef lubi Excela i chce sam sobie poprzestawiać co i jak wyświetli się na ekranie, administrator może zamiast ConvertTo-Html użyć ConvertTo-CSV i wynikowy plik wczytać prosto do arkusza.
Na końcu miało być o klasach WMI.
Otóż nawet najdłuższy wpis na blogu nie ujmie tego, co rzetelnie opisane jest na stronach MSDN.
Żeby wymienić na szybko to, co może przydać się podczas inwentaryzacji, wspomnieć należy:
- Win32_BaseBoard – dla płyt głównych
- Win32_Battery – dla baterii w laptopach
- Win32_BIOS – dla BIOSów
- Win32_CacheMemory – dla pamięci podręcznej
- Win32_CDROMDRIVE – dla napędów optycznych
- Win32_CodecFile – dla kodeków audio i video
- Win32_ComputerSystem – dla ogólnych parametrów komputera
- Win32_DiskDrive – dla dysków fizycznych
- Win32_Fan – dla wiatraczków
- Win32_NetworkAdapter – dla kart sieciowych
- Win32_OperatingSystem – dla wersji i edycji systemu operacyjnego
- Win32_PhysicalMemory – dla zainstalowanych kości pamięci
- Win32_Printer – dla drukarek
- Win32_Process – dla aktywnych procesów
- Win32_Processor – dla procesorów
- Win32_Share – dla udziałów sieciowych
I wiele, wiele innych czasem bardzo potrzebnych a czasem traktowanych wyłącznie jako ciekawostka. Ale administrator, który wie, z czego może skorzystać a do tego ma narzędzia pozwalające na odpytywanie zdalnych komputerów i ładną prezentację wyników – może dość swobodnie wyciągać od swoich systemów te informacje, które mu są w danym momencie potrzebne.
Warto też sięgnąć po PowerShell Quick Reference po polsku. Dwustronicowa ściągawka pozwoli wyjść poza Copy&Paste gotowych poleceń i podpowie czasem jak zrobić polecenie PowerShell jeszcze lepiej dostosowane do konkretnych potrzeb.
Autor: Grzegorz Tworek [MVP]