You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/azure-monitor/logs/move-workspace.md
+29-29Lines changed: 29 additions & 29 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -27,6 +27,35 @@ In this article, you'll learn the steps to move a Log Analytics workspace to ano
27
27
- To unlink the Automation account, you need `Microsoft.OperationalInsights/workspaces/linkedServices/delete` permissons on the linked workspace, as provided by the [Log Analytics Contributor built-in role](./manage-access.md#log-analytics-contributor), for example.
28
28
- To move a Log Analytics workspace, you need `Microsoft.OperationalInsights/workspaces/delete` and `Microsoft.OperationalInsights/workspaces/write` permissions on it, as provided by the [Log Analytics Contributor built-in role](./manage-access.md#log-analytics-contributor), for example.
29
29
30
+
## Workspace move considerations
31
+
32
+
Consider these points before you move a Log Analytics workspace:
33
+
34
+
- Managed solutions that are installed in the workspace will be moved in this operation.
35
+
- The move operation requires that no services can be linked to the workspace. Solutions that rely on linked services must be removed prior to the move, including an Azure Automation account. These solutions must be removed before you can unlink your Automation account. Data collection for the solutions will stop and their tables will be removed from the UI, but data will remain in the workspace per the table retention period. When you add solutions after the move, ingestion is restored and tables become visible with data. Linked services include:
36
+
- Update management
37
+
- Change tracking
38
+
- Start/Stop VMs during off-hours
39
+
- Microsoft Defender for Cloud
40
+
- Workspace keys (both primary and secondary) are regenerated with a workspace move operation. If you keep a copy of your workspace keys in Azure Key Vault, update them with the new keys generated after the workspace is moved.
41
+
- Connected [Log Analytics agents](../agents/log-analytics-agent.md) and [Azure Monitor Agent](../agents/azure-monitor-agent-overview.md) remain connected to the workspace after the move with no interruption to ingestion.
42
+
43
+
>[!IMPORTANT]
44
+
> **Microsoft Sentinel customers**
45
+
> - Currently, after Microsoft Sentinel is deployed on a workspace, moving the workspace to another resource group or subscription isn't supported.
46
+
> - If you've already moved the workspace, disable all active rules under **Analytics** and reenable them after five minutes. This solution should be effective in most cases, although it's unsupported and undertaken at your own risk.
47
+
> - It could take Azure Resource Manager a few hours to complete. Solutions might be unresponsive during the operation.
48
+
>
49
+
> **Re-create alerts:** All alerts must be re-created because the permissions are based on the workspace resource ID, which changes during a workspace move or resource name change. Alerts in workspaces created after June 1, 2019, or in workspaces that were [upgraded from the legacy Log Analytics Alert API to the scheduledQueryRules API](../alerts/alerts-log-api-switch.md) can be exported in templates and deployed after the move. You can [check if the scheduledQueryRules API is used for alerts in your workspace](../alerts/alerts-log-api-switch.md#check-switching-status-of-workspace). Alternatively, you can configure alerts manually in the target workspace.
50
+
>
51
+
> **Update resource paths:** After a workspace move, any Azure or external resources that point to the workspace must be reviewed and updated to point to the new resource target path.
The workspace source and destination subscriptions must exist within the same Azure Active Directory tenant. Use Azure PowerShell to verify that both subscriptions have the same tenant ID.
32
61
@@ -62,35 +91,6 @@ Run the [Get-AzSubscription](/powershell/module/az.accounts/get-azsubscription/)
62
91
63
92
---
64
93
65
-
## Workspace move considerations
66
-
67
-
Consider these points before you move a Log Analytics workspace:
68
-
69
-
- Managed solutions that are installed in the workspace will be moved in this operation.
70
-
- The move operation requires that no services can be linked to the workspace. Solutions that rely on linked services must be removed prior to the move, including an Azure Automation account. These solutions must be removed before you can unlink your Automation account. Data collection for the solutions will stop and their tables will be removed from the UI, but data will remain in the workspace per the table retention period. When you add solutions after the move, ingestion is restored and tables become visible with data. Linked services include:
71
-
- Update management
72
-
- Change tracking
73
-
- Start/Stop VMs during off-hours
74
-
- Microsoft Defender for Cloud
75
-
- Workspace keys (both primary and secondary) are regenerated with a workspace move operation. If you keep a copy of your workspace keys in Azure Key Vault, update them with the new keys generated after the workspace is moved.
76
-
- Connected [Log Analytics agents](../agents/log-analytics-agent.md) and [Azure Monitor Agent](../agents/azure-monitor-agent-overview.md) remain connected to the workspace after the move with no interruption to ingestion.
77
-
78
-
>[!IMPORTANT]
79
-
> **Microsoft Sentinel customers**
80
-
> - Currently, after Microsoft Sentinel is deployed on a workspace, moving the workspace to another resource group or subscription isn't supported.
81
-
> - If you've already moved the workspace, disable all active rules under **Analytics** and reenable them after five minutes. This solution should be effective in most cases, although it's unsupported and undertaken at your own risk.
82
-
> - It could take Azure Resource Manager a few hours to complete. Solutions might be unresponsive during the operation.
83
-
>
84
-
> **Re-create alerts:** All alerts must be re-created because the permissions are based on the workspace resource ID, which changes during a workspace move or resource name change. Alerts in workspaces created after June 1, 2019, or in workspaces that were [upgraded from the legacy Log Analytics Alert API to the scheduledQueryRules API](../alerts/alerts-log-api-switch.md) can be exported in templates and deployed after the move. You can [check if the scheduledQueryRules API is used for alerts in your workspace](../alerts/alerts-log-api-switch.md#check-switching-status-of-workspace). Alternatively, you can configure alerts manually in the target workspace.
85
-
>
86
-
> **Update resource paths:** After a workspace move, any Azure or external resources that point to the workspace must be reviewed and updated to point to the new resource target path.
0 commit comments