How to Set Up Azure Sentinel Integration with Windows Server 2025
Microsoft Sentinel is a cloud-native Security Information and Event Management (SIEM) and Security Orchestration, Automation, and Response (SOAR) platform built on Azure. When connected to your Windows Server 2025 estate, Sentinel ingests Windows Security events, system logs, and Microsoft Defender telemetry into a scalable Log Analytics workspace where you can write KQL threat-hunting queries, build real-time alert rules, and trigger automated response playbooks. In this tutorial you will create a Sentinel workspace, connect Windows Server 2025 hosts using the Azure Monitor Agent and Data Collection Rules, enable the built-in data connectors, write KQL queries to hunt for common Windows threats, and set up an alert rule with an automated Logic Apps playbook.
Prerequisites
- An Azure subscription with Contributor access on the target resource group
- Windows Server 2025 with outbound HTTPS access to Azure endpoints (
*.ods.opinsights.azure.com,*.oms.opinsights.azure.com) - Azure CLI installed on your workstation (
az --version) or access to Azure Cloud Shell - PowerShell 7 with the
Azmodule:Install-Module Az -AllowClobber -Scope CurrentUser - The
Microsoft.OperationsManagementandMicrosoft.SecurityInsightsresource providers registered on your subscription
# Register required resource providers
az provider register --namespace Microsoft.OperationsManagement
az provider register --namespace Microsoft.SecurityInsights
az provider register --namespace Microsoft.Insights
# Confirm registration status
az provider show --namespace Microsoft.SecurityInsights --query registrationState -o tsv
Step 1: Create a Log Analytics Workspace and Enable Sentinel
Sentinel is an add-on to a Log Analytics workspace. Create a dedicated workspace for security data — do not share it with operational monitoring workspaces to avoid mixing retention policies and controlling costs:
$resourceGroup = 'rg-sentinel-prod'
$location = 'eastus'
$workspaceName = 'law-sentinel-prod'
$sentinelName = 'sentinel-prod'
# Create resource group
az group create --name $resourceGroup --location $location
# Create Log Analytics workspace (PerGB2018 = pay-per-GB pricing)
az monitor log-analytics workspace create `
--resource-group $resourceGroup `
--workspace-name $workspaceName `
--location $location `
--sku PerGB2018 `
--retention-time 90
# Retrieve workspace ID for later use
$workspaceId = az monitor log-analytics workspace show `
--resource-group $resourceGroup `
--workspace-name $workspaceName `
--query customerId -o tsv
# Enable Microsoft Sentinel on the workspace
az sentinel workspace create `
--resource-group $resourceGroup `
--workspace-name $workspaceName
Write-Host "Workspace ID: $workspaceId"
Step 2: Install the Azure Monitor Agent on Windows Server 2025
The Azure Monitor Agent (AMA) replaces the legacy Microsoft Monitoring Agent (MMA/OMS agent) and is the recommended collector for Windows Server 2025. AMA uses Data Collection Rules (DCRs) to define exactly what data to collect — giving you granular control over cost and coverage:
# Install AMA via PowerShell on the target Windows Server 2025 machine
# (Run this on the server itself or via Invoke-Command)
$serverName = 'WS2025-PROD-01'
Invoke-Command -ComputerName $serverName -ScriptBlock {
# Download and install AMA MSI
$amaUrl = 'https://go.microsoft.com/fwlink/?linkid=2202225' # AMA for Windows
$tmpPath = 'C:TempAzureMonitorAgent.msi'
New-Item -ItemType Directory -Path C:Temp -Force | Out-Null
Invoke-WebRequest -Uri $amaUrl -OutFile $tmpPath -UseBasicParsing
Start-Process msiexec.exe -ArgumentList "/i $tmpPath /quiet /log C:TempAMA_install.log" `
-Wait -NoNewWindow
# Verify service is running
Get-Service -Name 'AzureMonitorAgent' | Select-Object Name, Status, StartType
}
In Azure, you can also deploy AMA at scale using Azure Policy or via the Azure portal (Virtual Machines > Extensions). For Arc-enabled on-premises servers:
# If server is onboarded to Azure Arc, install AMA as a VM extension
$serverArcId = "/subscriptions/{sub-id}/resourceGroups/$resourceGroup/providers/Microsoft.HybridCompute/machines/$serverName"
az connectedmachine extension create `
--resource-group $resourceGroup `
--machine-name $serverName `
--name AzureMonitorWindowsAgent `
--type AzureMonitorWindowsAgent `
--publisher Microsoft.Azure.Monitor `
--settings '{}' `
--enable-auto-upgrade true
Step 3: Create a Data Collection Rule for Windows Security Events
A Data Collection Rule defines which event channels and event IDs to forward from each server to the Log Analytics workspace. Create one DCR targeting the Security, System, and Application channels with a filtered XPath query to control ingestion volume:
# Create DCR via Azure REST API (az rest) or ARM template
# The following uses a JSON body for the DCR definition
$workspaceResourceId = "/subscriptions/{sub-id}/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspaceName"
$dcrBody = @{
location = $location
properties = @{
description = 'Windows Server 2025 Security Event Collection'
dataSources = @{
windowsEventLogs = @(
@{
name = 'SecurityChannel'
streams = @('Microsoft-SecurityEvent')
xPathQueries = @(
'Security!*[System[(EventID=4624 or EventID=4625 or EventID=4648 or EventID=4688)]]',
'Security!*[System[(EventID=4698 or EventID=4720 or EventID=4722 or EventID=4768 or EventID=4776)]]'
)
},
@{
name = 'SystemChannel'
streams = @('Microsoft-Event')
xPathQueries = @('System!*[System[(Level=1 or Level=2 or Level=3)]]')
}
)
}
destinations = @{
logAnalytics = @(
@{
workspaceResourceId = $workspaceResourceId
name = 'SentinelWorkspace'
}
)
}
dataFlows = @(
@{
streams = @('Microsoft-SecurityEvent')
destinations = @('SentinelWorkspace')
},
@{
streams = @('Microsoft-Event')
destinations = @('SentinelWorkspace')
}
)
}
} | ConvertTo-Json -Depth 10
$dcrBody | Out-File 'C:Tempdcr-windows-security.json' -Encoding UTF8
az rest --method PUT `
--url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/$resourceGroup/providers/Microsoft.Insights/dataCollectionRules/dcr-windows-security?api-version=2022-06-01" `
--body '@C:Tempdcr-windows-security.json' `
--headers 'Content-Type=application/json'
Step 4: Enable Microsoft Sentinel Data Connectors
Sentinel data connectors are pre-built integrations that surface in the Sentinel portal. Enable the Windows Security Events connector (which uses AMA and DCRs under the hood) and the Microsoft Defender for Endpoint connector for richer telemetry:
# Enable Sentinel data connectors via PowerShell Az module
Connect-AzAccount
Select-AzSubscription -SubscriptionId '{sub-id}'
# Get the Sentinel workspace object
$workspace = Get-AzOperationalInsightsWorkspace `
-ResourceGroupName $resourceGroup -Name $workspaceName
# Enable Windows Security Events via AMA connector
# (This is done through the Sentinel portal or REST API)
$connectorBody = @{
kind = 'WindowsSecurityEvents'
properties = @{
dataTypes = @{
securityEvents = @{ state = 'Enabled' }
}
}
} | ConvertTo-Json -Depth 5
az rest --method PUT `
--url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspaceName/providers/Microsoft.SecurityInsights/dataConnectors/WindowsSecurityEvents?api-version=2023-02-01" `
--body $connectorBody `
--headers 'Content-Type=application/json'
Step 5: Write KQL Threat-Hunting Queries
Kusto Query Language (KQL) is the query syntax used by Sentinel. These queries run against the SecurityEvent table populated by your Windows Server 2025 hosts:
// Hunt 1: Failed logon spike — potential brute force
// Run in Sentinel > Logs
SecurityEvent
| where TimeGenerated > ago(1h)
| where EventID == 4625
| summarize FailureCount = count() by IpAddress, Account, Computer
| where FailureCount >= 10
| order by FailureCount desc
// Hunt 2: Successful logon after 5+ failures (confirmed brute force)
let failures = SecurityEvent
| where TimeGenerated > ago(2h)
| where EventID == 4625
| summarize FailCount = count() by IpAddress
| where FailCount >= 5;
SecurityEvent
| where TimeGenerated > ago(2h)
| where EventID == 4624
| join kind=inner failures on IpAddress
| project TimeGenerated, Computer, Account, IpAddress, LogonType, FailCount
| order by TimeGenerated desc
// Hunt 3: Lateral movement — network logons (type 3) from unusual sources
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4624 and LogonType == 3
| where AccountType == "User"
| summarize LogonCount = count(), Computers = make_set(Computer) by Account, IpAddress
| where array_length(Computers) > 2 // Same account logging on to 3+ machines
| order by LogonCount desc
// Hunt 4: New scheduled task creation
SecurityEvent
| where TimeGenerated > ago(24h)
| where EventID == 4698
| extend TaskName = extract(@'TaskName.*?(.*?)', 1, EventData)
| project TimeGenerated, Computer, Account, TaskName, EventData
| order by TimeGenerated desc
Step 6: Create an Alert Rule
Sentinel Scheduled Query Rules run KQL on a timer and create incidents when results exceed a threshold. Create a brute-force detection rule via the REST API:
$alertRuleBody = @{
kind = 'Scheduled'
properties = @{
displayName = 'WS2025 — Brute Force Detected (10+ failures + success)'
description = 'Detects a successful logon after 10 or more failures from the same IP in 1 hour'
severity = 'High'
enabled = $true
queryFrequency = 'PT1H'
queryPeriod = 'PT2H'
triggerOperator = 'GreaterThan'
triggerThreshold = 0
suppressionEnabled = $false
suppressionDuration = 'PT5H'
tactics = @('CredentialAccess', 'LateralMovement')
query = @"
let failures = SecurityEvent
| where TimeGenerated > ago(2h)
| where EventID == 4625
| summarize FailCount = count() by IpAddress
| where FailCount >= 10;
SecurityEvent
| where TimeGenerated > ago(2h)
| where EventID == 4624
| join kind=inner failures on IpAddress
| project TimeGenerated, Computer, Account, IpAddress, LogonType, FailCount
"@
}
} | ConvertTo-Json -Depth 10
az rest --method PUT `
--url "https://management.azure.com/subscriptions/{sub-id}/resourceGroups/$resourceGroup/providers/Microsoft.OperationalInsights/workspaces/$workspaceName/providers/Microsoft.SecurityInsights/alertRules/brute-force-ws2025?api-version=2023-02-01" `
--body $alertRuleBody `
--headers 'Content-Type=application/json'
Microsoft Sentinel transforms raw Windows event logs into a living threat detection platform. With AMA and Data Collection Rules providing efficient, filtered ingestion, and KQL enabling sophisticated multi-step correlation that would require dozens of PowerShell scripts to replicate locally, the investment in the Azure integration pays for itself the first time it surfaces an incident before your team would otherwise have noticed. Start with the brute-force and lateral movement queries, add the Sentinel UEBA (User and Entity Behavior Analytics) feature once you have 30 days of baseline data, and build playbooks that automatically isolate compromised hosts via Microsoft Defender for Endpoint to close the loop from detection to response in minutes.
