7.3 Creating and Configuring a Sentinel Workspace

Creating and Configuring a Sentinel Workspace

Introduction

Subsection 7.2 covered the architectural decisions. This subsection executes those decisions: creating the Log Analytics workspace, enabling Sentinel, configuring initial settings, and validating the deployment. The entire process takes 10-15 minutes — one of cloud-native SIEM’s advantages over traditional platforms that require weeks of deployment.

Step-by-step workspace creation

Step 1: Create the Log Analytics workspace.

Navigate to the Azure portal → Create a resource → search “Log Analytics workspace” → Create.

Configure the following settings:

Subscription: select the Azure subscription that will be charged for data ingestion. For lab environments, use your free trial or PAYG subscription. For production, use the subscription designated for security operations (which may be separate from workload subscriptions for cost management clarity).

Resource group: create a new resource group or select an existing one. Use the naming convention from subsection 7.2: rg-sentinel-prod-uksouth. A dedicated resource group for Sentinel makes RBAC and cost management easier — all Sentinel resources are in one place.

Name: the workspace name must be globally unique in Azure. Use the naming convention: sentinel-northgateeng-prod-uksouth. The name cannot be changed after creation.

Region: select the Azure region that matches your data residency requirement. For UK organisations, UK South is the standard choice. For EU, West Europe or North Europe. The region cannot be changed after creation — choose carefully.

Click Review + create → Create. The workspace deploys in 30-60 seconds.

Step 2: Enable Microsoft Sentinel.

Navigate to the newly created workspace → Overview → click “Microsoft Sentinel” in the left navigation (or search for “Microsoft Sentinel” in the portal and select the workspace). Click “Add Microsoft Sentinel” → confirm. Sentinel is now enabled on the workspace.

Alternatively, navigate directly to Microsoft Sentinel → Create → select the workspace → Add. Both paths achieve the same result.

Step 3: Configure initial settings.

After Sentinel is enabled, configure the workspace settings that affect cost and retention:

Navigate to the workspace (not Sentinel — the settings are at the workspace level) → Settings → or → Log Analytics workspace → Usage and estimated costs.

Pricing tiers: pay-as-you-go vs commitment tiers

Sentinel offers two pricing models for data ingestion.

Pay-as-you-go charges per GB ingested per day. This is the default and the correct choice for lab environments and small deployments (under 100 GB/day). The per-GB price is higher than commitment tiers, but there is no minimum commitment — you pay only for what you use.

Commitment tiers provide a discounted per-GB price in exchange for a daily volume commitment. Available at 100, 200, 300, 400, 500, 1000, 2000, and 5000 GB/day tiers. If your daily ingestion consistently exceeds 100 GB, a commitment tier reduces your per-GB cost by 30-50%. If your ingestion falls below the commitment level on any day, you still pay the commitment price — so the tier should be set based on your minimum consistent daily volume, not your peak volume.

Sentinel-specific pricing benefits:

The first 90 days of data retention are free for all tables (included in the Sentinel per-GB price). Retention beyond 90 days incurs additional per-GB/month charges. This means most security investigation needs (data from the last 90 days) are covered at no additional retention cost.

The 5 GB/day free ingestion applies to the first workspace in each subscription. This is enough for a lab environment with basic connectors (Entra ID sign-in logs + M365 Defender alerts).

Microsoft 365 E5, A5, F5, and G5 customers receive a Sentinel data ingestion benefit: qualifying M365 data (from Defender XDR, Entra ID, Office activity) is ingested at no additional charge up to a per-user allowance. This benefit significantly reduces cost for M365-heavy organisations — check whether your licences qualify.

The free tier: what you get for 5 GB/day

The free 5 GB/day allowance is enough for a meaningful lab setup:

Entra ID sign-in logs: ~0.5-1 GB/day for a tenant with 25 lab users. M365 Defender alerts: ~0.1-0.5 GB/day for a quiet lab environment. Azure Activity logs: ~0.05-0.1 GB/day for a small Azure subscription. Total: ~1-2 GB/day — well within the free tier.

This leaves 3 GB/day of headroom for third-party data (Syslog from a virtual firewall, CEF from a test appliance) without incurring charges. The free tier is sufficient for all exercises in Modules 7-10.

Enabling diagnostic settings and health monitoring

After workspace creation, enable two diagnostic capabilities that are essential for operational management.

Workspace diagnostic settings: Navigate to the Log Analytics workspace → Diagnostic settings → Add diagnostic setting. Enable all log categories (Audit, SentinelAudit, SentinelHealth) and send them to the workspace itself (self-monitoring). This creates the audit trail for workspace operations: who modified an analytics rule, when a data connector was configured, and whether any health issues were detected.

Sentinel health monitoring: Navigate to Sentinel → Settings → Health monitoring (preview). Enable health monitoring for data connectors, analytics rules, and automation rules. Health events are written to the SentinelHealth table, which you can query with KQL to detect connector failures, rule execution errors, and automation problems. Subsection 7.11 covers health monitoring in depth.

