Poniżej znajduje się przewodnik, którego używam podczas rozwiązywania problemów z uszkodzoną instalacją WSUS. Może się to objawiać jako błąd konsoli serwera, popularne „to się po prostu nie zgłasza” lub poprzez dziennik zdarzeń. Przeprowadzę cię przez komponenty WSUS i jak sprawdzić i upewnić się, że każdy z nich działa poprawnie.
Pierwsza uwaga na temat tego, co jest dostępne na twojej platformie.
Jeśli pracujesz na Windows 7/8/Server 2008R2/2012R2 to wuauclt
działa dla ciebie.
Jedynym prawdziwym poleceniem, które musisz znać, jest wuauclt /resetauthorization /detectnow
.wauauclt /reportnow
nie robi tego, co myślisz i nie jest zbyt użyteczne.
Jeśli używasz systemu Windows 10/Server 2016, to wuauclt został pozbawiony tej funkcji i masz UsoClient
.usoclient.exe startscan
do wykrywania brakujących poprawekusoclient.exe refreshsettings
do odświeżania ustawień, jeśli zostały dokonane jakiekolwiek zmianyusoclient.exe startdownload
do pobierania poprawekusoclient.exe startinstall
do instalowania poprawek
Masz również możliwość użycia Powershell do zainicjowania żądania skanowania.
(New-Object -ComObject Microsoft.Update.AutoUpdate).DetectNow()
Mówiąc o Powershell, Microsoft udostępnia wiele cmdletów do zarządzania serwerem WSUS. Aby sprawdzić, czy są one dostępne, należy uruchomić
Get-Command -Module UpdateServices
Te cmdlety są przede wszystkim ukierunkowane na wdrażanie i zarządzanie serwerem, łatami i komputerami, a nie na rozwiązywanie problemów.
Na kliencie istnieje moduł WindowsUpdate, ale jego jedyną funkcją jest Get-WindowsUpdateLog, który jest używany do generowania czytelnego pliku WindowsUpdate.log w systemie Windows 10.
Istnieje moduł PS innej firmy do zarządzania Windows Update na kliencie.
Install-Module PSWindowsUpdate Import-Module PSWindowsUpdate Add-WUServiceManager -ServiceID 7971f918-a847-4430-9279-4a52d1efe18d Get-Command -Module PSWindowsUpdate Get-WUList –MicrosoftUpdate Get-WUInstall –MicrosoftUpdate –AcceptAll –AutoReboot
Baza danych
WSUS ma możliwość wykorzystania wewnętrznej bazy danych WID (Windows Internal DB) lub bazy danych SQL. Zamierzam założyć, że jest zainstalowany z WID na domyślnej ścieżce C:\Windows\WID\
.
Błędy związane z bazą danych (inne niż fragmentacja) zwykle występują w czasie instalacji, często podczas sekwencji zadań poinstalacyjnych.
Mimo że możliwe jest połączenie się z WID i upuszczenie SUSDB, błędy na tym etapie są zwykle najlepiej naprawiane poprzez całkowitą deinstalację i ponowną instalację.
Dla celów referencyjnych powiem, że możesz użyć SQLCMD lub SQL Mgmt Studio, aby połączyć się z DB.
Ciąg połączenia to np:\.\pipe\MICROSOFT##WID\tsql\query
select name from sys.sysdatabasesdrop table susdbselect name from sys.sysdatabases
Uninstalacja
Uninstaluj używając Server Manager.
Upewnij się, że folder zawartości WSUS zniknął, jak również witryna IIS WSUS Administration.
Odinstalowanie programu WSUS nie zawsze usuwa identyfikator WID. Usuń go w Powershell za pomocą Uninstall-WindowsFeature -Name windows-internal-database
Reboot i usuń pliki c:\windows\WID\SUSDB.mdf
i SUSDB_log.ldf
.
Instalacja
Poza wybraniem roli WSUS system Windows instaluje ASP.NET 4.6, narzędzia RSAT, IIS i usługę aktywacji procesów Windows.
Instaluj z administracyjnego znaku zachęty Powershell
Install-WindowsFeature -Name Updateservices,UpdateServices-WidDB,UpdateServices-services -IncludeManagementTools
Potem, przed uruchomieniem GUI, uruchom:
Sprawdź klienta
Jest kilka potencjalnych przyczyn nieotrzymywania aktualizacji przez klienta. Przejdę przez szereg kroków rozwiązywania problemów, a na końcu podam dwa skrypty do „zresetowania” klienta, jeśli nic innego nie działa.
Sprawdź wolne miejsce na dysku twardym.
Sprawdź dziennik Windowsupdate.
W systemie Windows 10 otwórz administracyjny wiersz poleceń powershell i uruchom Get-Windowsupdatelog
. Dziennik zostanie wyświetlony na pulpicie. Poczekaj, aż polecenie zakończy działanie.
W systemie Windows 7 sprawdź C:\Windows\WindowsUpdate.log
To powinno wskazać, czy problem jest oparty na kliencie, czy jest to problem z komunikacją ze zdalnym punktem końcowym.
Najprostszym pierwszym krokiem w rozwiązywaniu problemów z klientem jest uruchomienie narzędzia Windows Update Troubleshooter.
W systemie Windows 10 przejdź do witryny Microsoft iFixIt for WSUS.
Spowoduje to wyświetlenie monitu o pobranie narzędzia Windows Update Troubleshooter (w formacie pliku cab). Zapisz go i uruchom.
Wybierając Windows 7 na tej stronie zostaniesz poproszony o kliknięcie prawym przyciskiem myszy na Sieć (w zasobniku systemowym) i „Rozwiązywanie problemów”. Prawdopodobnie możesz pominąć ten krok.
W systemie Windows 10 spróbuj sprawdzić aktualizację online.
Sprawdź, czy usługa jest uruchomiona.Get-Service -Name wuauserv
Następnie sprawdź i upewnij się, że klient otrzymuje ustawienia WSUS z Group Policy.
Uruchom gpresult /scope computer
, aby sprawdzić, czy polityka ustawień WSUS jest stosowana na komputerze.
Zapytaj rejestr klienta o ustawienia WSUS za pomocą Get-ItemProperty HKLM:\Software\Policies\Microsoft\Windows\WindowsUpdate
Telnet może być użyty do sprawdzenia problemów z łącznością portów. Jeśli spróbujesz nawiązać połączenie telnet z otwartym i dostępnym portem, telnet otworzy nowe puste okno poleceń. Jeśli port jest niedostępny, polecenie po prostu się nie powiedzie. Spróbuj nawiązać połączenie z serwerem WSUS i portem. Jeśli połączenie nie powiedzie się, sprawdź ustawienia zapory sieciowej.telnet wsus.server.com 8530
Użyjmy Powershell do przetestowania łączności.Test-NetConnection -ComputerName <WSUS_Server> -Port 8530 -InformationLevel Detailed
Nie zapomnij o oczywistym kroku sprawdzenia dziennika zdarzeń.
Dziennik zdarzeń aplikacji, a także dzienniki aplikacji i usług > Microsoft > Windows > WindowsUpdateClient
Czasami programy antywirusowe lub inne agenty bezpieczeństwa punktów końcowych mogą zakłócać komunikację sieciową. Rozważ wyłączenie lub odinstalowanie ich na czas testów.
Uruchom sfc /scannow
z administracyjnego wiersza poleceń, aby sprawdzić, czy nie ma uszkodzeń plików, które mogą mieć wpływ na klienta.
Jeśli w programie WSUS są zarówno działające, jak i niedziałające klienty, sprawdź c:\program files\update services\WebServices\ClientWebServices
dla pliku web.config
i porównaj plik działający z niedziałającym w poszukiwaniu różnic.
Jeśli ten klient pochodzi z obrazu systemu operacyjnego, a program Sysprep nie został uruchomiony, problemem może być używanie przez wiele klientów tego samego klucza SUSClientID.
Sprawdź HKLM\Software\Microsoft\Windows\CurrentVersion\WIndowsUpdate
i usuń bieżący SUSClientID
.
Uruchom wuauclt /resetauthorization /detectnow
z podwyższonego wiersza poleceń.
Następująca sekwencja wyczyści lokalną pamięć podręczną klienta Windows Update
Następująca sekwencja ponownie zarejestruje maszynę na serwerze WSUS:
Sprawdź serwer
Sprawdź wolne miejsce na dysku twardym, dla woluminu startowego i woluminu repozytorium.
Sprawdź usługę Windows UpdateGet-Service -name WsusService
Sprawdź usługę IISGet-Service -name W3SVC
Czy serwer nasłuchuje? Sprawdź otwarte porty.netstat -an | findstr 853*
Czy możesz przejść do
You should see a blue and tan Client Service info page.
If not, we can try resetting the port. Open an elevated command prompt and run wsusutil usecustomwebsite false
. Spowoduje to zmianę portu używanego przez WSUS z 8530 na 80, więc upewnij się, że nic nie jest uruchamiane na porcie 80.
Teraz uruchom wsusutil usecustomwebsite true
, a następnie iisreset /restart
. Zmienia to port z powrotem na 8530 i "resetuje" konfigurację.
Sprawdź reguły zapory.
Sprawdź logowanie po stronie serwera: c:\program files\updateservices\logfiles\SoftwareDistribution
Uruchom sfc /scannow
, aby sprawdzić uszkodzenie plików.
WSUSUtil.exe
-
wsusutil.exe reset
- Sprawdza, czy każdy wiersz metadanych aktualizacji w bazie danych ma odpowiadające mu pliki aktualizacji przechowywane w systemie plików. Jeśli brakuje plików aktualizacji lub zostały one uszkodzone, program WSUS ponownie pobiera pliki aktualizacji.
-
wsusutil.exe checkhealth
- Sprawdza dziennik zdarzeń aplikacji pod kątem wpisów ze źródłem „Windows Server Update Services”
-
wsusutil.exe usecustomwebsite
- Zmienia port używany przez program WSUS. Również „resetuje” port podczas zmiany.
IIS
Sprawdza błędy połączeń http w c:\windows\system32\logfiles\httperr\
Sprawdza wiązania IP.
Sprawdza, czy działa Application Pool.
Sprawdź logi IIS pod kątem błędów połączenia c:\inetpub\logs\logfiles
Domyślna instalacja IIS przez instalator WSUS nie instaluje jednak komponentu logowania.
Trzeba to włączyć pod Manage Computer > Roles > Web Server > Web Server > Health & Diag > HTTP Logging
I już. Jeśli zastosowanie się do tego przewodnika nie rozwiązało problemu, miejmy nadzieję, że przynajmniej natknąłeś się na wadliwie działający komponent i masz lepszy pomysł, na czym skupić swoje poszukiwania w Google.