First page of Microsoft's 100,000-partner directory, sorted by responsiveness Microsoft Solutions Partner — Security, Modern Work, Infrastructure, App Innovation Microsoft partner since 2006 1,100+ organizations under management
Home/Services/Azure Arc Hybrid Server Management Implementation
Implementation

Azure Arc Hybrid Server Management Implementation

For the servers that are not moving to the cloud — and were never going to — IT Partner onboards your on-premises and other-cloud Windows and Linux servers to Azure Arc, so they get Azure-side inventory, governance, patching, and security visibility while staying exactly where they are. The two-week engagement covers connectivity design, at-scale rollout of the Connected Machine agent, a tagging and inventory taxonomy, an Azure Policy compliance baseline, Azure Update Manager patching schedules with maintenance windows, and optional Microsoft Defender for Cloud enrollment. Pricing is an estimate at $25 per server plus a $1,950 base fee, confirmed in writing once the server inventory is agreed. One boundary stated plainly: Azure charges for the management services you attach — patching for Arc servers, Defender plans, log ingestion — are billed by Microsoft separately, and the design phase models them before you switch anything on.

Timeline 2 weeksService owner Roman SotnikMicrosoft AzureAzure ArcWindows Server

What this engagement is

Not every server belongs in the cloud, and we say that as a company that migrates servers for a living. Some workloads are latency-bound to the factory floor, some talk to hardware, some are anchored by licensing or data-residency constraints, and some are simply not worth moving — the business case says stay. What those servers usually get is the worst of both worlds: none of the cloud's management surface and all of the operational sprawl of scattered infrastructure — patching by spreadsheet, inventory by memory, and security visibility that stops at the datacenter door. Azure Arc exists for exactly this population, and this engagement is the alternative we offer when the answer to migration was no. Arc projects your non-Azure servers into Azure Resource Manager: each machine — on-premises, at a colocation site, or in another cloud — appears in Azure as a resource you can tag, query, govern, and secure alongside everything else. The Connected Machine agent connects outbound only; nothing dials into your network, and no workload moves anywhere. On that foundation the engagement builds the management layer in a deliberate order. A tagging and inventory taxonomy first, so the estate becomes searchable and reportable. Then an Azure Policy baseline, which audits and enforces configuration standards on machines that have never seen the cloud. Then Azure Update Manager: patching schedules with real maintenance windows for Windows and Linux alike, replacing whatever mixture of WSUS, cron, and optimism is doing the job today. And optionally, Microsoft Defender for Cloud enrollment, extending threat protection and posture management to servers your Azure-side security tooling currently cannot see — a natural pairing with our Defender for Cloud CSPM service. There is also a licensing story worth knowing, because Microsoft keeps sweetening it: Arc is the delivery channel for benefits that used to require being in Azure. Windows Server 2025 machines connected through Arc can use hotpatching — security updates without the monthly reboot — which Microsoft made available at no extra cost in mid-2026, and a pay-as-you-go licensing option exists for organizations that want off the traditional licensing cycle. Older servers can receive Extended Security Updates through Arc, paid monthly instead of bought in annual blocks. None of this requires migrating anything; it requires exactly what this engagement delivers — a connected, governed estate. And if some of these servers do move to Azure later, the work is not throwaway: the inventory, tags, and policy assignments carry into the migration as its ready-made assessment.

Success criteria

01Every in-scope server has the Connected Machine agent deployed, appears in Azure Resource Manager, and reports a healthy connected status.
02The connectivity model — direct outbound, proxy, or Private Link — is designed, documented, and working for every network segment in scope.
03The tagging taxonomy is applied across the estate, and inventory questions (what exists, where, owned by whom, patched when) are answerable from Azure Resource Graph rather than from memory.
04The Azure Policy baseline is assigned and reporting: compliance state is visible per machine, and the chosen enforcement or audit mode is documented per policy.
05Azure Update Manager patching schedules are configured with agreed maintenance windows, and at least one full patch cycle has run successfully on pilot and production groups within the engagement.
06Where Defender for Cloud enrollment is in scope, the selected plan is enabled for the Arc estate and findings are flowing.
07Projected monthly Microsoft charges for every attached management service are documented and acknowledged before those services are enabled.
08The client's team can onboard a new server, interpret compliance and patch status, and adjust schedules unaided after the handover session.

What you receive

