WSUS: serwer aktualizacji w Windows Server 2012 (część 2)

To druga część dotycząca serwera WSUS. W pierwszym wpisie przedstawiłem na czym polegają aktualizacje w systemach Windows, oraz jakie są wymagania i jak uruchomić na serwerze Windows 2012 usługę Windows Server Update Services.

Konfiguracja klienta - Group Policy i GPO w Active Directory

W ostatnim wpisie także rozpocząłem stacji klienckich Windows - edycja odpowiednich wpisów Group Policy. Należy zwrócić uwagę, że niektóre opcje są od siebie wzajemnie zależne:

COMPUTER CONFIGURATION -> Administrative Templates -> Windows Componets ->Windows Update

• Do not display "Install Updates and Shut Down" option in Shut Down Windows dialog box, oraz
• Do not adjust default option to 'Install Updates And Shut Down' in Shut Down Windows dialog box

Czasami drażniąca opcja Windowsa, w niektórych środowiskach niewskazana. Włączenie spowoduje, że nie będzie wyświetlana możliwość instalacji aktualizacji w czasie zamykania systemu operacyjnego. Wyłączenie wyświetlania opcji jest też przydatne w konfiguracji domowego komputera. Działa w wersji od SP2 XP w górę.

• Enabling Windows Update Power Management to automatically wake up the system to install scheduled updates

W teorii brzmi ciekawie: "jeżeli system jest skonfigurowany do automatycznych aktualizacji, oraz jest zahibernowany, to uruchom komputer o zadanej godzinie, zainstaluj aktualizacje i ponownie zahibernuj". W uproszczeniu: jak nie ma pracowników, to poza godzinami pracy zrób co do aktualizacji należy. W praktyce może spowodować sporo ciekawych problemów, jak np. włączenie laptopa schowanego w torbie itd. Opcję należy stosować rozsądnie (np. różne GPO dla komputerów przenośnych).

• Configure Automatic Updates

Jedna z najważniejszych opcji. Od tych ustawień zależy, kiedy komputer "poprosi" o nowe aktualizacje, jak to zrobi i jakie będzie "zachowanie" komputera po aktualizacji. Wszystko zależy, dla jakich użytkowników jest kierowana konfiguracja, oraz jak restrykcyje jest środowisko. Najczęściej stosowana jest opcja 2 i 3: [item][2] Powiadom przed pobraniem aktualizacji i ponownie powiadom przed instalacją[/item][item][3] Pobierz aktualizacje i powiadom, kiedy są gotowe do instalcji (opcja domyśłna)[/item][item][4] Automatycznie pobierz aktualizacje i zainstaluj o zadanej godzinie (domyślnie o 3 rano codziennie). UWAGA: jeżeli jest taka potrzeba, AUTOMATYCZNIE zrestartuj komputer.[/item][item][5] Pozwól lokalnym administratorom decydować o aktualizacjach [/item]Jak wspomniałem, jedna z najważniejszych opcji. Od ustawień zależy, jak bardzo będą sfrustrowani użytkownicy np. w przypadku ustawienia opcji numer 4. Nie jest przyjemne, jak po powrocie z obiadu z niewiadomych przyczyn komputer został zresetowany, bo nie było nas przy ekranie, aby anulować reboot.

• Specify intranet Microsoft update service location

Wskazujemy klientowi WSUS, gdzie znajduje się serwer aktualizacji. W tym miejscu najczęściej pojawiają się błędy w konfiguracji - należy podać podać adres w formacie: protokół://adres:PORT, przykładowo: http://KSENIOS:8530

• Automatic Updates detection frequency

Jak "często" komputer ma odpytywać serwer aktualizacji i nowości. W sytuacji, gdy ustawimy na wartość "20", usługa będzie sprawdzać aktualizacje co 16-20h. Z tego też wynika, że dla środowiska testowego warto ustawić na "1".

• Turn on recommended updates via Automatic Updates

Opcja ta "mówi" klientowi, aby pobranie najważniejszych aktualizacji było z serwera Windows Update. Opcja może być przydatna np. dla laptopów i osób, które nie są często podłączone do lokalnej sieci.

• No auto-restart for scheduled Automatic Updates installations

