Strona korzysta z plików cookies w celu realizacji usług i zgodnie z Polityką Plików Cookies.



18.04.2018

Dla biznesu

Monitory AOC 6x
13.04.2018

Ochrona sieci przemysłowych

Stormshield SNi40
09.04.2018

Disaster recovery

Veeam Availability Orchestrator
05.04.2018

Pamięci masowe i SDS

IBM Spectrum Storage
27.03.2018

Wydajna podstawa

Asus RS700-E9, Asus WS C621E SAGE
22.03.2018

Seria dla profesjonalistów

Toshiba E-Generation
21.03.2018

Odzyskiwanie plików - nowa...

Zachowanie bezpieczeństwa plików jest dla wielu przedsiębiorców priorytetem. Z myślą o...
19.03.2018

Superszybkie SSD

Samsung SZ985 Z-SSD
15.03.2018

EPYC w serwerach

Dell EMC PowerEdge

Narzędzie RSAT

Data publikacji: 30-10-2017 Autor: Bartosz Bielawski

Administratorzy odpowiedzialni za serwery Windows, wybierając narzędzia, którymi mogą się posługiwać, mają na ogół kilka opcji oraz do pewnego stopnia możliwość wyboru miejsca, gdzie te narzędzia będą uruchamiać. Jednym z tego rodzaju pakietów jest RSAT.

Narzędzia można uruchamiać na serwerze, gdzie działa interesująca nas usługa. Można też skorzystać z serwera pośredniego, na którym wszelkie narzędzia do administracji są zainstalowane, a sam serwer oferuje je wielu użytkownikom jednocześnie, na ogół przy użyciu Terminal Services. Ostatnia opcja to skorzystanie z własnej stacji roboczej, na której również można zainstalować wiele narzędzi administracyjnych. Pakietem oferującym narzędzia zarządzania serwerem jest Remote Server Administration Tools (RSAT). Ma on jednak jedno dość poważne ograniczenie – instalować możemy jedynie narzędzia do serwera „pasującego” do systemu klienckiego zainstalowanego na danym komputerze. Oczywiście, kompatybilność ze starszymi wersjami działa dobrze, ale czasem sytuacja jest odwrotna, gdy jesteśmy zmuszeni zarządzać nowszym systemem, korzystając z końcówki działającej pod kontrolą starszej wersji systemu.

> RÓŻNE PODEJŚCIA

Przyczyną takiego stanu rzeczy jest kilka czynników. Przede wszystkim instalując w organizacji nowy serwer, na ogół poważnie rozważamy użycie możliwie nowej wersji systemu, skutkiem czego w takim środowisku znaleźć można wiele wersji systemów serwerowych. Z drugiej strony zarządzanie stacjami klienckimi jest znacznie uproszczone, gdy są one w pewien sposób ustandaryzowane. Na ogół więc, pomijając okresy pilotażowe, wszyscy pracownicy używają tej samej wersji systemu, a sam proces migracji do nowszej edycji na ogół przeprowadzany jest wg założenia – wszyscy albo nikt. Takie podejście wydłuża ten proces wszędzie tam, gdzie użytkownicy zmuszeni są korzystać z wielu różnych aplikacji i trudno jest ustalić, czy aplikacje te będą działać poprawnie na nowszych wersjach Windows.

Rozwiązanie z serwerem pośrednim oczywiście ma swoje zalety, szczególnie gdy planujemy korzystać z narzędzi graficznych. W przypadku PowerShella jednak sprawa się komplikuje. Tworzenie sesji RDP po to, aby skorzystać z tekstowej konsoli, brzmi fatalnie. O ile przyjemniej jest uruchomić wspomnianą konsolę na stacji roboczej i nawiązywać połączenia z serwerami z tego poziomu! Niestety, moduły do zarządzania systemem Windows są częścią RSAT i oficjalnie nie da się ich zainstalować na starszych wersjach systemów klienckich. Szczególnie w przypadku stacji roboczej wykorzystującej Windows 7 problem ten może być dotkliwy – liczba poleceń dodanych w Windows Server 2012 była tak duża, że niemożność korzystania z nich na stacjach klienckich byłaby bardzo ograniczająca.

> MODUŁY CMDLET DEFINITION XML

Szczęśliwie wiele modułów oferowanych jest jako moduły CDXML (cmdlet definition XML). Jest to klasa modułów, którą dodano w Windows Server 2012 w jednym, bardzo prostym celu – aby umożliwić prostą konwersję klas oferowanych w ramach CIM/WMI do poleceń łudząco przypominających cmdlety PowerShella. Moduły te pozwalają na tworzenie swoistych związków pomiędzy klasami, ich właściwościami (które stają się właściwościami zwracanych obiektów) oraz wybranymi metodami (które przekształcane są w polecenia). W przypadku poleceń pobierających dane nie trzeba nawet określać szczegółów, wystarczy podać: klasę, rzeczownik tworzący nazwę polecenia oraz listę poleceń, które komenda Get ma wspierać. Prosty przykład dla klasy Win32_Service:

<PowerShellMetadata xmlns="http://schemas.microsoft.com/cmdlets-over-objects/2009/11">
<Class ClassName="ROOT/CIMV2/Win32_Service">
<Version>1.0.0.0</Version>
<DefaultNoun>Win32Service</DefaultNoun>
<InstanceCmdlets>
<GetCmdletParameters>
<QueryableProperties>
<Property PropertyName="Name">
<Type PSType="System.String" />
<RegularQuery AllowGlobbing="true" />
</Property>
</QueryableProperties>
</GetCmdletParameters>
</InstanceCmdlets>
</Class>
</PowerShellMetadata>

[...]
 

Autor zawodowo zajmuje się informatyką. Jest Microsoft MVP w dziedzinie PowerShella, blogerem oraz jednym z moderatorów forum dotyczącego skryptów w serwisie TechNet. Autor książki „Windows PowerShell 5.0 Biblia”.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma.

.

Transmisje online zapewnia: StreamOnline

All rights reserved © 2013 Presscom / Miesięcznik "IT Professional"