Arc design document: resource group and management structure, connectivity model per network segment (direct, proxy, or Private Link), identity approach for onboarding, and the service-enablement plan.
At-scale agent rollout using the method that fits your estate — scripted deployment, Group Policy, or your configuration-management tooling — rather than hand-installing per server.
Tagging and inventory taxonomy: agreed tag schema applied to the estate, plus saved Azure Resource Graph queries for the inventory questions your team actually asks.
Azure Policy compliance baseline: an agreed set of audit and enforcement policies assigned to the Arc estate, with per-policy mode decisions documented.
Azure Update Manager configuration: patch schedules and maintenance windows per server group, update classifications, and reporting — with a pilot group patched first, by design.
Optional Microsoft Defender for Cloud enrollment for the Arc estate, with the plan selection made against your existing security tooling rather than by default.
Cost model for attached services: projected monthly Microsoft charges per service against the current price list, including the cases where charges are waived under Microsoft's bundling rules, so nothing is enabled blind.
Onboarding runbook for future servers: the exact procedure, scripts, and tag standards to add machine number 201 the same way as the first 200.
Handover session with your team: operating the estate day to day — compliance triage, patch schedule changes, and onboarding — plus the as-built documentation.
Closeout report: connected-machine reconciliation against the agreed inventory, exceptions dispositioned, and recommended next steps stated honestly.

How the work unfolds

1. Discovery and design (days 1-3)

Inventory the candidate estate: server count, operating systems and versions, network segments, egress rules, and proxies. Produce the design — connectivity model, resource structure, tag schema, policy set, patch groups — and the attached-services cost model. You approve both before anything is deployed.

2. Pilot onboarding (days 3-5)

Onboard a pilot group spanning your real diversity — Windows and Linux, each network segment, the oldest OS in scope. Validate agent health, connectivity, tagging, and a policy assignment on the pilot before scaling anything.

3. Estate rollout (week 2, first half)

Roll the agent out at scale using the chosen mechanism, reconcile connected machines against the inventory, apply the tag taxonomy, and chase the stragglers — there are always stragglers, and the closeout report names them rather than ignoring them.

4. Management services (week 2, second half)

Assign the Azure Policy baseline, configure Update Manager schedules and maintenance windows, run the pilot patch cycle, and enable Defender for Cloud where in scope — each service switched on against the acknowledged cost model, never silently.

5. Validation and handover (end of week 2)

Verify success criteria end to end, run the handover session with your team, and deliver the runbook, as-built documentation, and closeout report.

Prerequisites

A server inventory, even a rough one — count, operating systems, and locations — to confirm the estimate and shape the pilot; we refine it together during discovery.
Servers running operating system versions supported by the Connected Machine agent — current Windows Server versions and mainstream Linux distributions are covered, and we confirm your specific list against Microsoft's support matrix during planning.
Outbound HTTPS (port 443) connectivity from the servers to Azure endpoints, directly or via proxy — no inbound connectivity is required; fully air-gapped segments cannot be Arc-enabled and are flagged honestly in scope.
An Azure subscription with permissions to create resource groups, service principals or managed identities for onboarding, policy assignments, and the management services in scope.
A deployment path for the agent at scale: administrative credentials plus Group Policy, your configuration-management tooling, or approval for scripted rollout.
Named decision-makers for the tag taxonomy, the policy baseline's audit-versus-enforce choices, and maintenance windows — governance decisions are yours to sign, and we come with defensible defaults.
Acknowledgment that attached management services carry Microsoft charges billed to your subscription — presented in the cost model and approved before enablement.
For optional Defender enrollment: sight of your existing endpoint and security tooling so the plan choice complements rather than duplicates what you already pay for.

Who does what

IT Partner

  • Design the Arc architecture: connectivity, identity, resource structure, tags, policies, and patch groups.
  • Execute the pilot and the at-scale agent rollout, and reconcile connected machines against the inventory.
  • Configure Azure Policy, Update Manager schedules, and optional Defender for Cloud enrollment as scoped.
  • Produce the attached-services cost model and obtain acknowledgment before enabling anything metered.
  • Deliver the onboarding runbook, as-built documentation, handover session, and closeout report.
  • Flag servers that cannot or should not be Arc-enabled — and servers that frankly should be migrated instead — rather than onboarding indiscriminately.