Kolejna opcja z cyklu: "jak nie podpaść użytkownikom: warto dać na "Enable". Użytkownik zostanie ostrzeżony, że należy zrestartować komputer - ale reboot nie nastąpi automatycznie!

• Re-prompt for restart with scheduled installations i Delay Restart for scheduled installations

Kolejna opcja z cyklu: "jak nie dasz Enabled, to pracownicy będą odwracać głowę na twój widok". Poprzednia opcja wymuszała brak automatycznego restartu po instalacji aktualizacji. Problem jednak w tym, że użytkownik średnio co 10 minut będzie otrzymywał przypomnienie: "a może jednak już czas zrestartować komputer?"... "czy zrestartowałeś już komputer?". Bardziej irytujący był tylko spinacz z Office. Dobrze wyliczając czas ponownego monitu można zmotywować do restartu np. pod koniec dnia (np. aktualizacje o 13.30, 240 minut na ponowny pop-up).

Podłączanie klienta

W przypadku klienta podłączonego do domeny, aktualizacja GP nastąpi po około dwóch godzinach od zmian na serwerze AD. Wymuszenie zmian można wystąpić na dwa sposoby:

[item]restart komputera (pewniejsza metoda)[/item][item]z linii poleceń:[/item]

gpupdate /force

Z gpupdate jest ten problem, że nie zawsze poprawnie "podnoszą" się serwisy automatycznej aktualizacji. Warto więc sprawdzić stan usługi "wuauserv".

Można to zrobić z konsoli zarządzającej usługami (services.msc):

Z linii poleceń można za pomocą intepretera (cmd.exe):

Najnowsze "trendy" jednak podpowiadają, aby to zrobić z poziomu PowerShell :-) Posłuży nam do tego cmdlet Get-Service:

Na aktualizacje trzeba zaczekać - wcześniej ustawiliśmy w jakich godzinach / dniach ma nastąpić odpytanie o łatki. Można jednak wymusić to z linii poleceń:

Jest to narzędzie, które w praktyce jest wywoływane przez zaplanowane zadania do "odpytywania" serwera aktualizacji. W celu owego odpytania najlepiej wydać dwa polecenia:

Wynik wuauclt /detectnow... Wszystko zależy od konfiguracji w rejestrze "Configure Automatic Updates" opisanej wcześniej. Kolejna opcja (/reportnow), która przy przyjaznych wiatrach (zależne od stanu WUAgent, raportującego do RWS) "odświeży" swoją obecność w serwerze WSUS. W ostatnim wpisie użyłem "Client Diagnostics Tool": po poprawej konfiguracji od strony klienta wynik diagnostyki wygląda już lepiej:

Zarządzanie komputerami i aktualizacjami w konsoli WSUS.

Załóżmy, że konfiguracja jest poprawna - serwer WSUS jest poprawnie zainstalowany, komputer kliencki wie "gdzie" jest serwer i zadał pierwsze pytanie do serwera WSUS: "hej, jestem Windows 7 64bit, mam Office 2010 i kilka innych, co masz dla mnie?. W przypadku WSUSa należy się czasem uzbroić w cierpliwość, oraz przyzwyczaić się do stosowania przycisku "Refresh" - praktycznie po każdej zmianie, zatwierdzeniu aktualizacji itd.:

Jak widać na zrzucie ekranu, pojawiły się w konsoli dwie pozycje: stacja kliencka i serwer. Zatwierdzanie aktualizacji przebiega przez grupy do której należy dany komputer. Utwórzmy więc grupy: DESKTOPS i SERVERS:

Nic nie stoi na przeskodzie, aby wszystkie komputery należały do kilku grup - mogą także należeć do jednej domyślnej grupy (Unassigned), jednak nie jest to dobrą praktyką, o tym napiszę w dalszej części. Możemy przystąpić do zatwierdzania pierwszy aktualizacji. Podczas instalacji WSUSa zdecydowaliśmy, jakie grupy logiczne będą wyświetlane przy aktualizacjach. Zajrzyjmy do "Critical Updates":

W celu zatwierdzenia pierwszego "rzutu" łatek, należy po zaznaczeniu jednej z nich kliknąć w kolejne, trzymając klawisz Shift. Po dokonaniu pod prawym klawiszem myszy kryje się opcja "Aprove", gdzie można także zdecydować do jakich grup klientów będą kierowane aktualizacje (stacja roboczja jest w grupie DESKTOPS):

