Miesięcznik informatyków i menedżerów IT sektora publicznego

Bartosz Bielawski

Zarządzanie serwerami Windows

PowerShell powstał po to, by zarządzanie rozwiązaniami serwerowymi Microsoftu oddzielić od narzędzi stworzonych dla stacji roboczych – myszy i interfejsu graficznego. Dziś można zarządzać Windowsem, korzystając praktycznie tylko z tego środowiska.

Mówiąc o PowerShellu, nie powinniśmy się ograniczać li tylko do dwóch elementów, z którymi kojarzony jest najczęściej: konsoli i języka skryptowego. Są one oczywiście integralną i istotną częścią całości, ale skupiając się na nich, zatrzymujemy się na PowerShellu w wersji pierwszej. Wersja druga środowiska przyniosła PowerShell remoting, dzięki któremu zyskaliśmy platformę do uruchamiania automatyzacji wszędzie, w niemal niezmienny sposób. Pojawił się też prosty mechanizm rozbudowy w postaci modułów. Wersja trzecia, opublikowana wraz z Windows Server 2012, rozszerzyła możliwości o PowerShell workflow, dzięki któremu możemy zadbać o niezawodność naszego kodu. Pracę, niezależnie od zewnętrznych elementów, możemy podjąć w punkcie, w którym została ona przerwana, i nawet ponowne uruchomienie komputera przestaje stanowić problem. Windows Server 2012 R2 był pierwszym systemem, w którym pojawił się komplet rozwiązań, jaki zamierzali zrealizować twórcy PowerShella. Brakującym ogniwem, który dodano w czwartej odsłonie języka, był PowerShell DSC – platforma, którą udoskonalono w wersji piątej PowerShella, dostępnej w Windows Server 2016.

Drugim, istotnym elementem układanki było odzwierciedlenie czynności możliwych do wykonania w systemie w postaci poleceń. Większość braków dawało się obejść różnymi sposobami, by jednak platforma spełniała pokładane w niej oczekiwania, konieczne było stworzenie narzędzi natywnych. Największy w tym zakresie krok został wykonany w Windows Server 2012.

Zarządzanie Server Core

Pierwsza wersja Server Core pojawiła się wraz z Windows Ser­ver 2008. Ciężko uznać to za udany start: bez możliwości zainstalowania PowerShella trudno zarządzać serwerem pozbawionym interfejsu graficznego. Sytuacja poprawiła się nieco wraz z pojawieniem się Windows Server 2008 R2. Po zainstalowaniu PowerShella i włączeniu PowerShell remoting uzyskiwaliśmy serwer, którym można było zarządzać zdalnie. Był jednak pewien problem: decyzja o wyborze edycji była nieodwołalna. Nie można było przejść od Server Core do pełnej wersji, więc jeśli instalator narzędzia niezbędnego do poprawnego działania naszego serwera przyjmował założenie, że może w trakcie instalacji korzystać z elementów usuniętych w Server Core, to często okazywało się, że serwer trzeba budować od nowa.
Windows Server 2012 zmienił również i to: przełączanie się pomiędzy poszczególnymi wersjami wymaga jedynie restartu serwera. Dodatkowo Server Core stał się opcją domyślną, a nazewnictwo wersji alternatywnej przestawało dawać złudne wrażenie, że instalując wersję Core, coś tracimy: zamiast „wersji pełnej” serwera mamy więc „serwer z GUI”. Jak zarządzać Windows Server 2012 R2 jedynie za pomocą PowerShella? Konfigurując serwer, na ogół zaczynamy od ustawień sieci. Potrzebujemy skonfigurować interfejsy sieciowe, dodać trasy i domyślną bramę, listę serwerów DNS, ustawić wyjątki na ścianie ogniowej. Każdą z tych czynności możemy wykonać w PowerShellu:

# Konfigurujemy IP
$ip = @{
IPAddress = '192.168.200.200'
DefaultGateway = '192.168.200.1'
PrefixLength = 24
}
Get-NetIPInterface Ethernet -AddressFamily IPv4 |
Set-NetIPInterface -Dhcp Disabled -PassThru |
New-NetIPAddress @ip
# Dodajemy domyślny DNS
Set-DnsClientServerAddress -InterfaceAlias Ethernet `
-ServerAddresses 192.168.200.1
# Umożliwiamy korzystanie z RDP
Enable-NetFirewallRule -Name RemoteDesktop-UserMode-In-TCP
$rdpRegistry = @{
Path = 'HKLM:\System\CurrentControlSet\Control\Terminal Server'
Name = 'fDenyTSConnections'
Value = 0
PropertyType = 'Dword'
}
New-ItemProperty @rdpRegistry -Force

Role i funkcje możemy dodawać za pomocą PowerShella od dawna. Interesujące jest to, że od wersji Windows Server 2012 możemy usuwać je znacznie skuteczniej: oprócz usunięcia usługi z systemu możemy dodatkowo usunąć ją z dysku. W przypadku wersji Core od samego początku nie ma części elementów. Możemy pójść krok dalej. Dla przykładu: jeśli zamierzamy stworzyć farmę serwerów IIS opartych na Server Core, możemy swobodnie usunąć binaria związane z Active Directory z tych komputerów:

Get-WindowsFeature -Name AD* | Remove-WindowsFeature -Remove

Niestety, w Windows Server 2016 nie mamy już takiej możliwości – decyzję o typie instalacji podjąć musimy, zanim rozpoczniemy instalację systemu operacyjnego.
Wiele spośród dodanych w Windows Server 2012, 2012 R2, 2016 i 2019 poleceń to komendy oparte na modułach pisanych w formacie CDXML, będące w rzeczywistości odwołaniami do WMI opakowanymi i prezentowanymi w sposób łudzący przypominający cmdlety. Dwie cechy, które pozwalają określić, czy istotnie mamy do czynienia z takimi poleceniami, to typ (wszystkie prezentowane są jako funkcje) i obecność parametru CimSession (dzięki któremu polecenia te możemy uruchamiać zdalnie, bez korzystania z sesji PowerShell remoting). O jak wielkiej liczbie poleceń mówimy, łatwo jest się przekonać, importując moduły systemowe i sprawdzając te dwie właściwości. Na stacji roboczej z zainstalowanym Windows 10 i odpowiadającym tej wersji systemu pakietem RSAT jest takich poleceń ponad tysiąc:

Get-Module -ListAvailable | Where-Object Path -Like `
"$PSHOME\*" | Import-Module
Get-Command -CommandType Function -ParameterName CimSession |
Measure-Object | ForEach-Object Count
1333

