Introduction
We have announced the retirement of Edgio CDN for Azure DevOps and are transitioning to a solution served by Akamai and Azure Front Door CDNs. This change affects Azure DevOps Pipelines customers. This article provides guidance for the Azure DevOps Pipelines customers to check if they are impacted by this change in CDN and the changes required if impacted. Impacted Azure DevOps Service and Azure DevOps Server Customers should complete the suggested changes by May 1, 2025 and May 15, 2025 respectively.
Why the change
Azure DevOps Pipelines customers can configure various forms of self-hosted Agent pools. In case of these self-hosted Agent pools, Agent package is downloaded from CDN. As Edgio CDN is being retired, the Domain URL owned by Edgio https://vstsagentpackage.azureedge.net would be retired as well. So, customers need to open another Domain URL https://download.agent.dev.azure.com supported by the new CDNs. You should not delete the existing domain URL https://vstsagentpackage.azureedge.net from the Allow list.
Some Azure DevOps Server customers also require a patch to incorporate the backend changes to manage the CDN retiral.
Azure DevOps Service and Azure DevOps Server Customer can refer to the respective subsections below to learn about the required changes.
Azure DevOps Service
Who is impacted
Azure DevOps Service customers using any of the following hosted agent pool types for their pipelines could be impacted, as agent packages for these pools are downloaded from the CDN.
1. Self-hosted agents
2. Azure Virtual Machine Scale Set agents
3. Managed DevOps Pools agents
Azure DevOps Service customers using any of the affected Agent pool should follow the following steps.
Steps
1. Update your organization’s firewall Allow list. Refer the section Update the firewall Allow list.
2. Configure and Run the Test Pipeline. Refer the section Test Pipeline. The Test pipeline should pass.
Customers utilizing Azure DevOps Environment and Deployment Groups will observe updated Agent Download URLs within the registration script. Those employing registration scripts generated prior to the CDN cutover in their automation processes should ensure the Agent Download URL is updated accordingly.
Timelines
Azure DevOps Service customers must complete the above changes by May 1st, 2025, to avoid disruptions in downloading the Agent package and impacting pipeline runs.
Azure DevOps Server
Azure DevOps Server customers using pipelines should follow the following steps depending on the server version. Please refer the table below.
Steps
1. Update your organization’s firewall Allow list. Refer the section Update the firewall Allow list.
2. Configure and Run the Test Pipeline. Refer the section Test Pipeline. If the test pipeline passes, proceed ahead.
3. Apply the Azure DevOps Server patch, depending on the version. Refer the patch version required in the table below.
Change details for various Azure DevOps Server version
| Azure DevOps Server | Steps to be completed | Patch version if required |
|---|---|---|
| Azure DevOps Server 2022.2 | Steps 1-3 | Azure DevOps Server 2022.2 Patch 5 |
| Azure DevOps Server 2020.1.2 | Steps 1-3 | Azure DevOps Server 2020.1.2 Patch 16 |
| Azure DevOps Server 2019.1.2 | Steps 1-3 | Azure DevOps Server 2019.1.2 Patch 11 |
| TFS 2018.3.2 | Steps 1-3 | TFS 20183.2 Patch 18 |
| TFS 2017 | Steps 1-2 | NA |
| TFS 2015 | NA | NA |
Azure DevOps Server patches required for this change are available now. Please refer the blog for more details on these patches.
Timelines
Azure DevOps Server customers must complete the suggested changes by May 15, 2025, to avoid disruptions in downloading the Agent package and impacting pipeline runs.
Test Pipeline
For the affected hosted Agents, we need to ensure that it can connect to the new CDN. We have provided a test job, that verifies if the new CDN is accessible from the network hosting the Agent. So, if your organization uses any of the affected agents, add the job given below to a test pipeline and run it.
- job:
pool:
name: MyPool # please change the name 'MyPool' with name of a Agent Pool used in your organization
steps:
- pwsh: |
$ErrorActionPreference = 'Stop'
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
try {
Invoke-WebRequest -Method HEAD `
-Uri https://download.agent.dev.azure.com/agent/4.252.0/vsts-agent-win-x64-4.252.0.zip `
-TimeoutSec 5 `
-UseBasicParsing `
| Set-Variable response
if ($response.StatusCode -lt 400) {
Write-Host "Agent CDN is accessible. Status code: $($response.StatusCode)"
} else {
throw
}
} catch {
Write-Host "##vso[task.logissue type=warning]Can't access download.agent.dev.azure.com. Please make sure the access is not blocked by a firewall."
Write-Error "Agent CDN is inaccessible. Please make sure the access is not blocked by a firewall"
$response | Format-List
}
displayName: 'Test download.agent.dev.azure.com access'
If you use a classic pipeline, please add the job to the PowerShell task in classic pipeline. Refer the snapshot below to add the job to the classic pipeline.
If the test pipeline fails, it means that new CDN is not accessible from your organization.
Update the firewall Allow list
The network or Firewall configuration of your organization may block access to the new CDNs. Please ensure that the new Domain URL https://*.dev.azure.com is open. We recommend adding the new Domain URL to your organization’s firewall allow list.
If your organization’s policies do not permit adding the Domain URL with a wildcard, please add the following URL to your organization’s firewall Allow list:
https://download.agent.dev.azure.com
Please note that you need to have at least one of the above suggested Domain URLs in the firewall Allow list to access the new CDN. You can run the suggested test pipeline after adding the URL to the Allow list to ensure that your organization’s network allows the access to the CDN.
You should not delete the existing domain URL https://vstsagentpackage.azureedge.net from the Allow list. We will notify when it is safe to remove the same. This dual allow listing is to avoid any disruption in service during transition.
Conclusion
We understand these changes can be inconvenient, but they are necessary to ensure the continued reliability and performance of our services. We appreciate your cooperation and understanding in making this transition smooth and seamless. If you have any questions or need assistance, please do not hesitate to reach out to our support team.
FAQ
I have the URL (https://vstsagentpackage.azureedge.net) in the Allowed Domain URL list. Do I need to remove it now?
Please avoid removing the existing Domain URL from the allowed list until you receive an official notification. This dual allow listing will help avoid any disruptions in service.
I have updated the network/Firewall to open the Domain URLs, but why is the test pipeline still failing?
If you are sure that the new Domain URLs are open, please check the error in the pipeline and make sure there is no configuration error in the pipeline.
Hi Team,
We are encountering a firewall issue when attempting to run the code without TLS. However, when we try to access the package from a virtual machine where the agent is installed, we are able to successfully download the package.
Is there anything else we need to check on our side?
Does this affect running the pipelines itself or just automatical updates for the agent / downloading agent?
Affects hugely on my criticality of getting firewall changes through.
Subject: Clarification on Download Requirements for Ubuntu Agent Container.
Hello,
I am currently running a self-hosted Ubuntu agent container and am in the process of making some changes to improve my pipeline. However, I am unclear whether the download requirements apply specifically to Windows environments or if they are relevant to my Ubuntu setup as well.
This may seem like a basic question, but I want to ensure I don’t disrupt my pipeline. Could anyone provide clarification on this?
Thank you in advance for your help!
For existing VMSS agent, where extension ‘Microsoft.Azure.DevOps.Pipelines.Agent’ (which will download the agent package and register to Pipeline) gets installed on the VMSS automatically when registered to Pipeline. However, the concern comes, would Pipeline automatically update the extension with new URL for the existing VMSS? Based on the article, seems no manual action needed for customer to manually patch the extension, but need further confirmation.
I asked a similar question 4 days ago (my post is still pending moderation -_-).
For Linux VMSS, for instance, the latest version of the extension (1.26) still refers to the azureedge domain.
Moreover, these extensions do not support automatic upgrade/update.
So a manual action will be required in any case.
Hi,
The download URL is a parameter to the extension, and Azure Devops will update the parameter value to point to new URL automatically once this change will start deploying. There is no version upgrade needed for the extension itself and hence there is no manual action needed as of now for the VMSS settings. But please do make sure that VMMS instances can access the new URL and there is no firewall rule blocking these requests as mentioned above.
Thanks,
Tarun Ramsinghani
In my case, when I tested the job with the provided script, it failed on the first attempt.
To confirm if the firewall was blocking the connection, I tried accessing the URL directly from the browser:
https://download.agent.dev.azure.com/agent/4.252.0/vsts-agent-win-x64-4.252.0.zip
Surprisingly, the package downloaded successfully.
I later discovered that the script required specific TLS settings to succeed. Adding the following line resolved the issue:
<code>
After making this adjustment, the job was successful except for one agent. The failure was due to the agent using proxy settings for the connection. Once I removed the proxy settings, the job succeeded for that agent as well.
We have updated the script to include Tls 1.2 setting. Thanks for bringing it our attention.
Is there a list of those banners somewhere so I can disable the ones I want?
You can use the Azure DevOps CLI to manage banners.
Is there a list of the IP ranges associated with this new hostname?
I need to provide IP ranges rather than hostnames for whitelisting download.agent.dev.azure.com from on-premise VMs. The following links suggest some 13.xxx.xxx.xxx and 150.xxx.xxx.xxx IP ranges:
Self-hosted Windows agents FAQ https://learn.microsoft.com/en-us/azure/devops/pipelines/agents/windows-agent?view=azure-devops&tabs=IP-V4#im-running-a-firewall-and-my-code-is-in-azure-repos-what-urls-does-the-agent-need-to-communicate-with
IP address - Outbound connections https://learn.microsoft.com/en-us/azure/devops/organizations/security/allow-list-ip-url?view=azure-devops&tabs=IP-V4#outbound-connections
However, it appears download.agent.dev.azure.com is resolving to some 23.221.xxx.xxx, 23.44.xxx.xxx, and 23.206.xxx.xxx IP addresses.
I additionally don't find these addresses in the Azure IP Ranges and Service Tags – Public Cloud https://www.microsoft.com/en-us/download/details.aspx
I know the existing vstsagentpackage url points to the Akamai cdn, but even after the transition, keep the vstsagentpackage URL active but potentially have a redirect rule back to the new download url.
A quick search in GH, shows there are over 1.3k entries of the vstsagentpackage full URL, including in some MS owned repos but multiple user repos, code, blogs that might not get updated.