Azure Arc onboarding preflight checklist

Good For

• Change tickets for Azure Arc onboarding
• Pilot server selection and readiness review
• Evidence collection before deploying the Connected Machine agent
• CSV-based readiness reporting for single hosts or host lists

How to Use It

1. Confirm onboarding scope and Azure destination: Record subscription ID, resource group, Azure region, tenant, and naming standard for Arc resources. Document the intended owner, support group, maintenance window, and whether the server is pilot, wave 1, or deferred. Capture required tags before onboarding, such as Environment, BusinessOwner, CostCenter, PatchRing, DataClassification, and Criticality. Note whether the server will use public internet egress or an authenticated proxy.
2. Verify host eligibility and local prerequisites: Record server name, OS edition/version/build, domain membership, uptime, and pending reboot state. Confirm the operator account has local administrator rights on the target server. Check that time synchronization is healthy and not significantly skewed. Confirm core services needed for basic remote administration and time sync are present and running or intentionally managed: WinRM, w32time, Windows Update.
3. Validate outbound connectivity and proxy behavior: Resolve required Azure Arc and Microsoft identity endpoints via DNS from the server. Test outbound TCP 443 connectivity to required endpoints from the server itself, not only from a jump host. Record WinHTTP proxy settings and any user-context proxy settings that may differ. If a proxy is in use, confirm whether it requires authentication, TLS inspection, or explicit allowlisting.
4. Confirm identity, permissions, and deployment method: Identify the Azure role or delegated permissions the onboarding operator or service principal will use. Record whether onboarding will be interactive, service principal-based, or automated by policy/tooling. Verify the target resource group and region already exist and match governance requirements. Document any conditional access, MFA, or network segmentation constraints that could affect the onboarding flow.
5. Define pilot controls, evidence, and rollback notes: Select a small pilot set with mixed network paths: direct internet, proxy, domain-joined, and representative application roles. Define success evidence: server appears in Azure Arc, tags applied, status connected, and no unexpected service impact. Prepare rollback notes limited to disconnect/unregister decision authority, agent removal ownership, and post-change verification steps; do not execute rollback during preflight. Store all findings in operator notes and export a CSV readiness sheet for ticket attachment.

Execution Modes

• local

Inputs and Outputs

Inputs

• Server list - (required) - example: srv-app-01, srv-web-02
• Azure subscription/resource group/region - (required) - example: Sub=Prod-Infra, RG=rg-arc-prod, Region=eastus
• Required tags - (required) - example: Environment=Prod; BusinessOwner=ERP; CostCenter=1234; PatchRing=B
• Proxy and egress details - example: Explicit proxy proxy01.contoso.com:8080, no auth, TLS inspection enabled
• Operator identity and permission model - (required) - example: User-based onboarding with Contributor on RG and local admin on server

Outputs

• verbose-console
• operator-notes

Command Starter

Safe to run: read-only

# ---------------------------------------------------------------------
# Representative host-readiness checks
# Validate Microsoft's current full Azure Arc endpoint requirements separately.
# ---------------------------------------------------------------------
Get-ComputerInfo | Select-Object OsName, OsVersion, WindowsVersion
Get-Service WinRM, wuauserv, w32time | Select-Object Name, Status, StartType

# Representative outbound endpoints for a starter connectivity check.
$Endpoints = @(
    'gbl.his.arc.azure.com',
    'agentserviceapi.guestconfiguration.azure.com',
    'login.microsoftonline.com',
    'management.azure.com'
)

foreach ($Endpoint in $Endpoints) {
    Test-NetConnection -ComputerName $Endpoint -Port 443 |
        Select-Object ComputerName, RemotePort, TcpTestSucceeded
}

Validation

• Each target server has recorded OS/build, domain status, last boot time, and pending reboot evidence.
• DNS resolution and outbound TCP 443 tests succeed for required Azure Arc and identity endpoints, or exceptions are explicitly documented.
• Proxy path is identified with evidence from WinHTTP and user-context settings, including whether authentication or TLS inspection applies.
• Azure destination details, required tags, pilot wave, and operator permission model are documented and approved.

Reporting

• Summarize host count by readiness state: Ready, Ready with exceptions, Blocked.
• List blocked hosts with exact failed check: DNS, TCP 443, proxy auth, pending reboot, missing tags, missing permissions.
• Include a pilot scope table showing representative server roles and network paths.
• Attach raw command evidence or transcript for at least one sample host per network path.

Safety Notes

• These endpoint checks are representative starter checks, not a replacement for Microsoft's current full Azure Arc network-requirements documentation for the exact feature scope you plan to use.
• Keep the preflight read-only. Do not install agents, open firewall rules, or change proxy settings during the evidence pass.
• Record the Azure destination, tag plan, onboarding identity, and rollback owner before moving from preflight into execution.