Jeśli więc zamierzamy przeprowadzić za ich pomocą kilka operacji i jednocześnie mieć pewność, że wykonamy je na wybranym serwerze (czy nawet grupie serwerów), wystarczy odpowiednio skonfigurować sesję CIM i wybrać ją jako domyślną wartość parametru CimSession:

$nowy = New-CimSession -ComputerName WinITPro -Credential `
WinITPro\administrator
$PSDefaultParameterValues.'*:CimSession' = $nowy

Jeśli instalowany serwer zwirtualizujemy, to może się zdarzyć, że w trakcie instalacji czy nawet już w trakcie „życia” serwera zechcemy dodać dodatkowe dyski (np. dysk z danymi). Odpowiednie polecenie dodające dysk będzie się różnić w zależności od wykorzystywanego hypervisora, dla przykładu składnia w Hyper-V:

New-VHD -Path E:\VMs\VHDx\WinITPro\Data.vhdx -SizeBytes 20GB `
-Dynamic
Add-VMHardDiskDrive -Path E:\VMs\VHDx\WinITPro\Data.vhdx `
-VMName WinITPro

Dodanie dysku nie sprawi jednak, że stanie się on od razu widoczny dla systemu. Aby przygotować dysk do pracy, skorzystamy z poleceń w module Storage, z wykorzystaniem uprzednio przygotowanej i ustawionej jako domyślna sesji CIM:

$dodany = Get-Disk | Where-Object OperationalStatus -EQ Offline
Initialize-Disk -UniqueId $dodany.UniqueId
$partycja = $dodany | New-Partition -UseMaximumSize `
-AssignDriveLetter
$partycja| Get-Volume |
Format-Volume -FileSystem NTFS -NewFileSystemLabel Data `
-Confirm:$false

Co jednak począć, gdy zamiast dodać dysk, zamierzamy go powiększyć? Tu różnica między wirtualizatorami może być większa. Z doświadczenia: po powiększeniu dysku przy wykorzystaniu hypervisora firmy VMware musimy odświeżyć najpierw informację o dostępnych dyskach. W interfejsie graficznym wystarczyłoby wcisnąć klawisz [F5] w Menedżerze dysków. W przypadku PowerShella skorzystamy z polecenia Update-Disk. Następnie musimy ustalić, jak duża może być nasza powiększona partycja, a następnie rozszerzymy ją do maksymalnego dostępnego rozmiaru:

Resize-VHD -Path E:\VMs\VHDx\WinITPro\Data.vhdx -SizeBytes 40GB
$wspolne = @{
DiskNumber = $dodany.Number
PartitionNumber = $partycja.PartitionNumber
}
Update-Disk -UniqueId $dodany.UniqueId
$rozmiar = Get-PartitionSupportedSize @wspolne
Resize-Partition @wspolne -Size $rozmiar.SizeMax

Poza większymi zmianami, takimi jak dodanie czy poszerzenie dysku, na serwerach plików występuje często konieczność wykonania czynności drobniejszych. Gdy ktoś zablokuje plik, możemy plik ten zamknąć lub przynajmniej ustalić, kto go blokuje:

Get-SmbOpenFile | Where-Object Path -Match Zablokowany |
Format-Table -AutoSize ClientComputerName, ClientUserName
ClientComputerName ClientUserName
------------------ --------------
192.168.200.103 bielawscy\Administrator

Często może się też zdarzyć, że dostaniemy prośbę o nadanie uprawnienia do folderu wybranej grupie użytkowników. Przyjmując, że chcemy trzymać się przy tym zasady AGDLP (account, global, domain local, permission), musimy przede wszystkim uzyskać informację o tym, gdzie należy dodać tę grupę, by nadać jej odpowiednie uprawnienia.

[...]

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.1 Biblia”.

Pełna treść artykułu jest dostępna w papierowym wydaniu pisma. Zapraszamy do składania zamówień na prenumeratę i numery archiwalne.
 
 

Polecamy

Biblioteka Informacja Publiczna

Specjalistyczne publikacje książkowe dla pracowników administracji publicznej

więcej