★ First page of Microsoft's 100,000-partner directory, sorted by responsiveness✓ Microsoft Solutions Partner — Security, Modern Work, Infrastructure, App Innovation, Data & AI● Microsoft partner since 2006◆ 1,100+ organizations under management
Home/Services/Azure Infrastructure and Server Modernization/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 SotnikAzure ArcAzure policyDefender for CloudWindows 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. Sometimes the reason is a checklist rather than an engineering preference. A parent company, an acquirer or an insurer writes "central management of all servers" as a row on a security questionnaire, and the evidence they expect is an inventory, a patch-compliance view and access control for every server in one place, plus a change record they can audit. Arc with Azure Update Manager meets that row without moving a workload, and the pieces they ask for — read-only access for the parent group's team, maintenance windows that match your after-hours schedule, the paid add-ons left switched off until someone asks for them — are configuration, not projects. Where the date is set by someone else and the server count is a dozen or two, the narrower fixed-fee version of this work is the Azure Arc Onboarding with Azure Update Manager for an Audited Estate: one subscription, up to 25 servers, maintenance windows configured, a change record and a hand-over document in one week. How to meet the checklist and what the change record looks like is in Central management of all servers as an audit requirement.

Which one applies to you

What Microsoft charges for on an Arc-enabled server and what it does not, in the rules rather than the numbers — the rows the design-phase cost model starts from. Microsoft revises these terms; the model carries the current prices, this table carries the conditions.

Microsoft chargeCondition
Azure Arc control plane — the resource, tags, Resource Graph search, Azure RBAC, templates and extensionsNo extra costNone beyond your Azure subscription, per Microsoft's Azure Arc overview. This is the inventory layer.
Windows Server Management enabled by Azure Arc — Azure Update Manager, Change Tracking and Inventory, Azure Machine Configuration, Windows Admin Center in Azure, Remote Support, Best Practices Assessment, Azure Site Recovery configuration, Network HUD on Windows Server 2025No extra cost beyond networking, storage and log ingestionActive Software Assurance or Windows Server subscription licenses, attested per server in Azure; Connected Machine agent 1.47 or later and a Connected status. Microsoft states eligibility is not inferred from the Arc connection itself.
Azure Update ManagerIncluded, or metered per serverIncluded for servers covered by that attestation or enrolled in Extended Security Updates through Arc; otherwise purchasable for Arc-enabled servers and metered by Microsoft per server.
Extended Security Updates through Arc — Windows Server 2016 billing from 13 January 2027Metered monthly per coreStandard or Datacenter, physical or virtual cores, with a 16-core physical and 8-core virtual minimum; Software Assurance or an equivalent subscription attested. Enrolled servers get Azure Update Manager, Change Tracking and Inventory and Azure Policy guest configuration at no additional charge.
Hotpatch for Windows Server 2025No additional charge since 19 May 2026Arc-connected Windows Server 2025 Standard or Datacenter with Virtualization-Based Security enabled (Microsoft's prerequisite at the time of writing); Microsoft removed the hotpatch subscription charge on 19 May 2026 per our deadlines register.
Microsoft Defender for ServersChargedPer the Microsoft Defender for Cloud price list, per server, billed by Microsoft to your subscription; it is not on the Software Assurance benefits list.
Log Analytics ingestion — Change Tracking and Inventory, Best Practices Assessment, VM insights, Azure Monitor logs, Microsoft SentinelChargedData ingestion and retention at the workspace's pricing, even where the feature itself is included; the meter most likely to surprise.

Every meter in this table is Microsoft's charge on your Azure invoice and is not part of this fee; the cost model in the design phase prices each one for your estate before it is enabled.

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.
✓Outbound endpoint list for your firewall team: the Azure Arc, Azure Update Manager and Microsoft Update endpoints and ports the Connected Machine agent and the services in scope need over outbound HTTPS, taken from Microsoft's current network requirements at design time, with the proxy, Azure Arc gateway or Private Link path per network segment — so the allow-list is a change request your network team applies before the pilot, not a discovery during it.
✓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.
✓Maintenance configurations per time zone, in local time, with pre- and post-events (the checks before and after each run, raised through Event Grid) and dynamic scopes by tag so a server joins the right window the day it is onboarded — with baseline months (a full cumulative update, restart) and hotpatch months (security fixes applied to running code, no restart) distinguished for Windows Server 2025 machines, as laid out in the hotpatch restart calendar for Windows Server 2025.
✓Per Windows Server 2025 server: a virtualization-based security check (VBS running, which needs UEFI with Secure Boot or a generation 2 virtual machine) and the hotpatch enrollment through Azure Arc where the check passes, recorded per server; a server that fails the check is listed with what it would take to qualify rather than changed silently.
✓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. A hotpatched server still restarts in every baseline month — one planned baseline every three months, plus any unplanned one — which is why the maintenance configurations distinguish baseline months from hotpatch months; the calendar and the window layout are in the hotpatch restart calendar for Windows Server 2025.

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.

Related services

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