Jakie są wady i zalety korzystania z usług zdalnych programu Windows PowerShell 2.0?

Skrypciarze odpowiadają na Wasze pytania

Jakie są wady i zalety korzystania z usług zdalnych programu Windows PowerShell 2.0?

(Uwaga: dzisiejszy artykuł z serii „Cześć, Skrypciarze” został napisany przez skrypciarza-gościa — Tome'a Tanasovskiego. Tome jest kierownikiem zespołu inżynierów serwerowych w Nowym Jorku. Jest certyfikowanym trenerem firmy Microsoft, specjalizującym się w technologiach SQL Server, SharePoint i VMWare. Publikuje na forum Windows PowerShell oraz na forum skrypciarzy. Tome prowadzi też blog i jest organizatorem inauguracyjnego spotkania grupy użytkowników programu Windows PowerShell z Nowego Jorku.

Tome jest także autorem wczorajszego artykułu o korzystaniu z usług zdalnych podczas obsługi programu Office SharePoint przy użyciu programu Windows PowerShell 2.0 i usługi WinRM. Dzięki, Tome!)

----------

Administratorzy systemów muszą radzić sobie z wieloma problemami. Niezależnie, czy chodzi o dobranie odpowiedniego oprogramowania, by rozwiązać problem, czy też o dobranie poziomu kofeiny pozwalającego utrzymać optymalną wydajność podczas zarwanej nocy, trzeba podjąć decyzję, której skutki mogą być dobre lub złe. Czy zdarzyło wam się kiedyś wdrożyć oprogramowanie spełniające wszystkie wasze wymagania, które jednak po trzech miesiącach spowodowało problem — akurat w czasie, kiedy nie można uzyskać pomocy technicznej? Potem, kiedy już uda się z nią skontaktować, okazuje się, że nikt dotąd nie wprowadził takiej ilości danych do tej aplikacji. Czy zdarzyło się wam kupić napój energetyczny o podwyższonej zawartości kofeiny? Jasne, że dobrze zwalcza on senność, ale kiedy dłonie trzęsą się tak bardzo, że trudno trafić w klawisze, okazuje się, że nie było to optymalne wyjście.

Każdemu zdarza się podejmować błędne decyzje, ale w świecie IT tolerancja błędu jest bardzo niewielka. W niektórych branżach każda pomyłka może pociągać za sobą milionowe koszty. Jak zatem ograniczyć ryzyko popełnienia takich błędów? Jak się upewnić, że wszystkie czynniki zostały uwzględnione?

Rzecz jasna, zapisać swoje przemyślenia na często odwiedzanej stronie internetowej, aby cały świat mógł się z nimi zapoznać i poddać je krytyce.

Tak więc zabieram się za omówienie dobrych i złych stron korzystania z usług zdalnych programu Windows PowerShell, co pomoże mi podjąć decyzję, czy standardowo włączać je w swoich serwerach. Czytelnikom, którzy dopiero zaczynają przygodę z usługami zdalnymi, polecam artykuł wprowadzający Eda Wilsona.

Zalety

Łatwość zarządzania

Warto zwrócić uwagę na uruchamianie powłoki na komputerze zdalnym w celu szybkiego uzyskania informacji. Osobiście uważam, że do najważniejszych cech programu Windows PowerShell należą bardzo uniwersalne aplety poleceń Set-Location i Get-ChildItem, których aliasy to znajome dla użytkowników systemu DOS polecenia cd i dir. Dzięki nim nawigowanie w rejestrze z wiersza poleceń stało się tak łatwe, że praktycznie nie używam już do tego programu regedit. Wyobraźmy sobie teraz, że możemy w ten sposób pobierać informacje o wszystkich komputerach, nie ruszając się sprzed biurka. Załóżmy, że chcemy się upewnić, że na określonym komputerze zainstalowano dodatek COM programu Office Outlook. Czy może być coś łatwiejszego?

enter-PSSession wks1

cd HKLM:\SOFTWARE\Microsoft\Office\Outlook\Addins

dir

cd HKCU:\SOFTWARE\Microsoft\Office\Outlook\Addins

dir

Było to co prawda pytanie retoryczne, ale i tak odpowiem: nie ma nic łatwiejszego!

Uruchamianie poleceń, które normalnie można uruchamiać tylko w sposób lokalny

Dla mnie jako administratora SharePoint na pół etatu i użytkownika tego programu na cały etat, był to najważniejszy powód, by rozważyć włączenie usług zdalnych. Podobne rozwiązania można wprawdzie zastosować i w innych programach, ale SharePoint szczególnie się do tego nadaje. Jednym z ograniczeń modelu obiektów SharePoint jest to, że kod musi działać lokalnie w interfejsie internetowym SharePoint.

Oto przykładowy skrypt, który wczytuje model obiektów, łączy się z witryną SharePoint i dodaje nowy wpis do głównego kalendarza:

$script = {

    [System.Reflection.Assembly]::LoadWithPartialName("Microsoft.Sharepoint")

    $site = New-Object Microsoft.SharePoint.SPSite("http://server1")

    $web = $site.OpenWeb("")

    $list = $web.Lists["Calendar"]

    $item = $list.Items.Add()

    $item["Title"] = "Listen to the Powerscripting Podcast"

    $item["Start Time"] = "Thursday, February 04, 2010 9:30:00 PM"

    $item["Location"] = "Live online!"

    $item.Update()

}

Invoke-Command -ComputerName server1 -scriptblock $script -Authentication Credssp

