MICROSOFT PRODUCT CAPABILITIES
Manage the estate beyond Azure.
Azure Arc extends Azure’s management model to supported resources outside Azure, including on-premises and other cloud environments. It represents those resources in Azure Resource Manager so teams can organise them and apply the management services they need.
Connected server inventory
Connect supported Windows and Linux servers, then organise resources with tags, groups, and Azure role-based access.
Governance and configuration
Apply supported policies, extensions, and configuration controls to connected resources, with access managed through Azure.
Kubernetes management
Connect supported Kubernetes clusters to Azure and use capabilities such as inventory, governance, and GitOps configuration.
Operational services
Connect the required monitoring, update management, and security services so operational teams can manage more of the estate from Azure.
Management without moving the workload
Arc does not automatically migrate or host the connected workload in Azure. Connected agents, supported platforms, outbound connectivity, and the charges for additional Azure services form part of the implementation.
Put it to work with Braintree.
Braintree identifies which resources to connect, configures access and policy, and establishes monitoring and operational ownership across the environments you retain.
Microsoft product guidance
A management layer for the estate you have
Arc adoption starts with resource suitability, connectivity and ownership. Braintree can assess the estate, onboard supported resources and align the resulting management model with your Azure landing zone and operational standards.
✓
Inventory servers, clusters and their existing management tools.
✓
Confirm supported versions, agents and connectivity requirements.
✓
Define policy, monitoring and security baselines.
✓
Assign ongoing ownership for exceptions, patching and changes.
01
Manage a distributed estate without moving every workload
Azure Arc is relevant when servers and services need to remain in different locations but governance has become fragmented. It brings supported non-Azure resources into an Azure management context. Registering a server does not migrate its application or transfer its data into an Azure virtual machine; it creates a managed representation and connects the capabilities you configure.
An illustrative mixed estate could include a local production server, a hosted business application and resources in another cloud. The practical objective is a consistent record of ownership, configuration and monitoring. The location can remain different while the operating team uses common standards for the supported parts of the estate.
02
Separate Arc onboarding from the services you add
Microsoft documents Arc-enabled servers using the Connected Machine agent. Each connected machine has an Azure resource identity and can participate in management services. Azure Monitor, Update Manager, Defender for Cloud and Sentinel can contribute different monitoring, update and security functions. Their configuration, permissions and commercial scope remain separate decisions.
Kubernetes and data-service requirements need their own Arc assessment. A server registration is not proof that every Arc capability is supported on that operating system, architecture or cluster. The proposal should name the resource types and the services enabled for them, rather than promising one identical feature set across all infrastructure.
03
Connectivity and compatibility are design inputs
The Connected Machine agent has supported operating-system and architecture requirements. Microsoft also identifies workload boundaries: ordinary end-user productivity laptops that are frequently offline are not the intended Arc server-management scenario, and short-lived infrastructure introduces management complications. Those environments may be better served by endpoint or platform-native tooling.
Onboarding needs appropriate Azure permissions, registered resource providers and a suitable resource structure. Network access and any private-connectivity approach must be designed before rollout. The region selected for management metadata also deserves review; leaving a workload locally does not mean that no information about it is processed by the management service.
04
A useful Arc pilot proves the operating model
Braintree can assess the estate, select representative resources and configure the agreed policy, monitoring and security scope. The pilot should demonstrate what happens when a resource disconnects, fails a policy check or needs an update, including which team acts on that information.
Inventory supported resource types, versions, ownership and management gaps.
Agree Azure subscription, resource-group, region and access-role structure.
Confirm agent deployment, network requirements and the services to enable.
Test policy findings, monitoring, updates and exception ownership with representative systems.
BEFORE YOU DECIDE
