Built-in gateway support for workspaces in Azure API Management
Workspaces in Azure API Management let platform teams hand off API ownership to individual API teams while keeping centralized governance. Until now, using them meant deploying a dedicated workspace gateway on the Premium tier — adding cost, operational overhead, and limiting regional availability. That requirement is going away. Workspaces can now be associated directly with the built-in gateway, and this capability is generally available. What changes Available in more tiers. Use workspaces on the built-in gateway in any API Management tier except Consumption. Available in every region. Create workspaces in any region where API Management is supported. All built-in gateway capabilities apply. Workspaces deployed with the built-in gateway inherit features that dedicated workspace gateways don't offer today, including multi-region deployments, custom hostnames, and Private Link connectivity. Availability Rolling out now to v2 tiers, with Azure portal UI support expected around July. Rollout to classic tiers (Developer, Basic, Standard, Premium) will begin by August and may take up to a few months to complete. Get started Learn more about workspaces and how to deploy them on the built-in gateway.Security baseline for Microsoft Edge version 151
We are pleased to announce the enterprise-ready release of the security baseline for Microsoft Edge version 151! We have reviewed the settings in Microsoft Edge version 151 and updated our guidance with six new recommendations. We have also identified one additional setting that organizations should consider evaluating in their environments. A new Microsoft Edge security baseline package was just released to the Download Center. You can download the new package from the Security Compliance Toolkit. Enable Process Isolation (added) We are enforcing ‘Enable Process Isolation’ to help protect Microsoft Edge from unauthorized access, modification, and tampering by other applications running on the device. This setting strengthens browser process integrity and helps safeguard sensitive data used by Microsoft Edge. Organizations that encounter compatibility issues with software that depends on browser process injection should treat such configurations as exceptions requiring explicit risk acceptance and compatibility validation. Enable renderer in app container (added) We are enforcing the default and enabling ‘Enable renderer in app container’ to strengthen Microsoft Edge’s browser isolation protections by ensuring renderer processes run within the additional restrictions provided by AppContainer. This helps reduce the impact of browser-based attacks and limits the ability of exploited renderer processes to interact with system resources. Organizations that require this setting to be disabled due to incompatible software should treat such configurations as exceptions that require explicit risk acceptance. Enable the network service sandbox (added) We are enforcing the default and enabling ‘Enable the network service sandbox’ to ensure Microsoft Edge network-facing processes operate within sandbox isolation boundaries that help reduce the impact of exploitation and limit access to system resources. Because disabling the network service sandbox weakens a core browser security protection, organizations should treat any requirement to disable this setting as an exception scenario requiring explicit risk acceptance and compatibility validation. Configure browser process code integrity guard (added) We are enabling ‘Configure browser process code integrity guard setting’ with a value of ‘Enable code integrity guard enforcement in the browser process’. The setting strengthens protections against unauthorized code injection into Microsoft Edge browser processes. Some enterprise applications, extensions, accessibility tools, or security products may still rely on legacy injection techniques and require compatibility validation. We encourage organizations to fully test this setting in their environments and work with vendors to identify or remediate incompatible software. Enable Application Bound Encryption (added) We are enabling ‘Enable Application Bound Encryption’ to strengthen protections for browser-stored credentials, authentication tokens, and other sensitive data by binding encryption more closely to the browser process. This helps reduce the risk of unauthorized access to protected browser data by malware or other untrusted software. Because disabling this setting weakens an important protection boundary, organizations should treat any requirement to disable the feature as an exception requiring explicit risk review. Enhance the security state in Microsoft Edge (added) We are enabling ‘Enhance the security state in Microsoft Edge’ and configuring the setting to Balanced to provide additional protection against modern web-based attacks while maintaining compatibility for most enterprise users. In Balanced mode, Microsoft Edge applies additional mitigations such as disabling just-in-time (JIT) JavaScript compilation and enabling added operating system protections on processes used to load sites that users do not frequently visit, helping reduce the risk of memory-related vulnerabilities. Because these protections can introduce compatibility issues for some applications or workflows, organizations should validate critical business sites and applications during their normal testing process prior to broad deployment and configure exceptions as needed. Additional details can be found here. Configure Automatic HTTPS (worth considering) We previously released a blog discussing a new feature called Automatic HTTPS. This setting can automatically switch your connections to websites from HTTP to HTTPS on sites that are highly likely to support the more secure protocol. This option helps ensure that users' network traffic is more secure and less susceptible to SSL stripping attacks. The best part, the end user doesn’t get prompted, it just works! This new feature has two configuration options: Navigations delivered over HTTP are switched to HTTPS’ (UpgradeCapableDomains) and ‘All navigation delivered over HTTP are switched to HTTPS’ (AlwaysUpgrade). There are trade-offs for each configuration: the UpgradeCapableDomains option only upgrades to HTTPS if Microsoft believes the site is likely to work over HTTPS, and this setting is unavailable if you’ve disabled the ComponentUpdatesEnabled policy. The more secure AlwaysUpgrade option unconditionally updates all HTTP requests to HTTPS, which will result in a user-visible error page if the target site does not support HTTPS. We encourage organizations to consider implementing and testing Automatic HTTPS within their environment. Collectively, these changes continue our focus on strengthening browser isolation, sandboxing, process integrity, and protection of sensitive browser data while balancing enterprise compatibility requirements. Microsoft Edge version 151 introduced 4 new computer and user settings. We have included a spreadsheet listing the new settings in the release to make it easier for you to find them. As a friendly reminder, all available settings for Microsoft Edge are documented here, and all available settings for Microsoft Edge Update are documented here. Please continue to give us feedback through the Security Baseline Community or in comments on this post.Announcing Grafana 13 Support in Azure Managed Grafana
Enhanced Dashboarding and Visualization Experience Grafana 13 introduces a number of improvements that make dashboards easier to build, reuse, and manage at scale. Teams can create richer observability experiences while reducing duplication and improving consistency across environments. These improvements include Dynamic Dashboards, Saved Queries, enhanced filtering and grouping experiences, dashboard templates, and additional usability enhancements that streamline dashboard authoring and discovery. From enhanced dashboard authoring experiences and reusable queries to Git-based dashboard lifecycle management, Grafana 13 helps teams build and operate observability solutions more efficiently at scale. Git Sync: Manage Dashboards as Code One of the most anticipated capabilities associated with Grafana 13 is Git Sync: enabling organizations to manage Grafana dashboards using Git-based workflows. Dashboards can be stored as JSON files in a Git repository, making it easier to version, review, and automate dashboard changes using existing engineering practices. With Git Sync, teams can: Track dashboard changes through source control. Review updates through pull requests. Integrate dashboard deployments into CI/CD pipelines. Collaborate on dashboard development using familiar Git workflows. Git Sync supports bidirectional synchronization. Changes made in Grafana can be committed back to a repository, while changes committed to the repository are automatically synchronized to Grafana. Configuration is managed directly from the Grafana UI, with authentication supported through either a GitHub App or a Personal Access Token. For customers managing large observability estates, Git Sync helps bring dashboards into existing infrastructure-as-code and platform engineering workflows. Visit MSLearn to check out Git Sync on Azure Managed Grafana. Prometheus Authentication Changes in Grafana 13 One of the most important changes in Grafana 13: using Prometheus with Azure authentication. Starting with Grafana 13, Azure authentication is no longer supported in the standard open-source Prometheus data source. Instead, Azure authentication is exclusively available through the Azure Monitor Managed Service for Prometheus plugin. This change aligns with Grafana Labs' updated Prometheus data source strategy and deprecation guidance. Customers do not need to modify existing dashboards as part of this transition. Dashboards remain compatible across both plugin versions, and existing visualizations, imports, exports, and dashboard definitions continue to work as expected. Connectivity and query execution against Azure Monitor Workspaces and Azure Monitor Managed Service for Prometheus endpoints will use the Azure-specific plugin that now owns Azure authentication support. Prometheus data sources configured with non-Azure authentication methods are unaffected by this change and continue to operate without modification. We Recommend: You can start using Grafana 13 today by creating a new Azure Managed Grafana workspace and selecting Grafana 13. We encourage customers to explore the new dashboarding experiences introduced in Grafana 13 and review their Prometheus configurations to understand how Azure-authenticated data sources are transitioned to the Azure Monitor Managed Service for Prometheus plugin. Existing dashboards continue to work without changes. Customers do not need to: Recreate dashboards. Update visualizations. Modify dashboard JSON definitions. Reconfigure imports or exports. For additional guidance, see the Azure Managed Grafana documentation: Configure Bundled Prometheus (preview) in Azure Managed Grafana | Microsoft Learn Add an Azure Monitor workspace to Azure Managed Grafana | Microsoft Learn How to manage data sources for Azure Managed Grafana | Microsoft Learn Connect Grafana to Azure Monitor managed service for Prometheus - Azure Monitor | Microsoft Learn For additional details about Grafana 13, refer to the official Grafana Labs release announcement and release notes.Announcing Confidential Live Migration in Azure
Today at Build, Microsoft showcased Confidential Live Migration, a new capability that helps move Intel® TDX Confidential VMs to updated infrastructure with limited-service interruption while helping protect VM memory and execution context during migration.Retirement of Microsoft HPC Pack
Overview Microsoft HPC Pack is a Windows‑based high‑performance computing (HPC) scheduler that enables customers to deploy, manage, and operate HPC workloads in on‑premises and hybrid environments. Since its original release, HPC Pack has supported a range of Windows‑centric HPC scenarios, including job scheduling, workload orchestration, and integration with Windows Server–based technologies. Microsoft is announcing the planned retirement of HPC Pack. For customers looking to run HPC workloads going forward, Microsoft’s supported platform for managed HPC and parallel workloads is Azure Batch. Customers may also adopt any other Azure service as appropriate for their workload. These platforms provide modern, cloud‑native capabilities for scheduling, scaling, and operating HPC workloads on Azure. Important Dates Retirement announcement: August 27, 2026 End of Support / retirement date: August 27, 2027 After August 27, 2027, HPC Pack will no longer receive feature updates, bug fixes, or standard product support. No new versions or enhancements will be released. Existing HPC Pack deployments will not be forcibly disabled; however, they will be considered unsupported. Support During the Retirement Period HPC Pack is now entering a one-year retirement period that ends at End of Support on August 27, 2027. Microsoft will provide limited, retirement-only support during this period. The scope of this support is defined below so customers know what to expect. What Microsoft will provide during the retirement period: Security response, including investigation of applicable security vulnerabilities (CVEs) and any security updates deemed necessary by Microsoft Guidance based on existing Microsoft documentation, published best practices, and previously validated HPC Pack configurations Assistance with support incidents involving supported HPC Pack components and documented product functionality What is NOT included during the retirement period: Non-security bug fixes Performance, reliability, scalability, or optimization improvements New features or feature enhancements Customer-specific hotfixes, custom code changes, or design modifications Validation or certification of new operating systems, hardware platforms, drivers, firmware, third-party software, or dependencies Validation of new deployment architectures, configurations, or integration scenarios Changes to existing product behavior or design Creation of new documentation, guidance, or troubleshooting content Troubleshooting that requires new product investigation beyond existing product knowledge, documentation, or previously validated scenarios New customer onboarding, solution design, or pre-sales assistance Migration planning, migration execution, or migration consulting services Support for configurations, integrations, or deployment scenarios that are outside published documentation, established best practices, or previously validated HPC Pack environments After End of Support (August 27, 2027): HPC Pack will receive no further updates, fixes, or technical support, and deployments will be considered unsupported. What Customers Should Do Customers currently using HPC Pack should begin planning migration to a supported alternative as soon as possible. For most scenarios, the following services are recommended: Azure Batch – for managed scheduling and execution of parallel and HPC workloads Or any other Azure service as appropriate for your workload Resources HPC Pack documentation: Microsoft HPC Pack 2019 Public issue tracker: Azure/hpcpack GitHub repository Next Steps Customers who anticipate needing additional planning assistance or migration guidance should engage early with their Microsoft account team or Cloud Solution Architect (CSA) to help ensure a smooth transition and avoid potential disruption. To help us understand customer needs and improve future communications, please complete this Microsoft Form. Share any technical, operational, or business challenges you anticipate during your transition. Your feedback will help us identify common concerns and refine future guidance.
ExpressRoute Gateway Microsoft initiated migration
Important: Microsoft initiated Gateway migrations are temporarily paused. You will be notified when migrations resume. Objective The backend migration process is an automated upgrade performed by Microsoft to ensure your ExpressRoute gateways use the Standard IP SKU. This migration enhances gateway reliability and availability while maintaining service continuity. You receive notifications about scheduled maintenance windows and have options to control the migration timeline. For guidance on upgrading Basic SKU public IP addresses for other networking services, see Upgrading Basic to Standard SKU. Important: As of September 30, 2025, Basic SKU public IPs are retired. For more information, see the official announcement. You can initiate the ExpressRoute gateway migration yourself at a time that best suits your business needs, before the Microsoft team performs the migration on your behalf. This gives you control over the migration timing. Please use the ExpressRoute Gateway Migration Tool to migrate your gateway Public IP to Standard SKU. This tool provides a guided workflow in the Azure portal and PowerShell, enabling a smooth migration with minimal service disruption. Backend migration overview The backend migration is scheduled during your preferred maintenance window. During this time, the Microsoft team performs the migration with minimal disruption. You don’t need to take any actions. The process includes the following steps: Deploy new gateway: Azure provisions a second virtual network gateway in the same GatewaySubnet alongside your existing gateway. Microsoft automatically assigns a new Standard SKU public IP address to this gateway. Transfer configuration: The process copies all existing configurations (connections, settings, routes) from the old gateway. Both gateways run in parallel during the transition to minimize downtime. You may experience brief connectivity interruptions may occur. Clean up resources: After migration completes successfully and passes validation, Azure removes the old gateway and its associated connections. The new gateway includes a tag CreatedBy: GatewayMigrationByService to indicate it was created through the automated backend migration Important: To ensure a smooth backend migration, avoid making non-critical changes to your gateway resources or connected circuits during the migration process. If modifications are absolutely required, you can choose (after the Migrate stage complete) to either commit or abort the migration and make your changes. Backend process details This section provides an overview of the Azure portal experience during backend migration for an existing ExpressRoute gateway. It explains what to expect at each stage and what you see in the Azure portal as the migration progresses. To reduce risk and ensure service continuity, the process performs validation checks before and after every phase. The backend migration follows four key stages: Validate: Checks that your gateway and connected resources meet all migration requirements for the Basic to Standard public IP migration. Prepare: Deploys the new gateway with Standard IP SKU alongside your existing gateway. Migrate: Cuts over traffic from the old gateway to the new gateway with a Standard public IP. Commit or abort: Finalizes the public IP SKU migration by removing the old gateway or reverts to the old gateway if needed. These stages mirror the Gateway migration tool process, ensuring consistency across both migration approaches. The Azure resource group RGA serves as a logical container that displays all associated resources as the process updates, creates, or removes them. Before the migration begins, RGA contains the following resources: This image uses an example ExpressRoute gateway named ERGW-A with two connections (Conn-A and LAconn) in the resource group RGA. Portal walkthrough Before the backend migration starts, a banner appears in the Overview blade of the ExpressRoute gateway. It notifies you that the gateway uses the deprecated Basic IP SKU and will undergo backend migration between March 7, 2026, and April 30, 2026: Validate stage Once you start the migration, the banner in your gateway’s Overview page updates to indicate that migration is currently in progress. In this initial stage, all resources are checked to ensure they are in a Passed state. If any prerequisites aren't met, validation fails and the Azure team doesn't proceed with the migration to avoid traffic disruptions. No resources are created or modified in this stage. After the validation phase completes successfully, a notification appears indicating that validation passed and the migration can proceed to the Prepare stage. Prepare stage In this stage, the backend process provisions a new virtual network gateway in the same region and SKU type as the existing gateway. Azure automatically assigns a new public IP address and re-establishes all connections. This preparation step typically takes up to 45 minutes. To indicate that the new gateway is created by migration, the backend mechanism appends _migrate to the original gateway name. During this phase, the existing gateway is locked to prevent configuration changes, but you retain the option to abort the migration, which deletes the newly created gateway and its connections. After the Prepare stage starts, a notification appears showing that new resources are being deployed to the resource group: Deployment status In the resource group RGA, under Settings → Deployments, you can view the status of all newly deployed resources as part of the backend migration process. In the resource group RGA under the Activity Log blade, you can see events related to the Prepare stage. These events are initiated by GatewayRP, which indicates they are part of the backend process: Deployment verification After the Prepare stage completes, you can verify the deployment details in the resource group RGA under Settings > Deployments. This section lists all components created as part of the backend migration workflow. The new gateway ERGW-A_migrate is deployed successfully along with its corresponding connections: Conn-A_migrate and LAconn_migrate. Gateway tag The newly created gateway ERGW-A_migrate includes the tag CreatedBy: GatewayMigrationByService, which indicates it was provisioned by the backend migration process. Migrate stage After the Prepare stage finishes, the backend process starts the Migrate stage. During this stage, the process switches traffic from the existing gateway ERGW-A to the new gateway ERGW-A_migrate. Gateway ERGW-A_migrate: Old gateway (ERGW-A) handles traffic: After the backend team initiates the traffic migration, the process switches traffic from the old gateway to the new gateway. This step can take up to 15 minutes and might cause brief connectivity interruptions. New gateway (ERGW-A_migrate) handles traffic: Commit stage After migration, the Azure team monitors connectivity for 15 days to ensure everything is functioning as expected. The banner automatically updates to indicate completion of migration: During this validation period, you can’t modify resources associated with both the old and new gateways. To resume normal CRUD operations without waiting 15 days, you have two options: Commit: Finalize the migration and unlock resources. Abort: Revert to the old gateway, which deletes the new gateway and its connections. To initiate Commit before the 15-day window ends, type yes and select Commit in the portal. When the commit is initiated from the backend, you will see “Committing migration. The operation may take some time to complete.” The old gateway and its connections are deleted. The event shows as initiated by GatewayRP in the activity logs. After old connections are deleted, the old gateway gets deleted. Finally, the resource group RGA contains only resources only related to the migrated gateway ERGW-A_migrate: The ExpressRoute Gateway migration from Basic to Standard Public IP SKU is now complete. Frequently asked questions How long will Microsoft team wait before committing to the new gateway? The Microsoft team waits around 15 days after migration to allow you time to validate connectivity and ensure all requirements are met. You can commit at any time during this 15-day period. What is the traffic impact during migration? Is there packet loss or routing disruption? Traffic is rerouted seamlessly during migration. Under normal conditions, no packet loss or routing disruption is expected. Brief connectivity interruptions (typically less than 1 minute) might occur during the traffic cutover phase. Can we make any changes to ExpressRoute Gateway deployment during the migration? Avoid making non-critical changes to the deployment (gateway resources, connected circuits, etc.). If modifications are absolutely required, you have the option (after the Migrate stage) to either commit or abort the migration.
Bulk task changes
Does anyone know how am I able to add dates to tasks in bulk if it's the same due date? How do I assign tasks in bulk to a specific person? These used to easily be done by selecting the sections and right clicking to change but many settings updated today and I am no longer able to do this.Power Azure SRE Agent with the tools it needs
What is the Azure SRE Agent Azure SRE Agent is an AI-powered service designed to reduce operational toil. Teams can use it to: Investigate incidents and identify probable causes. Automate health checks, compliance reviews, and other scheduled work. Answer questions such as “What changed before this service became degraded?” Propose remediations while allowing teams to require human approval. An effective investigation rarely depends on one source of information. An alert might originate in Azure Monitor, while deployment history lives in source control, telemetry stored in another observability platform, and incident records in a service-management tool. Without access to those systems, you must retrieve and transfer the information manually, adding context switching and slowing diagnosis. MCP servers can give SRE Agent tools to query telemetry, inspect deployments, retrieve database records, look up incidents, etc. SRE Agent provides native connection for some servers such as GitHub, Datadog, New Relic, and Splunk. Connector Namespace makes it easier to host additional remote MCP servers you want the agent to use. Removing remote MCP server hosting burden Connecting SRE Agent to an existing remote endpoint is straightforward. Hosting that endpoint yourself is not. You must deploy the server, provide secure HTTPS infrastructure, configure authentication, manage downstream credentials, scale the runtime, monitor its health, recover failed instances, and maintain it over time. These responsibilities are necessary, but the value is in the server’s tools not in operating another service. Azure Connector Namespace is a fully managed service for hosting connectors and MCP servers. You select the server you need and let the namespace handles the operational and maintenance tasks. The offering is currently in preview. See documentation for supported regions and other preview considerations. You’ll find a wide variety of servers in the Connector Namespace’s catalog. Some examples of useful servers for the SRE agent include: Database servers such as Azure SQL and Azure Cosmos DB Source control and CI/CD servers like GitLab Incident management servers like Jira and PagerDuty A note on what's currently in development: We're building “bring-your-own” server support, allowing you to supply your own server image while the namespace handles hosting and operations. Please keep an eye out for the blog post about this! Deploy server and connect it to SRE Agent The following example deploys the SQL MCP server in Connector Namespace and connects it to Azure SRE Agent. 1. Server deployment Prerequisite: Install the Azure Developer CLI (azd). Clone the sql-server-samples repo: git clone https://github.com/microsoft/sql-server-samples.git Navigate to the azure-sql-mcp sample cd sql-server-samples/samples/applications/azure-sql-mcp From the azure-sql-mcp folder, run the following to log into your Azure subscription and then deploy the server and related resources: azd auth login azd up The last command will prompt for the following before deployment: Prompt Suggested value Explanation Enter a unique environment name mcp-dev This name added as prefix to Azure resources created Select an Azure Subscription Pick your subscription Resources will deploy under this subscription Enter value for connectorNamespaceIdentityType UserAssigned User assigned identity is recommended as it’s not tied to resource lifecycle Enter value for deployerLoginName Enter your Azure subscription login email To give your identity access to the MCP server Enter value for the location Pick a supported region Supported regions: West Central US, Central US, East Asia, North Europe Once deployment finishes, copy the MCP endpoint for use later. It looks similar to: https://<app-name>.<region>.logic.azure.com/api/connectorGateways/123abc456defg7890/mcpServerConfigs/sql-mcp/mcp (Optional) Test deployed server in Visual Studio Code GitHub Copilot: Open command palette > search MCP: Add server > pick HTTP > enter MCP endpoint and server name > pick Local Workspace. Inside .vscode/mcp.json, click Start above server name, then allow authentication with Microsoft in the popup and log into Azure subscription account. 2. Configure MCP connector in SRE Agent Connector Namespace does not create the connection in SRE Agent. Add the server endpoint through SRE Agent’s existing MCP connection experience. Open the Azure SRE Agent portal On the left menu, go to Builder > Connectors, and select + Add connector Under Choose a connector, select the MCP tab, choose MCP server, and select Next Configure the connector: Field Value Name A descriptive name for the server Connection type Streamable-HTTP URI The hosted server endpoint from Connector Namespace Authentication method Managed identity (Selecting managed identity automatically creates an identity for the connector.) Azure AD token scope https://apihub.azure.com/.default Select Next. Before testing the connection, grant the managed identity access to the MCP server. 3. Authorize the managed identity Open the Azure portal, search for the managed identity by name. In the identity’s Overview page, click JSON View (top right) and copy the tenantId and principalId. The principal ID is also called the object ID. Open Connector Namespace portal and search for the deployed namespace. Inside the namespace, navigate to the MCP Connectors tab on the left, then select the SQL MCP server. Inside the MCP server, click Access Policies, then select Add Access Policy. Enter the tenant ID and principal ID, then select Create. 4. Test and finish the connection Return to Azure SRE Agent portal and select Test connection. After the test succeeds, select the server tools the agent should use. Select Add connector. Establishing the connection can take a minute. Select Refresh at the top of the connectors page until its status changes to Connected. The agent can now use the selected server tools in chat threads. The azd deployment from previous created and seeded a SQL database with sample blog post data, so you can ask something like: What are the top blog posts? For more details, see MCP connectors and tools in Azure SRE Agent. Focus on the server, not its infrastructure MCP servers can give Azure SRE Agent access to the additional systems it needs to investigate incidents and perform operational work effectively. However, operating every remote server yourself introduces infrastructure, security, and maintenance responsibilities that distract from that goal. Connector Namespace removes much of that friction. Your primary question becomes “Which MCP server do I want to host?” rather than “How will I deploy, secure, scale, monitor, and maintain it?” Once deployed, the hosted endpoint can be added to Azure SRE Agent through its existing MCP connection experience. That gives teams a straightforward path to extending the agent with more operational tools, without turning MCP server hosting into another platform they must build and run. Try Connector Namespace with Azure SRE Agent and share your feedback! Resources Azure SRE Agent Overview Set up an MCP connector in Azure SRE Agent Connector Namespace Overview Hosted MCP servers in Connector NamespaceUpdate WCF Relay applications to use TLS 1.2 or later
WCF Relay listeners that still negotiate TLS 1.0 can stop passing traffic through Azure Relay. The symptom appears on the sender, which connected successfully before and now fails every call with System.ServiceModel.EndpointNotFoundException: None of the connected listeners accepted the connection within the allowed timeout. If you run a WCF Relay listener on the .NET Framework, and especially one built against an older version of the WindowsAzure.ServiceBus package or Microsoft.ServiceBus.dll, it is worth checking how it negotiates TLS. Azure Relay Hybrid Connections are not affected and need no action. They use HTTP and WebSockets through the Microsoft.Azure.Relay package, a different stack from the WCF Relay path described here. What is happening TLS 1.0 and TLS 1.1 are deprecated. We retired them across Azure services, and have since retired them at the operating system level as well. That operating system change is why a listener that had run until now can fail going forward. These failures come from a listener that still asks for TLS 1.0, which older .NET Framework defaults, application configuration, registry settings, or startup code can all cause. Relay requires TLS 1.2 or later and rejects the handshake. Where that rejection lands decides what the sender sees. A listener registers with Relay once, when it opens. Relay then asks that registered listener to open a separate rendezvous connection for each sender that arrives, and each of those is a new connection with its own handshake. In this case the rendezvous connection is the one that fails. Relay tries each registered listener until it runs out, none of them accepts, and the sender gets None of the connected listeners accepted the connection within the allowed timeout. The same failure can also surface as a timeout, when the sender's timeout elapses before Relay has finished trying the registered listeners. A listener whose handshake fails when it opens never registers at all. On a persistent relay the sender then gets There are no listeners connected for the endpoint. On a dynamic relay, which is the default for the WCF Relay bindings, the endpoint exists only while a listener is connected, so the sender gets Endpoint does not exist. All three arrive as EndpointNotFoundException, so the message text is what tells them apart, and all three are what the sender sees when the listener is the side still on TLS 1.0. The side that pins the protocol sees the failure directly instead. The trace below is a sender's, and a listener's differs in its lower frames, so search on the message rather than the frames: Exception Type: System.IO.IOException Authentication failed because the remote party has closed the transport stream. Server stack trace: at System.Net.Security.SslState.InternalEndProcessAuthentication(LazyAsyncResult lazyResult) at System.Net.Security.SslState.EndProcessAuthentication(IAsyncResult result) at Microsoft.ServiceBus.Messaging.IteratorAsyncResult`1.StepCallback(IAsyncResult result) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw() at Microsoft.ServiceBus.Common.AsyncResult.End[TAsyncResult](IAsyncResult result) at Microsoft.ServiceBus.SecureSocketUtil.<>c.<InitiateSecureClientUpgradeIfNeededAsync>b__3_1(IAsyncResult a) at System.Threading.Tasks.TaskFactory`1.FromAsyncCoreLogic(IAsyncResult iar, Func`2 endFunction, Action`1 endAction, Task`1 promise, Boolean requiresSynchronization) Relay closes the connection when the handshake offers only TLS 1.0 or 1.1, so it surfaces as a closed stream rather than a protocol mismatch. A sender that pins the protocol fails on its own connection to Relay, before Relay looks for a listener at all, so this exception is all it gets and none of the three messages appear. Whichever side logs it, the trace points at how that application negotiates TLS. Recommended actions Start with whichever application pinned the protocol, which is usually the listener. That change is scoped to the one application and is normally enough to resolve this. Check whether it sets a TLS or SSL version explicitly in code or configuration, and if it does, remove the explicit setting so the operating system chooses the protocol, or set TLS 1.2 or later. The quickest change is configuration-only. Two AppContext switches in the application configuration file put that application back on a supported protocol, and both go in a single semicolon-delimited value attribute: <configuration> <runtime> <AppContextSwitchOverrides value="Switch.System.Net.DontEnableSchUseStrongCrypto=false;Switch.System.Net.DontEnableSystemDefaultTlsVersions=false" /> </runtime> </configuration> Rebuilding against a current .NET Framework resolves it as well. Where startup code is easier to change than configuration, setting ServiceBusEnvironment.SystemConnectivity.Mode to ConnectivityMode.Https and ServicePointManager.SecurityProtocol to SecurityProtocolType.Tls12 moves the connection to HTTPS and TLS 1.2. Applications that target .NET Framework 3.5 and use TCP transport security are pinned to SSL 3.0 and TLS 1.0, so those need to be retargeted. Where the application cannot be changed, the same behavior can be set for the whole machine through two registry values, SchUseStrongCrypto and SystemDefaultTlsVersions, added as DWORD 1 under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319, using v2.0.50727 in place of v4.0.30319 for .NET Framework 3.5. Both values must be created, and they apply to every .NET Framework application on the machine, so treat this as the fallback. The .NET Framework TLS best practices guidance covers both approaches in full. Once the change is in place, restart the application and confirm that the listener and sender both connect. The call that previously failed should complete as soon as the Relay connection negotiates a supported TLS version. For more about the service itself, see the Azure Relay overview, the Azure Relay API overview, and the Azure Relay port settings. Help and support If you have questions, get answers from community experts in Microsoft Q&A or GitHub. If you have a support plan and you need technical help, create a support request.