Poniżej widać element dodany do kalendarza SharePoint.

Prawdopodobny wymóg przyszłych pakietów zarządzania

Niezwykle ważne jest to, że Exchange 2010 wymaga usług zdalnych (j.ang.) do korzystania z pakietu zarządzania. Załadowanie powłoki Exchange na komputerze automatycznie udostępnia powłokę zdalną na serwerze Exchange. Czy tak wygląda przyszłość pakietów zarządzania? Wprawdzie jak dotąd nie słyszałem nic podobnego na temat programów innych niż Exchange, jednak wydaje się, że może to być preferowana metoda używania programu Windows PowerShell na wszystkich przyszłych produktach serwerowych.

Uruchamianie skryptu na wielu serwerach przy użyciu jednego apletu polecenia Invoke-Command

Takie rozwiązanie ma niezwykły potencjał, gdyż teoretycznie pozwala znacznie uprościć wykonywanie zadań związanych ze skryptami.

Niektóre aplety poleceń mają własne interfejsy, umożliwiające pobieranie informacji ze zdalnych komputerów. Weźmy np. aplet polecenia Get-WMIObject:

Get-WMIObject Win32_Service -Computername server1

Jest to znakomity interfejs umożliwiający uruchamianie poleceń na zdalnych komputerach. Wyobraźmy sobie jednak bardziej złożony proces, sprawdzający, czy istnieje dana usługa, zatrzymujący ją i odinstalowujący tę usługę. Napisanie takiego skryptu dla zdalnego komputera jest bardzo trudne, a być może nawet niemożliwe. Dzięki usługom zdalnym można napisać skrypt wykonujący takie zadanie na kompuerze lokalnym, a następnie uruchomić go na wielu komputerach, używając apletu polecenia Invoke-Command:

Invoke-Command -ComputerName ("server1", "server2", "server3") -FilePath .\RemoveService.ps1

Jeśli wiemy, że usługi zdalne są w naszym środowisku dostępne, możemy w ten sposób z minimalnym wysiłkiem uruchamiać skrypty napisane dla komputerów lokalnych na dowolnej liczbie komputerów. Języki skryptów istnieją po to, by umożliwić szybsze rozwiązywanie problemów. Taka strategia dodatkowo nam w tym pomoże.

Importowanie zdalnych modułów na komputer

Po utworzeniu sesji na komputerze zdalnym i wczytaniu odpowiednich modułów lub przystawek, udostępnianych np. przez SQL Server lub Exchange Server, można uruchomić aplet polecenia Import-PSSession, aby dodać te moduły do lokalnej powłoki:

$session = New-PSSession server1

Invoke-Command -session $session -scriptblock {import-module moduletoimport}

Import-PSSession $session

Uruchomienie tego kodu zapewnia dostęp do modułów, które nie są zainstalowane na komputerze lokalnym. Można pójść o krok dalej i użyć apletu polecenia Export-PSSession w celu utworzenia modułu na komputerze lokalnym, który będzie wczytywany z komputera zdalnego.

Wady

Usługi zdalne stanowią furtkę dla ataków

Wobec ogromnych ilości wirusów i złośliwego oprogramowania jest to ważny argument. Jednak właściwie skonfigurowane zapory i poprawnie zaprojektowana sieć z zaufanymi komputerami pozwalają ograniczyć ryzyko. W końcu administratorzy przeważnie dopuszczają podłączanie pulpitu zdalnego, chociaż to również bywa zagrożeniem. Jeśli komputer jest połączony z Internetem (np. w strefie ograniczonego zaufania), należy jednak wziąć ten argument pod uwagę. Osobiście nigdy nie otworzyłbym w swojej zaporze portu przychodzącego, który nie jest absolutnie wymagany.

Usługa WinRM wymaga serwera sieci Web

Prawdziwy problem jest bardzo podobny do poprzedniego. Nie należy uruchamiać niepotrzebnych usług na serwerach. Możemy skonfigurować usługę WinRM w taki sposób, aby działała w ramach IIS, jeśli jest to dla nas wygodniejsze lub IIS już jest uruchomione. Warto zapoznać się z opisem instalacji i konfiguracji (j.ang.) usługi WinRM. Wprawdzie ustawienia domyślne wymuszają szyfrowanie, ale warto poświęcić trochę czasu na uruchomienie SSL. Można też rozważyć zmianę portów domyślnych i zmianę domyślnego prefiksu URL.

Podsumowanie

Nie jestem ekspertem w dziedzinie usługi WinRM, ale na podstawie dokumentacji znam ją wystarczająco dobrze, by stwierdzić, że stwarzane przez nią zagrożenia w poprawnie zaprojektowanej sieci są niewielkie. Częstsze pytanie, z jakim można się spotkać, chcąc wdrożyć usługi zdalne, brzmi: „Co nam to da?”. Mam nadzieję, że lektura niniejszego artykułu dała Wam odpowiednie argumenty. Jednak w żadnym razie nie uważam, by temat został wyczerpany. Warto rozważyć go bardziej dokładnie. Dlatego też zapraszam do tego wątku na forum programu Windows PowerShell (j.ang.), gdzie można przedstawić swoje argumenty i zadać pytania.

Sądzę, że mogę wreszcie przyznać, że dzięki naszkicowanym powyżej argumentom przeforsowałem wdrożenie usług zdalnych w swoim środowisku. Po prostu przedstawiłem opis zalet i wad.

Do początku strony