Czasami przy wyborze sposobu zarządzania poprawkami trzeba się zastanowić: “co będzie jeśli poprawka nam coś namiesza?”. Z mojej praktyki jako administratora na wszelakich systemach wynika, ze najbezpieczniejszym – przez co najbardziej czasochłonnym – podejściem jest wyłączenie automatycznych poprawek. Takie podejście ma swoje dobre i złe strony:

• dobrą – pozwala nam zaplanować proces instalacji poprawek, przejrzeć dokumentację do nich (np biuletyny bezpieczeństwa) i przetestować (co jest zalecane, choć nie często realizowane);
• złą – wymaga poświęcenia dodatkowego czasu w miarę regularnie (najlepiej po drugim wtorku miesiąca) na ich instalację.

Możemy oczywiście używać narzędzia WSUS (Windows Software Update Services), które to w większych sieciach czy instalacjach nierzadko staje się koniecznością. Jeśli jednak mamy na głowie mniejszą instalację możemy do każdego serwera podchodzić osobno. Przy instalacji nowego serwera opartego o system Windows 2008 Server R2 ustawienia aktualizacji nam nie umkną. Po zainstalowaniu systemu oczywiście powinniśmy (w wielu wypadkach musimy, bo będą tego wymagać aplikacje) dokonać aktualizacji, poprzez narzędzie Windows Update.

Jak widac na zrzucie ekranu poniżej, system nigdy nie był aktualizowany, zaś przed aktualizacja musimy przygotować ustawienia, wedla naszych upodobań. Bez tej operacji system nie pozwoli nam na pobranie poprawek (choć ułatwia wybór poprzez zaproponowanie automatycznych poprawek):

Jednak prawdziwy administrator powinien zacząć od pola Change Settings (czyli zmiany ustawień). Po wejściu w ustawienia, mamy możliwość wybrania jednej z czterech opcji podejścia do poprawek:

1. Instalacja automatyczna (rekomendowane przez producenta / nierekomendowane przeze mnie);
2. Pobranie poprawek, lecz z możliwością decydowania o momencie instalacji;*
3. Sprawdzenia dostępności poprawek z możliwością decydowania o momencie pobrania jak i instalacji;*
4. Całkowita odmowa pobierania poprawek (nierekomendowane przez producenta / nierekomendowane przeze mnie)

W przypadku moich systemów zawsze jest to opcja trzecia, która po pierwsze daje mi możliwość kontroli tego co chcę instalować, po drugie momentu instalacji, a po trzecie zabezpiecza przez nerwowymi telefonami użytkowników w ciągu dnia (którym ściągane poprawki mogą spowolnić działanie łącza). Dodatkowymi opcjami, które wybieram jest informowanie o rekomendowanych przez producenta poprawkach, w taki sam sposób jakbym je pobierał (w jednym miejscu) oraz zabronienie instalacji poprawek innym użytkownikom (szczególnie przydatne w małych instalacjach biurowych na komputerach klienckich).

Potem pozostaje już tylko zaakceptować wybrane ustawienie i voilà – można zacząć zapychać łącze.

Pierwszy zestaw jaki dostajemy dla Windows Server 2008 R2 x64 zawiera osiemdziesiąt pięć ważnych i jedną opcjonalną poprawkę. Potem po restarcie pojawi nam się jeszcze sześć, restart, service pack 1, restart, trzy, restart, jedna, restart… o ile dobrze zapamiętałem kolejność.

Decyzja o sposobie podejścia do zarządzania poprawkami jest zawsze indywidualna (o ile korporacja nie wymusza proceduralnego podejścia), ale już na początku pracy z systemem, warto zwrócić na ten temat uwagę.

* opcja 2 i 3 pozwalają nam panować nad instalacją i dostępnością środowiska, niejednokrotnie się bowiem okazuje, że dana poprawka (bez wzgldu na to czy jest mała czy duża) może wymagać fizycznego lub wirtualnego, ale pełnego restartu systemu operacyjnego. Niejednokrotnie umowy z klientami zewnętrzymi (np.: outsourcowany klient) lub wewnętrznymi (np.: nasza księgowość) wymagają zachowania dostępności, a już z pewnością żaden podmiot z nami współpracujący nie będzie szczęśliwy, jeśli nagle w środku dnia wyłączy mu się środowisko.

PS. Ci co byli na SQLDAY 2011 we Wrocławiu, mogli zaobserwować efekt działania automatycznych poprawek na działającym serwerze Business Intelligence…