Microsoft próbuje naprawić Windows Update, ale coś chyba poszło nie tak

Wkrótce po opublikowaniu lutowych aktualizacji zabezpieczeń w dla Windows 10, jedna z nich zniknęła z działu pobierania, a jej dokumentację dwukrotnie wycofano. Anulowana poprawka nie jest aktualizacją zabezpieczeń, a nową wersją tzw. stosu serwisowego (SSU) przeznaczonego dla starszych wersji Windows. SSU są wydawane periodycznie celem likwidacji problemów z instalacją pakietów Windows Update.

Najwyraźniej narzędzie do rozwiązywania problemów samo miało problemy. Jest już dostępna jej nowa wersja, wydana 3 dni później. Aby zrozumieć co złego dzieje się z Windows Update potrzebne jest nieco kontekstu. Przytoczenie kilku faktów pozwoli zrozumieć do jakiego stopnia mechanizm aktualizacji Windows wymknął się spod kontroli i jak trudny jest do naprawy.

Wraz z premierą Windows 10, Microsoft zdecydował się nie wydawać oddzielnych aktualizacji dla każdej łatanej dziury, a zamiast tego publikować jedną wielką paczkę ze wszystkimi. Pozwoliło to zmniejszyć liczbę scenariuszy testowych, zadbać o to by klienci mieli aktualne oprogramowanie i ułatwić polowanie na łatki. Ponadto, ukryto w ten sposób niemożliwy najwyraźniej do rozwiązania problem z Windows Update: wzrost liczby aktualizacji znacząco wydłuża proces ich wyszukiwania, ze względu na próbę rozwiązania zależności. Zjawisko to zachodzi do tej pory i potrafi rozciągnąć proces pierwszej instalacji nawet do kilku dni (!).

Jest po prostu niedostrzegalne, bo Windows otrzymuje jedną aktualizację miesięcznie, zastępującą w dodatku poprzednią. Istotnie, czasem pojawia się ich więcej, gdyż aktualizacje Flasha, mikrokodu, list odwoławczych UEFI Defendera, silnika antywirusowego oraz środowiska .NET są dostarczane oddzielnie. Ale ogólną zasadą jest jeden miesiąc = jedna aktualizacja. Stało się to możliwe odkąd sam składnik Windows Update zaczął być aktualizowany oddzielnie.

Windows Update zawsze wymagał oddzielnych aktualizacji, ale były one rzadkie bo i przed samym narzędziem nie stawiano niemożliwych wyzwań. Teraz jest inaczej. Systemy muszą bezproblemowo nakładać pakiety ważące 1.7GB i robić to najlepiej bez prowokowania systemu do tworzenia piętrowego drzewa czynności oczekujących (pending.xml) aby uniknąć trzech restartów i długiego porządkowania. Te częste aktualizacje Windows Update są wydawane po nazwą Servicing Stack Update (SSU).

Oddzielne naprawianie mechanizmu aktualizacji pozwoliło rozwiązać problemy z chybotliwym Windows Update, który wbrew powszechnej opinii i ogromu krytyki, działa naprawdę dobrze. Z tym, że Windows jest systemem ogólnego przeznaczenia i często jest obecny także miejscach pozbawionych przezroczystych aktualizacji automatycznych. Specyficzne wdrożenia regularnie wykluczają obecność połączenia internetowego albo jakiejś lokalnej instancji SCCM/WSUS i aktualizacje muszą być dostarczane i aplikowane samodzielnie.

Prowadzi to do zabawnego polowania. "Jedna aktualizacja" nagle przestaje być jedną aktualizacją. Poza ostatnią paczką kumulatywną (LCU) należy odnaleźć pasujące paczki stosu serwisowego. Zależność od nich jest w dodatku nieostra: nałożenie nowej łatki "być może" powiedzie się bez nich. A jeżeli są potrzebne, to możemy się tego dowiedzieć na przykład po dwóch godzinach mielenia dyskiem przez TrustedInstaller.

