Created using icon from srip at FlatIcon.com
December 9, 2025 / 0 Comments

Managing Delete Key Vaults

Having delete protection on shared cloud resources is usually a very nice and beneficial feature to enable, since it protects you and your organization from the disaster of someone accidentally deleting a resource they didn’t intend to by keeping the resource available in the background for restore after deletion. My team has the feature enabled on our storage accounts and some other resources which I knew about, but I did not know that our key vaults also had the same feature enabled. Until I was trying to create a new key vault with the same name as a key vault I had already deleted and was getting an error saying a key vault with that name already existed.

In this post I will show how to find and manage delete key vaults and how to permanently delete them if you want to. You could use this process to find a key vault to recover it if it was accidentally deleted, or you can use it to do what I did and get rid of it permanently so you can recreate it.

What’s in this post

Finding Deleted Key Vaults

When running a Bicep template, which was creating a new version of a key vault I had deleted moments before, I got an error that the key vault couldn’t be created because one with the same name already existed. Confused, since I knew I had already deleted the resource, I went back out to the Azure portal and searched for the key vault the template error indicated, which was called “biceptest”. As you can see in the screenshot below, searching for that name returned no results.

Screenshot of the Azure Portal page for Key Vault resources showing that one named "biceptest" does not appear when searched for, since it has been deleted.

As I mentioned above, key vaults can be set to not permanently delete immediately, and instead stay alive in the background for a set amount of time so they can be restored if needed. To find any deleted key vaults that are still available for restore, you can click on the “Manage deleted vaults” on the top menu of the key vault list.

Screenshot of the Azure Portal page for Key Vault resources showing where to locate the "Manage deleted vaults" button

When you click that, a new pane will pop up that will let you filter and view deleted key vaults by Subscription. Choose your subscription from the dropdown menu, and you will then be given a list of deleted key vaults that are still available for restore.

Screenshot of the Azure Portal page for Key Vault resources showing the "Managed deleted vaults" pane which lists recently deleted vaults that have not yet been permanently purged

Notice in the above screenshot that the deleted vaults list shows the date it was deleted and then the date it is set to be permanently removed from Azure. In my case, I had 90 days to recover a deleted vault.

Recover a Deleted Key Vault

To recover a deleted key vault, you need to check the box next to it in the pane showing a list of deleted vaults for a subscription, then click the “Recover” button at the bottom of the screen:

Screenshot of the Azure Portal page for Key Vault resources showing the "Managed deleted vaults" pane where you can click the "Recover" button to undelete the resource.

Permanently Delete a Deleted Key Vault

If you would like to permanently get rid of a deleted key vault, perhaps to create a new vault with the same name without getting an error, you will need to click the “Purge” button at the bottom of the screen after checking the box next to the vault you want to permanently delete.

Screenshot of the Azure Portal page for Key Vault resources showing the "Managed deleted vaults" pane where you can click the "Purge" button to permanently delete the resource

Note: If the key vault has been setup with “purge protection enabled”, you will not be able to purge/permanently delete the vault. In that case, the vault will only be permanently deleted once the preset number of days has been reached.

Summary

Choosing to delete a key vault through the Azure portal does not guarantee that the vault has been completely deleted from your system. If the vault was setup to have delete protection enabled, you may be able to recover the deleted vault for a set amount of time after it was deleted. If you want to permanently delete a vault that had delete protection enabled, you will need to go into “Manage Deleted Vaults”, choose the vault you want to completely remove, then click the option to “Purge”. Once you have done that, the key vault will be 100% gone and you will be able to create a new one with the same name if you choose to do so.

Related Posts

Created using icon from Umeicon at FlatIcon.com
December 2, 2025 / 0 Comments

Return the True URL for a Document in SharePoint Online Indexer for Azure Search

I am going to keep today’s post short and sweet, covering a quick change I needed to make to my SharePoint Online Indexer (still in preview but we’re using it for our custom chat bots) to make the index of a SharePoint library return the true URL of the source document so that we can feed that back to users so they can validate the chat bot answers.

It took me longer than I would like to admit to figure out how to do this, even though the metadata item is listed in the one and only Microsoft document for this tool, because I was wanting to return the URL and the documentation only mentioned URI and didn’t explain what they meant by that and gave no examples of it being used.

This index is specifically used for custom chat bots created through Azure AI Foundry, and not for those created with other AI or cognitive services within Azure. I saw a lot of documentation and forum posts about those versions of indexers, but didn’t see anything covering this topic specifically which is why I wanted to write this post.

