When Your Servers Are Invisible, Your Risks Are Not

A mid-sized logistics company running 40 on-premises Windows Servers had no idea three of them hadn’t received security patches in eight months. They only found out after a ransomware incident that started on one of those unmonitored machines. The culprit wasn’t a zero-day exploit — it was a blind spot.

If you’re managing on-premises infrastructure without centralized telemetry, you’re flying blind. Azure Arc integration is Microsoft’s answer to this problem — a powerful bridge that brings your local Windows Servers under the same monitoring, policy enforcement, and security umbrella as your cloud resources.

This guide walks you through what Azure Arc actually does, how to connect your on-premises servers, and how to use centralized telemetry to harden your security posture starting today.

What Is Azure Arc Integration and Why Does It Matter?

Azure Arc is a set of Microsoft technologies that extends Azure’s management plane beyond the cloud. In plain terms, it lets you manage on-premises Windows and Linux servers as if they were native Azure resources — without migrating a single workload.

Once a server is Arc-enabled, it appears in the Azure portal alongside your cloud VMs. You can apply Azure Policy, collect telemetry through Azure Monitor, run Defender for Servers, and enforce compliance — all from one place.

The Core Problem Azure Arc Solves

Most small and mid-sized businesses have a hybrid reality: some workloads in Azure or Microsoft 365, others still running on-premises on aging Windows Server infrastructure. Without Arc, those two worlds don’t talk. IT teams end up juggling multiple tools — Windows Admin Center here, a third-party monitoring agent there, manual patch checks somewhere else.

That fragmentation creates security gaps. Centralized telemetry closes them by giving you a single source of truth for health, performance, and security signals across every server, regardless of where it lives.

Prerequisites Before You Deploy Azure Arc on Windows Servers

Before connecting your first server, confirm the following are in place:

• Supported OS: Windows Server 2012 R2 and later (note: extended security updates for 2012/2012 R2 via Arc require a specific license agreement)
• Outbound internet access: The server needs HTTPS (port 443) access to Azure endpoints, or you can route through an Azure Arc proxy
• Azure subscription: With at least Contributor rights on the resource group where servers will be registered
• Service principal or device login: For scripted deployments across multiple machines
• PowerShell 5.1 or later: Required to run the onboarding script

Also make sure your firewall allows outbound connections to *.his.arc.azure.com, *.guestconfiguration.azure.com, and management.azure.com. These are the endpoints the Azure Connected Machine agent uses to phone home.

Step-by-Step: Connecting On-Premises Windows Servers to Azure Arc

Step 1 — Generate the Onboarding Script

In the Azure portal, navigate to Azure Arc → Servers → Add. Choose Add a single server for manual onboarding or Add multiple servers for scripted deployment via a service principal. Select your subscription, resource group, region, and operating system. Azure will generate a PowerShell script you copy and run locally on each target server.

Step 2 — Run the Connected Machine Agent Installer

On the target Windows Server, open PowerShell as Administrator and paste the generated script. It downloads and installs the Azure Connected Machine Agent, authenticates with Azure, and registers the server as an Arc-enabled resource. The whole process takes under five minutes per machine.

For bulk deployments across dozens of servers, use the service principal method. You’ll pass the --service-principal-id and --service-principal-secret flags so the script can authenticate non-interactively:

azcmagent connect --service-principal-id <appId> --service-principal-secret <secret> --tenant-id <tenantId> --subscription-id <subId> --resource-group <rg> --location eastus

Step 3 — Verify the Connection

Back in the Azure portal under Azure Arc → Servers, your machine should appear with a status of Connected. Click into it and you’ll see the server’s OS version, IP address, agent version, and last heartbeat timestamp. If status shows Disconnected, check that the Connected Machine Agent service is running locally with Get-Service himds in PowerShell.

Enabling Centralized Telemetry with Azure Monitor

Connecting a server to Arc is just the first step. The real value comes from wiring up centralized telemetry through Azure Monitor using the Azure Monitor Agent (AMA).

