{ "api_version": "1", "kind": "dse_post", "self": "https://update.dsesecurity.com/api/v1/posts/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/", "item": { "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": "

Source facts

\n

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.

\n

Applicability

\n

Use 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

DSE recommendation

\n

Document 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

Verification

\n

Inspect 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

Official references

\n

Microsoft 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." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/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/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-09-09" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "Choose Dedicated Host failure replacement before relying on automatic recovery", "item": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/#article", "identifier": "https://update.dsesecurity.com/updates/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/", "headline": "Choose Dedicated Host failure replacement before relying on automatic recovery", "description": "What recovery obligation follows from disabling automatic replacement of a failed Dedicated Host?", "abstract": "What recovery obligation follows from disabling automatic replacement of a failed Dedicated Host?", "articleBody": "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.", "datePublished": "2026-09-10T00:31:13+00:00", "dateModified": "2026-09-10T00:32:00+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/dse-20260909-043-choose-dedicated-host-failure-replacement-before-relying-on-automatic-recovery/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/continuity-recovery-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Choose Dedicated Host failure replacement before relying on automatic recovery" }, "articleSection": [ "Business Continuity", "IT" ], "keywords": [ "Business Continuity", "IT", "Guide", "Information priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "Business Continuity", "url": "https://update.dsesecurity.com/topic/business-continuity/" }, { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" } ], "wordCount": 248, "timeRequired": "PT2M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "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" } } ] } }