What’s in this post

Adding SharePoint document URL to index results

For creating my Azure Search data sources, indexes, and indexers, I have used Postman to run the API calls needed to hit the SharePoint Online (SPO) indexer service, since that is the only way to create this type of indexer (can’t use the Azure portal wizard).

It is very simple to return the document URL in your index, you only need to add this line to your index, and then rename it/map it in the indexer definition if you want. I didn’t not want to rename it, so I only changed the index definition.

{ "name": "metadata_spo_item_weburi", "type": "Edm.String", "key": false, "searchable": false, "filterable": false, "sortable": false, "facetable": false },

Once you add that to your index definition, make sure to send the API request through again, then reset and run the indexer related to the index. At that point, you should be able to query your index through the console and see that URL included in the results of the index.

Screenshot of an Azure AI Search Index resource test query demonstrating what the full URL of a SharePoint document looks like in the index

Summary

If you are using the SharePoint Online Indexer for Azure AI Search (with Azure AI Foundry) and you would like to return the full URL of a source document for a chat bot response, you can do so by adding the “metadata_spo_item_weburi” metadata field to your index definition.

Related Posts

Created using icon from Freepik at FlatIcon.com
November 25, 2025 / 0 Comments

Cybersecurity News Sources I am Following

You need to regularly be reviewing news sources for announcements about cybersecurity threats, vulnerabilities, and exploits if you are working anywhere in the IT field. There have never been more threats to our digital footprints than there are right now, and attackers are getting more ingenious with their attacks every day.

I used to not care about following this type of news, but then the recent SharePoint legacy server exploit hit close to home for my team. We weren’t negatively impacted, but we could have been. Thankfully, other people at my company were already keeping on top of those things so we were able to act immediately to secure our server as soon as the vulnerability was announced.

My team is also diving heavily into the AI space, which has been riddled with vulnerabilities and hacks this year, which I’m also now able to keep on top of by following a few websites.

To make it easier to see recent news at a glance, I decided to make myself an RSS feed (is that outdated?) to follow a handful of the top cybersecurity news sites so that I could quickly get an overview of what’s being discussed.

Sites I am following

In my RSS feed for cybersecurity news, I am following these websites:

  • Dark Reading
  • The Hacker News
  • SecurityWeek
  • Ars Technica Security

The first two on the list, Dark Reading and The Hacker News, are the ones I end up clicking through to the most, but all have good feeds that you can follow easily. I personally am using feedly.com as my RSS reader tool, but you can follow the sites however you choose. Just make sure you read regularly since new threats are coming out all the time.

Related Posts

Created using icon from nawicon at FlatIcon.com
November 18, 2025 / 0 Comments

You should Make Your Writing Easier to Understand

As technical professionals, those of us in the IT field tend to lean towards writing with technical language when we are communicating with others, whether that is with other members of our own teams or with business users or customers. While we may find our technical writing easy to understand, that may not be the case for others that we are working with.

Recently I was writing an email to a business customer in another part of my company who we made a custom chat bot for, trying to explain to her how the bot was able to give great answers even if the information it was providing was not explicitly written within the documentation we had given the bot for the Retrieval-Augmented Generation (RAG) model. Writing that email turned into a 20 minute learning experience of how I could simplify my explanation to a level that a normal business user would understand. I’m not sure why this idea popped into my head today, but I remembered that there are online services that will check the reading level of your writing, so I put my email draft into one of those and was surprised by the outcome and knew I needed to rewrite the email to be easier to understand for non-technical people.

What’s in this post

Average U.S. Adult Reading Level

Based on different studies and models, it is estimated that the average reading level for an adult in the United States is around the 7th-8th grade level[1]. There are other estimates that say that 54% of adults in the U.S. have a 6th grade reading level or below[2], which is a startling statistic.

I bring those statistics into this post because they point out why we as technical professionals may need to change our writing behaviors, especially when communicating with non-technical business users or customers. We need to make sure others understand what we are trying to say. If we are writing at a college level but the average person can only comprehend up to a 7th or 8th grade level, there are going to be misunderstandings.

Check Reading Level Online

In the email I was writing about how our chat bot worked, when I realized that it was overly complicated from a business user’s perspective, I started researching concrete changes I could make to how I wrote the message to make it more understandable to a normal, non-technical person. I love being in the weeds of the technicalities, but I know most of our business customers don’t; they only want to know how to use the tool to help themselves.

