SecurityInsights: Old Workspace ID Persisted for a period in backend after recreation of workspace with same name

[kaovd]

API Specification is 2021-10-01-preview, also present in previous preview versions

An issue occurs when deleting and recreating a workspace under the same name, where creation of new alert rules from Sentinel onto a workspace presumably does a workspace ID lookup and comes back with an ID of the previously deleted workspace

Example POST:

id: "/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.OperationalInsights/workspaces/workspacename/providers/Microsoft.SecurityInsights/alertRules/alertId" kind: "Scheduled" ... snipped type: "Microsoft.SecurityInsights/alertRules"

Example response:

{"error":{"code":"BadRequest","message":"Failed to run the analytics rule query. Log Analytics workspace '{old workspace id}' could not be found."}}

In my example, I have just deleted a previous workspace titled "workspacename" and created a new one, with the same name. The previous workspace had a workspace id of {old workspace id}, the new workspace has a different workspace id.

For some reason the backend does not refresh or caches the old workspace id's for lookup purposes and does not refresh them until after a while, even when using the permanent deletion feature of a workspace. This is generally annoying when rebuilding workspace in CI/CD testing capacity.

In addition other odd behaviour occurs, some alerts, incidents and automation rules still persist onto the new workspace. Rules that are not scheduled/NRT or are created in a disable state appear to work fine implying its happens during the lookup of the workspace when a rule is enabled to trigger its first run or along those lines.

I haven't tested the exact time period (its likely a few hours?) but definitely by a few days workspace and rules show back blank again

[ghost]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @amirkeren.

Issue Details

---

API Specification is 2021-10-01-preview, also present in previous preview versions An issue occurs when deleting and recreating a workspace under the same name, where creation of new alert rules from Sentinel onto a workspace presumably does a workspace ID lookup and comes back with an ID of the previously deleted workspace Example POST: id: "/subscriptions/xxxx/resourceGroups/xxxx/providers/Microsoft.OperationalInsights/workspaces/workspacename/providers/Microsoft.SecurityInsights/alertRules/alertId" kind: "Scheduled" ... snipped type: "Microsoft.SecurityInsights/alertRules" Example response: ``` {"error":{"code":"BadRequest","message":"Failed to run the analytics rule query. Log Analytics workspace '{old workspace id}' could not be found."}} ``` In my example, I have just deleted a previous workspace titled "workspacename" and created a new one, with the same name. The previous workspace had a workspace id of {old workspace id}, the new workspace has a different workspace id. For some reason the backend does not refresh or caches the old workspace id's for lookup purposes and does not refresh them until after a while, even when using the permanent deletion feature of a workspace. This is generally annoying when rebuilding workspace in CI/CD testing capacity. In addition other odd behaviour occurs, some alerts, incidents and automation rules still persist onto the new workspace. Rules that are not scheduled/NRT or are created in a disable state appear to work fine implying its happens during the lookup of the workspace when a rule is enabled to trigger its first run or along those lines. I haven't tested the exact time period (its likely a few hours?) but definitely by a few days workspace and rules show back blank again

Author:	kaovd
Assignees:	-
Labels:	`question`, `Service Attention`, `customer-reported`, `needs-triage`, `SecurityInsights`
Milestone:	-

[navba-MSFT]

Removing CXP attention label since Service as been involved already.

@amirkeren Could you please look into this once you get a chance ?

[amirkeren]

The workspaces are indeed cached (if I'm not mistaken, for a period of 24 hours). I'll reach out to the owning team for more information after the weekend.