VMs with boot diagnostics disabled in the ARM diagnostics profile
What does ZopNight detect here?
Boot diagnostics captures the serial console log and a boot screenshot, the only visibility into an Azure VM that hangs before SSH or RDP comes up. RC-1305 fires when Azure Resource Graph reports diagnosticsProfile.bootDiagnostics.enabled as false; guest-level Azure Monitor Agent coverage is deliberately outside this check's scope.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1305 |
| Category | compliance |
| Severity | low |
| Metric | none — pure configuration read |
| Source | vm_diagnostic.go |
Where it applies
Debugging a VM that never answers
Kernel panic mid-boot, a bad fstab entry, an interrupted OS update: failures like these kill a VM before any network service starts, so SSH and RDP tell you nothing. Boot diagnostics is the escape hatch: Azure streams the serial console output and captures a boot-time screenshot, which is usually enough to read the panic message or spot the prompt the boot is stuck at. With it disabled, the realistic fallback is detaching the OS disk and mounting it on a rescue VM, which turns a ten-minute diagnosis into an hour of surgery.
The exact field behind the finding
Azure Resource Graph exposes each VM’s diagnosticsProfile.bootDiagnostics.enabled, and the
discoverer copies it into metadata as boot_diagnostics_enabled. The rule fires only on the
explicit string "false" and abstains when the key is absent. History matters here: a prior
implementation read a diagnostics customer tag that no producer ever emitted, meaning the
rule could never fire on real data. The ARM-field rewrite is what connected it to reality.
Scope: boot telemetry only
Guest-level diagnostics (performance counters, syslog, event logs collected by the Azure Monitor Agent) is a different control with a different rule. A VM can pass this check with no AMA installed, and fail it while fully onboarded to Log Analytics. Keep the two findings separate when triaging: this one costs nothing to fix and has no data-volume implications.
Confirm from the CLI
az vm show -g <rg> -n <vm> \ --query "diagnosticsProfile.bootDiagnostics.{enabled:enabled, storage:storageUri}"Enabling it the modern way
az vm boot-diagnostics enable --name <vm> --resource-group <rg> with no storage URI uses a
platform-managed storage account, which is the low-friction default since the 2020-era managed
boot diagnostics rollout. Note the remediation trap on older guidance: the legacy
guest-diagnostics path through the Azure Diagnostics extension was retired on 2026-03-31, so
follow-up guest monitoring should go through AMA and a Data Collection Rule instead. Reader
alone reproduces this detection; severity is low because the fix is one idempotent command.