The best resources I found were the “Hemingway Editor Readability Checker” and then an older PDF document from Montclair State University which walks through getting analysis of writing in Microsoft Word. Jump to the section below to learn more about the Microsoft Word method.

The “Hemingway Editor” is a simple website where you can paste in your text you’d like to check, or provide a full text document, and it will do a quick analysis and highlight sentences that are hard to read, very hard to read, or not hard to read at all. It also gives a numeric “Grade” value indicating at what grade someone would be able to read the text.

When I pasted in my original email draft, it rated it at Grade 14, and marked all sentences in the text as either hard to read or really hard to read.

Screenshot of the Hemingway App readability checker showing a block of text marked with red and yellow highlights for very hard and hard-to-read sentences. The right panel displays a readability grade of 14 and notes that most of the six sentences are difficult to read

That review confirmed that I needed to rewrite the email to be less technical and easier to understand for average people. The website recommends aiming for Grade 9, which is what I tried to do. After a lot of editing, I got the score down to 10, which was as close as I could get to 9 without completely changing what I was trying to communicate.

Screenshot of the Hemingway App readability checker showing a block of text highlighted mostly in yellow, indicating hard-to-read sentences. The right panel reports a readability grade of 10 and notes that 5 of 6 sentences are hard to read, with none marked as very hard.

Check Reading Level with Microsoft Word

If you don’t want to use the online editor to check your writing level, there is also the option to do that through Microsoft Word. Before you can check the reading level, you first must enable an option to do that.

In Word, go to File > “Options”, then “Proofing”. Under that page, check the box for “Show readability statistics”. Click OK to save the change.

Screenshot of Microsoft Word "options" window on the "Proofing" page, demonstrating how to turn on the readability statistics function through a checkbox option.

Once you have enabled the feature, you can then go to the “Review” tab and click the button for “Spelling and Grammar”.

Screenshot of the "Review" ribbon tab at the top of the Microsoft Word screen highlighting the location of the feature "Spelling and Grammar".

When you click that, you will first get a panel that will point out any grammar issues that the program has found. If you don’t care about that, you can click the “X” at the top left of the window (next to “1 remaining”) to close those suggestions.

Screenshot of the first page of the "Spelling and Grammar" editor panel in Microsoft Word

After closing the grammar window, you will then get scores for your writing and recommendations for fixing the writing. There is also an option to check the similarity of the text to what can be found online, which might be useful for teachers and professors that are reviewing the writing of others and who may be concerned about plagiarism.

Screenshot of the "Spelling and Grammar" editor in Microsoft Word, showing the Editor Score of 89% for the document and other corrections, refinements, and features available for checking the document.

If you keep scrolling almost to the bottom of that recommendations panel, you can click on the “Document stats” button under the “Insights” heading, which will bring up a separate window with the reading level information and other details about your writing.

Screenshot showing the bottom of the "Spelling and Grammar" editor screen in Microsoft Word, where you can find the button called "Document Stats" to get insights into your document

While there are other statistics about my writing that could be helpful in other scenarios, what I am most interested for this example is the “Flesh-Kincaid Grade Level”. In this case, Microsoft Word recognizes the same reading level as what the online checker has for my simplified email. Which is cool.

Screenshot of the "Readability Statistics" window in Microsoft Word, which shows the word counts, averages, and readability scores of the document. The reading level of my sample email is 10.0 in this window.

Reading Level for this Post

I got curious while writing this post, wondering what its reading level would be. The answer? 12.2 according to Microsoft Word and 13 according to the online Hemingway Editor.

Screenshot of the "Readability Statistics" window in Microsoft Word, which shows the word counts, averages, and readability scores of the document. The reading level of my blog post is 12.2 in this window.

Screenshot of the Hemingway Editor Readability Checker showing a scoare of Grade 13 for my blog post draft, with 13 of 34 sentences having been marked as very hard to read, and 10 of 34 being marked as hard to read.

I thought it would be higher, so I’m glad to see that it hopefully isn’t unreadable for your average IT professional.

Summary

Technical people are often bad communicators, especially when it comes to interacting with non-technical people. I can’t say that we’re all terrible at it, but many technical degrees require technical communication classes for a reason. I am as guilty of too-elaborate writing as others are. But I am now going to intentionally work on better summarizing myself when emailing and talking with my business users. I would never want to make someone feel dumb because I was talking at too high a level.

