Ich stelle mal eine Beobachtung hier im Blog ein, und versuche mal die Schwarmintelligenz der Blog-Leserschaft anzuzapfen. Heute erreichten mich zwei Leserhinweise, die sich über langsame Downloads von Microsoft Updates zum Dezember 2024-Patchday ausließen. Mir ist die Nacht beim Schreiben der Patchday-Artikel aufgefallen, dass die Microsoft Supportseiten nur schlecht erreichbar sind. Liegt es an Microsoft oder an deutschen Providern?
Eine erste Lesermeldung
Stephan hat sich gestern Abend (10.12.2024, 21:48 Uhr) per Mail gemeldet und schrieb, dass er „gerade mal wieder vor den Windows Updates sitze und über die 100Mbit DSL -Leitung tröpfelt es mal wieder gewaltig“. Sprich: Die Download-Geschwindigkeiten, mit denen Windows seine Updates ziehen kann, sind bescheiden.
Stephan merkte an, dass er die schon einige Zeit beobachte und in den Foren würden auch Probleme nach der FS 2024 Start mit den Telekom Leitungen berichtet. Ist aber nur eine Randnotiz.
Seine klare Aussage: Egal, ob es nun Office 365-Update oder die Windows-Updates sind, in seiner Testumgebung werden die Pakete „über die Telekom-Leitung“ arg langsam gezogen. Der Leser schrieb: „Es ist furchtbar langsam, teilweise nur weniger 100 KBit“.
Er hat mittlerweile die Vermutung, das irgendwo ein Flaschenhals oder einer Limitierung greift. Am Firmen Anschluss der DG (wohl Deutsche Glasfaser) über die INEXIO gebe es keine Probleme, schreibt der Leser und fragt: „Vielleicht ist ihnen ähnliches zu Ohren gekommen und ich bin gespannt, ob Sie hierzu bereit andere Meldungen bekommen haben. Vielleicht ist es einen Beitrag wert, falls Sie dazu mehr Informationen haben.“
Meine eigene Beobachtung
Ich selbst hänge über 1&1 als Reseller an der Telekom Infrastruktur und habe da einen 100 MBit DSL-Anschluss, der diese Rate auch liefert (in 123 Meter Entfernung ist ein Glasfaser-Übergabepunkt). Ich habe es nicht explizit beobachtet, aber die Updates scheinen zügig eingelaufen zu sein, heute Früh standen die zur Installation an.
Ich beobachte aber seit dem November 2024-Patchday, dass es Probleme gibt, auf die Supportbeiträge von Microsoft zuzugreifen. Auch heute Nacht war es zeitweise für mich kaum möglich, beim Schreiben der Beiträge zum Patchday auf die Microsoft Supportbeiträge zuzugreifen.
Rufe ich beispielsweise die Microsoft-Webseite für die Windows 11-Update-Historie auf, wird diese sofort im Browser geöffnet. Aber beim Versuch, die Details zu einem Update abzurufen, wird mir mit „The request ist blocked“ abgewiesen (siehe obigen Screenshot). Versuche ich es einige Sekunden später oder machen einen Refresh im Browser, erscheint die Microsoft-Seite.
Das Bild wird bereits seit einiger Zeit im Internet diskutiert. Einen ersten Treffer aus dem Jahr 2020 habe ich auf Microsoft Answers gefunden. Ursache könne ein Proxy sein, der automatische Anfragen an Microsoft sendet. Microsoft hat wohl Mechanismen laufen, die „zu viele Anfragen während eines Zeitraums“ blockieren. Hier scheint möglicherweise ein maschinen-lernender Filter jetzt sehr stringent zu agieren und blockt alles, was über einen Provider und dessen Proxy kommt.
Es gibt noch einen MS Answers-Foreneintrag aus Mai 2024 mit der Fehlerbeschreibung. Hier konnte das Problem wohl an AVAST festgemacht werden. Das kann ich alles aber ausschließen, da nur der Microsoft Defender läuft.
Beobachtungen eines zweiten Lesers
Blog-Leser Joachim hat sich mit diesem Kommentar gemeldet, und berichtete, dass er am gestrigen Abend im Umfeld des Dezember 2024-Patchday etwas Interessantes festgestellt habe. Er hat nämlich beobachtet, dass ein „paar Maschinen das Update extrem langsam heruntergeladen haben“.
Der Versuch, die Pakete aus dem Microsoft Update Catalog herunter zu laden, lieferte das gleiche Bild. Er schrieb „Ich war ja remote, also am heimischen Anschluss getestet, auch hier das gleiche.“ Beim Test über Hotspot am Handy waren die Download-Durchsätze dagegen normal – wenn die Downloads über die Mobilfunkverbindung dann nur mit Abbrüchen fertig wurden. Ein klares Indiz, dass der reduzierte Download-Durchsatz etwas mit dem DSL-Provider zu tun haben.
Joachim schreibt, dass alle anderen Download-Tests (z.B. bei Nvidia) wie gewohnt schnell durchführbar waren. Er fragte dann: „Fall gelöst? Schuld hat MS?“ und kam zum Schluss „eher nicht“. Denn er hat am heutigen 11.12.2024 am Morgen noch experimentiert. Dabei ist ihm ein kurioser Sachverhalt aufgefallen (eine Gemeinsamkeit aller getesteten Anschlüsse):
- Wird als DNS-Server sei es im Domain-Controller, oder manuell, oder im Router, der Google DNS-Resolver 8.8.8.8 verwendet, sind den Downloads meistens extrem langsam.
- Verwendet der Leser den Telekom-DNS oder Cloudflare, werden die Downloads von Microsoft gewohnt schnell abgewickelt.
Der Leser konnte dieses Verhalten zu 90 % an insgesamt 5 Anschlüssen nachstellen. Maßnahmen, wie den DNS-Cache leeren, änderten nichts. Die Routenverfolgung sieht bei beiden Resolvern natürlich anders aber, schrieb Joachim. Er meint: „Aber dass es am Ende nur bei Microsoft-Downloads langsam ist, und beim Rest nicht, ist schon merkwürdig“ und fragt: „Hat sowas schonmal jemand erlebt, kann es bestätigen oder erklären?“
Ich habe mal auf die Schnelle bei mir geschaut – in der FRITZ!Box ist die Vorgabe den DNS-Resolver des Providers zu verwenden. Ein nslookup liefert mir die IPv6-Adresse fd00::e228:6dff:fe73:7688 zurück.
Auf dieser Webseite wird mir AS8881 1&1 Versatel Deutschland GmbH und die Mainova AG als ISP angegeben (die könnten was im Auftrag von 1&1 Versatel lokal als Exit-Knoten abwickeln, so meine Vermutung – aber ich kann mich täuschen). Mein Schluss ist, dass Microsoft da irgendwo eine Drossel eingebaut hat, die die Abfragen aus bestimmten IP-Bereichen der Provider bremst. Oder hat jemand eine Erklärung?
Ergänzung: Die Folgen habe ich im Artikel Windows: Wie langsame DSL-Verbindungen den WSUS kicken beschrieben.
Erkärung wird vermutlich die gleiche wie sonst auch sein: Die Peering-Politik der DTAG ist schuld.
Nicht schlimmer als sonst. Durchgängig volle Transferrate hatte ich bei den Updates noch nie. Das ging schon immer häppchenweise. Egal ob Telekom DSL oder TV-Kabel.
Bei 5 Rechner heute über die gleiche Leitung Updates gezogen.
4 waren ziemlich nochmal (24H2, 23H2, 2022, Win 10).
Der letzte Rechner hinkte voll beim Download (24H2).
Ja, das wird das übliche und auch bekannte Peering-Problem, der Telekom (AS3320), sein. Hat der Anbieter keinen Sondervertrag mit der Telekom, ist ab einem gewissen Traffic-Verbrauch schluss und der Seitenaufbau wird langsam. Einzige Möglichkeit, um dem dann zu entkommen ist, einen Internet-Provider nutzen, der kein AS3320 nutzt, einen VPN-Anbieter wie Mullvad oder Proton nutzen, oder einen VPS bei Netcup, Hetzner oder OVH buchen und seine eigene VPN nutzen (die Anbieter haben so einen Sondervertrag mit der Telekom) :D
Naja, da setzt sich die Telekom aber in rechtliche Nesseln!
Denn es gilt in der EU und somit auch in Deutschland die Netzneutralität, d.h. niemand darf bzgl. Geschwindigkeit benachteiligt oder bevorzugt werden.
Die Telekom hatte da ja mal entsprechende Mobilfunktarife.
Die wurden alle per Gerichtsurteil wegen Verletzung der Netzneutralität gekippt.
https://www.bundesnetzagentur.de/DE/Vportal/TK/InternetTelefon/Netzneutralitaet/start.html
Interessiert die Telekom allerdings nicht unbedingt. Deren Peeringpolitik ist auf Doublepaid ausgelegt. Hetzner ist vor Jahren eingeknickt und zahlt jetzt. Dadurch läuft es besser. Die anderen ISP wie Vodafone oder TEF haben die Probleme nicht. VPN kann helfen.
naja wen sie aktiv Drosseln hats du recht, wenn sie aber einfach nur „schlechtes Peering“ haben ist das halt nen technischer Umstand…
nicht schön, aber ist aber eben so…
Wobei ich seit Jahrzehnten Telekomkunde bin (mit mal zwischendrin kurz ein anderer lokaler Provider) und mich weder wegen übermäßigen Störungen (naja wenn ein Baggerfahrer eine Leitung kappt kann man das nicht der Telekom anlasten, war aber innerhalb 6h behoben) noch schlechtem Peering beschweren kann… die angegebenen und gebuchten Geschwindigkeiten stehen an und übertreffen diese teilweise sogar…das dir auch eine Standleitung nichts bringt, wenn der angesprochene Server nicht mehr hergibt sollte klar sein.
Das Problem mit AS3320 ist aber wirklich schon seit Jahren so wie beschrieben. Das das ganze nicht im Sinne der Netzneutralität ist würde ich auch so einstufen da die Telekom dies bewusst tut, aber wer soll da der Kläger sein? Die Lobby Boys der EU sicherlich nicht. Zwischen drosseln und bewusst einfach nicht genug Bandbreite zur Verfügung zu stellen ist auch einfach viel Spielraum für Pressetexte….
Bei uns war der Download letzten Monat extrem langsam. Diesen Monat habe ich aber nichts besonderes feststellen können. Sowohl per WSUS, als auch per Windows Update lief es wieder normal.
Wir nutzen WSUS somit ist das kein Thema für uns.
der DL von MS zum WSUS könnte natürlich auch betroffen sein.
Der war bei uns aber auch normal.
Das stimmt. Da diese Updates aber erst am Abend von MS freigegeben werden darf das auch mal etwas länger brauchen.
Hier an der Telekomleitung kein Problem.
Ist mir auch aufgefallen – diesmal besonders langsam – der eine PC hat ca. 250 MB Anbindung und das windowsupdate tröpfelte kb-weise herein, um immer wieder dazwischen ganz auf Null zu gehen – nach 50 min habe ich abgebrochen (abends) – der andere PC heute Morgen dauerte ca. 2h, bis alles bei mir war (ein anderer Provider am anderen Standort).
Mir ist aber schon seit Tagen was zweites aufgefallen: der battle-net-Downloader (wow – Blizzard) ist für aktuelle Spiele sehr schnell (fette 250 MB – wie erwartet) und für praktisch alle „classic-Spiel“ (der selbe battle-net-Downloader !) dauert es bei mir gefühlt eine Ewigkeit, bis er aus dem „Aktualisieren“ herauskommt und auf der Leitung passiert absolut gar nichts – so was kann meiner Meinung nach kein Zufall sein – es nervt bei Onlinespielen, weil man warten und warten muss (gerne mal 1h) und absolut nichts machen kann – bis man spielen „darf“… (bei diesen Spielen bezahlt man wohl gemerkt die Spielzeit !).
DNS Einstellungen haben erstmal wenig mit dem Routing und Peering zu tun. Irgendwelche Versuche mit anderen DNS Resolvern sind daher sinnfrei.
In 90% der Fälle lässt sich das auf irgendwelche zwischengeschaltete Hyperskaler wie Clownflare oder schlicht langsame Infrastruktur auf Seiten Microsoft zurückführen wozu der Screenshot „your request is blocked“ passen würde.
Da war ja was kürzlich beim Start von MSFS2024..
Doch hat es, Stichwort Geolokalisierung in Bezug auf CDNs. Sollte man sich unbedingt mal mit beschäftigen wenn man das noch nicht getan hat!
Ich denke dann solltest Du mal schnell selbst nachschlagen… die Stichworte haben ich weiter unten gegeben.
Dann mal selbst nachschlagen, Stichwort GeoDNS. Es ist durchaus möglich, dass du an unterschiedlichen Orten auf der Welt, unterschiedliche IP-Adressen vom DNS-Server geliefert bekommst. Ergo kann hier DNS doch eine Rolle spielen.
„Clownflare“ lässt auch schon wieder tief blicken, mir ist schleierhaft, wieso man ein Beitrag nicht einfach wertfrei und ohne solche Nickligkeiten schreiben kann.
Ach Tomas, du und dein Hate ggü. Microsoft…
Microsoft nutzt Akamai als CDN für Windows Updates und etliche ihrer Seiten.
Zudem liegst du gewaltig daneben mit der Aussage des geringen Zusammenhangs von DNS und Routing/Peering. Den falschen Resolver Host angefragt und eine unpassende IP aus einem CDN zurück bekommen und schon hast du eine ultra lahme Verbindung. Ein Großteil der Daten im Internet liegt eben nur leider in diesen großen CDNs verteilt um den Globus. Das trifft bestenfalls nicht auf kleinere Auftritte zu, wo eine Domain exakt auf eine IP aufgelöst wird und diese exakt auf ein System irgendwo am Netz angeklemmt, hinzeigt. Sogut wie alles, wo Verfügbarkeit irgendwo gegeben sein muss, wird über Redundanzen verfügen. Um so größer, um so mehr wird man sich da auf den Kopf stellen um Ausfälle zu vermeiden.
Im Falle der Windows Updates liegen die Daten aus (von Microsoft gesehen) dezentralen Cachingservern, die Akamai betreibt, wild über den Globus verteilt. Der Sinn dahinter ist eben gerade, dass man den lokal für sich optimal erreichbaren Server bekommt -> und das geht über DNS und nix anderes.
Ich kann mit der richtigen DNS Auflösung binnen weniger als 10ms die Download URL für Windows Update Files erreichen oder eben die selbe URL mit falscher Auflösung erst über die USA oder sonstwo bekommen, was entsprechend lahm ist. Im Extremfall bekommst du mit der falschen DNS Auflösung gerade bei US Firmen dann Systeme aus der USA mit 100ms und mehr zurück, obwohl in Zentraleuropa, ja selbst im eigenen Land (Frankfurt, Berlin bspw.) Cachingsysteme direkt vor der Haustür stehen.
Als User merkt man das nur bedingt, es ist nicht so dass es gar nicht geht (meistens zumindest) sondern es ist halt einfach nur langsam.
Dir sagt der Begriff Anycast und BGP aber schon was, oder?
Sehr wahrscheinlich macht die Telekom selbst Anycast für Ihre DNS.
Das bringt nur gar nichts in dem Fall.
Denn wenn man im Telekom Netz sitzt, und einen CDN findet für die Windows Updates, dieser aber nicht im Telekom Netz ist (oder am falschen Ende des Telekom Netzes), kann es sein dass dieser langsamer ist als erwartet.
Dass die Telekom genau diesen Umstand, ausnutzt um Partner zu vergüteten Peering zu zwingen ist seit Jahren bekannt.
(https://www.welt.de/wirtschaft/article117963991/Bei-Europas-Telekom-Riesen-ist-die-EU-unpatriotisch.html)
Ansonsten wäre es einfach zu lösen, die Telekom könnte Informationen zum eigenen CDN mit Google/Quad9/Cloudflare teilen.. und schon gäbe es das Problem nicht.
Haha, also P.B. scheinen die Begriffe durchaus etwas zu sagen, dir aber ganz offenbar nicht (oder schlicht das falsche).
Insofern, Ball flach halten und nicht so passiv aggressiv auftreten. Auch du hast die Weisheit nicht mit Löffeln gegessen.
EDNS Client-Subnet submission sagt dir aber schon was, oder?
Auffälligkeiten beim Zugriff auf die MS-Supportseiten kann ich momentan nicht beobachten, auch letzte Nacht nicht, inklusive manueller KB-Downloads für Win11. Die automatischen Updates selber sind bekanntlich sowieso eher gemächlich, vor allem am Beginn der Patchtage.
Google DNS am Telekom Internetanschluss ist eine ganz schlechte Idee. Denn die Geolokalisierung bei CDNs funktioniert oft so das dem anfragenden DNS-Server IPs in seiner Nähe geliefert werden. Der Google DNS löst daher häufig IP-Adressen aus Frankfurt mit guter Verbindung zum DE-CIX auf. Die Telekom peert aber schlecht am DE-CIX und daher sind diese Leitungen von der Telekom zu Google, Microsoft und Co am DE-CIX eigentlich immer dicht. Das schlechte Peering der Telekom ist aber eigentlich ziemlich bekannt. Ein ähnliches Problem kann z.B. auch mit den Quad9 DNS in Verbindung mit dem EPIC-Store auftreten, da bekommt man dann immer mal wieder die Meldung das man keine Lizenz hätte. Einfach mal einen anderen DNS Server nutzen ist oftmals keine gute Idee mehr bzw. eigentlich nur was für Profis!
Wenn man mal in die Übersicht bei allestörungen schaut, so erkennt man, dass gestern etliche Internet-Provider Probleme hatten. Bei Vodafone gab es schlagartig ab ca. 0:30 Uhr für rund 3 1/2 Stunden sogar einen Totalausfall, jedenfalls hier im Großraum Kiel.
Ich denke hier gibt es kein wirkliches Problem in dem Sinne, dass da was falsch läuft.
Siehe meine Äußerung als Antwort auf den Post von Joachim im oben verlinkten Blockpost.
https://www.borncity.com/blog/2024/12/11/patchday-windows-10-server-updates-10-dezember-2024/#comment-202561
DNS Server verschiedener Anbieter liefern möglicherweise unterschiedliche IPs für die selben URLs zurück. Und je nach ISP (Telekom und Vodafone vor allem im Kabelnetz) kann das zu Bandbreitenlimits bzw. Übergangsproblemen führen.
Weiterhin wird gerade bei solchen Dingen wie Windows Updates häufig mit wild wandelnden IPs gearbeitet. Je nach dem wie oft man den selben! Resolver Host anfragt, bekommt man im Zweifel verschiedenste IPs zurück. Das geht in Richtung Round Robin zur Verteilung der Anfragen.
Weiterhin kann es noch einen massiven Unterschied machen, ob man das Ziel via IPv4 oder IPv6 ansurft. Je nach Anschluss, Stichwort CGN bei DS-Lite Anschlüssen.
Mal als Schnelltest – ich suche via https://www.catalog.update.microsoft.com das aktuelle Windows 11 24H2 2024-12 Update File. Die Download URL zeigt auf: https://catalog.sf.dl.delivery.mp.microsoft.com
Nehme ich allein nur diese Domain und ratter die im Sekundentakt gegen die 1.1.1.1 als Resolver, bekomme ich schon bestimmt 5, 6 verschiedene v4 IPs zurück. Zzgl. noch v6. Dann nehme ich wahlweise mal zwei aus komplett unterschiedlichen Segmenten und prüfe die Antwortzeit habe ich Unterschiede von teilweise über 20ms.
-> Im traceroute sieht man dann, dass bspw. die 104.103.72.75 über Berlin letztlich nach Wien geht. Das ist also irgendwo ein System was in Österreich steht.
Die 2.19.213.88 bspw. wird schon interessant geroutet. Es geht über Berlin nach Frankfurt nach Berlin. Ich habe hier schon 26ms zu 39ms – den deutlich schlechteren Weg.
In meinem Test ist das hier jetzt aber ein Rechenzentrum als Quelle. Also kein Telekom Anschluss.
Mache ich den Quertest von einem Telekom Anschluss und frage die selben DNS Resolver an, so bekomme ich im Zweifel die selben IPs zurück. Die besagte 104.103.72.75 von einem Telekom Anschluss wird über den Atlantik geroutet. Nämlich über Washington. Es kommt zwar dann auch an, nach 110-115ms. Aber lahm(er) als lokal ist das alle mal. Dafür ist die 2er IP vom Telekom Backend direkt erreichbar, weil die Telekom ein direktes Peering mit Akamai hat und ich das hier von meinem Standort per 8ms erreiche. Wer näher dran sitzt, schafft das in unter 5 bis sogar runter auf 1-2ms.
Unterm Strich – es ist hier in dem Zusammenhang extrem wichtig, dass die DNS Server die man für die Namensauflösung anfragt, die richtigen und für den jeweilig eigenen Anschluss passenden IPs zurück liefern um nicht bei größeren CDNs erst durchs ganze Land oder den halben Erdball geschickt zu werden.
Ob man hingegen direkt den DNS Resolver des lokalen ISPs nutzen sollte, ist eine andere Debatte. Wahrscheinlich macht der gesunde Mix das beste Ergebnis. Also bspw. könnte man *.akamai.com lokal an den ISP Resolver schicken und den großen Rest über 1.1.1.1, 8.8.8.8 oder 9.9.9.9 oder sonstwen auflösen lassen um alles was Akamai für einen Anbieter hostet, möglichst optimal passend zum eigenen Anschluss aufgelöst zu bekommen.
Im kleinen ist das durchaus so praktikabel. Im größeren mit verteilten Standorten und lokalem INet Ausgang wird das schon mehr Config Aufwand.
Ich habe heute Nachmittag Office über das ODT runtergeladen, hat über 2 Stunden gedauert über ne 50mbit Leitung… Letzte Woche ging das wesentlich schneller.
Habe eben mal testweise Cu14 für Exchange heruntergeladen mit ca. 6 GB
Geschwindigkeit 110 MB/sec, also wie immer.
Provider WilhelmTel Glasfaser
Direkt Telekom Fibre/VDSL keine Probleme…
Wird heruntergeladen – 0%
Telekom 8.8.8.8 mit webproxy bei netcup
Hi…
An VDSL50-Leitung des rosa Riesen mit (permanentem) 1.1.1.2 DNS-Resolvereintrag im Router problemlos in unter einer Minute mit bis zu 7,2Mb/s gedownloadet.
Hatte ich im Rahmen meiner jetzt bereits (vor Corona) mehrjährig andauernden T-Kundschaft auch niemals Schwierigkeiten bei M$.
Kann die Problematik und das ständige Peering-Geschimpfe echt nicht nachvollziehen. 🤷♂️
Ich hatte das Problem beim letzten Patchday – aber mit dem Inteltreiberupdatepaket.
Windows 10 Pro (aktuelle Version) Patches wurden normal heruntergeladen,
aber das Intelpaket extrem langsam. Dann waren die Win 1o Pro updates fertig
installiert und es wurde neu gestartet und das Intelpaket startete danach erneut bei 0%.
Hat insgesamt 2 Stunden gedauert, aber am Ende konnte es erfolgreich installiert werden. Telekom 100MB/s an einem Telekom Router mit Standardeinstellungen D.
P.S. Bin technisch nicht so versiert und kanns nur beobachten, aber vielleicht kann sich jemand mit mehr Wissen einen Reim drauf machen: Beim Win10 Patchday im Juni und Juli dieses Jahres blieb der Download zwischen 50% und 80% jeweils einfach hängen. ÜbertragungsLED am Router blinkte dann auch nicht mehr. Ein Speedtest funktionierte aber einwandfrei und da blinke auch die RouterLED wieder. Der Windowsdownload war einfach eingefroren – ohne Fehlermeldung. Konnte völlig normal einen Neustart durchführen und dann wurde der Download an der jeweiligen Stelle weitergeführt und lief auch schnell + die Installation konnte problemlos abgeschlossen werden. War beide male das gleiche Verhalten. Jetzt schaue ich immer, dass ich etwas warte mit den WinPatches und eine Zeit wähle (9-10 Uhr morgens), wo in USA nicht so viel los sein dürfte. Seither hatte ich das Problem nicht mehr … kanns nicht kommentieren, nur beobachten und beschreiben, wie es war.
Aha… Das erklärt dann wohl auch warum ein Office 365 Setup ewig braucht und nicht fertig wird.
Hat nun nichts direkt mit diesem Windows Update Download Topic zu tun, aber sowas gibt es ja schon ewig. Wir hatten bei jedem Standort vorher immer den selben ext. DNS Server verwendet. Dieser passte natürlich nicht immer zum lokalen Internet Provider. Der unterschied ist eigentlich immer nur beim Geräte Staging aufgefallen. Dass diese obwohl das Image identisch ist, unterschiedlich lange gedauert hatten. Nach dem bei allen Standorten immer der vom lokalen Provider zugehörige empfohlene DNS Server verwendet wurde, waren diese zeitlich identisch. Das sieht man auch im Firewall Log das je nach Provider geo Location die URLs unterschiedliche IPs hatten vorher waren diese identisch.
Weil grade das Update bei mir tröpfchenweise reinkam hab ich mal testweise von dem zentralen unternehmensanschluss (telekom) auf eine andere Leitung gewechselt während der Download erst bei 20% nach einer Viertelstunde war. Nach einem kurzen Moment des Einschwingens ist der Download dann an der anderen Leitung förmlich durchgerannt mit 50 Mbit/s.
Mal beobachten. Ein Engpass der zentralen Leitung kann ausgeschlossen werden, andere Downloads gingen extrem zügig
Seit etwa zwei Monaten habe ich bei zwei meiner Kunden sehr geringe Download raten mit MS und Adobe. Einmal Telekom Vdsl 50mbit, einmal Telekom Glasfaser 100mbit. Mein eigener Vdsl 250 bei 1&1 ist dort schnell wie immer. Überall Standard DNS vom Provider
Woher soll man denn genau wissen, ob der Download tatsächlich „langsam“ ist? Erstens weiß man nicht wie groß der Download ist, zweitens gibt Windows keinen brauchbaren Status aus. Manchmal friert sogar einfach die Fortschrittsanzeige ein und erst wenn man die Settings-App beendet und neu aufruft, sieht man wieder den aktuellen Stand.
Gelegentlich schaue ich mir an, was auf dem Netzwerkadapter los ist – da lässt sich erkennen, ob Daten tröpfeln oder richtig fett durchlaufen.
Ein Glück habe ich wieder einen rettenden Artikel bei Günter gefunden :). Kann ich die Fehlersuche abbrechen.
Diesen kann ich den Kunden übermitteln. DANKE
„officecdn.microsoft.com“ Download fast nicht möglich, stundenlanges Warten..extreme Schwankungen der Downloadgeschwindigkeiten. Anschluss des Unternehmens bei Telekom 100 Mbit/s. Download über Vodafone zum Test, normale Geschwindigkeiten.
Gleiches hatte ich im Oktober bei Downloads über Sage.com erlebt..