Server findet nach Umstellung auf einen neuen WSUS den Server nicht mehr

[Thomas811 0]

vor 7 Minuten schrieb Sunny61:

OK, und jetzt gibt es nur noch das Problem mit dieser Fehlermeldung? 0x8024401c Richtig?

Ja, die Fehlermeldung beschäftigt mich jetzt noch und dass er im WSUS seinen Statusbericht nicht übermittelt! 

Aber das hängt ja vermutlich zusammen! 

[zahni 554]

Der WSUS lädt Updates immer (noch) per HTTP herunter, auch wenn die Kommunikation per HTTPS erfolgt.

Was steht denn genau in der WSUS-GPO, bitte alle Parameter. Beispiel:

 

Zitat

Interner Updatedienst zum Ermitteln von Updates: https://wsus-server:8531 
Intranetserver für die Statistik: https://wsus-server:8531 
Alternativen Downloadserver festlegen: http://wsus-server:8530 
 

 

[Thomas811 0]

vor 2 Stunden schrieb zahni:

Der WSUS lädt Updates immer (noch) per HTTP herunter, auch wenn die Kommunikation per HTTPS erfolgt.

Was steht denn genau in der WSUS-GPO, bitte alle Parameter. Beispiel:

 

 

Ich habe den alternativen Downloadserver frei gelassen und auch zum Testen hinzugefügt und alles noch auf http:

Interner Updatedienst zum Ermitteln von Updates: http://sv-cti:8530 
Intranetserver für die Statistik: http://sv-cti:8530 
Alternativen Downloadserver festlegen: http://sv-cti:8530 

 

Daran liegt es denk ich nicht, da alle Clients bis auf diesen einen Windows 2016 Server ihre Updates ziehen und installieren.

 

1 Sache die ich heute erst erfahren habe! Dieser SV-CTI der mir Probleme macht war vorher ein 2012 und wurde auf 2016 mit einem Upgrade hoch gezogen. (Ich habe die IT-Landschaft so übernommen!) Ob das der Zeitpunkt der Probleme ist kann ich leider nicht sagen!  Er meldet sich ja mit der neuen GPO am WSUS und ich kann ihn einordnen, jedoch meldet er keinen Bericht zurück an den WSUS und bei den Updates kommt der besagte Fehler 0x8024401c.

 

Online Suche nach Updates funktioniert und kann auch aktualisiert werden. 

bearbeitet 10. September von Thomas811

[tesso 375]

0x8024401c
# for hex 0x8024401c / decimal -2145107940
  WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT                            wuerror.h
# Same as HTTP status 408 - the server timed out waiting for
# the request.
# 1 matches found for "0x8024401c"

C:\Users\tesso\Downloads>

[daabm 1.356]

vor 14 Minuten schrieb tesso:

C:\Users\tesso\Downloads>

 

err.exe schmeiß ich auf allen Systemen nach Sytem32

[Sunny61 806]

vor 54 Minuten schrieb Thomas811:

Ich habe den alternativen Downloadserver frei gelassen und auch zum Testen hinzugefügt und alles noch auf http:

Interner Updatedienst zum Ermitteln von Updates: https://sv-cti:8530 
Intranetserver für die Statistik: https://sv-cti:8530 
Alternativen Downloadserver festlegen: https://sv-cti:8530 

 

Daran liegt es denk ich nicht, da alle Clients bis auf diesen einen Windows 2016 Server ihre Updates ziehen und installieren.

Zahni schrieb dass du bitte *ALLE* Parameter angeben sollst. Du fragst hier und möchtest Hilfe, bitte beantworte auch die Fragen so gut es geht ansonsten wird es schwierig bis unmöglich dir zu helfen.

 

Deaktiviere DualScan https://www.escde.net/blog/windows-update-richtlinien-und-dual-scan und trag auch als Alternativen Downloadserver deinen WSUS ein. Das kannst du jetzt einfach mal manuell in die Registry von dem Server eintragen. Wenn das eingetragen ist, dann nochmal %windir%\SoftwareDistribution leeren und den Server neu starten. Jetzt in einer Admin Commandline ein

