What Is Microsoft Sentinel

Microsoft Sentinel (formerly Azure Sentinel until 2021) is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform built on Azure. Unlike traditional on-premises SIEM systems that require dedicated hardware, licensing per managed device, and significant operational overhead, Sentinel is a fully managed SaaS platform that scales elastically with your data volume and charges based on data ingestion rather than per-device or per-user licensing.

For Windows Server 2022 environments, Sentinel provides centralized security event collection, machine learning-based threat detection, built-in threat intelligence integration (Microsoft Threat Intelligence, MITRE ATT&CK mappings), interactive workbooks for visualization, and SOAR playbooks that can automatically respond to detected threats. Integration with Windows Server 2022 is native, with Microsoft-provided data connectors specifically designed for Windows Security Events.

Sentinel is deployed as a Log Analytics workspace in Azure. All collected data is stored in Azure Monitor’s Log Analytics, queryable using Kusto Query Language (KQL). Before proceeding with this guide, you need an active Azure subscription and contributor-level access to a resource group where you will create the Log Analytics workspace and enable the Sentinel solution.

Creating the Log Analytics Workspace and Enabling Sentinel

Sentinel is layered on top of an Azure Log Analytics workspace. Begin by creating the workspace, then enable the Sentinel solution on it.

# Create a Log Analytics workspace using Azure PowerShell
# Install the Az module if not present
Install-Module -Name Az -AllowClobber -Force
Connect-AzAccount

$ResourceGroupName = "rg-security-sentinel"
$WorkspaceName     = "law-sentinel-prod"
$Location          = "eastus"

# Create resource group
New-AzResourceGroup -Name $ResourceGroupName -Location $Location

# Create Log Analytics workspace
New-AzOperationalInsightsWorkspace `
    -ResourceGroupName $ResourceGroupName `
    -Name $WorkspaceName `
    -Location $Location `
    -Sku "PerGB2018"  # Pay-as-you-go pricing tier

# Enable Microsoft Sentinel on the workspace
Install-Module -Name Az.SecurityInsights -Force
New-AzSentinel -ResourceGroupName $ResourceGroupName -WorkspaceName $WorkspaceName

Alternatively, create the workspace and enable Sentinel through the Azure Portal: navigate to Microsoft Sentinel in the portal, click Add, create a new Log Analytics workspace, select the workspace, and click Add Microsoft Sentinel. The process takes 1-2 minutes.

After Sentinel is enabled, retrieve the workspace ID and primary key — these are required to configure agents on your Windows Server 2022 systems:

# Get workspace ID and key for agent configuration
$Workspace = Get-AzOperationalInsightsWorkspace `
    -ResourceGroupName $ResourceGroupName `
    -Name $WorkspaceName

$WorkspaceId  = $Workspace.CustomerId
$WorkspaceKey = (Get-AzOperationalInsightsWorkspaceSharedKey `
    -ResourceGroupName $ResourceGroupName `
    -Name $WorkspaceName).PrimarySharedAccessSignature

Write-Host "Workspace ID:  $WorkspaceId"
Write-Host "Workspace Key: $WorkspaceKey"

Connecting Windows Server 2022 — Log Analytics Agent vs Azure Monitor Agent

Microsoft provides two agents for connecting Windows servers to Log Analytics / Sentinel: the Legacy Log Analytics Agent (also called the Microsoft Monitoring Agent, MMA) and the newer Azure Monitor Agent (AMA). As of 2024, Microsoft has deprecated the MMA in favor of AMA, which provides better performance, more granular data collection configuration via Data Collection Rules (DCRs), and improved security using Managed Identity rather than workspace keys.

For new deployments on Windows Server 2022, use the Azure Monitor Agent. For existing environments using MMA, begin planning migration to AMA.

Installing the Azure Monitor Agent on Windows Server 2022:

If your servers are Azure VMs, the AMA can be installed as a VM extension via the Azure Portal or PowerShell. For on-premises or other-cloud servers, use Azure Arc to onboard the server to Azure first, then install AMA as an Arc extension.