Your team

  • Provide the server inventory, administrative credentials, and the deployment mechanism for the agent.
  • Open the required outbound connectivity or provide proxy details per the design.
  • Sign off the tag taxonomy, policy baseline modes, maintenance windows, and the attached-services cost model.
  • Provide change-window approvals for the pilot patch cycle and any enforcement-mode policies.
  • Own Microsoft charges for attached services billed to your subscription, and licensing decisions the engagement surfaces.
  • Operate the estate after handover using the runbook, or engage ongoing operations separately.

What's not included

Server migrations — this service exists precisely for machines that are staying; when a server should move instead, we say so and route it to the VMware to Azure or Windows Server to Azure migration services.
Microsoft charges for attached services — Update Manager for Arc-enabled servers, Defender for Servers plans, log ingestion, and similar meters are billed by Microsoft to your subscription; we model them honestly in the design, but they are not inside our fee.
SQL Server enabled by Azure Arc beyond pointers — we flag SQL instances the rollout discovers and outline what Arc-enabled SQL Server offers, but SQL-specific configuration and licensing advisory are separate, deliberately scoped work.
Azure Arc for Kubernetes clusters and Arc-enabled data services — different Arc products, different projects; ask and we scope them separately.
Remediation of unhealthy servers: machines that fail to onboard due to broken agents-of-other-kinds, OS corruption, or unsupported versions are dispositioned in the closeout, and their repair is separate work.
Network engineering beyond the Arc connectivity design — new proxies, firewall replacements, or Private Link infrastructure build-out are scoped separately if the design calls for them (our VPN and ExpressRoute service covers the connectivity layer).
Ongoing operations after handover — patch babysitting, compliance triage, and monitoring are available through Azure Resource Monitoring and Maintenance as an explicit separate engagement.
Broader governance and landing-zone architecture for workloads actually in Azure — that is the Azure Landing Zone and Cloud Adoption Framework Implementation, and the two pair well for genuinely hybrid estates.

Limitations & technical notes

!The $25-per-server + $1,950 pricing is an estimate: heavily segmented networks, proxy complexity, very old operating systems, and Private Link requirements move effort, and the written quote follows the agreed inventory — before work begins.
!Arc's core control plane — inventory, tagging, resource organization — carries no Azure charge, but the management services you attach are metered: patching for Arc-enabled servers, Defender plans, and log ingestion are billed by Microsoft, with prices and waiver conditions that Microsoft revises. We deliberately print none of those numbers here; the cost model in the design carries the current ones.
!Arc requires a supported OS and outbound connectivity: end-of-life operating systems outside the agent's support matrix and fully air-gapped segments cannot be onboarded, and the closeout report names every machine excluded and why.
!Onboarding a server does not repair it. Machines with broken WMI, dying disks, or years of configuration drift will connect and then honestly report their condition — Arc makes problems visible, which is the point, but fixing them is separate work.
!Policy enforcement is a governance decision with operational consequences: enforce-mode policies can change machine configuration. The baseline defaults to audit mode wherever there is doubt, and every enforce decision is signed, not assumed.
!Patch schedules act on what Microsoft and the OS vendors publish; Update Manager orchestrates installation and reboots within your windows, but it cannot make a fragile application enjoy patching — pilot groups and maintenance windows exist for exactly that reason.
!Licensing benefits delivered through Arc — hotpatching terms, pay-as-you-go licensing, Extended Security Updates — are Microsoft programs with Microsoft's conditions, current as of the engagement and verified during design rather than promised from this page.

Frequently asked questions

What is Azure Arc, in plain terms?

A way to make servers that are not in Azure manageable as if they were. An agent on each server connects outbound to Azure, and the machine appears in Azure Resource Manager as a first-class resource — you can tag it, inventory it with queries, apply policy to it, patch it on a schedule, and point security tooling at it. The workload itself does not move, and nothing about Arc requires it ever to move.

Is this a migration in disguise?

No — it is the service we propose when migration was evaluated and declined, which happens for good reasons: latency, attached hardware, licensing anchors, data residency, or a business case that says stay. Arc gives those servers cloud-side governance without relocation. If circumstances change later, the connected estate doubles as a ready-made migration assessment — but that is your option, not our agenda.

What does Azure Arc itself cost to run?

Arc's core control plane — connecting machines, inventory, tagging, organizing them in Azure — carries no Azure charge. Costs come from the management services you attach: patching for Arc-enabled servers, Defender for Servers plans, and log ingestion are metered by Microsoft, and some charges are waived in specific bundling cases, such as patching being included for machines covered by certain Defender or ESU arrangements. Microsoft revises these prices, so we model your exact configuration against the current price list in the design phase — nothing gets enabled until you have seen its monthly number.

