TechPrufer
Get started
Microsoft
Microsoft logoMicrosoft · Feature trail

Azure DevOps IP Address Management

12 posts · Aug 2016 – Apr 2025

What this trail covers

Azure DevOps Services now supports Azure Service Tags for managing networking configurations, simplifying the process of allowing traffic from specific Azure services. This addresses the past issue of IP address changes requiring manual firewall updates. Service Tags can be used for inbound connections from Azure DevOps to customer-controlled resources like SQL Azure VMs, on-prem repositories, and Splunk for Audit Streaming. Microsoft Hosted Agents still require allowing the entire geography, with this transition to Akamai and Azure Front Door CDNs requiring specific domain URL allow-listing.

All Microsoft trails
  1. Important Update: Server Name Indication (SNI) Now Mandatory for Azure DevOps ServicesThis post announces the mandatory requirement of Server Name Indication (SNI) for all incoming HTTPS connections to Azure DevOps Services, effective April 23rd, 2025. It explains SNI's role in TLS protocol for hostname specification, notes that most modern clients are SNI-ready, but highlights potential compatibility issues with outdated software, proxies, or firewalls. The post provides detailed instructions for testing SNI compatibility using PowerShell, curl, browsers, and host file overrides, and lists common error messages associated with SNI issues.
  2. Update to Azure DevOps Allowed IP addressesThis post announces the addition of new IP addresses (IPv4 and IPv6 ranges, including specific ExpressRoute ranges) to the Azure DevOps allow list due to an upgrade of network edge devices. It instructs users to add these new IPs while keeping existing ones in place during a transition period, with a notification to follow when old IPs can be removed. The update also mentions that new IP ranges will be added to ExpressRoute's 'Azure Global Services' BGP community in March.
  3. Important: Switching CDN providersThis post announces an urgent transition of Azure DevOps's CDN provider from Edgio to Akamai and Azure Front Door due to Edgio's retirement. It provides PowerShell commands to validate firewall settings and recommends adding specific domain URLs (*.vsassets.io, download.agent.dev.azure.com) to allow lists instead of individual IP addresses to ensure uninterrupted access. This is a critical operational change impacting network connectivity for users with strict firewall configurations.
  4. Deprecating weak cryptographic standards (TLS 1.0 and 1.1) in Azure DevOps ServicesThis post announces the completion of the deprecation of TLS 1.0 and 1.1 for Azure DevOps Services, enforcing TLS 1.2 for all HTTPS connections to dev.azure.com and *.visualstudio.com domains. It details a partial rollback and subsequent re-release due to unexpected issues, and clarifies that the deprecation targets IPv4 endpoints. The post provides important dates for temporary disablings of TLS 1.0/1.1 to aid customer identification of incompatible software, and offers detailed guidance on enabling TLS 1.2, including required cipher suites and troubleshooting steps for Windows OS and application-level configurations. It also includes manual PowerShell checks, YAML pipeline steps, and a link to a GitHub troubleshooting script.
  5. Deprecating weak cryptographic standards (TLS 1.0 and TLS 1.1) in Azure DevOpsThis post announces the deprecation of TLS 1.0 and TLS 1.1 for Azure DevOps Services, mandating TLS 1.2 or higher for all HTTPS connections starting January 31, 2022. It details the rationale behind the change (security vulnerabilities and protocol downgrade attacks), anticipates minimal customer impact (as ~99.5% of connections already use TLS 1.2), and outlines a phased approach including temporary disablement windows to allow clients to upgrade. Guidance is provided for enabling TLS 1.2 on various client configurations, including older .NET Framework versions, Visual Studio versions (recommending upgrades to VS 2017 or VS 2022), and operating systems like Windows 7/Server 2008 R2.
  7. IPv6 fencing Conditional Access Policies now supportedExtended Conditional Access Policy (CAP) support in Azure DevOps to include IPv6 fencing policies, in addition to existing IPv4 support. This ensures that IPv6 traffic is subject to the same access rules defined in Azure AD, enhancing security for organizations using Azure DevOps. Previously, all inbound IPv6 traffic was allowed. This update requires users to update their CAP configurations to include IPv6 ranges if they wish to restrict access from these addresses.
  8. Azure DevOps Service Tag ReleasedIntroduced Azure Service Tags for Azure DevOps Services, allowing customers to use the 'AzureDevOps' tag in their NSGs or firewalls for inbound connections. This simplifies network management by abstracting away IP address changes. The post clarifies the scope of Service Tags (inbound only from Azure DevOps to customer resources) and mentions the continued need to allow Azure Front Door IPs for outbound connections. It also notes that Microsoft Hosted Agents are not covered by Service Tags.
  9. [Updated] New IP address ranges with Service Tags for Azure DevOps ServicesThis post announces the upcoming support for Azure Service Tags in Azure DevOps Services by the end of CY2020, allowing users to manage networking configurations by adding the `azuredevops` tag to NSGs or firewalls. It details upcoming IP address space changes for outbound traffic from Azure DevOps Services to on-prem systems, effective October 5, 2020, and outlines a brownout test schedule from September 9-15, 2020. It also clarifies that Service Tags do not apply to Microsoft Hosted Agents, which still require allowing the entire geography. An IP Check Tool is provided to help users determine impact and validate connectivity. The post also lists specific IP address ranges per region and announces the general availability of Service Tags for Azure DevOps in November 2020.
  10. New IP firewall rules for Azure DevOps ServicesThis post announces upcoming changes to Azure DevOps Services' IP address space due to routing structure enhancements. It provides new IPv4 and IPv6 ranges that users must whitelist by July 22, 2019, to maintain connectivity. A new IP check page is being developed to help users determine impact. The post also details a rollout plan with several testing phases involving temporary DNS updates.
  11. ExpressRoute for Azure DevOpsAnnounced that Azure DevOps is now available over Azure ExpressRoute, enabling private, reliable, and faster connections for customers in sectors like government and financial services. This connectivity is achieved through the Microsoft peering configuration of ExpressRoute circuits and route filters, specifically the 'Azure Global Services' route filter with BGP community value 12076:5050. ExpressRoute is supported for various Azure DevOps services including the dev.azure.com and visualstudio.com URLs, self-hosted agents, Visual Studio Marketplace, and Azure Artifacts. It is explicitly noted that ExpressRoute is not available for Azure DevOps static content delivered via Azure CDN (cdn.vsassets.io and gallerycdn.vsassets.io).
  12. Reducing the latency of permissions inherited through AAD Group membershipsThis post details a feature that reduces the latency of permissions inherited through Azure AD group memberships in VSTS from 24-48 hours to a maximum of 1 hour. It also introduces the ability for users to trigger a refresh of their Azure AD membership and inherited permissions by signing out and signing back in.
  13. Supporting AzureAD Conditional Access Policy across VSTSThis post details the upcoming support for Azure AD Conditional Access Policy (CAP) across VSTS by enabling the passing of client IP addresses in refresh token requests. This will allow VSTS to proactively block calls that do not meet the CAP IP policy. The change is planned for delivery during 2018 Q2. In the interim, APIs are provided for administrators to audit activity within an account, returning IP address and authentication mechanism for custom business logic to monitor and flag abnormalities. A sample on GitHub is shared for this purpose.
  14. Inviting directory guests to AAD-backed VSTS accountsThis post details how Azure AD B2B Collaboration can be used to invite external users (guests) into Azure Active Directory, which in turn allows them to access Azure AD-backed Visual Studio Team Services (VSTS) accounts. It outlines the two-step process of inviting a guest user via the Azure portal and then granting them project access within VSTS. Future plans include tighter integration with Azure AD for a one-step invitation process directly from VSTS and making the invitation email optional.
  15. User Lifecycle Management Improvements in Visual Studio Team ServicesThis post details improvements to user lifecycle management in Visual Studio Team Services (VSTS) by integrating with Azure Active Directory (AAD) and Office 365. When a user is disabled or deleted in AAD, their access to VSTS resources is revoked within an hour. This change impacts web logins, Personal Access Tokens (PATs), Alternate Credentials, and SSH access. It also clarifies the process for AAD administrators to restore access for re-enabled or accidentally deleted users using PowerShell cmdlets. The change specifically affects VSTS accounts secured by AAD, not Microsoft Accounts (MSA).