# For Azure VMs - install AMA via VM extension
$VMName            = "MyWindowsServer2022"
$VMResourceGroup   = "rg-servers"

Set-AzVMExtension `
    -ResourceGroupName $VMResourceGroup `
    -VMName $VMName `
    -Name "AzureMonitorWindowsAgent" `
    -Publisher "Microsoft.Azure.Monitor" `
    -ExtensionType "AzureMonitorWindowsAgent" `
    -TypeHandlerVersion "1.0" `
    -Location $Location `
    -EnableAutomaticUpgrade $true

For on-premises Windows Server 2022, first onboard to Azure Arc, then install the agent:

# On the Windows Server 2022 host - Azure Arc onboarding
# Download and run the Arc onboarding script from Azure Portal
# (Azure Arc > Servers > Add > Generate script)

# After Arc onboarding, install AMA via Arc extension
$MachineName = "myserver2022"
$ArcResourceGroup = "rg-arc-servers"

New-AzConnectedMachineExtension `
    -ResourceGroupName $ArcResourceGroup `
    -MachineName $MachineName `
    -Name "AzureMonitorWindowsAgent" `
    -Location $Location `
    -Publisher "Microsoft.Azure.Monitor" `
    -ExtensionType "AzureMonitorWindowsAgent" `
    -TypeHandlerVersion "1.0" `
    -EnableAutomaticUpgrade

Enabling the Windows Security Events Data Connector

After installing the agent, configure which events to collect by enabling the Windows Security Events via AMA data connector in Sentinel and creating a Data Collection Rule (DCR).

In the Azure Portal, navigate to Microsoft Sentinel → Data connectors, search for “Windows Security Events via AMA,” and click Open connector page. Under Configuration, click Create data collection rule. Provide a name, select your subscription and resource group, add your Windows Server 2022 machines as resources, and choose the event collection level:

All Events: Collects every security event from the Windows Security event log. This generates the highest data volume and cost but provides complete forensic coverage. Appropriate for highly sensitive servers like domain controllers and certificate authorities.

Common: A curated subset of events recommended by Microsoft for security monitoring. Includes the most security-relevant event IDs (logon events, account management, process creation, service installation, etc.) while excluding high-volume, low-value events. Appropriate for most production servers and significantly reduces ingestion cost.

Minimal: Only the most critical event IDs. Use only when cost is the primary concern and comprehensive monitoring is not feasible.

# Create a Data Collection Rule via PowerShell for Windows Security Events
# This collects the "Common" event set

$DCRName = "dcr-windows-security-events"

$DCRBody = @{
    location   = $Location
    properties = @{
        dataSources = @{
            windowsEventLogs = @(
                @{
                    name    = "eventLogsDataSource"
                    streams = @("Microsoft-SecurityEvent")
                    xPathQueries = @(
                        "Security!*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4656 or EventID=4688 or EventID=4697 or EventID=4698 or EventID=4700 or EventID=4701 or EventID=4719 or EventID=4720 or EventID=4728 or EventID=4732 or EventID=4740 or EventID=4756 or EventID=4768 or EventID=4769 or EventID=4776 or EventID=4798 or EventID=4799)]]"
                    )
                }
            )
        }
        destinations = @{
            logAnalytics = @(
                @{
                    workspaceResourceId = "/subscriptions/$((Get-AzContext).Subscription.Id)/resourceGroups/$ResourceGroupName/providers/Microsoft.OperationalInsights/workspaces/$WorkspaceName"
                    name                = "sentinelWorkspace"
                }
            )
        }
        dataFlows = @(
            @{
                streams      = @("Microsoft-SecurityEvent")
                destinations = @("sentinelWorkspace")
            }
        )
    }
}