Microsoft niewątpliwie był świadom, że uzależnienie od Windows Update to słaba opcja dla odizolowanych wdrożeń, a nie każde miejsce ma na stanie fachowca-psychopatę, który recytuje identyfikatory MSU z pamięci (job security takiej roli jest urokliwie wysokie, swoją drogą). Toteż nowe wersje Windows 10 i testowe wersje przyszłego Windows Server zaczęły oferować modyfikacje dla stosu serwisowego, wprowadzające "transakcje przedwstępne", w których pakiet aktualizacji sam potrafił zaktualizować stos, aby umieć się poprawnie zainstalować. W ten sposób system naprawdę zaczął otrzymywać jedną aktualizację.

Z tym, że zainkorporowanie tej zmiany w najnowszym Windows 10, systemie konsumenckim, oraz w Windows Server, systemie z przyszłości to niemal akt bezczelności. Nikt na nim nie skorzysta. Zapewne wskutek negatywnych głosów, zdecydowano się na rozszerzenie tego rozwiązania na starsze wersje. Szczególnie pożądane jest ono na systemie Windows Server 2016, którego aktualizacje bardzo mocno spuchły z biegiem lat, a w dodatku potrzebne jest spoko pakietów "out-of-band", których nigdy z LCU nie zintegrowano.

Wydano więc paczkę KB4601392 i zaktualizowano artykuł na temat połączenia SSU z LCU o wzmiankę o tym, że zintegrowane podejście rozszerzono o wersje serwerowe i LTSC. Lutowe SSU miało być ostatnie i jego zainstalowanie miało raz na zawsze zlikwidować zjawisko polowania na paczki. Z tym, że… aktualizacja wkrótce potem zniknęła. Linki do niej prowadziły do błędu 404, Update Catalog zwracał zero wyników. Sam Windows Server 2016 umiał coś pobrać jeżeli był podpięty do internetu, więc dlaczego nie dało się tego ściągnąć ręcznie?

Jeżeli podpięty do Windows Update system nie umie się zaktualizować, rozpocznie oczyszczanie i wygeneruje sporą paczkę telemetryczną. Następnie będzie rozmawiać z Microsoftem, wymieniać się raportami o błędach i aplikować zdalnie serwowane zmiany aż się naprawi. Odcięte od internetu systemy nie mogą tak robić. Dlatego dostarczane im SSU ma nie potrzebować takich zabiegów. Na produkcji niech testują klienci, a nie infrastruktura.

W piątek wieczorem lutowe SSU wróciło. Ale inne. Aktualizacja KB5001078 zastępuje KB4601392, ale w notatce nie ma o tym ani słowa. Co więcej niż, artykuł mówi wprost mówi, że paczka zastępuje aktualizację wrześniową, mamy więc przyjmować, że KB4601392 nigdy nie miało miejsca. Jedyne miejsce, w którym da się przeczytać cokolwiek oficjalnego na temat tej aktualizacji, to noty wydawnicze LCU, gdzie pada jedno zdanie na temat wymagania najnowszego SSU. Zaciemnianie historii nikomu nie służy, więc wybór takiej metody zarządzania szkodami nieco dziwi.

Co się stało? Jeżeli wierzyć wątkowi na forum Dokumentacji Microsoft, aktualizacja SSU doprowadzała do zawieszenia instalatora Windows Update… podczas pracy nad aktualizacją kumulatywną. Zawieszenie instalatora, zjawisko rzadkie, jest czymś o wiele gorszym niż zakończenie pracy z błędem. Błąd zazwyczaj oznacza, że możliwe jest zidentyfikowanie miejsca, w którym nastąpił problem i wycofanie zmian. Jeżeli zamiast tego instalator trzeba ubić, konieczne jest przejście przez analizę zdrowia systemu (SFC i DISM Health Check).

Problem wystąpił nie tylko na on-premowych Windows Serverach, ale także na platformie Azure. Oznacza to, że z nałożeniem aktualizacji nie radziły sobie także referencyjne wdrożenia… pod pewnymi warunkami. Nie jest do końca jasne, co doprowadziło do awarii TiWorkera, faktem jest jednak że Microsoft został zasypany zgłoszeniami błędów WER. Próby naprawienia Windows Update nie powiodły się zatem. Być może mechanizm ten, wywodzący się jeszcze z Visty, trzeba będzie wkrótce porzucić.