23
Updatessuche mit WSUS-Client geht nach W10-Update 1809 nicht ohne INet
Hallo liebe Kollegen,
auf einigen Maschinen führte ich heute das W10-Herbstupdate (1809) aus.
Das funktioniert bisher soweit problemlos.
Einer der geupdateten Rechner hat keinen Internetzugang und soll auch keinen haben. (Default-Gateway-Eintrag leer gelassen)
Vor dem Update lud er es sich vom WSUS und installierte es.
Nach dem Update kommt beim erneuten Updatesuchen diese Meldung:
Error encountered
We couldn't check for updates, becaus you aren't connected to the internet. Make sure you have a cdata or Wi-Fi connection and try again.
Wenn ich ein Gateway eintrage, also Internetzugang herstelle, sucht er anstandslos auf meinem WSUS im Lan und meldet er sei aktuell.
Im WSUS sehe ich dann auch die entsprechenden Kontakt- und Reporteinträge.
Die Konfiguration auf WSUS ist clientseitig auf allen Rechnern per Reg-Datei eingerichtet.
Mit den daraus resultierenden Einstellungen funktioniert der WSUS-Zugriff meiner Clients schon sehr lange.
Die Regdatei erneut zu importieren und den Rechner neuzustarten änderte auch nichts.
Testweise habe ich beim fraglichen Client die Windowsfirewall ausgeschaltet, was aber keine erkennbare Änderung brachte.
Die anderen Rechner, die ohnehin Internetzugang haben, haben diesen Kummer nicht.
Hat jemand eine Idee dazu?
Gruß Frank
auf einigen Maschinen führte ich heute das W10-Herbstupdate (1809) aus.
Das funktioniert bisher soweit problemlos.
Einer der geupdateten Rechner hat keinen Internetzugang und soll auch keinen haben. (Default-Gateway-Eintrag leer gelassen)
Vor dem Update lud er es sich vom WSUS und installierte es.
Nach dem Update kommt beim erneuten Updatesuchen diese Meldung:
Error encountered
We couldn't check for updates, becaus you aren't connected to the internet. Make sure you have a cdata or Wi-Fi connection and try again.
Wenn ich ein Gateway eintrage, also Internetzugang herstelle, sucht er anstandslos auf meinem WSUS im Lan und meldet er sei aktuell.
Im WSUS sehe ich dann auch die entsprechenden Kontakt- und Reporteinträge.
Die Konfiguration auf WSUS ist clientseitig auf allen Rechnern per Reg-Datei eingerichtet.
Mit den daraus resultierenden Einstellungen funktioniert der WSUS-Zugriff meiner Clients schon sehr lange.
Die Regdatei erneut zu importieren und den Rechner neuzustarten änderte auch nichts.
Testweise habe ich beim fraglichen Client die Windowsfirewall ausgeschaltet, was aber keine erkennbare Änderung brachte.
Die anderen Rechner, die ohnehin Internetzugang haben, haben diesen Kummer nicht.
Hat jemand eine Idee dazu?
Gruß Frank
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: 388393
Url: https://administrator.de/contentid/388393
Ausgedruckt am: 21.11.2024 um 23:11 Uhr
23 Kommentare
Neuester Kommentar
Hi
Da du die WSUS Einstellungen ja per reg machst was hast du den dort als Alternativen DownloadServer festlegen hinterlegt ?
Per GPO sieht das so aus
Mit freundlichen Grüßen Nemesis
Da du die WSUS Einstellungen ja per reg machst was hast du den dort als Alternativen DownloadServer festlegen hinterlegt ?
Per GPO sieht das so aus
Mit freundlichen Grüßen Nemesis
Du solltest in der GPO alle drei Einträge auf den WSUS zeigen lassen.
Hallo Nemesis,
danke für Deinen Beitrag.
bisher nichts
Die Reg-Entsprechung von Alternativen DownloadServer festlegen wäre laut Google das hier:
Ich habe meine Regdatei jetzt um diesen Wert ergänzt und mangels alternativen WSUS, den normalen WSUS angegeben, allerdings statt des Hostnamens dessen IP verwendet, damit die beiden Einträge nicht identisch sind.
Beispiel:
Diesen Eintrag nutze ich ebenfalls:
Den fraglichen Rechner habe ich nach dem erneuten Reg-Import neugestartet.
Eine Besserung im Sinne meiner Ausgangsfrage hat die Änderung leider nicht erbracht.
Wieso er also seit dem Update, beim Updatesuchen darüber jammert, dass er keine Internetverbindung hat, die er für WSUS ohnehin nicht nutzen soll, bleibt mir unklar.
Gruß Frank
danke für Deinen Beitrag.
bisher nichts
Die Reg-Entsprechung von Alternativen DownloadServer festlegen wäre laut Google das hier:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate]"UpdateServiceUrlAlternate"="http://AndererWSUS:8530"Ich habe meine Regdatei jetzt um diesen Wert ergänzt und mangels alternativen WSUS, den normalen WSUS angegeben, allerdings statt des Hostnamens dessen IP verwendet, damit die beiden Einträge nicht identisch sind.
Beispiel:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate]"WUServer"="http://MeinWSUS:8530""WUStatusServer"="http://MeinWSUS:8530""UpdateServiceUrlAlternate"="http://10.20.30.40:8530"Diesen Eintrag nutze ich ebenfalls:
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate]"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001Den fraglichen Rechner habe ich nach dem erneuten Reg-Import neugestartet.
Eine Besserung im Sinne meiner Ausgangsfrage hat die Änderung leider nicht erbracht.
Wieso er also seit dem Update, beim Updatesuchen darüber jammert, dass er keine Internetverbindung hat, die er für WSUS ohnehin nicht nutzen soll, bleibt mir unklar.
Gruß Frank
Hallo Looser27,
Testweise habe ich statt der IP auch beim dritten Eintrag (per Regdatei) den Hostnamen eingesetzt, also alle drei Einträge identisch gehalten und den Rechner neugestartet.
Leider keine Besserung.
Hat denn einer von Euch schon 1809 clientseitig in Einsatz und meinen erwähnten Kummer nicht?
Gruß Frank
Testweise habe ich statt der IP auch beim dritten Eintrag (per Regdatei) den Hostnamen eingesetzt, also alle drei Einträge identisch gehalten und den Rechner neugestartet.
Leider keine Besserung.
Hat denn einer von Euch schon 1809 clientseitig in Einsatz und meinen erwähnten Kummer nicht?
Gruß Frank
Hat denn einer von Euch schon 1809 clientseitig in Einsatz
Natürlich nicht. Ist noch viel zu früh dafür. Das Upgrade ist auch erst seit 2 Tagen raus.
Damit warte ich noch min. bis Ende des Jahres
Moin,
ich stelle das morgen auf nem Testclient nach.
Allerdings dann über die GPO Konfig und nicht über die manuellen Reg-Einträge.
Ich werde berichten.
Gruß
Spirit
ich stelle das morgen auf nem Testclient nach.
Allerdings dann über die GPO Konfig und nicht über die manuellen Reg-Einträge.
Ich werde berichten.
Gruß
Spirit
Hi
Schau mal auf meinem Bild zwei Punkte unten darunter das zu konfigurieren Bzgl Windows Updates aus dem Internet auf deaktiviert
Mit freundlichen Grüßen Nemesis
Schau mal auf meinem Bild zwei Punkte unten darunter das zu konfigurieren Bzgl Windows Updates aus dem Internet auf deaktiviert
Mit freundlichen Grüßen Nemesis
Hallo,
Keine Verbindungen mit Windows Update-Internetadressen herstellen entspricht dem Reg-Eintrag
Diesen Eintrag nutze ich bereits.
Danke, ich bin gespannt.
Gruß Frank
Zitat von @nEmEsIs:
Schau mal auf meinem Bild zwei Punkte unten darunter das zu konfigurieren Bzgl Windows Updates aus dem Internet auf deaktiviert
Schau mal auf meinem Bild zwei Punkte unten darunter das zu konfigurieren Bzgl Windows Updates aus dem Internet auf deaktiviert
Keine Verbindungen mit Windows Update-Internetadressen herstellen entspricht dem Reg-Eintrag
[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate]"DoNotConnectToWindowsUpdateInternetLocations"=dword:00000001Diesen Eintrag nutze ich bereits.
Danke, ich bin gespannt.
Gruß Frank
Das Update lief ohne Verbindung nach Extern durch.
Allerdings startet die VM seid dem Update nicht mehr. Also auch totaler Mukrs.
Allerdings startet die VM seid dem Update nicht mehr. Also auch totaler Mukrs.
Hallo Spirit,
danke für's Ausprobieren und Berichten.
Das war bei meinem fraglichen Rechner auch so, denn er hat keine Internetanbindung.
Mein "Kummer" ist, dass er nach dem Update ohne Internetanbindung keine Verbindung zum lokalen WSUS aufbauen kann, also weder Updates suchen noch Reports abgeben kann.
Beim Updatessuchen kommt seither die eingangs zitierte Fehlermeldung.
Ich habe testweise bei einem anderen Rechner (mit 1809) den Gatewayeintrag gelöscht und auch er kann dann keine Verbindung zum WSUS aufbauen bis ich das Gateway wieder eintrage.
Es scheint also ein generelles Problem zu sein.
Wenn die VM nicht mehr startet, kannst Du leider nicht nachprüfen, ob sie denselben "Kummer" hätte.
Das ist Schade, aber so ist es eben.
Es bleibt offen, ob es ein Bug in 1809 ist oder ob meine bisher gut funktionierende WSUS-Client-Konfiguration für 1809 ungenügend ist.
Gruß Frank
danke für's Ausprobieren und Berichten.
Das war bei meinem fraglichen Rechner auch so, denn er hat keine Internetanbindung.
Mein "Kummer" ist, dass er nach dem Update ohne Internetanbindung keine Verbindung zum lokalen WSUS aufbauen kann, also weder Updates suchen noch Reports abgeben kann.
Beim Updatessuchen kommt seither die eingangs zitierte Fehlermeldung.
Ich habe testweise bei einem anderen Rechner (mit 1809) den Gatewayeintrag gelöscht und auch er kann dann keine Verbindung zum WSUS aufbauen bis ich das Gateway wieder eintrage.
Es scheint also ein generelles Problem zu sein.
Zitat von @Spirit-of-Eli:
Allerdings startet die VM seid dem Update nicht mehr. Also auch totaler Mukrs.
Ich gehe davon aus, dass die VM Dein Testclient ist.Allerdings startet die VM seid dem Update nicht mehr. Also auch totaler Mukrs.
Wenn die VM nicht mehr startet, kannst Du leider nicht nachprüfen, ob sie denselben "Kummer" hätte.
Das ist Schade, aber so ist es eben.
Es bleibt offen, ob es ein Bug in 1809 ist oder ob meine bisher gut funktionierende WSUS-Client-Konfiguration für 1809 ungenügend ist.
Gruß Frank
Einer der geupdateten Rechner hat keinen Internetzugang und soll auch keinen haben. (Default-Gateway-Eintrag leer gelassen)
Deaktiviere stattdessen auf dem Router das Forwarding für den Client in andere Netze als dem lokalen. Damit klappt das hier problemlos.
Hallo speedlink,
Das Updateziehen vom lokalen WSUS auch mit 1809 als Client?
Wenn Du lediglich die Unterbindung des Internetzugangs meinst, dann danke für den Tipp.
Für mich ist es aber einfacher und zweckmäßiger den Gatewayeintrag leer zu lassen, statt den Router umzukonfigurieren.
Gruß Frank
Zitat von @137289:
Deaktiviere stattdessen auf dem Router das Forwarding für den Client in andere Netze als dem lokalen. Damit klappt das hier problemlos.
Was klappt damit problemlos?Deaktiviere stattdessen auf dem Router das Forwarding für den Client in andere Netze als dem lokalen. Damit klappt das hier problemlos.
Das Updateziehen vom lokalen WSUS auch mit 1809 als Client?
Wenn Du lediglich die Unterbindung des Internetzugangs meinst, dann danke für den Tipp.
Für mich ist es aber einfacher und zweckmäßiger den Gatewayeintrag leer zu lassen, statt den Router umzukonfigurieren.
Gruß Frank
Die VM startet nach einiger Zeit doch.
Report an den WSUS ist auch durch gelaufen.
Jetzt habe ich allerdings kein mit dem KMS Key aktiviertes System mehr.
Dies ist selbst mit Internet nicht zu aktivieren.
Kurz zum Aufbau. Ich habe das GW nicht raus genommen aber die Verbindung nach extern am Router gesperrt.
Report an den WSUS ist auch durch gelaufen.
Jetzt habe ich allerdings kein mit dem KMS Key aktiviertes System mehr.
Dies ist selbst mit Internet nicht zu aktivieren.
Kurz zum Aufbau. Ich habe das GW nicht raus genommen aber die Verbindung nach extern am Router gesperrt.
Hallo Spirit,
darf ich Dich um einen weiteren Test bitten?
1. Updates suchen lassen mit am Router gesperrter Verbindung nach extern.
(Erfolg oder Fehlermeldung)
2. Updates suchen lassen mit leerem Gateway-Eintrag
(Erfolg oder Fehlermeldung)
Es würde mich wirklich überraschen wenn das in Bezug auf die lokale Verbindung zum WSUS einen Unterschied macht.
Gruß Frank
darf ich Dich um einen weiteren Test bitten?
1. Updates suchen lassen mit am Router gesperrter Verbindung nach extern.
(Erfolg oder Fehlermeldung)
2. Updates suchen lassen mit leerem Gateway-Eintrag
(Erfolg oder Fehlermeldung)
Es würde mich wirklich überraschen wenn das in Bezug auf die lokale Verbindung zum WSUS einen Unterschied macht.
Gruß Frank
Zitat von @Pedant:
Was klappt damit problemlos?
Das Updateziehen vom lokalen WSUS auch mit 1809 als Client?
Ja klar. Ohne GW Eintrag geht's hier auch nicht, jedoch mit GW aber am Router deaktiviertem Forwarding für den Kandidaten schon.Was klappt damit problemlos?
Das Updateziehen vom lokalen WSUS auch mit 1809 als Client?
Hallo speedlink,
Danke für die Info.
Sie irritiert mich allerdings sehr.
Statt am Router Änderungen vorzunehmen, habe ich soeben bei dem fraglichen WSUS-Client als Gateway die IP eines lokalen Servers eingetragen, der seinerseits auch keinen Internetzugang hat (kein Gatewayeintrag).
Das Updatesuchen funktioniert daraufhin einwandfrei.
Es spielt dabei auch keine Rolle, ob ich das Netzwerk des WSUS-Clients als Public oder Private deklariere.
(Die Windows-Firewall des WSUS-Clients ist aktiviert.)
Frage 1:
Was bitte ist der entscheidende Unterschied zwischen kein Internet wegen keinem Gateway und kein Internet wegen eines nutzlosen Gateways?
Frage 2:
Was spiel ein Gateway für ein Rolle bei einer Lan-Verbindung zum lokalen WSUS?
Mir kommt es so vor als sei der WSUS-Client einfach nur beleidigt, wenn er kein Gateway hat und verweigert schmollend seine Arbeit.
Ich markiere den Thread als gelöst, auch wenn ich nicht verstanden habe warum sich das Problem so lösen oder zumindest umgehen lässt.
Gruß Frank
Zitat von @137289:
Ohne GW Eintrag geht's hier auch nicht, jedoch mit GW aber am Router deaktiviertem Forwarding für den Kandidaten schon.
Ohne GW Eintrag geht's hier auch nicht, jedoch mit GW aber am Router deaktiviertem Forwarding für den Kandidaten schon.
Danke für die Info.
Sie irritiert mich allerdings sehr.
Statt am Router Änderungen vorzunehmen, habe ich soeben bei dem fraglichen WSUS-Client als Gateway die IP eines lokalen Servers eingetragen, der seinerseits auch keinen Internetzugang hat (kein Gatewayeintrag).
Das Updatesuchen funktioniert daraufhin einwandfrei.
Es spielt dabei auch keine Rolle, ob ich das Netzwerk des WSUS-Clients als Public oder Private deklariere.
(Die Windows-Firewall des WSUS-Clients ist aktiviert.)
Frage 1:
Was bitte ist der entscheidende Unterschied zwischen kein Internet wegen keinem Gateway und kein Internet wegen eines nutzlosen Gateways?
Frage 2:
Was spiel ein Gateway für ein Rolle bei einer Lan-Verbindung zum lokalen WSUS?
Mir kommt es so vor als sei der WSUS-Client einfach nur beleidigt, wenn er kein Gateway hat und verweigert schmollend seine Arbeit.
Ich markiere den Thread als gelöst, auch wenn ich nicht verstanden habe warum sich das Problem so lösen oder zumindest umgehen lässt.
Gruß Frank
Zitat von @Pedant:
Statt am Router Änderungen vorzunehmen, habe ich soeben bei dem fraglichen WSUS-Client als Gateway die IP eines lokalen Servers eingetragen, der seinerseits auch keinen Internetzugang hat (kein Gatewayeintrag).
Das Updatesuchen funktioniert daraufhin einwandfrei.
Genau, ohne GW Eintrag spielt die NLA verrückt wie du gerade bemerkst.Statt am Router Änderungen vorzunehmen, habe ich soeben bei dem fraglichen WSUS-Client als Gateway die IP eines lokalen Servers eingetragen, der seinerseits auch keinen Internetzugang hat (kein Gatewayeintrag).
Das Updatesuchen funktioniert daraufhin einwandfrei.
https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm
Es spielt dabei auch keine Rolle, ob ich das Netzwerk des WSUS-Clients als Public oder Private deklariere.
(Die Windows-Firewall des WSUS-Clients ist aktiviert.)
Die NLA braucht einen GW Eintrag, egal ob das ein Router oder Dummy Host ist.(Die Windows-Firewall des WSUS-Clients ist aktiviert.)
Frage 1:
Was bitte ist der entscheidende Unterschied zwischen kein Internet wegen keinem Gateway und kein Internet wegen eines nutzlosen Gateways?
Die NLA.Was bitte ist der entscheidende Unterschied zwischen kein Internet wegen keinem Gateway und kein Internet wegen eines nutzlosen Gateways?
Frage 2:
Was spiel ein Gateway für ein Rolle bei einer Lan-Verbindung zum lokalen WSUS?
Ohne MAC eines GWs hängt die NLA in der Luft und Windows stellt sich stumm. Da hängen außer des Netzwerkprofils und der Firewall auch noch andere Prozesse mit dran.Was spiel ein Gateway für ein Rolle bei einer Lan-Verbindung zum lokalen WSUS?
Find ich sowieso eine schlechte Lösung, denn ohne GW kann man auch kein lokales Routen zu anderen lokalen Subnetzen mehr machen ohne am Client statische Routen zu setzen.
Es gibt noch andere Probleme wenn am Client kein GW gesetzt ist, hab ich schon einige Software gesehen die dann nicht will.
Zitat von @137289:
Find ich sowieso eine schlechte Lösung, denn ohne GW kann man auch kein lokales Routen zu anderen lokalen Subnetzen mehr machen ohne am Client statische Routen zu setzen.
Find ich sowieso eine schlechte Lösung, denn ohne GW kann man auch kein lokales Routen zu anderen lokalen Subnetzen mehr machen ohne am Client statische Routen zu setzen.
Es ist durchaus üblich auch in isolierten netzen ohne Gateway zu arbeiten. Es ist eher ein unding, zwingend ein gatewy vorauszusetzen, selbst wenn es ein dummy-gateway sein sollte.
Es gibt noch andere Probleme wenn am Client kein GW gesetzt ist, hab ich schon einige Software gesehen die dann nicht will.
Schlampige fehelerhafte Programmierer! Das muß man denen um die nase hauen!
lks
Hallo speedlink,
danke für Deine Erläuterungen.
NLA = Network Location Awareness Service Provider
Nunja, egal, ich habe jetzt eine Lösung und eine Erklärung, wobei die Erklärung eher nach einem hausgemachten Windowsproblem klingt, als nach einer generellen TCP/IP-Funktionsweise.
Gruß und Dank
Frank
danke für Deine Erläuterungen.
NLA = Network Location Awareness Service Provider
Zitat von @137289:
...ohne GW Eintrag spielt die NLA verrückt wie du gerade bemerkst.
Bis Version 1803 war das zumindest in Bezug auf WSUS-Client nicht so oder es blieb unbemerkt und ohne diesbezüglichen Funktionseinfluss....ohne GW Eintrag spielt die NLA verrückt wie du gerade bemerkst.
Nunja, egal, ich habe jetzt eine Lösung und eine Erklärung, wobei die Erklärung eher nach einem hausgemachten Windowsproblem klingt, als nach einer generellen TCP/IP-Funktionsweise.
Gruß und Dank
Frank
Zitat von @Lochkartenstanzer:
Schlampige fehelerhafte Programmierer! Das muß man denen um die nase hauen!
Dann musst du MS die Nase amputieren Schlampige fehelerhafte Programmierer! Das muß man denen um die nase hauen!
, bei denen fehlen sowieso schon etliche Körperteile.
NLA lässt sich auch umbiegen und auch der Download der Text Datei ändern.
Sicher, aber das ist nur ein kleiner Teil der NLA nämlich die des Network Status Indicator, NLA besteht aber aus mehr als das.
Zitat von @137289:
Sicher, aber das ist nur ein kleiner Teil der NLA nämlich die des Network Status Indicator, NLA besteht aber aus mehr als das.
Sicher, aber das ist nur ein kleiner Teil der NLA nämlich die des Network Status Indicator, NLA besteht aber aus mehr als das.
So ein Akt ist das jetzt auch nicht und das umzubiegen funktioniert.
Gerade bei den Anwendungen die rumzicken.
