Recently I was working with a colleague and we were trying to track down where specific data had been stored in a Log Analytics workspace. Specifically, we were using the Upgrade Readiness solution and we were tracking down where the data was being written when we updated applications which were in a “Not reviewed” state. We expected the data was in Log Analytics and we knew a sample of the data, but we did not know which table had the custom data which we had added via the solution.

The query below searches an entire workspace for specific content:

search “<string you are searching for>”

Example:

search “Cameron Fuller”

A sample output for this query for what we wrote to the Upgrade Readiness solution is shown below: (please note, the data appeared for me the next day after adding the records in the Upgrade Readiness solution – not immediately).

If you open the details with the greater than sign on the left, we can list all fields, and as you can see the AppOwner field below has the value I was searching for.

Here’s a sample response when the string is found in multiple tables.

For background, you can configure this in the Upgrade Readiness solution by going to the Prioritize Applications section, and opening the content listed as “Not reviewed”

From there you can put in the information that you are want to add related to this specific application. I am using the “App owner” field as the key which I’m searching on in the Log Analytics workspace.

This query can also be used to search for specific strings (as an example maybe sample PII data to validate if it exists anywhere in the workspace).

Summary: The query in this blog post provides a quick way to search a workspace and find any tables which contain the data that you are looking for. On the Upgrade Readiness example, when you use the bulk edit option, data is written to the UAApp table but those records do not appear to be available when querying for a while (potentially the next day as I saw in my tests).

Update: The original query in this blog post had a search * which is not a recommended approach which is quite heavy, inefficient query, so should be used sparingly.

Update 7/6/22: A slight variance I have been using on this often is:

search “test” | project $table | distinct $table | sort by $table

This provides just the list of tables that contain the content you are looking for.