$DCRBodyJson = $DCRBody | ConvertTo-Json -Depth 10
Invoke-AzRestMethod -Method PUT `
    -Path "/subscriptions/$((Get-AzContext).Subscription.Id)/resourceGroups/$ResourceGroupName/providers/Microsoft.Insights/dataCollectionRules/$DCRName?api-version=2022-06-01" `
    -Payload $DCRBodyJson

The SecurityEvent Table and KQL Queries

Once data is flowing from Windows Server 2022 into Sentinel, all Windows security events are stored in the SecurityEvent table in the Log Analytics workspace. Query this table using KQL (Kusto Query Language) from Sentinel’s Logs blade.

// Find all failed logon attempts in the last 24 hours
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| project TimeGenerated, Computer, Account, IpAddress, LogonTypeName, SubStatus
| order by TimeGenerated desc

// Detect brute force: >10 failed logons from same IP in 10 minutes
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4625
| summarize FailureCount = count(), TargetAccounts = make_set(Account) by IpAddress, bin(TimeGenerated, 10m), Computer
| where FailureCount > 10
| order by FailureCount desc

// Find new service installations
SecurityEvent
| where TimeGenerated > ago(7d)
| where EventID == 4697
| project TimeGenerated, Computer, Account, ServiceName, ServiceFileName, ServiceStartType
| order by TimeGenerated desc

// Track user additions to privileged groups
SecurityEvent
| where TimeGenerated > ago(30d)
| where EventID in (4728, 4732, 4756)
| project TimeGenerated, Computer, Activity, MemberName, TargetUserName, SubjectUserName
| order by TimeGenerated desc

// Suspicious process creation: PowerShell spawned from unusual parent
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4688
| where NewProcessName has "powershell.exe" or NewProcessName has "cmd.exe"
| where ParentProcessName has_any ("w3wp.exe","sqlservr.exe","iexplore.exe","winword.exe","excel.exe","outlook.exe")
| project TimeGenerated, Computer, Account, NewProcessName, CommandLine, ParentProcessName
| order by TimeGenerated desc

Creating Analytics Rules

Analytics rules in Sentinel run KQL queries on a schedule and generate incidents when the query returns results. This is the mechanism for automated threat detection. Navigate to Sentinel → Analytics → Create → Scheduled query rule.

For a brute-force detection rule, configure: Name: “Brute Force Logon Attack on Windows Server,” Query: the brute-force KQL query above, Query scheduling: run every 5 minutes on data from the last 30 minutes, Alert threshold: greater than 0 results, Incident settings: group all events into a single incident per unique IP address.

