141427
Oct 08, 2019
2664
5
0
Problem bei WSUS-Update Verteilung in virtueller Hyper-V Testumgebung
Guten Tag,
meine virtuelle Testumgebung besteht aus:
1x Win SRV 2016 (2 NICs)
1x Win 10 1903
1x Win 7 Pro
Der SRV hängt am Default Hyper-V Switch (Zugang zum Internet über Host-PC) & an einem virtuellen privaten Switch.
Die beiden Rechner hängen nur am privaten Switch.
Auf dem SRV ist die WSUS-Rolle installiert (und alles läuft soweit flüssig), die Clients wurden mit einem Registry-Eintrag konfiguriert.
Dazu siehe:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="192.168.2.2:8530"
"WUStatusServer"="192.168.2.2:8530"
"ElevateNonAdmins"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"AUOptions"=dword:00000004
"UseWUServer"=dword:00000001
"NoAutoUpdate"=dword:00000000
"AutoInstallMinorUpdates"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000a
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduledWaitTime"=dword:00000003
"RebootRelaunchTimeoutEnabled"=dword:00000001
Nun möchte ich Updates über meinen Server von Microsoft herunterladen lassen und diese dann an die beiden Rechner verteilen.
Es werden auch Updates gefunden, bloß können die beiden PCs diese nicht von SRV 16 abrufen und ich bekomme die Fehlermeldung:"Wir konnten keine Verbindung mit dem Updatedienst herstellen. Wir versuchen es später erneut. Alternativ können Sie es jetzt versuchen. Überprüfen Sie Ihre Internetverbindung, falls es immer noch nicht funktioniert."
Ich habe in den Update-Logs von meinem Win 10 geschaut und dort ist zu sehen, dass nicht einmal eine Verbindung zum SRV hergestellt wird.
An den Firewalls kann es auch nicht liegen, die sind deaktiviert.
Ist es möglich, dass es daran liegt, dass die beiden "normalen" Rechner keinen Zugang zum externen Netz haben, sprich Internet?
Hat jemand eine Idee, wie man das beheben könnte?
meine virtuelle Testumgebung besteht aus:
1x Win SRV 2016 (2 NICs)
1x Win 10 1903
1x Win 7 Pro
Der SRV hängt am Default Hyper-V Switch (Zugang zum Internet über Host-PC) & an einem virtuellen privaten Switch.
Die beiden Rechner hängen nur am privaten Switch.
Auf dem SRV ist die WSUS-Rolle installiert (und alles läuft soweit flüssig), die Clients wurden mit einem Registry-Eintrag konfiguriert.
Dazu siehe:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]
"WUServer"="192.168.2.2:8530"
"WUStatusServer"="192.168.2.2:8530"
"ElevateNonAdmins"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU]
"AUOptions"=dword:00000004
"UseWUServer"=dword:00000001
"NoAutoUpdate"=dword:00000000
"AutoInstallMinorUpdates"=dword:00000001
"NoAutoRebootWithLoggedOnUsers"=dword:00000001
"ScheduledInstallDay"=dword:00000000
"ScheduledInstallTime"=dword:0000000a
"RescheduleWaitTimeEnabled"=dword:00000001
"RescheduledWaitTime"=dword:00000003
"RebootRelaunchTimeoutEnabled"=dword:00000001
Nun möchte ich Updates über meinen Server von Microsoft herunterladen lassen und diese dann an die beiden Rechner verteilen.
Es werden auch Updates gefunden, bloß können die beiden PCs diese nicht von SRV 16 abrufen und ich bekomme die Fehlermeldung:"Wir konnten keine Verbindung mit dem Updatedienst herstellen. Wir versuchen es später erneut. Alternativ können Sie es jetzt versuchen. Überprüfen Sie Ihre Internetverbindung, falls es immer noch nicht funktioniert."
Ich habe in den Update-Logs von meinem Win 10 geschaut und dort ist zu sehen, dass nicht einmal eine Verbindung zum SRV hergestellt wird.
An den Firewalls kann es auch nicht liegen, die sind deaktiviert.
Ist es möglich, dass es daran liegt, dass die beiden "normalen" Rechner keinen Zugang zum externen Netz haben, sprich Internet?
Hat jemand eine Idee, wie man das beheben könnte?
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 502242
Url: https://administrator.de/contentid/502242
Printed on: April 26, 2024 at 00:04 o'clock
5 Comments
Latest comment
Wsus dient nur als Cache. Die Updateliste holt sich jeder Client direkt im Internet. Diese wird dann dem Wsus als „erforderliches Update“ mitgeteilt.
Moin,
das sieht mir nach der altbekannten DualScan-Problematik aus. Hast du per GPO "Zugriff auf alle Windows-Update Funktionen deaktivieren" gesetzt?
Dann könnte es sein, das auf dem Client noch DualScan aktiviert ist. Windows versucht dann am WSUS vorbei aus dem Internet Updates zu ziehen, was aber per GPO verboten wird. Dann taucht der von dir beschrieben Fehler auf.
Vielleicht hilft das weiter: windowspro.de - Windows Update for Business und WSUS parallel nutzen
Gruß NV
das sieht mir nach der altbekannten DualScan-Problematik aus. Hast du per GPO "Zugriff auf alle Windows-Update Funktionen deaktivieren" gesetzt?
Dann könnte es sein, das auf dem Client noch DualScan aktiviert ist. Windows versucht dann am WSUS vorbei aus dem Internet Updates zu ziehen, was aber per GPO verboten wird. Dann taucht der von dir beschrieben Fehler auf.
Vielleicht hilft das weiter: windowspro.de - Windows Update for Business und WSUS parallel nutzen
Gruß NV
NordicMice
Also ersteinmal: Danke für den Hinweis. Ich wusste noch nicht, dass WSUS nur als Cache dient.
Ich habe jetzt meinen beiden Rechner (Win 10 + Win 7) eine zweite NIC eingebaut und diese hängt am Default Switch, hat also Internetzugang. Beim Win 10 konnte ich nach Updates suchen, bin mir aber nicht sicher, woher er sich die Updates geholt hat, da auf dem Server in der WSUS-Konsole noch keine Einträge zu verbundenen PCs angezeigt werden.
Nach einem Neustart, wollte ich erneut nach Updates suchen (testweise) - ich bekam den selben Fehler wie in dem Ausgangsproblem ("Wir konnten keine Verbindung mit dem Updatedienst herstellen..........."). Vor der Suche hätte ich unter "Updates suchen" auch "online nach Updates suchen" wählen können, was ich ja aber nicht möchte.
Mein Win 7 gibt immer noch denselben Fehler (Code 80072EE6) aus.
Nixverstehen:
Ich habe mir den Artikel durchgelesen und diese Problematik verstanden.
Leider ist bei mir in den GPOs beim Win 10 diese Einstellung "Zugriff auf alle Windows-Update Funktionen deaktivieren" garnicht zu finden, weswegen ich dies nicht testen konnte.
Also ersteinmal: Danke für den Hinweis. Ich wusste noch nicht, dass WSUS nur als Cache dient.
Ich habe jetzt meinen beiden Rechner (Win 10 + Win 7) eine zweite NIC eingebaut und diese hängt am Default Switch, hat also Internetzugang. Beim Win 10 konnte ich nach Updates suchen, bin mir aber nicht sicher, woher er sich die Updates geholt hat, da auf dem Server in der WSUS-Konsole noch keine Einträge zu verbundenen PCs angezeigt werden.
Nach einem Neustart, wollte ich erneut nach Updates suchen (testweise) - ich bekam den selben Fehler wie in dem Ausgangsproblem ("Wir konnten keine Verbindung mit dem Updatedienst herstellen..........."). Vor der Suche hätte ich unter "Updates suchen" auch "online nach Updates suchen" wählen können, was ich ja aber nicht möchte.
Mein Win 7 gibt immer noch denselben Fehler (Code 80072EE6) aus.
Nixverstehen:
Ich habe mir den Artikel durchgelesen und diese Problematik verstanden.
Leider ist bei mir in den GPOs beim Win 10 diese Einstellung "Zugriff auf alle Windows-Update Funktionen deaktivieren" garnicht zu finden, weswegen ich dies nicht testen konnte.
Hallo Breno,
ist denn der Server der Domänencontroller bzw. nutzt du überhaupt eine Domäne? Falls ja, hast du die GPO für die Nutzung des WSUS erstellt und greift die GPO auf den Clients auch?
Mach mal bitte auf einem Client eine Powershell auf und führe diesen Inhalt aus:
Dann am besten das Ergebnis als Screenshot posten.
Edit: Hast du das schon geprüft -> Microsoft - 80072EE6 error code
Gruß NV
ist denn der Server der Domänencontroller bzw. nutzt du überhaupt eine Domäne? Falls ja, hast du die GPO für die Nutzung des WSUS erstellt und greift die GPO auf den Clients auch?
Mach mal bitte auf einem Client eine Powershell auf und führe diesen Inhalt aus:
$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager"
$MUSM.Services | select Name, IsDefaultAUServiceDann am besten das Ergebnis als Screenshot posten.
Edit: Hast du das schon geprüft -> Microsoft - 80072EE6 error code
Gruß NV
Guten Morgen,
in der Testumgebung befindet sich kein Domänencontroller.
PowerShell-Ausgabe:
- bei Win7:
- bei Win10:
Den Artikel von Microsoft hab ich mir angeschaut, hatte allerdings Probleme beim Anwenden/Testen der Lösung: ich habe keine URLs angezeigt bekommen. Habe ich das Falsche geöffnet (Signierte Updates aus einem Intranetspeicher für Microsoft-Updatedienste zulassen)? Dies habe ich aktiviert.
Ich habe jetzt noch eine andere Richtlinie gefunden (Internen Pfad für den Microsoft Updatedienst angeben). Diese wird in dem Artikel beschrieben, nicht?
Was muss ich jetzt genau in den Feldern eintragen?
Interner Updatedienst zum Ermitteln von Updates: 192.168.2.2 oder den Server-Namen ("SRV-testrechner") mit http/https?
Intranetserver für die Statistik: auch den 192.168.2.2
Alternativer Downloadserver festlegen: freilassen oder etwas eintragen?
Grüße
in der Testumgebung befindet sich kein Domänencontroller.
PowerShell-Ausgabe:
- bei Win7:
- bei Win10:
Den Artikel von Microsoft hab ich mir angeschaut, hatte allerdings Probleme beim Anwenden/Testen der Lösung: ich habe keine URLs angezeigt bekommen. Habe ich das Falsche geöffnet (Signierte Updates aus einem Intranetspeicher für Microsoft-Updatedienste zulassen)? Dies habe ich aktiviert.
Ich habe jetzt noch eine andere Richtlinie gefunden (Internen Pfad für den Microsoft Updatedienst angeben). Diese wird in dem Artikel beschrieben, nicht?
Was muss ich jetzt genau in den Feldern eintragen?
Interner Updatedienst zum Ermitteln von Updates: 192.168.2.2 oder den Server-Namen ("SRV-testrechner") mit http/https?
Intranetserver für die Statistik: auch den 192.168.2.2
Alternativer Downloadserver festlegen: freilassen oder etwas eintragen?
Grüße
