This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(76.8, 43%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EME%3C/text%3E%3C/svg%3E)
{
"code": "ResourceDeploymentFailure",
"target": "/subscriptions/<subscription>/resourceGroups/<group>/providers/Microsoft.Cache/redisEnterprise/<name>",
"message": "The resource write operation failed to complete successfully, because it reached terminal provisioning state 'Failed'."
}
Thank you for any assistance to track down what is going on here.
An Azure service that provides access to a secure, dedicated Redis cache, managed by Microsoft.
Hi @Anonymous thank you for your reply but that is a lot of information you are asking for as I have already provided the correlation ID which should give you all the information you need. Can you please confirm that Redis instances are able to be deployed without error? Thank you for your continued assistance.
I have tried another deployment and instead of it gracefully with a comprehensive error message like you see in every Microsoft product but Azure, it fails with the most obscure and useless message you can think of, as if your team is creatively finding ways to confuse the user. Why are you emitting failure errors that give no indication of why the operation failed? I hope you can understand the concern.
I have tried another deployment and instead of it gracefully with a comprehensive error message like you see in every Microsoft product but Azure, it fails with the most obscure and useless message you can think of, as if your team is creatively finding ways to confuse the user. Why are you emitting failure errors that give no indication of why the operation failed? I hope you can understand the concern.
So I was able to get a deployment successfully made when switching the region to eastus2. There was ZERO mention of anything region-specific in the error. What you see above is the error that is presented to the user and it is astounding to me that this is considered acceptable by every person working at Azure.
Ironically I was using eastus because eastus2 was throwing errors regarding databases at one point. This whole system is truly Jenga, especially when very little information is presented to the user to help them solve the problem they are experiencing.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(262.40000000000003, 18%, 35%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EVP%3C/text%3E%3C/svg%3E)
The error means the connection didn’t have a valid database context or the Entra identity isn’t fully registered inside that database. You don’t need to add pgaadauth as an extension manually—it’s built into the service. The right approach is to enable Entra authentication at the server and then create the identity as a principal in the target database.
Make sure you’re connecting with the correct FQDN (not IP), using SSL, and explicitly specifying the database name.
After that, confirm the identity exists in that database and grant the roles you need. Without that, even if the token looks fine, the database won’t recognize you.
If you’re on Flexible Server, this is the standard flow. If it’s Cosmos DB for PostgreSQL, the steps differ slightly.
Hi @VRISHABHANATH PATIL thank you for your reply.
The error means the connection didn’t have a valid database context or the Entra identity isn’t fully registered inside that database. You don’t need to add pgaadauth as an extension manually—it’s built into the service. The right approach is to enable Entra authentication at the server and then create the identity as a principal in the target database.
How can you be so sure about this? Exactly zero of this is relayed in the error message presented to me. Additionally, as I was able to deploy to eastus2 without issue, this also seems to imply this was a different issue altogether than you are suggesting.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hi Mike,
Thank you for the detailed feedback and for your patience here – I completely understand how frustrating it is to wait ~70 minutes only to see a generic “deployment failed” error with no actionable details.
Based on the behavior you described and the fact that the same Redis Enterprise deployment succeeds in eastus2 but consistently fails in eastus, this strongly suggests a region-specific platform/capacity issue in eastus rather than a problem with your ARM/Bicep template or parameters.
the deployment should fail quickly with a clear reason such as “SKU unavailable or capacity exhausted in this region” instead of a generic ResourceDeploymentFailure after a long timeout. I’ve flagged this feedback to the team so they can review both the error message and the timeout behavior for such cases.
I hope this is helpful! Do not hesitate to let me know if you have any other questions or clarifications
Hi @Anonymous thank you for the kind words but what exactly do you hope that is helpful? I managed to "fix" the issue on my own by using another region, and your comments seem to suggest that you are going to flag this with a team somewhere to review the terrible user experience this has saddled upon your customer. Regions may play a role in this issue, but it is still very unclear exactly what occurred here. Can you please confirm that my correlation ID and all the information requested of me is being used to determine root cause? Thank you for your continued assistance.
Yes, your correlation ID and the details you shared are being used. I’ve passed them to the product team so they can pull the exact backend logs for your failed deployment in eastus and confirm root cause.as soon as the team confirms what happened, I’ll come back and update this thread with the final explanation, not just the workaround.
Thank you, Swapnesh. That is good to hear. Looking forward to hearing what has occurred here.
Hi @Anonymous why are you asking me for a correlation id when I have already provided it in the chat? Additionally you are asking me for the time of the incident and shouldn't the correlation Id already tell you this? What is the correlation ID correlating if not the time of the incident? I hope you can understand the concern. Additionally, why are you asking for this information nearly two weeks after the incident? You gave the very distinct impression that this was already being actively investigated. I hope you can understand the concern you are placing upon customers who report active and obvious defects in your software.
Unfortunately, the backend team attempted to validate the deployment logs for the provided correlation ID but did not find any logs. They searched for deployments from your subscription and discovered that the AMR cache was already created on 2025-11-15 at 12:31:53 UTC. They are now inquiring what's pending from this case.
Are you seeking the root cause of previous cache deployment failures attempted before 11/15?
Hi @VRISHABHANATH PATIL thank you for your investigation.
Unfortunately, the backend team attempted to validate the deployment logs for the provided correlation ID but did not find any logs
What? Why are you providing correlation IDs to your users when they do not seem to correlate with anything? I hope you can understand the concern.
They searched for deployments from your subscription and discovered that the AMR cache was already created on 2025-11-15 at 12:31:53 UTC.
Confirm that this is eastus2 and NOT eastus where the error occurred.
Are you seeking the root cause of previous cache deployment failures attempted before 11/15?
If that is the correlation ID of the failure I reported nearly two weeks ago, then yes? Why is it so difficult and takes so long to report obvious and flagrant errors occurring in your system? It is compounded by the painful consideration that such an obvious exception should be reported to you and your teams automatically in the first place. Does a deployment that takes over 70 minutes to complete with an obscure failure seem "normal" to you? What am I missing here? Again, I hope you can understand the rather obvious and apparent concern here.
Thank you for your patience. We have thoroughly reviewed the correlation ID and confirmed that no related logs exist for the earlier failure. The cache was successfully created in eastus2 on 2025‑11‑15, and there are no active issues at this time.
We understand your concern and will escalate this internally to improve error reporting and correlation tracking. While we cannot retrieve additional details for the previous attempt, please be assured that your feedback will bring improvements to prevent such gaps in the future.
Wow, so if I understand correctly @VRISHABHANATH PATIL , you essentially made me wait for half a month under the pretense that you were actively investigating this issue, when in fact you were not at all. In doing so, you allowed the logs to expire while they were still meaningful and valuable to the investigation? It also seems you and your team repeatedly misunderstood the situation, as I clearly stated that the WORKAROUND (as denoted by the "recommended answer" here -- one I cannot accept as such btw, adding to the perceived low quality experience from start to finish of your services) was to deploy to eastus2. This has been known for several weeks now, and you are repeating this in your findings as if this is a new development.
There may not be an "active failure at this time", but there is certain defective software lurking in your system. Defects that should be reported to you automatically and not weeks after the fact by your slow and clearly overburdened support team.
I hope you understand the concern. Please put yourself in my situation. Would you honestly feel this to be a pleasant user experience for your product? Thank you for your consideration.
We sincerely apologize for the frustration and inconvenience this situation has caused. Your concerns are completely valid, and we deeply regret that the investigation did not meet your expectations.
We acknowledge the gap in log retention and communication, and we are taking immediate steps to improve error reporting, proactive alerts, and support responsiveness to prevent this from happening again.
Thank you, @VRISHABHANATH PATIL for your understanding and reply, it is appreciated. To be sure, are you saying that when a 70-minute deployment fails without a meaningful message to your user, you will be getting a report of this immediately in your system and will not require the user to report it to you?
Hi @Anonymous why are you asking me for a correlation id when I have already provided it in the chat? Additionally you are asking me for the time of the incident and shouldn't the correlation Id already tell you this? What is the correlation ID correlating if not the time of the incident? I hope you can understand the concern. Additionally, why are you asking for this information nearly two weeks after the incident? You gave the very distinct impression that this was already being actively investigated. I hope you can understand the concern you are placing upon customers who report active and obvious defects in your software.
I have tried another deployment and instead of it gracefully with a comprehensive error message like you see in every Microsoft product but Azure, it fails with the most obscure and useless message you can think of, as if your team is creatively finding ways to confuse the user. Why are you emitting failure errors that give no indication of why the operation failed? I hope you can understand the concern.
Hi Mike-E-angelo ,
Welcome to the Microsoft Q&A and thank you for posting your questions here.
Could you please share the details requested in the private message for further investigation.
The error message you are encountering indicates that the deployment of the Azure Cache for Redis resource has failed, reaching a terminal provisioning state of 'Failed'. This can happen for a variety of reasons, including issues with resource availability, configuration errors, or permission problems.
To troubleshoot this issue, you can follow these steps:
If the problem persists, consider reaching out to Azure support with the correlation ID and tracking ID you provided, as they can help investigate further.
References:
I tried redeploying already, 3 different times and all 3 took over an hour to fail. Seems really broken.
I love all the reasons it is suggesting for the failure, but not really explaining why these very basic failure reasons do not make their way into the actual error being generated and displayed to the user.