Sources

Related Posts

Created using icon from FlatIcon.com
November 11, 2025 / 0 Comments

Change the Admin Password on an Oracle Database

Do you have an old or bad Oracle admin password that you’ve been putting off changing because you’re scared of the impacts? Has your Oracle SYS user password been through the hands of multiple generations of database developers? Or maybe you just need to start regularly rotating your admin passwords to meet auditing guidelines? If you answered yes to any of those, I am here to help you make the change of your admin passwords on your Oracle Cloud Infrastructure (OCI) databases.

This post focuses on changing the passwords for OCI databases and pluggable databases. I specifically have done this on database version 23.9.0.25.07 and 19.0.0.0. The process was exactly the same for both, and is covered fully in this post.

What’s in this post

Why change your SYS and SYSTEM user passwords?

As we all know, password security is one of the easiest ways to increase the security of any account you own, which will include the admin accounts for your OCI database. There have been countless data breaches across all sectors, even ones you would think would be better at making strong passwords, due to people using too simple of passwords like “admin123” or “password”. We want to be better than that.

Regular rotation of your strong passwords will also increase the security posture of your system, which is another reason you may want to consider changing the passwords of your SYS and SYSTEM users on your database, especially when I show you how easy it is to do.

Disclaimer: This process worked for me and my systems using the OCI databases, it may not work as flawlessly for you. If your overall architecture includes having applications use these admin accounts for access, changing the password could break those systems. Make sure you don’t have any applications, pipelines, or processes using these accounts before you start. Or simply be aware that they will all have to be updated with the new password once you change it on the database (but don’t be that person, use service accounts or managed identities instead!).

Change the SYS User and TDE Wallet Passwords through the Console

The best and easiest way to change the password for your SYS admin account on an OCI database is to do so through the OCI console. If you navigate to the database you need to make the change for (not the Database System or the Pluggable Databases, just the Database level), you can find the option to change the passwords under the additional menu on the top right of the screen. Choose “Manage Passwords”.


That will bring open a pane that looks like this, which will allow you to change the password for your Admin account (SYS user) or for the TDE wallet.

You will only be able to change one of those passwords at a time. To change the admin user password, leave the option for “Update administrator password” selected, then enter the new password into both boxes. When you start typing, you will be provided the requirements for the password.

If you enter a password that doesn’t meet those requirements then try to save, you will get this error:

For my database, the password requirements are the following:

  • Length: 9-30 characters
  • Alphabetic characters:
    • Minimum 2 uppercase
    • Minimum 2 lowercase
  • Numeric: Minimum 2
  • Special characters:
    • Minimum 2
    • Only options are hyphen, underscore, pound

Once you click “Apply” to save the password, it will take about 2 minutes for the database to make the change. During that time, the state of the database will show as “Updating”.

If you would like to update the TDE Wallet password as well, you will need to wait for the other password change to apply first. It is just as simple to update that password as it was to update the admin password, except this time you must first specify the previous password along with the new password and confirmation.

Once again, the database will go into an “Updating” state once you click “Apply” to change the password. For me though, the TDE Wallet password took much less time to apply.

Change the SYS Password on the Pluggable Database Level

In my situation, once I updated the SYS password on the container database (CDB) level, the same change was automatically applied to all the Pluggable Databases (PDBs) within that CDB. Which was a surprise to me, since everything I was reading online before making the change seemed to indicate that I would need to make the change there as well.

I was able to confirm that the PDB SYS user password had been updated on all PDBs by updating my connections to them in my IDE to use the new password. Once that connection worked, I knew that the password had been updated everywhere.

Change the SYSTEM User Password on the Container Database

The console method of updating the main admin password for an OCI database unfortunately won’t update the passwords for all system users at the same time. In my case, I also needed to update the password of the SYSTEM user. (Curious how many system users there might be on your database? You can view the complete list here.)

To change the password of the user “SYSTEM” on an OCI database, you will need to connect to the container database (CDB) and run the ALTER USER command to change the password. You can do that through the terminal/command line or through an IDE. I chose to make the change through an IDE.

Since I wasn’t sure what was going to be required for updating this user, I decided to start at the Pluggable Database Level, where I ran this command: ALTER USER SYSTEM IDENTIFIED BY "password";. I got an error when trying to run that though:

