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



23.11.2017

Z IEEE 802.3bz

Przełączniki Netgear
21.11.2017

4K z USB-C

EIZO FlexScan EV2785
16.11.2017

Wielofunkcyjne MFP

Canon imageRUNNER ADVANCE C256i, C356i oraz C356P
14.11.2017

Fabryka Przyszłości w drodze...

W dniach 25 i 26 października we Wrocławiu odbyła się czwarta edycja konferencji...
14.11.2017

Pamięć definiowana programowo

Red Hat Container-Native Storage 3.6
09.11.2017

Zgodnie z rodo

Snow Software GDPR Risk Assessment
07.11.2017

Bezpieczna stacja robocza

F-Secure Protection Service for Business (PSB)
03.11.2017

III Forum Bezpieczeństwa...

21 listopada 2017 r. w PSE w Konstancinie-Jeziornie odbędzie się III Forum Bezpieczeństwa...
27.10.2017

Zasilanie gwarantowane

Schneider Electric Galaxy VX

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"