13
WSUS - Probleme nach Installation mit Clients und Serverknoten
Hallo in die Runde,
habe ein kleines Problem (hoffe ich zumindest) und eventuell kennt ja jemand dazu die Lösung
Folgendes Szenario:
Zwei Server jeweils Windows Server 2012 R2
Ein Server ist Domänencontroller unter Windows Server 2012
Auf einem der zwei Server wurde nach Installation die Rolle WSUS hinzugefügt und eingerichtet.
Der zweite Server als Client nurmal installiert und in die Domäne eingebunden.
Auf dem Domänencontroller wurde eine GPO eingerichtet (GPO_WSUS) die für den Client gelten soll.
Im Anschluß an die Installation wurde ein SSL-Zertifikat über IIS erstellt und der Bindung als https auf 8531 hinzugefügt.
Gleichzeitig die empfohlenen Verzeichnisse für SSL-Zertifikat erforderlich ergänzt.
In der GPO wurde dann die Adresse auf https://wsus:8531 geändert
Auf Domänencontroller und Client die GPO mittels gpupdate /force aktualisiert.
Auf dem Client zusätzlich noch /detectnow ausgeführt.
Am WSUS-Server die Konsole gestartet und einen Fehler erhalten, das der Serverknoten nicht gestartet werden kann - greift weiterhin auf den hhtp 8530 zu, manuelle Änderung auf 8531 und der Knoten funkioniert.
Die Computergruppe erweitert, kein PC drin, auf Suchen gegangen, kein PC angezeigt.
- Neustart von Client und WSUS-Server
Gleiches Ergebnis.
Damit hab ich aktuell zwei Probleme:
1) Wird die WSUS-Konsole geöffnet muss ich ständig den Server manuell nachtragen
2) Der Client will sich einfach nicht am WSUS-Server anmelden
Keine Ahnung an was es liegen könnte, oder hab ich irgendetwas entscheidendes übersehen?
Grüße
Forseti
habe ein kleines Problem (hoffe ich zumindest) und eventuell kennt ja jemand dazu die Lösung
Folgendes Szenario:
Zwei Server jeweils Windows Server 2012 R2
Ein Server ist Domänencontroller unter Windows Server 2012
Auf einem der zwei Server wurde nach Installation die Rolle WSUS hinzugefügt und eingerichtet.
Der zweite Server als Client nurmal installiert und in die Domäne eingebunden.
Auf dem Domänencontroller wurde eine GPO eingerichtet (GPO_WSUS) die für den Client gelten soll.
Im Anschluß an die Installation wurde ein SSL-Zertifikat über IIS erstellt und der Bindung als https auf 8531 hinzugefügt.
Gleichzeitig die empfohlenen Verzeichnisse für SSL-Zertifikat erforderlich ergänzt.
In der GPO wurde dann die Adresse auf https://wsus:8531 geändert
Auf Domänencontroller und Client die GPO mittels gpupdate /force aktualisiert.
Auf dem Client zusätzlich noch /detectnow ausgeführt.
Am WSUS-Server die Konsole gestartet und einen Fehler erhalten, das der Serverknoten nicht gestartet werden kann - greift weiterhin auf den hhtp 8530 zu, manuelle Änderung auf 8531 und der Knoten funkioniert.
Die Computergruppe erweitert, kein PC drin, auf Suchen gegangen, kein PC angezeigt.
- Neustart von Client und WSUS-Server
Gleiches Ergebnis.
Damit hab ich aktuell zwei Probleme:
1) Wird die WSUS-Konsole geöffnet muss ich ständig den Server manuell nachtragen
2) Der Client will sich einfach nicht am WSUS-Server anmelden
Keine Ahnung an was es liegen könnte, oder hab ich irgendetwas entscheidendes übersehen?
Grüße
Forseti
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: 238753
Url: https://administrator.de/contentid/238753
Ausgedruckt am: 25.11.2024 um 12:11 Uhr
13 Kommentare
Neuester Kommentar
Hey,
da ich auch gerade mit GPOs gekämpft habe kann ich dir folgenden Hinweis geben:
am betroffenen Rechner rsop.msc ausführen, er zeigt dir dann welche Einstellungen er sich zieht.
cmd --> gpresult /r zeigt dir welche Richtlinien er verarbeitet.
musst also nur noch checken wo in rsop die einstellung für 8530 liegt, dann checkste welche Richtlinien er sich zieht (gpresult) und kuckst im Richtlinieneditor (server) alle betroffenen Richtlinien durch und navigierst zu der Stelle welche in der RSOP 8530 anzeigt.
viel erfolg
da ich auch gerade mit GPOs gekämpft habe kann ich dir folgenden Hinweis geben:
am betroffenen Rechner rsop.msc ausführen, er zeigt dir dann welche Einstellungen er sich zieht.
cmd --> gpresult /r zeigt dir welche Richtlinien er verarbeitet.
musst also nur noch checken wo in rsop die einstellung für 8530 liegt, dann checkste welche Richtlinien er sich zieht (gpresult) und kuckst im Richtlinieneditor (server) alle betroffenen Richtlinien durch und navigierst zu der Stelle welche in der RSOP 8530 anzeigt.
viel erfolg
Im Anschluß an die Installation wurde ein SSL-Zertifikat über IIS erstellt und der Bindung als https auf 8531 hinzugefügt.
Bevor du @cse Rat folgst, würde ich auf SSL verzichten und Step-by-Step den Fehler suchen.Gleichzeitig die empfohlenen Verzeichnisse für SSL-Zertifikat erforderlich ergänzt.
Wo hast du diese Empfehlungen her? Ist das Zertifikat ein internes von deiner CA oder gekauft?In der GPO wurde dann die Adresse auf https://wsus:8531 geändert
Kannst du am Client den Rechnernamen "wsus" überhaupt auflösen (Eingabeaufforderung -> nslookup wsus". Das ist die Basis. Ohne die funktioniert der Rest auch nicht.Grüße,
Dani
Hallo,
nicht https://wsus:port verwenden sondern bitte den FQDN. Warscheinlich vertrauen die Clients dem WSUS nicht da der Zertifikat nicht auf WSUS lautet sondern auf wsus.domain.tld
Grüße
nicht https://wsus:port verwenden sondern bitte den FQDN. Warscheinlich vertrauen die Clients dem WSUS nicht da der Zertifikat nicht auf WSUS lautet sondern auf wsus.domain.tld
Grüße
Okay, das hat mir schonmal ein Stück weitergeholfen, hätte ich auch selbst draufkommen können. Ergebnis von gpresult war, das der Client die GPO gar nicht zieht, Fehler hierbei war ganz simpel - die GPO war in der falschen Struktur verlinkt, hab diese nun höher gesetzt, direkt in das Root der Domäne und der Client sieht und zieht die Richtlinie jetzt.
Dummerweise sieht der WSUS-Server den Client weiterhin nicht.
Dummerweise sieht der WSUS-Server den Client weiterhin nicht.
Das wäre der nächste Schritt, wenn alles andere nicht weiterführt, würde aber vorerst mit SSL noch probieren.
Die Empfehlungen für die Verzeichnisse stammt aus der Hilfeseite von Microsoft, nach der Installation von WSUS kann man einen Link zu verschiedenen Themen auswählen, einer ist die Einrichtung von WSUS mit SSL-Zertifikaten.
Das Zertifikat wurde über die interne CA erstellt - Domänenzertifikat.
Dasu auflösen des Rechnernamens klappt wunderbar, daran liegt das Problem nicht.
Die Empfehlungen für die Verzeichnisse stammt aus der Hilfeseite von Microsoft, nach der Installation von WSUS kann man einen Link zu verschiedenen Themen auswählen, einer ist die Einrichtung von WSUS mit SSL-Zertifikaten.
Das Zertifikat wurde über die interne CA erstellt - Domänenzertifikat.
Dasu auflösen des Rechnernamens klappt wunderbar, daran liegt das Problem nicht.
Zitat von @lenny4me:
Hallo,
nicht https://wsus:port verwenden sondern bitte den FQDN. Warscheinlich vertrauen die Clients dem WSUS nicht da der Zertifikat
nicht auf WSUS lautet sondern auf wsus.domain.tld
Grüße
Hallo,
nicht https://wsus:port verwenden sondern bitte den FQDN. Warscheinlich vertrauen die Clients dem WSUS nicht da der Zertifikat
nicht auf WSUS lautet sondern auf wsus.domain.tld
Grüße
Hab ich jetzt auf FQDN geändert, gleiches Ergebnis.
Hallo,
die Aussage ist technisch falsch. Der Client sieht den WSUS nicht umgekehrt.
Der Client repored ja zum WSUS... aber das ist Erbsenglauberei.
Was sagt die Windowsupdatelog auf dem Client?
Grüße
Dummerweise sieht der WSUS-Server den Client weiterhin nicht.
die Aussage ist technisch falsch. Der Client sieht den WSUS nicht umgekehrt.
Der Client repored ja zum WSUS... aber das ist Erbsenglauberei.
Was sagt die Windowsupdatelog auf dem Client?
Grüße
Das Zertifikat wurde über die interne CA erstellt - Domänenzertifikat.
Dasu auflösen des Rechnernamens klappt wunderbar, daran liegt das Problem nicht.
D.h. Rechnername (DNS) stimmt mit Zertifikatsnamen überein?Dasu auflösen des Rechnernamens klappt wunderbar, daran liegt das Problem nicht.
Die Clients vertrauen den Zertifikat auch (z.B. https://wsus.abc.local) funktioniert ohne Warnung?
Das wäre der nächste Schritt, wenn alles andere nicht weiterführt, würde aber vorerst mit SSL noch probieren.
Kein Ding... ist nicht meine Arbeitszeit. Grüße,
Dani
Zitat von @lenny4me:
Hallo,
>Dummerweise sieht der WSUS-Server den Client weiterhin nicht.
die Aussage ist technisch falsch. Der Client sieht den WSUS nicht umgekehrt.
Der Client repored ja zum WSUS... aber das ist Erbsenglauberei.
Was sagt die Windowsupdatelog auf dem Client?
Grüße
Hallo,
>Dummerweise sieht der WSUS-Server den Client weiterhin nicht.
die Aussage ist technisch falsch. Der Client sieht den WSUS nicht umgekehrt.
Der Client repored ja zum WSUS... aber das ist Erbsenglauberei.
Was sagt die Windowsupdatelog auf dem Client?
Grüße
Hab jetzt mal die GPO auf den normalen Pfad umgelegt, also http: und Port 8530 - brachte aber erstmal auch kein Ergebnis, wenn ich SSL ignoriere.
Aber, nachdem ich den Client neugestartet habe, da plötzlich meldete er sich am WSUS an.
Ich lass jetzt erstmal das SSL aussen vor, für den WSUS-Server sollte das ja nicht wirklich primär wichtig sein und heute abend starte ich dann mal alle Server die aufgenommen werden sollen neu, dann könnte das ganze funktionieren
Danke für Eure Hilfen.
heute abend starte ich dann mal alle Server die aufgenommen werden sollen neu, dann könnte das ganze funktionieren
Den Neustart kannst du dir sparen, einfach folgendes Skript ausführen und danach nach Updates suchen lassen. @echo off
net stop wuauserv
if exist "%windir%\SoftwareDistribution" rmdir /S /Q "%windir%\SoftwareDistribution"
pauseGrüße,
Dani
Den Neustart kannst du dir sparen, einfach folgendes Skript ausführen und danach nach Updates suchen lassen
Wenn er an den GPOs gedreht hat ist ein Neustart der Clients vielleicht wirklich keine schlechte Idee.
... mich würde trotzdem interessieren was im Windowsupdatelog des Clients steht
Zitat von @Dani:
> heute abend starte ich dann mal alle Server die aufgenommen werden sollen neu, dann könnte das ganze funktionieren
Den Neustart kannst du dir sparen, einfach folgendes Skript ausführen und danach nach Updates suchen lassen.
Grüße,
Dani
> heute abend starte ich dann mal alle Server die aufgenommen werden sollen neu, dann könnte das ganze funktionieren
Den Neustart kannst du dir sparen, einfach folgendes Skript ausführen und danach nach Updates suchen lassen.
> @echo off
> net stop wuauserv
> if exist "%windir%\SoftwareDistribution" rmdir /S /Q "%windir%\SoftwareDistribution"
>
> pause
> Grüße,
Dani
Das funktioniert leider nicht, die weiteren Server hab ich ja erst der Sicherheitsgruppe zugewiesen, insofern können die dann noch nicht die GPO laden, da sie aktuell nicht wissen, das sie dieser Gruppe zugehörig sind und somit lehnen sie die GPO ab.
Daher wollte ich den Neustart durchführen, damit die Gruppe und die GPO gleich da ist. Außer ich kann die Sicherheitsgruppe ohne Neustart einlesen, da wüsste ich aber nicht wie das geht.
Zitat von @lenny4me:
> Den Neustart kannst du dir sparen, einfach folgendes Skript ausführen und danach nach Updates suchen lassen
Wenn er an den GPOs gedreht hat ist ein Neustart der Clients vielleicht wirklich keine schlechte Idee.
... mich würde trotzdem interessieren was im Windowsupdatelog des Clients steht
> Den Neustart kannst du dir sparen, einfach folgendes Skript ausführen und danach nach Updates suchen lassen
Wenn er an den GPOs gedreht hat ist ein Neustart der Clients vielleicht wirklich keine schlechte Idee.
... mich würde trotzdem interessieren was im Windowsupdatelog des Clients steht
Okay, das mit den Log's ist kein Problem:
bis zu dem Zeitpunkt wo es nicht funktioniert hat sind folgende Einträge vorhanden:
Fehler Uhrzeit 10:05:09 WindowsUpdateClient Ereignis-ID 25 Windows Update-Agent - Fehler bei der Suche nach Updates: 0x80248014
Fehler Uhrzeit 13:20:28 WindowsUpdateClient Ereignis-ID 25 Windows Update-Agent - Fehler bei der Sucha nach Updates: 0x80072F8f
Fehler Uhrzeit 13:30:21 WindowsUpdateClient Ereignis-ID 25 Windows Update-Agent - Fehler bei der Suche nach Updates: 0x800B010F
dieser Fehler wiederholt sich dann noch um 13:34 - ab da läuft es dann und es kommen keine Fehler mehr.
die letzten beiden Fehler würden auf das SSL-Zertifikat als Verursacher verweisen, die beiden davor keine Ahnung.