Which operating systems can be onboarded?

The Connected Machine agent supports current Windows Server versions and the mainstream Linux distributions — Ubuntu, Red Hat, SUSE, and peers — and we confirm your specific OS list against Microsoft's support matrix during discovery. End-of-life systems outside the matrix cannot be onboarded and are dispositioned honestly in the closeout: sometimes the answer is an OS upgrade, sometimes ESU through Arc for versions that qualify, and sometimes retirement.

Do you need inbound access to our network?

No. The agent connects outbound over HTTPS only — directly, through your existing proxy, or via Azure Private Link for organizations that want traffic off the public internet entirely. Nothing in Azure initiates connections into your network, and no inbound firewall rules are opened for this engagement. Fully air-gapped segments are the one hard limit: no outbound path, no Arc.

What does the Azure Policy baseline actually do on-premises?

It audits — and where you explicitly choose, enforces — configuration standards on the connected machines: things like required security settings, expected agents, and OS configuration state. The practical win is one compliance view across cloud and on-premises instead of a separate standard for each. We default to audit mode wherever there is doubt, because enforcement changes machine state, and that switch gets flipped by your signature, not our assumption.

How does patching through Azure Update Manager compare to WSUS?

It replaces the machinery, not the discipline. Update Manager schedules and orchestrates Windows and Linux patching from Azure — one console, real maintenance windows, per-group schedules, and reporting that shows the truth per machine — without a WSUS server to feed and water. For Arc-enabled machines it is a metered Azure service, which the cost model covers. The engagement configures pilot-first patching so schedule mistakes surface on ten servers, not two hundred.

What do we get from enrolling the Arc servers in Defender for Cloud?

Security posture and threat protection for machines your Azure security tooling currently cannot see: vulnerability findings, attack-surface recommendations, and alerting, in the same Defender for Cloud view as your Azure resources. It is optional in this engagement on purpose — plan selection depends on what endpoint protection you already run and pay for, and we choose against your existing stack rather than stacking duplicates. For the fuller posture-management picture, this pairs naturally with our Defender for Cloud CSPM implementation.

We have SQL Server on several of these machines — is that covered?

Discovered and flagged, yes; configured, no. The rollout surfaces SQL instances, and Arc-enabled SQL Server can add instance-level inventory, best-practice assessment, and licensing options — but SQL-specific enablement and the licensing questions that come with it deserve their own conversation, and bundling them quietly into a server-management project is how scope goes wrong. We include pointers and an honest recommendation in the closeout.

What is this about hotpatching and licensing benefits through Arc?

Microsoft has been routing genuine licensing value through Arc. Windows Server 2025 machines connected via Arc can use hotpatching — most security updates applied without rebooting, cutting patch reboots to a handful of planned events a year — and Microsoft dropped the separate subscription charge for it in mid-2026. There is also a pay-as-you-go licensing option for Windows Server 2025 through Arc, and older servers can buy Extended Security Updates month to month through Arc instead of in annual blocks. Terms are Microsoft's and move over time, so the design phase verifies what applies to your estate at engagement time.

How disruptive is the onboarding to production servers?

Minimally, by design. Installing the Connected Machine agent does not require a reboot and does not touch workloads — it is a lightweight service making outbound connections. The pilot group exists to prove exactly that on your own estate before we scale. The only activities with real change impact are the ones scheduled deliberately: the pilot patch cycle and any enforce-mode policies, both inside maintenance windows you approve.

Who runs all this after the two weeks?

Your team, equipped to do it — the handover session and runbook cover onboarding new servers, reading compliance and patch status, and adjusting schedules, and the taxonomy is documented so the estate stays coherent after we leave. If you would rather have it operated for you, our Azure Resource Monitoring and Maintenance service can take the keys as a separate, explicit engagement — we do not bundle a retainer into an implementation.

Didn’t find your question?

Ask it here. A real engineer answers by email within one business day — and if it’s a good one, it becomes part of this page so the next person finds it.

Answered by a person, one time, to your inbox. Nothing you type here is published without a human reviewing and anonymizing it first.

Often combined with

$25 per server + $1,950 tenant fee
2 weeks
Book an Arc scoping call