wuauclt /resetauthorization /detectnow

ausführen und nach 2 Minuten Wartezeit ein

wuauclt /reportnow

nachschicken.

 

Sind die restlichen Server auch alle 2016 oder jünger? Ob es da mal ein InplaceUpgrade gegeben hat, ist IMHO egal, ein paar von unseren alten 2016er sind via Inplaceupgrade aktualisiert worden und haben nie Probleme mit dem WSUS gehabt.

 

Ein saubere Neuinstallation des betroffenen Server ist keine Option?

bearbeitet 10. September von Sunny61

[NorbertFe 2.045]

vor einer Stunde schrieb Thomas811:

Ich habe den alternativen Downloadserver frei gelassen und auch zum Testen hinzugefügt und alles noch auf http:

Interner Updatedienst zum Ermitteln von Updates: https://sv-cti:8530 
Intranetserver für die Statistik: https://sv-cti:8530 
Alternativen Downloadserver festlegen: https://sv-cti:8530 

https: ist beim WSUS auf Port 8531. Heißt, so wird es sicherlich nicht funktionieren. Und im Zertifikat steht üblicherweise auch nicht nur der kurze Name, sondern der komplette FQDN.

 

Bye

Norbert

[zahni 554]

Bei und stehen beide Namen in Zertifikat 😏

[NorbertFe 2.045]

Und was sagt der Security Fuzzi dazu? ;)

[zahni 554]

vor 14 Stunden schrieb NorbertFe:

Und was sagt der Security Fuzzi dazu? ;)

Wieso? Darf man das beim SAN-Attribut DNS nicht mehr reinschreiben?

[NorbertFe 2.045]

Kurze Namen sind halt ein (wie auch immer gewichtetes) Sicherheitsrisiko. Denn im Zweifel kann ja jeder ein Zertifikat auf wsus ausstellen. (Ist halt bei einer internen CA ggf. ein eher hypothetisches Problem, aber ich bin da halt lieber auf Standardlinie und die ist nun mal, dass FQDN in ein Zertifikat gehören).

[zahni 554]

Das halte ich für sehr hypothetisch. 1. Ist der Common-Name  natürlich mit dem  FQDN ausgestellt, sonst geht es eher nicht und 2. sind es interne Systeme. Das funktioniert nur, wenn der Client den DNS-Suffix kennt. Wie sollte "jemand" nun ein Zertifikat ausstellen? 1. müsste er es mit einer Public CA machen. Da geht sowas nicht. Und mit einer internen CA müsste er dem WSUS sein Server-Zertifikat unterschieben und dem Client sein Root-Zertifikat. Da habe ich in beiden Fällen was dagegen.

 

[NorbertFe 2.045]

vor 2 Stunden schrieb zahni:

Das halte ich für sehr hypothetisch.

 

vor 2 Stunden schrieb NorbertFe:

Kurze Namen sind halt ein (wie auch immer gewichtetes) Sicherheitsrisiko.

Sag ich ja. :) Aber... ich empfehle eben lange Namen zu benutzen damit sich die Nutzer daran gewöhnen mehr als den Hostnamen zu verwenden. Aber offenbar will ja jeder nur noch $irgendwas in die Searchbar eingeben und erwartet dann wie selbstverständlich, dass er am richtigen Server landet. ;)

[daabm 1.356]

vor 5 Stunden schrieb zahni:

1. Ist der Common-Name  natürlich mit dem  FQDN ausgestellt

 

Sobald ein SAN drinsteht, ist der CN egal und wird ignoriert. Irgendwo mal aufgeschnappt, scheint aber zu stimmen nach unseren Erfahrungen mit LDAPS

[NorbertFe 2.045]

vor 5 Minuten schrieb daabm:

Sobald ein SAN drinsteht, ist der CN egal und wird ignoriert

Kommt aber auf den client an. Ich meine mich zu erinnern, dass der CN zwingend als SAN mit drin stehen muss und zweitens hatte ich neulich grad den Fall, dass ein Zertifikat Ohne CN vom Client gar nicht akzeptiert wurde. (Komischerweise hat die Kerberos Vorlage der Windows CA keinen CN).