53
Server 2019 "hat keine Internetverbindung" (angeblich)
Moin Kollegen !
Einer unserer Server 2019, eingesetzt als Mailserver für TOBIT, zeigt eine seltsame Sache seit ca. 2 Monaten: in der Taskleiste unten rechts den Status "Internet nicht verbunden" und die Problembehandlung liefert die Aussage
"Das Gerät bzw. die Ressource (www.microsoft.com) ist nicht für das Akzeptieren von Verbindungen an Port "Der World Wide Web-Dienst (HTTP)" eingerichtet. " (eine Aussage, die für mich wenig Sinn macht)
Zudem -und das ist das eigentliche Problem- kann "der Microsoft-Update-Server nicht erreicht werden. => es laufen keine Updates mehr seit 2-3 Monaten.
Statusprüfungen:
Der Rechner HAT definitiv Internet: Surfen problemlos, Dauerping auf google.com läuft mit 15 ms Responsetime konstant ohne Aussetzer, Emails werden empfangen und werden gesendet.
CHKDSK liefefert "fehlerfrei"
Ereignisprotokoll zeigt einen sauberen Server fast ohne relevante Fehler, aber:
Alle drei Sekunden liefert der "DeviceSetupManager" die Warnung 200 "Es konnte keine Verbindung mit dem Windows-Update-Dienst hergestellt werden."
Unwirksame Massnahmen:
Mit CCleaner Dateien geputzt + Registry gepflegt
sfc /scannow durchgeführt, irgendetwas "wurde repariert", aber keine Änderung
Natürlich mehrmals gebootet, klar.
Ideen:
Es handelt sich anscheinend um ein Problem mit dem "Device Netzwerkkarte" und der Server ist eine VM auf VMware. Man könnte die Netzwerkkarte sauber herauslöschen, neu booten und dann die Netzwerkkarte wieder neu zuweisen.
Oder habt Ihr Kollegen eine andere Idee ?
Gruß Walter
Einer unserer Server 2019, eingesetzt als Mailserver für TOBIT, zeigt eine seltsame Sache seit ca. 2 Monaten: in der Taskleiste unten rechts den Status "Internet nicht verbunden" und die Problembehandlung liefert die Aussage
"Das Gerät bzw. die Ressource (www.microsoft.com) ist nicht für das Akzeptieren von Verbindungen an Port "Der World Wide Web-Dienst (HTTP)" eingerichtet. " (eine Aussage, die für mich wenig Sinn macht)
Zudem -und das ist das eigentliche Problem- kann "der Microsoft-Update-Server nicht erreicht werden. => es laufen keine Updates mehr seit 2-3 Monaten.
Statusprüfungen:
Der Rechner HAT definitiv Internet: Surfen problemlos, Dauerping auf google.com läuft mit 15 ms Responsetime konstant ohne Aussetzer, Emails werden empfangen und werden gesendet.
CHKDSK liefefert "fehlerfrei"
Ereignisprotokoll zeigt einen sauberen Server fast ohne relevante Fehler, aber:
Alle drei Sekunden liefert der "DeviceSetupManager" die Warnung 200 "Es konnte keine Verbindung mit dem Windows-Update-Dienst hergestellt werden."
Unwirksame Massnahmen:
Mit CCleaner Dateien geputzt + Registry gepflegt
sfc /scannow durchgeführt, irgendetwas "wurde repariert", aber keine Änderung
Natürlich mehrmals gebootet, klar.
Ideen:
Es handelt sich anscheinend um ein Problem mit dem "Device Netzwerkkarte" und der Server ist eine VM auf VMware. Man könnte die Netzwerkkarte sauber herauslöschen, neu booten und dann die Netzwerkkarte wieder neu zuweisen.
Oder habt Ihr Kollegen eine andere Idee ?
Gruß Walter
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: 42963557429
Url: https://administrator.de/forum/server-2019-hat-keine-internetverbindung-angeblich-42963557429.html
Ausgedruckt am: 21.01.2025 um 12:01 Uhr
53 Kommentare
Neuester Kommentar
Moin,
wer CCleaner im professionellen Umfeld nutzt, sollte seinen Job an den Nagel hängen.
Gruß
Jasper
wer CCleaner im professionellen Umfeld nutzt, sollte seinen Job an den Nagel hängen.
Gruß
Jasper
6
Moin @MeinGottWalter
vielleicht lugst du mal in die Windows-Firewall ob da die HTTP-Einstellung auf AUS steht.
Kreuzberger
vielleicht lugst du mal in die Windows-Firewall ob da die HTTP-Einstellung auf AUS steht.
Kreuzberger
Moin,
Was hängt denn als Router/ Firewall zwischen dem Server und dem WAN?
Vielleicht hat da jemand die Microsoft-Seiten geblockt.
Ansonsten mal ins Eventlog schauen sowie mal Updates manuell, ggf. Via WSUS offline installieren…
Was hängt denn als Router/ Firewall zwischen dem Server und dem WAN?
Vielleicht hat da jemand die Microsoft-Seiten geblockt.
Ansonsten mal ins Eventlog schauen sowie mal Updates manuell, ggf. Via WSUS offline installieren…
Vermutlich die gleiche Ursache wie in > 90% der Fälle wenn Windows sagt "kein Internet". Der in Windows eingebaute Internetverfügbarkeitstest kann, warum auch immer, die programmierten Ziele nicht erreichen.
Manuel
Windows attempts to download a file from a dedicated Web server. Depending on which version of Windows, it’s http://www.msftncsi.com/ncsi.txt or http://www.msftconnecttest.com/connecttest.txt. If the download is successful and contains the correct contents, then Windows concludes that you have full Internet access.
Manuel
Hallo zusammen !
Vielen Dank erst mal für Eure Antworten.
Ich hatte vergessen zu erwähnen, dass auch komplettes Ausschalten der Firewall nichts ändert.
Der Server geht ins Internet / ins WAN über den IPcop ... seit Jahr und Tag und alle anderen Server haben damit auch kein Problem.
Was mich zudem wundert (wenn es kein Übersetzungsfehler ist) ist die Formulierung dieser Aussage
"Das Gerät bzw. die Ressource (www.microsoft.com) ist nicht für das Akzeptieren von Verbindungen an Port "Der World Wide Web-Dienst (HTTP)" eingerichtet. "
Ruft man die angegebene Ressource www.microsoft.com in einem Browser auf, switched die Verbindung -wie zu erwarten- automatisch auf https.
Das mit dem manuellen Offline-Installieren von Updates wäre eine Option, danke für den Tipp. Vielleicht auch eine Desinstalltion des letzten Updates, um einfach das "Drüberrechnen" anzutriggern ?
Vielen Dank erst mal für Eure Antworten.
Ich hatte vergessen zu erwähnen, dass auch komplettes Ausschalten der Firewall nichts ändert.
Der Server geht ins Internet / ins WAN über den IPcop ... seit Jahr und Tag und alle anderen Server haben damit auch kein Problem.
Was mich zudem wundert (wenn es kein Übersetzungsfehler ist) ist die Formulierung dieser Aussage
"Das Gerät bzw. die Ressource (www.microsoft.com) ist nicht für das Akzeptieren von Verbindungen an Port "Der World Wide Web-Dienst (HTTP)" eingerichtet. "
Ruft man die angegebene Ressource www.microsoft.com in einem Browser auf, switched die Verbindung -wie zu erwarten- automatisch auf https.
Das mit dem manuellen Offline-Installieren von Updates wäre eine Option, danke für den Tipp. Vielleicht auch eine Desinstalltion des letzten Updates, um einfach das "Drüberrechnen" anzutriggern ?
Hallo Manuel !
Deine beiden angegebenen http-Testlinks lassen sich problemlos öffnen, schalten aber ebenfalls auf https um.
Deine beiden angegebenen http-Testlinks lassen sich problemlos öffnen, schalten aber ebenfalls auf https um.
Und übrigens: über den Browser lässt sich auch www.microsoft.com problemlos öffnen !
Zitat von @MeinGottWalter:
Deine beiden angegebenen http-Testlinks lassen sich problemlos öffnen, schalten aber ebenfalls auf https um.
Deine beiden angegebenen http-Testlinks lassen sich problemlos öffnen, schalten aber ebenfalls auf https um.
Dann würde ich tatsächlich mal die neusten Updates manuell installieren. Was sind denn die letzten Updates die installiert wurden?
Manuel
1
Letztes Update:
Am 25.05.2024 wurde Kumulatives Update für Server 2019 (KB5038283) erfolgreich installiert.
Gruss Walter
Am 25.05.2024 wurde Kumulatives Update für Server 2019 (KB5038283) erfolgreich installiert.
Gruss Walter
Ich habe mir gerade einmal dieses WSUS offline angesehen, das emp_ie empfohlen hat. Aber ehrlich gesagt blicke ich da nicht durch, wie das geht.
Kann mir denn jemand sagen, wie ich so eine offline-Updaterei veranstalte ?
Kann mir denn jemand sagen, wie ich so eine offline-Updaterei veranstalte ?
Zitat von @MeinGottWalter:
Kann mir denn jemand sagen, wie ich so eine offline-Updaterei veranstalte ?
Kann mir denn jemand sagen, wie ich so eine offline-Updaterei veranstalte ?
Eigentlich nur runterladen und installieren. Dann angeben welche Updates, starten und warten.
Du kannst aber auch einfach mal bei https://www.catalog.update.microsoft.com/Home.aspx nachsehen, was es seit 05/2024 an Updates gibt für deinen Server. Das dann runterladen und installieren.
Danke erstmal ! Ich kucks mir an !
Moin @MeinGottWalter,
du musst bei einem Windows schon einiges mehr wie www.microsoft.com freigeben, damit die Updates & Co richtig laufen.
Schau mal am Besten die folgende Liste an ...
https://learn.microsoft.com/de-de/windows/privacy/manage-windows-11-endp ...
... und stelle zuerst sicher, dass deine IPcop, insbesondere die Dinge die unter "Statusanzeige der Netzwerkverbindung (NCSI)", "Microsoft Store" & "Windows Update" auf jeden Fall nicht blockt.
Und ja, die Verbindungspunkte von Windows 10/11 und Server 2019/2022 sind identisch.
Gruss Alex
Der Server geht ins Internet / ins WAN über den IPcop ... seit Jahr und Tag und alle anderen Server haben damit auch kein Problem.
Was mich zudem wundert (wenn es kein Übersetzungsfehler ist) ist die Formulierung dieser Aussage
"Das Gerät bzw. die Ressource (www.microsoft.com) ist nicht für das Akzeptieren von Verbindungen an Port "Der World Wide Web-Dienst (HTTP)" eingerichtet. "
Was mich zudem wundert (wenn es kein Übersetzungsfehler ist) ist die Formulierung dieser Aussage
"Das Gerät bzw. die Ressource (www.microsoft.com) ist nicht für das Akzeptieren von Verbindungen an Port "Der World Wide Web-Dienst (HTTP)" eingerichtet. "
du musst bei einem Windows schon einiges mehr wie www.microsoft.com freigeben, damit die Updates & Co richtig laufen.
Schau mal am Besten die folgende Liste an ...
https://learn.microsoft.com/de-de/windows/privacy/manage-windows-11-endp ...
... und stelle zuerst sicher, dass deine IPcop, insbesondere die Dinge die unter "Statusanzeige der Netzwerkverbindung (NCSI)", "Microsoft Store" & "Windows Update" auf jeden Fall nicht blockt.
Und ja, die Verbindungspunkte von Windows 10/11 und Server 2019/2022 sind identisch.
Gruss Alex
Hallo Alex ! Grundsätzlich gebe ich Dir recht. Aber folgendes:
In der Vergangenheit hatte dieser Server -genauso wie seine Brüder- und die anderen Rechner im Netz keine Probleme mit Updates. => die Einstellungen dieses Servers und auch die der Firewall / IPcop stimmen.
Per Browser (Google + Firewall) sowie per ping ist die angemeckerte Ressource www.microsoft.com problemlos zu erreichen.
Das einzige Konstrukt, welches anscheinend damit Schwierigkeiten hat, ist diese Kombionation aus DeviceSetupManager, Internetverbindungsprüfung und Update-Service.
Es ist ja zu beobachten, dass beim Aufruf von www.microsoft.com bzw. http://microsoft.com die Verbindung zumindest bei Browserzugriff erfolgreich auf https://microsoft.com umschaltet.
Jetzt kommt's: damit das klappt benutzt der Browser ein Zertifikat ! Aber er benutzt eines, das er sich vorher selbst geholt hat. Daher hat er das richtige Cert und die Verbindung ist erfolgreich.
Diese Internetverbindungsprüfung, der DeviceSetupmanager und / oder der Update-Service müßte dasselbe tun: das gültige Zertifikat benutzen!
Was, wenn MS neue Zertifikate ausgestellt hat und dieser Server das aus irgendwelchen Gründen nicht mitkriegt ? Ist bloss ein Verdacht, aber würde Sinn machen.
Interessanterweise steht in Deinem o.g. Link auch einiger Text zu Zertifikaten / Stammzertifikaten zu lesen. Also das Thema "Zertifikate" könnte schon die Baustelle sein!
Ich denke wir machen erst mal manuelle Updates wie vom Kollegen empfohlen.
Gruss Walter
In der Vergangenheit hatte dieser Server -genauso wie seine Brüder- und die anderen Rechner im Netz keine Probleme mit Updates. => die Einstellungen dieses Servers und auch die der Firewall / IPcop stimmen.
Per Browser (Google + Firewall) sowie per ping ist die angemeckerte Ressource www.microsoft.com problemlos zu erreichen.
Das einzige Konstrukt, welches anscheinend damit Schwierigkeiten hat, ist diese Kombionation aus DeviceSetupManager, Internetverbindungsprüfung und Update-Service.
Es ist ja zu beobachten, dass beim Aufruf von www.microsoft.com bzw. http://microsoft.com die Verbindung zumindest bei Browserzugriff erfolgreich auf https://microsoft.com umschaltet.
Jetzt kommt's: damit das klappt benutzt der Browser ein Zertifikat ! Aber er benutzt eines, das er sich vorher selbst geholt hat. Daher hat er das richtige Cert und die Verbindung ist erfolgreich.
Diese Internetverbindungsprüfung, der DeviceSetupmanager und / oder der Update-Service müßte dasselbe tun: das gültige Zertifikat benutzen!
Was, wenn MS neue Zertifikate ausgestellt hat und dieser Server das aus irgendwelchen Gründen nicht mitkriegt ? Ist bloss ein Verdacht, aber würde Sinn machen.
Interessanterweise steht in Deinem o.g. Link auch einiger Text zu Zertifikaten / Stammzertifikaten zu lesen. Also das Thema "Zertifikate" könnte schon die Baustelle sein!
Ich denke wir machen erst mal manuelle Updates wie vom Kollegen empfohlen.
Gruss Walter
So, nächstes Problem: Ich habe gerade einmal versucht, auf
https://www.catalog.update.microsoft.com/Search.aspx?q=server+2019
nach geeigneten Updates zu suchen. Ergebnis: für Server 2019 werden ausschließlich irgendwelche Hardware-Treiber angeboten, aber nichts, was mit dem Betriebssystem an sich - "Kumulatives Update" oder so etwas- zu tun hat.
Wo also bekomme ich Offline-Updates denn her ?
Nachtrag: gerade noch mal gefiltert auf der Seite und habe was gefunden. Also auch diese Seite hätte MS wesentlich besser machen können, was Filter und Ergebnisdarstellung anbelangt.
Nachtrag 2: was für Server 2019 zu finden ist, sind verschiedene "Kumulative Updates für .net-Framework", aber das war's. Könnte natürlich ein Treffer sein, weil es ja den Bereich Konnektivität" trifft.
Gruss Walter
https://www.catalog.update.microsoft.com/Search.aspx?q=server+2019
nach geeigneten Updates zu suchen. Ergebnis: für Server 2019 werden ausschließlich irgendwelche Hardware-Treiber angeboten, aber nichts, was mit dem Betriebssystem an sich - "Kumulatives Update" oder so etwas- zu tun hat.
Wo also bekomme ich Offline-Updates denn her ?
Nachtrag: gerade noch mal gefiltert auf der Seite und habe was gefunden. Also auch diese Seite hätte MS wesentlich besser machen können, was Filter und Ergebnisdarstellung anbelangt.
Nachtrag 2: was für Server 2019 zu finden ist, sind verschiedene "Kumulative Updates für .net-Framework", aber das war's. Könnte natürlich ein Treffer sein, weil es ja den Bereich Konnektivität" trifft.
Gruss Walter
Moin,
Lad dir das Tool von WSUSoffline herunter.
Starte die .exe darin und klicke mal „alles sinnvolle“ an. Auch die Stammzertifikate.
Im Tool lässt du auch ne ISO erstellen, mountest die auf dem Sorgen-Server und lässt die Updates installieren
Lad dir das Tool von WSUSoffline herunter.
Starte die .exe darin und klicke mal „alles sinnvolle“ an. Auch die Stammzertifikate.
Im Tool lässt du auch ne ISO erstellen, mountest die auf dem Sorgen-Server und lässt die Updates installieren
1
Moin em_pie ! Ich danke Dir.
Habe gerade 4 dieser .net-Updates von der MS-Seite heruntergeladen. 2 Davon waren "ungeeignet für diesen Computer", eines war "bereits installiert" und eines lief durch und erforderte einen Reboot. Leider ohne ERrfolg: immer noch "keine Internetverbindung", Situation unverändert.
Ich folge jetzt mal Deinem Weg!
Gruss Walter
Habe gerade 4 dieser .net-Updates von der MS-Seite heruntergeladen. 2 Davon waren "ungeeignet für diesen Computer", eines war "bereits installiert" und eines lief durch und erforderte einen Reboot. Leider ohne ERrfolg: immer noch "keine Internetverbindung", Situation unverändert.
Ich folge jetzt mal Deinem Weg!
Gruss Walter
Hallo em_pie !
Habe beide Versionen von WSUSoffline -v12.0 und 11.9- heruntergeladen und getestet. In beiden Fällen sieht das Ergebnis in der Konsole ungefähr so aus:
Starting WSUS Offline Update download v. 11.9.1 for w100-x64 glb...
Checking for sufficient file system rights...
Cleaning up existing directories...
Preserving custom language and architecture additions and removals...
Updating static and exclude definitions for download and update...
--2024-08-11 12:47:35-- https://download.wsusoffline.net/StaticDownloadLinks-sysinternals.txt
Resolving download.wsusoffline.net (download.wsusoffline.net)... 49.12.5.18
Connecting to download.wsusoffline.net (download.wsusoffline.net)|49.12.5.18|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 162 [text/plain]
Saving to: '../static/StaticDownloadLinks-sysinternals.txt'
StaticDownloadLinks-sysintern 100%[=================================================>] 162 --.-KB/s in 0s
2024-08-11 12:47:35 (525 KB/s) - '../static/StaticDownloadLinks-sysinternals.txt' saved [162/162]
FINISHED --2024-08-11 12:47:35--
Total wall clock time: 0,2s
Downloaded: 1 files, 162 in 0s (525 KB/s)
No URLs found in ../exclude/ExcludeDownloadFiles-modified.txt.
No URLs found in ../client/static/StaticUpdateFiles-modified.txt.
Restoring custom language and architecture additions and removals...
Downloading/validating mkisofs tool...
--2024-08-11 12:47:36-- https://download.wsusoffline.net/mkisofs.exe
Resolving download.wsusoffline.net (download.wsusoffline.net)... 49.12.5.18
Connecting to download.wsusoffline.net (download.wsusoffline.net)|49.12.5.18|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 380416 (372K) [application/octet-stream]
Saving to: '../bin/mkisofs.exe'
mkisofs.exe 100%[=================================================>] 371,50K --.-KB/s in 0,1s
2024-08-11 12:47:36 (3,78 MB/s) - '../bin/mkisofs.exe' saved [380416/380416]
FINISHED --2024-08-11 12:47:36--
Total wall clock time: 0,3s
Downloaded: 1 files, 372K in 0,1s (3,78 MB/s)
Downloading Sysinternals' tools Autologon, Sigcheck and Streams...
--2024-08-11 12:47:36-- https://download.sysinternals.com/files/AutoLogon.zip
Resolving download.sysinternals.com (download.sysinternals.com)... 152.199.19.160
Connecting to download.sysinternals.com (download.sysinternals.com)|152.199.19.160|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 507115 (495K) [application/octet-stream]
Saving to: '../bin/AutoLogon.zip'
AutoLogon.zip 100%[=================================================>] 495,23K --.-KB/s in 0,05s
2024-08-11 12:47:36 (9,69 MB/s) - '../bin/AutoLogon.zip' saved [507115/507115]
--2024-08-11 12:47:36-- https://download.sysinternals.com/files/Sigcheck.zip
Reusing existing connection to download.sysinternals.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 680079 (664K) [application/x-zip-compressed]
Saving to: '../bin/Sigcheck.zip'
Sigcheck.zip 100%[=================================================>] 664,14K --.-KB/s in 0,05s
2024-08-11 12:47:36 (13,4 MB/s) - '../bin/Sigcheck.zip' saved [680079/680079]
--2024-08-11 12:47:36-- https://download.sysinternals.com/files/Streams.zip
Reusing existing connection to download.sysinternals.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 511505 (500K) [application/octet-stream]
Saving to: '../bin/Streams.zip'
Streams.zip 100%[=================================================>] 499,52K --.-KB/s in 0,03s
2024-08-11 12:47:36 (15,0 MB/s) - '../bin/Streams.zip' saved [511505/511505]
FINISHED --2024-08-11 12:47:36--
Total wall clock time: 0,4s
Downloaded: 3 files, 1,6M in 0,1s (12,4 MB/s)
Archive: AutoLogon.zip
inflating: ../client/bin/Autologon.exe
inflating: ../client/bin/Autologon64.exe
inflating: ../client/bin/Autologon64a.exe
Archive: Sigcheck.zip
inflating: sigcheck.exe
inflating: sigcheck64.exe
inflating: sigcheck64a.exe
Archive: Streams.zip
inflating: streams.exe
inflating: streams64.exe
inflating: streams64a.exe
Downloading/validating most recent Windows Update catalog file...
--2024-08-11 12:47:38-- http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2. ...
Resolving download.windowsupdate.com (download.windowsupdate.com)... 146.75.118.172
Connecting to download.windowsupdate.com (download.windowsupdate.com)|146.75.118.172|:80... failed: Bad file descriptor.
ERROR: Download failure for w100-x64 glb.
Note: To better help understanding this error, you can select and copy the last messages from this window using the context menu (right mouse click in the window).
Drücken Sie eine beliebige Taste . . .
Der Download-Fehler mit "Bad file descriptor" ist immer derselbe und ich habe das sicherheitshalber sowohl auf dem betroffenen Server als auch auf einem nicht vom Fehler betroffenen Server 2019. Und ich habe es auch mit beiden Versionen 12.0 und 11.9 des Tools versucht.
Von der Bedienung her ist das ja wirklich gut gemacht und logisch. Aber eine wirkliche Auswahl der einzelnen Update-Dateien bekommt man ja nicht; das Ding legt nach Auswahl der Optionen einfach los. Geschrieben wurde gar nichts und für meinen Geschmack läuft das Ganze auch sehr schnell durch ... bis es dann eben zur Fehleranzeige kommt.
Er will ja den Update-Katalog herunterladen, was er nicht kann:
http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2. ...
Der Witz dabei: manuell kann ich den Katalog herunterladen, nachdem ich eine Ausnahmegenehmigung wegen http erteilt habe. Aber damit fange ich ja nichts an außerhalb des Tools.
Also es scheint mal wieder auf dasselbe Problem hinauszulaufen: aus nicht nachvollziehbarem Grund wird ein http-Aufruf veranstaltet (warum nicht gleich https ?) , den dann MS auf https umschaltet, was aber der aufrufende Computer -anscheinend auch problemlose Computer- nicht gebacken bekommen.
Eine Idee ?
Gruss Walter
Habe beide Versionen von WSUSoffline -v12.0 und 11.9- heruntergeladen und getestet. In beiden Fällen sieht das Ergebnis in der Konsole ungefähr so aus:
Starting WSUS Offline Update download v. 11.9.1 for w100-x64 glb...
Checking for sufficient file system rights...
Cleaning up existing directories...
Preserving custom language and architecture additions and removals...
Updating static and exclude definitions for download and update...
--2024-08-11 12:47:35-- https://download.wsusoffline.net/StaticDownloadLinks-sysinternals.txt
Resolving download.wsusoffline.net (download.wsusoffline.net)... 49.12.5.18
Connecting to download.wsusoffline.net (download.wsusoffline.net)|49.12.5.18|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 162 [text/plain]
Saving to: '../static/StaticDownloadLinks-sysinternals.txt'
StaticDownloadLinks-sysintern 100%[=================================================>] 162 --.-KB/s in 0s
2024-08-11 12:47:35 (525 KB/s) - '../static/StaticDownloadLinks-sysinternals.txt' saved [162/162]
FINISHED --2024-08-11 12:47:35--
Total wall clock time: 0,2s
Downloaded: 1 files, 162 in 0s (525 KB/s)
No URLs found in ../exclude/ExcludeDownloadFiles-modified.txt.
No URLs found in ../client/static/StaticUpdateFiles-modified.txt.
Restoring custom language and architecture additions and removals...
Downloading/validating mkisofs tool...
--2024-08-11 12:47:36-- https://download.wsusoffline.net/mkisofs.exe
Resolving download.wsusoffline.net (download.wsusoffline.net)... 49.12.5.18
Connecting to download.wsusoffline.net (download.wsusoffline.net)|49.12.5.18|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 380416 (372K) [application/octet-stream]
Saving to: '../bin/mkisofs.exe'
mkisofs.exe 100%[=================================================>] 371,50K --.-KB/s in 0,1s
2024-08-11 12:47:36 (3,78 MB/s) - '../bin/mkisofs.exe' saved [380416/380416]
FINISHED --2024-08-11 12:47:36--
Total wall clock time: 0,3s
Downloaded: 1 files, 372K in 0,1s (3,78 MB/s)
Downloading Sysinternals' tools Autologon, Sigcheck and Streams...
--2024-08-11 12:47:36-- https://download.sysinternals.com/files/AutoLogon.zip
Resolving download.sysinternals.com (download.sysinternals.com)... 152.199.19.160
Connecting to download.sysinternals.com (download.sysinternals.com)|152.199.19.160|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 507115 (495K) [application/octet-stream]
Saving to: '../bin/AutoLogon.zip'
AutoLogon.zip 100%[=================================================>] 495,23K --.-KB/s in 0,05s
2024-08-11 12:47:36 (9,69 MB/s) - '../bin/AutoLogon.zip' saved [507115/507115]
--2024-08-11 12:47:36-- https://download.sysinternals.com/files/Sigcheck.zip
Reusing existing connection to download.sysinternals.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 680079 (664K) [application/x-zip-compressed]
Saving to: '../bin/Sigcheck.zip'
Sigcheck.zip 100%[=================================================>] 664,14K --.-KB/s in 0,05s
2024-08-11 12:47:36 (13,4 MB/s) - '../bin/Sigcheck.zip' saved [680079/680079]
--2024-08-11 12:47:36-- https://download.sysinternals.com/files/Streams.zip
Reusing existing connection to download.sysinternals.com:443.
HTTP request sent, awaiting response... 200 OK
Length: 511505 (500K) [application/octet-stream]
Saving to: '../bin/Streams.zip'
Streams.zip 100%[=================================================>] 499,52K --.-KB/s in 0,03s
2024-08-11 12:47:36 (15,0 MB/s) - '../bin/Streams.zip' saved [511505/511505]
FINISHED --2024-08-11 12:47:36--
Total wall clock time: 0,4s
Downloaded: 3 files, 1,6M in 0,1s (12,4 MB/s)
Archive: AutoLogon.zip
inflating: ../client/bin/Autologon.exe
inflating: ../client/bin/Autologon64.exe
inflating: ../client/bin/Autologon64a.exe
Archive: Sigcheck.zip
inflating: sigcheck.exe
inflating: sigcheck64.exe
inflating: sigcheck64a.exe
Archive: Streams.zip
inflating: streams.exe
inflating: streams64.exe
inflating: streams64a.exe
Downloading/validating most recent Windows Update catalog file...
--2024-08-11 12:47:38-- http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2. ...
Resolving download.windowsupdate.com (download.windowsupdate.com)... 146.75.118.172
Connecting to download.windowsupdate.com (download.windowsupdate.com)|146.75.118.172|:80... failed: Bad file descriptor.
ERROR: Download failure for w100-x64 glb.
Note: To better help understanding this error, you can select and copy the last messages from this window using the context menu (right mouse click in the window).
Drücken Sie eine beliebige Taste . . .
Der Download-Fehler mit "Bad file descriptor" ist immer derselbe und ich habe das sicherheitshalber sowohl auf dem betroffenen Server als auch auf einem nicht vom Fehler betroffenen Server 2019. Und ich habe es auch mit beiden Versionen 12.0 und 11.9 des Tools versucht.
Von der Bedienung her ist das ja wirklich gut gemacht und logisch. Aber eine wirkliche Auswahl der einzelnen Update-Dateien bekommt man ja nicht; das Ding legt nach Auswahl der Optionen einfach los. Geschrieben wurde gar nichts und für meinen Geschmack läuft das Ganze auch sehr schnell durch ... bis es dann eben zur Fehleranzeige kommt.
Er will ja den Update-Katalog herunterladen, was er nicht kann:
http://download.windowsupdate.com/microsoftupdate/v6/wsusscan/wsusscn2. ...
Der Witz dabei: manuell kann ich den Katalog herunterladen, nachdem ich eine Ausnahmegenehmigung wegen http erteilt habe. Aber damit fange ich ja nichts an außerhalb des Tools.
Also es scheint mal wieder auf dasselbe Problem hinauszulaufen: aus nicht nachvollziehbarem Grund wird ein http-Aufruf veranstaltet (warum nicht gleich https ?) , den dann MS auf https umschaltet, was aber der aufrufende Computer -anscheinend auch problemlose Computer- nicht gebacken bekommen.
Eine Idee ?
Gruss Walter
Jetzt schlägt es 13: bin gerade auf die Idee gekommen, diese Generiererei statt auf einem Server 2019 ohne Probleme nochmals auf meinem Notebook WIN10 64 zu veranstalten. Dort läuft es erst mal durch anscheinend. Werde berichten.
Nachtrag: Hat eine Stunde gedauert. Auf dem WIN 10 wurde ein Verzeichnis mit 12 GB an Updates geschrieben und ein "Updateinstaller" bereitgestellt. Wenn man den aufruft bekommt man tatsächlich eine Auswahl an zu installierenden Updates und man kann tatsächlich "Zertifikate aktualisieren" anhaken !
Jetzt muss ich das Ganze nur noch im Firmennetzwerk zum Laufen kriegen wegen der Datenmenge, die sonst zu kopieren wäre.
Gruss Walter
Nachtrag: Hat eine Stunde gedauert. Auf dem WIN 10 wurde ein Verzeichnis mit 12 GB an Updates geschrieben und ein "Updateinstaller" bereitgestellt. Wenn man den aufruft bekommt man tatsächlich eine Auswahl an zu installierenden Updates und man kann tatsächlich "Zertifikate aktualisieren" anhaken !
Jetzt muss ich das Ganze nur noch im Firmennetzwerk zum Laufen kriegen wegen der Datenmenge, die sonst zu kopieren wäre.
Gruss Walter
Moin,
Gruß
DivideByZero
Zitat von @MeinGottWalter:
Jetzt schlägt es 13: bin gerade auf die Idee gekommen, diese Generiererei statt auf einem Server 2019 ohne Probleme nochmals auf meinem Notebook WIN10 64 zu veranstalten. Dort läuft es erst mal durch anscheinend. Werde berichten.
Genau das ist der Sinn des Offline-Installers. Auf einem Gerät mit Internetverbindung wird das "Installationspaket" vorbereitet, auf einem Gerät ohne Internetverbindung installiert.Jetzt schlägt es 13: bin gerade auf die Idee gekommen, diese Generiererei statt auf einem Server 2019 ohne Probleme nochmals auf meinem Notebook WIN10 64 zu veranstalten. Dort läuft es erst mal durch anscheinend. Werde berichten.
Jetzt muss ich das Ganze nur noch im Firmennetzwerk zum Laufen kriegen wegen der Datenmenge, die sonst zu kopieren wäre.
Kopierer wäre sicherlich der schnellste Weg, das ist doch keine Datenmenge. Ansonsten einfach auf einem beliebigen Firmen-PC (nur nicht dem, der zickt) laufen lassen, Installationspaket dann auf den Server umkopieren und installieren.Gruß
DivideByZero
@MeinGottWalter
also im ernst, die 12GB passen doch locker auf ein USB-Stick. Die gibts für 5€ im MediaMarkt.
Das sollte doch nicht wirklich problematisch sein.
Kreuzberger
also im ernst, die 12GB passen doch locker auf ein USB-Stick. Die gibts für 5€ im MediaMarkt.
Das sollte doch nicht wirklich problematisch sein.
Kreuzberger
Also wenn der Telemetrieserver an der Firewall geblockt ist, sollte das genau zu dem Ergebnis führen.
Moin @MeinGottWalter,
damit das Windows eine funktionierende Internetverbindung erkennt, muss aber nicht "www.microsoft.com" Problemlos erreichbar sein, sondern "www.msftconnecttest.com" und "ipv6.msftconnecttest.com" und zwar per HTTP und HTTPS und ICMP.
Gruss Alex
Per Browser (Google + Firewall) sowie per ping ist die angemeckerte Ressource www.microsoft.com problemlos zu erreichen.
damit das Windows eine funktionierende Internetverbindung erkennt, muss aber nicht "www.microsoft.com" Problemlos erreichbar sein, sondern "www.msftconnecttest.com" und "ipv6.msftconnecttest.com" und zwar per HTTP und HTTPS und ICMP.
Gruss Alex
Hört sich für mich so an, als ob einer der Windows Dienste deaktiviert worden ist. In der Windows Wiederherstellungskonsole mal Nachsehen, ob zu dieser Zeit davor ein Wiederherstellungspunkt gesetzt worden ist. Eventuell mal die VMware selbst überprüfen, ob da alles verfügbar erscheint und auf dem Hostsystem checken, ob alle erforderlichen Dienste zur Verfügung stehen. Ich hatte es in der Vergangenheit allerdings auch schon des öftern, das angeblich kein Internet verbunden sei, ob wohl ich grade gegenwärtig damit surfe.... Microsofts typischen Probleme....
Updates Manuel versuchen herunter zu ziehen und hoffen, daß der Fehler verschwindet. CC kann daran auch schuld sein. Dazu Windows mal reparieren versuchen, Falls der notwendige Dienst auf einem der beiden Systemen deinstalliert wurde.
Updates Manuel versuchen herunter zu ziehen und hoffen, daß der Fehler verschwindet. CC kann daran auch schuld sein. Dazu Windows mal reparieren versuchen, Falls der notwendige Dienst auf einem der beiden Systemen deinstalliert wurde.
damit das Windows eine funktionierende Internetverbindung erkennt, muss aber nicht "www.microsoft.com" Problemlos erreichbar sein, sondern "www.msftconnecttest.com" und "ipv6.msftconnecttest.com" und zwar per HTTP und HTTPS und ICMP.
www.msftconnecttest.com wird via Firefox aufgelöst, fordert aber eine Ausnahmegenehmigung beim Umswitchen auf https://www.msftconnecttest.com. Dannach Seite mit Text "page not found"
Dasselbe passiert mit http://www.msftconnecttest.com und https://www.msftconnecttest.com
Und zwar identisch sowohl auf dem Problemserver als auch vergleichsweise auf meinem völlig problemlosen WIN10-Notebook.
ipv6 ist bei uns generell ausgeschaltet und wie ich ICMP testen soll, weiß ich nicht.
Gruß Walter
Windows attempts to download a file from a dedicated Web server. Depending on which version of Windows, it’s http://www.msftncsi.com/ncsi.txt or http://www.msftconnecttest.com/connecttest.txt. If the download is successful and contains the correct contents, then Windows concludes that you have full Internet access.
Zudem: auch diese beiden Links funktionieren auf dem Problemserver -wie oben bereits gesagt- :
www.msftncsi.com/ncsi.txt fordert Ausnahmegenehmigung anund zeigt Text "Page not found"
www.msftconnecttest.com/connecttest.txt löst sofort auf und zeigt Text "Microsoft Connect Test"
Zum Vergleich: auf meinem problemlosen WIN10 Notebook außerhalb des Firmennetzes passiert genau dasselbe.
Gruss Walter
PS: die Offline-Updates sind für Mittwoch geplant. Das ist nun bereitgestellt.
Moin @MeinGottWalter,
das ist aber schon sehr komisch, den ich kann bei mir "www.msftncsi.com/ncsi.txt" ...
... ohne Probleme aufrufen. 🤔
Mach mal eine CMD auf und tippsel dort mal das folgende ein ...
... was spuckt die daraufhin an Infos aus?
Gruss Alex
www.msftncsi.com/ncsi.txt fordert Ausnahmegenehmigung anund zeigt Text "Page not found"
www.msftconnecttest.com/connecttest.txt löst sofort auf und zeigt Text "Microsoft Connect Test"
Zum Vergleich: auf meinem problemlosen WIN10 Notebook außerhalb des Firmennetzes passiert genau dasselbe.
www.msftconnecttest.com/connecttest.txt löst sofort auf und zeigt Text "Microsoft Connect Test"
Zum Vergleich: auf meinem problemlosen WIN10 Notebook außerhalb des Firmennetzes passiert genau dasselbe.
das ist aber schon sehr komisch, den ich kann bei mir "www.msftncsi.com/ncsi.txt" ...
... ohne Probleme aufrufen. 🤔
Mach mal eine CMD auf und tippsel dort mal das folgende ein ...
nslookup www.msftncsi.com... was spuckt die daraufhin an Infos aus?
Gruss Alex
Moin @MeinGottWalter,
ja, das ist definitiv eine Baustelle, aber nicht die von dir, sondern die von Microsoft, da der entsprechenden Webservice, schlichtweg mit einem dafür ungültigen Zertifikat gesichert sind. 🙈
Daher habe ich soeben bei Microsoft eines meiner "speziellen" Support-Tickets diesbezüglich eröffnet.
🤪
Gruss Alex
Interessanterweise steht in Deinem o.g. Link auch einiger Text zu Zertifikaten / Stammzertifikaten zu lesen. Also das Thema "Zertifikate" könnte schon die Baustelle sein!
ja, das ist definitiv eine Baustelle, aber nicht die von dir, sondern die von Microsoft, da der entsprechenden Webservice, schlichtweg mit einem dafür ungültigen Zertifikat gesichert sind. 🙈
Daher habe ich soeben bei Microsoft eines meiner "speziellen" Support-Tickets diesbezüglich eröffnet.
Gruss Alex
Zitat von @MysticFoxDE:
Moin @MeinGottWalter,
ja, das ist definitiv eine Baustelle, aber nicht die von dir, sondern die von Microsoft, da der entsprechenden Webservice, schlichtweg mit einem dafür ungültigen Zertifikat gesichert sind. 🙈
Daher habe ich soeben bei Microsoft eines meiner "speziellen" Support-Tickets diesbezüglich eröffnet.
🤪
Gruss Alex
Moin @MeinGottWalter,
Interessanterweise steht in Deinem o.g. Link auch einiger Text zu Zertifikaten / Stammzertifikaten zu lesen. Also das Thema "Zertifikate" könnte schon die Baustelle sein!
ja, das ist definitiv eine Baustelle, aber nicht die von dir, sondern die von Microsoft, da der entsprechenden Webservice, schlichtweg mit einem dafür ungültigen Zertifikat gesichert sind. 🙈
Daher habe ich soeben bei Microsoft eines meiner "speziellen" Support-Tickets diesbezüglich eröffnet.
Gruss Alex
Spielt hier keine Rolle, denn die Seiten werden vom NLASVC eh nur per http (ohne SSL) abgerufen.
Außerdem lässt sich die zu prüfende URL oder die DNS-Domain auch an eigene Bedürfnisse anpassen und dort der Inhalt über eigene Webserver bzw. DNS-Records wiedergeben wenn man möchte .
https://www.msxfaq.de/netzwerk/grundlagen/network_location_awareness.htm
Moin @14135584197,
in der Doku von Microsoft, steht aber HTTPS und nicht HTTP. 🙃
Gruss Alex
Spielt hier keine Rolle, denn die Seiten werden vom NLASVC eh nur per http (ohne SSL) abgerufen.
in der Doku von Microsoft, steht aber HTTPS und nicht HTTP. 🙃
Gruss Alex
Moin @14135584197,
ähm, du liegst mit deiner Aussage aber dennoch richtig!
🙃
Sprich, die entsprechenden Microsoft Dokus ...
https://learn.microsoft.com/de-de/windows/privacy/manage-windows-11-endp ...
https://learn.microsoft.com/de-de/windows/privacy/manage-windows-21h2-en ...
... sind falsch, da diese auf HTTPS verweisen. 😭
Gruss Alex
Spielt hier keine Rolle, denn die Seiten werden vom NLASVC eh nur per http (ohne SSL) abgerufen.
ähm, du liegst mit deiner Aussage aber dennoch richtig!
Sprich, die entsprechenden Microsoft Dokus ...
https://learn.microsoft.com/de-de/windows/privacy/manage-windows-11-endp ...
https://learn.microsoft.com/de-de/windows/privacy/manage-windows-21h2-en ...
... sind falsch, da diese auf HTTPS verweisen. 😭
Gruss Alex
Moin @MeinGottWalter,
🤔 ... das sieht mir irgendwie nach einem DNS Problem aus.
Was kommt den auf dem entsprechenden Rechner raus, wenn du in einer CMD das folgende eingibst ...
... ?
Gruss Alex
www.msftncsi.com/ncsi.txt fordert Ausnahmegenehmigung anund zeigt Text "Page not found"
🤔 ... das sieht mir irgendwie nach einem DNS Problem aus.
Was kommt den auf dem entsprechenden Rechner raus, wenn du in einer CMD das folgende eingibst ...
ping www.msftncsi.com... ?
Gruss Alex
Tja, da hat sich wohl jemand vertippt oder nur blind übernommen. Never trust MS Doku 😜
Moin @14135584197,
ja, leider, davon kann ich mittlerweile auch ein sehr langes Lied singen. 😔
Gruss Alex
Never trust MS Doku 😜
ja, leider, davon kann ich mittlerweile auch ein sehr langes Lied singen. 😔
Gruss Alex
Jaja, Microsoft, und seine eigenen Behauptungen:
In meinem damaligen MCITP-Kurs durfte ich lernen: Windows PE ist kein Betriebssystem, weil man es separat nicht kaufen kann. Laut MS TechNet hiess es damals aber: Windows PE ist ein Minimal Betriebssystem zum . . . .
naja .... wer glaubt den Äusserungen Microsofts noch?
Kreuzberger
In meinem damaligen MCITP-Kurs durfte ich lernen: Windows PE ist kein Betriebssystem, weil man es separat nicht kaufen kann. Laut MS TechNet hiess es damals aber: Windows PE ist ein Minimal Betriebssystem zum . . . .
naja .... wer glaubt den Äusserungen Microsofts noch?
Kreuzberger
ping www.msftncsi.com
Moin zusammen ! Erfahrungen mit MS haben wir denke ich alle.
Bei dem ping kommt raus:
Antwort von 88.221.110.216 ... Zeit 16 ms ...
Dauerhaft ohne Aussetzer.
Der erste Teil des Offline-Updates ist gelaufen und er fordert einen Reboot. Kann ich aber erst heute abend machen, wenn die Leute nicht mehr arbeiten.
Gruss Walter
Moin @MeinGottWalter,
bei mir wird "www.msftncsi.com" auf "2.21.20.155" & "2.21.20.140" aufgelöst. 🤔
Welche externen DNS Server verwendest du den genau?
Denn meine Kristallkugel sagt mit gerade, dass du wahrscheinlich irgendwo in deiner Konfig/Umgebung einen Verweis auf einen veralteten DNS hast, was auch ein Stückweit die Probleme mit den Updates erklären würde.
Stell mal testweise auf einem der problematischen Clients die DNS Server in der Netzwerkkarte auf 8.8.8.8 und oder 1.1.1.1 und schau ob danach die Internetverbindung wieder sauber erkannt wird.
Gruss Alex
Antwort von 88.221.110.216 ... Zeit 16 ms ...
bei mir wird "www.msftncsi.com" auf "2.21.20.155" & "2.21.20.140" aufgelöst. 🤔
Welche externen DNS Server verwendest du den genau?
Denn meine Kristallkugel sagt mit gerade, dass du wahrscheinlich irgendwo in deiner Konfig/Umgebung einen Verweis auf einen veralteten DNS hast, was auch ein Stückweit die Probleme mit den Updates erklären würde.
Stell mal testweise auf einem der problematischen Clients die DNS Server in der Netzwerkkarte auf 8.8.8.8 und oder 1.1.1.1 und schau ob danach die Internetverbindung wieder sauber erkannt wird.
Gruss Alex
Die Domain läuft auf ein CDN bei Akamai die IPs fallen dann bei jedem eh anders aus ...
1
Nutzt ihr zufällig einen Proxy?
Nur zur Info, NLA nutzt WinHTTP, wenn da also bspw. noch ein falscher Proxy oder kein Proxy (wenn jedoch einer genutzt wird) in den Einstellungen steht kann es auch zu dem Verhalten kommen.
Wenn kein Proxy genutzt wird setzt man die Einstellungen folgendermaßen zurück
Nur zur Info, NLA nutzt WinHTTP, wenn da also bspw. noch ein falscher Proxy oder kein Proxy (wenn jedoch einer genutzt wird) in den Einstellungen steht kann es auch zu dem Verhalten kommen.
netsh winhttp show proxynetsh winhttp reset proxy
Moin @14135584197,
das ist mir nicht entfallen, ich bekomme jedoch von so gut wie jedem DNS Server bei einer Anfrage für "www.msftncsi.com" IP aus +- derselben Range geliefert und die entspricht nicht dem was der TO zurückbekommt, daher auch die Idee mit dem "suboptimalen" DNS, zumal bei ihm auch der Browser nichts zurück liefert.
Gruss Alex
Die Domain läuft auf ein CDN bei Akamai die IPs fallen dann bei jedem eh anders aus ...
das ist mir nicht entfallen, ich bekomme jedoch von so gut wie jedem DNS Server bei einer Anfrage für "www.msftncsi.com" IP aus +- derselben Range geliefert und die entspricht nicht dem was der TO zurückbekommt, daher auch die Idee mit dem "suboptimalen" DNS, zumal bei ihm auch der Browser nichts zurück liefert.
Gruss Alex
Moin zusammen !
Wegen arbeitstechnischen Gründen musste ich weitere Aktionen auf voraussichtlich heute abend verschieben.
Ich werde berichten.
Vorab nur so viel: bei mir ausserhalb der Firmennetzes auf dem Notebook erhalte ich dasselbe Ergebnis für www.msftncsi.com wie auf dem Problemserver: ping liefert einwandfrei Antwort (wenn auch mit anderer IP-Adresse) und Browser liefert "page not found".
Der Problemserver arbeitet gegen DNS von VERSATEL während das Notebook gegen die DNS von O2 Mobilnetz arbeitet. Das Firmennetz hat von VERSATEL einen Anschluß mit 5 festen IP's, also schon was "Richtiges" bzw. nichts "Komisches".
Gruss Walter
Wegen arbeitstechnischen Gründen musste ich weitere Aktionen auf voraussichtlich heute abend verschieben.
Ich werde berichten.
Vorab nur so viel: bei mir ausserhalb der Firmennetzes auf dem Notebook erhalte ich dasselbe Ergebnis für www.msftncsi.com wie auf dem Problemserver: ping liefert einwandfrei Antwort (wenn auch mit anderer IP-Adresse) und Browser liefert "page not found".
Der Problemserver arbeitet gegen DNS von VERSATEL während das Notebook gegen die DNS von O2 Mobilnetz arbeitet. Das Firmennetz hat von VERSATEL einen Anschluß mit 5 festen IP's, also schon was "Richtiges" bzw. nichts "Komisches".
Gruss Walter
Ich habs mal bei mir auch mal mit www.msftncsi.com versucht. Das gleiche Problem erhalten: "page not found"..
Also ist bei Dir wohl alles OK. Nur bei denen nicht. Kannst die ja mal per Mail auf dieses Problem verweisen. Auch ganz andere Server hängen zur Zeit.....
Also ist bei Dir wohl alles OK. Nur bei denen nicht. Kannst die ja mal per Mail auf dieses Problem verweisen. Auch ganz andere Server hängen zur Zeit.....
Zitat von @PlainPlounder:
Ich habs mal bei mir auch mal mit www.msftncsi.com versucht. Das gleiche Problem erhalten: "page not found"..
Also ist bei Dir wohl alles OK. Nur bei denen nicht. Kannst die ja mal per Mail auf dieses Problem verweisen. Auch ganz andere Server hängen zur Zeit.....
Ich habs mal bei mir auch mal mit www.msftncsi.com versucht. Das gleiche Problem erhalten: "page not found"..
Also ist bei Dir wohl alles OK. Nur bei denen nicht. Kannst die ja mal per Mail auf dieses Problem verweisen. Auch ganz andere Server hängen zur Zeit.....
Je nee, es muss http://www.msftncsi.com/ncsi.txt aufgerufen werden , nicht nur die Domain, ohne angehängtes ncsi.txt ist es normal das "Page not found" geliefert wird! RTFM!
2
Moin Kollegen !
Zunächst meinen Dank für die vielen Hinweise und Erläuterungen. Es gibt nun einen neuen Stand, der auch einen neuen Blickwinkel auf die Problemstellung liefert.
i) Offline-Updates wurden durchgeführt .. ohne Veränderung.
ii) Wenn man die Testlinks nach Euren Anleitungen per Browser richtig aufruft -danke bacardi !- funktioniert das auch.
iii) Einträge für den NLA-Dienst in der Registry gecheckt: alles Standard bzw. korrekt laut Internetquellen
Dennoch "kein Internet" angeblich, kein online-Update möglich
Jetzt kommt der Hammer:
Ich bin ja kein Freund davon, dass jeder Rechner weltweit einzigartig identifiziert werden kann. Demnach ist IP6 bei uns generell ausgeschaltet. Ich kam nun auf die Idee, das IP6-Protokoll einfach mal einzuschalten, testweise. Und das Resultat: SOFORT wurde erkannt, dass die Maschine Internet hat und ich konnte ganz normal die online-Updates fahren.
Bedeutet zunächst einmal, dass die ganzen im Verdacht stehenden Fehlerquellen wie DNS-Einträge etc. korrekt sind und die Testaufrufe funktionieren ja manuell aucb wenn nur IP4 aktiv ist.
Es ist jetzt also die neue Fragestellung: warum klappt es mit IP4 nicht ? Über IP6 funktioniert die Interneterkennung. Bei den Brüdern des Problemservers geht es ja auch mit nur IP4 aktiv.
Das IP4-Protokoll bzw. der Weg darüber hat in Bezug auf die Internetprüfung irgendwie einen Schuss weg.
Mein Gott, Walter ! .-)))
Zudem fällt bei diesem Server auf:
Die beiden Dienste "Diagnosesystemhost" und "Diagnosediensthost" stehen auf Startart "automatisch", kommen aber nicht hoch und können nicht manuell gestartet werden, weil die Option "Starten" ausgegraut ist.
Hat jemand zu diesem neuen Sachstand eine Idee ?
Gruß Walter
Zunächst meinen Dank für die vielen Hinweise und Erläuterungen. Es gibt nun einen neuen Stand, der auch einen neuen Blickwinkel auf die Problemstellung liefert.
i) Offline-Updates wurden durchgeführt .. ohne Veränderung.
ii) Wenn man die Testlinks nach Euren Anleitungen per Browser richtig aufruft -danke bacardi !- funktioniert das auch.
iii) Einträge für den NLA-Dienst in der Registry gecheckt: alles Standard bzw. korrekt laut Internetquellen
Dennoch "kein Internet" angeblich, kein online-Update möglich
Jetzt kommt der Hammer:
Ich bin ja kein Freund davon, dass jeder Rechner weltweit einzigartig identifiziert werden kann. Demnach ist IP6 bei uns generell ausgeschaltet. Ich kam nun auf die Idee, das IP6-Protokoll einfach mal einzuschalten, testweise. Und das Resultat: SOFORT wurde erkannt, dass die Maschine Internet hat und ich konnte ganz normal die online-Updates fahren.
Bedeutet zunächst einmal, dass die ganzen im Verdacht stehenden Fehlerquellen wie DNS-Einträge etc. korrekt sind und die Testaufrufe funktionieren ja manuell aucb wenn nur IP4 aktiv ist.
Es ist jetzt also die neue Fragestellung: warum klappt es mit IP4 nicht ? Über IP6 funktioniert die Interneterkennung. Bei den Brüdern des Problemservers geht es ja auch mit nur IP4 aktiv.
Das IP4-Protokoll bzw. der Weg darüber hat in Bezug auf die Internetprüfung irgendwie einen Schuss weg.
Mein Gott, Walter ! .-)))
Zudem fällt bei diesem Server auf:
Die beiden Dienste "Diagnosesystemhost" und "Diagnosediensthost" stehen auf Startart "automatisch", kommen aber nicht hoch und können nicht manuell gestartet werden, weil die Option "Starten" ausgegraut ist.
Hat jemand zu diesem neuen Sachstand eine Idee ?
Gruß Walter
Moin @MeinGottWalter,
😯 ... 😖 ... 😰
das hört sich irgendwie ganz schräg an.
Ich habe bei mir am Rechner definitiv kein IPv6 aktiviert und dennoch klappen bei diesem die Updates und auch die Verbindungserkennung, ohne Probleme.
Und auch auf den hunderten Servern unserer Kunden ist ebenfalls kein IPv6 aktiviert und auch dort habe ich ähnliche Probleme noch nicht gesehen.
Sehr interessant, du scheinst irgendwie und irgendwo, eine etwas ungewöhnliche Konfiguration zu haben.
Gute Frage, schalte mal wie hier beschrieben ...
https://learn.microsoft.com/de-de/windows-server/networking/ncsi/ncsi-tr ...
... die NCSI Protokollierung ein, dann werden wir eventuell etwas schlauer.
Gruss Alex
Ich bin ja kein Freund davon, dass jeder Rechner weltweit einzigartig identifiziert werden kann. Demnach ist IP6 bei uns generell ausgeschaltet. Ich kam nun auf die Idee, das IP6-Protokoll einfach mal einzuschalten, testweise. Und das Resultat: SOFORT wurde erkannt, dass die Maschine Internet hat und ich konnte ganz normal die online-Updates fahren.
😯 ... 😖 ... 😰
das hört sich irgendwie ganz schräg an.
Ich habe bei mir am Rechner definitiv kein IPv6 aktiviert und dennoch klappen bei diesem die Updates und auch die Verbindungserkennung, ohne Probleme.
Und auch auf den hunderten Servern unserer Kunden ist ebenfalls kein IPv6 aktiviert und auch dort habe ich ähnliche Probleme noch nicht gesehen.
Sehr interessant, du scheinst irgendwie und irgendwo, eine etwas ungewöhnliche Konfiguration zu haben.
Es ist jetzt also die neue Fragestellung: warum klappt es mit IP4 nicht ? Über IP6 funktioniert die Interneterkennung. Bei den Brüdern des Problemservers geht es ja auch mit nur IP4 aktiv.
Gute Frage, schalte mal wie hier beschrieben ...
https://learn.microsoft.com/de-de/windows-server/networking/ncsi/ncsi-tr ...
... die NCSI Protokollierung ein, dann werden wir eventuell etwas schlauer.
Gruss Alex
Hallo Alex ! Ja, diese Situation ist schräg ! Tatsachen sind:
i) Der Problemserver ist auch bei mir der einzige Rechner, der diese Zicken macht.
ii) Am 01.06.2024 sind zum letzten Mal die online-Updates gelaufen und zwar mit nur IP4 aktiv.
iii) Natürlich hat da niemand etwas verändert.
Ich lasse den Server jetzt mal 2 Tage laufen mit IP4 + IP6 aktiv und starte ihn dann mal durch und sehe mir die Situation nochmals an. Aber die Sache mit den beiden Diensten gefällt mir nicht. Zwischendurch bei der Updaterei startete einer der Dienste tatsächlich, dann zum Schluß aber wieder nicht und ist manuell auch nicht startbar.
Deine Idee mit der Protokollierung ist gut !
Gruß Walter
i) Der Problemserver ist auch bei mir der einzige Rechner, der diese Zicken macht.
ii) Am 01.06.2024 sind zum letzten Mal die online-Updates gelaufen und zwar mit nur IP4 aktiv.
iii) Natürlich hat da niemand etwas verändert.
Ich lasse den Server jetzt mal 2 Tage laufen mit IP4 + IP6 aktiv und starte ihn dann mal durch und sehe mir die Situation nochmals an. Aber die Sache mit den beiden Diensten gefällt mir nicht. Zwischendurch bei der Updaterei startete einer der Dienste tatsächlich, dann zum Schluß aber wieder nicht und ist manuell auch nicht startbar.
Deine Idee mit der Protokollierung ist gut !
Gruß Walter
Moin Kollegen !
Nach längerer Zeit hier ein Update zu diesem Problem:
Wir haben ja mehrere Server 2019 im Netz und nachdem das Verbindungsproblem zum Updateserver bzw. der unwahren Behauptung, der Rechner hätte kein Internet, ja zunächst mit einem der drei angefangen hat, trat es nun auch bei den anderen beiden auf.
Die Lösung war jedes Mal, IPv6 einzuschalten. Sofort war das Problem weg.
Aber: wir benutzen für alle Rechner im Netz die Firewall IPCop und die kann nur IPv4 !
IPv6 gab es zu dieser Zeit noch gar nicht. => die Server können sich via IPv6 gar nicht mit dem Internet verbinden !
=> Es scheint so zu sein, dass MS die Leute partout zum Einschalten von IPv6 bringen will. Eine andere Erklärung fällt mir nicht ein.
(Was in unserem Fall aber keine Rolle spielt, weil der IPCop eine Identifikation über IPv6 eh verhindert.)
Was meint Ihr ?
Gruss Walter
Nach längerer Zeit hier ein Update zu diesem Problem:
Wir haben ja mehrere Server 2019 im Netz und nachdem das Verbindungsproblem zum Updateserver bzw. der unwahren Behauptung, der Rechner hätte kein Internet, ja zunächst mit einem der drei angefangen hat, trat es nun auch bei den anderen beiden auf.
Die Lösung war jedes Mal, IPv6 einzuschalten. Sofort war das Problem weg.
Aber: wir benutzen für alle Rechner im Netz die Firewall IPCop und die kann nur IPv4 !
IPv6 gab es zu dieser Zeit noch gar nicht. => die Server können sich via IPv6 gar nicht mit dem Internet verbinden !
=> Es scheint so zu sein, dass MS die Leute partout zum Einschalten von IPv6 bringen will. Eine andere Erklärung fällt mir nicht ein.
(Was in unserem Fall aber keine Rolle spielt, weil der IPCop eine Identifikation über IPv6 eh verhindert.)
Was meint Ihr ?
Gruss Walter
Was meint Ihr ?
IPv6 nicht deaktivieren
We do not recommend that you disable IPv6 or its components. If you do, some Windows components may not function.
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking ...
Hallo CamelCase !
Danke für Deine Antwort ! Folgt man Deinem Link, könnte einem schlecht werden, denn da ist von Problemen und Aufgabenstellungen für Administratoren die Rede, die man Gott sei Dank nie hatte .. wenigstens ich nicht.
Zunächst bezieht sich Dein Link u.a. auf Server 2008 und nicht auf Server 2019. Server 2008R2 ist mein bevorzugtes Betriebssystem u.a. genau deswegen, weil keine Updates mehr kommen, welche jedes Mal eine potenzielle Gefahr für den Betrieb darstellen. Die älteren Systeme tun einfach das, was sie sollen und das jeden Tag. Und wenn man sie von außen gut schützt, passiert auch nichts.
Wir reden hier von Server 2019, die allesamt seit 2019 auch ohne IPv6 problemlos liefen bis ca. April 2024. Dann kam ein Update welches -zunächst nur auf einem der derei Server- bewirkte, dass -obwohl alle Funktionen ausser dem Update-Dienst- einwandfrei auch mit Internet (z.B. der Emailserver) liefen, unten rechts das Warnsignal "kein Internet" erschien und plötzlich Updates fehlschlugen.
Mit anderen Worten: alles war OK, bis Microsoft einmal wieder ein Update sandte, welches diese Störung verursachte. Das läßt sich ganz klar sagen: Microsoft erzeugt ein Problem, das es vorher nicht gab. So etwas nennt sich "Fehler". Und da hilft es auch nichts bzw. ist eine Frechheit, Administratoren eine ellenlange Anleitung zu geben, wie dieses Problem vielleicht behoben werden könnte. Und dabei ist auch noch "von irgendwelchen Problemen, die möglicherweise auftreten" die Rede.
Klar ist, dass die alten Systeme keinerlei Probleme dieser Art haben. Und ein LINUX-System hat mit so etwas auch ken Problem. So what ?
Jedenfalls bin ich froh, dass ich eine Lösung bzw. eher einen Workaround gefunden habe.
Prüfung auf "Internet vorhanden ?"
Doch wie es dazu kommen kann, dass ein Betriebssystem behaupten kann, der Rechner habe kein Internet, obwohl manuell und durch Programme alle Internet-Funktionalitäten laufen, ist mir nur dadurch erklärbar, dass mit dem Prüfungsmechansismus "ist Internet vorhanden ?" etwas nicht stimmt, wobei ein einfaches ping google.com bzw. einen MS-Server ja reichen würde. Wie kann man das vermasseln ?
Gruß Walter
Danke für Deine Antwort ! Folgt man Deinem Link, könnte einem schlecht werden, denn da ist von Problemen und Aufgabenstellungen für Administratoren die Rede, die man Gott sei Dank nie hatte .. wenigstens ich nicht.
Zunächst bezieht sich Dein Link u.a. auf Server 2008 und nicht auf Server 2019. Server 2008R2 ist mein bevorzugtes Betriebssystem u.a. genau deswegen, weil keine Updates mehr kommen, welche jedes Mal eine potenzielle Gefahr für den Betrieb darstellen. Die älteren Systeme tun einfach das, was sie sollen und das jeden Tag. Und wenn man sie von außen gut schützt, passiert auch nichts.
Wir reden hier von Server 2019, die allesamt seit 2019 auch ohne IPv6 problemlos liefen bis ca. April 2024. Dann kam ein Update welches -zunächst nur auf einem der derei Server- bewirkte, dass -obwohl alle Funktionen ausser dem Update-Dienst- einwandfrei auch mit Internet (z.B. der Emailserver) liefen, unten rechts das Warnsignal "kein Internet" erschien und plötzlich Updates fehlschlugen.
Mit anderen Worten: alles war OK, bis Microsoft einmal wieder ein Update sandte, welches diese Störung verursachte. Das läßt sich ganz klar sagen: Microsoft erzeugt ein Problem, das es vorher nicht gab. So etwas nennt sich "Fehler". Und da hilft es auch nichts bzw. ist eine Frechheit, Administratoren eine ellenlange Anleitung zu geben, wie dieses Problem vielleicht behoben werden könnte. Und dabei ist auch noch "von irgendwelchen Problemen, die möglicherweise auftreten" die Rede.
Klar ist, dass die alten Systeme keinerlei Probleme dieser Art haben. Und ein LINUX-System hat mit so etwas auch ken Problem. So what ?
Jedenfalls bin ich froh, dass ich eine Lösung bzw. eher einen Workaround gefunden habe.
Prüfung auf "Internet vorhanden ?"
Doch wie es dazu kommen kann, dass ein Betriebssystem behaupten kann, der Rechner habe kein Internet, obwohl manuell und durch Programme alle Internet-Funktionalitäten laufen, ist mir nur dadurch erklärbar, dass mit dem Prüfungsmechansismus "ist Internet vorhanden ?" etwas nicht stimmt, wobei ein einfaches ping google.com bzw. einen MS-Server ja reichen würde. Wie kann man das vermasseln ?
Gruß Walter
Und wenn man sie von außen gut schützt, passiert auch nichts.
Ein Trugschluss, das war einmal! Denn die meisten Angriffe kommen heutzutage aus dem eigenen LAN. Es braucht nur einen einzigen infizierten Client, der kann es sich dann per nicht mehr geschlossenen Sicherheitslücken schön bequem auf deinem Server machen ...So wie du dachten auch diverse andere Admins und deswegen wurden und werden noch immer viele Netze hier in DE gekapert, Daten verschlüsselt und Firmen erpresst, die Presse spricht ja Bände.
Zunächst bezieht sich Dein Link u.a. auf Server 2008 und nicht auf Server 2019
Internet Protocol version 6 (IPv6) is a mandatory part of Windows Vista and Windows Server 2008 and newer versions.
Wenn du Windows in einer nicht unterstützten Konfiguration (IPv6 deaktiviert) benutzt, musst du, noch mehr als sonst, damit rechnen dass mal ein Update kommt welches dir den Tag versaut.
Moin Kollegen !
Grundsätzlich hat gastric mit seinem Hinweis natürlich recht. Bloss: wenn EINE Maschine -egal ob Server oder Client- im grünen Netz einmal infiziert ist, ist natürlich High Noon und dagagen hilft sicher nicht, eine MS-Empfehlung a la "IPv6 aktivieren !" zu befolgen. Angriffe innerhalb des grünen Netzes zu parieren erfordert andere Maßnahmen, klar. Und das hat mit irgendwelchen Sicherheitslücken nichts zu tun, wenn der Teufel das grüne Netz bereits erreicht hat. Dagegen helfen bloss Virtualisierung + Snapshots, auf die man zurücksetzen kann und eine zerstörungssichere Datensicherung.
CamelCase: ok soweit, d'acord. Aber: zumindest ist die abgegebne Fehlermeldung sachlich einfach falsch, denn der Rechner HAT JA INTERNET ! Diese Fehlermeldung bzw. dieser zarte Hinweis unten rechts in der Ecke ist schlicht irreführend.
Und als ich zum ersten Mal mit dem Problem konfrontiert war, habe ich natürlich nach Lösungen gesucht und bin schon fündig geworden: da gab es allerlei Beiträge mit mehr oder weniger aufwendigen Lösungsvorschlägen. Bloss diese Lösung "IPv6 aktivieren !" war nicht dabei. Insofern kann man diese meine Erkenntnis als Lösung markieren, zumindest als eine mögliche Lösung.
Und weil der IPcop zwischen dem Server und Microsoft dazwischen hängt, kann der Update-Mechanismus, wenn er denn loslegt, auch nicht IPv6 benutzen.
Gruss Walter
Grundsätzlich hat gastric mit seinem Hinweis natürlich recht. Bloss: wenn EINE Maschine -egal ob Server oder Client- im grünen Netz einmal infiziert ist, ist natürlich High Noon und dagagen hilft sicher nicht, eine MS-Empfehlung a la "IPv6 aktivieren !" zu befolgen. Angriffe innerhalb des grünen Netzes zu parieren erfordert andere Maßnahmen, klar. Und das hat mit irgendwelchen Sicherheitslücken nichts zu tun, wenn der Teufel das grüne Netz bereits erreicht hat. Dagegen helfen bloss Virtualisierung + Snapshots, auf die man zurücksetzen kann und eine zerstörungssichere Datensicherung.
CamelCase: ok soweit, d'acord. Aber: zumindest ist die abgegebne Fehlermeldung sachlich einfach falsch, denn der Rechner HAT JA INTERNET ! Diese Fehlermeldung bzw. dieser zarte Hinweis unten rechts in der Ecke ist schlicht irreführend.
Und als ich zum ersten Mal mit dem Problem konfrontiert war, habe ich natürlich nach Lösungen gesucht und bin schon fündig geworden: da gab es allerlei Beiträge mit mehr oder weniger aufwendigen Lösungsvorschlägen. Bloss diese Lösung "IPv6 aktivieren !" war nicht dabei. Insofern kann man diese meine Erkenntnis als Lösung markieren, zumindest als eine mögliche Lösung.
Und weil der IPcop zwischen dem Server und Microsoft dazwischen hängt, kann der Update-Mechanismus, wenn er denn loslegt, auch nicht IPv6 benutzen.
Gruss Walter