Deploy the Azure Monitor Agent via Arc

In the Azure portal, go to your Arc-enabled server → Extensions → Add and select Azure Monitor Agent. This installs the AMA directly on your on-premises machine through the Arc management channel — no need to physically touch the server or run scripts locally.

Next, create a Data Collection Rule (DCR) that defines what telemetry to gather. Common data sources for Windows Servers include:

• Windows Event Logs (Security, System, Application channels)
• Performance counters (CPU, memory, disk I/O)
• Syslog (if you have mixed environments)
• Custom text logs from line-of-business applications

Associate the DCR with your Arc-enabled servers, and data starts flowing into your Log Analytics Workspace within minutes.

Using Log Analytics for Security Insights

Once telemetry is flowing, use KQL (Kusto Query Language) in Log Analytics to surface actionable security data. For example, this query identifies failed login attempts across all Arc-connected servers:

SecurityEvent | where EventID == 4625 | summarize FailedLogins = count() by Computer, Account | order by FailedLogins desc

Run this on a schedule and pipe results to an alert rule. You’ve just built a basic brute-force detection mechanism across your entire on-premises estate — without a SIEM subscription.

Azure Arc Integration and Microsoft Defender for Servers

One of the most compelling security benefits of Azure Arc integration is the ability to onboard on-premises servers into Microsoft Defender for Servers (part of Defender for Cloud). This gives you:

• Vulnerability assessments powered by Qualys or Microsoft Defender Vulnerability Management
• Just-in-time VM access recommendations (even for on-premises machines)
• File integrity monitoring
• Adaptive application controls
• Security score contributions from your on-premises servers

To enable it, go to Defender for Cloud → Environment Settings, select your subscription, and toggle on Defender for Servers. Arc-connected machines automatically inherit coverage. Plan P1 costs approximately $0.007 per server per hour — for most small businesses running under 20 servers, that’s well under $100/month for enterprise-grade threat detection.

Enforcing Compliance with Azure Policy on Arc-Enabled Servers

Security isn’t just about detection — it’s about consistent configuration. Azure Policy lets you define and enforce standards across your Arc-connected servers automatically.

Practical policies to apply immediately:

• Audit Windows servers missing security updates — built-in policy flags machines with outstanding patches
• Require BitLocker on OS drives — enforces disk encryption compliance
• Restrict allowed PowerShell execution policies — reduces attack surface from malicious scripts
• Audit accounts with passwords that never expire — catches a common misconfiguration

Assign these policies to the resource group containing your Arc servers. Non-compliant machines get flagged in the Compliance dashboard, giving you a clear remediation queue without manual audits.

Getting the Most from Azure Arc: Practical Tips

• Tag your servers logically — use Azure resource tags like environment: production or location: datacenter-east to filter telemetry and apply policies at scale
• Set up workbook dashboards — Azure Monitor Workbooks let you build visual dashboards for server health and security KPIs without writing code
• Use update management through Arc — Azure Update Manager (now Arc-integrated) schedules and reports on patch compliance across hybrid environments
• Rotate service principal credentials regularly — if you used a service principal for bulk onboarding, treat it like a privileged account and rotate its secret on a schedule

Centralized Telemetry Is No Longer Optional

The logistics company mentioned at the start eventually deployed Azure Arc integration across their entire server fleet. Within the first week, they discovered two more servers with critical vulnerabilities, one with an unauthorized local admin account, and a performance bottleneck that had been silently degrading a key application for months. None of that would have surfaced without centralized telemetry.

If you’re running on-premises Windows Servers and relying on manual checks or disconnected tools, you have blind spots — and attackers know it. Azure Arc closes the gap between your local infrastructure and modern cloud-native security practices without requiring a full migration.

Start with one server. Run the onboarding script, connect Azure Monitor, and run that failed-login KQL query. What you find in the first 24 hours might surprise you.

Ready to get started? Visit Techbytes for more practical guides on securing your hybrid infrastructure, or drop your questions in the comments below.