1
2
3
4
5
6

// Verify the workspace is receiving data
union withsource=TableName *
| where TimeGenerated > ago(1h)
| summarize EventCount = count(), LastEvent = max(TimeGenerated) by TableName
| order by EventCount desc
| take 20

Post-deployment configuration checklist

After creating the workspace and enabling Sentinel, complete this checklist before proceeding to data connector configuration (Module 8).

Verify workspace settings: Correct region, pricing tier set to Pay-as-you-go (or appropriate commitment tier for production), retention set to 90 days (minimum), daily cap set (lab only — disabled in production).

Verify Sentinel enablement: Navigate to Microsoft Sentinel → confirm the workspace appears in the workspace list with “Active” status.

Verify diagnostic settings: All log categories enabled, sending to the workspace itself.

Verify health monitoring: Enabled for data connectors, analytics rules, and automation rules.

Verify free tier availability: Navigate to Usage and estimated costs → check the daily ingestion graph. If ingestion is below 5 GB/day, the free allowance applies.

Document the workspace: Record the workspace name, resource group, region, subscription, and workspace ID (found in Properties) in your operations runbook. The workspace ID is needed for API calls, playbook configuration, and cross-workspace queries.

Deploying via ARM template or Bicep

For production deployments and repeatable infrastructure-as-code, deploy the workspace using an ARM template or Bicep rather than the portal UI.

Advantages of template deployment: Repeatable (deploy identical workspaces across environments or for different customers), version-controlled (templates stored in Git alongside analytics rules), reviewable (infrastructure changes go through the same pull request process as detection rules), and faster for multi-workspace deployments (MSSPs deploying 25 customer workspaces benefit enormously from template automation).

Bicep example — workspace + Sentinel in one deployment:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

// This is Bicep, not KQL — shown for reference
// resource workspace 'Microsoft.OperationalInsights/workspaces@2022-10-01' = {
//   name: 'sentinel-northgateeng-prod-uksouth'
//   location: 'uksouth'
//   properties: {
//     sku: { name: 'PerGB2018' }
//     retentionInDays: 90
//   }
// }
// resource sentinel 'Microsoft.SecurityInsights/onboardingStates@2023-02-01' = {
//   name: 'default'
//   scope: workspace
// }

The template creates the workspace and enables Sentinel in a single deployment. Add diagnostic settings, health monitoring, and initial data connectors to the same template for a complete deployment. Store the template in your infrastructure Git repository and deploy through CI/CD.

Common deployment errors and troubleshooting

Error: “Resource provider Microsoft.SecurityInsights not registered.” Sentinel requires the SecurityInsights resource provider to be registered on the Azure subscription. Navigate to the subscription → Resource providers → search “Microsoft.SecurityInsights” → Register. This is a one-time step per subscription.

Error: “Workspace name already exists.” Log Analytics workspace names are globally unique. Choose a different name — the naming convention in subsection 7.2 helps avoid collisions by including the organisation name and region.

Error: “Insufficient permissions.” Creating a workspace requires Contributor access on the resource group. Enabling Sentinel requires the Sentinel Contributor role (or Owner/Contributor at the workspace level). If you receive permission errors, check your role assignment in IAM.

Issue: “Sentinel enabled but no data flowing.” Sentinel enablement does not automatically connect data sources. Data connectors must be configured separately (Module 8). After enabling Sentinel, the workspace has the Sentinel features (analytics rules, incidents, automation) but no data until connectors are configured.

Issue: “Wrong region selected.” The workspace region cannot be changed after creation. If you created the workspace in the wrong region, you must create a new workspace in the correct region and delete the old one. There is no migration path for workspace regions. Double-check the region before clicking Create.

Workspace configuration verification queries

After deployment, run these queries to verify the workspace is correctly configured and operational.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

// Query 1: Verify workspace properties
// Run in Azure Resource Graph Explorer, not Log Analytics
// resources
// | where type == "microsoft.operationalinsights/workspaces"
// | project name, location, properties.retentionInDays,
//     properties.sku.name

// Query 2: Verify Sentinel is enabled (run in the workspace Logs blade)
SentinelHealth
| take 1
// If this returns results, health monitoring is active
// If it errors with "table not found," enable health monitoring

// Query 3: Verify data ingestion is occurring
Usage
| where TimeGenerated > ago(1h)
| where IsBillable == true
| summarize TotalMB = sum(Quantity) by bin(TimeGenerated, 10m)
| order by TimeGenerated desc
| take 6

If Query 2 fails, navigate to Sentinel → Settings → Health monitoring and enable it. If Query 3 returns zero rows, no billable data has been ingested in the last hour — either no connectors are configured (expected for a fresh workspace) or a connector has failed (unexpected for an established workspace).

Knowledge check