# Create an analytics rule via PowerShell
New-AzSentinelAlertRule -ResourceGroupName $ResourceGroupName `
    -WorkspaceName $WorkspaceName `
    -Kind "Scheduled" `
    -DisplayName "Windows - Brute Force Logon Attempt" `
    -Description "Detects more than 10 failed logon attempts from the same IP within 10 minutes" `
    -Enabled $true `
    -Severity "Medium" `
    -Query @"
SecurityEvent
| where TimeGenerated > ago(30m)
| where EventID == 4625
| summarize FailureCount = count() by IpAddress, Computer
| where FailureCount > 10
"@ `
    -QueryFrequency (New-TimeSpan -Minutes 5) `
    -QueryPeriod (New-TimeSpan -Minutes 30) `
    -TriggerOperator "GreaterThan" `
    -TriggerThreshold 0

For Near-Real-Time (NRT) detection of the highest-priority events (such as new domain admin additions), use NRT analytics rules instead of Scheduled rules. NRT rules run continuously on the event stream with approximately 1-3 minute latency, compared to 5-30 minutes for scheduled rules.

Windows Server Monitoring Workbooks

Sentinel Workbooks are interactive dashboards built on Azure Monitor Workbooks that provide visual representations of your security data. Microsoft publishes a library of pre-built workbooks in Sentinel’s Workbooks blade. For Windows Server 2022 monitoring, deploy the following workbooks from the Sentinel Content Hub:

Windows Security Events: Provides an overview of logon activity, account management events, group membership changes, and privileged access across all connected Windows servers. Shows logon heatmaps by time-of-day, top source IPs, and authentication failure trends.

Identity and Access: Focuses on user account activity, including new account creation, password changes, group membership changes, and privileged logons. Excellent for detecting insider threat activity and unauthorized account modifications.

Install content hub solutions from Sentinel → Content Hub, search for “Windows Security Events,” and deploy the solution which includes both analytics rules and workbooks.

Sentinel SOAR Playbooks for Automated Response

Sentinel Playbooks are Azure Logic Apps workflows triggered automatically when an incident is created or an alert fires. They enable automated response actions without human intervention, dramatically reducing mean time to respond (MTTR) for common threat scenarios.

A practical example for Windows Server 2022: when a brute-force attack is detected (more than 50 failed logons from a single IP in 5 minutes), automatically block that IP at the Azure Network Security Group level and post an alert to a Microsoft Teams security channel.

# The playbook itself is an Azure Logic App - this PowerShell creates the Sentinel automation rule
# that triggers the playbook when a brute force incident is created

# Assumes the Logic App playbook "Block-BruteForce-IP" already exists in the same resource group
$PlaybookResourceId = "/subscriptions/$((Get-AzContext).Subscription.Id)/resourceGroups/$ResourceGroupName/providers/Microsoft.Logic/workflows/Block-BruteForce-IP"

New-AzSentinelAutomationRule `
    -ResourceGroupName $ResourceGroupName `
    -WorkspaceName $WorkspaceName `
    -DisplayName "Auto-block brute force IPs" `
    -Order 1 `
    -TriggeringLogic_IsEnabled $true `
    -TriggeringLogic_TriggersOn "Incidents" `
    -TriggeringLogic_TriggersWhen "Created" `
    -Action @(
        @{
            order        = 1
            actionType   = "RunPlaybook"
            logicAppResourceId = $PlaybookResourceId
        }
    )

Other useful automated response playbooks for Windows Server environments include: disabling compromised user accounts in Active Directory when credential theft is detected, enriching incidents with threat intelligence lookups (VirusTotal, CIRCL, or Microsoft Threat Intelligence), and creating ServiceNow/Jira tickets automatically when high-severity incidents are generated.

Pricing Considerations for Windows Event Ingestion

Understanding Sentinel pricing is critical for budget planning. Sentinel charges based on data ingested into the Log Analytics workspace, measured in GB per day. Windows Security events can generate significant data volume depending on the number of servers and the event collection level chosen.

As a rough benchmark: a busy Windows Server 2022 domain controller generating thousands of authentication events per hour may produce 1-5 GB of security events per day with the “All Events” collection level, and 200-500 MB per day with the “Common” level. A lightly loaded member server may generate 50-200 MB per day on “Common.” Multiply by the number of servers to estimate monthly ingestion volume.

Use Sentinel’s built-in data ingestion workbook to monitor actual data volumes after initial deployment. Adjust the collection level or add XPath query filters to the Data Collection Rule to exclude high-volume, low-value events that are driving cost without contributing to security detection.

// KQL query to analyze data ingestion volume by source and table
Usage
| where TimeGenerated > ago(30d)
| where DataType == "SecurityEvent"
| summarize GB_Ingested = sum(Quantity) / 1024 by Computer, bin(TimeGenerated, 1d)
| order by GB_Ingested desc

For cost optimization at scale, consider using the Sentinel Data Collection Rules to ingest only the specific event IDs you have analytics rules for, using the Azure Monitor Basic Logs tier for high-volume, low-query-frequency data, and taking advantage of Sentinel commitment tiers (100 GB/day, 200 GB/day, etc.) which offer significant discounts over per-GB pricing for predictable high-volume environments. Always model your expected data volume before deployment to avoid budget surprises in the first month of production operation.

Links

Newsletter

Contact

How to Set Up Windows Server 2022 Group Policy Modelling