Scope & Topology
Azure Local baseline locked by ADR 0001. Hyper-V scope is intentionally not locked until its research program produces a supported topology and successor ADR.
Platform scope
| Platform | Current topology status | Delivery surfaces |
|---|---|---|
| Azure Local | Accepted three-layer infrastructure model documented below | SCOM and Azure Monitor |
| Hyper-V | Research planned for standalone, failover-clustered, and supported SCVMM-managed variants | SCOM committed; Azure Monitor conditional |
The health dimensions and rollup principles can be shared. The Azure Local entity inventory below must not be copied wholesale into the Hyper-V Management Pack: Azure Local lifecycle, DCMA, HCI registration, and Azure Local resource types remain platform-specific. Network ATC is a shared capability for eligible Windows Server 2025 Datacenter clusters; the Hyper-V model must include it when present and distinguish it from manual and SCVMM/SDN-managed networking.
What we monitor for Azure Local
Azure Local infrastructure only — every component that is deployed as part of an Azure Local deployment. Three layers, ~25 entities. Workloads (VMs, AKS pods, applications) are explicitly out of scope and tracked as future companion MPs in the Roadmap.
Three-layer entity model
Layer 1 — On-prem (the cluster box)
| Entity | SCOM class | Base class | Purpose | Source |
|---|---|---|---|---|
| Cluster | AzureLocal.Cluster | Microsoft.Windows.LocalApplication | The Azure Local cluster (S2D + Failover Clustering) | Get-Cluster / Get-ClusterResource |
| Node | AzureLocal.Node | Microsoft.Windows.LocalApplication | Each cluster member node | Get-ClusterNode / WMI |
| Storage Pool | AzureLocal.StoragePool | Microsoft.Windows.ApplicationComponent | The Storage Spaces Direct pool | Get-StoragePool |
| Volume (CSV) | AzureLocal.Volume | Microsoft.Windows.ApplicationComponent | Each cluster shared volume | Get-Volume / Get-ClusterSharedVolume |
| Storage Tier | AzureLocal.StorageTier | Microsoft.Windows.ApplicationComponent | Pool's cache + capacity tiers | Get-StorageTier |
| Physical Disk | AzureLocal.PhysicalDisk | Microsoft.Windows.ApplicationComponent | Each physical disk in the S2D pool — health, media type, usage | Get-PhysicalDisk |
| Network Intent | AzureLocal.NetworkIntent | Microsoft.Windows.ApplicationComponent | Each named Network ATC intent (Mgmt / Compute / Storage) | Get-NetIntent / Get-NetIntentStatus |
| Network Adapter | AzureLocal.NetworkAdapter | Microsoft.Windows.ApplicationComponent | Each physical NIC bound to a Network Intent — link speed, RDMA, PFC/ETS | Get-NetAdapter / Get-NetAdapterRdma |
| Storage Replica | AzureLocal.StorageReplica | Microsoft.Windows.ApplicationComponent | Replication relationship (if configured) | Get-SRPartnership |
| LCM State | AzureLocal.LCMState | Microsoft.Windows.ApplicationComponent | Solution-level update posture | Get-SolutionUpdate (Azure Local LCM) |
Granularity note (updated):
AzureLocal.PhysicalDiskis a hosted class beneathAzureLocal.StoragePool. A disk's health state is its own SCOM object, but it rolls up to the pool via an aggregated health roll-up monitor. SimilarlyAzureLocal.NetworkAdapteris hosted beneathAzureLocal.NetworkIntent; individual NIC failures propagate to the parent intent. All base class choices follow Brian Wren Module 7 — see ADR 0005 for the full inheritance tree.
Layer 2 — Cluster-resident platform services
| Entity | SCOM class | Base class | Purpose | Source |
|---|---|---|---|---|
| Arc Resource Bridge / MOC | AzureLocal.ArcResourceBridge | Microsoft.Windows.LocalApplication | The Resource Bridge VM and its MOC components | az arcappliance / Resource Health |
| AKS Arc platform | AzureLocal.AKSArcPlatform | Microsoft.Windows.ApplicationComponent | AKS platform only (host pool, control plane reachability) | AKS extension status |
| Cloud Agent / DCMA | AzureLocal.DCMA | Microsoft.Windows.ApplicationComponent | Microsoft-supplied management agents — locally observable | Service state + registry + last heartbeat |
| Arc agent (per node) | AzureLocal.Node (attribute group) | (extends Node) | Arc Connected Machine Agent services + extension health — locally observable, no ARM required (see ADR 0011 Tier A) | Get-Service HIMDS, registry, event log |
| HCI registration state | AzureLocal.HCIRegistration | Microsoft.Windows.ApplicationComponent | Registration / billing / license tier | ARM resource state + local registry |
ADR 0011 Tier A signals: Arc agent connectivity and extension health signals are collected on
AzureLocal.Node(not a separate class) using agent-local data sources. See signal-catalog.md — Arc agent locally observable.
Layer 3 — Azure-side infrastructure
| Entity | Purpose | Source |
|---|---|---|
| HCI Cluster resource | Microsoft.AzureStackHCI/clusters | ARM / Resource Graph |
| Arc-enabled Server (per node) | Microsoft.HybridCompute/machines | ARM + Connected Machine Agent |
| Custom Location | The Custom Location Azure resource | ARM |
| Logical Networks | Microsoft.AzureStackHCI/logicalNetworks | ARM |
| Managed Identities | System- + user-assigned MIs used by the deployment | ARM + Microsoft Graph |
| Deployment SPN | The SPN performing deployment / ongoing operations | Microsoft Graph |
| Key Vault | Secrets, access policies, expiry | ARM + Resource Health |
| Storage Account | Account, ACLs, redundancy | ARM + Resource Health |
| RBAC / role assignments | Required role assignments on cluster identity, SPN, MI | ARM Authorization |
| Update Manager linkage | Azure Update Manager linkage for the cluster | ARM |
| Data Collection Rules | DCRs associated with the cluster | ARM |
| Log Analytics Workspace linkage | Workspace reachability + ingestion | ARM + KQL Heartbeat |
| Resource Health / Activity Log | Per-resource health stream | Activity Log stream |
Total: ~27 entities across 3 layers (10 L1, 5 L2, 13 L3 — up from the original ~25 with the addition of AzureLocal.PhysicalDisk, AzureLocal.NetworkAdapter, and the Arc agent Tier A group).
Out of scope (deferred)
These are tracked in the Roadmap as future companion MPs that take a dependency on this health model:
- Guest OS health inside HCI VMs
- Application services running inside VMs
- AKS Arc workload pods, deployments, ingress
- SQL MI / AVD / other workloads
- Customer applications and their dependencies
How tracks consume this scope
| Track | Implementation |
|---|---|
| SCOM MP | One SCOM class per entity. L1+L2 discovered via PowerShell Discovery on each cluster node. L3 discovered via ARM/Resource Graph from a designated management server. See ADR 0004 and ADR 0005. |
| Azure Monitor Health Model | One model entity per entity. L1+L2 surfaced through HCI Insights + DCMA metrics + Resource Health on AzureStackHCI/clusters. L3 surfaced through Resource Health + Activity Log + Resource Graph signals. See ADR 0006. |