Hyper-V SCOM Management Pack design
This is the active first delivery lane. The Management Pack and platform-owned Distributed Application are committed; implementation remains gated by topology, signal, threshold, workflow, and lab evidence.
Design map
| Design contract | Purpose |
|---|---|
| End-to-end architecture | Requirements, topology variants, runtime planes, data flow, and non-functional requirements |
| Management Pack structure | Proposed sealed artifacts, dependencies, override boundary, and release bundle |
| Override and tuning architecture | Separate customer Discovery/Monitoring overrides, public profile templates, parameters, targeting, and lifecycle |
| Class and relationship model | Stable identity, hosting, containment, reference relationships, and VM mobility |
| Discovery and workflow architecture | Staged discovery, source selection, execution placement, cookdown, monitors, rules, and tasks |
| Health and alert architecture | Health dimensions, thresholds, state, alerting, suppression, expected state, and rollup |
| Distributed Application | Cluster/standalone service roots, dynamic membership, branches, rollup, and operator surfaces |
| Authoring standards | IDs, display strings, knowledge, overrides, modules, scripts, and definition of done |
| Security and operability | Least privilege, Run As, task safety, monitoring-pipeline health, and diagnostics |
| Validation and release | Static, fixture, lab, fault, scale, lifecycle, signing, and publishing gates |
Proposed architecture decisions
| ADR | Decision | Status and gate |
|---|---|---|
| 0027 | Modular sealed artifacts, separate customer Discovery/Monitoring overrides, and optional tuning templates | Proposed; evidence required |
| 0028 | Stable boundary identity, mobile VM model, staged discovery, execution placement, and cookdown | Proposed; evidence required |
| 0029 | Evidence-driven health, actionable alerts, topology-aware rollup, and monitoring-pipeline branch | Proposed; evidence required |
| 0031 | Tool-neutral XML/fragments, PowerShell build checks, Microsoft verification/sealing, and lab authority | Proposed; build-environment proof required |
These refine accepted ADRs 0022, 0025, and 0026. They do not change the independent product boundary.
Current design baseline
| Concern | Current authority |
|---|---|
| Support matrix and topology | Support and topology research |
| Raw Windows Server, Hyper-V, cluster, storage, and network inventories | Signal inventory research |
| Prior Microsoft MP research | Reference analysis only; no dependency |
| SCOM workflow mapping | Workflow research |
| Threshold and tuning policy | Threshold engineering |
| Lab and fault validation | Lab evidence |
| Curated default catalog | Catalog synthesis |
| DA classes and membership | DA design validation |
| DA rollups and operator surfaces | DA behavior validation |
| Architecture validation and ADR resolution | Architecture evidence review |
Authoring boundary
The Microsoft Hyper-V 2019 MP is research evidence only. The new product does not import, extend, override, require, or take a runtime dependency on it. The same prohibition applies to Azure Local MPs. Approved Microsoft System, Windows Server, and Failover Cluster libraries can be referenced when the support and compatibility matrix explicitly identifies them.
The design follows current Microsoft guidance for MP contents, separate overrides, Run As assignment, pre-production lifecycle validation, Distributed Applications, and service-level objectives. Detailed legacy authoring concepts remain useful only when revalidated against the supported SCOM releases.