Azure Arc for Servers: Enterprise Implementation Guide [2025]

The Evolution from MMA to Azure Arc

Before diving into Azure Arc, it's important to understand the journey that brought us here. For years, I worked extensively with the Microsoft Monitoring Agent (MMA) architecture, and honestly, it was beautifully simple and effective.

The Golden Age of MMA and Solution Packs

The old architecture was elegant in its simplicity. You had one agent - the Microsoft Monitoring Agent - and everything was enabled through solution packs at the Log Analytics workspace level. Azure Update Management was free, making it an easy door-opener to introduce other datacenter management capabilities to customers.

This architecture integrated seamlessly: Azure Automation, Process Automation, Configuration Management, Update Management, Inventory and Change Tracking, Log Analytics, Defender for Cloud (then Security Center), and Azure Sentinel all worked together as a unified ecosystem. One agent, multiple solution packs, everything connected to a central workspace. It was the best combo ever in terms of simplicity and integration.

The Service Evolution: V1 to V2 to V3

What many people don't realize is that the services we loved in the MMA era are now deprecated. Azure Update Management, Change Tracking, and Desired State Configuration - what I call the "V1 services" - were all based on Log Analytics Workspace (LAW) integrations and are no longer supported.

Microsoft has replaced them with entirely new architectures:

