One of the promises of hybrid cloud is consistent management. Resources in the public cloud, datacentre and edge should be visible and controllable through a shared platform.

In practice, Azure Local administrators still work with several management tools.

The Azure portal, Azure Arc, Windows Admin Center, PowerShell, Hyper-V Manager and Failover Cluster Manager all have a role. The challenge is not finding a tool that can perform a task. It is knowing which tool should be used as the primary management layer.

Without that clarity, hybrid management can quickly become another collection of consoles.

The Azure portal as the central control plane

For most day-to-day Azure Local operations, the Azure portal is becoming the primary starting point.

Through Azure Arc, administrators can view and manage Azure Local resources alongside public Azure resources. The portal can be used for areas including:

• infrastructure monitoring;
• Arc-enabled virtual machine management;
• access control and policy;
• updates;
• Azure Virtual Desktop;
• Kubernetes workloads;
• security and compliance services;
• cost and subscription information.

This is particularly valuable for organisations that already use Azure. Teams do not need a completely separate governance model for local infrastructure. Microsoft provides a more detailed overview of Azure Arc-enabled virtual machine management for Azure Local. 

However, the portal does not replace every local administration tool.

Windows Admin Center for detailed Windows management

Windows Admin Center provides browser-based management for Windows Servers, clusters, storage and virtual machines. It is useful when administrators need more detailed access to the local Windows environment or functionality that is not yet available through the Azure Arc control plane. Examples include certain storage operations, non-Arc virtual machines and lower-level server configuration. The important distinction is that Windows Admin Center should complement the Azure portal, not become a parallel management strategy. Where possible, workloads should be created and managed through Azure Arc. This keeps them visible within the central governance and monitoring model.

PowerShell for automation and advanced administration

Graphical interfaces are useful for individual tasks. They become less efficient when the same action needs to be performed across many clusters, nodes or virtual machines.

PowerShell remains essential for:

• repeatable deployments;
• bulk configuration changes;
• diagnostics;
• scripted health checks;
• advanced cluster operations;
• integration with internal automation.

A mature Azure Local operating model should therefore not depend entirely on manual portal administration. Standard tasks should be automated where possible, documented and tested before they are used in production.

Traditional tools still have a role

Hyper-V Manager and Failover Cluster Manager are familiar tools for many Windows infrastructure administrators. They remain useful for specific local tasks, troubleshooting and direct access to cluster or virtualisation functions. However, using them as the default interface can bypass the broader benefits of Azure Arc. Resources created or managed only through traditional tools may have limited visibility and fewer Azure management capabilities. The same applies to Microsoft Management Console snap-ins. They are useful instruments, but they are not a hybrid cloud control plane.

A practical management hierarchy

For most Azure Local environments, we recommend the following hierarchy:

1. Azure portal and Azure Arc

Use these for central governance, monitoring, policy, updates and management of hybrid workloads.

2. Windows Admin Center

Use this for Windows-specific tasks and functionality that is not yet available through Azure Arc.

3. PowerShell and automation

Use these for repeatable administration, deployment, bulk changes and advanced operations. Microsoft’s Azure Local documentation provides current commands and deployment guidance. 

4. Hyper-V Manager and Failover Cluster Manager

Use these selectively for direct host, virtual machine or cluster troubleshooting.

This hierarchy helps prevent every tool from becoming equally important.

Technology is only half of management

The correct tools do not automatically create a manageable platform.

Organisations also need to define:

• which team owns the cluster;
• who manages Azure subscriptions and policies;
• how access is granted;
• how updates are tested and scheduled;
• how alerts are handled;
• when local tools may be used;
• how configuration changes are documented;
• how support is escalated between partners.

Without these agreements, a single pane of glass can still hide fragmented responsibility.

DataON tooling and lifecycle integration

DataON systems include a Solution Builder Extension for Azure Local. This allows validated hardware updates and platform updates to be coordinated as part of the Azure Local lifecycle.

That integration is important. Updating the operating system without aligning firmware and drivers can introduce unnecessary risk.

A validated update package reduces that risk, but organisations still need an update strategy, maintenance windows and recovery procedures.

How XCES keeps Azure Local manageable

At XCES, we do not treat management as something that starts after deployment.

We design the operational model together with the infrastructure. That includes Azure Arc, monitoring, role-based access, update management, backup, escalation procedures and ongoing support.

As DataON’s European preferred partner, we combine DataON’s hardware and lifecycle integration with local implementation and managed services.

The objective is not to remove every management tool. It is to ensure that each tool has a clear purpose and that the organisation retains control over the complete environment.