Inwentaryzacja
Czasem (koniec roku to dobry pretekst) ktos zadaje administratorom pytanie "a co tak naprawde mamy w naszej sieci?". Administratorzy nie kochaja takich pytan, glównie dlatego, ze kojarza im sie z wedrówka od biurka do biurka, papierowymi arkuszami do wypelniania i przepisywaniem wszystkiego w ladne tabelki dla szefostwa.
Administrator szanujacy swój czas i wiedze skorzysta z automatu. Jest takich wynalazków wiele, pracujacych na najrózniejszych zasadach, z bardzo róznymi cenami i mozliwosciami. Ale moze by tak uzyc wylacznie tego, co juz jest w systemie? Przeciez jest PowerShell. Prostym skryptem (znaczaco milszym niz rozwiazania vbs z ubieglego wieku) mozna dowiedziec sie tego, co jest w danym momencie potrzebne.
Do siegania do zdalnych maszyn dobrze nada sie WMI. Metoda ta dostepna jest od Windows 2000 i mimo, ze calkiem skuteczna – jest malo popularna w swiadomosci administratorów. Tymczasem ma ona dwie niepodwazalne zalety:
- Dziala na zdalnych komputerach
- Potrafi naprawde gleboko siegnac po informacje
Pierwsza zaleta uwolni administratora od wysylania maili z cyklu "prosze o uruchomienie skryptu z zalacznika i przeslanie mi wyniku", druga zas pozwala odkryc rzeczy, które wydaja sie calkiem solidnie schowane. Szybkosc i ilosc kosci RAMu, pojemnosc baterii, obroty wiatraków, numery seryjne twardych dysków itd. A do tego oczywiscie zupelnie "zwykle" rzeczy takie jak udzialy sieciowe, uslugi systemowe itp.
Zeby zapytac o cos uzywajac WMI i PowerShella nalezy wydac polecenie:
Get-WMIObject –ComputerName <nazwa_komputera> Nazwa_klasy_WMI
Oczywiscie administrator bywa leniwy, wiec robienie tego komputer po komputerze nie jest najlepszym podejsciem. Zakladajac, ze mamy plik tekstowy z nazwami komputerów do sprawdzenia (nazwijmy go machines.txt) mozemy uzyc powershellowego polecenia Get-Content. W takiej sytuacji, polecenie przyjmie postac:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Nazwa_klasy_WMI
O nazwach klas bedzie jeszcze za chwile, ale na razie mozna dla testów spróbowac z Win32_Product.
Jak widac ,cos jest zwracane, wyglada nawet jak lista zainstalowanego oprogramowania ale... jakos jest tak skromnie z tymi informacjami. To juz urok PowerShella, ze jak mu administrator nie powie wprost, co jest dla niego wazne, to PowerShell spróbuje odgadnac sam. Wystarczy poprosic "daj mi wszystko co wiesz" i od razu informacji jest o wiele wiecej:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Select-Object *
Oczywiscie zamiast gwiazdki (oznaczajacej wszystkie wlasciwosci danej klasy) mozna samodzielnie wymienic te wlasciwosci, które sa szczególnie interesujace. Na przyklad:
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Select-Object Caption, InstallDate
Otrzymana w ten sposób liste mozna filtrowac (na przyklad nie wyswietlac oprogramowania zawierajacego w swojej nazwie slowo "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
Skladnia polecenia Where-Object wymaga nieco wprawy, ale znajac operatory like i notlike mozna dosc prosto zmodyfikowac na wlasne potrzeby powyzszy przyklad. Mozna oczywiscie zamiast filtrowac po nazwie uzyc wlasciwosci Vendor, która pokazuje aplikacje Microsoftu nawet, jezeli ich nazwa nie zawiera bezposrednio tej informacji.
Dla administratora te pare linijek na ekranie to rzecz cenna, ale co z szefostwem?Sa to zwykle ludzie nadzwyczaj odporni na piekno PowerShella... Dla nich istnieja polecenia ConvertTo-Html. Wygenerowana na ekranie tabelka moze byc w HTMLu, dzieki czemu mozna ja wkleic do maila albo pokazac komus nie-informatycznemu. Uzycie jest bardzo proste: wynik wygenerowany przez poprzedni przyklad nalezy przekazac (uzywajac | jak to w PowerShell) do wspomnianego powyzej ConvertTo-HTML.
Get-WMIObject –ComputerName (Get-Content c:\test\machines.txt) Win32_Product | Where-Object {$_.Caption –notlike '*Microsoft*'} | Select-Object Caption, InstallDate | ConvertTo-Html
Dziala? Dziala… tylko wynik pojawia sie na ekranie. PowerShell tak wlasnie robi, jezeli administrator jasno nie powie, co ma sie z wynikiem stac. Wiec 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 powstal, tabelka sie otwiera w przegladarce, ale jeszcze moze razic niektórych estetów. Dlatego, warto zrobic sobie zmienna $naglowek zawierajaca pare 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 nalezy ani troche ufac moim sugestiom estetycznym i lepiej spróbowac z wlasnymi ulubionymi kolorami.
Teraz wystarczy powiedziec, ze polecenie generujace HTML ma uzyc naszego nagló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 inwentaryzacja oprogramowania dla szefa zrobiony w pare minut. Jezeli szef lubi Excela i chce sam sobie poprzestawiac co i jak wyswietli sie na ekranie, administrator moze zamiast ConvertTo-Html uzyc ConvertTo-CSV i wynikowy plik wczytac prosto do arkusza.
Na koncu mialo byc o klasach WMI.
Otóz nawet najdluzszy wpis na blogu nie ujmie tego, co rzetelnie opisane jest na stronach MSDN.
Zeby wymienic na szybko to, co moze przydac sie podczas inwentaryzacji, wspomniec nalezy:
- Win32_BaseBoard – dla plyt glównych
- Win32_Battery – dla baterii w laptopach
- Win32_BIOS – dla BIOSów
- Win32_CacheMemory – dla pamieci podrecznej
- Win32_CDROMDRIVE – dla napedó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 kosci pamieci
- Win32_Printer – dla drukarek
- Win32_Process – dla aktywnych procesów
- Win32_Processor – dla procesorów
- Win32_Share – dla udzialów sieciowych
I wiele, wiele innych czasem bardzo potrzebnych a czasem traktowanych wylacznie jako ciekawostka. Ale administrator, który wie, z czego moze skorzystac a do tego ma narzedzia pozwalajace na odpytywanie zdalnych komputerów i ladna prezentacje wyników – moze dosc swobodnie wyciagac od swoich systemów te informacje, które mu sa w danym momencie potrzebne.
Warto tez siegnac po PowerShell Quick Reference po polsku. Dwustronicowa sciagawka pozwoli wyjsc poza Copy&Paste gotowych polecen i podpowie czasem jak zrobic polecenie PowerShell jeszcze lepiej dostosowane do konkretnych potrzeb.
Autor: Grzegorz Tworek [MVP]
Comments
Anonymous
January 01, 2003
@kcpr: spróbuj wyłapać rozbieżności i może trafimy na jakiś ślad... skrypt zwraca to, co wie WMI. Lista w PaF pochodzi prosto z rejestru. @Amandi: spojrzyj na wynikowy HTML z -head i bez -head. Zasadniczo, to co jest po -head (u mnie zmienna $naglowek) trafia do nagłówka HTML i tu konkretnie jest to definicja stylów, z których później korzysta tabelka.Anonymous
January 01, 2003
Istnieją setki gotowych rozwiązań i tysiące stron z dyskusjami, które jest lepsze a które gorsze. Ale nawet najlepsze narzędzie to zupełnie nie ten sam poziom satysfakcji, co samodzielnie wystrugany skrypt. :)Anonymous
January 01, 2003
Co do tego Spiceworks, to to cudo chyba nie wspiera x64, w przeciwieństwie do PS. :) Grzegorz a mógłbyś trochę więcej o tym nagłówku (–head $naglowek), bo szczerze, to nie "nadążam" . Gdzie to można wstawić (?), sformatować (?) czy co innego... ;)Anonymous
January 01, 2003
hm... :) Przyjrzę się temu dokładniej.Anonymous
January 01, 2003
Przyjrzałem się i odpowiedź dotyczącą inwentaryzacji zainstalowanego oprogramowania znalazłem całkiem blisko. U Ziemka: http://ziembor.pl/post/Ku-pamieci-jak-dodac-do-WMI-wlasna-klase.aspxAnonymous
December 06, 2009
Istnieje tez gotowe rozwiazanie www.spiceworks.com polecam:)Anonymous
December 06, 2009
Wszystko fajnie. Tylko, że zwrócona przez skrypt lista nie bardzo zgadza się z tym co mam w Programs and Features. Dużo pozycji jest na liście ze skryptu, a nie ma ich w PaF i na odwrót. Oczywiście w moim przypadku usunąłem filtr dotyczący aplikacji z Microsoft w nazwie. Co może być powodem tych różnic?Anonymous
December 09, 2009
Różnic jest tak dużo, że żeby wyłapać wszystkie rozbieżności musiałbym chyba po prostu wkleić tu obie listy z których każda ma około 60 pozycji. Największą rozbieżność widać przy nowym Office 2010 Beta. W PaF jest to jedna pozycja, Powershell zwraca... 29. :D Większość z nich to MUI do każdej oddzielnej aplikacji z pakietu. Co ciekawe są też w wersji 2007, której nigdy nie miałem zainstalowanej. Co do reszty to wygląda to zupełnie losowo. Np. 7-Zip, Opera, Safari, FoxitReader są na obu listach, ale już VLC, Songbird, Pidgin, NetBeans czy Firefox są tylko w PaF