Deploying Logic Apps to production environments with Azure DevOps and ARM templates is typically a smooth process, especially when you’ve done it several times. However, as with any technology, unexpected errors can suddenly appear, leaving you scratching your head and searching for answers.
Recently, I encountered a frustrating issue during the deployment. The error message read:
“ConnectionGatewayFailure: Establishing connection with the service failed with code ‘DMTS_EncryptClusterCredentialsErrorCode’.”
To give you a bit more background: My standard Logic App comprises several workflows and API connections, all deployed via a CI/CD pipeline. Typically (at least, according to our internal best practices), the first deployment step involves provisioning all the API connections, with respect to that, I started deploying all the API connection via ARM template, but due to the above error the deployment failed,
Interestingly, the same ARM template had been successfully deployed over 20 times previously without any issues. The only recent change was the addition of the new SharePoint API connection.
At first, I thought the error was caused by adding a new SharePoint API connection to my existing ARM template. Despite revising and redeploying the template several times, the issue persisted. Like many others, I turned to the web for a solution. While searching, I came across an insightful blog post by Sandro Pereira. Although my specific problem was somewhat different, the post provided a crucial hint that helped me identify the root cause.
If you closely examining the error message, it explicitly mentioned a “ConnectionGatewayFailure.” This small detail guided me towards identifying the correct root cause.
A “DMTS_EncryptClusterCredentialsErrorCode” typically indicates issues related to the On-Premises Data Gateway (OPDG). Specifically, it arises when the referenced OPDG instance is either inactive or incorrectly referenced.
In my case, it was incorrectly referenced. We had recently migrated our OPDG to a new gateway instance, but I hadn’t updated it. One of the File API connections was referencing the old gateway instance. This mismatch was causing the deployment error.
The solution turned out to be straightforward: update the File API Connection ARM template to reference the new gateway instance. After implementing this simple correction, the API connection deployment succeeded without any further issues.
I hope this explanation helps clarify similar problems you might encounter. If you have any further questions or insights, please leave a comment or reach out through the contact form on my website.