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



06.12.2018

Niższe moce

UPS Eaton 9SX
03.12.2018

Monitory dla MŚP

AOC E1
29.11.2018

Wykrycie szkodliwego...

Sophos Intercept X Advanced
27.11.2018

Automatyzacja zabezpieczeń

Red Hat Ansible Automation
23.11.2018

Nieograniczona skalowalność

SUSE Enterprise Storage 5.5
20.11.2018

Dwa procesory Threadripper

AMD Ryzen Threadripper 2970WX i 2920X
16.11.2018

Dla biznesu i edukacji

Optoma 330USTN
13.11.2018

Superszybki dysk SSD

Patriot Evolver
09.11.2018

Ograniczenie kosztów

Canon imageRUNNER ADVANCE 525/615/715

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"