WSUS: serwer aktualizacji w Windows Server 2012

Wstęp

W przypadku Windows przez lata zarzucano Microsoftowi dość dużą opieszałość w łatananiu swoich produktów. Dość sporą rewolucją było wprowadzenie w WindowsME automatycznej aktualizacji przez internet. Usługa o której mowa to Windows Update - darmowe narzędzie dla posiadaczy licencji. W największym uproszczeniu: Windows Update jest repozytorium aktualizacji dla produktów Microsoft. Każdy, kto chociaż raz instalował Windows i uruchomił usługę WindowsUpdate wie, że jest to złożonym czasem nawet irytujący cykl:

• wygenerowanie na lokalnym komputerze "słowa" z informacjami, jakie są obecnie zainstalowane produkty i ich aktualizacje,
• zapytanie do usługi WindowsUpdate,
• odpowiedź serwisu WU, jakie są dostępne poprawki dla danego stanu systemu,
• decyzja użytkownika, jakie elementy mają zostać zakutalizowane,
• pobranie aktualizacji,
• instalacja.

Cykl zakończony jest najczęściej komunikatem o konieczności restartu systemu, następnie można ponownie sprawdzić, czy obecny stan systemu umożliwia pobranie dodatkowych łatek... i tak kilka razy :>

Microsoft publikuje najnowsze łatki w cyklu miesięcznym (wtorki), oraz te najbardziej krytyczne także w innych dniach tygodnia. Co pewien czas pojawiają się "duże" aktualizacje w postaci "paczek serwisowych" - Service Pack. Zawierają one kilkadziesiąt drobniejszych łatek, dodatkowo potrafią wnieść sporo do działania systemu (co miało miejsce w przypadku SP dla XP, czy Windows 7).

Kontrola musi być

W przypadku użytkownika domowego jest to genialne i proste w użyciu narzędzie. Co jednak, gdy:

• mamy w firmie 4000 komputerów
• , w sytuacji, gdy kilkadziesiąt z nich zacznie pobierać SP "ważący" 500MB - zapcha się nawet najszerszą rura do internetu,
• przez przypadek zaktualizują elementy, które mogą być krytyczne dla funcjonowania biznesu (np. źle napisany CRM, który tylko poprawnie działa w Internet Exporer 6 i nie może być aktualizacji dla .NET),
• aktualizacja unieruchomi całkowicie kilkadziesiąt komputerów.

Z pomącą przychodzi Server Update Service, znany obecnie jako WSUS. W początkach swojego istnienia (2005 rok) było to dość proste i kolokwialnie mówiąc... uperdliwe narzędzie. WSUS z czasem wyrusł z pieluch i w obecniej (3.0) jest dużym darmowym narzędziem usprawniającym zarządzenie stacjami roboczymi.

Z nieznanych mi przyczyn niektórzy administratorzy... boją się WSUSa, uznając usługę za mało wnoszącą do ich pracy i dodatkowo skomplikowana w działaniu. Nie do końca wiem skąd są się wzięły te miejskie legendy, postaram się przybliżyć działanie programu.

Jak to działa

Windows Server Update Services do prawidłowego działania wymaga:

• serwerowej wersji OS (min. MS Windows 2003),
• miejsca na dysku na aktualizacje (o tym później...),
• kilku składników w postaci usługi IIS, MMS, .Net Framework i silnika DB (SQL, lub WID).

WSUS dd wprowadzenia Windows 2008R2 jest jedną z możliwych usług serwera- tyczy to się także Windows 2012.

Sama idea serwera WSUS to lokalny serwer aktualizacji: administrator więc decyduje, jakie aktualizacje będą dostarczone do komputerów (pobieranie tylko raz).

Załóżmy, że mamy już zainstalowany Windows 2012, oraz skonfigurowane najważniejsze elementy (DNS, w miarę możliwości Active Directory itd.). Dodajmy więc rolę WSUS:

"Czarodziej" grzecznie nas poinformuje o konieczności dodania wyżej wymienionych składników i po zatwierdzeniu puści nas w dalszą część konfiguracji:

Konfiguracja następnej opcji powinna być dobrze przemyślana: repozytorium aktualizacji. Możemy całkowicie wyłączyć opcję trzymania plików na lokalnym serwerze (konieczność pobierania łatek przez stacje robocze z internetu), lub wskazać ścieżkę, gdzie zapisywać pliki.

Objętość tego folderu będzie zależała:

• od tego, ile mamy rożnych systemów operacyjnych w sieci (XP, Vista, 7/8, 32/64bit, MS Office, wersje językowych, itd.)
• , umiejętności posługowania się WSUSem.
• .

