Usługa Windows Update nie działa w systemie Windows 2012 R2 Standard

Niedawno odziedziczyłem zarządzanie serwerem Windows 2012 w zdalnej witrynie.

Sprawdziłem Windows Update i nie aktualizuje się od marca. Kiedy mówię Windowsowi, aby sprawdził dostępność aktualizacji, działa tak, jakby sprawdzał, ale wydaje się, że mówi to godzinami. Jeśli spróbuję ponownie uruchomić usługę aktualizacji systemu Windows, wydaje się, że nigdy nie będzie w stanie się zamknąć. Moim jedynym lekarstwem jest ponowne uruchomienie komputera, aby wrócić do punktu, w którym mogę powiedzieć Windows Update, aby sprawdził dostępność nowych aktualizacji.

Ostatnie pomyślne sprawdzenie aktualizacji mówi 20 marca.

Ostatnie zainstalowanie aktualizacji mówi 17 marca (nie powiodło się).

Historia aktualizacji pokazuje, że jedna aktualizacja nie powiodła się 17 marca, aktualizacja sterownika drukarki, ale historia pokazuje 13 nieudanych aktualizacji 17 lutego.

Nie jestem pewien, co jeszcze spróbować.

Dwie z moich trzech maszyn 2012R2 wykazały takie zachowanie w kwietniu ubiegłego roku. Zawiesiliby się przy Sprawdzaniu aktualizacji ... na zawsze.

Nigdy nie dowiedziałem się dokładnie, co spowodowało problem, ale udało mi się go rozwiązać, wykonując następujące czynności:

1. Zatrzymaj usługę Windows Update.

   net stop wuauserv
   

2. Usuń katalog pamięci podręcznej Windows Update C:\Windows\SoftwareDistribution.

   Remove-Item -Recurse -Force C:\Windows\SoftwareDistribution
   

3. Zrestartuj komputer. (Na jednym komputerze wymagało to kilku restartów, aby faktycznie usunąć wszystko z tego katalogu, więc spróbuj w razie potrzeby.)

4. Uruchom ponownie Windows Update ręcznie. Niemal natychmiast zawiedzie i zaoferuje uruchomienie narzędzia diagnostycznego. Pobierz narzędzie i pozwól mu działać.

5. Narzędzie znajdzie i naprawi niektóre problemy. W tym momencie uruchom ponownie Windows Update ręcznie. W tym momencie Windows Update działał dobrze.

znalazłem tę świetną odpowiedź tutaj i działała dla mnie pięknie. Po prostu chcę się podzielić na wypadek, gdyby ktoś szukał:

Spróbuj tego w wierszu polecenia z podwyższonym poziomem uprawnień:

netsh winhttp import proxy source=ie

i uruchom ponownie

innym rozwiązaniem, które również działało dla mnie, było ustawienie trybu aktualizacji na „Nigdy nie sprawdzaj dostępności aktualizacji”

Użyłem narzędzia gotowości aktualizacji systemu i narzędzia DISM. To zadziałało dla mnie. Możesz go pobrać tutaj: http://support.microsoft.com/kB/947821

Bawiłem się maszyną wirtualną z 2012 roku i miałem ten problem. Moje rozwiązanie (szybkie, niepewne itp.) Polegało na wyłączeniu bezpieczeństwa IE Enhanced na serwerze i szczęśliwie zaczęło rozmawiać z MS Windows Update. Nie jest to rozwiązanie dla prawdziwego serwera, ale to serwer deweloperów zabawek i nie mam nic przeciwko.

Prawdopodobnie witryna z aktualizacjami systemu Windows musi zostać dodana do niektórych zaufanych witryn, aby znaleźć prawdziwe rozwiązanie?

Moja poprawka na nowo zainstalowanym w systemie Windows Server 2012 R2 na maszynie Wirtualnej Citrix 6.5 i, jak napisał Marcus Greasly, wyłącz IE Enchanced Security ... zadziałało natychmiast ...

Aby wyłączyć ulepszone zabezpieczenia IE w systemie Windows Server 2012 R2, uruchom Menedżera serwera, po lewej stronie kliknij Serwer lokalny. Po prawej stronie kliknij link Włączony obok pozycji Konfiguracja zwiększonych zabezpieczeń IE. Zobaczysz teraz okno Konfiguracja zwiększonych zabezpieczeń programu Internet Explorer.

https://prajwaldesai.com/disable-ie-enhanced-security-in-windows-server-2012-r2/

Ostatnio miałem te same problemy na moim serwerze 2012 i wszystko, co zrobiłem, to wyłączyć usługę Malwarebytes i aktualizacje pobrane od razu. Spróbuj wyłączyć wszelkie złośliwe oprogramowanie lub oprogramowanie antywirusowe, ponieważ może to być przyczyną root.

Przegląd

Ten problem występował na niektórych serwerach wirtualnych migrowanych z dostawcy „chmury” z powrotem do naszego wewnętrznego centrum danych. Główną przyczyną były uprawnienia do %SystemRoot%\System32\catroot2folderu. Istnieje wiele różnic między uprawnieniami do tego folderu na zdrowym serwerze a uprawnieniami na serwerze migrowanym. Uważam, że kluczowym było to, TrustedInstallerże nie miał full access.

Dodatkowe objawy

Patrząc na dziennik aplikacji w przeglądarce zdarzeń, zauważyliśmy szereg błędów:

Source: CAPI2
EventId: 257
Text: The Cryptographic Services service failed to initialize the Catalog Database. The ESENT error was: -1032.

Source: ESENT
EventId: 490
Text: Catalog Database (416) Catalog Database: An attempt to open the file "C:\Windows\system32\CatRoot2\{127D0A1D-4EF2-11D1-8608-00C04FC295EE}\catdb" for read / write access failed with system error 5 (0x00000005): "Access is denied. ".  The open file operation will fail with error -1032 (0xfffffbf8).

Wskazówka znajduje się w tekście błędu ESENT; tzn. problem z uprawnieniami dostępu do pliku w folderze catroot2.

Rozkład

Daj zaufanemu instalatorowi pełną kontrolę nad folderem catroot2 i jego dziećmi.

Jeśli to nie wystarczy, dla porównania uruchomienie icacls %systemroot%\system32\catroot2na zdrowym serwerze daje:

C:\Windows\system32\catroot2 NT SERVICE\CryptSvc:(F)
                         NT SERVICE\CryptSvc:(OI)(CI)(IO)(F)
                         NT SERVICE\TrustedInstaller:(I)(F)
                         NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
                         NT AUTHORITY\SYSTEM:(I)(F)
                         NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Administrators:(I)(F)
                         BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                         BUILTIN\Users:(I)(RX)
                         BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
                         CREATOR OWNER:(I)(OI)(CI)(IO)(F)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
                         APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(OI)(CI)(IO)(GR,GE)

Uwaga: aby dodać Zaufany instalator, musisz wyszukać na kontach komputera lokalnego nt service\trustedinstaller.

Po zamianie uprawnień na catroot2, upewnij się, że kliknąłeś pole replace permissions on child objects & containerswyboru, aby upewnić się, że elementy potomne mają również przydzielone uprawnienia.

Ponowne uruchomienie nie jest wymagane dla samej poprawki (choć oczywiście, gdy aktualizacje zaczną ponownie działać, prawdopodobnie trzeba będzie je ponownie uruchomić).