Workspace reconfiguration via ARM or Powershell?

[nathanmitten]

I have 150ish subscriptions that are already configured with workspaces. I need to create a new workspace and have all the VMs get reconfigured. 

I've tested that this will work given time via manually changing the workspace and saying yes to the reconfigure popup in the portal.

I've tested with ARM templates and with powershell but it does not appear that the reconfiguration happens. 

Is this expected behavior, or will I need to look at running commands on all the VMs with the workspace id?

[#2]

Hi @nathanmitten,

Thanks for reaching out. If your subscriptions are currently using Security Center's managed workspaces (default workspaces) and you'd like to change them to report to a workspace of your own, you can reconfigure your existing VMs to report to this new workspace programmatically by using REST API:

HTTP Method: POST

URI:  https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Security/workspaceSe...

Request Body:

/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.OperationalInsights/workspaces/{workspaceName}

Reconfiguration of the agents may take up to 12 hours.

Alternatively you can see the same in the ASC Portal experience: Pricing & Settings -> Select subscription -> Data collection -> switch from default workspaces to a workspace of your own. You'll then see the following confirmation dialog (Of course this method is applicable only in case you want to alter a few subscriptions and not dozens)

We plan to add this to our API documentation in the near future as this specific functionality is missing from it, along with adding this to our PowerShell snippet.

If your VMs currently report to your own workspace (whether the Microsoft Monitoring agent was provisioned manually on your VMs or with ASC's automatic provisioning), you'll have to reconfigure the Microsoft Monitoring agent to the new workspace manually. ASC can't do this automatically for you since it did not necessarily provision the agent and the actual reporting to the (user) workspace may have served needs besides ASC - thus this can't be done automatically.

Reconfiguration in this case can be done in multiple ways, but this depend on how the Microsoft Monitoring Agent was installed (as an Azure Extension or as a Direct Agent installation) and on the OS. Please consult the relevant docs in such a case to find your appropriate scenario: https://docs.microsoft.com/en-us/azure/azure-monitor/platform/log-analytics-agent

Please reach out if you have any further questions or required clarifications.

Thanks,

Yoav Francis,

Senior Product Manager, Azure Security Center 

[#3]

Hi @yoavfrancis thanks for the reply.

I think I may just need some clarification.

Is the POST doing anything different than the following would?

Set-AzSecurityWorkspaceSetting -Name "default" -Scope "/subscriptions/$subscriptionid" -WorkspaceId "/subscriptions/$subscriptionid/resourcegroups/$rg_name/providers/microsoft.operationalinsights/workspaces/$workspace_name"

If not, then are you saying if the workspace is still default (aka was never changed) it will reconfigure the VMs, but if it was changed to a custom workspace, running the above powershell or API will not reconfigure the VMs?

Thanks,

Nathan

[#4]

@nathanmitten Apologies for the delay.

Set-AzSecurityWorkspaceSetting controls in which workspace to save the data, in case auto provisioning was enabled (with Set-AzSecurityAutoProvisioningStatus). In case you're using auto provisioning with managed workspaces ('default' workspaces), no need to call Set-AzSecurityWorkspaceSetting at all.

Neither of the above PowerShell cmdlets take care of reconnecting the VMs in case you move from auto provisioning on default workspace to auto provisioning on a central workspace. In order to reconnect the VMs you'll need to explicitly make a POST call to the URI I mentioned in my last post:

https://management.azure.com/subscriptions/SUBSCRIPTION_ID/providers/Microsoft.Security/workspaceSet... 

Thanks,

Yoav