Mając przykładowo w sieci tylko Win7/32bit z preinstalowanymi SP1, będzie to niewiele ponad 0.5GB - widziałem jednak foldery mające więcej, niż 100GB. Przy dobrych wiatrach nie powinien jednak zająć więcej, niż 7‑15GB.

Kolejny etap to rząd ustawień, które później będziemy mogli bez problemu zmodyfikować:

Upstream Server

Źródło łatek dla naszego WSUSa. Domyślną opcją jest serwer Microsoft, jednak nic nie stoi na przeszkodzie używać kilku serwerów WSUS w jednej sieci, gdzie jeden jest np. źródłem danych dla innych.

Specify Proxy

Jest to o tyle warta uwagi funkcja, gdyż po zatwierdzeniu zmian następuje pierwsze połączenie ze źródłowym serwerem aktualizacji - może to potrwać dobre kilkanaście minut:

Choose language

W większości przypadku wystarczy wybrać język lokalny i angielski - zależne od naszych stacji roboczych. Jest to jedna z tych opcji, która może wyraźnie "nadmuchać" repozytorium. W niektórych firmach (np. programistyczne, tłumaczenie tekstów itd.) pracownicy używają różnych wersji systemu i jest to spore obciążenie dla zasobów dyskowych.

Choose products

Tutaj wybór jest spory, warto poświęcić czas tej sekcji:

• systemy operacyjne (od 2000 kończąc na Windows 8 i RT, z uwzględnieniem edycji serwerowych)
• program antywirusowy (MS Security Essentials),
• pakiety biurowe (Works, Office 2002/XP-2013),
• SQL,Exchange,
• inne produkty MS (Forefront, Visual Studio łącznie ze Skype itd.).

Choose Classifications

Podział logiczny (kategoryzacja) aktualizacji. Jest to raczej kwestia kosmetyczna, polecam zaznaczyć: Critical Updates, Definition Updates, Security Packs, Security Updates.

Configure Sync Schedule

Sync Schedule, czyli jak często WSUS ma aktualizować bazę łatek z serwera źródłowego:

Uruchomienie

Załóżmy  że instalacja powiodła się - urchamiamy więc konsolę WSUS:

Główny ekran prezentuje najważniejsze informacje:

[list] [item]komputery wymagające aktualizacji,[/item][item]status synchronizacji,[/item][item]możliwe "szybkie akcje" w postaci zaakceptowania oczekujących łatek.[/item][list]

Po rozwinięciu instancji WSUS (w tym przypadku jest jeden serwer, w złożonych środowiskach może ich być więcej) ukaże się siedem głównych sekcji:

• aktualizacje: tu będziemy zatwierdzać (lub wycofywać...) łatki,
• downstream servers: serwery replikujące (czyli inne serwery WSUS),
• synchronizacje: status połączeń do serwera źródłowego (czas trwania sesji, rezultat w postaci informacji o nowych aktualizacjach, lub wycofanych).
• raporty: numerki, którymi możemy się pochwalić na spotkaniu firmowym ("w dniu X nastąpiła 2334 desktopów zakończona sukcesem),
• Opcje:czyli konfiguracja WSUSa.

Do dokładniejszego omówienia wrócę w dalszej części, najpierw należy dodać komputery do zasobów serwera aktualizacji.

WSUS okiem klienta, czyli stacji roboczej

Jak już wspomniałem, Windows przy ustawieniach domyślnych pobiera aktualizacje z internetu. Status tego procesu można śledzić w logach znajdujących się w głównym katalogu Windowsa:

Microsoft udostępnia też proste, ale bardzo pomocne narzędzie: Client Diagnostics Tool, które w działaniu wygląda następująco:

Zmianę w konfiguracji zapewni konfiguracja polis: Group Policy. W komputerze, który nie jest podłączony do domeny wystarczy (uprawnienia administratora lokalnego) wywołać konsolę gpedit.msc. Gałąź wymagająca edycji to Windows Update:

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

W przypadku kontrolera domeny należy:

[list] [item]utworzyć nowy obiekt GPO (można także wyedytować isniejący, jednak dobra praktyką zapewniającą przejrzystość i elastyczność konfiguracji jest utworzenie nowego)[/item][img=GPO1]

[item] podlinkować ("przeciągnąć") obiekt GPO do domeny:[/item][img=GPO2]

[item]wyedytować ustawienia[/item][img=GPO3]

[/list]

Podsumowanie

Jak widać powyżej, temat jest mimo wszystko dość złożony. W drugiej części poruszę tematy dotyczące:

• konfiguracji i opisu opcji klienta,
• konfiguracja komputerów i grup w konsoli,
• automatycznych zadań na przykładzie aktualizacji programu antywirusowego,
• diagnostyki i dobrych praktyk w przypadku serwera WSUS.