W tym momencie zaczyna się dopiero pobieranie odpowiednich plików na dysk serwera - nie jest tak, jak niektórzy twierdzą, że WSUS trzyma "shadow", czy tam inny "sync" całego serwera WindowsUpdate. Można sobie podejrzeć tworzącą się strukturę plików i pojawiające się łatki w repozytorium:

Po zatwierdzeniu i pobraniu aktualizacji, można spróbować ponownie "podpytać" WSUS przez stację kliencką, czyli:

Jak widać na powyższym screenie, aktualizacje są zarządzane przez administratora użytkownik nie ma możliwości pobierać łatek bezpośrednio z internetu (szara opcja).

Dobre rady

Przedstawiona konfiguracja pokazuje tylko podstawy zarządzania WSUSem. Administrowanie automatycznymi aktualizacjami powinno być rozsądne i przemyślane. Przedstawię kilka rad i problemów, z którymi najczęściej się spotykałem.

[item]Brak komunikacji z serwerem WSUS[/item]Podstawą jest sprawdzić, czy "WSUS" dobrze został zainstalowany i jest możliwa z nim komunikacja. Niezbędny jest dostęp do serwera przez port 8530 usługi http (domyślny, można go zmienić: Od strony klienta wystarczy więc spradzić dostęp do strony http://nazwaserwera:8530 (zgłosi się pusta witryna):

W przypadku braku odpowiedzi należy sprawdzić, czy poprawnie działa serwer IIS:

Kolejnym problemem może być DNS - klient poprawnie powinien rozpoznawać nazwę serwera użytą jako źródło aktualizacji.

[item]Firewall na serwerze[/item]Serwer WSUS używa portów 443 i 80 do pobierania aktualizacji z serwerów Microsoft: wypada więc pozwolić mu na dostęp do:

   
        http://windowsupdate.microsoft.com
        http://*.windowsupdate.microsoft.com
        https://*.windowsupdate.microsoft.com
        http://*.update.microsoft.com
        https://*.update.microsoft.com
        http://*.windowsupdate.com
        http://download.windowsupdate.com
        http://download.microsoft.com
        http://*.download.windowsupdate.com
        http://wustat.windows.com
        http://ntservicepack.microsoft.com

[item]Konfiguracja[/item]Bardzo ważna jest przemyślana konfiguracji dotyczących sposobu aktualizacji i dla kogo są kierowane: * nie jest dobrą praktyką, aby komputer restartował się automatycznie, szczególnie w godzinach pracy :-) * przy małej ilości serwerów WSUS należy używać jako narzędzia informacyjnego a akutalizacje wykonywać ręcznie (do większych środowisk są inne narzędzia), * roządnie zarządać grupami: stacje robocze rozbić na laptopy i desktopy, * w większej sieci komputerów warto utworzyć grupę "Świnki Morskie" - tam przesunąć np. po jednej stacji roboczej z każdego działu. Po aktualizacjach dla tych komputerów można odczekać z tydzień - wtedy jest pewność, że łatwki nie wyrządziły krzywdy systemowi operacyjnemu. Takie podejście zmniejszy ryzyko zatrzymania działania firmy, gdzie np. jedna aktualizacja "uszkodziła" najważniejszy CRM, niezbędny dla biznesu. * mimo łatwo konfigurowalnej opcji automatycznego zatwierdzania aktualizacji, nie należy go używać bezkrytycznie. Można opcję zastosować np. dla systemu antywirusowego, ale wtedy także utworzyć grupę "świnki morskie", * warto skonfigurować w konsoli WSUS raporty przychodzące na adres mailowy administratora (o dostępnych nowych aktualizacjach i statusie stacji klienckich).

Podsumowanie

Zarządzanie aktualizacjami jest dość ciekawym zagadnieniem, szczególnie dla dużych środowisk. Do większych zadań jest bardzo dobre narzędzie w postaci System Center Configuration Manager (znany wcześniej jako SMS), który przy najbliższej okazji postaram się przybliżyć na podstawie wersji 2012 beta1