Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Azure App Service: Failed to Deploy. The underlying connection was closed: An unexpected error occurred on a send. #12444
Entering this information will route you directly to the right team and expedite traction.
Question, Bug, or Feature?
Enter Task Name: Azure App Service deploy(4.163.3)
list here (V# not needed):
Task name: Deploy Azure App Service
Only happening for web apps in Canary (East US 2 EUAP) region
##[debug]Exit code 4294967295 received from tool 'C:\Program Files\IIS\Microsoft Web Deploy V3\msdeploy.exe'
Checkout how to troubleshoot failures and collect debug logs: https://docs.microsoft.com/en-us/vsts/build-release/actions/troubleshooting
##[error]Error: Error: Could not complete the request to remote agent URL 'https://.scm.azurewebsites.net/msdeploy.axd?site='.
same issue since yesterday
[error]Failed to deploy App Service.
This script is using [Net.ServicePointManager]::SecurityProtocol to check if Tls12 is enabled. To check if Tls12 is enabled on your build machine you can run this command in Powershell console.
PS C:\> [Net.ServicePointManager]::SecurityProtocol Tls, Tls11, Tls12 PS C:\>
To enforce Tls12 you can add this keys in the registry:
No need to change TLS level to 1.0 in the Azure Portal.
+1 for @rdeveen 's solution. Per this article, I believe that the Self-hosted Windows build agent software is targeting an earlier version of .Net. Therefore, it executes pipeline deploys using the TLS settings that are default to that version of .Net.
In that article, it suggests modifying the OS registry with the values referenced by @rdeveen and two more (all of which copied below). After I do that and re-run the [Net.ServicePointManager]::SecurityProtocol PS command, I get back "SystemDefault". As my OS is on .Net 4.7 (which uses TLS 1.2 by default), the build agent uses TLS 1.2 and we no longer have any pipeline deploy issues ran through this agent pool.
We are aware of the issue. This was a result of App Service enforcing the minTlsVersion on the web app for the SCM endpoint. As folks pointed out already, this is a breaking change from a behavior perspective, even though it was well intended.
As some of you already figured it out, there are multiple ways to get unblocked while App Service team address this
Had the same issue when trying to run a deployment on a App Service in West Europe, but only for our production environment.
Temporarely switched to an Hosted Build Agent, but after reboot of the build server the deployment is running as smooth as before. :-)