Windows Server 2008 R2– Server Manager Error ??:/

Jak to zwykle bywa w czwartek przed wyjściem z pracy włączyłem sobie uaktualnienia jednego z serwerów produkcyjnych, potrzebowałem dograć jedną łatkę a przy okazji poleciało trochę zaległości. Aktualizacja przeleciała błyskawicznie, restart serwera, 1/3, 2/3, 3/3, cofanie zmian. Godzina już późna 15.55 i nagle wysypały się uaktualnienia. Na szczęście system po restarcie uruchomił się poprawie, przynajmniej tak mi się wydawało. W piątek około 10 stwierdziłem, że doinstaluje pewną role, jednak ku mojemu zdziwieniu zobaczyłem biały ekran w zarządzaniu serwerem:/

Sytuacja o tyle dziwna, że przed aktualizacją wszystko działo poprawnie. Od pewnego czasu, w takich sytuacjach, uwielbiam  sprawdzać logi systemowe. W sumie szkoda, że często nie ma bezpośredniej informacji, który log muszę przeszukać. Na szczęście pomimo tego, że MS nie lubi się chwalić logami w komunikatach o błędach, często na technecie lub w dzienniku zdarzeń często gęsto można znaleźć odnośnik do właściwego pliku. W mojej sytuacji był to plik w

%systemroot%\Logs\CBS\CBS.log. Aktualnie nie posiadam, przed sobą kopi tego logu jednak można z niego przeczytać dlaczego otrzymujemy błąd podczas server manager’a. W moim przypadku plik w/w logu nie do końca pozwolił mi uzyskać info o tym, która łatka popsuła pliki systemowe.

Z pomocą przyszedł System Update Readiness Tool for Windows Server 2008 R2 x64 Edition – małe narzędzie pozwalające nam sprawdzić, które pliki usług są uszkodzone lub niewłaściwe (nowsze/starsze). Narzędzie działa dość prosto:

1. 
   
   Po pobraniu próbuje się zainstalować w systemie tak jak zwykła łatka


2. 
   
   Podczas instalacji tworzy log c:\windows\logs\CBS\CheckSUR.log, który wygląda mniej więcej tak:
   Przykład:
   
   =================================
   Checking System Update Readiness.
   Binary Version 6.1.7600.20822
   Package Version 10.0
   2010-11-25 11:22
   
   Checking Windows Servicing Packages
   
   Checking Package Manifests and Catalogs
   (f)    CBS MUM Corrupt    0x00000000    servicing\Packages\Package_for_KB981957_RTM~31bf3856ad364e35~amd64~~6.1.1.2.mum        Expected file name Microsoft-Windows-Foundation-Package~31bf3856ad364e35~amd64~~6.1.7600.16385.mum does not match the actual file name
   
   Checking Package Watchlist
   
   Checking Component Watchlist
   
   Checking Packages
   
   Checking Component Store
   ==================================


3. Jeśli złapaliśmy info to anulujemy instalacje łatki RTools i możemy przystępować do naprawy.

Przewróciło się niech leży czyli jak odkręcić ten cały bałagan:

Drobna uwaga: przed przystąpieniem do jakiejkolwiek naprawy lepiej wykonaj backup. Za działanie poniższej procedury nie biorę odpowiedzialności. Tak więc jeśli coś pomylisz to lepiej miej kopie zapasową serwera

1. 
   
   Dobra złapaliśmy log i co dalej. Jak pewnie zauważyłeś w pliku mamy informacje który z plików jest uszkodzony:
   servicing\Packages\Package_for_KB981957_RTM~31bf3856ad364e35~amd64~~6.1.1.2.mum


2. 
   
   Pogrubionym tekstem zaznaczyłem numer paczki, w której możemy znaleźć odpowiedni plik. Dlatego pierwsze co musimy zrobić to pobrać odpowiednią wersję aktualizacji z strony supportu MS. W moim przypadku musiałem pobrać   KB981957 dla Windows Server 2008 R2 x64.


3. 
   
   Po pobraniu paczki, zamieniamy jej rozszerzenie z msu na cab., jeśli posiadacie na serwerze 7zipa można bez zmiany rozszerzenia wypakować paczkę do nowego katalogu.


4. 
   
   Po rozpakowaniu paczki wyszukujemy plik: Package_for_KB981957_RTM~31bf3856ad364e35~amd64~~6.1.1.2.mum


5. 
   
   Przed podmianką pliku musimy najpierw zmienić właściciela i nadać naszemu kontu pełne prawa do oryginalnego pliku.


6. 
   
   Po nadaniu uprawnień zmieniamy nazwę oryginalnego pliku – dobrze jest mieć kopię gdyby jednak podmianka pliku spowodowała niespodziewane błędy.


7. 
   
   Następnie do katalogu c:\Windows\Servicing\Packages\ (*ten katalog też jest wypisany w logu Rtools) kopiujemy plik który wypakowaliśmy sobie z świeżo pobranej paczki.


8. 
   
   Po skopiowaniu pliku zmieniamy jego właściciela na konto systemowe oraz dodajemy pełne uprawnienia dla NT SERVICE\TrustedInstaller. Uprawnienia dla TrustedInstaller powinny zostać odziedziczone z katalogu nadrzędnego.


9. 
   
   Jeśli w logu CheckSUR.log było więcej wpisów to dla kolejnych plików postępujemy zgodnie z krokami 1-8.


10. 
    
    Po podmienieniu wszystkich plików dobrze jest jeszcze raz uruchomić Readiness Tool by sprawdzić czy wprowadzone zmiany nie powodują konfliktów lub czy jakimś cudem nie wgraliśmy złych plików.


11. 
    
    Jeśli kolejny log jest czysty to spokojnie możemy uruchomić server manager’a.

Cała procedura działa też na innych systemach Vista/7/2008. Także, jeśli widzisz dziwne błędy, które nie są opisane w żadnym KB to warto uruchomić System Update Readiness Tool.