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:

  • [2] Powiadom przed pobraniem aktualizacji i ponownie powiadom przed instalacją
  • [3] Pobierz aktualizacje i powiadom, kiedy są gotowe do instalcji (opcja domyśłna)
  • [4] Automatycznie pobierz aktualizacje i zainstaluj o zadanej godzinie (domyślnie o 3 rano codziennie). UWAGA: jeżeli jest taka potrzeba, AUTOMATYCZNIE zrestartuj komputer.
  • [5] Pozwól lokalnym administratorom decydować o aktualizacjach
  • 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:

  • restart komputera (pewniejsza metoda)
  • z linii poleceń:
  • 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):

    sc query "wuauserv"

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

    Get-Service wuau*

    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ń:

    wuauclt

    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:

    wuauclt /detectnow
    wuauclt /reportnow

    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:

    wuauclt /detectnow

    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.

  • Brak komunikacji z serwerem WSUS
  • 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.

  • Firewall na serwerze
  • 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
    
  • Konfiguracja
  • 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