PowerShell, WMI i CIM do zaawansowanej automatyzacji w systemach Windows

Informatec Digital » Zasoby » PowerShell, WMI i CIM do zaawansowanej automatyzacji w systemach Windows

Jeśli pracujesz jako administrator systemów Windows, prędzej czy później natkniesz się na problemy z PowerShell, WMI i zaawansowana automatyzacjaNie chodzi tylko o to, żeby wiedzieć, jak uruchomić cztery polecenia: zarządzając dziesiątkami lub setkami serwerów, potrzebujesz poważnego, ustrukturyzowanego i bezpiecznego podejścia do gromadzenia informacji, stosowania zmian i powtarzania zadań, nie popadając w szaleństwo... ani niczego nie psując.

W poniższych wierszach spokojnie, ale dokładnie przyjrzymy się, jak wykorzystać Zdalna komunikacja WMI, CIM i PowerShell automatyzować wszystko, od prostych zapytań po złożone scenariusze infrastrukturalne. Zobaczymy również, jak to wszystko współgra z modułami, zadaniami w tle, platformą Azure, Microsoft 365 i niektórymi zaawansowanymi funkcjami, które znacząco wpływają na codzienną pracę administratora systemów.

Ulepszenia programu PowerShell i przegląd zaawansowanej automatyzacji

Program Windows PowerShell rozwinął się w ogromnym stopniu Już w najwcześniejszych wersjach, a w dużej mierze rozwój ten miał miejsce w systemie Windows Server 2012, w którym ulepszono komunikację zdalną, rozszerzono liczbę dostępnych poleceń cmdlet i ułatwiono wykonywanie takich czynności, jak debugowanie, zadania w tle i ograniczone punkty połączeń, co pozwoliło na zwiększenie bezpieczeństwa.

Jedną z kluczowych idei tego środowiska jest to, że administratorzy mogą Twórz zachowania przypominające polecenia cmdlet bez dogłębnego programowania, opierając się na zaawansowanych funkcjach, moduły wielokrotnego użytku oraz bardzo kompleksowy system pomocy. Oznacza to, że zamiast polegać na rozproszonych narzędziach graficznych, można zbudować spójny zestaw skryptów i modułów, które automatyzują procesy zarządzania serwerami, sieciami, Active Directory, Azure lub Microsoft 365.

Na gruncie zaawansowana automatyka Na uwagę zasługują również takie funkcje, jak zadania umożliwiające asynchroniczne uruchamianie zadań, przepływy pracy, administracja oparta na konfiguracji za pomocą PowerShell DSC oraz opcje zabezpieczeń, takie jak JEA (Just Enough Administration) lub PowerShell Web Access, które umożliwiają szczegółową kontrolę nad tym, co każda osoba może robić i skąd.

