[English]Kleiner Nachtrag vom 27.12.2024. Microsoft war zu diesem Zeitpunkt gezwungen, die Download-Adressen für .NET-, PowerShell-Scripte und Win32-Anwendungen zu ändern. Hintergrund ist die Insolvenz von Edgio (Limelight Networks).
Es gibt zwei Fundstellen, die mir diesbezüglich untergekommen sind. Einmal gibt es die Microsoft Message Center-Nachricht MC964310, in der Microsoft die Änderung der Netzwerkendpunkte für Win32-Anwendungen und PowerShell-Skripte bis zum 27. Dezember 2024 bekannt gegeben hat.
Summary
Update network endpoints for Win32 apps and PowerShell scripts by December 27, 2024, due to Edgio retirement. Ensure access to new CDN endpoints to maintain functionality for Intune deployments. Refer to the provided links for the updated list of CDN endpoints and update firewall rules accordingly.
More information
On December 27, 2024 as a result of the Edgio retirement, we are updating the required CDN endpoints for Win32 apps and PowerShell scripts. Refer to Network requirements for PowerShell scripts and Win32 apps for the updated list of CDN endpoints required for your tenant location.
How this will affect your organization:
If you are using Intune to deploy PowerShell scripts or Win32 apps, you will need to grant access to the updated endpoints for your location. If access to these endpoints is not granted, users will not be able to install Win32 apps and PowerShell scripts will fail.
What you need to do to prepare:
Update your firewall rules to include the new CDN endpoints for Win32 apps and PowerShell scripts: Network requirements for PowerShell scripts and Win32 apps
- A list of CDNs required for Windows can be viewed at the following link: Netzwerkanforderungen für PowerShell-Skripts und Win32-Apps
- A list of CDNs required for macOS can be viewed at the following link: Netzwerkanforderungen für macOS-App- und Skriptbereitstellungen
Anmerkung: Ich habe ich obiger Meldung die Angabe „Edgeio“ in „Edgio“ korrigiert, da dies der neue Name von Limelight Networks ist. Dies ist der Betreiber eines privaten globalen Glasfasernetzwerkes und Entwickler einer cloud-basierten Digital Presence Management Plattform, die digitale Kommunikation zusammenführt. Microsoft hat dieses CDN genutzt – aber Edgio hat im Herbst 2o24 einen Insolvenzantrag gestellt.
Die zweite Fundstelle gab es bei Dr. Windows und bei deskmodder.de, die auf den Blog-Beitrag Critical: .NET Install links are changing hinwiesen. Dort gab Microsoft bekannt, dass man die Download-Adressen für .NET-Installationsprogramme und Archive unerwartet ändern musste.
Hintergrund ist, dass Microsoft mehrere Content Delivery Network (CDN)-Instanzen für die Bereitstellung von .NET-Builds verwenden. Einige enden mit azureedge.net. Diese Domains werden von edg.io gehostet, das seinen Betrieb aufgrund eines Konkurses bald einstellen wird. Microsoft ist daher gezwungen, auf ein neues CDN zu migrieren und verwendet in Zukunft neue Domains.
Betroffen sind die Domains:
dotnetcli.azureedge.netdotnetbuilds.azureedge.net
Neue CDNs:
- Official builds:
builds.dotnet.microsoft.com - CI builds:
ci.dot.net
Nicht betroffen sind:
dotnet.microsoft.comdownload.visualstudio.microsoft.com
Man hat also Kernfunktionen auf Drittfirmendomains verlinkt, absolut haarsträubendes Sicherheitsverständnis.
Unsinn, warum sollte das ein Problem sein? Der Sinn dahinter ist ein CDN zu nutzen um die Last zu Verteilen und Spitzen abfedern zu können. völlig unnötig wäre, wenn Microsoft ein eigenes CDN hochzieht, weil es sowas auch von extern einkaufbar gibt. Blöd wenn der Dienstleister pkeite geht, aber shit happens… Für andere Dienste nutzen sie btw. Akamai.
Wer wie hier keine Kontrolle über die genutzten Domain/DNS hatte, hat bzgl. Sicherheit versagt.
Haben sie doch? Microsoft gehört azuredge.net. Dein Einwand ist völlig an der Realität vorbei. Man hat hier volle Kontrolle und nutzt diese Kontrolle um vor Abschalten der Server eben die Endpunkte zu ändern, sodass negative Auswirkungen schlicht quasi nicht auftreten werden. Man hat sich bewusst für ein solches Verfahren entschieden. Was im übrigen bis auf kleinst Angebote die gängige Praxis ist heutzutage. Sogut wie alle trafficlastigen Angebote nutzen CDNs.
Aber es ist einfach immer zu meckern anstatt das Problem mit einer Lösung zu beseitigen. Wie willst du die Anforderung von Millionen Zugriffen Weltweit in kurzen Zeitintervallen wenn nicht mit einem CDN abfedern? Inkl. der Flexibilität der Datenreplikation so eines CDN mit verteilten Caching Servern über den Erdball?
Sie haben das Problem nicht verstanden. Hätte man die Kontrolle über diese Domains, müsste man nichts aber auch gar nichts an Endpunkten oder Powershell Scripts ändern…
Artikel genauer lesen: „Einige enden mit inazureedge.net. Diese Domains werden von edg.io gehostet, das seinen Betrieb aufgrund eines Konkurses bald einstellen wird.“
Nix für ungut, aber ich verstehe mehr als genug vom Thema, entgegen Ihrer Aussage, die klar zeigt, dass Sie absolut gar nix verstehen. Eindach mal vom hohen Ross runter kommen wenn man nichtmal die Basics versteht. Sorry, das nervt einfach nur noch wie abgehoben manche sich im Internet benehmen.
A) Der Artikel enthält einen Fehler, der offenbar aufgrund der Kette sich aufeinander beziehenden Meldungen her führt. @Günter
Es gibt „inazureedge.net“ nicht, die Domain ist nicht registriert!
B) Der Fehler kommt wohl, weil in der englischen Quelle steht: „We maintain multiple Content Delivery Network (CDN) instances for delivering .NET builds. Some end inazureedge.net.“
Das ist nicht nur ein Fehler beim Verbreiten der Meldung sondern ein Copy&Paste Problem, da das Leerzeichen zwischen „in“ und „azureedge.net“ nicht mit kopiert wird, in der Quelle aber angezeigt wird.
Ihre komplette Aussage bezieht sich also auf etwas, was komplett irrelevant für das Thema ist. Die Domain um die es geht ist wie eingangs gesagt, „azureedge.net“ (ohne „in“) und die gehört nachweislich Microsoft.
Fakt ist: Microsoft verwendet bisher hier Domainnamen über die sie keine Kontrolle haben. Daher müssen diese Domains jetzt manuell geändert werden. Lesen Sie einfach die Quellen. Hätte Microsoft Kontrolle über die Domains, könnte einfach der DNS darin auf andere CDN-Server angepasst werden.
Nochmal, die Behauptung ist falsch. Es ist Microsoft denen die Domain gehört, also haben sie volle Kontrolle über die Ei träge. Da gibt es nix zu diskutieren, weil es schlicht belegt ist. Keine Ahnung was das soll…
Sie haben sich bewusst für andere Namen entschieden. Sei es aus Gründen eine Zeit parallel fahren zu können oder auch um bspw. „azure“ im Namen weg zu bekommen.
Das ändern des Ziels vom CNAME wäre ein harter Cut gewesen, binnen weniger Minuten bis maximal weniger Stunden würden alle Zugriffe dann am neuen Ziel System ankommen und würde damit alle Beteiligten vor ein Problem stellen, die eben ihre Internet Zugriffsregeln nicht angepasst haben. DAS ist schlicht nicht wünschenswert die halbe Welt unnötigerweise i so ein Problem rennen zu lassen. Also gibt es neue Domains und als Fallback geht es noch eine Zeit weiter mit den alten Namen. Damit haben alle Beteiligten Zeit ihre Regel anzupassen und es kommt zu weniger Problemen.
Ich hab es jetzt nochmal konkret nachgelesen.
https://github.com/dotnet/core/issues/9671
Fakt 1)
Die „azureedge.net“ Domains verwenden den Traffic Manager, was ein auf DNS Namensänderung basierter Lastenausgleich ist um Traffic zwischen verschiedenen CDN Endpunkten zu verteilen.
Fakt 2)
Seit 27.12.24 wird das CDN von edge.io NICHT mehr angesprochen, der Traffic wird/wurde zu Akamai verlagert.
„Users should not consider azureedge.net to be a long-term usable domain. Please move to the new domains as soon as possible. It is likely that these domains will be retired in the first half on 2025. No other party will be able to use them. We are not able to control the timing of these events.“
Im Endeffekt schreibt das zuständige Team, dass sie keine Kontrolle über die genauen Zeiten haben. Aber man wohl H1/2025 noch weiter die alten URLs nutzen kann.
Es sind also zwei paar Schuhe. Wie ich bereits sagte. Das Abschalten der alten CDNs (bereits erfolgt) und das Nutzen neuer Namen (bereits möglich, aber noch nicht zwingend nötig)
Das inazureedge.net ist in azureedge.net korrigiert – danke. Ansonsten mäandert die Diskussion wieder weit ab vom Thema: Wer betroffen ist (Entwickler) muss die URLs anpassen – darum ging es im Beitrag.
@Günter, das ist natürlich vollkommen richtig, dass die Nutzer tätig werden müssen. Aber mal Hand aufs Herz, wie hätte es besser laufen können?
Wird ein Projekt nicht mehr aktiv betreut, ist es auch relativ egal ob da eine URL ins leere zeigt in Zukunft oder nicht. Und wenn etwas aktiv betreut wird, wird es eben angepasst.
Ich kann die Panik in den Kommentaren nicht verstehen. Dein Hinweis ist richtig und gut, aber die Panik und der Gegenwind der Anti Microsoft Fraktion ist mMn nur peinlich. Da passieren ganz andere wildere Dinge am Markt als so ein Firlefanz. Aber wahrscheinlich haben die meisten Leute einfach zu wenig zu tun und können sich über solch wenig problematischen Kram aufregen.
Den „Gegenwind“ kann ich schlecht steuern, es sei denn, ich lösche alle diesbezüglichen Kommentare. Möchte aber so wenig wie möglich hier moderieren.
Aber again: Mir ging es nicht um Gegenwind – ich bin inzwischen längst aus diesem „täglichen Geschäft“ raus, blogge entspannt unter einer Win 10 IoT Enterprise LTSC und frickele immer mal wieder mit Linux herum. Es gäbe also für jeden, der unzufrieden ist, genügend Alternativen – imho.
Wieder ein Negativ-Beispiel für die Verwendung externer (fremder) Resourcen.
In der heutigen Zeit sollte es doch egal sein, wohin ein DNS-Eintrag letztlich zeigt (wenn man ihn unter eigener Kontrolle hat).
Das ist gar nicht das Problem. Microsoft verwendet einfach neue/andere CNAMES in Zukunft. azureedge.net gehört ihnen doch.
Das Thema ist eher, dass ein Umbiegen der selben Domains einen harten Cut bedeutet, während man so einfach zeitweise parallel fährt. Die bisherigen Domains könnten so als Fallback bspw. noch fungieren.
Zudem Azure als Begriff ja irgendwie heute nicht mehr so intensiv genutzt wird. Davon weg zu gehen ist also auch nicht verwunderlich.
Wohin die Domains zeigen ist letztlich wirklich relativ egal, einzig der Umstand, dass in URL Freigaben eben zusätzlich diese Domains mit hinterlegt werden müssen ist für die Nutzer ein Problem. Aber das wird dann nachgetragen und gut ist… Zumindest in größeren Umgebungen. Im kleinen wird weniger häufig ausgehender Traffic gefiltert.
Aber inazureedge.net gehört ihnen nicht. Artikel lesen…
Ne, nicht Artikel lesen sondern Quellen lesen!! Glaubt nicht jede Meldung ungeprüft nur weil ihr immer die gleichen News von den selben Personen konsumiert.
„inazureedge.net“ gibt es nicht.
Das ist einfach nur dumm und dilettantisch von MS, nicht mehr und nicht weniger. Aber manche lernen es halt nie…
Ich vermisse „Copilot“ in der neuen URL …
Guten Rutsch
.nsa
Bald kommt der DNS-DNS von Microsoft?
lustig war es auch als MS die cnames der Update Server für embedded Windows einfach umbenannt hat, weil dem Marketing die Namen nicht mehr gefielen, aber in der Microsoft Update Software noch die alten Server Namen fest im Code und nicht der Registry standen und das Slip streaming nicht mehr funktionierte und man als Work Arround bekam, lassen Sie es einfach und updaten Sie erst nach der Installation…
Microsoft, die können es.
.