• Azure Update Management → Azure Update Manager (V2)
• Change Tracking (solution pack) → Change Tracking via DCR (V2) → Change Tracking V3 (latest, but I haven't had time to test this newest version yet)
• Desired State Configuration → Azure Machine Configuration service through Azure Policies (V2)

This versioning is based on my own classification system, not official Microsoft numbering, but it helps understand the evolution. Each generation has become more capable but also more complex to implement and manage.

Why the Transition to Arc is More Complex

Now, with Azure Arc for Servers, things have become significantly more complicated. While the new architecture offers much more flexibility and capability, it's lost some of that beautiful simplicity that made the MMA approach so appealing to customers and easy to implement.

Looking at the Azure Arc building blocks today, the complexity is immediately apparent. We now have Azure Policies, Azure Resource Graph, Azure Log Analytics, User-assigned Managed Identity, Data Collection Rules (DCR), Data Collection Endpoints (DCE), Azure Monitoring Agent, Extensions, and the core Azure Arc for Servers platform itself. Each component requires configuration, management, and understanding of how it interacts with the others.

The granular data collection capabilities through DCR and DCE let you precisely control what data gets collected from which servers and where it goes. You have DCR associations, different regional considerations, extension management, managed identities for authentication, and Azure Resource Graph for querying across your entire hybrid estate.

We've gained enormous capability, but the complexity has gone up exponentially. You need to understand management groups, subscriptions, Azure policies, RBAC inheritance, data collection architectures, extension lifecycles, and how all these components work together across different regions and compliance boundaries.

Some people dismiss the old approach as outdated and claim the new way is always better. I don't believe that's entirely true. The MMA architecture had real advantages in terms of simplicity and ease of deployment that we shouldn't ignore when planning Arc implementations.

What Azure Arc for Servers Actually Is

Azure Arc for Servers extends Azure management capabilities to machines running outside of Azure. At its core, it's a hybrid cloud platform that allows you to project on-premises servers, virtual machines from other cloud providers, and edge devices into Azure as first-class Azure resources.

When you Arc-enable a server, it becomes visible in the Azure portal alongside your native Azure VMs. You can apply Azure policies, install extensions, manage updates, collect logs, and even run PowerShell scripts remotely through the Azure Resource Manager (ARM) interface.

Azure Arc-enabled server appearing in Azure portal as a first-class Azure resource

Built on Azure Resource Manager (ARM)

The foundation of Azure Arc for Servers is Azure Resource Manager (ARM). When you onboard a server to Arc, it becomes a native Azure resource with a full ARM representation. This isn't just metadata storage - it's full integration with the Azure control plane.

This ARM foundation is what enables Arc servers to work with Azure RBAC, Azure Policy, resource tags, and all other Azure management capabilities. The server appears in the Azure portal, responds to ARM API calls, and can be managed through any Azure management tool.

This ARM foundation is why Arc feels like native Azure management rather than a separate hybrid management layer. Your on-premises servers become Azure resources that happen to be running elsewhere.

Business Case and Value Proposition

The fundamental business case for Azure Arc is platform unification - bringing your entire infrastructure and security stack under one management platform. Instead of juggling multiple tools for governance, protection, configuration, and monitoring, Arc creates a single Azure-based control plane for hybrid environments.

Foundation for Hybrid-Cloud Management

Arc establishes the foundation that enables four critical management pillars across your entire infrastructure:

Arc foundation: Unified governance, protection, configuration, and monitoring across hybrid infrastructure

Business Impact: From Tool Sprawl to Platform Efficiency

Organizations typically manage hybrid infrastructure through 5-10 different management tools. Arc consolidates these into Azure's unified platform, delivering:

Strategic Platform Foundation

Arc isn't just another management tool - it's the foundation that enables Azure's entire management ecosystem to work with your hybrid infrastructure. This includes Azure RBAC, Azure Policy, Defender for Cloud, Azure Monitor, and hundreds of other Azure services.

Arc ecosystem integration: Enabling Azure's entire service ecosystem for hybrid infrastructure management

Assessment Phase: Understanding Your Current State

Before implementing Azure Arc, you need to thoroughly assess your current infrastructure and administrative model. This isn't just an inventory exercise - it's about understanding the complexity and interdependencies that will impact your Arc deployment strategy.

Infrastructure Discovery and Classification

Start with a complete inventory of your server infrastructure. This goes beyond simple server counts - you need to understand operating systems, patch levels, network configurations, and existing management tools. Many organizations discover forgotten systems during this phase.

Arc assessment checklist: Infrastructure discovery, classification, and readiness evaluation

Legacy Tool Assessment

If you're currently using Configuration Manager (and yes, some of my MVP peers would want to slap me for calling it SCCM, but old habits die hard! 😄), understanding your existing collections, deployment packages, and automation scripts is critical. Arc doesn't simply replace Configuration Manager - it requires thoughtful migration of functionality.

Business Goal Alignment

Arc implementation should align with specific business objectives. Are you trying to improve security posture? Reduce operational overhead? Meet compliance requirements? The answers to these questions drive your Arc extension strategy and rollout approach.

Arc server classification spreadsheet: Excel template showing server inventory with Tier 0/1/2 classification, applications, and current management tools

Design Workshops: Architecture Planning

Once you understand your current state, the design workshop phase focuses on creating the target architecture. This is where you make critical decisions about subscription structure, network connectivity, and administrative boundaries that will impact your Arc deployment for years to come.

Subscription and Resource Group Design

One of the most important architectural decisions is how to organize your Arc-enabled servers within Azure subscriptions and resource groups. This isn't just about organization - it directly impacts billing, permissions, and policy application.

Arc subscription design: Security tier-based organization with clear RBAC boundaries and policy inheritance

Network Connectivity Architecture

Deciding how your Arc-enabled servers communicate with Azure is another critical architectural choice. The options range from direct internet connectivity to fully private connections using Arc Gateway or Azure Private Link.

Resource Tagging Strategy Design

During the design workshop phase, you need to carefully plan your resource tagging strategy. This isn't something to figure out later - tagging drives automation, policy application, cost allocation, and operational processes. Take time to understand what tags you actually need based on your business requirements.

Arc Tagging Considerations

Consider these categories during your design workshops, but only implement tags that serve a specific business or operational purpose:

Remember: every tag you define needs governance, validation, and maintenance. Start with tags that drive automation or business requirements, then expand based on actual usage patterns.

Architecture Planning: Integration Strategy

The final planning phase defines how Arc integrates with your identity infrastructure and broader IT ecosystem. This phase establishes the security foundation through identity governance design, implements the Active Directory tiering model for proper asset classification, and plans the automation strategy that will drive operational efficiency. Getting this architecture right determines your security posture, operational success, and long-term Arc implementation outcomes.

Active Directory Tiering Model (Enterprise Access Model)

The traditional Active Directory tiering model (now evolved into Microsoft's "Enterprise Access Model") establishes proper security boundaries through administrative isolation. This architectural design must be integrated with your Arc subscription design, RBAC assignments, and operational processes:

Active Directory tiering model: Tier 0/1/2 administrative boundaries and how they apply to Azure Arc server classification

Modern Identity Foundation for Hybrid Management

Before you can securely manage Arc servers and hybrid infrastructure, you need proper identity and access management as your foundation. You cannot secure other clouds with Azure without first securing the identity layer that controls access to everything.

Microsoft's Entra ID platform provides the modern identity security services that enable secure hybrid management:

• Cloud-only administrative accounts - Eliminate sync dependencies and on-premises compromise risks
• FIDO2 security keys - Passwordless authentication that can't be phished or compromised remotely
• Authentication Strengths - Granular control over authentication methods based on resource sensitivity
• Conditional Access policies - Context-aware access controls based on user, device, location, and risk
• Privileged Identity Management (PIM) - Just-in-time access with approval workflows and audit trails
• Identity Protection - AI-powered risk detection and automated remediation
• Access Reviews - Regular certification of permissions and access rights

Identity Governance Integration

With your identity security foundation established, you need to plan the technical implementation. Arc's integration with Entra ID creates specific governance requirements for how Arc service principals, Azure RBAC assignments, and conditional access policies work with your existing identity infrastructure.

Arc identity governance architecture: Integration with Entra ID, Azure RBAC, Conditional Access, and PIM

Automation and Operations Strategy

The main automation foundation is Azure Automation Account + Hybrid Workers - this combination enables you to make automation across all clouds and on-premises infrastructure. Once you have hybrid workers deployed, you can connect to any data source you need: Entra ID, Defender XDR, CMDB, ServiceNow, custom APIs - you name it. This is where you deliver all the automation scenarios your business actually needs.

With this foundation established, you can build automation that includes patch management through Azure Update Manager, security configuration through Azure Policy, and custom automation through Azure Resource Graph queries - but the real power is connecting to all your data sources and systems.

Azure Resource Graph for Arc Automation

Azure Resource Graph serves as the foundation for everything you'll build on top of Arc automation. Think of it as a library that lists all your Azure resources, including Arc-enabled servers. This becomes necessary for automation scenarios, reporting, and workbooks.

Without understanding Resource Graph, you'll struggle with advanced Arc automation. Every PowerShell script, every workbook, every custom reporting solution you build will query Resource Graph to discover and work with your Arc-enabled machines.

Resources
| where type == "microsoft.hybridcompute/machines"
| extend AgentVersion = properties.agentVersion
| extend LastHeartbeat = properties.lastStatusChange
| project name, resourceGroup, location, AgentVersion, LastHeartbeat
| order by name asc

Azure Resource Graph Explorer showing Arc-enabled servers with agent versions and status

Resource Tagging Strategy

Tagging becomes critical for Arc automation. Tags drive policy application, update schedules, and automation targeting. Your tagging strategy should align with your operational processes.

# Arc server tagging strategy implementation
Environment = "Production" | "Development" | "Testing"
Tier = "0" | "1" | "2"
PatchGroup = "Critical" | "Standard" | "Delayed"
Owner = "team-email@company.com"
Application = "exchange" | "sharepoint" | "custom-app"
MaintenanceWindow = "Saturday-2AM" | "Sunday-3AM" | "Wednesday-11PM"

Automated Defender integration tags: Azure automation runbook adds MDE exposure score, last seen timestamp, and onboarding status to every Arc server

Extension Deployment Planning

Extensions are the small applications that run on top of your Arc agent - they're what actually deliver functionality to your Arc-connected servers and Azure VMs. This is where the real business value emerges, but also where you'll encounter the most operational challenges.

What Extensions Actually Are

Extensions are lightweight applications that extend Arc agent functionality. They enable different capabilities on your servers:

• Microsoft Defender for Endpoint - Endpoint detection and response with Security Settings Management capabilities
• Azure Monitor Agent (AMA) - Log and metric collection
• Guest Configuration - Policy enforcement and compliance
• Custom Script Extensions - Run PowerShell or shell scripts
• Dependency Agent - Application dependency mapping
• Key Vault Extension - Certificate management

Extension Monitoring and Lifecycle Management

The biggest mistake organizations make is deploying extensions through Azure Policy and assuming they're working. Policy assignment success doesn't equal functional extensions. You need active monitoring of extension health and actual functionality.

// Get all Arc machines with their extension status
resources
| where type =~ "microsoft.hybridcompute/machines"
| where properties.status == "Connected"
| project 
    MachineName = name,
    ResourceGroup = resourceGroup,
    Location = location,
    OSType = properties.osType,
    Status = properties.status,
    AgentVersion = properties.agentVersion,
    MachineId = tolower(id)
| join kind=leftouter (
    resources
    | where type =~ "microsoft.hybridcompute/machines/extensions"
    | project 
        MachineId = tolower(tostring(split(id, "/extensions/")[0])),
        ExtensionName = name,
        ExtensionType = properties.type,
        ProvisioningState = properties.provisioningState
) on MachineId
| project MachineName, ResourceGroup, ExtensionName, ExtensionType, ProvisioningState
| order by MachineName asc, ExtensionName asc

Common Extension Problems and Solutions

Arc server extensions view: Installed extensions on a single Arc node showing status, version, and provisioning state

Permission Inheritance and Security Boundaries

One of the most shocking discoveries during Arc implementations is realizing how many people have elevated permissions in your Azure environment. Arc resources inherit permissions from management groups, subscriptions, and resource groups - suddenly making every server visible and manageable by anyone with elevated access at those levels.

Azure RBAC inheritance view: Azure portal showing how subscription-level role assignments automatically inherit to Arc-enabled servers

Getting Started: First Steps

Ready to test Arc? The quickest way to understand Azure Arc is to onboard a test server and see it appear in the Azure portal. This section covers the basic testing workflow - not production deployment.

Step 1: Register Required Resource Providers

Before onboarding any servers to Arc, you must register the recommended resource providers in your Azure subscription. This is a one-time setup step that enables Arc functionality:

• Microsoft.HybridCompute - Core Arc for Servers functionality
• Microsoft.GuestConfiguration - Azure Policy guest configuration
• Microsoft.HybridConnectivity - Hybrid connectivity features
• Microsoft.AzureArcData - Arc data services (required if you plan to Arc-enable SQL Servers)
• Microsoft.Compute - Azure Update Manager and automatic extension upgrades

# Connect to your Azure subscription first
Connect-AzAccount

# Register recommended Arc resource providers
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute
Register-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration
Register-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity
Register-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData
Register-AzResourceProvider -ProviderNamespace Microsoft.Compute

# Verify registration status
Get-AzResourceProvider -ProviderNamespace Microsoft.HybridCompute | Select-Object RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.GuestConfiguration | Select-Object RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.HybridConnectivity | Select-Object RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.AzureArcData | Select-Object RegistrationState
Get-AzResourceProvider -ProviderNamespace Microsoft.Compute | Select-Object RegistrationState

Step 2: Onboarding Script Generation

The Azure portal provides a simple script generation method that's perfect for understanding how Arc works:

1. Navigate to Azure Arc in the Azure portal
2. Select "Servers" from the left navigation
3. Click "Add/Create" and choose "Add a server"
4. Select "Generate script" for interactive installation
5. Configure basic settings: Subscription, Resource Group, Region
6. Download the generated PowerShell script

Azure portal Arc server onboarding: Generate script interface with subscription and resource group selection

Running the Onboarding Script

The generated script handles agent download, installation, and registration automatically:

$global:scriptPath = $myinvocation.mycommand.definition

function Restart-AsAdmin {
    $pwshCommand = "powershell"
    if ($PSVersionTable.PSVersion.Major -ge 6) {
        $pwshCommand = "pwsh"
    }

    try {
        Write-Host "This script requires administrator permissions to install the Azure Connected Machine Agent. Attempting to restart script with elevated permissions..."
        $arguments = "-NoExit -Command `"& '$scriptPath'`""
        Start-Process $pwshCommand -Verb runAs -ArgumentList $arguments
        exit 0
    } catch {
        throw "Failed to elevate permissions. Please run this script as Administrator."
    }
}

try {
    if (-not ([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)) {
        if ([System.Environment]::UserInteractive) {
            Restart-AsAdmin
        } else {
            throw "This script requires administrator permissions to install the Azure Connected Machine Agent. Please run this script as Administrator."
        }
    }

    # Add the service principal application ID and secret here
    $ServicePrincipalId="your-service-principal-id";
    $ServicePrincipalClientSecret="";

    $env:SUBSCRIPTION_ID = "your-subscription-id";
    $env:RESOURCE_GROUP = "your-resource-group";
    $env:TENANT_ID = "your-tenant-id";
    $env:LOCATION = "westeurope";
    $env:AUTH_TYPE = "principal";
    $env:CORRELATION_ID = "your-correlation-id";
    $env:CLOUD = "AzureCloud";
    

    [Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor 3072;

    $azcmagentPath = Join-Path $env:SystemRoot "AzureConnectedMachineAgent"
    if (-Not (Test-Path -Path $azcmagentPath)) {
        New-Item -Path $azcmagentPath -ItemType Directory
        Write-Output "Directory '$azcmagentPath' created"
    }

    $tempPath = Join-Path $azcmagentPath "temp"
    if (-Not (Test-Path -Path $tempPath)) {
        New-Item -Path $tempPath -ItemType Directory
        Write-Output "Directory '$tempPath' created"
    }

    $installScriptPath = Join-Path $tempPath "install_windows_azcmagent.ps1"

    # Download the installation package
    Invoke-WebRequest -UseBasicParsing -Uri "https://gbl.his.arc.azure.com/azcmagent-windows" -TimeoutSec 30 -OutFile "$installScriptPath";

    # Install the hybrid agent
    & "$installScriptPath";
    if ($LASTEXITCODE -ne 0) { exit 1; }
    Start-Sleep -Seconds 5;

    # Run connect command
    & "$env:ProgramW6432\AzureConnectedMachineAgent\azcmagent.exe" connect --service-principal-id "$ServicePrincipalId" --service-principal-secret "$ServicePrincipalClientSecret" --resource-group "$env:RESOURCE_GROUP" --tenant-id "$env:TENANT_ID" --location "$env:LOCATION" --subscription-id "$env:SUBSCRIPTION_ID" --cloud "$env:CLOUD" --correlation-id "$env:CORRELATION_ID";
}
catch {
    $logBody = @{subscriptionId="$env:SUBSCRIPTION_ID";resourceGroup="$env:RESOURCE_GROUP";tenantId="$env:TENANT_ID";location="$env:LOCATION";correlationId="$env:CORRELATION_ID";authType="$env:AUTH_TYPE";operation="onboarding";messageType=$_.FullyQualifiedErrorId;message="$_";};
    Invoke-WebRequest -UseBasicParsing -Uri "https://gbl.his.arc.azure.com/log" -Method "PUT" -Body ($logBody | ConvertTo-Json) | out-null;
    Write-Host  -ForegroundColor red $_.Exception;
}

Local Agent Security Controls

Starting with Azure Arc agent version 1.16, you can implement enhanced security controls directly on the agent for environments requiring additional security hardening.

Agent Configuration Mode

By default, the Azure Arc agent runs in "full mode," which enables all extensions and functionalities including guest configuration, remote connectivity tools, and complete extension management. For environments requiring enhanced security, you can switch the agent to "monitor mode":

# Switch to monitor mode (monitoring extensions only)
azcmagent config set config.mode monitor

# View current agent configuration
azcmagent config get

# Return to full mode if needed
azcmagent config set config.mode full

Monitor mode restricts the agent to only monitoring-related extensions and disables guest configuration services, providing a more secure but limited operational scope.

Extension Control

Configure which extensions can be installed on servers to prevent installation of unauthorized or arbitrary scripts. This is essential for managing extensions in privileged contexts:

# Configure extension allowlist (only these extensions can be installed)
azcmagent config set extensions.allowlist "Microsoft.Azure.Monitor.AzureMonitorLinuxAgent,Microsoft.Azure.Security.Monitoring.AzureSecurityLinuxAgent"

# Configure extension blocklist (these extensions cannot be installed)
azcmagent config set extensions.blocklist "Microsoft.CPlat.Core.RunCommandLinux"

# Disable extension manager entirely (maximum security)
azcmagent config set extensions.enabled false

# View current extension configuration
azcmagent config get extensions

Guest Configuration Management

Azure Policy Guest Configuration can be disabled for strict control requirements:

# Disable Guest Configuration
azcmagent config set guestconfiguration.enabled false

# Enable Guest Configuration
azcmagent config set guestconfiguration.enabled true

Verification Steps

After running the script, verify successful onboarding:

Successfully onboarded Arc server appearing in Azure portal with "Connected" status

# Check agent configuration and status
azcmagent show

# Test connectivity to Azure Arc
azcmagent check

# View installed extensions (should be empty initially)
azcmagent extension list

azcmagent show command output displaying successful connection details and agent configuration

What's Next: Once you've successfully onboarded a test server, you can experiment with extensions, policies, and monitoring capabilities. For production deployments, continue to the Technical Requirements and Deployment Methods sections.

Technical Requirements and Dependencies

Before implementing Arc at scale, understand the platform requirements, network dependencies, and architectural prerequisites. This section provides the technical foundation for planning your deployment.

Platform Support Matrix

Required Azure Resource Providers

Your subscription must have these resource providers registered before onboarding Arc servers:

Azure portal: Resource provider registration status showing Microsoft.HybridCompute and related providers

Network Connectivity Requirements

Arc servers need connectivity to specific Azure endpoints. Network configuration often requires significant planning time.

Agent Connectivity Methods

Reference: For detailed connectivity guidance, see Microsoft's Arc connectivity documentation.

Deployment Methods and Enterprise Automation

Moving from testing to production requires choosing the right deployment method for your environment. This section covers enterprise-grade approaches that scale beyond individual servers.

Deployment Methods Comparison

Service Principal Setup for Production

Service principals provide secure, scalable authentication for Arc deployments without exposing user credentials:

# Connect to Microsoft Graph for Entra ID operations
Connect-MgGraph -Scopes "Application.ReadWrite.All"

# Connect to Azure for RBAC assignment
Connect-AzAccount

# Create the service principal
$appParams = @{
    DisplayName = "Arc-Onboarding-ServicePrincipal"
    Description = "Service Principal for Azure Arc server onboarding"
}
$app = New-MgApplication @appParams

# Create service principal for the application
$sp = New-MgServicePrincipal -AppId $app.AppId

# Create a client secret (valid for 2 years)
$passwordCred = @{
    displayName = "Arc-Onboarding-Secret"
    endDateTime = (Get-Date).AddYears(2)
}
$secret = Add-MgApplicationPassword -ApplicationId $app.Id -PasswordCredential $passwordCred

# Assign Azure Connected Machine Onboarding role
# Replace with your subscription ID and scope (subscription, resource group, etc.)
$subscriptionId = "your-subscription-id"
$scope = "/subscriptions/$subscriptionId" # or "/subscriptions/$subscriptionId/resourceGroups/your-rg"

New-AzRoleAssignment `
    -ObjectId $sp.Id `
    -RoleDefinitionName "Azure Connected Machine Onboarding" `
    -Scope $scope

# Output the details you need for onboarding script
Write-Host "Service Principal Details:" -ForegroundColor Green
Write-Host "Application ID: $($app.AppId)" -ForegroundColor Yellow
Write-Host "Secret Value: $($secret.SecretText)" -ForegroundColor Yellow
Write-Host "Tenant ID: $((Get-MgContext).TenantId)" -ForegroundColor Yellow

Creating dedicated service principal for Arc onboarding with minimal required permissions

Configuration Manager Integration (Enterprise Approach)

For organizations already running Configuration Manager (yes, I still call it SCCM sometimes! 😄), this is often the most logical Arc deployment method. People who complain that Configuration Manager is complex usually haven't done real device management in larger environments - when you're managing thousands of servers across multiple sites, geographic regions, and maintenance windows, you need that level of control and orchestration.

Configuration Manager provides excellent control for Arc deployment through custom task sequences, offering enterprise-grade deployment management capabilities that simple scripts can't match:

SCCM task sequence for Arc deployment: conditional steps, OS detection, and phased rollout configuration

PowerShell Remoting Approach

If you have PowerShell remoting enabled, then you can download the Microsoft official PowerShell module from the PowerShell Gallery and onboard all the machines remotely! If you are not using PowerShell remoting today, then it is time to ditch the RDP :)

# Install the Az.ConnectedMachine PowerShell module
Install-Module -Name Az.ConnectedMachine -Verbose -Force

# Connect to Azure and set context
Connect-AzAccount
Set-AzContext -SubscriptionId "your-subscription-id"

# Onboard remote machine using PowerShell Remoting
$ServerName = "SERVER02"
$PSRemoteSession = New-PSSession -ComputerName $ServerName

$OnboardingDetails = @{
    ResourceGroupName = "RG-PROD-IT-ARC"
    Location = "West Europe"
    PSSession = $PSRemoteSession
}

Connect-AzConnectedMachine @OnboardingDetails

The Az.ConnectedMachine PowerShell module provides an official Microsoft approach for Arc onboarding. You can create multiple remote sessions against many machines and onboard them simultaneously. This method works well for PowerShell-capable environments where you have remote access to target servers.

Dynamic Tagging and Resource Organization

My recommendation is to set up automated tagging that triggers after Arc onboarding through Azure eventing and provisioning automation. As I mentioned in the design section, resource tagging is important for operational efficiency. This approach gives you extra use cases - when a node gets onboarded, automation kicks in to automatically apply tags based on data sources like CMDB, Defender for Endpoint, ServiceNow, or whatever systems you're working with. These tags can also be used for Microsoft Defender XDR Security Settings Management enrollment targeting.

Pre-Onboarding Discovery (Option 1)

You can discover and gather all the necessary data first, then connect the server to Arc with tags already applied. This approach reduces post-onboarding automation complexity but requires the onboarding script to handle data discovery upfront.

Event-Driven Tag Assignment (Option 2)

When an Arc server is onboarded, automation triggers queries to multiple data sources simultaneously. The CMDB provides department and application information, Defender XDR supplies security risk levels, ServiceNow offers ownership details, and custom APIs deliver business-specific data.

Automated Tag Building

All collected data gets consolidated into a comprehensive tag set that includes security tier classification, maintenance windows, cost center allocation, and operational metadata. This happens automatically without manual intervention.

Reference: For complete deployment options and detailed procedures, see Microsoft's Arc deployment documentation.

Troubleshooting and Operations

When Arc deployments fail or agents disconnect, quick diagnosis and resolution are critical. This section provides practical troubleshooting guidance based on real-world operational experience.

Common Issues and Resolutions

Diagnostic Commands Reference

Essential commands for diagnosing Arc agent issues:

# Check agent status and configuration
azcmagent show

# Test connectivity to Azure Arc endpoints
azcmagent check

# List installed extensions
azcmagent extension list

# Check agent version
azcmagent --version

# View agent logs location
azcmagent logs

azcmagent check command output showing connectivity test results and potential network issues

Arc Agent Log Analysis

Arc agents write diagnostic information to log files that can be collected and analyzed for troubleshooting. The azcmagent logs command provides an easy way to gather all relevant log files.

# Collect recent log files to current directory
azcmagent logs

# Collect all log files to specific location
azcmagent logs --full --output "C:\temp\arc-logs.zip"

# Enable verbose logging for troubleshooting (Windows)
& "$env:ProgramFiles\AzureConnectedMachineAgent\azcmagent.exe" connect --verbose

# View live log file (Windows)
Get-Content "%ProgramData%\AzureConnectedMachineAgent\Log\azcmagent.log" -Wait

# View live log file (Linux)
tail -f /var/opt/azcmagent/log/azcmagent.log

Network Connectivity Troubleshooting

Network issues are the most common cause of Arc problems. Systematic network testing is needed:

# Use the Arc agent's built-in network connectivity test
azcmagent check --location "westeurope"

# This tests all required Arc endpoints automatically:
# - Azure Resource Manager endpoints
# - Azure Active Directory endpoints  
# - Telemetry endpoints
# - Guest configuration endpoints
# - Extension management endpoints

# For detailed output with specific endpoint results
azcmagent check --location "westeurope" --verbose

# Check connectivity with private endpoints enabled
azcmagent check --location "westeurope" --enable-pls-check

# Check connectivity including all extension endpoints
azcmagent check --extensions all

Agent Service Management

Sometimes restarting services resolves connectivity or performance issues:

# Check Arc service status
Get-Service -Name "himds" | Format-List

# Restart Arc agent service
Restart-Service -Name "himds" -Force

# Check Guest Configuration service
Get-Service -Name "GCArcService" | Format-List

# View service dependencies
Get-Service -Name "himds" -DependentServices

Resource Cleanup and Maintenance

Operational hygiene prevents many issues before they occur:

Azure dashboard showing Arc server fleet health: connectivity status, agent versions, and operational alerts

Strategic Implementation Success: Beyond Agent Installation

Azure Arc for Servers represents one of Microsoft's most significant infrastructure innovations, but successful implementation requires far more than just installing agents on servers. This is a strategic transformation that touches security architecture, administrative models, network design, and operational processes.

Key Strategic Considerations

Throughout this guide, we've emphasized that Azure Arc success depends on understanding these critical elements:

The Transformation Challenge

Moving from the simple MMA architecture to Azure Arc's distributed building blocks requires architectural thinking. Organizations that treat this as "just another agent installation" typically struggle with:

• Security boundaries becoming blurred when domain admins suddenly have cloud management capabilities
• Network complexity underestimated, leading to connectivity failures and performance issues
• Operational gaps where no one knows how to troubleshoot or maintain the new hybrid architecture
• Scale limitations when testing approaches don't translate to enterprise production requirements

The Enterprise Success Formula

Based on real-world implementations across multiple enterprise environments, successful Azure Arc transformations follow this pattern:

When Professional Services Make Sense

Azure Arc implementations benefit from professional services when you need to:

Ready to Transform Your Infrastructure?

Azure Arc for Servers isn't just a technology decision - it's a strategic transformation that requires careful planning, expert architecture, and proven implementation methods. Don't let your organization struggle with common pitfalls or settle for suboptimal implementations.

"Transform your infrastructure strategically, not tactically. Get the architectural foundation right from the beginning."