Cały ten ekosystem szczególnie dobrze pasuje do WMI i CIM, ponieważ informacje zarządcze udostępniane przez system operacyjny (sprzęt, usługi, procesy(konfiguracja sieci, zainstalowane oprogramowanie itp.) staje się zbiorem obiektów, które można wyszukiwać, filtrować i modyfikować za pomocą poleceń programu PowerShell przeznaczonych do masowej automatyzacji.

WMI i CIM: kluczowe koncepcje i praktyczne różnice

Instrumentacja zarządzania systemem Windows, lepiej znana jako WMI to technologia niezależna od programu PowerShell. Jest on częścią systemu Windows od lat i udostępnia repozytorium informacji administracyjnych o systemie operacyjnym, sprzęcie i wielu aplikacjach. Nie jest zależny od programu PowerShell, ale program PowerShell w dużym stopniu wykorzystuje go do automatyzacji zadań.

Naturalnym następcą WMI w ekosystemie PowerShell jest Polecenia cmdlet CIM (Common Information Model)Tego typu polecenia cmdlet, wprowadzone w programie PowerShell 3.0, są zgrupowane w module CimCmdlets i obejmują polecenia takie jak Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance i Remove-CimInstance.

W starszych wersjach programu Windows PowerShell, takich jak wersja 5.1 w systemie Windows 10 lub Windows 11, nadal można znaleźć klasyczne polecenia cmdlet WMI (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Te polecenia cmdlet są jednak przestarzałe i nie są już dostępne w programie PowerShell 6 i nowszych wersjach, dlatego są przydatne jedynie do konserwacji starszych skryptów lub przeglądania starego kodu.

Nie jest sprzecznością, gdy ktoś mówi o „wykonywaniu zapytań do WMI za pomocą poleceń cmdlet CIM”: Polecenia cmdlet CIM nadal uzyskują dostęp do informacji WMIRobią to jednak za pomocą nowocześniejszych protokołów, takich jak WSMan, i bardziej spójnego API. Ze względów praktycznych, w przypadku nowych projektów należy skupić się na CIM i rozważyć użycie poleceń cmdlet WMI tylko wtedy, gdy zachodzi potrzeba migracji lub zrozumienia starszych skryptów.

Tradycyjnie wielu administratorów używało języka VBScript z językiem zapytań WQL do wykonywania zapytań do WMI, na przykład poprzez łączenie się z przestrzenią nazw korzeń\CIMV2 i klas zapytań, takich jak Win32_BIOS. To samo zapytanie WQL można dziś wykorzystać ponownie za pomocą polecenia Get-CimInstance, przekazując parametr -Query, co znacznie upraszcza przejście z VBScript do PowerShell bez konieczności przepisywania logiki od podstaw.

Praktyczne wykorzystanie Get-CimInstance i efektywne zapytania

W codziennej pracy najbardziej naturalnym sposobem zapytania WMI za pomocą programu PowerShell jest użycie Pobierz-CimInstance z parametrem -ClassNameZamiast pisać kompletne zapytania WQL, możesz użyć polecenia Get-CimInstance -ClassName Win32_BIOS, aby uzyskać informacje o systemie BIOS. Zwróci ono obiekt z właściwościami takimi jak producent, nazwa, numer seryjny lub wersja SMBIOSBIOS.

Ponieważ wszystko w PowerShellu to obiekty, jest to bardzo proste Filtruj i wybieraj tylko to, czego potrzebujeszJeśli interesuje Cię tylko numer seryjny, możesz przekazać wynik do `Select-Object -Property SerialNumber` lub użyć `Select-Object -ExpandProperty SerialNumber`, aby wygenerować prosty ciąg zamiast obiektu z właściwością. Inną powszechną opcją jest użycie składni z kropką (`Get-CimInstance ...`).SerialNumber`, aby uzyskać bezpośredni dostęp do wartości.

Warto zauważyć, że domyślnie Zapytania WMI zwracają więcej właściwości, niż faktycznie wykorzystaszNa komputerze lokalnym zazwyczaj nie powoduje to żadnych problemów, ale gdy zaczynasz odpytywać wiele komputerów zdalnych, przekłada się to na dodatkowy czas przetwarzania i niepotrzebny ruch sieciowy. Właśnie tutaj pojawia się parametr `-Property` polecenia `Get-CimInstance`, który pozwala ograniczyć, które właściwości są pobierane ze źródła.

Określając na przykład parametr -Property SerialNumber, zmniejszasz ilość przesyłanych informacji, dzięki czemu zapytanie szybciej i wydajniej, zwłaszcza na dużą skalęTo podejście „zamawiam tylko to, czego potrzebuję” jest kluczowe przy projektowaniu skryptów inwentaryzacyjnych lub audytowych, które działają na dziesiątkach lub setkach maszyn.

Podsumowując, Get-CimInstance oferuje bardzo mocny balans pomiędzy prostota (jeden wiersz poleceń) i elastycznośćNiezależnie od tego, czy pracujesz z konkretnymi klasami, starszymi zapytaniami WQL czy konkretnymi właściwościami, które chcesz zoptymalizować pod kątem pobierania.

Zdalne konsultacje z CIM, sesjami i protokołami WSMan/DCOM

Gdy oddalasz się od lokalnego zespołu i zaczynasz przeszukiwać zdalne maszyny, w grę wchodzi kilka czynników: uprawnienia, protokół komunikacyjny i wydajnośćMimo że wiele osób postrzega PowerShell jako coś „niebezpiecznego”, prawda jest taka, że ​​nie daje on dodatkowych uprawnień: masz dokładnie takie same uprawnienia, jak w przypadku interfejsu graficznego lub dowolnego innego narzędzia, ani więcej, ani mniej.

Jeżeli spróbujesz uruchomić polecenie Get-CimInstance -ComputerName Server -ClassName Win32_BIOS nie mając wystarczających uprawnień na tym komputerze, Wyświetli się błąd „Dostęp zabroniony”.Nie chodzi o to, że PowerShell zawodzi; po prostu użytkownik, z którego konta uruchamiasz sesję, nie ma uprawnień dostępu do tych informacji w WMI. Możesz oczywiście otworzyć konsolę jako administrator domeny, ale oznacza to, że każde polecenie zostanie wykonane z tymi uprawnieniami, co w wielu środowiskach stanowi niepotrzebne ryzyko.

Zaleca się stosowanie zasady minimalne uprawnienia i podnoś je tylko wtedy, gdy jest to konieczneW poleceniach cmdlet obsługujących parametr -Credential można określić alternatywne dane uwierzytelniające tylko dla danego polecenia. Polecenie Get-CimInstance nie akceptuje jednak bezpośrednio parametru -Credential i właśnie tutaj CimSessions wkraczają jako eleganckie rozwiązanie.

CimSession to trwałe połączenie ze zdalnym komputerem, które można utworzyć za pomocą New-CimSession, przekazując nazwę komputera i dane uwierzytelniające (na przykład New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Ta sesja jest przechowywana w zmiennej, takiej jak $CimSession, a następnie jest ponownie używany za pomocą Get-CimInstance korzystając z parametru -CimSession zamiast -ComputerName, co umożliwia skupienie wielu zapytań w jednym połączeniu.

Oprócz problemu z poświadczeniami, Get-CimInstance używa domyślnego Protokół WSMan (oparty na WinRM)Oznacza to, że komputer zdalny musi mieć stos WSMan w wersji 3.0 lub nowszej, co jest typowe dla programu PowerShell 3.0 i nowszych. Aby skorzystać z tej metody połączenia, możesz sprawdzić wersję stosu WSMan na komputerze za pomocą polecenia `Test-WSMan -ComputerName RemoteComputer` i upewnić się, że wartość „Stack” wynosi 3.0 lub nowszą.

Sesje CIM z DCOM i wsteczną kompatybilnością

Starsze polecenia cmdlet WMI oparte na poleceniu Get-WmiObject polegają na Protokół DCOM, który jest nadal kompatybilny ze starszymi wersjami systemu WindowsProblem polega na tym, że w nowocześniejszych systemach zapora sieciowa zazwyczaj domyślnie blokuje protokół DCOM i aby z niego korzystać, trzeba otworzyć określone porty, co może być sprzeczne z polityką bezpieczeństwa organizacji.

Polecenia cmdlet CIM oferują potężne rozwiązanie pośrednie: możesz tworzyć opcje sesji za pomocą New-CimSessionOption -Protocol DcomMożna je zapisać w zmiennej (na przykład $DCOM), a następnie połączyć za pomocą polecenia New-CimSession, aby wygenerować sesję CimSession korzystającą z DCOM zamiast WSMan. Pozwala to na łączenie się z bardzo starymi serwerami, nawet tymi sprzed systemu Windows Server 2000, na których nie ma nawet zainstalowanego programu PowerShell.

Zazwyczaj wygodnie jest przechowywać dane uwierzytelniające administratora domeny lub konta z podwyższonymi uprawnieniami w zmiennej (na przykład $Cred = Pobierz-poświadczeniaaby uniknąć konieczności wpisywania ich za każdym razem. Następnie, za pomocą polecenia takiego jak New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, można uruchomić sesję CimSession przez DCOM na starym serwerze, który nie obsługuje WSMan, ale ma WMI.

Z punktu widzenia scenarzysty, największą zaletą jest to, że Wynik polecenia Get-CimInstance nie zmienia się w zależności od protokołuOtrzymujesz te same obiekty i właściwości niezależnie od tego, czy używasz WSMan, czy DCOM. To znacznie upraszcza logikę, ponieważ możesz hermetyzować wykrywanie odpowiedniego protokołu w funkcji, a reszta kodu zawsze działa transparentnie z CimSessions.

W rzeczywistości dość często tworzy się funkcje niestandardowe, które testują WSMan za pomocą Test-WSMan i, jeśli jest niedostępny, automatycznie przechodzą do DCOM za pomocą New-CimSessionOption. W ten sposób można Standaryzacja tworzenia sesji CimSession w środowiskach mieszanych z nowoczesnymi i starszymi serwerami, bez konieczności powielania logiki połączeń we wszystkich skryptach.

Zarządzanie, tworzenie list i czyszczenie sesji CimSessions

Gdy zaczniesz intensywnie korzystać z CimSessions, ważne jest, aby to monitorować, aby uniknąć gromadzenia niepotrzebnych połączeń. Get-CimSession umożliwia wyświetlenie listy wszystkich otwartych sesji, zobacz, do którego urządzenia są skierowane i sprawdź, jakiego protokołu używają (WSMAN lub DCOM), co jest bardzo przydatne przy diagnozowaniu problemów z łącznością lub uwierzytelnianiem.

Można również pobrać istniejące sesje w zmiennej, na przykład $CimSession = Pobierz-CimSessioni użyć ich w jednym poleceniu Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS, aby wysłać zapytanie do wielu komputerów jednocześnie, łącząc sesje WSMan i DCOM w tej samej operacji.

Po zapoznaniu się z tymi informacjami najlepiej zamknąć sesje, aby uniknąć niepotrzebnego pozostawiania otwartych zasobów. Pobierz-CimSession | Usuń-CimSession Spowoduje to jednoczesne usunięcie wszystkich aktywnych sesji CimSession z bieżącego profilu. Alternatywnie, można przekazać określone sesje do polecenia cmdlet Remove-CimSession, aby zamknąć tylko niektóre z nich.

Pracując w ten sposób, możesz mieć kontrolowane cykle łączenia i rozłączaniaJest to szczególnie zalecane w przypadku stosowania skryptów w ramach zadań zaplanowanych, podręczników automatyzacji lub procesów ciągłej integracji, które mogą powodować zawieszenie sesji, jeśli nie zaplanowano wyraźnie takiego czyszczenia.

PowerShell jako kompleksowy język automatyzacji

Oprócz WMI i CIM, PowerShell stał się język automatyzacji ogólnego przeznaczenia Wykracza daleko poza typowy skrypt administracyjny systemu Windows. Istnieją książki i całe kursy poświęcone jego zaawansowanym możliwościom, obejmujące wszystko, od instalacji w systemach Linux i Windows, przez tworzenie modułów dystrybuowalnych za pomocą NuGet, po nowoczesne środowiska programistyczne, takie jak Visual Studio Code.

Wspólnym punktem wyjścia jest zrozumienie zaawansowane funkcje programu PowerShellModuły te umożliwiają definiowanie parametrów, walidację, ustrukturyzowane dane wyjściowe i zintegrowaną pomoc niemal na poziomie natywnego polecenia cmdlet. Organizacja kodu w moduły ułatwia współpracę w zespołach operacyjnych, ponieważ moduły te można wersjonować i publikować w wewnętrznych lub publicznych repozytoriach NuGet.

Współpraca jest również kluczowa obiekty i klasy niestandardoweOtwiera to drzwi do znacznie bogatszych modeli danych niż typowe skrypty liniowe. Pozwala to na hermetyzację logiki biznesowej, ponowne wykorzystanie struktur i projektowanie wewnętrznych interfejsów API dla własnego zespołu zarządzającego – a wszystko to dzięki silnikowi PowerShell.

W dziedzinie zaawansowanej automatyzacji istotną rolę odgrywają: Zadania i przepływy pracy w tleTe funkcje umożliwiają zarządzanie zadaniami asynchronicznymi, uruchamianie długotrwałych operacji bez blokowania konsoli oraz organizowanie złożonych sekwencji na wielu maszynach. Idealnie sprawdzają się w przypadku zbiorczych zapytań WMI/CIM i scenariuszy zdalnej administracji, gdzie często konieczne jest oczekiwanie na wdrożenie zmian lub zwrócenie danych przez systemy.

Kolejnym kluczowym komponentem jest PowerShell DSC (Desired State Configuration), który umożliwia zdefiniować pożądaną konfigurację infrastruktury (role, funkcje, usługi, pliki, ustawienia zabezpieczeń…) i wielokrotnie stosować te stany. W połączeniu z informacjami uzyskanymi za pośrednictwem WMI/CIM możesz wykrywać odchylenia, proaktywnie je korygować i utrzymywać spójność środowisk przy mniejszym nakładzie pracy ręcznej.

Zarządzanie lokalne, zdalne i w chmurze za pomocą programu PowerShell

Na poziomie czysto lokalnym program PowerShell udostępnia polecenia cmdlet dla Administracja usługami domenowymi Active DirectoryKonfiguracja sieci i zarządzanie serwerem. W systemie Windows 10 i nowszych wersjach integracja jest jeszcze głębsza, umożliwiając automatyzację wszystkiego, od tworzenia witryn internetowych po zarządzanie obiektami Active Directory i konfigurację karty sieciowej.

Mniej znanym, ale bardzo przydatnym elementem są PSProviders i PSDrivesFunkcje te pozwalają traktować różne lokalizacje pamięci masowej (systemy plików, rejestry, Active Directory itp.) tak, jakby były to dyski nawigowalne. Umożliwia to na przykład tworzenie grup Active Directory, kluczy rejestru lub struktur folderów na komputerach zdalnych przy użyciu tej samej składni, której używa się do nawigacji po dysku twardym.

W zakresie administracji zdalnej PowerShell integruje bardzo wydajny zestaw funkcji połączyć się z jednym lub większą liczbą komputerów i uruchom polecenia w Twoim imieniuMożesz korzystać z trwałych sesji PSSession, zaawansowanych technik zdalnego dostępu, scenariuszy jeden do wielu (do jednoczesnego zarządzania wieloma serwerami) lub scenariuszy jeden do jednego do debugowania konkretnych przypadków. Wszystko to oczywiście z poszanowaniem architektury i modelu bezpieczeństwa zdalnego dostępu.

Chmura odgrywa dziś również fundamentalną rolę. Azure PowerShell i Azure Cloud Shell Możesz zarządzać maszynami wirtualnymi, pamięcią masową i subskrypcjami bezpośrednio z wiersza poleceń. Zainstalowanie modułów Azure PowerShell i zapoznanie się z nimi jest niemal obowiązkowe, jeśli zarządzasz środowiskami hybrydowymi lub w pełni hostowanymi na platformie Azure.

Z drugiej strony PowerShell ugruntował swoją pozycję jako Narzędzie referencyjne do zarządzania usługą Microsoft 365 (Exchange Online, SharePoint Online, Teams, użytkownicy i licencje). Od tworzenia i zarządzania kontami po administrowanie zasobami Exchange Online, w tym grupami, witrynami SharePoint i Microsoft Teams, wszystko można zorganizować za pomocą skryptów, które znacznie redukują ręczną pracę w portalu internetowym.

Skrypty, potoki i najlepsze praktyki robocze

Aby w pełni wykorzystać możliwości zaawansowanej automatyzacji z WMI i CIM, niezbędne jest opanowanie Model potoku programu PowerShellW odróżnieniu od innych powłok, tutaj nie przesyłasz zwykłego tekstu, lecz kompletne obiekty, co pozwala na selekcjonowanie, sortowanie, mierzenie, filtrowanie, wyliczanie i przekształcanie informacji z dużą precyzją.

Nauka pracy z channelingiem polega na jego prawidłowym stosowaniu polecenia cmdlet wyboru i filtrowaniaObejmuje to zrozumienie, jak enumerować złożone obiekty i jak przesyłać dane między poleceniami i skryptami bez utraty informacji. Umiejętności te są wzmacniane przez strukturalne wykorzystanie zmiennych, tablic i tablic skrótów, które działają jak tymczasowe struktury danych, na których można budować bardziej zaawansowaną logikę.

Następnym krokiem jest Skryptowanie jako takie: pakowanie poleceń w skrypty wielokrotnego użytkuDzięki kontroli przepływu (if, for, foreach), importowaniu danych z plików CSV lub innych formatów, obsłudze danych wprowadzanych przez użytkownika, obsłudze błędów i rejestrowaniu zdarzeń można przejść od pojedynczych poleceń do bardziej zaawansowanych narzędzi wewnętrznych.

Rozwiązywanie problemów i obsługa błędów są szczególnie ważne w środowiskach automatyzacji masowej z WMI/CIM, ponieważ awaria sieci, błędnie skonfigurowane uprawnienie lub nieistniejąca klasa Mogą one przerwać proces, jeśli nie będą odpowiednio zarządzane. Dzięki blokom try/catch, konfigurowalnym akcjom na błędy i szczegółowemu rejestrowaniu zdarzeń możesz przewidywać takie sytuacje i lepiej na nie reagować.

Na koniec wszystko co związane z funkcje i moduły zamykają krągPodpisujesz skrypty, aby zapewnić ich integralność, pakujesz funkcje w moduły, dystrybuujesz te moduły w wewnętrznych lub publicznych repozytoriach i tworzysz ekosystem współdzielonych narzędzi w swojej organizacji. W ten sposób każde nowe rozwiązanie w WMI, CIM lub zdalnej obsłudze jest zintegrowane w spójny i łatwy w utrzymaniu pakiet.

Gdy zsumujesz wszystkie powyższe elementy — WMI/CIM, sesje zdalne, skrypty, zadania asynchroniczne, DSC, Azure i Microsoft 365 — otrzymasz środowisko, w którym zaawansowana automatyzacja z programem PowerShell Staje się centralnym punktem administracyjnym. Dzięki solidnym fundamentom najlepszych praktyk, inteligentnemu wykorzystaniu CimSessions (zarówno z WSMan, jak i DCOM) oraz modułowej konstrukcji skryptów, możesz zarządzać heterogenicznymi infrastrukturami spójnie, bezpiecznie i znacznie wydajniej niż polegając wyłącznie na graficznych kreatorach lub odizolowanych narzędziach.

Podobne artykuł:

Zaawansowana automatyzacja w systemie Windows z PowerShell DSC i Ansible