I researched that error and found this Oracle help document, which indicated that changing the password for “common users” needs to be done at the CDB level, or the root level of the container database. Based on that, I then ran that same ALTER USER command on the CDB level and it completed without any issues.

I’m not sure why, but the SYSTEM user then became locked (or it was locked before I changed the password but I hadn’t seen that). After changing the password for that account, I wasn’t able to login on either the CDB or any of the PDBs with that user, so I was worried something had broken. However, logging in with a different user I was able to see that the SYSTEM user was locked on the CDB level, but not the PDB level, so I unlocked the account and was then able to login on the CDB and PDB level. And that also taught me that if a user is locked out on the CDB level that they will also not be able to login to any of the PDBs. Which makes sense for security purposes.

Change the SYSTEM Password on the Pluggable Database Level

As with the SYS user, once the SYSTEM user password was changed on the container database (CDB) level, the password for the account was also automatically changed on the pluggable database (PDB) level without me having to do anything.

Summary

The process of changing the admin account passwords on an OCI database is simple and straightforward if you know what you need to do. To change the SYS user password, use the OCI console on the container database level. To change the SYSTEM user password, as well as any other system/common user passwords, you will need to run an ALTER USER SQL command to make the change at the container database level. While I didn’t need to update the password on the pluggable database level at all, you will need to verify the same for your own system.

Related Posts

Created with Icon from Freepik on FlatIcon.com
October 28, 2025 / 0 Comments

Troubleshoot ALL Layers of Your Data Flows

This is going to be a short post, which I am writing as a reminder for my future self as well as any of you reading out there.

If you are troubleshooting an error with your pipeline, especially if you work in a database system that has layered views, make sure you fully dig down through all layers of your data setup before you make a ticket with Microsoft. I learned this the annoying way over a work week while working through a ticket with Microsoft for a very strange issue I was seeing in a pipeline that uses a Synapse Serverless SQL Pool. We had checked so many things that week with no luck in changing the outcome of how the pipeline runs, and then the pipeline just went back to working when I ran it outside of its schedule.

What’s in this post

The Error

