6
Clients melden sich nicht bei WSUS
Guten Tag,
ich habe in einer unserer Umgebungen ein Problem mit der Einrichtung des WSUS.
WSUS wurde auf einem WIndows Server 2012R2 installiert.
WSUS via Gruppenrichtlinie als Quelle eingestellt. Ein paar weitere Windows Update Einstellungen wurden auch per Gruppenrichtlinie konfiguriert.
Die Clients (Windows 7 x64 Pro) melden sich seit sieben Tagen nicht beim WSUS an. Ich sehe nur drei Rechner, diese waren nach wenigen Stunden vorhanden.
Was könnte ich prüfen? Bin beim Thema WSUS nicht wirklich erfahren. In den anderen Umgebungen lief das ganze ohne größere Probleme.
Viele Grüße und ein schönes Wochenende!
ich habe in einer unserer Umgebungen ein Problem mit der Einrichtung des WSUS.
WSUS wurde auf einem WIndows Server 2012R2 installiert.
WSUS via Gruppenrichtlinie als Quelle eingestellt. Ein paar weitere Windows Update Einstellungen wurden auch per Gruppenrichtlinie konfiguriert.
Die Clients (Windows 7 x64 Pro) melden sich seit sieben Tagen nicht beim WSUS an. Ich sehe nur drei Rechner, diese waren nach wenigen Stunden vorhanden.
Was könnte ich prüfen? Bin beim Thema WSUS nicht wirklich erfahren. In den anderen Umgebungen lief das ganze ohne größere Probleme.
Viele Grüße und ein schönes Wochenende!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 266961
Url: https://administrator.de/contentid/266961
Ausgedruckt am: 22.11.2024 um 13:11 Uhr
6 Kommentare
Neuester Kommentar
Hallo,
Sollen die Clients sich tatsächlich beim WSUS melden oder nimmst du das nur an? GPO? Prüfen was denn nun ist,
Stammen die Clients aller aus "der"" Klonfabrik?
Was sagt ein Wireshark am Client wenn er versucht Updates zu machen?
Gruß,
Peter
Sollen die Clients sich tatsächlich beim WSUS melden oder nimmst du das nur an? GPO? Prüfen was denn nun ist,
Stammen die Clients aller aus "der"" Klonfabrik?
Was sagt ein Wireshark am Client wenn er versucht Updates zu machen?
Gruß,
Peter
Die Clients sollen Ihre Updates über den WSUS ziehen. Per GPO gelöst.
Nein, die Clients sind nicht geklont.
Wireshark werde ich mal prüfen! Danke!
Gruß,
Oz
Nein, die Clients sind nicht geklont.
Wireshark werde ich mal prüfen! Danke!
Gruß,
Oz
Hallo,
SOLLEN, tun diese das aber auch, das solltest du prüfen, und das du die per GPO vermeintlich meinst zu betanken ist wohl auch nur eine Annahme. Prüfe die Clients was die tatsächlich tun bzw. wo deine GPO Einstellungen evtl. geblieben sind. Auch ein blick in den Clientlogs sagt dir was die tun
( %WinDir%\WindowsUpdate.log ). Und eine Beispiel reg findest du hier http://www.wsus.de/wsusreg
http://www.wsus.de
Gruß,
Peter
SOLLEN, tun diese das aber auch, das solltest du prüfen, und das du die per GPO vermeintlich meinst zu betanken ist wohl auch nur eine Annahme. Prüfe die Clients was die tatsächlich tun bzw. wo deine GPO Einstellungen evtl. geblieben sind. Auch ein blick in den Clientlogs sagt dir was die tun
( %WinDir%\WindowsUpdate.log ). Und eine Beispiel reg findest du hier http://www.wsus.de/wsusreg
http://www.wsus.de
Gruß,
Peter
Moin,
Hast du mit rsop.msc geprüft, ob die Gruppenrichtlinie angewendet wird? Die Ereignisanzeige spricht normal Bände.
Gruß,
Dani
WSUS via Gruppenrichtlinie als Quelle eingestellt. Ein paar weitere Windows Update Einstellungen wurden auch per Gruppenrichtlinie konfiguriert.
Und welche Einstellungen hast du in der Gruppenrichtlinie konfiguriert? Nein, die Clients sind nicht geklont.
Wie hast du das überprüft? Ich würde sicherheitshalber die IDs überall löschen und ein gpupate /force ausführen.Hast du mit rsop.msc geprüft, ob die Gruppenrichtlinie angewendet wird? Die Ereignisanzeige spricht normal Bände.
Gruß,
Dani
Hi,
die ganze Sache hört sich für mich nach einem DNS-Problem seitens der betroffenen Client-PCs an.
Dabei ist es unwichtig, ob die betroffenen Client-PCs Mitglieder der lokalen Domäne sind oder der WSUS-Server ein oder kein Mitglied der lokalen Domäne ist.
1. Melde dich mit einem AD-User-Account (kein Admin-Account) an einem der betroffenden Client-PC an.
2. Öffne dort eine Eingabeauffordung und pinge den WSUS-Server ("die Quelle") über seinen Computernamen an (z.B. ping wsus).
3. Falls nicht erreichbar oder nur über eine verbindungslokale IPv6 Adresse (fe80::.....) erreichbar, liegt ein DNS-Problem mit IPv4 vor.
3.1 Lösung 1: Ändere die Einstellungen in der zuständigen GPO: als "Quelle" nicht den Computernamen des WSUS-Servers eintragen, sondern seine aktuelle IP (z.B.: http://192.168.1.123).
3.2 Lösung 2: Ändere die Einstellungen in der zuständigen GPO: als "Quelle" nicht den Computernamen des WSUS-Servers eintragen, sondern seine aktuelle IP inkl. Portangabe (z.B. http://192.168.1.123:8530)
4. Starte den betroffenden Client-PC neu, damit die die geänderte GPO neu angewendet wird (gpupdate /force ist hier nicht effektiv genug).
5. Öffne auf dem betroffenden PC eine Eingabeaufforderung.
6. wuauclt.exe /detectnow /reauthorization
7. Innerhalb von ca. 3 Minuten meldet sich der Client-PC beim WSUS-Server.
8. Sollte der Client-PC nicht umgehend (innerhalb von 10 Minuten) einen Report an den WSUS-Server senden, führe Punkt 5. mit
wuauclt.exe /reportnow aus.
greetings
Bourness
die ganze Sache hört sich für mich nach einem DNS-Problem seitens der betroffenen Client-PCs an.
Dabei ist es unwichtig, ob die betroffenen Client-PCs Mitglieder der lokalen Domäne sind oder der WSUS-Server ein oder kein Mitglied der lokalen Domäne ist.
1. Melde dich mit einem AD-User-Account (kein Admin-Account) an einem der betroffenden Client-PC an.
2. Öffne dort eine Eingabeauffordung und pinge den WSUS-Server ("die Quelle") über seinen Computernamen an (z.B. ping wsus).
3. Falls nicht erreichbar oder nur über eine verbindungslokale IPv6 Adresse (fe80::.....) erreichbar, liegt ein DNS-Problem mit IPv4 vor.
3.1 Lösung 1: Ändere die Einstellungen in der zuständigen GPO: als "Quelle" nicht den Computernamen des WSUS-Servers eintragen, sondern seine aktuelle IP (z.B.: http://192.168.1.123).
3.2 Lösung 2: Ändere die Einstellungen in der zuständigen GPO: als "Quelle" nicht den Computernamen des WSUS-Servers eintragen, sondern seine aktuelle IP inkl. Portangabe (z.B. http://192.168.1.123:8530)
4. Starte den betroffenden Client-PC neu, damit die die geänderte GPO neu angewendet wird (gpupdate /force ist hier nicht effektiv genug).
5. Öffne auf dem betroffenden PC eine Eingabeaufforderung.
6. wuauclt.exe /detectnow /reauthorization
7. Innerhalb von ca. 3 Minuten meldet sich der Client-PC beim WSUS-Server.
8. Sollte der Client-PC nicht umgehend (innerhalb von 10 Minuten) einen Report an den WSUS-Server senden, führe Punkt 5. mit
wuauclt.exe /reportnow aus.
greetings
Bourness
@bourness:
Hatte das Problem auch nachdem ich den alten WSUS durch einen 2016er ablösen wollte. Die Clients haben sich einfach nicht gemeldet beim neuen WSUS. DNS sieht eigentlich gut aus. Der Eintrag ist drinnen und der ping auf den Namen klappt auch. Ich habe jetzt nicht ausprobiert, ob es gereicht hätte http://Hostname:8530
Habe es nämlich ohne Port eingetragen in der GPO und das wurde auch korrekt verteilt. Hat man mit rsop.msc super sehen können. Das war vorher zumindest ohne Port eingetragen und hat geklappt. Naja jetzt habe ich einfach wie du beschrieben hast die IP mit Port eingetragen und dann hats sofort geklappt.
Vielen Dank für deine Ausführliche Problemlösung.
Hatte das Problem auch nachdem ich den alten WSUS durch einen 2016er ablösen wollte. Die Clients haben sich einfach nicht gemeldet beim neuen WSUS. DNS sieht eigentlich gut aus. Der Eintrag ist drinnen und der ping auf den Namen klappt auch. Ich habe jetzt nicht ausprobiert, ob es gereicht hätte http://Hostname:8530
Habe es nämlich ohne Port eingetragen in der GPO und das wurde auch korrekt verteilt. Hat man mit rsop.msc super sehen können. Das war vorher zumindest ohne Port eingetragen und hat geklappt. Naja jetzt habe ich einfach wie du beschrieben hast die IP mit Port eingetragen und dann hats sofort geklappt.
Vielen Dank für deine Ausführliche Problemlösung.
