The current content delivery network (CDN) provider Edgio, used by Azure DevOps is retiring. We’re urgently transitioning to a solution served by Akamai and Azure Front Door CDNs to maintain the responsiveness of our services.
What this means for you
For most of you, this transition will be seamless. To ensure that you can continue to access Azure DevOps without any interruptions, use the following Powershell commands to validate that your current firewall settings allow connectivity to the new CDN providers:
Invoke-WebRequest -Uri https://cdn.vsassets.io/content/icons/favicon.ico
Invoke-WebRequest -Method Head -Uri https://vstsagentpackage.azureedge.net/agent/3.248.0/vsts-agent-win-x64-3.248.0.zip
If your network includes firewalls that could affect access to the new CDNs, we recommend adding the following domain URLs to the allow list and not the individual IP addresses.
https://vstsagentpackage.azureedge.net
For more details, please refer to this guidance.
Our commitment
We appreciate your patience during this transition. For questions or feedback, please comment below.
There are current issues with the GIT Integration in Fabric as been seen in this post: https://community.fabric.microsoft.com/t5/Data-Engineering/GIT-integration-with-Lakehouse-not-working-this-morning/m-p/4365386#M6114
Can this “Switching CDN providers” be the rootcause for the issues in the Fabric Azure DevOps implementation?
Question regarding the links.
Everywhere there is shouting to migrate away from azureedge.net and azurefd.net but what is the replacement for vstsagentpackage.azureedge.net?
So in the end no azureedge needs to be in any whitelist?
Hello,
Could this change be the cause of issues with running/configuring self-hosted agents?
My self-hosted agent installation on MacOS suddenly stopped working yesterday with this error:
“ERR AgentServer] System.TimeoutException: The HTTP request timed out after 00:01:00.”
…
“GET request to https://dev.azure.com/%5Bmy project]/_apis/connectionData failed”
Thank you
Sorry to hear about the issues you’re facing. This doesn’t seems to be related to this transition, though.
Feel free to reach out to Azure support to get further assistance!
Can we double check those domains please? They both CNAME to v0cdn.net endpoints which (as far as I can tell) are Edgio domains that are going away…
vsassets.io has been on the list of addresses for at least the past 2 years (https://github.com/MicrosoftDocs/azure-devops-docs/commit/90b95284da6c2e5d3016adf26b44787888bf0868) so isn’t a “new” endpoint
We use Azure Traffic Manager for geography- and percentage- based rollover on these domains. Currently, we are transitioning from Edgio domains (v0cdn.net) to Akamai (edgesuite.net / akamai.net) and Azure Front Door (azurefd.net) domains.
As you correctly noted, none of the vsassets.io subdomains are new; only their DNS resolution chain is changing. The blog announcement serves as a heads-up for customers who may have dependencies on specific IP addresses or low-level Edgio domains in their firewall or proxy configurations.
Thank you for your diligence! Let me know if you have any questions
That’s great, thanks for the clarification
…. and yet again, you suggest the next scammer domain vsassets.io as replacement.
The TLD .io is not under Microsoft control or US control or jurisdiction. I cannot follow your recommendation to make exceptions for vsassets.io
You people at Microsoft are absolutely resilient to basic security concepts.