The error I was seeing made it look like the Serverless SQL Pool views, which use an OPENROWSET call to a parquet file, were referencing the wrong source file even though I confirmed multiple times that the view definitions were correct. For example, the view was written to use parquet files under TestDatabase/MyTable/** as the source files, but the error was making it seem like they were instead pulling data from TestDatabase/OtherRandomTable/** which was confusing to say the least. I thought that the Serverless node was broken or had a bug that was making the views look at “OtherRandomTable” files instead of the correct files.

The Cause

The error happened because multiple views used a CROSS APPLY to another view tied to a parquet file in a data lake, and that parquet file was being deleted and recreated by a parallel pipeline. When the failing pipeline tried to reference its views, it couldn’t find that base view because the source file had not yet been recreated by the parallel pipeline. Makes sense and is so obvious in hindsight, but it took Microsoft support directly asking me to make me realize that I had a view referencing another view, which I needed to check the definition of.

The change I needed to make was to update the pipeline triggers so that the process deleting and recreating the base view would be done making the parquet files when the second pipeline ran and tried to use those files.

If I had done my due diligence and dug through every layer of the data environment, which I am normally good at with other scenarios, I would have quickly and easily discovered the issue myself. But sometimes we need to learn the hard way because our brains aren’t running at full capacity. (It also helps that I finally had dedicated time to set aside to this problem and so wasn’t trying to multitask multiple work items at once.)

Summary

If you are troubleshooting ETL failures of any kind, make sure you dig down through all layers of the process to ensure you have checked everything possible related to your failure before reaching out to support. They’ll happily help you find what you missed, but it will save everyone time if you can figure it out yourself first.

Related Posts

Created using icon from SBTS2018 at FlatIcon.com
October 21, 2025 / 1 Comment

Azure SQL Database – Removing Replicas Doesn’t Delete the Replica DB

A couple months ago, I was asked to add geo-replication for all our Azure SQL Databases to align with our recovery strategy in case of disaster. A few weeks ago, when upper management finally realized the full cost of that replication for all our databases, they requested that we remove replication from anything that isn’t business critical and doesn’t need to be recovered immediately in case of a disaster to reduce the shocking cost of replication.

I mistakenly didn’t do research before doing what I thought was fully removing the replicas I had previously created, which was removing the replica from the primary databases. I only recently realized that those replica databases were still alive and well and charging us money that we thought we were already saving while I was reviewing resources for another task . Keep reading to learn how to do better and fully get rid of the replicas you no longer need.

What’s in this post

What is a replica for an Azure SQL Database?

A replica for an Azure SQL Database is a way to make a secondary copy of your database on a separate logical SQL Server in a different region that you can keep available to failover to in case of a full region outage in Azure. Although this scenario is rare, it has happened in the past, and most companies do not want to be caught without their vital resources for hours while Microsoft troubleshoots their outage. In such a case, having a geo-replica means that you can immediately failover to an exact copy of your database in a different region and keep your business running.

How to Remove Replica Link from Primary

Getting rid of a replica of an Azure SQL Database is a two step process. The first step is to remove the replication link between the primary and secondary databases, which I will cover here, and the second step is to delete the database itself, which I will cover in the section below.

Removing the replication link between primary and secondary is as simple as the click of a button. Navigate to the primary database for which you want to remove the replica, and go to the “Replicas” page under “Data Management” in the menu.

On that page, you will see the primary database listed first, then in the section below that, any and all replica databases.

To remove the replica, you will click on the ellipses menu on the right side of the replica database, then choose “Stop Replication”.

At first I was confused as to why this said that it was going to stop replication because I was assuming that I would be able to delete the replication and delete the replica in one step. But now I better understand that this is a two step process.

After you have chosen to “Stop Replication”, you will get a prompt to have you confirm that you want to remove the replica. It also clearly points out what happens when you choose to do this, but I just didn’t understand what it meant. “This will remove server/MySecondaryDatabase” from replication relationship immediately and make it a stand-alone database.” When I read that, I thought it meant that removing the replication would be reverting the primary database to a standalone database, but now I know that it means what it says: the secondary database will become a standalone database that you will later have to deal with.

Click “Yes” to remove the replication relationship.

You will get a notification that replication is being removed.

After a few minutes, you will be able to refresh the page and see that no replica link exists for the primary database anymore.

However, if you search for the name of the database that you previously had a replica for, you will see that the replica still exists, it’s just no longer linked to the primary through a replication process.

Fully Removing Replica (so that it’s like it never happened)

To get rid of the replica you no longer want so you can stop being charged for it, you will need to navigate to that former-replica database in the portal and then delete it like you would any other database. Before deleting, ensure that this is the database that you really want to get rid of since the deletion cannot be undone.

Once you have deleted the Azure SQL Database resource for the replica, you are finally done with removing your replica.

Summary

If you want to remove a geo-replica database from an Azure SQL Database to save money (or for any other reason), you will need to complete the two step process to do so. First, remove the replication relationship between the primary and the secondary through the “Replicas” page under the primary resource. Once that is complete, navigate to the former-secondary database in the portal and delete the resource. Removing the replica relationship alone won’t delete the database, and you will keep getting charged for that secondary database until you fully delete it.

Related Posts

Created using icon from srip at FlatIcon.com
October 14, 2025 / 0 Comments

Recent Security Issues with AI

Are you and your company keeping track of the security of the artificial intelligence (AI) tools your employees are using? Are you aware that AI is not magically more secure than other software tools, and may in fact be more prone to attack due to its newness and speedy development? If not, you need to start watching the news for cyber attacks that are related to AI. These aren’t even exclusive to all the new AI startups making moves in the industry; even tech giants like Google have been found to have major flaws in their AI tools.

I am not a cybersecurity expert, so I won’t go into detail attempting to cover the vulnerabilities that have been found, but I highly encourage you to read through these two articles I found recently that covered the exploits.

The first is about three major vulnerabilities discovered in Google’s Gemini AI assistant. Three different issues spread across different facets of the tool. I expect better of Google.

https://www.darkreading.com/vulnerabilities-threats/trifecta-google-gemini-flaws-ai-attack-vehicle

The second article is about a much more niche AI tool, a “Model Context Protocol” (MCP) server package that had the most ridiculously simple exploit.

https://www.darkreading.com/application-security/malicious-mcp-server-exfiltrates-secrets-bcc

Standard cybersecurity processes are more important now than ever. Never trust the software or code you are using. Don’t put your most sensitive company data into tools managed by people outside of your company that you don’t trust 100%. Due diligence is always useful. AI is proliferating more than ever and it is guaranteed a lot of the tools won’t be following security best-practices. Protect yourself as much as you can using common sense, and keep on top of recently announced exploits using trusted news sources.

Created using icon from Freepik at FlatIcon.com
September 23, 2025 / 1 Comment

Synapse Serverless SQL Pool View Seemingly Caching Data

This morning I ran into the strangest data issue I’ve seen with Azure Synapse Serverless SQL Pools, which is that a view we have seemed to be caching data, and that data was very weird, wrong for the column data type, and causing issues with an application query. While I still have no idea how or why this happened since the serverless SQL pools aren’t supposed to cache data like the standard SQL pools, but I thought I would share what I saw to maybe help others (and to see if anyone else knew why this was happening).

I was able to correct the issue to get the app query working again, I just won’t ever know why (unless you know why, in which case you should share in the comments below!).

What’s in this post

Background

I first learned of this issue through an application developer on another team emailing me saying that they were running the same query on our serverless and dedicate SQL pools on Synapse, and the query was working as it normally does on the dedicated pool but was giving the following error on the serverless SQL pool:

Msg 241, Level 16, State 1, Line 3

Conversion failed when converting date and/or time from character string.

The query they were trying to run is one that hasn’t had any issues in the past.

In our setup, we load the same data into both our serverless and dedicated SQL pools for different use cases, and both are loaded from the same set of delta parquet files in a Data Lake on an Azure Storage Account. Which means that there should be no reason that the query running on one should run and the other not.

The first step of my troubleshooting process was to replicate the error that the developer sent me, and I was able to do that. I then reviewed the very long query for anything that was doing a CAST or CONVERT on a date field, which helped me narrow down the problem to a single view on our serverless pool.

The Weird Data

After I identified the one view that seemed to have the bad data on a date column, I ran a DISTINCT query on that one column and received the most confusing results.

Screenshot of SQL query in SSMS demonstrating the bad data contained in the date column of my serverless SQL pool view.

None of those values look like dates to me. Which made me question myself and the data type for that column “order_entry_dt”, since a data column couldn’t possibly hold string values like this. But no, the column data type does say it’s a “datetime2”.

Screenshot of the problematic view column and its data type

At that point, I started downloading and reviewing individual parquet files from the Data Lake to see if any of them had that weird data, and none did.

The next step I took was to look at the view definition to see what it was doing again, to make sure I was looking at the correct source data, and that all looked good. I decided that I would run my distinct query on the view itself, but then also run the exact same query using the SELECT statement that defines the view, to see what both returned. And that made things even more weird, because it confirmed that the source data should be correct, but the view is somehow wrong.

Screenshot of two SQL queries in SS<S showing that selecting from my view and running the select contained in the view definition return different results

If the view definition uses that exact same “OPENROWSET” query as it’s definition, why does the view return different data than the “OPENROWSET” query??

Correcting the Problem

Even if I couldn’t figure out why or how the problem data happened, I still needed to figure out how to resolve the issue so that the app query would start working again. What I decided to do was drop and recreate the view, which is easy given how simple the view definition is.

Once I dropped and recreated the view, I ran the exact same queries as above again, yet this time the view started to return data that I expected.

Screenshot of two SQL queries in SSMS showing correct data being returned from selecting from my view and run the query that is the view definition

So why was the view data weird?

While writing this post, I decided that I couldn’t let this go without knowing why the data got weird, so I decided to test out some theories for myself. (Spoiler: I couldn’t figure it out.)

My first theory was that someone ran an UPDATE query on the view accidentally to change the data. But that is not allowed in serverless SQL Pools, which I even tested out myself. By making a copy of the problem view with a different name and then trying to run an update statement, I was able to prove to myself that this theory was not how the bad data was created.

Screenshot of a SQL query in SSMS where I attempted to update data in a column in the view, which pulls data from a parquet file so thus cannot be updated

Then I thought maybe someone wrote a query to change the underlying parquet files directly, but that doesn’t seem to be possible either.

The only thing I can now think of is that someone accidentally overwrote the source parquet file, or made a second that was also used as source data, which contained the bad data. Parquet files are immutable, so there should have been no way for someone to update a parquet source file with bad data to get bad data into our serverless pool view.

I have learned many things today, but one of those things is not why this issue happened, unfortunately.

But like I said above, if you have ideas, I would love to hear them in the comments below!

Summary

If you run into this same strange issue where a Synapse Serverless SQL Pool view has weird data that you don’t expect, and that data doesn’t match the query that is used as the view data source, drop and recreate the view to fix the problem.

Related Posts

« Older posts

Categories