Settings and patching are the headline capabilities, but they are not what running an Arc server actually feels like day to day. That experience is made of three things: the extensions that add capability, the monitoring that tells you what is happening, and the remote access that lets you reach a server without a jump box. Each of them is genuinely good, and each carries an edge that will surprise you if you meet it in production instead of reading about it here. The operations surface is where Arc stops being an onboarding story and becomes a way of working.
Feature status, checked July 2026
Several capabilities in this article are moving, and a doctrine article that does not date its claims ages badly. This is where each one stood when this was last checked, and it is worth re-checking before you commit a runbook to any of them.
| Capability | Status, July 2026 | What that means for you |
|---|---|---|
| Run Command for Arc-enabled servers | Public preview | Driven from the command line and REST, with no portal path, so do not build a runbook that assumes portal parity or a stable interface |
| Windows Admin Center in the Azure portal for Arc | Public preview | A real console with no inbound port, but preview terms apply and it replaces any Windows Admin Center instance already installed on the machine |
| Connected Machine agent automatic upgrade | Public preview | Agent 1.57 and later, Azure public cloud only. Automatic upgrade of extensions is a separate and generally available thing; do not conflate them |
| Windows Server 2025 Entra sign-in for Arc | Generally available | Generally available and still constrained: Conditional Access is not supported for it, and enabling it makes the server Entra joined, which excludes Active Directory domain join |
| Machine configuration and Update Manager metering, and the licensing waivers | Rates and rules checked July 2026 | Prices and waiver eligibility both move. Re-check before you quote a figure to anyone who will budget from it |
Extensions, and the version drift you should expect
Extensions are how Arc grows past management into capability: the monitoring agent, the Defender sensor, the Key Vault integration, Windows Admin Center, Entra sign-in, and more all arrive as extensions the manager installs. Most of them support automatic upgrade, and it is on by default, which is the right choice and also the source of a fact worth internalizing. Publisher rollouts are staged, and a new extension version can take weeks to reach every machine in your fleet, with the most urgent security releases moving faster but nothing arriving everywhere at once. The practical consequence is that version heterogeneity across your Arc estate is the normal state, not a fault to chase. If your operational model assumes every server runs the same extension build on the same day, it is wrong in a way that will generate false alarms. Design your monitoring and your change control to tolerate a spread of versions, because the platform guarantees you one.
The other thing to notice about extensions is that they are the capability side of the authority conversation from the onboarding article. Every extension the manager can install is code running as the machine’s most privileged account, which is exactly why the local allowlist exists and exactly why deciding what may be installed is a security decision rather than a convenience one. Capability and blast radius are the same surface viewed from two sides.
Monitoring costs what you collect
Monitoring an Arc server is the Azure Monitor agent plus data collection rules, and the model is clean: the rules define what is gathered and where it goes, and you scope them like any other governed thing. But there is a cost shape here that catches people who are used to Azure virtual machines. An Azure VM gives you host-level metrics for free because Azure owns the hypervisor and can see the machine from outside. Arc does not give you the native hypervisor metrics an Azure virtual machine gets for free, because there is no hypervisor Azure owns to read the machine from outside. The guest logs, custom counters, and security events you collect through the Azure Monitor Agent and a data collection rule can carry ingestion and retention charges, so design the rule around the data you will actually use. Some platform records and standard Azure Monitor capabilities do not carry an ingestion charge, and a preview guest-metrics path exists, so the discipline is to be deliberate about ingestion rather than to assume every signal is billable. That is not a reason to under-monitor. Decide what you actually need to see, collect that, and treat a firehose data collection rule as a line item rather than a default, because on this platform that is what it is.
One specific caution, because it is a trap with a clock on it. The dependency mapping and the visual service map that older Azure monitoring guidance leans on are being retired on June 30, 2028, and the portal path to onboard new machines to them closed back in September 2025, though other onboarding methods linger until the end. Do not architect your Arc monitoring around dependency maps; they are a dead end on a published timer. Build on the current agent-and-rules model and the direction Microsoft is actually investing in, not on a feature you will have to migrate off of before you have finished rolling it out.
Reaching the server without a jump box
The remote access story is the one that changes how it feels to operate these machines, because it begins to retire the jump box. SSH through Arc tunnels a session to the server over the agent’s existing outbound connection, with no public IP and no inbound port opened, which is a genuinely better security posture than the bastion-and-firewall dance it replaces. But Arc supplies the transport, and the authentication method still decides what governs the session. A session that authenticates with a local account, whether SSH or an RDP tunnel, gains nothing from Conditional Access simply because it traveled through Arc. A Linux server can instead authenticate with Entra ID, and that path does carry Azure role-based access control and Conditional Access, including multifactor and device checks. Windows Server 2025 can authenticate Windows sign-in with Entra ID as well, but Conditional Access is not currently supported for it, and enabling that capability makes the server Entra joined, which means it can no longer be joined to Active Directory or Entra Domain Services. So the jump box goes away, which is good, but the identity perimeter around the session is not one thing, it is three, and a security review will and should ask which of the three a given server is actually using. The Windows Server 2025 case carries the sharpest edge, because the domain-join exclusion is an architectural commitment dressed as a sign-in option.
SSH through Arc removes the jump box and the inbound port. What governs the session after that is decided by the authentication method, not by Arc, and the three paths do not govern alike.
Two more remote capabilities are worth knowing about with their status attached. Run Command executes a script on the server through the agent, and Windows Admin Center gives you a full management console in the browser without a local credential, and both are genuinely useful, but both are still preview features as of the status box above, and Run Command is command-line rather than portal. Use them, but do not build a runbook that assumes they are generally available and unchanging, because they are neither yet.
The code paths, and the control that answers them
Step back and notice what Run Command and the Custom Script extension actually are: a way for someone with the right role in Azure to run arbitrary code as SYSTEM or root on any connected server, unaudited by default because they are not designed as an auditing surface. That is enormous power, and it is the reason the agent’s local blocklist matters. On a server where that reach is unacceptable, you block those specific capabilities in the agent’s own configuration, where no cloud role can override the decision. This is the operations-surface expression of the whole platform’s authority split: the cloud grants the ability to run code, and the machine keeps the ability to refuse it. Use the refusal deliberately on the servers that warrant it, and enforce it through configuration management so it does not quietly lapse.
Where we turn next
Extensions, monitoring, and remote access are what make an Arc server something you can actually run, edges and all. With the management and operations surface now covered end to end, the series turns to the reason many organizations adopt Arc in the first place, which is not management at all but money: Extended Security Updates, pay-as-you-go licensing, and the waiver matrix that decides what any of this costs. The dates there are close and the rules are specific, and that is the next article.
Azure Arc
‹ Previous: [ARC 4.1] Build Sheet: Update Manager End to End
Next: [ARC 5.1] Build Sheet: Operating an Arc Server ›
