Azure SQL Database
An Azure relational database service.
6,233 questions
AZURE SUPPORT FRAUD
![](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, 74%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EGM%3C/text%3E%3C/svg%3E)
Geter Moura
0
Reputation points
Reposting as my fist post was locked without response and without any reason given.
I'm posting this not because I want, but because there's no other thing I can do before I sue Microsoft. You should see this post as a last try of me trying to help you do the right thing, before I go crazy with the absurd responses I'm getting from Azure support that is clearly outsourced and have no clue what they are doing and are just going hardcore on not refund me to meet their goals.
I'm gonna be as detailed as possible as I've been with since the beginning with them.
I have a .net framework web API hosted on azure in a web app. In February I created a staging slot for it for testing and also had to create another SQL database as my production app uses it. When creating the Azure Portal offered a free 100,000 vCore seconds SQL elastic pool database. I chose that but that didn't last long as on the next day it was blocked saying my free seconds were all consumed. So I had to activate the pay as you go charging for it.
After that I did my tests and all went fine. On the 14th of February I stopped the web app (as my activity logs shows). On the 19th I checked my subscription and my billing forecast was sky rocketing because of the SQL elastic pool database. So, I immediately deleted it and got a successful confirmation.
Few days later I checked it again and for my surprise it was even higher, showing the staging SQL database as the most costly resource. I was like "WTF, I deleted this SQL database days ago! What happened?". And for my surprise when I looked at my resource list, there it was again the database I deleted days prior. So I deleted again and had a successful confirmation for it, AGAIN.
Days later I checked and the database was back there incurring charges ONCE AGAIN. Then I opened a ticket for Azure billing support, taking screen shots as I was performing the THIRD deletion of that database with time stamps and all.
Then the support hell started. With clearly clueless staff, no matter how much detailed information and screenshots I gave them, they would not understand the issue let alone know what could be happening. So they scheduled a Teams meeting with me so that I could show them my issue. Two Indians from the outsource support called me and I went through it all AGAIN. Performing live the FORTH attempt of deleting the data base for them. After the 4th attempt we stayed with the portal opened refreshing to see if the database would show back and in about two minutes it was showing back at my resource list. Immediately after seeing the behavior of the Azure Portal silently recreating a deleted database without permission or notification, they where quick and spot on on asking me to go to the web app(the one stopped since the 14th of February) that used the database to see if there was a connection string pointing to it and asked me to delete it. I deleted connection string from the configuration, performed a delete on the database once more and the SQL database was not recreated. After that they acted like they solved the issue and that it was my mistake of having a connection string configured on a stopped web app pointing to a deleted database. Then I brought up many points to them before finishing the call:
- A deleted resource should not be silently recreated without permission or warnings.
- A stopped web app could not have tried to connect to it, because is was stopped.
- EVEN IF it was running, the ONLY thing that should have happened was an connection error to the deleted database not existing anymore
- That a connection string holds no information more than the address(ip/host) and login information and nothing on how to recreate a database.
- I simulated another database delete for them to show what in the delete modal there absolutely no warning saying that the database could be recreated by only having a connection string pointing to it.
After a few days I got a reply saying that they would refund me an amount less than what I expected and I did not understood why it was not all of the amount the resource incurred since after I tried to delete it from the first time. They said the smaller then expected amount was refunded and that it would reflect on my credit card bill. BUT IT NEVER DID.
After reviewing the billing statements form February and March I noticed that It was showing an "SQL Database Single/Elastic Pool General Purpose - SQL License" resource that was not showing in my actual "All Resources" page in the Azure Portal.
I contacted them again to say that the refund was never given by my bank and that another resource related to that SQL database was still incurring charges and was not showing in my resources list. They scheduled another Teams call and I showed them the billings and that it was now showing in the portal. They also asked me for the activity logs and there we could see my 1st delete attempt on the 19th initiated by my user and right after another entry showing the database was recreated, initiated by: "-" Yes, the activity logs shows a DASH character in the field where it should show the name of who initiated the action.
Even after all that evidence they replied couple days later saying that it was my fault that the SQL database was getting recreated because A CONNECTION STRING was configured in my STOPPED WEB APP and that no other refund would be given.
I REPEAT: THEY CLAIM ITS MY FAULT THE SQL DATABASE WAS SILENTLY RECREATED BECAUSE MY STOPPED WEB APP HAD A CONNECTION STRING POINTING TO IT.
Azure Portal/inner workings clearly has an issue of silently recreating SQL Databases by only having any web app with a connection string pointing to it and they are blaming me and saying the connection string is to blame.
Please any MVP or whatever help get this fixed. Support ticket number is: 2503120040007117
I think I might ask Bill Gates to put me as CEO of Microsoft at this point because clearly the AZURE support does not even know what a connection string is, what it is used for and what it can/cannot do. Knowing what a connection string is these days clearly qualifies me for the job.
That is my last attempt to get REAL help before I sue Microsoft.
Thank you.
Azure SQL Database
{count} votes
-
Oury Ba-MSFT 20,816 Reputation points Microsoft Employee Moderator2025-05-07T21:07:26.51+00:00 Thank you for reaching out and sharing your detailed experience. I sincerely apologize for the frustration and inconvenience you have encountered with the Azure support team and the recurring charges for the SQL database.
Your efforts to resolve this issue and the detailed information you have provided are greatly appreciated. I want to assure you that your concerns are being taken seriously, and I will do my best to assist you in resolving this matter. I have started a conversation with the case owner to ensure the correct actions/information is shared with them.
Regards,
Oury
-
TP 119.1K Reputation points Moderator2025-05-08T01:47:29.9633333+00:00 Hi,
First, if billing support said you would receive a refund and none has been given after significant amount of time, I agree that is a problem that Azure support needs to address immediately.
Second, in regards to most of your other points, I respectfully disagree based on the information you have provided combined with my experience with Azure SQL since it was first created.
Below is my opinion regarding potential explanations and more information about what happened. Since I only have limited information it is possible that some of what I explain below will not fit your situation 100%.
I have seen databases be created in the past where I didn't know the cause at first. Some were created by an application, some by another admin, and others by some sort of automated deployment script or job. In no case was the cause an Azure bug.
As to why the database was recreated after you deleted it. Your web app may be configured to check if database exists and automatically create it if not. This is common feature of Object Relational Mapping (ORM) packages.
For example Entity Framework has this and it may even be default behavior in some/all cases. Many tutorials/documentation/sample code demonstrate/include this when showing "Code first" methodology. Please note that it isn't only EF that has this--other ORMs/data access layers include it as well.
The fact that the database stopped being re-created as soon as you removed the connection string was not "just a coincidence" in my opinion. Without the connection string your app had no way of knowing which server to attempt to connect to and create the database.
As to why there is a dash for "Event initiated by", that is normal in some cases. One such case is if an application connects to the logical Azure SQL Server and creates database via T-SQL. This is how your web app connects. There will be some entries in Activity log with Event initiated by - , however, if you look in the JSON of the entries you will typically see Caller: <user account>, IPaddress <client IP address>, etc.
Examining these entries combined with querying current SQL Server connections could've shown conclusively that the requests came from your web app if in fact that is what occurred. Or, if the create came from some other source you would've been pointed in another direction.
Further, if you look at the owner of the database via SSMS or similar method, you can see account name there (important clue). Still more fine details related to the database creation can be viewed if you have SQL auditing enabled.
As to your app being stopped. Did you have all slots of your web app stopped? You mentioned a staging slot. If that is the only slot you created, you would need to keep both your Staging slot and Production stopped. Stopping one of them wouldn't be enough.
Connecting with excessive permissions. An application should use an account that only has bare minimum permissions to the database needed for the application to function and no more.
For example, if an application only needs to read/insert/update/delete on certain tables and execute user stored procedures then that is all the permissions the account should have. No ability to create databases, create/drop/truncate tables, etc. This is time consuming and requires knowledge of permissions/security and testing to make sure app still works with limited permissions.
Perhaps if you explain what you think happened to billing support and that it was completely unintentional, they will refund more of the balance this one time. It is worth a try.
-
Geter Moura 0 Reputation points
2025-05-08T03:36:03.26+00:00 TP,
Thanks for replying.
The web app had the standard production slot and I created a staging slot.
Each slot has its own isolated configuration. The staging slot never connected to the production SQL database and the production slot never connected to the staging database, obviously.The single place in my whole Azure subscription that had a connection string pointing to the new database I created for the staging was the configuration of the staging slot.
I know that Entity Framework can recreate a database depending on the configuration of the DBContext.
As I stated, the staging slot was stopped, and still is, since the 14th of Feb.If you say that both need to be stopped that doesn't make any practical sense:
If I have a production slot of an application it CANNOT stop. And I need a different database for each slot for obvious reasons.
Also, if that's the case, having isolated configuration for each slots makes no sense at all. Why have connections strings for each SQL server on each slot configuration if the production, that cannot be stopped, will somehow be affected by the staging slot configuration?The user in the connection string of the staging environment was a user with full rights. It had to have create rights because when I first ran with the application I ran it with a less privileged user that was throwing SQL exceptions that the user could not create the tables(as it was empty because I has just created it on the portal). So I had to change the user. And its just the staging slot, not the production one.
Azure SQL server has a LOT of limitations and restrictions that on premises SQL Server do not have, like attaching a profiler.
In the same fashion, it cannot in any situation, allow the creation of a database that incur charges without notifying the owner , hence my " silently ".
Specially when you have so many different options of databases that vary a lot in price. How it would know what tier of database to create?By the way, my solution also deploys couple WebJobs. But those are tied to the web app being stopped or started. So as it was stopped it should not do anything.
Sign in to comment
Sign in to answer