Microsoft limits its recommendation for 4K hardware-hash registration through Intune to testing or other limited uses. The import checks the assigned user’s domain, not whether the individual UPN identifies the intended existing user. An invalid assignment can make the device inaccessible until that assignment is removed. Microsoft also requires the CSV to be edited as plain text rather than saved with Excel. Microsoft Learn.
\nUse this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.
\nKeep the hardware-hash file in a restricted working location. Have a second operator compare each proposed user assignment with the authoritative account record and approved device allocation. Review the complete file against the source’s formatting requirements after editing. Begin with a small, explicitly identified set and keep a record of which rows were submitted.
\nInspect the resulting Autopilot entries and compare serial numbers and user assignments with the approved input. Test the intended sign-in on a designated pilot device before releasing the remainder. If an unexpected assignment appears, stop further imports and have the enrollment owner correct that specific record. Preserve sanitized validation results, not hardware hashes in ordinary support tickets.
\nMicrosoft Learn: Manually Register Devices with Windows Autopilot.
", "content_text": "Source facts\nMicrosoft limits its recommendation for 4K hardware-hash registration through Intune to testing or other limited uses. The import checks the assigned user’s domain, not whether the individual UPN identifies the intended existing user. An invalid assignment can make the device inaccessible until that assignment is removed. Microsoft also requires the CSV to be edited as plain text rather than saved with Excel. Microsoft Learn.\nApplicability\nUse this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.\nDSE recommendation\nKeep the hardware-hash file in a restricted working location. Have a second operator compare each proposed user assignment with the authoritative account record and approved device allocation. Review the complete file against the source’s formatting requirements after editing. Begin with a small, explicitly identified set and keep a record of which rows were submitted.\nVerification\nInspect the resulting Autopilot entries and compare serial numbers and user assignments with the approved input. Test the intended sign-in on a designated pilot device before releasing the remainder. If an unexpected assignment appears, stop further imports and have the enrollment owner correct that specific record. Preserve sanitized validation results, not hardware hashes in ordinary support tickets.\nOfficial references\nMicrosoft Learn: Manually Register Devices with Windows Autopilot.", "content_markdown": "## Source facts\n\nMicrosoft limits its recommendation for 4K hardware-hash registration through Intune to testing or other limited uses. The import checks the assigned user’s domain, not whether the individual UPN identifies the intended existing user. An invalid assignment can make the device inaccessible until that assignment is removed. Microsoft also requires the CSV to be edited as plain text rather than saved with Excel. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/add-devices).\n\n## Applicability\n\nUse this review for an approved limited manual-registration exercise. Identify the devices, intended tenant, account assignments, and person responsible for the import before collecting their hardware hashes.\n\n## DSE recommendation\n\nKeep the hardware-hash file in a restricted working location. Have a second operator compare each proposed user assignment with the authoritative account record and approved device allocation. Review the complete file against the source’s formatting requirements after editing. Begin with a small, explicitly identified set and keep a record of which rows were submitted.\n\n## Verification\n\nInspect the resulting Autopilot entries and compare serial numbers and user assignments with the approved input. Test the intended sign-in on a designated pilot device before releasing the remainder. If an unexpected assignment appears, stop further imports and have the enrollment owner correct that specific record. Preserve sanitized validation results, not hardware hashes in ordinary support tickets.\n\n## Official references\n\n[Microsoft Learn: Manually Register Devices with Windows Autopilot](https://learn.microsoft.com/en-us/autopilot/add-devices)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair/", "slug": "dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair", "url": "https://update.dsesecurity.com/updates/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-002-plan-the-autopilot-identity-handoff-before-motherboard-repair/" }, "title": "Plan the Autopilot identity handoff before motherboard repair", "summary": "Who will restore the repaired device’s Autopilot identity before it returns to its user?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "identity-cloud", "label": "Identity & cloud", "alt": "Governed cloud identity system with connected service and lifecycle nodes.", "card_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/identity-cloud-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:54+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 233, "potentially_affected": "Use this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.", "dse_recommendation": "Agree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment.", "primary_source": { "name": "Windows Autopilot motherboard replacement | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/autopilot-motherboard-replacement", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft recommends deregistering an Autopilot device before motherboard replacement, then capturing a new hardware hash, registering the repaired device again, and returning it to its out-of-box state. A repaired device registered through Partner Center needs its new 4K hardware hash; a product key identifier or serial/manufacturer/model tuple is insufficient. Microsoft also warns that motherboard-repair scenarios often lose data. Microsoft Learn.
\nUse this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.
\nAgree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment. Protect required user data through the approved recovery process. Record who will handle deregistration, verify the repaired firmware information, capture the replacement identity, and confirm registration. Give the facility the approved operating-system requirement and a clear return-state acceptance record, without supplying user passwords.
\nBefore returning the device to normal use, reconcile the repaired physical unit with the newly registered identity and intended tenant. Check that the unit reaches the expected out-of-box experience rather than an inaccessible previous installation. Perform an authorized enrollment and sign-in test. Hold the return if the tenant, hardware identity, or repair evidence is inconsistent, and route the discrepancy to the responsible registration owner.
\nMicrosoft Learn: Windows Autopilot motherboard replacement.
", "content_text": "Source facts\nMicrosoft recommends deregistering an Autopilot device before motherboard replacement, then capturing a new hardware hash, registering the repaired device again, and returning it to its out-of-box state. A repaired device registered through Partner Center needs its new 4K hardware hash; a product key identifier or serial/manufacturer/model tuple is insufficient. Microsoft also warns that motherboard-repair scenarios often lose data. Microsoft Learn.\nApplicability\nUse this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.\nDSE recommendation\nAgree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment. Protect required user data through the approved recovery process. Record who will handle deregistration, verify the repaired firmware information, capture the replacement identity, and confirm registration. Give the facility the approved operating-system requirement and a clear return-state acceptance record, without supplying user passwords.\nVerification\nBefore returning the device to normal use, reconcile the repaired physical unit with the newly registered identity and intended tenant. Check that the unit reaches the expected out-of-box experience rather than an inaccessible previous installation. Perform an authorized enrollment and sign-in test. Hold the return if the tenant, hardware identity, or repair evidence is inconsistent, and route the discrepancy to the responsible registration owner.\nOfficial references\nMicrosoft Learn: Windows Autopilot motherboard replacement.", "content_markdown": "## Source facts\n\nMicrosoft recommends deregistering an Autopilot device before motherboard replacement, then capturing a new hardware hash, registering the repaired device again, and returning it to its out-of-box state. A repaired device registered through Partner Center needs its new 4K hardware hash; a product key identifier or serial/manufacturer/model tuple is insufficient. Microsoft also warns that motherboard-repair scenarios often lose data. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/autopilot-motherboard-replacement).\n\n## Applicability\n\nUse this review for a motherboard repair on an Autopilot-registered device. Match the specific hardware scenario to the source’s supported repair guidance; do not assume that every combination of reused components behaves alike.\n\n## DSE recommendation\n\nAgree on the handoff between the original registration owner, repair facility, and receiving administrator before shipment. Protect required user data through the approved recovery process. Record who will handle deregistration, verify the repaired firmware information, capture the replacement identity, and confirm registration. Give the facility the approved operating-system requirement and a clear return-state acceptance record, without supplying user passwords.\n\n## Verification\n\nBefore returning the device to normal use, reconcile the repaired physical unit with the newly registered identity and intended tenant. Check that the unit reaches the expected out-of-box experience rather than an inaccessible previous installation. Perform an authorized enrollment and sign-in test. Hold the return if the tenant, hardware identity, or repair evidence is inconsistent, and route the discrepancy to the responsible registration owner.\n\n## Official references\n\n[Microsoft Learn: Windows Autopilot motherboard replacement](https://learn.microsoft.com/en-us/autopilot/autopilot-motherboard-replacement)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-003-check-procurement-registration-before-promising-dfci-management/", "slug": "dse-20260909-003-check-procurement-registration-before-promising-dfci-management", "url": "https://update.dsesecurity.com/updates/dse-20260909-003-check-procurement-registration-before-promising-dfci-management/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-003-check-procurement-registration-before-promising-dfci-management.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-003-check-procurement-registration-before-promising-dfci-management/" }, "title": "Check procurement registration before promising DFCI management", "summary": "Does the device’s firmware and registration history make it eligible for DFCI?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:53+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 231, "potentially_affected": "Use this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.", "dse_recommendation": "Ask procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory.", "primary_source": { "name": "DFCI Management | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/dfci-management", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "DFCI lets Intune manage firmware settings on supported Autopilot devices. Microsoft requires compatible manufacturer firmware and registration performed by the OEM or a Cloud Solution Provider partner. Devices registered manually with a CSV are excluded because the feature requires external evidence of commercial acquisition. The source also documents an out-of-box enrollment restriction for Windows 11 version 24H2 Professional editions, with a separate updated-device path after provisioning. Microsoft Learn.
\nUse this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.
\nAsk procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory. Obtain the manufacturer’s supported firmware guidance for the selected models. Review the source’s edition-specific exception before planning out-of-box enforcement. Treat a missing eligibility record as a question to resolve with the supplier, not as permission to repeat a manual import.
\nUse a representative eligible device to inspect DFCI readiness and the resulting management state after the approved provisioning path. Confirm that a selected firmware setting behaves as intended under the agreed test conditions. Keep hardware, registration, and operating-system evidence together so an enrollment failure can be assigned to the correct owner. Do not expand the purchase or deployment assumption to unverified models.
\nMicrosoft Learn: DFCI Management.
", "content_text": "Source facts\nDFCI lets Intune manage firmware settings on supported Autopilot devices. Microsoft requires compatible manufacturer firmware and registration performed by the OEM or a Cloud Solution Provider partner. Devices registered manually with a CSV are excluded because the feature requires external evidence of commercial acquisition. The source also documents an out-of-box enrollment restriction for Windows 11 version 24H2 Professional editions, with a separate updated-device path after provisioning. Microsoft Learn.\nApplicability\nUse this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.\nDSE recommendation\nAsk procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory. Obtain the manufacturer’s supported firmware guidance for the selected models. Review the source’s edition-specific exception before planning out-of-box enforcement. Treat a missing eligibility record as a question to resolve with the supplier, not as permission to repeat a manual import.\nVerification\nUse a representative eligible device to inspect DFCI readiness and the resulting management state after the approved provisioning path. Confirm that a selected firmware setting behaves as intended under the agreed test conditions. Keep hardware, registration, and operating-system evidence together so an enrollment failure can be assigned to the correct owner. Do not expand the purchase or deployment assumption to unverified models.\nOfficial references\nMicrosoft Learn: DFCI Management.", "content_markdown": "## Source facts\n\nDFCI lets Intune manage firmware settings on supported Autopilot devices. Microsoft requires compatible manufacturer firmware and registration performed by the OEM or a Cloud Solution Provider partner. Devices registered manually with a CSV are excluded because the feature requires external evidence of commercial acquisition. The source also documents an out-of-box enrollment restriction for Windows 11 version 24H2 Professional editions, with a separate updated-device path after provisioning. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/dfci-management).\n\n## Applicability\n\nUse this review before committing a hardware population to DFCI. Identify its manufacturer, firmware revision, Windows edition and build, and the organization that registered each device.\n\n## DSE recommendation\n\nAsk procurement and the supplier to document the registration route, then have endpoint administrators reconcile that evidence with the actual device inventory. Obtain the manufacturer’s supported firmware guidance for the selected models. Review the source’s edition-specific exception before planning out-of-box enforcement. Treat a missing eligibility record as a question to resolve with the supplier, not as permission to repeat a manual import.\n\n## Verification\n\nUse a representative eligible device to inspect DFCI readiness and the resulting management state after the approved provisioning path. Confirm that a selected firmware setting behaves as intended under the agreed test conditions. Keep hardware, registration, and operating-system evidence together so an enrollment failure can be assigned to the correct owner. Do not expand the purchase or deployment assumption to unverified models.\n\n## Official references\n\n[Microsoft Learn: DFCI Management](https://learn.microsoft.com/en-us/autopilot/dfci-management)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset/", "slug": "dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset", "url": "https://update.dsesecurity.com/updates/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-004-check-device-ownership-after-a-local-or-remote-autopilot-reset/" }, "title": "Check device ownership after a local or remote Autopilot Reset", "summary": "Will the primary-user and device-owner records match the intended reassignment after Autopilot Reset?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:52+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 235, "potentially_affected": "Use this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.", "dse_recommendation": "Record the intended post-reset ownership before authorizing an action that removes user material.", "primary_source": { "name": "Windows Autopilot Reset | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Autopilot Reset removes personal files, applications, and settings while retaining the connections to Entra ID and Intune. A local reset leaves the primary user and Entra device owner unchanged. A remote reset removes those associations and assigns the next signing-in user; shared devices remain shared. Microsoft requires a working Windows Recovery Environment and excludes hybrid-joined devices and Surface Hub from this reset method. Microsoft Learn.
\nUse this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.
\nRecord the intended post-reset ownership before authorizing an action that removes user material. Arrange protection of required data and verify the recovery-environment prerequisite through the approved support process. For a local reset, include an explicit administrator review of the unchanged ownership records. For a remote reset, coordinate which authorized person should complete the next sign-in. Keep shared-device intent visible in the handoff.
\nAfter the reset completes, inspect both the Intune primary-user record and the Entra device owner against the handoff plan. Confirm the expected management connection and perform the agreed user or shared-device workflow. Do not close the reassignment merely because the desktop opens. Resolve an unexpected owner before issuing the device, and retain identifiers and observed outcomes without copying credentials into the record.
\nMicrosoft Learn: Windows Autopilot Reset.
", "content_text": "Source facts\nAutopilot Reset removes personal files, applications, and settings while retaining the connections to Entra ID and Intune. A local reset leaves the primary user and Entra device owner unchanged. A remote reset removes those associations and assigns the next signing-in user; shared devices remain shared. Microsoft requires a working Windows Recovery Environment and excludes hybrid-joined devices and Surface Hub from this reset method. Microsoft Learn.\nApplicability\nUse this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.\nDSE recommendation\nRecord the intended post-reset ownership before authorizing an action that removes user material. Arrange protection of required data and verify the recovery-environment prerequisite through the approved support process. For a local reset, include an explicit administrator review of the unchanged ownership records. For a remote reset, coordinate which authorized person should complete the next sign-in. Keep shared-device intent visible in the handoff.\nVerification\nAfter the reset completes, inspect both the Intune primary-user record and the Entra device owner against the handoff plan. Confirm the expected management connection and perform the agreed user or shared-device workflow. Do not close the reassignment merely because the desktop opens. Resolve an unexpected owner before issuing the device, and retain identifiers and observed outcomes without copying credentials into the record.\nOfficial references\nMicrosoft Learn: Windows Autopilot Reset.", "content_markdown": "## Source facts\n\nAutopilot Reset removes personal files, applications, and settings while retaining the connections to Entra ID and Intune. A local reset leaves the primary user and Entra device owner unchanged. A remote reset removes those associations and assigns the next signing-in user; shared devices remain shared. Microsoft requires a working Windows Recovery Environment and excludes hybrid-joined devices and Surface Hub from this reset method. [Microsoft Learn](https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset).\n\n## Applicability\n\nUse this review for an approved reset of an eligible managed device. Identify whether the action will be local or remote and whether the device is assigned to a person or deliberately shared.\n\n## DSE recommendation\n\nRecord the intended post-reset ownership before authorizing an action that removes user material. Arrange protection of required data and verify the recovery-environment prerequisite through the approved support process. For a local reset, include an explicit administrator review of the unchanged ownership records. For a remote reset, coordinate which authorized person should complete the next sign-in. Keep shared-device intent visible in the handoff.\n\n## Verification\n\nAfter the reset completes, inspect both the Intune primary-user record and the Entra device owner against the handoff plan. Confirm the expected management connection and perform the agreed user or shared-device workflow. Do not close the reassignment merely because the desktop opens. Resolve an unexpected owner before issuing the device, and retain identifiers and observed outcomes without copying credentials into the record.\n\n## Official references\n\n[Microsoft Learn: Windows Autopilot Reset](https://learn.microsoft.com/en-us/autopilot/windows-autopilot-reset)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/", "slug": "dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend", "url": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-006-check-missing-summary-rule-intervals-before-accepting-a-log-analytics-trend/" }, "title": "Check missing summary-rule intervals before accepting a Log Analytics trend", "summary": "How should an operator distinguish a quiet interval from an unsuccessful summary-rule bin?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:50+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 255, "potentially_affected": "Log Analytics workspaces using summary rules in the public cloud.", "dse_recommendation": "Reconcile successful bin execution with the reporting interval before accepting an aggregate trend.", "primary_source": { "name": "Aggregate data in a Log Analytics workspace with summary rules - Azure Monitor | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Summary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. Microsoft Learn.
\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. Microsoft Learn.
\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. Microsoft Learn. Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.
\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.
\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.
\nMicrosoft Learn: Aggregate data with summary rules.
", "content_text": "Source facts\nSummary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. Microsoft Learn.\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. Microsoft Learn.\nApplicability\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. Microsoft Learn. Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.\nDSE recommendation\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.\nVerification\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.\nOfficial references\nMicrosoft Learn: Aggregate data with summary rules.", "content_markdown": "## Source facts\n\nSummary rules periodically aggregate workspace logs into a custom table. Enabling the workspace’s Summary Logs diagnostic category sends execution outcomes to LASummaryLogs. A failed bin receives ten retry attempts within eight hours; after those attempts are exhausted, that bin is skipped. Microsoft also documents a hold after eight consecutive bin retries. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules).\n\nThe source provides a completeness query using successful runs and BinStartTime. A manually retried run is identified by its failed bin’s start time, not an arbitrary reporting timestamp. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules).\n\n## Applicability\n\nApply this review to Log Analytics workspaces using summary rules in the public cloud. Summary rules are unavailable outside that cloud scope. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules). Keep the rule’s configured bin size and the report’s time range in the review record. Treat completeness as a question to establish, not something implied by an attractive chart.\n\n## DSE recommendation\n\nDSE recommends checking execution coverage before interpreting a drop in summarized activity. Assign missing intervals to a separate exception list, with their rule name and bin start. Ask the rule owner to investigate failed execution before requesting a rerun. Do not quietly replace unknown intervals with zero in a management report; label the uncertainty until evidence resolves it.\n\n## Verification\n\nFor an approved sample period, compare the expected interval sequence with successful execution records and the destination results. Preserve the missing-bin list, any retry request, and its observed outcome. Have a second reviewer confirm that the final trend distinguishes measured values from intervals that remain unverified.\n\n## Official references\n\n[Microsoft Learn: Aggregate data with summary rules](https://learn.microsoft.com/en-us/azure/azure-monitor/logs/summary-rules)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/", "slug": "dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request", "url": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-008-validate-the-hana-host-role-before-submitting-a-netapp-volume-group-request/" }, "title": "Validate the HANA host role before submitting a NetApp volume-group request", "summary": "Can the same NetApp application-volume-group payload be reused for the first and every additional HANA host?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "network-infrastructure", "label": "Networks & infrastructure", "alt": "Resilient network core with engineered blue and gold data paths.", "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:48+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 247, "potentially_affected": "Use this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source's networking, placement and protocol requirements before deployment.", "dse_recommendation": "Make host role and expected volume roles explicit inputs to the deployment review.", "primary_source": { "name": "Configure application volume groups for SAP HANA using REST API | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. Microsoft Learn.
\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.
\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.
\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.
\nMicrosoft Learn: Configure application volume groups for SAP HANA using REST API.
", "content_text": "Source facts\nAn Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. Microsoft Learn.\nApplicability\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.\nDSE recommendation\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.\nVerification\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.\nOfficial references\nMicrosoft Learn: Configure application volume groups for SAP HANA using REST API.", "content_markdown": "## Source facts\n\nAn Azure NetApp Files application volume group creates volumes for one SAP HANA host. The first host requires data, log and shared volumes, with backup volumes optional. Each additional scale-out host can add only data and log volumes. These groups require manual QoS capacity pools. Microsoft also warns that REST callers do not receive the portal and Resource Manager template’s deployment prechecks and recommendations. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api).\n\n## Applicability\n\nUse this review for SAP HANA application-volume-group creation through REST. Identify whether the request represents the first host or an additional scale-out host, and review the complete source’s networking, placement and protocol requirements before deployment.\n\n## DSE recommendation\n\nMake host role and expected volume roles explicit inputs to the deployment review. Compare the requested array with an approved host-to-volume map before issuing a write. Keep the first-host example separate from the additional-host example; do not carry shared or backup volume entries into every repeated request. Have the HANA and storage owners agree the intended size and throughput independently of the sample values. Preserve the reviewed payload without access tokens.\n\n## Verification\n\nIn an approved environment, inspect the returned group and its volume roles against the host map. Verify the selected pool’s QoS mode and the actual requested parameters. Treat a successful API response as provisioning evidence, not certification that the complete HANA design is appropriate. Resolve any extra or missing role before proceeding to another host.\n\n## Official references\n\n[Microsoft Learn: Configure application volume groups for SAP HANA using REST API](https://learn.microsoft.com/en-us/azure/azure-netapp-files/configure-application-volume-group-sap-hana-api)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/", "slug": "dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup", "url": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-011-do-not-equate-a-mars-volume-snapshot-with-application-consistent-backup/" }, "title": "Do not equate a MARS volume snapshot with application-consistent backup", "summary": "Does the MARS agent's use of VSS establish application-consistent recovery for the files it protects?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "networks-infrastructure", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:45+00:00", "modified_at": "2026-09-10T00:31:59+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 235, "potentially_affected": "Identify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server's stored data.", "dse_recommendation": "Match the required application recovery behavior to the selected backup method before accepting coverage.", "primary_source": { "name": "Architecture Overview - Azure Backup | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/backup/backup-architecture", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "For direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. Microsoft Learn.
\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.
\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.
\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.
\nMicrosoft Learn: Architecture Overview.
", "content_text": "Source facts\nFor direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. Microsoft Learn.\nApplicability\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.\nDSE recommendation\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.\nVerification\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.\nOfficial references\nMicrosoft Learn: Architecture Overview.", "content_markdown": "## Source facts\n\nFor direct Windows file and folder protection, the MARS agent takes a point-in-time volume snapshot using VSS. Microsoft says it uses only the Windows system write operation, not application VSS writers, and therefore does not capture application-consistent snapshots. The same architecture guide distinguishes DPM/MABS protection of specific applications using application-aware backup settings. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/backup/backup-architecture).\n\n## Applicability\n\nIdentify the actual backup method for the workload, not just whether a VSS snapshot exists. Apply this limitation to the documented direct MARS path; do not generalize it to every Azure Backup workload or to MARS transporting a backup server’s stored data.\n\n## DSE recommendation\n\nMatch the required application recovery behavior to the selected backup method before accepting coverage. Ask the application owner what must be consistent at recovery and which supported procedure establishes that result. Record whether the protected content is ordinary files or an active application’s data. If application consistency is required, evaluate the appropriate supported application-aware method rather than assuming the file agent supplies it. Keep existing protection in place while that assessment is completed.\n\n## Verification\n\nRestore a representative protected dataset in an approved isolated environment and perform the application’s documented recovery checks. Preserve the chosen method and its consistency boundary with the result. A completed file restore should be recorded as such, not expanded into a claim that transaction state or application recovery requirements were satisfied without testing.\n\n## Official references\n\n[Microsoft Learn: Architecture Overview](https://learn.microsoft.com/en-us/azure/backup/backup-architecture)." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/", "slug": "dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery", "url": "https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-015-return-the-right-state-change-result-from-service-fabric-data-loss-recovery/" }, "title": "Return the right state-change result from Service Fabric data-loss recovery", "summary": "What should a Service Fabric OnDataLossAsync implementation return after examining or restoring surviving state?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:41+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 236, "potentially_affected": "Custom stateful Service Fabric services implementing OnDataLossAsync recovery handling.", "dse_recommendation": "DSE recommends making the handler's return value an explicit state-change contract.", "primary_source": { "name": "Azure Service Fabric disaster recovery - Azure Service Fabric | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Service Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. Microsoft Learn.
\nUse this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.
\nDSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.
\nIn a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.
\nMicrosoft Learn. Source retrieved September 9, 2026.
", "content_text": "Source facts\nService Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. Microsoft Learn.\nApplicability\nUse this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.\nDSE recommendation\nDSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.\nVerification\nIn a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.\nOfficial references\nMicrosoft Learn. Source retrieved September 9, 2026.", "content_markdown": "## Source facts\n\nService Fabric calls OnDataLossAsync for suspected, not necessarily proven, data loss and chooses the remaining replica with the most progress. After examination and any restoration, the handler returns true if it changed state and false if it did not. A true result causes other remaining replicas to be dropped and rebuilt from that replica; false lets them retain their state. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery).\n\n## Applicability\n\nUse this review for application-owned recovery code, not as permission to force system services out of quorum loss. Establish how the implementation decides whether state changed. Keep the decision to restore a backup separate from the meaning of the Boolean result.\n\n## DSE recommendation\n\nDSE recommends making the handler’s return value an explicit state-change contract. Have the service owner review the paths for no change, successful restoration and incomplete investigation. Define how coordinated services will be checked before recovery is accepted, and preserve enough evidence to explain which state was selected. Do not return a success-looking value merely because the handler reached its final line.\n\n## Verification\n\nIn a disposable failure simulation, exercise both an unchanged surviving replica and a path that actually modifies state. Inspect the returned value and resulting handling of the remaining replicas. Verify application data and cross-service consistency after the test, not just replica availability. Record why the handler concluded that a change did or did not occur before approving the implementation.\n\n## Official references\n\n[Microsoft Learn](https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-disaster-recovery). Source retrieved September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials/", "slug": "dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials", "url": "https://update.dsesecurity.com/updates/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-016-register-a-manually-installed-mobility-agent-without-discovery-credentials/" }, "title": "Register a manually installed Mobility agent without discovery credentials", "summary": "How should a modernized Site Recovery agent be registered when machine and virtualization discovery credentials cannot be supplied?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "physical-security", "label": "Physical security", "alt": "Integrated video surveillance and controlled entry at a modern commercial facility.", "card_url": "https://update.dsesecurity.com/assets/editorial/physical-security-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/physical-security-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/physical-security-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:40+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 229, "potentially_affected": "Consider this workflow for on-premises VMware or physical-machine protection using the modernized architecture. Establish which appliance should own the registration, and confirm the source operating system and installation permissions before choosing the manual path.", "dse_recommendation": "Document the machine-to-appliance pairing before distributing installation material.", "primary_source": { "name": "About the Mobility service for disaster recovery of VMware VMs and physical servers with Azure Site Recovery - Azure Site Recovery | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/site-recovery/vmware-physical-mobility-service-overview", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Modernized Azure Site Recovery offers credential-less discovery when the machine and vCenter or ESXi credentials cannot be provided. This path requires manually installing the Mobility service and enabling its credential-less discovery option. Registration uses a configuration file generated on the chosen appliance from the source machine’s unique details string. The configuration file is then supplied to the agent on that source machine. Microsoft Learn.
\nConsider this workflow for on-premises VMware or physical-machine protection using the modernized architecture. Establish which appliance should own the registration, and confirm the source operating system and installation permissions before choosing the manual path.
\nDocument the machine-to-appliance pairing before distributing installation material. Keep each source identifier associated with its own generated configuration file; do not circulate one convenient file as a fleet-wide registration package. Separate approval to install the service from the decision to supply discovery credentials, and record which documented installation mode was selected.
\nOn a controlled candidate machine, verify the identifier used to generate the file, the intended appliance, and the registration result. Reconcile the registered source with the inventory before enabling replication. Treat a completed software installation as an intermediate checkpoint: do not close onboarding until the correct machine has registered through the chosen workflow.
\nMicrosoft’s specialized-disk workflow creates a new Azure Windows VM around an existing operating-system disk. The resulting guest keeps the original computer name and other machine-specific identifiers, including CMID; duplicated identifiers can affect applications. The portal procedure requires the selected disk to be unattached. Microsoft also documents creating a snapshot-derived disk while retaining the original as a fallback. Microsoft Learn.
\nUse this review for a particular retained Windows installation, not an empty VM or a generalized-image rollout. Identify whether the request replaces a failed VM or creates a separate copy. Ask the application owner which stored machine identifiers matter to that purpose.
\nTreat the specialized disk as an existing machine identity and approve its intended replacement or copy role before starting the new VM. Record the source VM, selected disk, proposed Azure resource name, and expected guest identity separately. Decide how the source installation will be isolated during the test. Prefer an approved snapshot-derived working disk when preserving the original is part of the recovery plan.
\nBefore accepting the replacement, inspect its guest computer name and application-specific identity, then compare them with the planned outcome. Exercise the application in the approved network context and investigate any duplicate-identity warning. Keep the disk lineage and resource identifiers with the recovery record. Do not discard the preserved source solely because the new Azure resource reports successful creation.
\nMicrosoft Learn: Attach an existing OS disk to a VM. Source reviewed September 9, 2026.
", "content_text": "Source facts\nMicrosoft’s specialized-disk workflow creates a new Azure Windows VM around an existing operating-system disk. The resulting guest keeps the original computer name and other machine-specific identifiers, including CMID; duplicated identifiers can affect applications. The portal procedure requires the selected disk to be unattached. Microsoft also documents creating a snapshot-derived disk while retaining the original as a fallback. Microsoft Learn.\nApplicability\nUse this review for a particular retained Windows installation, not an empty VM or a generalized-image rollout. Identify whether the request replaces a failed VM or creates a separate copy. Ask the application owner which stored machine identifiers matter to that purpose.\nDSE recommendation\nTreat the specialized disk as an existing machine identity and approve its intended replacement or copy role before starting the new VM. Record the source VM, selected disk, proposed Azure resource name, and expected guest identity separately. Decide how the source installation will be isolated during the test. Prefer an approved snapshot-derived working disk when preserving the original is part of the recovery plan.\nVerification\nBefore accepting the replacement, inspect its guest computer name and application-specific identity, then compare them with the planned outcome. Exercise the application in the approved network context and investigate any duplicate-identity warning. Keep the disk lineage and resource identifiers with the recovery record. Do not discard the preserved source solely because the new Azure resource reports successful creation.\nOfficial references\nMicrosoft Learn: Attach an existing OS disk to a VM. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft’s specialized-disk workflow creates a new Azure Windows VM around an existing operating-system disk. The resulting guest keeps the original computer name and other machine-specific identifiers, including CMID; duplicated identifiers can affect applications. The portal procedure requires the selected disk to be unattached. Microsoft also documents creating a snapshot-derived disk while retaining the original as a fallback. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/attach-os-disk).\n\n## Applicability\n\nUse this review for a particular retained Windows installation, not an empty VM or a generalized-image rollout. Identify whether the request replaces a failed VM or creates a separate copy. Ask the application owner which stored machine identifiers matter to that purpose.\n\n## DSE recommendation\n\nTreat the specialized disk as an existing machine identity and approve its intended replacement or copy role before starting the new VM. Record the source VM, selected disk, proposed Azure resource name, and expected guest identity separately. Decide how the source installation will be isolated during the test. Prefer an approved snapshot-derived working disk when preserving the original is part of the recovery plan.\n\n## Verification\n\nBefore accepting the replacement, inspect its guest computer name and application-specific identity, then compare them with the planned outcome. Exercise the application in the approved network context and investigate any duplicate-identity warning. Keep the disk lineage and resource identifiers with the recovery record. Do not discard the preserved source solely because the new Azure resource reports successful creation.\n\n## Official references\n\n[Microsoft Learn: Attach an existing OS disk to a VM](https://learn.microsoft.com/en-us/azure/virtual-machines/attach-os-disk). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-025-read-the-windows-vm-creation-flag-before-planning-a-patch-mode-transition/", "slug": "dse-20260909-025-read-the-windows-vm-creation-flag-before-planning-a-patch-mode-transition", "url": "https://update.dsesecurity.com/updates/dse-20260909-025-read-the-windows-vm-creation-flag-before-planning-a-patch-mode-transition/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-025-read-the-windows-vm-creation-flag-before-planning-a-patch-mode-transition.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-025-read-the-windows-vm-creation-flag-before-planning-a-patch-mode-transition/" }, "title": "Read the Windows VM creation flag before planning a patch-mode transition", "summary": "Can an existing Azure Windows VM switch freely between AutomaticByOS and Manual patch modes?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "managed-it", "label": "Managed IT operations", "alt": "A controlled technology lifecycle progressing from assessment to approved production.", "card_url": "https://update.dsesecurity.com/assets/editorial/managed-it-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/managed-it-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/managed-it-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:31+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 233, "potentially_affected": "Azure Windows VMs using the documented supported platform images and reviewing patch-orchestration transitions.", "dse_recommendation": "Include enableAutomaticUpdates in the before-state record for a Windows patch-mode change.", "primary_source": { "name": "Automatic Guest Patching for Azure Virtual Machines and Scale Sets - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-vm-guest-patching", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An Azure Windows VM’s enableAutomaticUpdates property is set only when the VM is created. With that property false, Microsoft supports transitions between AutomaticByPlatform and Manual; with it true, transitions are between AutomaticByPlatform and AutomaticByOS. Switching between AutomaticByOS and Manual is unsupported. AutomaticByOS uses native Windows updates, while Manual disables them. Microsoft Learn.
\nUse this check before planning the return path from platform-orchestrated guest patching. The source limits automatic guest patching to its listed platform-image combinations and excludes custom images, so validate the image as well as the Windows configuration.
\nInclude enableAutomaticUpdates in the before-state record for a Windows patch-mode change. Have the patch owner identify the current value and the supported destination mode before approving the change. Record who will manage updates after platform orchestration is disabled. Do not assume that selecting a different label can override a creation-time property, and do not leave the replacement update mechanism unspecified.
\nIn a representative approved test, compare the resource’s actual patch settings with the planned transition and inspect the resulting guest update configuration. Verify an authorized assessment or update outcome through the intended mechanism. If the requested transition is unsupported, redesign the plan rather than repeatedly editing the immutable flag. Preserve the selected mode and its operational owner in the maintenance record.
\nMicrosoft Learn: Automatic Guest Patching for Azure Virtual Machines and Scale Sets. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAn Azure Windows VM’s enableAutomaticUpdates property is set only when the VM is created. With that property false, Microsoft supports transitions between AutomaticByPlatform and Manual; with it true, transitions are between AutomaticByPlatform and AutomaticByOS. Switching between AutomaticByOS and Manual is unsupported. AutomaticByOS uses native Windows updates, while Manual disables them. Microsoft Learn.\nApplicability\nUse this check before planning the return path from platform-orchestrated guest patching. The source limits automatic guest patching to its listed platform-image combinations and excludes custom images, so validate the image as well as the Windows configuration.\nDSE recommendation\nInclude enableAutomaticUpdates in the before-state record for a Windows patch-mode change. Have the patch owner identify the current value and the supported destination mode before approving the change. Record who will manage updates after platform orchestration is disabled. Do not assume that selecting a different label can override a creation-time property, and do not leave the replacement update mechanism unspecified.\nVerification\nIn a representative approved test, compare the resource’s actual patch settings with the planned transition and inspect the resulting guest update configuration. Verify an authorized assessment or update outcome through the intended mechanism. If the requested transition is unsupported, redesign the plan rather than repeatedly editing the immutable flag. Preserve the selected mode and its operational owner in the maintenance record.\nOfficial references\nMicrosoft Learn: Automatic Guest Patching for Azure Virtual Machines and Scale Sets. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAn Azure Windows VM’s enableAutomaticUpdates property is set only when the VM is created. With that property false, Microsoft supports transitions between AutomaticByPlatform and Manual; with it true, transitions are between AutomaticByPlatform and AutomaticByOS. Switching between AutomaticByOS and Manual is unsupported. AutomaticByOS uses native Windows updates, while Manual disables them. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-vm-guest-patching).\n\n## Applicability\n\nUse this check before planning the return path from platform-orchestrated guest patching. The source limits automatic guest patching to its listed platform-image combinations and excludes custom images, so validate the image as well as the Windows configuration.\n\n## DSE recommendation\n\nInclude enableAutomaticUpdates in the before-state record for a Windows patch-mode change. Have the patch owner identify the current value and the supported destination mode before approving the change. Record who will manage updates after platform orchestration is disabled. Do not assume that selecting a different label can override a creation-time property, and do not leave the replacement update mechanism unspecified.\n\n## Verification\n\nIn a representative approved test, compare the resource’s actual patch settings with the planned transition and inspect the resulting guest update configuration. Verify an authorized assessment or update outcome through the intended mechanism. If the requested transition is unsupported, redesign the plan rather than repeatedly editing the immutable flag. Preserve the selected mode and its operational owner in the maintenance record.\n\n## Official references\n\n[Microsoft Learn: Automatic Guest Patching for Azure Virtual Machines and Scale Sets](https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-vm-guest-patching). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-026-plan-the-one-way-boundary-of-availability-set-migration-to-flexible-scale-sets/", "slug": "dse-20260909-026-plan-the-one-way-boundary-of-availability-set-migration-to-flexible-scale-sets", "url": "https://update.dsesecurity.com/updates/dse-20260909-026-plan-the-one-way-boundary-of-availability-set-migration-to-flexible-scale-sets/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-026-plan-the-one-way-boundary-of-availability-set-migration-to-flexible-scale-sets.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-026-plan-the-one-way-boundary-of-availability-set-migration-to-flexible-scale-sets/" }, "title": "Plan the one-way boundary of availability-set migration to Flexible scale sets", "summary": "What does cancellation preserve during the preview migration from an availability set to a Flexible scale set?", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:30+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 274, "potentially_affected": "Teams evaluating the preview migration of Azure availability-set VMs to Flexible Virtual Machine Scale Sets.", "dse_recommendation": "Write a per-VM migration and interruption plan that does not treat cancellation as reversal.", "primary_source": { "name": "Migrate availability sets to Virtual Machine Scale Sets - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/availability-set-migrate-to-scale-sets", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft labels availability-set migration to Flexible scale sets as preview. Migration deallocates VMs and cannot be reversed back to an availability set after completion. Canceling an unfinished migration leaves already-moved VMs in the scale set; only the remaining VMs stay in the availability set. The portal migrates the whole set together, whereas CLI, PowerShell, and REST workflows permit individual VM moves. Once migration begins, the availability set is locked to migration, completion, or cancellation operations until the process finishes. Migrated VMs require an explicit start. Microsoft Learn.
\nEvaluate this preview only through an approved trial. Check registration and the documented disk, public-IP, and load-balancer exclusions before selecting a target. Record whether the workload can tolerate the proposed interruption and whether its migration needs per-VM sequencing.
\nWrite a per-VM migration and interruption plan that does not treat cancellation as reversal. Name the intended target and zone assignment, the point at which each VM may move, and the operator responsible for starting it afterward. Include an explicit decision for a partially migrated estate: continue, pause for investigation, or cancel the remaining moves. Do not promise a return path that the procedure does not provide.
\nIn a permitted pilot, capture validation results and the membership of each VM before and after its move. Exercise the approved start and workload checks before moving the next participant. If testing cancellation, compare the resulting split membership with the written expectation. Retain the old availability-set record until every intended VM has been accounted for and the cleanup decision is approved.
\nMicrosoft Learn: Migrate availability sets to Virtual Machine Scale Sets. Source reviewed September 9, 2026.
", "content_text": "Source facts\nMicrosoft labels availability-set migration to Flexible scale sets as preview. Migration deallocates VMs and cannot be reversed back to an availability set after completion. Canceling an unfinished migration leaves already-moved VMs in the scale set; only the remaining VMs stay in the availability set. The portal migrates the whole set together, whereas CLI, PowerShell, and REST workflows permit individual VM moves. Once migration begins, the availability set is locked to migration, completion, or cancellation operations until the process finishes. Migrated VMs require an explicit start. Microsoft Learn.\nApplicability\nEvaluate this preview only through an approved trial. Check registration and the documented disk, public-IP, and load-balancer exclusions before selecting a target. Record whether the workload can tolerate the proposed interruption and whether its migration needs per-VM sequencing.\nDSE recommendation\nWrite a per-VM migration and interruption plan that does not treat cancellation as reversal. Name the intended target and zone assignment, the point at which each VM may move, and the operator responsible for starting it afterward. Include an explicit decision for a partially migrated estate: continue, pause for investigation, or cancel the remaining moves. Do not promise a return path that the procedure does not provide.\nVerification\nIn a permitted pilot, capture validation results and the membership of each VM before and after its move. Exercise the approved start and workload checks before moving the next participant. If testing cancellation, compare the resulting split membership with the written expectation. Retain the old availability-set record until every intended VM has been accounted for and the cleanup decision is approved.\nOfficial references\nMicrosoft Learn: Migrate availability sets to Virtual Machine Scale Sets. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft labels availability-set migration to Flexible scale sets as preview. Migration deallocates VMs and cannot be reversed back to an availability set after completion. Canceling an unfinished migration leaves already-moved VMs in the scale set; only the remaining VMs stay in the availability set. The portal migrates the whole set together, whereas CLI, PowerShell, and REST workflows permit individual VM moves. Once migration begins, the availability set is locked to migration, completion, or cancellation operations until the process finishes. Migrated VMs require an explicit start. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/availability-set-migrate-to-scale-sets).\n\n## Applicability\n\nEvaluate this preview only through an approved trial. Check registration and the documented disk, public-IP, and load-balancer exclusions before selecting a target. Record whether the workload can tolerate the proposed interruption and whether its migration needs per-VM sequencing.\n\n## DSE recommendation\n\nWrite a per-VM migration and interruption plan that does not treat cancellation as reversal. Name the intended target and zone assignment, the point at which each VM may move, and the operator responsible for starting it afterward. Include an explicit decision for a partially migrated estate: continue, pause for investigation, or cancel the remaining moves. Do not promise a return path that the procedure does not provide.\n\n## Verification\n\nIn a permitted pilot, capture validation results and the membership of each VM before and after its move. Exercise the approved start and workload checks before moving the next participant. If testing cancellation, compare the resulting split membership with the written expectation. Retain the old availability-set record until every intended VM has been accounted for and the cleanup decision is approved.\n\n## Official references\n\n[Microsoft Learn: Migrate availability sets to Virtual Machine Scale Sets](https://learn.microsoft.com/en-us/azure/virtual-machines/availability-set-migrate-to-scale-sets). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-028-keep-vm-watch-process-cpu-percentages-tied-to-their-denominator/", "slug": "dse-20260909-028-keep-vm-watch-process-cpu-percentages-tied-to-their-denominator", "url": "https://update.dsesecurity.com/updates/dse-20260909-028-keep-vm-watch-process-cpu-percentages-tied-to-their-denominator/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-028-keep-vm-watch-process-cpu-percentages-tied-to-their-denominator.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-028-keep-vm-watch-process-cpu-percentages-tied-to-their-denominator/" }, "title": "Keep VM watch process CPU percentages tied to their denominator", "summary": "Why can two VM watch process CPU metrics report different percentages for the same process?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:28+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 233, "potentially_affected": "Azure VMs and scale sets evaluating the VM watch preview's process CPU measurements.", "dse_recommendation": "Label process CPU charts with the exact VM watch metric and denominator.", "primary_source": { "name": "Azure VM Watch - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/azure-vm-watch", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "VM watch is a preview that runs configurable in-guest health checks and is delivered through the Application Health VM extension. Its ProcessCPUCoreUsage metric expresses instantaneous process usage against one CPU core, whereas ProcessCPUMachineUsage expresses process usage against the machine’s total CPU. MachineTotalCpuUsage describes the VM’s total instantaneous CPU utilization. Microsoft Learn.
\nUse this interpretation check when building process-level dashboards or comparing a process chart with a whole-machine chart. Preserve the metric names in the evidence instead of presenting every percentage under a generic CPU heading.
\nLabel process CPU charts with the exact VM watch metric and denominator. Have the monitoring owner explain which question each chart answers: how much of one core the process is consuming, how much of the machine it is consuming, or how busy the entire VM is. Review any proposed alert threshold against that selected measurement. Do not transfer a threshold merely because both charts use a percent sign.
\nCollect the relevant signals over the same controlled workload interval and inspect them together. Record the VM configuration and the exact measurement being reviewed. If a chart differs from expectations, check its selected metric before diagnosing a workload regression. Treat this as a preview evaluation, and verify the actual deployed collector configuration rather than assuming every default signal is present.
\nMicrosoft Learn: VM watch: Enhancing VM health monitoring preview. Source reviewed September 9, 2026.
", "content_text": "Source facts\nVM watch is a preview that runs configurable in-guest health checks and is delivered through the Application Health VM extension. Its ProcessCPUCoreUsage metric expresses instantaneous process usage against one CPU core, whereas ProcessCPUMachineUsage expresses process usage against the machine’s total CPU. MachineTotalCpuUsage describes the VM’s total instantaneous CPU utilization. Microsoft Learn.\nApplicability\nUse this interpretation check when building process-level dashboards or comparing a process chart with a whole-machine chart. Preserve the metric names in the evidence instead of presenting every percentage under a generic CPU heading.\nDSE recommendation\nLabel process CPU charts with the exact VM watch metric and denominator. Have the monitoring owner explain which question each chart answers: how much of one core the process is consuming, how much of the machine it is consuming, or how busy the entire VM is. Review any proposed alert threshold against that selected measurement. Do not transfer a threshold merely because both charts use a percent sign.\nVerification\nCollect the relevant signals over the same controlled workload interval and inspect them together. Record the VM configuration and the exact measurement being reviewed. If a chart differs from expectations, check its selected metric before diagnosing a workload regression. Treat this as a preview evaluation, and verify the actual deployed collector configuration rather than assuming every default signal is present.\nOfficial references\nMicrosoft Learn: VM watch: Enhancing VM health monitoring preview. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nVM watch is a preview that runs configurable in-guest health checks and is delivered through the Application Health VM extension. Its ProcessCPUCoreUsage metric expresses instantaneous process usage against one CPU core, whereas ProcessCPUMachineUsage expresses process usage against the machine’s total CPU. MachineTotalCpuUsage describes the VM’s total instantaneous CPU utilization. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/azure-vm-watch).\n\n## Applicability\n\nUse this interpretation check when building process-level dashboards or comparing a process chart with a whole-machine chart. Preserve the metric names in the evidence instead of presenting every percentage under a generic CPU heading.\n\n## DSE recommendation\n\nLabel process CPU charts with the exact VM watch metric and denominator. Have the monitoring owner explain which question each chart answers: how much of one core the process is consuming, how much of the machine it is consuming, or how busy the entire VM is. Review any proposed alert threshold against that selected measurement. Do not transfer a threshold merely because both charts use a percent sign.\n\n## Verification\n\nCollect the relevant signals over the same controlled workload interval and inspect them together. Record the VM configuration and the exact measurement being reviewed. If a chart differs from expectations, check its selected metric before diagnosing a workload regression. Treat this as a preview evaluation, and verify the actual deployed collector configuration rather than assuming every default signal is present.\n\n## Official references\n\n[Microsoft Learn: VM watch: Enhancing VM health monitoring preview](https://learn.microsoft.com/en-us/azure/virtual-machines/azure-vm-watch). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-029-test-boot-diagnostics-capture-separately-from-an-operator-s-ability-to-view-it/", "slug": "dse-20260909-029-test-boot-diagnostics-capture-separately-from-an-operator-s-ability-to-view-it", "url": "https://update.dsesecurity.com/updates/dse-20260909-029-test-boot-diagnostics-capture-separately-from-an-operator-s-ability-to-view-it/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-029-test-boot-diagnostics-capture-separately-from-an-operator-s-ability-to-view-it.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-029-test-boot-diagnostics-capture-separately-from-an-operator-s-ability-to-view-it/" }, "title": "Test boot-diagnostics capture separately from an operator's ability to view it", "summary": "Which storage paths should be checked when Azure boot diagnostics are missing or inaccessible?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:27+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 261, "potentially_affected": "Operators using Azure VM boot diagnostics with managed or custom storage.", "dse_recommendation": "Test platform capture and authorized operator viewing as two separate checks before relying on boot diagnostics.", "primary_source": { "name": "Azure boot diagnostics - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Azure boot diagnostics collects serial output and screenshots for investigating startup failures. With firewall-protected custom storage, Microsoft requires access for Azure to publish that evidence and separate firewall allowances for the operator’s viewing network. Viewing also requires the appropriate read and view permissions. The custom account must share the VM’s region and subscription. Managed boot diagnostics offers no configurable retention period and overwrites logs after their total size exceeds 1 GB. Microsoft Learn.
\nIdentify whether each VM uses managed or custom diagnostic storage before investigating an empty view. For custom storage, record the selected account and the approved support workstation’s network. Check the source’s supported account types and VM limitations instead of copying a storage policy from unrelated evidence systems.
\nTest platform capture and authorized operator viewing as two separate checks before relying on boot diagnostics. Assign the VM owner to identify an expected startup observation and the storage owner to review its access path. Establish a deliberate preservation step for evidence needed beyond the live troubleshooting session. Keep that decision separate from normal application-log retention.
\nDuring an approved diagnostic exercise, confirm that a current screenshot and serial output can be retrieved by the intended responder. Compare an authorized viewing path with an intentionally unapproved one, without widening production access simply to make the test pass. Record the VM, storage mode, observation time, and retrieval result. Investigate whether a missing artifact was never captured or merely could not be read before declaring the diagnostic feature unavailable.
\nMicrosoft Learn: Azure boot diagnostics. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAzure boot diagnostics collects serial output and screenshots for investigating startup failures. With firewall-protected custom storage, Microsoft requires access for Azure to publish that evidence and separate firewall allowances for the operator’s viewing network. Viewing also requires the appropriate read and view permissions. The custom account must share the VM’s region and subscription. Managed boot diagnostics offers no configurable retention period and overwrites logs after their total size exceeds 1 GB. Microsoft Learn.\nApplicability\nIdentify whether each VM uses managed or custom diagnostic storage before investigating an empty view. For custom storage, record the selected account and the approved support workstation’s network. Check the source’s supported account types and VM limitations instead of copying a storage policy from unrelated evidence systems.\nDSE recommendation\nTest platform capture and authorized operator viewing as two separate checks before relying on boot diagnostics. Assign the VM owner to identify an expected startup observation and the storage owner to review its access path. Establish a deliberate preservation step for evidence needed beyond the live troubleshooting session. Keep that decision separate from normal application-log retention.\nVerification\nDuring an approved diagnostic exercise, confirm that a current screenshot and serial output can be retrieved by the intended responder. Compare an authorized viewing path with an intentionally unapproved one, without widening production access simply to make the test pass. Record the VM, storage mode, observation time, and retrieval result. Investigate whether a missing artifact was never captured or merely could not be read before declaring the diagnostic feature unavailable.\nOfficial references\nMicrosoft Learn: Azure boot diagnostics. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAzure boot diagnostics collects serial output and screenshots for investigating startup failures. With firewall-protected custom storage, Microsoft requires access for Azure to publish that evidence and separate firewall allowances for the operator’s viewing network. Viewing also requires the appropriate read and view permissions. The custom account must share the VM’s region and subscription. Managed boot diagnostics offers no configurable retention period and overwrites logs after their total size exceeds 1 GB. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics).\n\n## Applicability\n\nIdentify whether each VM uses managed or custom diagnostic storage before investigating an empty view. For custom storage, record the selected account and the approved support workstation’s network. Check the source’s supported account types and VM limitations instead of copying a storage policy from unrelated evidence systems.\n\n## DSE recommendation\n\nTest platform capture and authorized operator viewing as two separate checks before relying on boot diagnostics. Assign the VM owner to identify an expected startup observation and the storage owner to review its access path. Establish a deliberate preservation step for evidence needed beyond the live troubleshooting session. Keep that decision separate from normal application-log retention.\n\n## Verification\n\nDuring an approved diagnostic exercise, confirm that a current screenshot and serial output can be retrieved by the intended responder. Compare an authorized viewing path with an intentionally unapproved one, without widening production access simply to make the test pass. Record the VM, storage mode, observation time, and retrieval result. Investigate whether a missing artifact was never captured or merely could not be read before declaring the diagnostic feature unavailable.\n\n## Official references\n\n[Microsoft Learn: Azure boot diagnostics](https://learn.microsoft.com/en-us/azure/virtual-machines/boot-diagnostics). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-031-choose-the-correct-allocation-path-when-associating-an-existing-vm-with-reserved/", "slug": "dse-20260909-031-choose-the-correct-allocation-path-when-associating-an-existing-vm-with-reserved", "url": "https://update.dsesecurity.com/updates/dse-20260909-031-choose-the-correct-allocation-path-when-associating-an-existing-vm-with-reserved/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-031-choose-the-correct-allocation-path-when-associating-an-existing-vm-with-reserved.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-031-choose-the-correct-allocation-path-when-associating-an-existing-vm-with-reserved/" }, "title": "Choose the correct allocation path when associating an existing VM with reserved capacity", "summary": "How does associating an existing regional Azure VM differ from the preview path for an existing zonal VM?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:25+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 251, "potentially_affected": "Operators associating existing Azure Windows or Linux VMs with capacity reservation groups.", "dse_recommendation": "Classify the existing VM as regional or zonal before approving its reservation-association procedure.", "primary_source": { "name": "Associate a virtual machine to a capacity reservation group - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-associate-vm", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "An Azure VM references its capacity reservation group through a VM property. Microsoft requires an existing regional VM to be deallocated, associated, and restarted. The documented alternative for associating an existing zonal VM without deallocation is preview. After association and allocation, the reservation’s instance view identifies the VM through virtualMachinesAllocated. Microsoft Learn.
\nUse this check for an existing VM and a specifically identified reservation group in the same subscription. Record the VM’s regional or zonal placement and the intended matching reservation. Do not apply the preview procedure merely because the VM happens to reside in a region that offers zones.
\nClassify the existing VM as regional or zonal before approving its reservation-association procedure. For the regional path, include the interruption and restart in the workload owner’s change plan. If evaluating the zonal preview, obtain an explicit preview-use decision and retain the source conditions with the trial. Separate the request to change the association property from the evidence showing where capacity was actually allocated.
\nInspect the VM’s resulting group reference and the reservation’s instance view. Match the allocated VM identifier to the intended resource rather than relying on a similar display name. For a regional move, also verify the guest and application after restart. If the association exists but the expected allocation evidence is absent, leave the change open and investigate the mismatch before extending the procedure to additional machines.
\nMicrosoft Learn: Associate a virtual machine to a capacity reservation group. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAn Azure VM references its capacity reservation group through a VM property. Microsoft requires an existing regional VM to be deallocated, associated, and restarted. The documented alternative for associating an existing zonal VM without deallocation is preview. After association and allocation, the reservation’s instance view identifies the VM through virtualMachinesAllocated. Microsoft Learn.\nApplicability\nUse this check for an existing VM and a specifically identified reservation group in the same subscription. Record the VM’s regional or zonal placement and the intended matching reservation. Do not apply the preview procedure merely because the VM happens to reside in a region that offers zones.\nDSE recommendation\nClassify the existing VM as regional or zonal before approving its reservation-association procedure. For the regional path, include the interruption and restart in the workload owner’s change plan. If evaluating the zonal preview, obtain an explicit preview-use decision and retain the source conditions with the trial. Separate the request to change the association property from the evidence showing where capacity was actually allocated.\nVerification\nInspect the VM’s resulting group reference and the reservation’s instance view. Match the allocated VM identifier to the intended resource rather than relying on a similar display name. For a regional move, also verify the guest and application after restart. If the association exists but the expected allocation evidence is absent, leave the change open and investigate the mismatch before extending the procedure to additional machines.\nOfficial references\nMicrosoft Learn: Associate a virtual machine to a capacity reservation group. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAn Azure VM references its capacity reservation group through a VM property. Microsoft requires an existing regional VM to be deallocated, associated, and restarted. The documented alternative for associating an existing zonal VM without deallocation is preview. After association and allocation, the reservation’s instance view identifies the VM through virtualMachinesAllocated. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-associate-vm).\n\n## Applicability\n\nUse this check for an existing VM and a specifically identified reservation group in the same subscription. Record the VM’s regional or zonal placement and the intended matching reservation. Do not apply the preview procedure merely because the VM happens to reside in a region that offers zones.\n\n## DSE recommendation\n\nClassify the existing VM as regional or zonal before approving its reservation-association procedure. For the regional path, include the interruption and restart in the workload owner’s change plan. If evaluating the zonal preview, obtain an explicit preview-use decision and retain the source conditions with the trial. Separate the request to change the association property from the evidence showing where capacity was actually allocated.\n\n## Verification\n\nInspect the VM’s resulting group reference and the reservation’s instance view. Match the allocated VM identifier to the intended resource rather than relying on a similar display name. For a regional move, also verify the guest and application after restart. If the association exists but the expected allocation evidence is absent, leave the change open and investigate the mismatch before extending the procedure to additional machines.\n\n## Official references\n\n[Microsoft Learn: Associate a virtual machine to a capacity reservation group](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-associate-vm). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-033-restore-the-prior-quantity-when-a-capacity-reservation-increase-fails/", "slug": "dse-20260909-033-restore-the-prior-quantity-when-a-capacity-reservation-increase-fails", "url": "https://update.dsesecurity.com/updates/dse-20260909-033-restore-the-prior-quantity-when-a-capacity-reservation-increase-fails/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-033-restore-the-prior-quantity-when-a-capacity-reservation-increase-fails.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-033-restore-the-prior-quantity-when-a-capacity-reservation-increase-fails/" }, "title": "Restore the prior quantity when a capacity-reservation increase fails", "summary": "What state should an operator restore after Azure cannot satisfy an increase to an existing capacity reservation?", "format": { "slug": "playbook", "name": "Playbook" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:23+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 251, "potentially_affected": "Operators changing the quantity of an existing Azure capacity reservation.", "dse_recommendation": "Preserve the last successfully reserved quantity and use it as the explicit recovery target for an unsuccessful increase.", "primary_source": { "name": "Modify a capacity reservation in Azure - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-modify", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft warns that an unsuccessful request for more reserved capacity can rarely leave an existing reservation in Failed state and unavailable until its previous quantity is restored. VMs already associated with that failed reservation continue operating normally. The documented recovery can obtain the successfully reserved amount from currentCapacity in the reservation’s instance view and update the requested quantity accordingly. Microsoft Learn.
\nUse this response for a quantity increase on an existing reservation, not as a general remedy for every VM allocation error. Record the intended increase, previous successful amount, reservation identifier, and returned failure. Separate the reservation’s provisioning state from observations of its associated workloads.
\nPreserve the last successfully reserved quantity and use it as the explicit recovery target for an unsuccessful increase. Ask the capacity owner to approve restoring that amount before retrying a larger request. Keep the requested quantity, observed current capacity, and resulting state in one record. Assign any remaining growth requirement its own follow-up instead of interpreting restoration as delivery of the extra capacity.
\nAfter the approved correction, inspect the reservation’s quantity and state again. Compare the restored value with the preserved successful amount and reconcile the list of associated VMs. Have the workload owner check the relevant service separately, particularly if other changes occurred during the incident. Close the recovery only when the reservation-state discrepancy is resolved, and leave the unmet expansion request visible to its owner.
\nMicrosoft Learn: Modify a capacity reservation in Azure. Source reviewed September 9, 2026.
", "content_text": "Source facts\nMicrosoft warns that an unsuccessful request for more reserved capacity can rarely leave an existing reservation in Failed state and unavailable until its previous quantity is restored. VMs already associated with that failed reservation continue operating normally. The documented recovery can obtain the successfully reserved amount from currentCapacity in the reservation’s instance view and update the requested quantity accordingly. Microsoft Learn.\nApplicability\nUse this response for a quantity increase on an existing reservation, not as a general remedy for every VM allocation error. Record the intended increase, previous successful amount, reservation identifier, and returned failure. Separate the reservation’s provisioning state from observations of its associated workloads.\nDSE recommendation\nPreserve the last successfully reserved quantity and use it as the explicit recovery target for an unsuccessful increase. Ask the capacity owner to approve restoring that amount before retrying a larger request. Keep the requested quantity, observed current capacity, and resulting state in one record. Assign any remaining growth requirement its own follow-up instead of interpreting restoration as delivery of the extra capacity.\nVerification\nAfter the approved correction, inspect the reservation’s quantity and state again. Compare the restored value with the preserved successful amount and reconcile the list of associated VMs. Have the workload owner check the relevant service separately, particularly if other changes occurred during the incident. Close the recovery only when the reservation-state discrepancy is resolved, and leave the unmet expansion request visible to its owner.\nOfficial references\nMicrosoft Learn: Modify a capacity reservation in Azure. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft warns that an unsuccessful request for more reserved capacity can rarely leave an existing reservation in Failed state and unavailable until its previous quantity is restored. VMs already associated with that failed reservation continue operating normally. The documented recovery can obtain the successfully reserved amount from currentCapacity in the reservation’s instance view and update the requested quantity accordingly. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-modify).\n\n## Applicability\n\nUse this response for a quantity increase on an existing reservation, not as a general remedy for every VM allocation error. Record the intended increase, previous successful amount, reservation identifier, and returned failure. Separate the reservation’s provisioning state from observations of its associated workloads.\n\n## DSE recommendation\n\nPreserve the last successfully reserved quantity and use it as the explicit recovery target for an unsuccessful increase. Ask the capacity owner to approve restoring that amount before retrying a larger request. Keep the requested quantity, observed current capacity, and resulting state in one record. Assign any remaining growth requirement its own follow-up instead of interpreting restoration as delivery of the extra capacity.\n\n## Verification\n\nAfter the approved correction, inspect the reservation’s quantity and state again. Compare the restored value with the preserved successful amount and reconcile the list of associated VMs. Have the workload owner check the relevant service separately, particularly if other changes occurred during the incident. Close the recovery only when the reservation-state discrepancy is resolved, and leave the unmet expansion request visible to its owner.\n\n## Official references\n\n[Microsoft Learn: Modify a capacity reservation in Azure](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-modify). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-034-verify-capacity-reservation-disassociation-separately-from-vm-deallocation/", "slug": "dse-20260909-034-verify-capacity-reservation-disassociation-separately-from-vm-deallocation", "url": "https://update.dsesecurity.com/updates/dse-20260909-034-verify-capacity-reservation-disassociation-separately-from-vm-deallocation/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-034-verify-capacity-reservation-disassociation-separately-from-vm-deallocation.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-034-verify-capacity-reservation-disassociation-separately-from-vm-deallocation/" }, "title": "Verify capacity-reservation disassociation separately from VM deallocation", "summary": "Does stopping and deallocating a VM remove its capacity-reservation association?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:22+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 250, "potentially_affected": "Azure VMs retiring an association with a capacity reservation group.", "dse_recommendation": "Confirm both VM state and the reservation reference when closing an approved association-removal change.", "primary_source": { "name": "Remove a virtual machine association from a capacity reservation group - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-remove-vm", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "A deallocated Azure VM remains associated with its capacity reservation group until that reference is changed. Microsoft documents deallocation followed by clearing the association as one removal path. Another path sets reserved quantity to zero before changing the association, for cases where the VM cannot be deallocated and the reservation is no longer required. VM deletion also removes the association, but allocation-state updates can lag completion of the delete request. Microsoft Learn.
\nUse this check when a VM should remain available for future use but should no longer be attached to its current reservation. Do not treat the stopped state alone as evidence that the intended relationship was removed.
\nConfirm both VM state and the reservation reference when closing an approved association-removal change. Have the capacity and workload owners choose the supported path and document whether the reservation itself is still needed. Do not reduce reserved quantity merely to clear one relationship without reviewing the intended reservation use. Keep deletion out of the procedure when the approved outcome is to retain the VM.
\nInspect the VM’s group reference and the reservation’s associated-machine view after the approved operation. If a deletion was separately authorized, wait for its actual completion and inspect Capacity Reservation Instance View instead of inferring allocation state from request submission. Record the retained VM or completed deletion explicitly, together with any remaining association that needs investigation.
\nMicrosoft Learn: Remove a VM association from a capacity reservation group. Source reviewed September 9, 2026.
", "content_text": "Source facts\nA deallocated Azure VM remains associated with its capacity reservation group until that reference is changed. Microsoft documents deallocation followed by clearing the association as one removal path. Another path sets reserved quantity to zero before changing the association, for cases where the VM cannot be deallocated and the reservation is no longer required. VM deletion also removes the association, but allocation-state updates can lag completion of the delete request. Microsoft Learn.\nApplicability\nUse this check when a VM should remain available for future use but should no longer be attached to its current reservation. Do not treat the stopped state alone as evidence that the intended relationship was removed.\nDSE recommendation\nConfirm both VM state and the reservation reference when closing an approved association-removal change. Have the capacity and workload owners choose the supported path and document whether the reservation itself is still needed. Do not reduce reserved quantity merely to clear one relationship without reviewing the intended reservation use. Keep deletion out of the procedure when the approved outcome is to retain the VM.\nVerification\nInspect the VM’s group reference and the reservation’s associated-machine view after the approved operation. If a deletion was separately authorized, wait for its actual completion and inspect Capacity Reservation Instance View instead of inferring allocation state from request submission. Record the retained VM or completed deletion explicitly, together with any remaining association that needs investigation.\nOfficial references\nMicrosoft Learn: Remove a VM association from a capacity reservation group. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nA deallocated Azure VM remains associated with its capacity reservation group until that reference is changed. Microsoft documents deallocation followed by clearing the association as one removal path. Another path sets reserved quantity to zero before changing the association, for cases where the VM cannot be deallocated and the reservation is no longer required. VM deletion also removes the association, but allocation-state updates can lag completion of the delete request. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-remove-vm).\n\n## Applicability\n\nUse this check when a VM should remain available for future use but should no longer be attached to its current reservation. Do not treat the stopped state alone as evidence that the intended relationship was removed.\n\n## DSE recommendation\n\nConfirm both VM state and the reservation reference when closing an approved association-removal change. Have the capacity and workload owners choose the supported path and document whether the reservation itself is still needed. Do not reduce reserved quantity merely to clear one relationship without reviewing the intended reservation use. Keep deletion out of the procedure when the approved outcome is to retain the VM.\n\n## Verification\n\nInspect the VM’s group reference and the reservation’s associated-machine view after the approved operation. If a deletion was separately authorized, wait for its actual completion and inspect Capacity Reservation Instance View instead of inferring allocation state from request submission. Record the retained VM or completed deletion explicitly, together with any remaining association that needs investigation.\n\n## Official references\n\n[Microsoft Learn: Remove a VM association from a capacity reservation group](https://learn.microsoft.com/en-us/azure/virtual-machines/capacity-reservation-remove-vm). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-036-size-an-mpi-transport-experiment-by-connection-count-not-node-count-alone/", "slug": "dse-20260909-036-size-an-mpi-transport-experiment-by-connection-count-not-node-count-alone", "url": "https://update.dsesecurity.com/updates/dse-20260909-036-size-an-mpi-transport-experiment-by-connection-count-not-node-count-alone/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-036-size-an-mpi-transport-experiment-by-connection-count-not-node-count-alone.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-036-size-an-mpi-transport-experiment-by-connection-count-not-node-count-alone/" }, "title": "Size an MPI transport experiment by connection count, not node count alone", "summary": "What should be calculated before applying Azure HPC guidance for smaller versus larger MPI jobs?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:20+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 237, "potentially_affected": "MPI workloads on Azure HPC VMs evaluating the source's transport-scaling guidance.", "dse_recommendation": "Record the estimated connection count alongside the proposed MPI transport experiment.", "primary_source": { "name": "Scaling HPC applications - Azure Virtual Machines - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/compiling-scaling-applications", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Microsoft’s Azure HPC guidance estimates an MPI job’s maximum connections by multiplying processes per node by the square of the job’s node count. It suggests UCX_TLS=rc,sm for jobs below 256K connections and UCX_TLS=dc,sm above 256K connections. The source also emphasizes workload-specific tuning experiments rather than assuming an optimal configuration from VM selection alone. Microsoft Learn.
\nUse this planning check when scaling an MPI job beyond an earlier test. Record both the process layout and node count; a node-count-only label does not express the source’s connection estimate. The documented smaller/larger examples do not specify the exact boundary case.
\nRecord the estimated connection count alongside the proposed MPI transport experiment. Have the application owner compare the intended job layout with the transport guidance for its actual MPI runtime. Keep the runtime, transport setting, process placement and input workload together in the experiment record. Avoid carrying an old small-job setting into a larger run without examining that estimate.
\nRehearse the candidate configuration with an approved representative job. Check correctness first, then compare completion behavior and measured scaling against the prior configuration. Change one intended variable at a time where practical so an improvement or regression can be attributed. Retain an unsuccessful result as useful evidence instead of turning the source’s tuning suggestion into a claimed performance guarantee.
\nMicrosoft Learn: Scaling HPC applications. Source reviewed September 9, 2026.
", "content_text": "Source facts\nMicrosoft’s Azure HPC guidance estimates an MPI job’s maximum connections by multiplying processes per node by the square of the job’s node count. It suggests UCX_TLS=rc,sm for jobs below 256K connections and UCX_TLS=dc,sm above 256K connections. The source also emphasizes workload-specific tuning experiments rather than assuming an optimal configuration from VM selection alone. Microsoft Learn.\nApplicability\nUse this planning check when scaling an MPI job beyond an earlier test. Record both the process layout and node count; a node-count-only label does not express the source’s connection estimate. The documented smaller/larger examples do not specify the exact boundary case.\nDSE recommendation\nRecord the estimated connection count alongside the proposed MPI transport experiment. Have the application owner compare the intended job layout with the transport guidance for its actual MPI runtime. Keep the runtime, transport setting, process placement and input workload together in the experiment record. Avoid carrying an old small-job setting into a larger run without examining that estimate.\nVerification\nRehearse the candidate configuration with an approved representative job. Check correctness first, then compare completion behavior and measured scaling against the prior configuration. Change one intended variable at a time where practical so an improvement or regression can be attributed. Retain an unsuccessful result as useful evidence instead of turning the source’s tuning suggestion into a claimed performance guarantee.\nOfficial references\nMicrosoft Learn: Scaling HPC applications. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nMicrosoft’s Azure HPC guidance estimates an MPI job’s maximum connections by multiplying processes per node by the square of the job’s node count. It suggests UCX_TLS=rc,sm for jobs below 256K connections and UCX_TLS=dc,sm above 256K connections. The source also emphasizes workload-specific tuning experiments rather than assuming an optimal configuration from VM selection alone. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/compiling-scaling-applications).\n\n## Applicability\n\nUse this planning check when scaling an MPI job beyond an earlier test. Record both the process layout and node count; a node-count-only label does not express the source’s connection estimate. The documented smaller/larger examples do not specify the exact boundary case.\n\n## DSE recommendation\n\nRecord the estimated connection count alongside the proposed MPI transport experiment. Have the application owner compare the intended job layout with the transport guidance for its actual MPI runtime. Keep the runtime, transport setting, process placement and input workload together in the experiment record. Avoid carrying an old small-job setting into a larger run without examining that estimate.\n\n## Verification\n\nRehearse the candidate configuration with an approved representative job. Check correctness first, then compare completion behavior and measured scaling against the prior configuration. Change one intended variable at a time where practical so an improvement or regression can be attributed. Retain an unsuccessful result as useful evidence instead of turning the source’s tuning suggestion into a claimed performance guarantee.\n\n## Official references\n\n[Microsoft Learn: Scaling HPC applications](https://learn.microsoft.com/en-us/azure/virtual-machines/compiling-scaling-applications). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-038-list-excluded-data-before-approving-an-azure-vm-restore-point-plan/", "slug": "dse-20260909-038-list-excluded-data-before-approving-an-azure-vm-restore-point-plan", "url": "https://update.dsesecurity.com/updates/dse-20260909-038-list-excluded-data-before-approving-an-azure-vm-restore-point-plan/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-038-list-excluded-data-before-approving-an-azure-vm-restore-point-plan.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-038-list-excluded-data-before-approving-an-azure-vm-restore-point-plan/" }, "title": "List excluded data before approving an Azure VM restore-point plan", "summary": "Which disks and mounted data remain outside a proposed Azure VM restore point?", "format": { "slug": "checklist", "name": "Checklist" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:18+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 247, "potentially_affected": "Teams evaluating Azure VM restore points against a workload's disk and mounted-data inventory.", "dse_recommendation": "Create a coverage map that names every excluded disk or data path before approving the restore-point design.", "primary_source": { "name": "Support matrix for VM restore points - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/concepts-restore-points", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Azure VM restore points support managed disks, but not ephemeral OS disks or shared disks. Ultra Disks and Premium SSD v2 support application-consistent restore points, not crash-consistent ones. Temporary-disk contents are absent from restore points. Microsoft also excludes mounted NFS files: restore points cover locally attached VM disks rather than data from an NFS server. Microsoft Learn.
\nReview the actual VM architecture, operating system, orchestration mode, consistency choice, and disk types against the full support matrix. Identify application data reached through mounts as well as data on attached disks. Do not assume that a VM-level label establishes coverage for every path the application uses.
\nCreate a coverage map that names every excluded disk or data path before approving the restore-point design. Have the workload owner classify each item as reproducible, protected through another approved mechanism, or an unresolved recovery gap. Choose the required consistency mode with that owner rather than selecting it solely because a restore-point request is available in the interface.
\nFor an approved test workload, reconcile the created restore point with the intended disk inventory and exclusions. Restore the covered data into a permitted test context and exercise the application against the separately recovered dependencies. Record missing data as a coverage defect, even if the restore-point operation itself succeeded. Keep the matrix decision and the recovery evidence together when accepting or rejecting the proposed protection plan.
\nMicrosoft Learn: Support matrix for VM restore points. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAzure VM restore points support managed disks, but not ephemeral OS disks or shared disks. Ultra Disks and Premium SSD v2 support application-consistent restore points, not crash-consistent ones. Temporary-disk contents are absent from restore points. Microsoft also excludes mounted NFS files: restore points cover locally attached VM disks rather than data from an NFS server. Microsoft Learn.\nApplicability\nReview the actual VM architecture, operating system, orchestration mode, consistency choice, and disk types against the full support matrix. Identify application data reached through mounts as well as data on attached disks. Do not assume that a VM-level label establishes coverage for every path the application uses.\nDSE recommendation\nCreate a coverage map that names every excluded disk or data path before approving the restore-point design. Have the workload owner classify each item as reproducible, protected through another approved mechanism, or an unresolved recovery gap. Choose the required consistency mode with that owner rather than selecting it solely because a restore-point request is available in the interface.\nVerification\nFor an approved test workload, reconcile the created restore point with the intended disk inventory and exclusions. Restore the covered data into a permitted test context and exercise the application against the separately recovered dependencies. Record missing data as a coverage defect, even if the restore-point operation itself succeeded. Keep the matrix decision and the recovery evidence together when accepting or rejecting the proposed protection plan.\nOfficial references\nMicrosoft Learn: Support matrix for VM restore points. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAzure VM restore points support managed disks, but not ephemeral OS disks or shared disks. Ultra Disks and Premium SSD v2 support application-consistent restore points, not crash-consistent ones. Temporary-disk contents are absent from restore points. Microsoft also excludes mounted NFS files: restore points cover locally attached VM disks rather than data from an NFS server. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/concepts-restore-points).\n\n## Applicability\n\nReview the actual VM architecture, operating system, orchestration mode, consistency choice, and disk types against the full support matrix. Identify application data reached through mounts as well as data on attached disks. Do not assume that a VM-level label establishes coverage for every path the application uses.\n\n## DSE recommendation\n\nCreate a coverage map that names every excluded disk or data path before approving the restore-point design. Have the workload owner classify each item as reproducible, protected through another approved mechanism, or an unresolved recovery gap. Choose the required consistency mode with that owner rather than selecting it solely because a restore-point request is available in the interface.\n\n## Verification\n\nFor an approved test workload, reconcile the created restore point with the intended disk inventory and exclusions. Restore the covered data into a permitted test context and exercise the application against the separately recovered dependencies. Record missing data as a coverage defect, even if the restore-point operation itself succeeded. Keep the matrix decision and the recovery evidence together when accepting or rejecting the proposed protection plan.\n\n## Official references\n\n[Microsoft Learn: Support matrix for VM restore points](https://learn.microsoft.com/en-us/azure/virtual-machines/concepts-restore-points). Source reviewed September 9, 2026." }, { "id": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/", "slug": "dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery", "url": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/", "alternate_urls": { "markdown": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery.md", "json": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/" }, "title": "Choose Dedicated Host failure replacement before relying on automatic recovery", "summary": "What recovery obligation follows from disabling automatic replacement of a failed Dedicated Host?", "format": { "slug": "guide", "name": "Guide" }, "priority": { "slug": "info", "name": "Information" }, "featured": false, "image": { "theme": "continuity-recovery", "label": "Continuity & recovery", "alt": "Paired infrastructure paths converging on a stable recovered service.", "card_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-card.webp?v=1.8.20", "hero_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-hero.webp?v=1.8.20", "social_url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 2400, "height": 1350 }, "topics": [ { "slug": "business-continuity", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "slug": "it", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "author": { "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team", "type": "Organization" }, "publisher": { "name": "Detection Systems & Engineering", "url": "https://dsesecurity.com/" }, "published_at": "2026-09-10T00:31:13+00:00", "modified_at": "2026-09-10T00:32:00+00:00", "reviewed_on": "2026-09-09", "reading_minutes": 2, "word_count": 248, "potentially_affected": "Azure Dedicated Host owners choosing host-level automatic replacement behavior.", "dse_recommendation": "Document the manual recovery owner before opting out of automatic host replacement.", "primary_source": { "name": "Overview of Azure Dedicated Hosts for virtual machines - Azure Virtual Machines | Microsoft Learn", "url": "https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts", "published_on": null, "authority": "Microsoft Learn" }, "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usage_info": "https://update.dsesecurity.com/usage/", "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "content_html": "Azure Dedicated Host normally service-heals an unhealthy host by moving its VMs to healthy hardware and restarting them, with downtime during that process. Disabling automatic replacement can instead leave the host pending deallocation after failure, requiring manual creation of a replacement host and VM movement. Microsoft describes auto-replacement as a creation-time setting that cannot later be changed. Manually stopped or deallocated VMs are not moved by automatic service healing. Microsoft Learn.
\nUse this decision when a host-affinity requirement is being weighed against automated recovery. Include deliberately stopped VMs in the recovery inventory instead of assuming every associated machine participates in service healing.
\nDocument the manual recovery owner before opting out of automatic host replacement. Have the workload and platform owners agree how failure will be detected, who will provision replacement capacity, and how each VM will be recovered under the chosen setting. Record the reason for any opt-out and the intended recovery procedure before host creation. Do not equate a dedicated physical boundary with uninterrupted service.
\nInspect the created host’s actual auto-replacement property and reconcile the VM inventory with the recovery plan. Rehearse the decision and authorized recovery steps in a controlled environment without manufacturing a production host failure. After a real or approved recovery event, verify each workload separately and account for machines that were stopped beforehand. Keep missing recovery evidence open rather than reporting host availability as complete application restoration.
\nMicrosoft Learn: Azure Dedicated Hosts. Source reviewed September 9, 2026.
", "content_text": "Source facts\nAzure Dedicated Host normally service-heals an unhealthy host by moving its VMs to healthy hardware and restarting them, with downtime during that process. Disabling automatic replacement can instead leave the host pending deallocation after failure, requiring manual creation of a replacement host and VM movement. Microsoft describes auto-replacement as a creation-time setting that cannot later be changed. Manually stopped or deallocated VMs are not moved by automatic service healing. Microsoft Learn.\nApplicability\nUse this decision when a host-affinity requirement is being weighed against automated recovery. Include deliberately stopped VMs in the recovery inventory instead of assuming every associated machine participates in service healing.\nDSE recommendation\nDocument the manual recovery owner before opting out of automatic host replacement. Have the workload and platform owners agree how failure will be detected, who will provision replacement capacity, and how each VM will be recovered under the chosen setting. Record the reason for any opt-out and the intended recovery procedure before host creation. Do not equate a dedicated physical boundary with uninterrupted service.\nVerification\nInspect the created host’s actual auto-replacement property and reconcile the VM inventory with the recovery plan. Rehearse the decision and authorized recovery steps in a controlled environment without manufacturing a production host failure. After a real or approved recovery event, verify each workload separately and account for machines that were stopped beforehand. Keep missing recovery evidence open rather than reporting host availability as complete application restoration.\nOfficial references\nMicrosoft Learn: Azure Dedicated Hosts. Source reviewed September 9, 2026.", "content_markdown": "## Source facts\n\nAzure Dedicated Host normally service-heals an unhealthy host by moving its VMs to healthy hardware and restarting them, with downtime during that process. Disabling automatic replacement can instead leave the host pending deallocation after failure, requiring manual creation of a replacement host and VM movement. Microsoft describes auto-replacement as a creation-time setting that cannot later be changed. Manually stopped or deallocated VMs are not moved by automatic service healing. [Microsoft Learn](https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts).\n\n## Applicability\n\nUse this decision when a host-affinity requirement is being weighed against automated recovery. Include deliberately stopped VMs in the recovery inventory instead of assuming every associated machine participates in service healing.\n\n## DSE recommendation\n\nDocument the manual recovery owner before opting out of automatic host replacement. Have the workload and platform owners agree how failure will be detected, who will provision replacement capacity, and how each VM will be recovered under the chosen setting. Record the reason for any opt-out and the intended recovery procedure before host creation. Do not equate a dedicated physical boundary with uninterrupted service.\n\n## Verification\n\nInspect the created host’s actual auto-replacement property and reconcile the VM inventory with the recovery plan. Rehearse the decision and authorized recovery steps in a controlled environment without manufacturing a production host failure. After a real or approved recovery event, verify each workload separately and account for machines that were stopped beforehand. Keep missing recovery evidence open rather than reporting host availability as complete application restoration.\n\n## Official references\n\n[Microsoft Learn: Azure Dedicated Hosts](https://learn.microsoft.com/en-us/azure/virtual-machines/dedicated-hosts). Source reviewed September 9, 2026." } ] }