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.
As of June 11, 2025, the old domain URL (https://vstsagentpackage.azureedge.net) is inactive. Impacted Customers are advised to implement the recommended changes if they have not already done so.
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 Agent 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.
Will download.agent.dev.azure.com be supported on Azure Express Route for ADO
I don’t understand why you guys changed the DNS?
Why not just point it to the new location?
Seems silly and a bit of a waste of our time.
The test yaml above only works for Windows Self Hosted Agents, it's using PowerShel which is not available on a linux self hosted machine ...
Here is the yaml for Linux self hosted agent.
<code>
When i am trying to access the URL - https://download.agent.dev.azure.com/agent in self hosted agent VM and I am getting the below message does this mean i am not able to access and needs some further modification if yes, what exactly I need to do. Please tell on priority -
"
ResourceNotFound
The specified resource does not exist. RequestId:211e103c-e01e-0053-21f3-ba3790000000 Time:2025-05-01T23:51:12.0589459Z
"
With https://download.agent.dev.azure.com - "
InvalidQueryParameterValue
Value for one of the query parameters specified in the request URI is invalid. RequestId:772b7e60-d01e-0048-61f3-ba0993000000 Time:2025-05-01T23:49:17.3832049Z
comp
"
Please use the full URL to test “https://download.agent.dev.azure.com/agent/4.252.0/vsts-agent-win-x64-4.252.0.zip”. It is expected to get the above errors with partial path.
Alternatively you can use this in your PowerShell to test
Thanks a lot for the above information Tarun.
Could you please also tell the url and steps to check for Self-hosted linux agent?
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?
If you can download agent packages from https://download.agent.dev.azure.com/agent on the VMs you use to run your agent, you should be good
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.
This affects agent installs and upgrades only. Once installed/upgraded, it works as bafore. Have you tested whether https://download.agent.dev.azure.com is accessible? As *.dev.azure.com was recommended to be allow listed before we expect most customers not to be impacted.