Troubleshoot Hyper-V guarded fabrics and shielded VMs
Use this FAQ when a guarded fabric can't be deployed, a host can't attest, a shielded virtual machine (VM) can't be provisioned or started, or an operation such as migration, servicing, or recovery fails. It accompanies the Microsoft Learn module: https://learn.microsoft.com/en-us/training/modules/guarded-fabric-shielded-virtual-machines/ Warning Don't use TPM clearing, an unrelated new or local KP, disabled Secure Boot or CI, a weaker attestation mode, certificate-validation bypasses, or copied owner private keys as generic troubleshooting fixes. Don't delete protected VM state or checkpoint files to make an error disappear. These actions can weaken the trust boundary or permanently remove access to encrypted data. In this FAQ Why can't I install or prepare the platform? Why does HGS deployment or service operation fail? Why can't hosts or owners reach the correct HGS service? Why do certificate enrollment, import, or private-key operations fail? What do HGS client attestation results mean? Why does a TPM-trusted host fail a specific security check? Why do code integrity policy changes break the host? Why do host-key or legacy AD-based attestation fail? Why does attestation pass but a VM still can't obtain its keys? Why do template preparation or image validation fail? Why do shielding-data creation and VM provisioning fail? Why can't the owner access the guest or confirm its protection? Why do live migration, cluster placement, or failover fail? Why do servicing, key rollover, or retirement cause an outage? Why does withdrawing trust not immediately contain an incident? What fails when HGS or a site is unavailable? Why do backups or disaster recovery fail? Why does Windows guest BitLocker recovery fail? How do I recover from TPM failures or an offline CA? Why are diagnostics inconclusive or misleading? Why can't I install or prepare the platform? Resolve platform failures before investigating HGS policy. A feature name appearing in a script doesn't establish that the target system supports it. Failure mode or symptom Likely causes Resolution overview HostGuardian isn't available or the host can't become guarded. The Hyper-V host runs an unsuitable Windows Server edition or release. Use a supported Datacenter edition for guarded Hyper-V hosts. Don't confuse this requirement with HGS servers, whose role is available in Standard and Datacenter. Check the Windows Server 2025 edition inventory. The HGS role is installed on a Hyper-V host, but attestation support is missing. HostGuardianServiceRole was confused with the host-side HostGuardian feature. Install the correct host features on the guarded host and deploy HGS on its separately administered servers. Installing the HGS role doesn't enroll the local Hyper-V host or shield its VMs. A required cmdlet, module, or wizard is missing. Missing RSAT/provisioning tools, wrong machine or PowerShell environment, unsupported parameter, or incomplete feature installation. Check Get-WindowsFeature , Get-Command , module source/version, and installed help on the machine that performs that stage. Install the documented tools there. Don't move owner secrets to a host just because the host has more tools. A graphical shielding-data or template wizard won't run on Server Core. The workflow assumes a local Desktop Experience interface. Use the supported PowerShell workflow or a trusted Desktop Experience management system with the required tools. Server Core support for HGS and Hyper-V doesn't imply every graphical preparation tool is available locally. Features or protection settings are configured, but don't take effect. A required restart hasn't occurred, Group Policy hasn't applied, or a policy is configured but not running. Complete the approved maintenance restart and check effective policy and running security services. Distinguish Win32_DeviceGuard configured values from running values. Drain workloads first where necessary. TPM-trusted prerequisites or virtualization startup fail. Missing/disabled TPM 2.0, SLAT, IOMMU, hardware virtualization, UEFI boot, or Secure Boot; incompatible firmware or drivers. Verify actual firmware settings and supported hardware, not only specifications. TPM mode requires UEFI 2.3.1 or later and the relevant protections to function. Replace unsuitable hardware or use a separately approved architecture; don't silently lower assurance. Enabling Host Guardian support or HVCI causes a stop error or device failure. A driver or device is incompatible with virtualization-based code integrity. Keep the host out of placement, preserve the crash evidence securely, and use the supported rollback or recovery path. Obtain compatible OEM firmware/drivers and test the security configuration before returning the host to service. A copied example fails with a particular guest, device, nested-virtualization, or management combination. Support was inferred from ordinary Hyper-V support or an older example. Verify the exact build, guest OS, protection policy, device feature, and operation. Use an explicitly supported combination. A successful unshielded-VM test isn't support evidence for the shielded equivalent. References Guarded-host prerequisites: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-guarded-host-prerequisites Windows Server edition comparison: https://learn.microsoft.com/windows-server/get-started/editions-comparison?view=windows-server-2025&preserve-view=true Guarded-host troubleshooting: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-hosts Get-HgsTrace: https://learn.microsoft.com/powershell/module/hgsdiagnostics/get-hgstrace?view=windowsserver2025-ps&preserve-view=true Test-HgsClientConfiguration: https://learn.microsoft.com/powershell/module/hgsclient/test-hgsclientconfiguration?view=windowsserver2025-ps&preserve-view=true Why does HGS deployment or service operation fail? The HGS cluster supplies attestation and key protection. It is separate from the Hyper-V cluster that provides workload availability. Failure mode or symptom Likely causes Resolution overview The role installs, but no working HGS forest or service exists. Role installation was mistaken for forest creation and HGS initialization. Complete the documented Install-HgsServer and Initialize-HgsServer stages, with the correct identity, certificates, and restart boundaries. Inspect Get-HgsServer ; a successful role installation alone isn't completion. New-forest setup or domain-controller promotion fails. Incorrect starting domain membership, DNS/network configuration, permissions, name conflicts, or an incomplete previous attempt. Review deployment and AD DS events, correct the actual prerequisite, and follow the supported installation/recovery path. Don't experiment by deleting AD or cluster objects. Preserve DSRM recovery credentials separately. HGS can't be deployed correctly in an existing forest. Attempted deployment in a child domain, inadequate privileges, or unsuitable bastion-forest design. Deploy in the existing forest's root domain using the documented prerequisites. If the forest isn't an isolated, highly privileged security boundary, redesign rather than accepting fabric-administrator control over HGS. An additional HGS node won't join or initialize. The new node can't resolve the existing forest, credentials can't join/promote it, a reboot is outstanding, or the existing-node address is wrong. Restore domain connectivity and authorized enrollment, then initialize against a reachable existing HGS node. Verify domain, cluster, and HGS membership rather than assuming one implies the others. HGS fails after losing a node or during maintenance. Insufficient healthy nodes, quorum or cluster-network failure, insufficient remaining capacity, or a shared failure domain. Restore cluster communications and healthy capacity using the approved cluster recovery plan. Service one node at a time. Don't force quorum or remove cluster state without a recovery decision and evidence. Requests intermittently fail through a healthy-looking service name. One HGS node has stale policy, broken TLS, unusable keys, a failed application pool, or an HSM access problem. Correlate failures with the responding node. Exercise attestation and key release on every node while preserving service-name validation. Repair or safely remove the failing node from service; one successful clustered request isn't sufficient. The KPS application pool can't use its service identity. HGS node computer accounts can't retrieve the gMSA password, AD replication is unhealthy, or service identity configuration changed. Repair the specific gMSA retrieval permissions and AD/service configuration. Separately check private-key permissions. Don't replace the gMSA with a broad administrator account. KPS returns HTTP 500 with a required-privilege or security-audit-source error. The HGS gMSA lacks Generate security audits ( SeAuditPrivilege ), often after security-policy hardening. Restore the documented user right through the controlling policy on every HGS node. Preserve required default principals as well as the gMSA: assigning this right replaces, rather than appends to, the existing list. A JEA reviewer can't connect or can't run a requested command. Wrong microsoft.windows.hgs endpoint, incorrect role membership, WinRM authentication/listener failure, or a command outside the delegated role. Repair the endpoint and authenticated remoting path. Use reviewer access for inspection and the authorized HGS administrator role for changes. A reviewer being unable to edit policy is expected, not grounds for granting Domain Admins. The entire fabric can't start after a power or site outage. Virtualized HGS, DNS, identity, or backup-access services depend on shielded VMs that need the unavailable HGS. Restore an independently bootable recovery path. Place essential recovery services and credentials outside that circular dependency. A production architecture must be able to start its security dependencies before protected workloads. HGS becomes slow or times out during a restart wave. Simultaneous attestation/key-release demand, HSM latency, resource exhaustion, or too much capacity removed for maintenance. Measure the constrained resource, restore capacity, and stagger starts or maintenance. Validate latency and key access under representative load. Longer timeouts alone don't repair unavailable keys or failed attestation. References HGS troubleshooting: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-fabric-hgs Managing HGS: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs HGS deployment prerequisites: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs Why can't hosts or owners reach the correct HGS service? Check transport and service identity before changing host trust. The host's Attestation and KeyProtection URLs and the owner's metadata URL serve different operations. Failure mode or symptom Likely causes Resolution overview The HGS service name doesn't resolve or resolves to the wrong nodes. Missing/stale DNS records, incorrect conditional forwarders, wrong DNS suffix, or use of a node name instead of the distributed service name. Correct authoritative records and forwarding, then verify resolution from each affected host and owner-management system. Don't use an IP-address URL to bypass a TLS-name failure. TCP 443 or required deployment/domain traffic is blocked. Routing, firewall, VLAN, network ACL, or segmentation changes. Restore only the required documented flows for HGS, AD DS, cluster operation, and management. Opening HTTPS alone doesn't satisfy forest creation, replication, gMSA, or cluster dependencies. TCP succeeds but HTTPS authentication fails. Expired/not-yet-valid TLS certificate, service-name/SAN mismatch, wrong binding, missing private key, or an untrusted chain. Correct the endpoint certificate and binding on the affected nodes, validate time, and distribute the verified public trust chain to clients. Retain name and chain validation. TLS identity is separate from HGS guardian authorization. TLS works on one computer but not another. CA trust was deployed only in the HGS forest, an intermediate was put in the root store, or client policy hasn't applied. Install verified roots and intermediates in their correct local computer stores using the appropriate domain or owner policy. HGS-forest Group Policy doesn't configure hosts in another forest or independent owner systems. Chain validation is slow or fails despite the root being installed. Required intermediate discovery, CRL, or AIA endpoints are unavailable; certificate dates or trust policy are wrong. Repair the relevant PKI publication and network paths and inspect chain-validation errors. Don't globally disable revocation checks. HGS service-key revocation semantics aren't a reason to ignore TLS trust failures. A service URL returns an unexpected page, 404, or the wrong service. Incorrect protocol/path, wrong HGS instance, or proxy/routing configuration. Compare client settings with the intended Get-HgsServer output and use the correct /Attestation and /KeyProtection paths. Confirm the intended organization and guardian keys before accepting metadata. Requests fail only through an inspection, load-balancing, or WAN path. The intermediary changes protected traffic, routes to unhealthy nodes, or introduces an unsupported TLS/proxy configuration. Compare with an approved direct service path, preserve errors, and correct the intermediary design. VMM specifically documents provisioning failures when packets are modified in transit. Don't weaken message validation to accommodate rewriting. HGS breaks after HTTPS hardening. The required HTTP IIS binding was removed, or TLS settings became incompatible with the client stack. Restore the supported HGS binding configuration; retain HTTP binding as documented while using approved network controls for access restrictions. Investigate protocol compatibility separately. Don't re-enable obsolete TLS versions as the default fix. Health certificates appear expired or not yet valid; Kerberos also fails. Time drift among hosts, HGS nodes, domain controllers, or the management system. Restore trusted time synchronization first. If HGS's internally managed attestation signer remains invalid, follow its documented renewal-task procedure. That certificate isn't the administrator-provided KPS signing certificate. Hosts contact an old service or lose fallback after a configuration edit. Stale endpoints or a Set-HgsClientConfiguration call omitted the fallback parameters. Inspect all four endpoint values and restore the approved primary/fallback pairs. Omitting fallback parameters clears that configuration. Recheck both services' policies and keys; URL configuration doesn't synchronize them. References HGS certificates and HTTPS: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-obtain-certs Set-HgsServer: https://learn.microsoft.com/powershell/module/hgsserver/set-hgsserver?view=windowsserver2025-ps&preserve-view=true HGS troubleshooting: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-fabric-hgs Fallback configuration: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-branch-office Why do certificate enrollment, import, or private-key operations fail? Identify the certificate's purpose before repairing it: HGS signing, HGS encryption, HTTPS, host-key identity, owner identity, template signing, and guest endpoint identity aren't interchangeable. Failure mode or symptom Likely causes Resolution overview A standalone CA request stays pending or no certificate file is returned. Administrative approval is required; submission was mistaken for issuance. Record the request ID, have the CA administrator authenticate and approve the request, and retrieve the issued certificate. Don't repeatedly generate new keys while waiting for approval. Certificate enrollment fails with a template or CA configuration error. An enterprise-template procedure was applied to a standalone CA, the ComputerName\CAName value is wrong, or enrollment access is unavailable. Use the correct CA and enrollment workflow. Standalone CAs don't use certificate templates; put the required properties in the request and have the CA administrator review the issued result. HGS rejects a signing/encryption certificate or crypto operations fail. Legacy CSP rather than KSP, unsuitable algorithm/key size, missing usages, or a vendor provider mismatch. Obtain the documented HGS certificate profile: KSP, RSA of at least 2048 bits, required signing/data-encipherment usages and Server Authentication EKU. Verify the issued certificate rather than assuming the request was honored. Certificate acceptance succeeds but the private key is absent. Only a public .cer was imported, acceptance occurred on a different computer from the request, or the original key was lost. Accept against the original request/key or restore an approved PFX/provider-backed key. A public certificate can't recreate its private key. Reissuing with a different key is a rollover, not recovery of the original. PFX import or export fails. Wrong password, damaged file, inaccessible path/store, missing private key, or intentionally nonexportable/HSM-backed key. Verify the intended artifact and authorization. Use the original protected PFX/password or the provider's supported provisioning and recovery method. Don't try to make a nonexportable key exportable as an incident shortcut. A certificate shows HasPrivateKey , but HGS can't use it. The gMSA lacks access, the provider can't open the key, or the key is available only under another identity. Verify actual cryptographic use under the HGS service identity and repair the minimum private-key/provider permissions. Key association, file access, and successful service use are separate checks. A new HGS node has certificate objects but can't release keys. Thumbprint-referenced private keys weren't installed or authorized on that node. Provision the original private-key access on every node. PFX-provided HGS keys can replicate; thumbprint references don't replicate their private keys. Test each node before admitting traffic. HSM-backed operations fail or become intermittent. HSM outage, network/session failure, missing KSP/driver, inaccessible key set, authorization change, or HSM capacity exhaustion. Use the vendor-supported health and recovery procedures, restore the correct key set, and verify node and gMSA access. Don't create unrelated replacement keys or export keys into an unapproved software store. HTTPS fails after adding a node or renewing certificates. TLS certificates/bindings were assumed to replicate with HGS service keys. Configure the approved TLS identity and private-key access on each node. Test service-name and chain validation from hosts. TLS deployment and HGS signing/encryption-key replication are different processes. A service or host-key certificate expires, but authorization continues. Expiry was incorrectly treated as key withdrawal. This can be expected: HGS uses its signing/encryption certificates as key containers, and host-key attestation registers the public key rather than enforcing certificate expiry. Explicitly retire the relevant service key or host registration. TLS expiry still affects transport. Importing guardian metadata fails even though the service still uses those keys. Owner-side certificate checks reject an expired or untrusted guardian certificate. Authenticate the fabric and keys independently, repair trust or obtain appropriate updated metadata/certificates through an approved process. Don't normalize untrusted-root/expiry bypasses. Import-time validation and HGS's use of registered keys have different semantics. Old VMs fail after a certificate was renewed with the same subject. Renewal generated a new key pair; the subject stayed the same but cryptographic identity changed. Recover the original uncompromised key if available, or perform owner-authorized existing-KP updates as a planned rollover. Inventory retained backups and PDKs before retiring the old key. References Obtain certificates for HGS: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-obtain-certs Certificate and gMSA troubleshooting: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-fabric-hgs HGS key management: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Create a host key: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-host-key What do HGS client attestation results mean? Inspect AttestationStatus , AttestationSubStatus , the service contacted, and the event timeline together. Don't equate a previously successful result with a fresh test of the current configuration. Result Interpretation Resolution overview NotConfigured The client isn't configured for HGS-backed attestation/key protection; it can be in local mode. Configure the approved HGS endpoints and retest. Local vTPM operation isn't proof of guarded-fabric protection. Unknown No usable attestation result is available, commonly because attestation hasn't yet been attempted. Check configuration, initiate a fresh supported client test, and collect diagnostics. Don't treat the absence of a rejection as acceptance. TransientError A networking, service, or other temporary failure prevented completion. Correlate DNS, TLS, IIS, HGS-node health, and timing. Retry after the underlying condition is repaired rather than repeatedly re-enrolling the host. Expired A previously issued health certificate is no longer valid. Check clocks and service reachability, then obtain fresh attestation. Investigate renewal failures if the condition recurs. UnauthorizedHost The presented identity isn't admitted under the active mode. Compare the actual TPM identity, host public key, or legacy AD group identity with the applicable registration. An AD-group membership repair is relevant only to AD-based attestation. TpmError The host couldn't complete TPM-related attestation work. Review TPM, firmware, and measured-boot evidence; check TPM readiness and OEM updates. Don't clear or replace the TPM before assessing protected-state and recovery consequences. InsecureHostConfiguration One or more enabled host security requirements aren't satisfied. Follow the actual substatus and verify effective host state. Correct unintended drift or approve a justified policy/evidence change; don't disable every failed check. Passed but the VM still fails Host admission succeeded; VM guardian authorization, provisioning, guest encryption, and migration authentication weren't thereby proven. Move to the failing later layer. Inspect KPS and the VM's existing KP for key-release errors, or provisioning/guest/migration evidence for later failures. References Attestation status and substatus reference: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-hosts Why does a TPM-trusted host fail a specific security check? The following substatuses describe the physical Hyper-V host, not the guest vTPM. Confirm the exact spelling and policy behavior on the installed build. Failure mode or substatus Likely causes Resolution overview TPM registration reports a missing or untrusted endorsement-key certificate. Export wasn't elevated, the OEM didn't provision the certificate as expected, or HGS lacks the TPM manufacturer's trust chain. Export the identifier with appropriate privileges, investigate missing certificates with the OEM, and install verified manufacturer roots/intermediates in TrustedTPM_RootCA and TrustedTPM_IntermediateCA on every HGS node. The HGS TLS CA isn't the TPM manufacturer CA. A replacement host or TPM isn't recognized. Enrollment describes the old physical TPM, even if the hostname is unchanged. Verify the new hardware's provenance and security configuration, enroll its actual identity, and withdraw the retired identity from all applicable HGS services. Don't reuse another host's identifier file. SecureBoot Secure Boot isn't enabled or the required boot trust configuration isn't in use. Enable Secure Boot with the Microsoft Secure Boot template. Investigate incompatible or revoked boot components; don't repair by leaving Secure Boot disabled. SecureBootSettings Current measurements don't match approved baselines, including after firmware, DBX, boot-authority, or debug-setting changes. Explain the measurement change. Roll back unintended drift or capture and approve a new baseline from a verified configuration. Use a baseline appropriate to that hardware/firmware class. VirtualSecureMode VBS isn't running, despite possible policy configuration. Check firmware virtualization, platform protections, effective policy, hypervisor startup, driver compatibility, and required restart. Verify the running protected environment before reattestation. HypervisorEnforcedCodeIntegrityPolicy Hypervisor-enforced code integrity isn't active or isn't enforced as required. Correct HVCI configuration and incompatible components, activate the intended policy, and verify runtime state. An audit-only policy or a registry setting alone doesn't prove enforcement. CodeIntegrityPolicy The active CI policy is missing, stale, or not registered with HGS in the expected form. Compare the deployed policy and registered approved unsigned binary. Activate the intended enforced policy and register its matching measurement through change control. See the next section for policy-deployment failures. Iommu IOMMU/DMA protection is unavailable, disabled, or not required by the host's VBS configuration. Enable supported hardware and the required VBS DMA protection; replace unsuitable hardware if necessary. Disabling the HGS requirement changes the threat model. PagefileEncryption Host paging-file encryption isn't enabled as required. Apply the supported encrypted-paging configuration and any required restart, then reattest. This check concerns host paging data, not guest BitLocker volumes. FullBoot The host resumed from sleep or hibernation rather than completing the required full boot. Arrange a controlled full restart with workloads drained. Verify the restart path instead of repeatedly resuming the host. HibernationEnabled Host hibernation configuration doesn't meet admission policy. Apply the approved no-hibernation configuration and restart. Don't relax the policy merely to preserve a sleep/resume operational practice. DumpsEnabled Dumps are enabled while policy requires them disabled. Disable the disallowed dumps. If operational requirements justify encrypted dumps instead, use an explicitly approved HGS dump-policy design rather than an ad hoc exception. DumpEncryption Dumps are permitted but not encrypted as required. Disable dumps or configure supported dump encryption according to policy. Protect diagnostic collection as potential tenant-sensitive material. DumpEncryptionKey The host encrypts dumps with a key that HGS doesn't recognize. Use an approved dump-encryption key and register its correct hash/policy with HGS. Preserve the independent private-key recovery authority needed to read an authorized dump. TcgLogVerification Measured-boot log retrieval/verification fails because of firmware, TPM, hardware, or an outdated PXE network boot program. Collect TPM/boot evidence, review boot order, update approved firmware and PXE components, and involve the OEM where necessary. Don't register an unverifiable log as an accepted baseline. BitLocker An enabled HGS host-BitLocker policy isn't satisfied. Verify and restore the required protection of the host OS volume. This policy is disabled by default and is independent of guest encryption. Don't change it without the HGS policy owner's decision. All artifacts seem present, but attestation still fails or unexpectedly uses an older version. Incompatible identity/baseline/CI artifact versions, a version setting retained during upgrade, or matching legacy artifacts that permit fallback. Inventory actual versions and installed command interfaces. Establish a complete approved version-2 path, then retire unapproved version-1 artifacts. Don't invent a version parameter or downgrade to bypass endorsement validation. Failure follows TPM clearing, security reset, or replacement even though the server still boots. TPM-protected or VBS identity material changed; previously sealed state or offline caches aren't usable. Recover host security configuration and re-establish online attestation/key release under the approved identity. Use independent recovery material for affected encrypted host data. A TPM reset isn't a harmless inventory operation. References Guarded-host security checks: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-hosts TPM artifact capture and versions: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware Trusted TPM roots: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-install-trusted-tpm-root-certificates HGS attestation policies: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Why do code integrity policy changes break the host? App Control for Business code integrity controls what can run. HGS checks whether the host is using an approved policy; it doesn't certify that every allowed program is safe. Failure mode or symptom Likely causes Resolution overview An approved driver, backup agent, or management tool is blocked. Missing allow rules, an overly narrow rule, or an update invalidated a hash rule. Examine CodeIntegrity events and verify the publisher/package. Update only the necessary approved rules, validate in audit on a reference system, and deploy/register the enforced policy through change control. No audit events appear, but enforcement later breaks workloads. The audit policy wasn't active, or the test didn't exercise the relevant workload. Verify the policy is active after deployment/restart, then exercise backup, management, drivers, servicing, and recovery. An empty log without representative activity isn't evidence of compatibility. HGS rejects a host after a signed CI policy is registered. The signed wrapper or a different binary was supplied instead of the matching unsigned measured policy. Register the correct unsigned form corresponding to the deployed signed policy. Don't remove signed-policy protection from the host merely to simplify registration. CI deployment reports a missing provider or policy-format error. The single-policy update provider isn't available, or the tool, file format, and target build don't match. Verify the installed provider/tool and supported policy format. Validate both local enforcement and HGS measurement; support for CiTool or multiple policies alone doesn't prove that a particular HGS combination works. A policy file was updated, but the host still presents the old policy. Deployment targeted the wrong location, activation failed, a restart is required, or signed update rules rejected the change. Inspect the active policy and deployment events. Use the supported activation/update procedure and required restart. Don't repeatedly register different HGS artifacts to conceal an inactive host policy. A signed policy prevents boot or can't be replaced. Required boot components were blocked, the authorized update signer is unavailable, or signed-policy recovery wasn't prepared. Use the approved signed-policy recovery/update process with retained signing authority and recovery access. Preserve evidence and restore a known-good policy; don't arbitrarily delete EFI or protected policy files. Attestation passes with an unexpectedly permissive software configuration. A broad publisher rule, audit policy, obsolete policy, or other unintended admission artifact remains accepted. Review enforcement and policy scope, remove unapproved artifacts after impact analysis, and test rejection of a representative unapproved configuration. A Passed result can expose a policy-design failure rather than prove strong protection. References TPM and CI preparation: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware Deploy App Control policies: https://learn.microsoft.com/windows/security/application-security/application-control/app-control-for-business/deployment/deploy-appcontrol-policies-with-script HGS policy management: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Why do host-key or legacy AD-based attestation fail? Host-key possession, AD group membership, and TPM-backed measured health are different admission mechanisms. HGS has one active attestation mode. Failure mode or symptom Likely causes Resolution overview A host key was registered, but the host is still rejected. HGS is using another mode, the client presents another key, or the required version isn't active. Compare HGS mode/version with the host's actual public key and registration. Stage a service-wide mode change only after all affected clients are ready; registration doesn't switch the mode. Host-key attestation fails after rebuild, rotation, or inventory scripting. The local key was regenerated, lost, or replaced without enrolling the new identity. Identify the intended key and its provenance. Enroll an approved replacement on every applicable HGS service and withdraw the old registration. Don't run key-generation commands as read-only inventory. A custom host-key certificate can't be used. Missing/unusable private key, wrong provider permissions, or an unsuitable certificate profile. Verify the documented host-key profile and private-key usability. Custom certificates require the appropriate RSA key, Client Authentication EKU, and Digital Signature usage; don't substitute the KPS or TLS certificate blindly. A host with unapproved drivers still passes host-key attestation. Key possession was mistaken for measured-health validation. This is a design limitation, not a driver-detection bug. Use TPM-trusted attestation when measured boot and CI assurance are required. Don't describe a host-key success as evidence of a clean software state. Removing one hostname doesn't reliably deauthorize a host, or an expired certificate still works. Another registration refers to the same key, the key is shared/copied, or certificate expiry was mistaken for withdrawal. Identify and withdraw the actual public-key authorization everywhere. Assess every host holding that private key and move to distinct protected identities. Validate the installed removal interface; don't guess a cmdlet or policy name. Many hosts fail after switching attestation modes. Required artifacts weren't staged, mode changes haven't reached all nodes, or clients are incompatible. Inspect mode on each node and the client population. Complete the approved transition or controlled rollback, then collect fresh results. Don't delete the old enrollment before the approved replacement path is proven. A legacy AD-authorized host is rejected after group or domain changes. Wrong registered group SID, stale computer-account group membership, failed required trust, or DNS/Kerberos/time failure. Repair the documented AD-based trust and group path, refresh machine membership as required, and retest. Recreating a group with the same name doesn't preserve its SID. This isn't a fix for TPM or host-key mode. A workgroup host is rejected solely because it isn't in the HGS domain, or AD mode is assumed removed. Domain requirements or deprecation were misinterpreted. TPM and host-key attestation don't require joining the HGS forest. Diagnose actual admission evidence. AD-based attestation is deprecated, not automatically removed; maintain only required legacy use and plan a supported migration. References Host-key preparation: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-host-key Attestation-mode transitions: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-upgrade-to-2019 HGS management: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Why does attestation pass but a VM still can't obtain its keys? Investigate KPS, the VM's existing KP, and guardian identities. A host may be eligible to run some owners' VMs while correctly being denied access to others. Failure mode or symptom Likely causes Resolution overview One VM fails while other shielded VMs start on the same host. Its KP doesn't authorize the available fabric keys, an old key was retired, or the VM's protected state is inconsistent. Preserve the current KP and compare its guardian identities with KPS keys and the recent change record. The owner authorizes any KP update; HGS administrators restore approved service-key usability. A VM fails only at a recovery site or new destination. The destination passes attestation but its fabric guardian isn't authorized by that VM. Have the owner grant the approved recovery guardian access to the existing KP, preserving its secret. Configure future PDKs separately. Storage access and host admission don't authorize the destination. KPS reports an unwrap/key-protection failure for many VMs. Wrong KPS endpoint, unavailable signing/encryption keys, disabled keys, invalid health evidence, or a service/private-key failure. Correlate KPS and client events, validate fresh attestation, and check the complete required key set on every node. Don't weaken attestation or copy owner keys to hosts. Updating a PDK or making HGS keys primary doesn't repair an existing VM. Those operations don't rewrite the deployed VM's KP. Use the owner-authorized grant/revoke workflow on the existing KP. Treat the PDK as a future-provisioning artifact and retain the original PDK for its recovery role. Owner guardian creation or KP changes fail with missing-key/access errors. Only public metadata is present, the wrong certificate store or identity is used, or owner private-key access is missing. Restore and authorize the matching owner keys on the owner-controlled management system. Validate actual use, not just HasPrivateKey . Fabric-administrator membership isn't owner authority. A KP export can't be parsed or fails after a file transfer. Binary data was formatted as text, truncated, overwritten, or confused with another VM's KP. Retrieve an authentic lossless byte export and preserve its VM/version association. Keep protected originals and authenticated handoffs. Don't reconstruct bytes from a console display. A returned KP is stale or conflicts with the VM's current state. The VM started during the exchange, another operator changed it, or the wrong export/return pair was used. Stop the exchange and reconcile current state under owner control. Keep the VM off for the complete approved update and use distinct artifact names. Don't apply a stale result simply because the command accepts bytes. Grant succeeds but required revocation or export fails. An incomplete workflow left a partial or old staged return file. Treat the whole change as failed. Don't transfer a grant-only result when revocation was required. Preserve the original and create a new fully verified return artifact only after every required operation succeeds. A VM becomes inaccessible after attaching a new or local KP. The unrelated KP doesn't preserve the secret associated with existing vTPM/protected state, or authorization was weakened. Stop further changes. Use an approved matching rollback KP/consistent backup or owner recovery path. Last-known-good rollback is appropriate only if it doesn't restore withdrawn trust. A new PDK KP isn't a repair for an existing VM. Guardian names match, but authorization still fails. Friendly names or certificate subjects were mistaken for cryptographic identity; metadata came from another fabric or predates rollover. Compare authenticated signing/encryption key identities and the actual KP content. Obtain approved metadata independently of its filename or display name and authorize the intended keys. Owner keys are lost while some VMs continue to run. Current KPS authorization still works, but owner update/recovery authority is unavailable. Preserve running availability and remaining recovery options while retrieving independent owner-key backups. Plan owner-authorized recovery/reprotection if possible. Continued operation isn't proof that future KP updates or disaster recovery remain possible. A KP exchange fails while reading or writing its staging files. The directory exists only on the other computer, a file occupies the directory path, permissions are wrong, an output name is already in use, or another operator changed the staged artifact. Prepare and restrict the host-side and owner-side directories independently. Use unused filenames, preserve original exports, coordinate concurrent access, and stop on every failed read/write. Don't overwrite a retained KP or send an unverified partial file. Also see the module's existing-KP exchange procedure. References HGS key rollover: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Grant KP access: https://learn.microsoft.com/powershell/module/hgsclient/grant-hgskeyprotectoraccess?view=windowsserver2025-ps&preserve-view=true Revoke KP access: https://learn.microsoft.com/powershell/module/hgsclient/revoke-hgskeyprotectoraccess?view=windowsserver2025-ps&preserve-view=true Why do template preparation or image validation fail? The publisher prepares and signs the template; the owner decides whether to trust it. Signature integrity isn't a substitute for approval of the image's contents. Failure mode or symptom Likely causes Resolution overview Protect-TemplateDisk rejects the disk or the Windows template can't boot correctly. Wrong VM generation, MBR rather than GPT, dynamic guest disk, unsuitable partitions, or wrong Windows-volume filesystem. Prepare the supported generation 2 Windows layout: GPT, a basic guest disk, correct EFI/boot partitions, and an NTFS Windows volume. A dynamically expanding VHDX is not a Windows dynamic disk. Don't format the EFI system partition as NTFS. Specialization fails across every VM from a template. The source wasn't generalized, Windows updates/setup are incomplete, or a required guest component is missing. Repair and validate the retained servicing source, complete supported generalization, and create a fresh protected copy. Don't repair the sole signed template in place. Template signing fails. Missing or inaccessible publisher private key, wrong certificate/profile, unsuitable preparation tools, or an inaccessible disk. Verify the publisher's approved signing identity, key usability, tools, and disk access. Keep publisher private keys in the publisher-controlled preparation environment. Template protection is interrupted or runs out of space. Insufficient storage, file locks, I/O failure, or process interruption during an in-place transformation. Preserve evidence and the failed copy, correct the dependency, and restart from the known-good unprotected servicing source. Don't distribute a partially transformed disk with an old catalog. A protected template fails when booted as an ordinary VM. A secure-provisioning template was used as a normal boot disk. Use the supported shielded provisioning path. For servicing, return to the unprotected source. Booting the protected template as an ordinary VM isn't a supported validation method. The PDK and VSC aren't applicable to each other. Wrong template identity, publisher, version rule, catalog, or PDK type. Compare the owner's approved template identity and exact version semantics. Supply the correct signed artifacts or obtain approval for a new version. Don't broaden acceptance merely to eliminate the mismatch. Applicability passes, but actual provisioning rejects the disk. The supplied VHDX changed after signing or doesn't correspond to the catalog. Quarantine the disk, investigate substitution or corruption, and obtain the authentic protected image. Retest actual disk validation, not just the PDK/VSC relationship. A signed image or later accepted version contains unapproved software. Publisher compromise, weak source-image review, or overly broad future-version trust. Contain affected deployments, investigate the publishing authority, and rebuild from approved sources. Tighten version/publisher approval and rotate affected secrets. A valid signature doesn't establish that the software is benign. References Windows shielded template preparation: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template Owner shielding-data preparation: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data Why do shielding-data creation and VM provisioning fail? Keep PDK creation, template validation, VM configuration, and guest specialization separate. A visible VM object or returned helper object isn't proof of successful provisioning. Failure mode or symptom Likely causes Resolution overview PDK creation fails or required guardian/qualifier inputs are missing. Missing owner keys/tools, wrong guardian selection, malformed input, inaccessible files, or a new-template/existing-VM parameter-set mismatch. Use the correct workflow on the trusted owner system, validate all inputs, and select the intended owner, fabrics, and image qualifiers. Preserve the original encrypted package after creation. Provisioning can't read the PDK, VSC, template, or specialization file. Wrong path, file permissions, incomplete transfer, corrupt artifact, or inaccessible library/share. Restore authenticated intact artifacts and minimum required read/write access for the provisioning identity. Check storage locally and remotely. Don't grant broad access to plaintext owner files. New-ShieldedVM isn't found or behaves differently from the example. Missing/unapproved GuardedFabricTools version, command shadowing, dependency mismatch, or unsupported target-build behavior. Verify command source and the reviewed package version, including nested modules and installed interfaces. The module's pinned 1.1.1 example isn't evidence of universal Windows Server 2025 compatibility. Don't bypass execution policy or import an unreviewed replacement. A generation 2 VM exists but isn't actually shielded or fully provisioned. Only New-VM , vTPM enablement, or state-encryption settings were applied; the owner's policy and initialization were omitted. Use a validated complete orchestration that applies the PDK-derived policy/KP and secure provisioning. Inspect resulting firmware/security state and provisioning status. Don't invent a Set-VMSecurity -ShieldingRequested parameter. VM creation or template copy fails before specialization. Insufficient disk space or memory, invalid path, conflicting VM name, missing virtual switch, permissions, or storage failure. Correct the specific capacity/configuration issue and reconcile partial artifacts before retrying. The example CPU/memory values aren't capacity recommendations for every workload. Specialization hangs or Windows setup reports an input error. Invalid unattend XML, missing placeholder, invalid product key, unsupported setup setting, or script failure. Validate the owner's answer file and supplied values against the target image. Reproduce with nonsecret test data in an isolated owner-approved lab. Correct the PDK for a controlled new attempt; don't downgrade a production VM's policy for console access. Computer naming, networking, or enrollment fails during setup. FSK tokens don't match owner-approved placeholders, address/DNS data is wrong, duplicate names/IPs exist, or domain-join credentials/connectivity fail. Reconcile exact placeholders and the intended network/identity services. Keep credentials inside owner-controlled encrypted inputs, not fabric-readable specialization values. A guest setup script or endpoint certificate isn't installed. A file referenced by the answer file wasn't included in the PDK, the path is wrong, or required secret access isn't available. Have the owner correct package contents, paths, and setup logic. Verify the resulting guest endpoint identity. Don't expose private certificates to the fabric to work around packaging errors. A helper returns without an unambiguous success result. An asynchronous job is still running, failed, or wasn't correctly tracked. Inspect Get-ShieldedVMProvisioningStatus and its error details until the outcome is clear. A missing job/status object, running VM, or object returned by a helper isn't a success criterion. A retry fails because the VM already exists or has partial protected state. Creation/initialization was rerun blindly against an interrupted deployment. Isolate the failed instance, preserve logs and artifacts, and use the workflow's supported cleanup/retry procedure under change control. Don't overwrite a working VM, its disks, or its KP. Existing-VM conversion fails or leaves encryption incomplete. A new-template recipe was reused; generation, disk layout, guest, helper, or conversion prerequisites aren't satisfied. Take a recoverable backup and use a supported conversion path with owner approval and downtime. Verify actual volume encryption. Adding a vTPM alone neither encrypts existing disks nor removes old plaintext copies. Newly provisioned VMs share credentials or unintended identities. A reusable PDK/answer file hard-codes per-VM secrets or names. Stop further deployment, repair the owner-controlled identity/credential lifecycle, and rotate affected credentials. Reissue approved packages. Successful provisioning can still represent a serious configuration failure. References Create shielding data: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data Create a shielded VM with PowerShell: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-using-powershell ShieldedVMProvisioning reference: https://learn.microsoft.com/powershell/module/shieldedvmprovisioning/?view=windowsserver2025-ps&preserve-view=true GuardedFabricTools package: https://www.powershellgallery.com/packages/GuardedFabricTools/1.1.1 Why can't the owner access the guest or confirm its protection? Once provisioning and key release succeed, distinguish network access, guest authentication, guest boot, and encryption state. The fabric operator and the guest administrator aren't the same security identity. Failure mode or symptom Likely causes Resolution overview The VM runs but RDP, WinRM, or SSH is unreachable. Wrong virtual switch/VLAN, address, DNS, route, guest firewall, disabled listener, or incomplete guest setup. Fabric administrators check the external path; the owner checks guest services and firewall/configuration. Restore the intended management endpoint without changing the KP or exposing guest secrets. The endpoint responds but authentication fails. Wrong, expired, locked, or unauthorized guest credentials; domain/time failure; incompatible authentication configuration. Repair guest/domain identity under owner authority and use a supported authentication method. Fabric membership isn't a guest credential bypass. RDP/WinRM certificate or SSH host-key identity doesn't match expectations. Wrong endpoint, stale deployment identity, certificate renewal/configuration failure, or possible interception. Stop trusting the session until the owner verifies the endpoint through an independent channel. Repair the correct identity and trust configuration; don't routinely dismiss warnings or accept replacement keys blindly. Basic console, debugging, disk inspection, or a security-weakening edit is blocked. The VM's shielded policy intentionally restricts fabric-administrator access. Treat the block as expected protection. Use owner-authenticated guest management or a documented owner recovery path. Don't replace the policy with encryption-supported mode as a routine operational fix. Enhanced Session Mode or PowerShell Direct isn't available. Unsupported host/guest combination, missing guest configuration, owner restrictions, or absent guest credentials. Check version-specific support and owner policy. Where supported, these paths still require guest authentication; their existence doesn't grant an administrator a way around owner authorization. Windows starts only to a BitLocker recovery prompt. Guest boot measurements or vTPM/protected state changed, a recovery condition occurred, or restored state doesn't match. Preserve the recovery point and use the owner's valid OS-volume recovery mechanism. Diagnose guest changes separately from host attestation. Don't reset the vTPM to bypass recovery. A vTPM is enabled, but the OS volume isn't protected. Provisioning didn't complete, BitLocker wasn't enabled, encryption is incomplete, or protection is suspended. The owner inspects volume status, encryption percentage, and protection status inside the guest, then repairs the supported encryption configuration and escrow. Host-side security properties don't prove guest encryption. A data disk is unencrypted or can't unlock after restart/restore. OS-volume shielding was assumed to cover data volumes, or data-volume protectors/normal-unlock dependencies weren't preserved. Establish and verify an owner-controlled encryption, unlock, and recovery policy for every data volume. Escrow the matching recovery material. The OS disk's shielded recovery key isn't a data-disk key. An application is compromised or traffic is readable despite shielding. Guest malware, vulnerable applications, stolen owner credentials, or unencrypted application traffic lie outside the host-isolation guarantee. Apply guest/application incident response, patching, authorization, and network encryption. Host attestation doesn't attest guest application behavior, and encrypted migration doesn't encrypt ordinary workload traffic. An encryption-supported or ordinary VM doesn't meet the malicious-admin requirement. VM policy was confused with host eligibility, BitLocker, or vTPM enablement. Reassess the required protection and use an approved shielding/reprotection workflow where supported. Verify existing copies and exposed secrets. Enrolling a host doesn't upgrade every VM's policy. References Guarded-fabric protection boundaries: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms Shielding-data guest configuration: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data Version-specific management improvements: https://learn.microsoft.com/windows-server/get-started/whats-new-in-windows-server-2019#troubleshooting-improvements Why do live migration, cluster placement, or failover fail? Check both ordinary Hyper-V dependencies and the destination's guarded-fabric eligibility. Neither source-host success nor a healthy HGS cluster proves that a particular destination can run the VM. Failure mode or symptom Likely causes Resolution overview The destination rejects a shielded VM. It fails attestation, can't reach an authorized KPS, lacks the required features, or its guardian isn't in the VM's KP. Validate the destination independently and repair the exact admission/key-release issue. Don't copy owner or HGS private keys onto destination hosts; generic local-vTPM certificate-copy advice isn't an HGS repair. Migration breaks after upgrading to Windows Server 2025. Credential Guard prevents the CredSSP delegation path previously used by live migration. Configure supported Kerberos constrained delegation or resource-based constrained delegation with the AD administrator. Keep Credential Guard enabled. Changing VirtualMachineMigrationAuthenticationType alone doesn't configure AD delegation. Kerberos migration fails with access/delegation errors. Missing/duplicate SPNs, wrong service/account scope, delegation restrictions, DNS/time problems, or an unsuitable initiating identity. Correct the specific Kerberos and constrained-delegation design for migration and, when needed, storage services. Test from the actual initiating identity. Don't enable unconstrained delegation as a generic repair. Migration fails only from a remote management session. The authentication path requires delegation that the remote workflow doesn't supply. Compare local and remote initiation under the approved design and repair supported delegation. Don't assume host attestation supplies credentials for the management second hop. Migration reports processor or VM configuration incompatibility. CPU-feature differences, incompatible firmware/settings, or a VM configuration version newer than the destination supports. Choose a compatible destination or a supported planned compatibility setting. Treat configuration-version upgrades as potentially irreversible for return migration. Don't assume a compatibility switch handles every CPU/vendor difference. Transfer stalls, times out, or stops after starting. Migration-network failure, inadequate bandwidth, packet loss, firewall restrictions, overloaded storage, or concurrency/capacity limits. Identify and repair the failing path or resource, reduce contention, and test at representative load. Preserve state/migration encryption rather than disabling it for throughput. VM storage isn't available at the destination. Missing shared-storage/CSV access, incorrect SMB/storage permissions, absent storage-move parameters, or an unsupported disk/device arrangement. Restore supported destination storage access or use the correct storage-migration workflow. Don't copy an active VHDX and treat it as a consistent VM transfer. Migration succeeds but the workload loses network access. Destination virtual switches, VLANs, network mappings, or guest addressing differ. Correct destination networking and verify owner access and application health. A completed compute move doesn't prove network continuity. Cluster failover can't start the VM even though HGS is healthy. The VM role isn't configured correctly, no eligible node/capacity exists, cluster quorum is lost, or shared resources are unavailable. Repair the workload cluster and placement policy. Registering a clustered VM role adds availability management, not shielding. The Hyper-V cluster and HGS cluster need independent health checks. Resume/import fails with saved-state incompatibility. The saved state is incompatible with the destination build/CPU or the restore set is damaged. Preserve a consistent backup and assess a supported owner-approved cold-start path. Discarding saved memory can lose unsaved work; don't delete vTPM, KP, protected configuration, or disk-chain files as a generic fix. Replica failover or failback fails. Destination host/key authorization wasn't maintained, storage/network mapping differs, or a previously trusted site was withdrawn. Revalidate the selected replica's KP, destination attestation, keys, current policies, and application consistency in isolation. Test failback as a separate operation; replication success alone isn't proof of recoverability. Drain/migration fails while a backup or checkpoint operation is active. A VM is in an incompatible transitional state, a backup lock is held, or checkpoint processing is stuck. Coordinate with the backup product and inspect VMMS/cluster/backup events. Complete or recover the supported operation before retrying. Don't manually delete checkpoint chains or restart shared services without assessing other VMs. Also see the module's destination-eligibility and protected-state guidance. References Credential Guard and Windows Server 2025 migration: https://learn.microsoft.com/windows/security/identity-protection/credential-guard/considerations-known-issues#live-migration-with-hyper-v-breaks-when-upgrading-to-windows-server-2025 Hyper-V migration setup: https://learn.microsoft.com/windows-server/virtualization/hyper-v/deploy/set-up-hosts-for-live-migration-without-failover-clustering Why do servicing, key rollover, or retirement cause an outage? Security evidence and cryptographic dependencies survive beyond the change window. Test both the current workload population and retained recovery points. Failure mode or symptom Likely causes Resolution overview An approved firmware, driver, OS, or Secure Boot update causes rejection. The intended change altered measured evidence or CI rules without coordinated approval/registration. Verify the actual update, stage matching approved artifacts, reattest, and start a protected test workload. Don't authorize unexplained measurements just because the change window was approved. Older hosts fail after HGS policy activation. New checks were activated before all hosts supplied the required evidence. Follow the module's cumulative-update order: guarded hosts first, then HGS nodes, then any separately required policy activation. For OS-version upgrades, use the specific compatibility matrix rather than assuming the same order. OS-version upgrade breaks mixed-version operation. Unsupported host/HGS combinations, old attestation versions, or configuration-version changes. Validate the exact source, target, and intermediate combinations. Stage the supported upgrade sequence and rollback boundaries. An older Windows Server upgrade article isn't blanket approval for every later release combination. New VMs work after key rollover, but older VMs or backups fail. Old KPs/PDKs authorize retired keys, and primary-key selection didn't update them. Restore an approved uncompromised recovery path or have owners update existing KPs. Inventory checkpoints, replicas, backups, and future-provisioning packages before disabling old keys. Some requests fail immediately after new keys become primary. The new key's private half or permissions weren't provisioned on every node. Restore consistent key access on all nodes before completing the transition. Test actual key release; public metadata publication alone doesn't prove usable private keys. An obsolete or weaker host configuration still passes after rollout. Temporary old baselines, CI policies, host registrations, or legacy versions were never retired. End the approved overlap window, withdraw obsolete artifacts with dependency review, and test fresh rejection. Don't keep a permanent weaker fallback simply to avoid documenting exceptions. Retirement destroys service availability or recovery capability. The last usable HGS key/node, required domain service, owner-key copy, or backup dependency was removed too early. Stop retirement, recover approved material where possible, and complete dependency-aware decommissioning. Clear-HgsServer and Uninstall-HgsServer have different domain/cluster consequences and aren't general reset commands. References HGS patching, key management, and decommissioning: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Version-specific upgrade guidance: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-upgrade-to-2019 Why does withdrawing trust not immediately contain an incident? Trust-policy changes affect future authorization decisions. They don't erase already released secrets, stop every running workload, or rewrite historical backups. Failure mode or symptom Likely causes Resolution overview A deauthorized host continues running a shielded VM. The VM already obtained keys; existing health evidence or eligible cached material may remain relevant. Isolate the host and its management/network access under the incident plan, block placement, preserve evidence, and recover on clean infrastructure. Verify future rejection separately from immediate containment. A withdrawn host is still admitted elsewhere. Only primary HGS was updated, another registration/version remains, or a shared host key is still trusted. Inventory every applicable HGS service and actual identity, including fallback and legacy artifacts. Withdraw the correct identity everywhere and test fresh attestation. Don't remove a shared baseline to target one host. HGS or its signing/encryption keys are compromised. An attacker can alter admission or use the fabric's key-protection authority. Rebuild from clean administrative authority, review policy, establish clean keys, and have owners withdraw compromised guardians from existing KPs and future PDKs. Don't blindly restore unreviewed HGS state. An owner guardian key is compromised. The attacker has owner-level authority affecting that ownership group. Assess all dependent workloads and copies. Establish clean owner recovery/reprotection authority through a validated process and rotate exposed guest secrets. Rotating only HGS keys doesn't repair owner-key compromise. A publisher/template-signing key is compromised. Malicious images can be signed as an approved publisher. Stop new provisioning from the affected trust, preserve evidence, rebuild approved images, and revise owner-approved catalogs/version rules and publishing keys. Investigate already deployed images rather than merely re-signing them. Plaintext answer files, PFX passwords, owner keys, or decrypted recovery keys are exposed. Insecure staging, shared folders, transcripts, support bundles, or backup access. Restrict and preserve evidence through incident response, assess which secrets were disclosed, rotate/reprotect as required, and remove unauthorized copies under policy. Deleting one working file doesn't undo exposure. Rotating keys doesn't eliminate the exposure. Plaintext, old KPs, old keys, credentials, or backups were already copied. Assess the full exposure window and affected copies. Reprotect data and rotate guest/application secrets where required. Wrapping-key rotation isn't retroactive erasure. Shielding doesn't prevent deletion, outage, or hostile administration of the whole design. Fabric administrators retain availability control, or HGS/owner/publisher roles aren't genuinely separated. Protect backup retention and independent recovery, enforce administrative separation, and treat collapsed authority as a design failure. Shielding isn't an availability guarantee or protection from every trusted authority. Also see the module's compromise-response unit. References HGS separation of duties and key management: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Protection boundaries: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms What fails when HGS or a site is unavailable? Distinguish a running VM from a cold start. A currently running workload doesn't demonstrate that it can restart, migrate, or recover after another failure. Failure mode or symptom Likely causes Resolution overview Running VMs survive an HGS outage but cold starts fail. Running VMs already have usable material; new starts lack an available authorized release path or eligible cache. Restore primary/fallback HGS or use previously established eligible offline operation. Avoid unnecessary VM/host restarts until dependencies are understood. Don't replace the KP. Fallback URLs are configured, but the recovery HGS rejects the host or VM. Enrollment, policies, keys, TLS trust, or KP authorization weren't maintained independently. Repair the missing approved dependency on the recovery service and host. Distinct fabric keys require owner authorization for that guardian; endpoint configuration doesn't copy policy or keys. Fallback doesn't override a primary security rejection. Availability fallback was mistaken for a way around failed trust checks. Correct the actual security condition. Don't design recovery HGS to accept hosts specifically rejected by primary policy. Fallback is for an unreachable/unresponsive service, not a weaker admission route. Offline caching is enabled, but the VM won't start offline. The host/VM never obtained eligible cacheable material, the build isn't supported, or the VM was only guest-restarted. While HGS is available, perform the required full VM shutdown and start under the approved caching policy, then test an isolated outage. Enabling the service flag alone doesn't populate every VM's cache. Offline startup worked before servicing but fails afterward. CI, Secure Boot, VBS identity, or other security-state changes invalidated the cache. Restore online attestation and obtain new eligible material after the approved change. Don't attempt to carry an old cache across a changed security identity. A cache on one host doesn't help another host or recovery site. Offline material is host-, VM-, and security-state-specific rather than portable recovery authority. Provide the destination with its own valid online authorization and any approved cache eligibility. Full-site recovery requires independent keys and VM backups, not copies of a lost host's cache. Operators expect a host restart to work offline in every case. Cache eligibility was inferred from a prior VM-only start rather than the exact reboot/security-state scenario. Test the intended restart and servicing cases. Maintain online recovery capacity for cases that invalidate eligibility; don't promise offline operation solely from a configuration flag. Disabling caching or withdrawing trust is expected to erase cached secrets immediately. Service policy was confused with deletion of material already released to another system. Apply explicit containment and assess cached/running-state exposure. Use caching only after approving its availability-versus-revocation tradeoff. References Fallback HGS and offline operation: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-branch-office Why do backups or disaster recovery fail? Recover the authorization, keys, and protected state needed by the selected recovery point. A recent VHDX isn't necessarily a recoverable shielded VM. Failure mode or symptom Likely causes Resolution overview VM backups exist, but recovery operators can't access them. Backup identity, DNS, MFA/secret access, repository decryption keys, or storage depends on the failed fabric. Restore independent recovery authority and infrastructure first. Keep tested access to encrypted off-site/offline or immutable copies outside routine fabric control. HGS state import fails. Wrong export password, damaged/incomplete file, uninitialized destination, incompatible build, or unresolved import errors. Verify the protected export, initialize a supported clean HGS destination, and inspect each reported error. Reconcile duplicates deliberately; don't assume a command returning some objects means full restoration. HGS import succeeds but key release still fails. The export contains public references, not the thumbprint-referenced/HSM private keys. Restore the original private keys through their independent recovery method and authorize every node. HGS state import can't reconstruct missing nonexported keys. HGS restores without working DNS, TLS, AD identity, or JEA. Those dependencies were assumed to be part of the HGS state export. Recreate the service identity, domain/cluster configuration, administration, and TLS endpoints as required. Restore legacy AD host-group membership separately; an HGS export preserves group SIDs, not membership. Review policy and then test client attestation and actual VM key release. The restored HGS service admits retired hosts or uses compromised keys. An old or unreviewed export restored historical trust. Review all imported identities, versions, policies, and keys before exposing the service. Remove withdrawn trust under the incident/recovery plan. A usable backup isn't automatically an approved security configuration. Rebuilding HGS with the old certificate names doesn't unlock existing VMs. The new certificates contain different keys. Restore the original uncompromised key material or use surviving owner authority to authorize clean replacement keys in existing KPs. Names can't recreate cryptographic continuity. A disk-only restore can't start the protected VM. VM configuration, KP, vTPM/protected state, or checkpoint-chain dependencies weren't backed up. Restore a supported consistent whole-VM set. If that set is unavailable, assess the separate owner-authorized guest-volume recovery path. Attaching the VHDX to a new VM isn't equivalent to restoring it. A restored VM has BitLocker or state-consistency errors. Disks, configuration, KP, vTPM state, or differencing-disk parents come from different points in time. Recover a consistent known-good set without editing the originals. Preserve disk-chain relationships and use supported backup tooling. Don't mix state files to see which combination boots. A pre-rollover backup can't start or authorizes a compromised guardian. Its KP still depends on historical keys and permissions. Inspect in isolation. Use an approved retained uncompromised key or clean owner-authorized recovery/reprotection. Never re-enable a compromised guardian in production solely for convenience. Backup succeeds but application/item-level restore fails. Crash consistency was mistaken for application consistency, or the product lacks the required shielded-VM/guest-aware support. Verify product/version/operation support and use owner-authorized guest credentials where required. Test application recovery and data integrity, not only successful VM boot. A checkpoint or replica doesn't provide an independent recovery copy. It shares storage, administrative control, chain dependencies, or unavailable keys with production. Maintain separately protected backups and test full restoration. Checkpoints and replication can support recovery operations but don't replace independent retention or recoverable keys. Recovery exceeds RTO or loses more data than the RPO allows. Security dependencies are older than VM backups, retrieval was never rehearsed, or the recovery site lacks capacity/network mappings. Define and test RPO/RTO for HGS, owner keys, KPs, original PDKs, VM state, and applications together. Refresh the recovery inventory after policy/key changes and rehearse dependency-ordered recovery. Recommended order: recover clean authority and backup access; restore power, networks, DNS, time, and required identity services; rebuild/restore HGS and keys; establish eligible hosts/storage; restore consistent VMs; then have owners validate guest and application health. Also see the module's artifact-custody and recovery units. References HGS backup and recovery: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Why does Windows guest BitLocker recovery fail? This is an owner-controlled guest-volume operation, not HGS service restoration. Work on an isolated consistent copy and preserve the original recovery point. Failure mode or symptom Likely causes Resolution overview Save-ShieldedVMRecoveryKey can't find the expected material. Wrong disk, damaged/inaccessible data, or a VM outside the documented eligibility. Select the Windows guest's OS disk and verify provenance. The documented mechanism requires a Windows shielded VM deployed with a PDK created on Windows Server version 1709 or later. Use another valid owner-escrowed protector if this path doesn't apply. Extraction works, but Unprotect-ShieldedVMRecoveryKey fails. Wrong/or newly generated PDK, missing matching owner private keys, or private-key access failure. Retrieve the original deployment PDK and usable matching owner keys on the trusted recovery computer. A replacement file with the same name or an HGS backup isn't equivalent. The recovered file isn't accepted as a typed recovery password. The output is a decrypted .bek key file, not necessarily a numerical recovery-password string. Use the supported BitLocker recovery procedure that accepts the key file for the matching OS volume. Protect the decrypted file as plaintext recovery authority. The OS recovery key doesn't unlock an encrypted data volume. The material is specific to the OS volume; data volumes have independent protectors. Retrieve that data volume's owner-escrowed recovery material. Don't overwrite or remove its protectors while searching for a working key. A correct key doesn't restore a healthy workload. The filesystem/application is damaged, the disk chain is incomplete, or the recovery point is inconsistent. Recover the best consistent backup and use supported volume/application repair on copies. Decryption establishes access, not data integrity or application consistency. Original owner authority and all valid recovery protectors are unavailable. Irrecoverable key loss or destruction of the only consistent recovery artifacts. Exhaust independently retained legitimate recovery sources and assess whether another authorized path remains usable. If none exists, data can be permanently unrecoverable. Fabric-administrator access, new certificates, or a new vTPM don't provide a bypass. After recovery, restore the intended encryption and authorization, validate owner access, and remove temporary decrypted material according to the approved handling policy. References Save-ShieldedVMRecoveryKey: https://learn.microsoft.com/powershell/module/shieldedvmdatafile/save-shieldedvmrecoverykey?view=windowsserver2025-ps&preserve-view=true Unprotect-ShieldedVMRecoveryKey: https://learn.microsoft.com/powershell/module/shieldedvmdatafile/unprotect-shieldedvmrecoverykey?view=windowsserver2025-ps&preserve-view=true How do I recover from TPM failures or an offline CA? Use these recovery sequences when a Hyper-V host or HGS server reports TPM errors, a server stops at BitLocker recovery after a hardware change, or an unavailable certification authority (CA) blocks certificate operations. The host TPM, HGS guardian keys, and CA signing keys have different recovery dependencies. Replacing one doesn't recreate another. How do I recover when a Hyper-V host's TPM fails? Symptoms can include TpmError , a missing or not-ready TPM, or a host BitLocker recovery prompt. Firmware configuration, driver problems, and TPM lockout can resemble hardware failure. Confirm the cause with the server OEM rather than treating every attestation failure as a failed chip. The host's physical TPM is separate from each guest's vTPM. Protect running workloads and collect evidence. Stop new placement on the affected host. Preserve running VMs where safe; don't restart them merely to test the fault. On the affected host, inspect Get-Tpm , Get-HgsClientConfiguration , and TPM, BitLocker, and HostGuardian events. Record recent firmware, motherboard, boot, and policy changes. Retrieve recovery material before hardware changes. Obtain the host's escrowed BitLocker recovery password or other valid recovery protector, plus recovery material for any separately encrypted host data volumes. Preserve accessible, consistent VM backups and their configuration, KPs, vTPM/protected state, disks, and checkpoint relationships. A guest's BitLocker recovery key doesn't unlock the host's encrypted volume. Recover workload availability on an eligible host. If supported migration can still complete, move workloads to a healthy guarded host that passes attestation and can obtain keys authorized by each VM's existing KP. Otherwise, use a supported cluster-failover or consistent whole-VM restore workflow. Don't assume live migration can succeed after the TPM fault. Physical TPM failure doesn't, by itself, permanently bind an intact shielded VM to the failed host. Repair or replace the failed platform component. Follow the OEM's supported hardware and firmware procedure. Use the host recovery protector if BitLocker blocks access. After repair, restore the required TPM 2.0, UEFI, Secure Boot, VBS, and enforced CI configuration. Complete the supported BitLocker post-recovery process so protection uses the intended TPM; verify protection is active and recovery material is escrowed before returning the host to production. Don't leave BitLocker suspended. Register a replacement TPM as a new identity. If the TPM was replaced, capture its actual platform identifier with Get-PlatformIdentifier and have the HGS administrator register it on every applicable primary and fallback HGS deployment. Verify the replacement TPM's endorsement-certificate chain. Reuse existing approved baselines and CI policies only when they still match; approve new artifacts only for an explained configuration change. An old identifier export isn't a backup of the original TPM's private keys. Withdraw the retired host identity without deleting shared baselines or weakening attestation. Prove recovery before resuming placement. Restore the correct primary and fallback endpoints if the host was rebuilt, then obtain fresh attestation with Test-HgsClientConfiguration . Test a controlled shielded-VM cold start and have the owner verify guest access, encryption, and application health. Don't rely on the failed host's old offline cache. Where caching is approved, establish new eligibility with the required full VM shutdown and start while HGS is available. Recovery limit: If the only VM copy is on an encrypted host volume and neither a valid host-volume recovery protector nor an independent backup is available, HGS can't unlock that host volume for you. If only a guest disk survives, assess the separate owner-authorized guest-volume recovery path; creating a new vTPM or KP isn't equivalent to recovering the original VM. References Guarded-host and TPM troubleshooting: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-hosts TPM identity registration and baseline capture: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware BitLocker recovery and post-recovery tasks: https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/recovery-process Offline key-material caching requirements: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-branch-office How do I recover when an HGS server's TPM fails? First establish whether the error concerns the HGS server itself or a Hyper-V host trying to attest. HGS operating in TPM-attestation mode validates the Hyper-V hosts' TPM evidence; that setting doesn't automatically store HGS guardian keys in the HGS server's TPM. This module creates HGS certificates with the Microsoft Software Key Storage Provider. A local TPM failure can prevent the server's BitLocker-protected OS from unlocking or affect other TPM-protected credentials, but it doesn't automatically destroy those software-backed HGS keys. Determine the outage scope. Check individual HGS nodes, not just the service name. Keep healthy nodes serving requests and use the approved maintenance procedure to keep an unusable node out of the service path. Preserve quorum, DNS, and remaining capacity. Avoid unnecessary guarded-host or VM restarts while the available key-release paths are reduced. Secure the available recovery material. Retrieve the affected HGS server's own BitLocker recovery protector before resetting or replacing its TPM. From a healthy HGS node, preserve an up-to-date Export-HgsServerState backup and its password through the approved custody process. Also locate the original HGS private-key backups or HSM recovery capability and the separately maintained TLS material. If no node is available, use the independently retained backups. Repair the node or replace it in the surviving cluster. Recover OS access and repair the hardware through the OEM-supported process, then restore the server's BitLocker protection. If the node can't be repaired, follow the documented procedure to add a replacement HGS node to the surviving deployment. In this module, HGS nodes are domain controllers: coordinate domain-controller replacement and AD health rather than blindly rolling back a server disk image. Losing one node doesn't require rebuilding the entire HGS forest or changing every VM's guardian. Use HGS disaster recovery if the entire cluster is lost. Reestablish the required clean identity, DNS, time, and administration dependencies; install and initialize a replacement HGS deployment; then use Import-HgsServerState with the approved export and its password. Review restored host identities, baselines, CI policies, and withdrawals before admitting workloads. Prefer the documented HGS rebuild-and-state-restore procedure over assuming a whole-server image reconstructs the distributed service. Restore usable keys on every node. PFX-based keys can be restored from the HGS export and replicated by HGS. Thumbprint-referenced and HSM-backed private keys require their separate restoration or provider-access procedure and gMSA permissions on each node. Restore TLS certificates and bindings separately; they aren't supplied by the HGS state export. Preserve the original, uncompromised fabric key identities when possible. Neither a new certificate with the old subject nor a replacement TPM recreates a lost private key. Validate the complete service and refresh backups. Confirm AD, gMSA, DNS, TLS, and HGS health, including actual private-key use on every node. Run HGS diagnostics, obtain fresh host attestation, and test key release with a controlled shielded-VM cold start. Have the owner verify the workload, then restore the intended node redundancy and take a new protected HGS export. Recovery limit: If all usable copies of the required HGS private keys are lost, use another fabric guardian already authorized by the VM's KP, or have the owner use surviving owner keys to authorize replacement fabric keys in the existing KP. Preserve its secret and keep the VM off throughout that exchange. A new PDK doesn't repair deployed KPs. Without an authorized key path, owner authority, or valid guest recovery material, some VM data can be permanently unrecoverable. References HGS prerequisites and deployment model: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs Single-node and complete-cluster HGS recovery: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs#backing-up-and-restoring-hgs HGS private-key storage, replication, and replacement: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs#key-management BitLocker recovery for the HGS server: https://learn.microsoft.com/windows/security/operating-system-security/data-protection/bitlocker/recovery-process How do I maintain or recover the fabric when the CA is offline? An unavailable certificate-issuance service, an intentionally offline root CA, and an unreachable certificate-validation endpoint aren't the same failure. Existing certificates don't become invalid merely because the issuing service is stopped. HGS doesn't need a newly issued certificate for every VM start, and its signing/encryption key-container certificates have different expiry and revocation semantics from TLS certificates. HTTPS and other certificate consumers can still fail when certificate validity, chain building, or required revocation checks fail. Identify which CA and operation are affected. Determine whether the CA is an offline root used during controlled signing operations or an issuing CA needed for pending requests and renewals. This module uses a standalone CA; don't assume enterprise certificate templates or autoenrollment apply. If existing HGS operations still work, preserve availability while arranging the required CA operation rather than replacing working guardians. Separate issuance from certificate validation. From the affected host or management network, check certificate dates, trusted roots and intermediates, service-name matching, and time. Inspect the exact authority information access (AIA) locations and certificate revocation list (CRL) distribution points (CDPs) embedded in the affected certificate chain. A running CA doesn't prove those locations work, and a stopped CA doesn't make separately hosted publication endpoints unavailable. Restore the publication path when chain or revocation retrieval fails. Repair DNS, network access, web or directory publication, and the transfer of the correct CA certificates and signed CRLs. An existing valid CRL can be served without keeping the CA's signing service online. If a required CRL has expired, the responsible CA must publish a new signed CRL; repair parent-CA publication dependencies as needed. For an offline root, use the approved controlled startup, signing, and transfer process, then return it offline. Keep any required base and delta CRLs consistent. Don't disable revocation checking or change clocks to conceal expiry. Repair an unexpectedly unavailable issuing CA. Have the CA administrator inspect the AD CS service ( CertSvc ), events, storage, database/log access, and signing-key or HSM availability. Correct the identified dependency under the CA's recovery procedure. Restoring an HTTP CDP alone doesn't restore issuance, and repeatedly restarting the service won't recreate a missing signing key or repair a damaged database. Restore the original CA if its server is lost. Use the supported AD CS restoration/migration procedure with the original CA identity, CA certificate and private keys, database and logs, registry configuration, and CAPolicy.inf where used. Restore HSM access and any applicable AD dependencies separately. Match the standalone/enterprise and root/subordinate CA types. Prevent the old and replacement servers from operating independently as the same CA. Keep the AIA/CDP locations referenced by existing certificates available; changing extensions on the new server affects only newly issued certificates. Complete pending issuance and required renewals. Retain each outstanding request and its matching private key, obtain the approved issued certificate, and accept it on the system holding that key. Renew expired TLS or CA certificates through the appropriate PKI procedure, distribute the required public trust chain, and update TLS bindings on each HGS node. Restoring the CA or replacing a TLS certificate doesn't, by itself, require changing HGS guardian keys. If fabric signing/encryption key pairs really change, use the owner-authorized existing-KP workflow rather than assuming a same-name certificate preserves access. Verify service continuity before closing the outage. Test permitted enrollment/renewal, chain building, and revocation retrieval from representative client networks using both existing certificates and an approved test certificate. Confirm fresh HGS attestation and a controlled VM key-release test. Monitor certificate and CRL expiry and verify publication before the next planned offline period. A deliberately offline root can remain offline between its scheduled operations while its publication endpoints stay available. Recovery limit: If the CA signing key is irretrievably lost, a replacement CA with the same name can't issue certificates or fresh CRLs under the original key. Plan a controlled trust-chain transition and affected-certificate replacement. A CA backup doesn't normally contain the HGS private keys generated on HGS nodes; preserve and recover those keys independently. References CA backup and restoration/migration: https://learn.microsoft.com/windows-server/identity/ad-cs/migrate-certification-authority CRL publication, offline-root operation, and CDP recovery: https://learn.microsoft.com/windows-server/identity/ad-cs/operate-certificate-revocation-crl-cdp PKI design, AIA, and CDP requirements: https://learn.microsoft.com/windows-server/identity/ad-cs/pki-design-considerations HGS signing/encryption certificate expiry and revocation behavior: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs#renewing-or-replacing-keys Why are diagnostics inconclusive or misleading? Missing or stale evidence can delay recovery and hide trust failures. Collect enough information to identify the layer without disclosing the secrets that layer protects. Failure mode or symptom Likely causes Resolution overview A requested event channel is absent or has no events. Wrong computer/channel/build, disabled logging, incorrect time window, insufficient access, or no attempt occurred. Discover installed HostGuardian, CodeIntegrity, VMMS, worker, and cluster channels under the correct authority. Correlate timestamps and generate an approved diagnostic attempt. Don't suppress errors and label an empty result healthy. Monitoring is green while cold starts or key release fail. Monitoring tests only TCP, one node, a running VM, or a previously cached result. Monitor the full authorized path: fresh attestation, key usability on each node, controlled cold starts, fallback readiness, and recoverability. Keep synthetic tests isolated and non-destructive. Events across systems appear contradictory. Clock drift, stale status, different responding HGS nodes, mixed modes/versions, or unrelated attempts. Align the timeline, operation/VM identity, endpoint, node, and change record. Retain the original output alongside the interpretation. Logs disappeared after compromise or rollback. Evidence existed only on an affected host, retention was too short, or restoration replaced local logs. Forward and retain security events outside routine fabric control and preserve evidence before remediation. Missing evidence doesn't prove that no compromise occurred. A diagnostic bundle contains keys or tenant secrets. Transcripts captured PFX passwords, recovery protectors, answer files, private keys, or sensitive configuration. Restrict the bundle immediately, apply the incident-handling process, and produce a sanitized minimum necessary copy for support. Don't paste decrypted .bek files or private-key material into tickets. No listed cause explains the failure. A product defect, hardware fault, vendor integration, or unmodeled combination requires deeper investigation. Capture a minimal reproduction on a supported isolated system, correlate version-specific release notes, and escalate with evidence. Don't fabricate an error-code interpretation or progressively disable protections until the symptom disappears. References HGS diagnostics: https://learn.microsoft.com/powershell/module/hgsdiagnostics/get-hgstrace?view=windowsserver2025-ps&preserve-view=true HGS event monitoring: https://learn.microsoft.com/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-manage-hgs Guarded-host troubleshooting: https://learn.microsoft.com/troubleshoot/windows-server/virtualization/troubleshoot-guarded-hostsAdvanced Windows Firewall
If you administer Windows, you’re already aware of Windows Firewall. You might use it to allow an application, open a port, or block unwanted inbound traffic. But those familiar tasks only scratch the surface of what it can do. The Microsoft Learn module Understand advanced Windows Firewall takes you beyond basic rules and introduces Windows Firewall as a powerful platform for host-based segmentation, authenticated access, traffic protection, operational evidence, and incident response. In the module you'll learn about the following: Rule creation and management View effective, enabled rules in the ActiveStore . Inspect the port, address, application, and service filters associated with a rule. Create precisely scoped inbound rules for services such as HTTPS, WinRM, Remote Desktop, and WMI. Enable, disable, modify, and remove existing rules with PowerShell. Define a traffic contract before creating a rule. Correctly distinguish local and remote ports and addresses. Scope rules by protocol, port, address, application, service, profile, user, and computer. Restrict rules to stable executable paths, Windows services, or packaged application identities. Limit access to management subnets, jump hosts, privileged workstations, application tiers, and collectors. Create consistent rule names and groups for ownership and automation. Firewall profiles Apply different policies to Domain, Private, and Public networks. Enable the firewall and block unmatched inbound traffic on every profile. Restrict administrative exceptions to the profiles that require them. Inspect active network profiles and their default actions. Design policies that remain secure during DNS, routing, domain-controller, or network-adapter failures. Test how network failure states affect profile selection. Host segmentation Build a traffic matrix describing permitted communication between device and application tiers. Implement default-deny inbound segmentation. Block unnecessary workstation-to-workstation communication. Preserve approved management, monitoring, application, recovery, and domain-member traffic. Reduce lateral movement through controlled management paths. Deliver firewall policy centrally through Group Policy. Disable local firewall-rule merging. Disable local connection-security-rule merging. Stage enforcement through logging, discovery, pilots, and role-based deployment. Define success criteria and maintain a tested rollback path. IPsec and identity-based access Design IPsec connection security rules for peer authentication. Provide packet integrity, replay protection, and optional encryption. Select Kerberos or certificate-based authentication for different trust scenarios. Protect legacy plaintext applications without changing the application. Coordinate secure firewall rules with compatible connection security rules. Use request authentication during deployment before enforcing required authentication. Correctly define IPsec endpoints and traffic selectors. Require authenticated traffic before allowing access. Authorize traffic by Active Directory user-group membership. Require both an authorized user and an authorized managed computer. Combine identity with network, service, application, and profile restrictions. Create narrowly scoped authenticated bypass rules. Design governed identity exceptions. Validate both successful and denied authorization scenarios. Outbound traffic control Understand how stateful inspection permits response traffic. Avoid unnecessary inbound rules for dynamic client ports. Identify the dependencies required before introducing outbound default-deny. Restrict administrative tools, service accounts, high-risk applications, and servers to approved destinations. Account for dynamic cloud services, proxies, certificate endpoints, and content delivery networks. Introduce outbound restrictions gradually through discovery, narrow allow rules, pilots, and monitoring. Logging and evidence Enable logging for dropped packets and successful connections. Configure the log location and maximum size for every profile. Verify effective logging settings. Interpret firewall log fields such as action, protocol, address, port, interface, and direction. Use observed traffic to discover application dependencies. Distinguish observed traffic from authorized traffic. Use dropped-packet records to confirm that traffic reached the host firewall. Use successful-connection records to confirm firewall admission. Forward firewall evidence to protected central storage. Correlate firewall data with process, authentication, application, and network telemetry. Troubleshooting Follow a structured diagnostic sequence from the application listener through firewall and IPsec state. Inspect the merged runtime policy rather than only an individual policy source. Trace an effective rule back to Group Policy or another originating store. Identify conflicting or overriding block rules. Inspect active IPsec rules and main-mode and quick-mode security associations. Diagnose authentication, trust, time, name-resolution, selector, and cryptographic mismatches. Capture and interpret IPsec negotiation traffic on UDP ports 500 and 4500. Differentiate firewall admission failures from application or identity failures. Make controlled policy changes without disabling the firewall or creating unrestricted exceptions. Windows Firewall might already be a familiar part of your Windows environment. This module will help you appreciate just how much security and diagnostic functionality is built into it—and how to apply that functionality with greater precision. Start learning: Understand advanced Windows FirewallActive Directory Domain Services modules on Microsoft Learn
The following is a list of Active Directory Domain Services modules on Microsoft Learn sorted from introductory to advanced. Is there an Active Directory topic that isn't listed here that you'd like to see covered? (AD CS modules are coming). If you know all this, remember we have the free 45 minute practical Active Directory administration test that gets you a validated Microsoft credential. You can take the test here https://aka.ms/ADDSAppliedSkillTest. Introductory 1. Introduction to AD DS URL: https://learn.microsoft.com/en-us/training/modules/introduction-to-ad-ds/ Assessment: BEGINNER This module establishes the essential AD DS vocabulary and mental model. It introduces directory services, users, groups, computers, forests, domains, sites, domain controllers, and organizational units, then shows how directory objects and their properties are managed. It should come first because nearly every later module assumes familiarity with these structures and their relationships. Intermediate 2. Create and manage Active Directory objects URL: https://learn.microsoft.com/en-us/training/modules/create-manage-active-directory-objects/ Assessment: INTERMEDIATE This module turns the foundational concepts into routine administrative skills. It covers users, groups, computers, organizational units, object properties, object creation and configuration, bulk user-account management, and basic domain controller maintenance. The module is the natural bridge from understanding AD DS to operating it. 3. Manage Active Directory Domain Services using PowerShell cmdlets URL: https://learn.microsoft.com/en-us/training/modules/manage-active-directory-domain-services-use-powershell-cmdlets/ Assessment: INTERMEDIATE This module applies PowerShell to the object-management tasks learned previously. It introduces cmdlets for creating and maintaining users, groups, group memberships, computers, organizational units, and other directory objects, giving learners a repeatable and scalable alternative to graphical administration. Prior PowerShell familiarity is expected. 4. Deploy and manage Active Directory Domain Services domain controllers URL: https://learn.microsoft.com/en-us/training/modules/deploy-manage-active-directory-domain-services-domain-controllers/ Assessment: INTERMEDIATE This module moves from directory objects to the servers that host the directory. It reviews forests and domains, explains domain controller topology, covers domain controller deployment and movement between sites, and introduces operations master roles. It provides the deployment context needed before studying domain controller maintenance and role placement in greater depth. 5. Manage AD DS domain controllers and FSMO roles URL: https://learn.microsoft.com/en-us/training/modules/manage-active-directory-domain-services-flexible-single-master-operation-roles/ Assessment: INTERMEDIATE This module deepens domain controller administration through deployment, maintenance, backup and recovery considerations, global catalog placement, Flexible Single Master Operations (FSMO) role placement and management, and an introduction to schema management. It builds on the preceding deployment module and prepares learners for later architecture, recovery, and design topics. 6. Implement Group Policy Objects URL: https://learn.microsoft.com/en-us/training/modules/implement-group-policy-objects/ Assessment: INTERMEDIATE This module introduces domain-based Group Policy Objects (GPOs), including scope, inheritance, creation, configuration, storage, administrative templates, and the Central Store. It should precede the other Group Policy modules because it explains both the logical processing model and the underlying storage components on which later policy and troubleshooting work depends. 7. Create and configure Group Policy Objects in Active Directory URL: https://learn.microsoft.com/en-us/training/modules/create-configure-group-policy-objects-active-directory/ Assessment: INTERMEDIATE This module reinforces GPO definition, scope, inheritance, and domain-based configuration, then extends those skills into domain password policy and fine-grained password policy. Although some content overlaps the preceding module, its identity-policy focus makes it a useful second step after learners understand GPO storage, templates, and general processing. 8. Manage security in Active Directory URL: https://learn.microsoft.com/en-us/training/modules/manage-security-active-directory/ Assessment: INTERMEDIATE This module addresses practical directory hardening through user rights, access restrictions, delegated permissions, the Protected Users group, Windows Defender Credential Guard, NTLM blocking, and identification of problematic accounts. It connects identity administration and Group Policy knowledge to least-privilege operations and modern credential protection. 9. Implement and manage Active Directory Certificate Services URL: https://learn.microsoft.com/en-us/training/modules/implement-manage-active-directory-certificate-services/ Assessment: INTERMEDIATE This module introduces public key infrastructure and Active Directory Certificate Services (AD CS), including certification authority types, AD CS design and implementation, certificate enrollment, revocation, and trust. It belongs after core directory security because certificates extend AD-based authentication and authorization into a broader trust infrastructure. Advanced 10. Understand Active Directory Group Policy security settings URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-security-policies/ Assessment: ADVANCED This module provides an in-depth treatment of security policy design and operation at scale. It covers password, lockout, and Kerberos account policies; fine-grained password policies; user rights; security options; auditing; secured groups, services, registry keys, files, and logs; network and application policies; and Windows Server 2025 OSConfig baselines. Its assumptions about GPO processing, security identifiers, access tokens, ACLs, Kerberos, and NTLM make it the bridge from practical GPO administration to protocol-level authentication hardening. 11. Active Directory Domain Services authentication and Kerberos hardening URL: https://learn.microsoft.com/en-us/training/modules/active-directory-authentication-kerberos/ Assessment: ADVANCED This module examines Windows authentication end to end, explaining how SSPI, Negotiate, NTLM, and Kerberos interact and tracing Kerberos from Ticket Granting Ticket issuance through service-ticket presentation and authorization. It covers diagnosis of Service Principal Name, delegation, Privilege Attribute Certificate, encryption-type, and NTLM fallback problems; staged migration from NTLM to Kerberos; RC4 auditing and remediation for Windows Server 2025; and planning for PKINIT agility, Kerberos encryption policy, SMB NTLM blocking, and password-change hardening. It caps the security stage because it requires learners to combine policy, identity, logging, and authentication-protocol knowledge. 12. Understand how Active Directory Domain Services uses DNS URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-domain-name-system/ Assessment: ADVANCED This module explains and diagnoses the DNS mechanisms on which AD DS depends. It traces service discovery and domain controller location through SRV records, LDAP ping, site selection, and caching, and examines AD-integrated zones, application directory partitions, secure dynamic updates, registration, replication convergence, baselining, and failure recovery. This knowledge is essential before designing or troubleshooting site topology and replication. 13. Active Directory sites, topology, and replication URL: https://learn.microsoft.com/en-us/training/modules/active-directory-site-replication/ Assessment: ADVANCED This module develops a detailed model of sites, subnets, site links, costs, bridgeheads, connection objects, the Knowledge Consistency Checker (KCC), and the Inter-Site Topology Generator (ISTG). It also covers DC Locator behavior, topology anti-patterns, update sequence numbers, replication vectors, object metadata, replication failure diagnosis, and the Windows Server 2025 replication priority boost. The module supplies the replication foundation needed for the deeper storage and design modules that follow. 14. Understand the Active Directory Domain Services database and SYSVOL URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-database/ Assessment: ADVANCED This module explains how a domain controller stores and replicates directory data and SYSVOL through separate mechanisms. It distinguishes the logical directory from the local ESE database and directory partitions, traces transactional writes and logical AD DS replication, explains SYSVOL access and DFS Replication, follows a GPO across its directory and file-system components, and defines safe backup, recovery, virtualization, and version boundaries. It is especially useful for diagnosing whether a failure lies in directory data, SYSVOL, replication, or client access. 15. Understand the Active Directory Domain Services Schema URL: https://learn.microsoft.com/en-us/training/modules/understand-active-directory-schema/ Assessment: ADVANCED This module examines the forest-wide schema that defines directory object classes, attributes, syntax, inheritance, links, identifiers, search behavior, security metadata, and global catalog content. It covers safe inspection, schema versions, governance, extension design and deployment, indexing and replication effects, access control, and schema-related troubleshooting. The topic is advanced because schema changes are forest-wide, effectively permanent, and demand disciplined testing and change control. 16. Design a single-domain Active Directory forest URL: https://learn.microsoft.com/en-us/training/modules/design-single-domain-active-directory-forest/ Assessment: ADVANCED This module combines the preceding operational knowledge into a resilient single-domain forest design. It covers durable DNS and UPN namespaces, AD-integrated DNS, sites, subnets, site links, replication convergence and failure behavior, and placement of domain controllers, DNS servers, global catalogs, FSMO roles, and the authoritative time source. Learners also validate designs against objective evidence and failure scenarios. 17. Design a multi-domain or multi-forest Active Directory environment URL: https://learn.microsoft.com/en-us/training/modules/design-multi-domain-forest-trust/ Assessment: ADVANCED This module extends single-domain design to scenarios requiring security isolation, legal separation, administrative autonomy, mergers, or replication boundaries. It addresses domain trees and partitions, namespace coexistence, delegation, GPO scope, schema governance, trust direction and security, cross-forest name resolution, global catalog and authentication paths, advanced replication and capacity, and read-only domain controller branch designs. It should follow single-domain design because additional domains and forests introduce complexity that must be justified. 18. Manage advanced features of AD DS URL: https://learn.microsoft.com/en-us/training/modules/manage-advanced-features-of-ad-ds/ Assessment: ADVANCED This module brings together several specialized administration scenarios: creating trust relationships, implementing Enhanced Security Administrative Environment (ESAE) forests, monitoring and troubleshooting replication, and creating custom AD DS partitions. These tasks rely on a mature understanding of forest boundaries, trusts, security, partitions, and replication, so they are best approached after both architecture modules. 19. Deploy and manage Azure IaaS Active Directory domain controllers in Azure URL: https://learn.microsoft.com/en-us/training/modules/deploy-manage-azure-iaas-active-directory-domain-controllers-azure/ Assessment: ADVANCED This module applies established AD DS administration to Azure infrastructure. It compares directory and identity service options, prepares Azure virtual networking for domain controllers, deploys and configures AD DS on Azure virtual machines, installs a replica domain controller, and creates a new forest on an Azure virtual network. The broad prerequisites in on-premises AD DS, Azure IaaS, networking, resiliency, security, PowerShell, automation, and monitoring make this advanced in the proposed path. 20. Active Directory Domain Services migration URL: https://learn.microsoft.com/en-us/training/modules/active-directory-domain-services-migration/ Assessment: ADVANCED This module evaluates how to move an existing AD DS environment to Windows Server 2025. It compares in-place forest upgrade with migration to a new forest, then outlines the process for each approach. Although concise, migration is placed late because selecting and executing a safe strategy requires solid knowledge of domain controllers, operations roles, DNS, replication, security, architecture, recovery, and change management. 21. Troubleshoot Active Directory URL: https://learn.microsoft.com/en-us/training/modules/troubleshoot-active-directory/ Assessment: ADVANCED This module provides broad recovery and troubleshooting coverage for AD DS failures and degraded performance. It addresses restoring deleted objects with the AD Recycle Bin, recovering the AD DS database and SYSVOL, troubleshooting replication, and diagnosing hybrid authentication issues. The potential impact of recovery operations and the need to correlate several directory subsystems make this an advanced operational module despite its relatively compact scope. 22. Troubleshoot Active Directory Domain Services replication URL: https://learn.microsoft.com/en-us/training/modules/troubleshoot-active-directory-replication/ Assessment: ADVANCED This module develops a disciplined process for diagnosing replication failures with Repadmin, DCDiag, PowerShell, and event logs. It teaches learners to distinguish true failures from expected latency or transient topology states, isolate DNS, network, authentication, topology, and domain controller health dependencies, recognize data-consistency risks, apply a targeted correction or escalate safely, and verify convergence and the original business symptom. This diagnostic discipline should precede advanced recovery so learners can distinguish a correctable replication fault from a broader consistency failure that warrants restoration. 23. Advanced Active Directory back up and recovery URL: https://learn.microsoft.com/en-us/training/modules/active-directory-backup-recovery/ Assessment: ADVANCED This module treats AD DS backup and recovery as Tier 0 architecture and incident response rather than a single restore operation. It covers backup design around recovery time and recovery point objectives, topology, retention, and trust boundaries; evidence-based backup validation; selection of object, domain controller, domain, or forest recovery scope; recovery of objects, attributes, hierarchies, DNS, and SYSVOL; domain and forest sequencing involving FSMO roles, RID state, global catalogs, and trusts; safe virtualized domain controller recovery; and comprehensive validation before reconnection. It is the final capstone because safe recovery requires the learner to integrate nearly every preceding topic while making high-impact decisions under controlled change and security processes.Some tools and techniques for hardening Windows Server
In this post I go over some tools and techniques exist for hardening Windows Server. As always, apply controls according to the server's role, test them against representative workloads before production rollout, document approved exceptions, and maintain tested console and recovery access in case a security control affects management or application compatibility. Apply the role-specific Windows Server 2025 baseline with OSConfig Security baselines turn hundreds of individual security decisions into a consistent, role-aware desired state. Using OSConfig reduces exposure caused by insecure defaults, legacy protocols, inconsistent administrator choices, and configuration drift that attackers can exploit for credential theft, lateral movement, or persistence. You can use use OSConfig at build time to apply the Microsoft security baseline that matches the server role: SecurityBaseline/WindowsServer/2025/MemberServer , SecurityBaseline/WindowsServer/2025/DomainController , or SecurityBaseline/WindowsServer/2025/WorkgroupMember . The baseline contains more than 300 settings covering network exposure, credentials, lateral movement, persistence resistance, and auditing. It can be managed through PowerShell, Windows Admin Center, or Azure Policy for Azure Arc-enabled servers. You can keep OSConfig drift control enabled so unauthorized or accidental changes are detected and corrected. Pilot the baseline with each workload, record required exceptions, and manage those exceptions centrally rather than weakening the baseline broadly. Implementation steps: Identify the server's role and the management authority that will own its settings, install the OSConfig PowerShell module, review the matching scenario, and apply it first to a representative test server. Validate application and management access, deploy the scenario in controlled rings, schedule and complete the restart required after applying the baseline, verify the desired configuration and compliance results, enable drift control, and record any approved exceptions and recovery procedures. Possible drawbacks: A baseline can disrupt legacy applications, authentication methods, network flows, or management tools that depend on weaker settings. Drift control can also reverse intentional emergency changes if they aren't recorded through the correct authority, so staged testing, documented exceptions, and tested recovery access are essential. Documentation on Learn: OSConfig security configuration for Windows Server | Deploy Windows Server 2025 security baselines with OSConfig | OSConfig security settings repository Use Secured-core hardware and enable platform security Windows Server secured-core combines hardware, firmware, virtualization, and operating-system protections to establish trust before Windows starts and preserve that trust while it runs. These controls mitigate bootkits, malicious or vulnerable kernel drivers, direct memory access attacks, firmware tampering, and attempts to extract credentials from the operating system. You deploy on hardware or virtual machines that support TPM 2.0, UEFI Secure Boot, virtualization-based security, DMA protection, and the other Secured-core requirements. Enable the OSConfig SecuredCore scenario and verify that Credential Guard, hypervisor-protected code integrity, kernel protections, and the signed boot chain are active. You need to keep system firmware, TPM firmware, hypervisor components, and hardware drivers current. Test older drivers before enabling enforcement because incompatible kernel drivers can prevent security features from activating or can affect boot reliability. Implementation steps: Confirm that the physical server or virtual-machine platform meets the Secured-core requirements, update firmware and drivers, and enable TPM 2.0, Secure Boot, virtualization extensions, and DMA or IOMMU protection in the platform configuration. Apply the OSConfig SecuredCore scenario or configure the features through Windows Admin Center, restart as required, verify that each protection is active, record evidence of the hardware capabilities and running Windows protections rather than only the assigned policy, and monitor for driver or workload compatibility issues. Possible drawbacks: Secured-core features require compatible hardware, firmware, hypervisors, and signed drivers, which can increase procurement costs or rule out older systems. Virtualization-based protections can introduce a workload-dependent performance impact, and incompatible drivers or firmware can cause application failures, feature activation problems, or difficult boot recovery. Documentation: What is Secured-core server? | Configure Secured-core server | Windows Server 2025 secured-core hardware requirements Deploy Server Core and minimize installed components Attack-surface reduction removes code, services, interfaces, and utilities that an attacker could exploit or misuse after gaining access. A minimal Server Core deployment lowers the number of vulnerabilities that require patching and reduces opportunities for interactive attacks, malicious browsing, persistence, and abuse of unnecessary administrative tools. Install Server Core unless a supported workload specifically requires Desktop Experience. Server Core has a smaller local interface and component footprint, reducing exposed code, maintenance requirements, and opportunities for interactive misuse. Windows Server 2025 can't convert between Server Core and Server with Desktop Experience after installation, so changing this choice later requires a clean installation. Install only the roles, features, management agents, and application components required for the server's purpose. Remove obsolete utilities and unused software, avoid browsing the web from servers, and disable unnecessary services only after confirming role and application dependencies. Where practical, dedicate each server to a single security or workload role. Implementation steps: Confirm that the workload and vendor support Server Core, formally record the installation-option decision before deployment, select Server Core during installation, and define the minimum roles, features, agents, and software required for the server's purpose. Install only those components, configure remote management and recovery access, remove or disable unused components after dependency testing, and verify that the application, monitoring, backup, patching, and support processes still function. Possible drawbacks: Server Core can make local troubleshooting less familiar and increases reliance on remote management, automation, and command-line skills. Some vendor applications, support tools, or administrators require Desktop Experience, and removing roles or disabling services without dependency testing can break workloads, monitoring, backup, or recovery operations. Documentation: What is the Server Core installation option? | Server Core and Desktop Experience installation options Ensure rapid patching and continuous vulnerability management Patching and vulnerability management identify and close known weaknesses before attackers can reliably exploit them. This practice reduces exposure to remote-code execution, privilege escalation, ransomware, vulnerable drivers, compromised third-party components, and attacks that target publicly documented vulnerabilities soon after disclosure. Make sure you are aware if any of your server workloads have not got the latest security updates deployed Maintain an inventory of operating-system, application, driver, firmware, and management-agent versions. Use deployment rings to test updates quickly, meet defined remediation deadlines, install out-of-band security updates when required, and monitor update compliance and pending restarts. Azure Update Manager can provide centralized assessment and orchestration for Azure and Azure Arc-enabled servers. Use Microsoft Defender Vulnerability Management or an equivalent platform to discover exposures, prioritize remediation by exploitability and business impact, and verify that fixes actually remove the vulnerability. Patching Windows while leaving internet-facing applications, drivers, or firmware obsolete does not adequately harden the server. Implementation steps: Inventory servers and every supported update source, define remediation deadlines and deployment rings, and configure Azure Update Manager or another actively developed orchestration platform. Windows Server Update Services remains supported and available but is deprecated and should be treated as a legacy option rather than the preferred platform for a new long-term design. Run vulnerability assessments, prioritize exposed and actively exploited weaknesses, test updates, deploy them with coordinated reboots, verify compliance after installation, and maintain rollback and exception procedures. Possible drawbacks: Updates can require reboots, consume maintenance windows, or introduce application, driver, and performance regressions. Vulnerability scanners and management agents also consume resources and can generate false positives, so organizations need test rings, rollback procedures, maintenance coordination, and a risk-based process for temporary deferrals. Documentation: Azure Update Manager overview | Cloud-native patch management for Azure Arc-enabled servers | Microsoft Defender Vulnerability Management | Deprecated Windows Server features Implement Microsoft Defender Antivirus and endpoint detection and response Antivirus and endpoint detection and response combine prevention with behavioral monitoring and investigation. They mitigate malicious files, ransomware, web and network-delivered payloads, suspicious process activity, persistence mechanisms, credential theft, and attacks that evade simple signature-based detection. Run Microsoft Defender Antivirus in active mode unless a documented and tested security architecture requires another antimalware product. Enable real-time protection, behavior monitoring, cloud-delivered protection, automatic sample submission, and frequent security-intelligence updates. Use the OSConfig Defender/Antivirus/WindowsServer/2025 scenario as the recommended Server 2025 configuration starting point. Onboard servers to Microsoft Defender for Endpoint or Microsoft Defender for Servers for endpoint detection and response, investigation, and centralized visibility. Enable tamper protection and keep exclusions narrow, workload-specific, and regularly reviewed; broad path, process, or extension exclusions create useful hiding places for attackers. Implementation steps: Confirm licensing, connectivity, proxy, and third-party antivirus requirements, then apply the OSConfig Defender Antivirus scenario or an equivalent centrally managed policy. Enable real-time, behavior, cloud-delivered, sample-submission, and tamper protections; onboard the server to Defender for Endpoint or Defender for Servers; review Microsoft's built-in, automatic server-role, and workload-specific exclusions before adding any manual exclusion; verify sensor health, signature currency, alert delivery, and investigation access; and periodically confirm that every manual exclusion remains necessary. Possible drawbacks: Real-time scanning and endpoint telemetry can add CPU, memory, disk I/O, network, and licensing costs, particularly on high-throughput workloads. False positives or quarantine actions can interrupt services, while cloud-delivered capabilities can raise connectivity, privacy, or data-residency considerations; performance exclusions must therefore be tested and kept narrowly scoped. Documentation: Microsoft Defender Antivirus in Windows | Microsoft Defender for Endpoint on Windows | Defender Antivirus exclusions | Protect against security-setting tampering Deploy attack surface reduction and network protection on your Windows Server workloads Attack surface reduction rules prevent high-risk behaviors rather than waiting for a specific malicious file to be identified, while network protection blocks access to known or suspicious destinations. Together they mitigate ransomware, credential theft, malicious scripts, abuse of trusted tools, vulnerable drivers, command-and-control traffic, and payload delivery. Configure Microsoft Defender attack surface reduction rules to block common behaviors used by ransomware, credential theft, malicious scripts, vulnerable signed drivers, and executable content. Begin with audit or warning mode, review telemetry for legitimate workload dependencies, create narrowly scoped exclusions, and then move suitable rules to block mode on a defined schedule. Enable network protection where supported to prevent processes from reaching malicious or untrusted destinations. Manage these controls centrally through Group Policy, Microsoft Defender for Endpoint security settings management, or another supported policy platform. Implementation steps: Inventory server workloads and make a rule-by-rule applicability decision for each server role rather than reusing a generic workstation ASR profile unchanged. Create a centrally managed ASR and network-protection policy that initially uses audit or warning mode, collect and review events, confirm business-critical dependencies, create narrowly scoped exclusions, move applicable rules to block mode through deployment rings, verify that protected applications remain functional, and continuously review detections and exception use. Possible drawbacks: ASR rules can block legitimate automation, administrative tools, installers, scripts, or line-of-business applications that exhibit high-risk behavior. Audit mode can produce substantial telemetry, and broad exclusions can undermine the protection, so successful deployment requires workload testing, event review, careful exception design, and ongoing tuning. Documentation: Attack surface reduction capabilities | Evaluate Microsoft Defender Antivirus and ASR rules using Group Policy Allow only trusted code with App Control for Business Application control changes the execution model from allowing everything except known malware to allowing only code that satisfies an approved policy. This technique mitigates unknown malware, ransomware, unauthorized administrative utilities, malicious scripts, unapproved drivers, and opportunistic payloads that antivirus has not yet classified. Use App Control for Business to define which executables, scripts, installers, libraries, and drivers may run. Windows Server 2025 includes OSConfig scenarios for Microsoft's default policy and application blocklist. Start in audit mode, collect Code Integrity event ID 3076, create required supplemental allow policies, and move to enforcement only after representative workload testing. There are some good GUI tools written by MVPs published on GitHub that make this very easy. https://github.com/HotCakeX/Harden-Windows-Security Monitor blocked-code event ID 3077 after enforcement and maintain a controlled process for policy updates and emergency recovery. Application allowlisting is substantially stronger than relying only on malware signatures because unapproved code is prevented from running even when it has not yet been classified as malicious. Implementation steps: Verify that the device is running a production-signed Windows Server 2025 build because the OSConfig default policy doesn't permit flight-signed binaries. Inventory approved applications, scripts, drivers, publishers, and update mechanisms, then deploy the default policy and application blocklist through OSConfig in audit mode. Collect event ID 3076, build and deploy required supplemental policies, and sign policies only when the additional tamper resistance is required and certificate lifecycle, policy servicing, removal, and offline recovery have been tested. Test application updates and recovery, move the policy to enforcement in stages, and monitor event ID 3077 and policy health after deployment. Possible drawbacks: Poorly designed policies can block legitimate applications, updates, scripts, drivers, or boot-critical components and can cause a severe service outage. Maintaining allow policies creates operational overhead, especially for frequently changing software, and approved tools can still be abused, so audit-mode deployment, controlled updates, and offline recovery procedures are necessary. Signed policies provide stronger tamper resistance but are intentionally harder to remove, including during recovery. Documentation: Configure App Control for Business by using OSConfig | App Control for Business Keep Windows Defender Firewall enabled with restrictive rules A host firewall limits which systems and applications can communicate with the server, even when upstream network controls are absent or bypassed. Restrictive rules reduce exposure to service exploitation, scanning, lateral movement, remote administration abuse, command-and-control traffic, and accidental publication of listening services. Enable Windows Defender Firewall on Domain, Private, and Public profiles. Retain the default block for unsolicited inbound traffic and create only the rules required by the server role. Scope rules by program or service, protocol, local port, remote address, interface, and profile rather than creating broad port-based or any-source exceptions. Log dropped packets and successful connections where operationally appropriate, centrally monitor policy changes, and review stale rules. Apply explicit outbound restrictions to high-value or tightly controlled servers where feasible, especially when they should communicate with only a small set of update, identity, management, and application endpoints. Implementation steps: Inventory listening services and required inbound and outbound flows, enable the firewall on all profiles, and create narrowly scoped rules for the server role. Decide whether locally created rules may merge with centrally deployed rules for each profile, verify the effective policy on representative servers, remove obsolete or duplicate rules, test application, domain, cluster, backup, and management traffic, enable appropriate logging, deploy the policy centrally, and monitor rule changes and blocked connections before introducing selective outbound restrictions. Possible drawbacks: Incorrect firewall rules can interrupt application traffic, clustering, domain operations, monitoring, backup, or remote management and can make diagnosis difficult. Detailed connection logging consumes storage, while restrictive outbound policies require continuous maintenance as service endpoints change, so rules should be documented, tested, and deployed with recovery access. Documentation: Windows Firewall rule recommendations | OSConfig baseline network protections Harden Remote Desktop and remote administration Remote administration exposes privileged authentication and interactive control paths that are attractive targets for brute-force attacks, credential theft, session hijacking, and exploitation of internet-facing services. Gateways, multifactor authentication, encrypted sessions, restricted source networks, and credential isolation reduce the likelihood that a stolen password or exposed management port leads directly to server compromise. Disable Remote Desktop Services when it is not required. When it is required, use a VPN or Remote Desktop Gateway, require multifactor authentication and Network Level Authentication, restrict source networks and authorized groups, use trusted TLS certificates, and configure sensible idle and disconnected-session limits. Disable clipboard, drive, printer, port, and device redirection unless the operational need outweighs the data-transfer risk. Use Remote Credential Guard only for compatible direct RDP administration of Active Directory-joined targets using Kerberos so credentials aren't sent to the remote host. Remote Credential Guard isn't supported through Remote Desktop Gateway or Remote Desktop Connection Broker. For helpdesk access to a potentially compromised host, use Restricted Admin mode instead of Remote Credential Guard. Never expose TCP port 3389 directly to the internet, and avoid using saved privileged credentials on ordinary administrator workstations. Implementation steps: Disable RDP on servers that don't require it. For brokered or externally initiated access, place RDP behind a VPN or MFA-protected Remote Desktop Gateway and restrict permitted users and source networks. For compatible direct RDP administration of Active Directory-joined targets, configure Remote Credential Guard separately; use Restricted Admin mode for appropriate helpdesk scenarios. Configure Network Level Authentication, trusted TLS certificates, session limits, and required redirection controls, test routine and emergency access, and monitor remote logons and gateway activity. Possible drawbacks: Gateways, VPNs, MFA services, and secure administrative hosts add licensing, infrastructure, and support dependencies, and their outage can block legitimate administration. Device-redirection restrictions can hinder support workflows, while Network Level Authentication and Remote Credential Guard have compatibility and delegation limitations; a separately secured emergency access path is therefore required. Documentation: Plan multifactor authentication for Remote Desktop Services | Remote Credential Guard Enforce least privilege and separate administrative identities Least privilege limits each identity and session to the minimum actions required for its task. Separating standard and privileged accounts constrains the damage caused by phishing, token or password theft, malicious insiders, vulnerable administrative tools, and compromised lower-trust devices, while reducing opportunities for privilege escalation and persistence. Give administrators standard user accounts for routine work and separate privileged accounts for administrative duties. Minimize membership of local Administrators, Domain Admins, Enterprise Admins, and other powerful groups; review membership and assigned user rights regularly; and prevent highly privileged identities from signing in to lower-trust servers and workstations. Use Just Enough Administration endpoints, Windows Admin Center role-based access control, and time-limited elevation where possible. Delegate specific tasks rather than granting unrestricted interactive or PowerShell access, and maintain separately protected emergency accounts for identity-service outages. Implementation steps: Inventory privileged human accounts, service principals, managed identities, service and automation credentials, scheduled tasks, local group membership, duties, and logon locations. Create separate standard and administrative identities, remove unnecessary standing memberships, delegate tasks through role groups, JEA endpoints, Windows Admin Center RBAC, or time-limited elevation, restrict high-tier logons to secured administrative hosts, test that each role can perform its approved duties, and monitor privileged-group, role, automation, and emergency-account use. Possible drawbacks: Designing roles, JEA endpoints, approval processes, and time-limited access requires ongoing engineering and governance. Excessively narrow delegation can delay troubleshooting or incident response, while separate accounts add friction for administrators, so permissions should be tested against real duties and emergency access should remain tightly controlled but usable. Documentation: Just Enough Administration | Windows Admin Center user access options | Enterprise access model Deploy Windows LAPS for local administrator credentials Windows LAPS replaces shared or manually maintained local administrator passwords with unique, random, automatically rotated credentials. It mitigates password reuse, pass-the-hash attacks, credential dumping, and broad lateral movement in which compromise of one server's local administrator credential grants access to many others. Use Windows Local Administrator Password Solution to assign a unique, random, automatically rotated local administrator password to every server. The backup destination depends on join state: Active Directory-only devices can use only Active Directory, Microsoft Entra-only devices can use only Microsoft Entra ID, and hybrid-joined devices can use either destination but not both simultaneously. Tightly restrict and audit password retrieval, configure password history and post-authentication rotation, and monitor policy-processing failures. Never reuse a common local administrator password across servers because one compromised password or hash can enable broad lateral movement. OSConfig provides the LAPS/WindowsServer/2025/MemberServer scenario for member servers. Workgroup systems can be managed through LAPS for Azure Arc, which Microsoft currently documents as a preview feature. On domain controllers, use Windows LAPS to manage the Directory Services Restore Mode password where appropriate. Implementation steps: Select the password-backup destination permitted by the device's join state, prepare Active Directory or Microsoft Entra ID, and identify the local account to manage. For workgroup systems, evaluate the operational and support implications of the preview LAPS for Azure Arc service before adoption. Configure password length, complexity, age, history, and post-authentication actions through policy or OSConfig; configure DSRM password management for applicable domain controllers; delegate password read and reset permissions to a small approved group; pilot the policy; verify password backup and rotation; test authorized recovery; and monitor LAPS processing and retrieval events. Possible drawbacks: LAPS introduces directory, policy, permissions, auditing, and recovery dependencies that must be designed correctly. Scripts or applications that rely on a fixed local password can fail, password rotation can disrupt active sessions or automation, and overly broad rights to retrieve stored passwords can create a new privileged credential repository for attackers to target. Documentation: What is Windows LAPS? | OSConfig Windows LAPS scenario | LAPS for Azure Arc Replace static service-account passwords with managed service accounts Managed service accounts replace human-managed, long-lived service passwords with complex credentials that Active Directory changes automatically. This reduces exposure to password theft, reuse, weak password selection, expired credentials, secrets embedded in scripts, and persistence based on service accounts whose passwords are rarely rotated. Use group managed service accounts for supported Windows services, scheduled tasks, and application pools in Active Directory environments. gMSAs provide automatic password management and reduce the need to store or manually rotate long-lived service credentials. Windows Server 2025 also introduces delegated Managed Service Accounts for supported migrations from traditional service accounts. A dMSA binds authentication to approved machine identities, uses managed randomized keys, and disables use of the original service-account password. dMSA deployment requires a discoverable Windows Server 2025 domain controller, and an existing gMSA can't be migrated to a dMSA. Grant each gMSA only the logon rights, resource permissions, and password-retrieval scope it requires. Do not make service accounts members of privileged groups unless unavoidable, prohibit interactive sign-in, remove obsolete accounts promptly, and monitor changes to the hosts permitted to retrieve each managed password. Implementation steps: Inventory service identities and application dependencies, then select a gMSA for supported services that can directly use a managed account or evaluate a dMSA for a supported Windows Server 2025 migration from a traditional service account. For a gMSA, confirm Active Directory and key-distribution prerequisites, limit which hosts may retrieve its password, assign only required logon rights, permissions, and service principal names, install and test the account on approved hosts, migrate the service or task, and disable or remove the former static-password account. For a dMSA, confirm a discoverable Windows Server 2025 domain controller and follow the documented migration and rollback process. Possible drawbacks: Managed service accounts depend on Active Directory and are not supported by every application, installer, or cross-platform workload. Migration can involve service-principal-name, delegation, permission, and clustering changes, while an overly broad password-retrieval scope allows additional hosts to use the identity. dMSA also requires Windows Server 2025 domain-controller availability and has migration rules that differ from gMSA, so compatibility, rollback, and access boundaries require careful testing. Documentation: Secure group managed service accounts | Delegated Managed Service Accounts overview | Delegated Managed Service Accounts FAQ Protect credentials and phase out legacy authentication Credential isolation and modern authentication reduce the value of secrets that an attacker can extract or relay. Credential Guard, LSA protection, Kerberos AES, and retirement of weak authentication mitigate memory scraping, pass-the-hash, pass-the-ticket, NTLM relay, downgrade attacks, and cracking of obsolete password representations. Verify that Credential Guard and Local Security Authority protection are active where hardware and workload compatibility permit. Windows Server 2025 enables Credential Guard by default on eligible domain-joined systems that aren't domain controllers, but the state should still be verified and centrally enforced where required. Use Negotiate with Kerberos and modern AES encryption for domain authentication, prevent storage of LM hashes or reversibly encrypted passwords, and keep delegated credentials non-exportable. NTLMv1 is removed in Windows Server 2025, and deprecated NTLMv2 should be treated only as a temporary compatibility fallback rather than an end state. Audit NTLM and other legacy authentication dependencies before restricting or disabling them, then remove those dependencies in a controlled sequence. Do not disable legacy protocols blindly on production servers, but do not leave them enabled indefinitely solely because their consumers have not been inventoried. Implementation steps: Confirm hardware and driver support, verify the default Credential Guard state, and use OSConfig or centrally managed policy to enforce Credential Guard and LSA protection where required. Enable NTLM auditing, inventory clients and services using legacy authentication, configure Negotiate and Kerberos AES, update affected service accounts, remediate dependencies, assign an owner and retirement date to every NTLMv2 exception, introduce NTLM restrictions in stages, and monitor authentication failures before broader enforcement. Possible drawbacks: Virtualization-based credential protection requires compatible hardware and can have a workload-dependent performance or compatibility impact. Legacy devices, applications, trusts, or service configurations may still depend on NTLM or weaker cryptography, and disabling them without complete auditing can cause widespread authentication failures or outages. Documentation: Credential Guard overview | OSConfig baseline credential protections | Deprecated Windows Server features Harden SMB and file-server access SMB hardening protects Windows file sharing and related management traffic against protocol downgrade, relay attacks, on-path tampering, brute-force authentication, guest access, data disclosure, and exploitation of obsolete implementations such as SMBv1. Signing verifies message integrity, while encryption protects sensitive content in transit. Remove SMBv1, prevent insecure guest logons, retain and verify the Windows Server 2025 default requirement for inbound and outbound SMB signing, use SMB encryption for sensitive or untrusted network paths, and use SMB 3.x for modern file services. Treat any relaxation of signing for an incompatible third-party device as a documented, isolated, and time-bound exception. Windows Server 2025 also provides SMB authentication rate limiting and stronger signing and encryption capabilities that should be retained unless a documented compatibility requirement exists. Restrict TCP port 445 to approved clients and servers, apply share and NTFS permissions according to least privilege, enable access-based enumeration where appropriate, and audit access to sensitive shares. Do not publish traditional SMB directly to the internet; use a supported secure access design such as SMB over QUIC when its requirements and threat model fit. Implementation steps: Inventory SMB clients, servers, protocol versions, shares, and access requirements, then remove SMBv1 and insecure guest access. Verify that inbound and outbound signing remain required, document and isolate any temporary third-party compatibility exception, configure encryption, authentication rate limiting, and firewall scope according to the workload, review share and NTFS permissions, pilot changes with older clients and high-throughput workloads, and monitor SMB security, authentication, and performance events after enforcement. Possible drawbacks: Mandatory SMB signing and encryption consume processor resources and can reduce throughput or increase latency on demanding file workloads. Older storage appliances, scanners, applications, or clients might not support modern SMB requirements, and overly restrictive port or permission changes can disrupt file access, administration, Group Policy, or backup operations. Documentation: SMB security hardening | Secure SMB traffic in Windows Server Require modern TLS and manage certificates securely Modern TLS protects application and management traffic by authenticating endpoints and encrypting data in transit. Requiring current protocol versions, strong cipher suites, and trusted certificates mitigates eavesdropping, man-in-the-middle attacks, protocol downgrade, weak-cryptography attacks, and impersonation using invalid or compromised certificates. Require TLS 1.2 or later and prefer TLS 1.3 where the application stack supports it. Windows Server 2025 disables TLS 1.0 and TLS 1.1 by default; verify that these protocols and obsolete SSL versions remain disabled and prevent unauthorized re-enablement. Disable weak cipher suites and obsolete hashes through a tested baseline rather than ad hoc registry changes. Inventory old agents, middleware, and network appliances first so incompatible dependencies can be upgraded instead of becoming permanent exceptions. Use certificates from a trusted public or enterprise certification authority, protect private keys with restrictive access control, select appropriate key sizes and algorithms, monitor expiration, and automate renewal. After dependency review, remove expired, untrusted, orphaned, or unnecessary certificates from server stores. Implementation steps: Inventory listening services, clients, protocol versions, cipher dependencies, and installed certificates, then replace weak or expiring certificates and confirm application support for modern TLS. Verify that TLS 1.0 and TLS 1.1 remain disabled, apply tested Schannel or OSConfig settings in stages, disable other legacy protocols and weak ciphers, validate every client and integration, rescan the endpoints, remove only certificates confirmed to be unnecessary, and implement automated certificate enrollment, renewal, expiration alerting, and private-key access review. Possible drawbacks: Disabling old protocols and ciphers can break legacy clients, middleware, monitoring agents, or network devices with no modern TLS support. Certificate issuance, private-key protection, renewal automation, and revocation checking add operational complexity, and an expired or incorrectly deployed certificate can cause a complete service outage. Documentation: TLS/SSL and Schannel overview | OSConfig baseline protocol protections | Deprecated Windows Server features Encrypt operating-system and data volumes with BitLocker BitLocker encrypts data at rest so possession of a disk or offline copy does not provide immediate access to its contents. It mitigates data theft from lost or stolen servers, removed drives, improperly decommissioned hardware, offline password-reset attacks, and attempts to read files by booting an alternate operating system. Enable BitLocker on operating-system and data volumes, using TPM-backed protectors and additional startup authentication where the physical threat model and availability requirements justify it. Use virtual TPMs and supported host or cloud protections for virtual machines. Encryption protects data on removed drives, decommissioned hardware, stolen systems, and offline copies. Escrow recovery information in a protected, recoverable directory or management service before enforcement. Limit access to recovery keys, audit retrieval, include key recovery in incident procedures, and test recovery on representative systems so encryption does not become an availability risk. Implementation steps: Inventory operating-system and data volumes, confirm TPM or virtual TPM readiness, select protectors that meet the physical and availability threat model, and configure a protected recovery-key escrow location. Enable BitLocker in controlled stages, verify encryption and key backup, test normal reboot and recovery scenarios, document break-glass procedures, and continuously monitor encryption and protector compliance. Suspend protection for firmware or boot-chain maintenance only through an approved procedure, then verify that BitLocker protection resumes afterward. Possible drawbacks: Lost recovery material can make encrypted data permanently inaccessible, while firmware, TPM, boot, or hardware changes can unexpectedly trigger recovery. Encryption can add some performance and operational overhead, and startup PINs can conflict with unattended reboot requirements, so protector selection, key escrow, and recovery testing must reflect the server's availability needs. Documentation: BitLocker planning guide | BitLocker operations guide | BitLocker recovery overview Configure detailed auditing and protect local logs Detailed auditing records security-relevant activity so suspicious behavior can be detected, investigated, and attributed. Authentication, privilege, process, PowerShell, policy, and firewall logs help expose brute-force attempts, credential misuse, privilege escalation, persistence, defense evasion, and attacker efforts to alter system configuration. Enable advanced audit policy for successful and failed logons, credential validation, account and group changes, sensitive privilege use, process creation with command-line capture, policy changes, removable storage, file shares, firewall activity, and other events relevant to the server role. The OSConfig baseline enables a broad audit configuration and increases important log sizes to improve forensic coverage. Enable PowerShell module and script block logging, and use protected event logging where appropriate because command content can contain sensitive data. Increase log capacity and retention for the expected event volume, restrict permissions to clear or modify logs, monitor audit-policy changes, and synchronize time with trusted sources. Implementation steps: Define the activities and events required for detection, investigation, and compliance, then apply advanced audit policy through OSConfig or Group Policy. Enable process command-line and PowerShell logging, measure event volume during a representative pilot, size and protect each log and forwarding path from the observed rates, configure trusted time synchronization, generate representative test events to confirm collection, and review event volume, retention, and policy health regularly. Possible drawbacks: Detailed auditing can generate large volumes of events, consume storage and processing resources, and overwhelm analysts with noise if collection isn't tuned. Command-line and PowerShell logs can contain credentials or other sensitive data, while undersized logs may overwrite useful evidence, so access, retention, filtering, and capacity require deliberate design. Documentation: OSConfig baseline auditing and visibility | Recommended audit policy for Windows Event Forwarding | PowerShell logging on Windows Centralize security telemetry and alert on suspicious activity Centralized telemetry moves evidence away from the system that generated it and correlates activity across servers, identities, and networks. This improves detection of distributed attacks, limits an intruder's ability to erase local evidence, and shortens response time for credential attacks, lateral movement, persistence, defense evasion, and destructive actions. Forward security-relevant logs away from each server using Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM such as Microsoft Sentinel, or another protected collection platform. Include Security, System, Windows Defender, PowerShell, Code Integrity, Windows Firewall, Windows LAPS, and role-specific operational logs. Create actionable alerts for repeated authentication failures, new or changed administrators, unexpected service or scheduled-task creation, security-control changes, Defender detections, App Control blocks, log clearing, unusual remote administration, and backup deletion. Restrict access to collectors and retention systems so an attacker who compromises a server cannot erase the centralized evidence. Implementation steps: Select Windows Event Forwarding, Azure Monitor, Microsoft Defender, a SIEM, or a combination; define prioritized detection use cases and role-specific retention before selecting log channels and verbosity; design resilient collectors, access control, and capacity; and deploy the required agents or subscriptions. Onboard the prioritized channels, verify end-to-end ingestion and timestamps, create and test high-value detections and notifications, restrict access to the monitoring platform, and continuously monitor collection health and tune noisy rules. Possible drawbacks: Central collection introduces bandwidth, storage, ingestion, licensing, retention, and analyst costs and can expose sensitive operational data if the monitoring platform is poorly secured. Collector failures create visibility gaps, while poorly tuned rules produce false positives and alert fatigue, so the design needs resilience, health monitoring, access controls, and continuous tuning. Documentation: Use Windows Event Forwarding for intrusion detection | Microsoft Defender for Endpoint security capabilities Maintain ransomware-resilient backups and test recovery Ransomware-resilient backups preserve a trustworthy recovery path when production data, operating systems, or identity services are encrypted, deleted, or corrupted. Isolated and immutable copies mitigate ransomware, destructive administrators, compromised backup credentials, accidental deletion, hardware failure, and attacks intended to eliminate both systems and their recovery data. Keep multiple protected backup copies, including a copy that is offline, immutable, or otherwise isolated from normal server and domain administrator credentials. Use separate backup administration identities, multifactor authorization for destructive operations, encryption, soft delete or immutability controls, and alerts for policy changes or mass deletion. Hypervisor snapshots alone are not an adequate backup strategy. Back up application data and configuration as well as system state and bare-metal recovery data where required by the server role. Define recovery-point and recovery-time objectives, test file, application, system-state, and full-server restoration regularly, and record the evidence. Domain controllers, certificate authorities, and other identity infrastructure require workload-aware recovery procedures. Implementation steps: Classify workloads and define recovery-point and recovery-time objectives, then select local, offsite, offline, and immutable backup targets appropriate to the risk. Use separate backup identities and MFA, schedule application data, configuration, system-state, and bare-metal backups as required, enable encryption and deletion protections, and monitor every job and policy change. Perform regular isolated restore tests that verify application consistency and role-specific recovery semantics for identity systems, not only successful restoration of files or virtual disks, and maintain documented recovery runbooks. Possible drawbacks: Multiple isolated copies, immutable storage, long retention, and regular restore exercises increase storage, network, licensing, staffing, and operational costs. Backups can create false confidence when they are incomplete, stale, infected, or untested, and strong credential separation can slow routine administration, so restore validation and lifecycle management are as important as backup creation. Documentation: Design a ransomware-resilient backup architecture | Azure Backup security best practices | Back up Windows Server system state --- This isn't everything you can do, but it's a start. What other techniques do you use to harden your Windows Server deployments?Internet Information Services Learning Path
Internet Information Services (IIS) is the modular web server and application platform that first shipped as an optional add-on for Windows NT 3.51 in 1995, evolving from basic HTTP and FTP services into a full-featured web stack tightly integrated with Windows Server and Client operating systems. Today, IIS remains a core component of Windows Server and client editions, used to host legacy and modern web applications, APIs, and services in on-premises and hybrid environments alongside newer cloud-native options. The following training modules on Microsoft Learn provide you with a structured curriculum to learn how to manage and maintain Internet Information Services. It's relevant to almost all supported versions of IIS, but also includes coverage of some functionality that is available with Windows Server 2025. The modules in this learning path are as follows: Deploy and configure Internet Information Services. Understand how to configure, administer, and validate an IIS installation on Windows Server. Configure Internet Information Services websites and applications. Create and configure websites, web applications, and virtual directories in IIS. Manage Internet Information Services. Scripting bulk configuration changes, watching worker processes for signs of trouble, or run health checks to keep your IIS environment running reliably. Secure and harden Internet Information Services. Authentication, authorization, and other security best practices to protect the server and websites. Troubleshoot and optimize IIS performance. Learn how to troubleshoot IIS problems with logs, tracing, and performance counters, then apply tuning changes to improve reliability and throughput. The Administer Internet Information Services learning path collects all these modules together, providing you with a comprehensive guide to managing and maintaining Internet Information Services.Foundry Local Web UI for IIS
If you've been exploring local AI with Microsoft Foundry Local, you've learned that running a chatbot frontend on Windows Server or Windows Client that you can access over the network comes with a challenging set of dependencies. FoundryLocalWebUI is a simple, self-contained web frontend for Foundry Local that runs on IIS, works on both Windows Server and Windows Client, and uses common Windows ecosystem components. You can find the project on GitHub: https://github.com/itopstalk/FoundryWebUI Here is an explanatory video here: https://youtu.be/IGWNhSQziZI FoundryLocalWebUI is a lightweight web application designed to be hosted on IIS, which is already available to Windows Server and can be enabled on Windows Client with a few clicks. There is no need to install a separate web server, worry about a package manager, or spin up a Windows Subsystem for Linux environment. FoundryLocalWebUI is an experimental proof of concept. It doesn't support multiple users and just provides basic chatbot functionality. It's suitable if: You're evaluating Foundry Local and want a quick, no-fuss frontend to test models through a browser rather than the command line. You want to keep your deployment footprint small and your dependencies minimal. You're running Windows Client and want a local chat interface without the overhead of heavier solutions. The setup process is intentionally straightforward. Make sure that Git is installed: winget install --id Git.Git -e --accept-source-agreements --accept-package-agreements Clone the repo and run the installer (you'll have to use set-executionpolicy to allow the PowerShell script to run) cd C:\Projects git clone https://github.com/itopstalk/FoundryWebUI.git FoundryLocalWebUI cd FoundryLocalWebUI # Windows Server 2025: .\Install-FoundryWebUI.ps1 # Windows 10/11: .\Install-FoundryWebUI-Desktop.ps1 Full setup details are in the GitHub repo, and the walkthrough video covers the process end to end if you'd rather follow along visually. This is still early days for the project, and I'd love to hear from the community. Local AI is becoming a real option for organizations that need to keep data on-premises and maintain control over their infrastructure. Spin up a WS 2025 eval edition VM and give it a go.Configure a log analytics workspace to collect Window Server Event log, IIS and performance data.
Configuring Azure Monitor with Log Analytics for IIS Servers Azure Monitor combined with Log Analytics provides centralized telemetry collection for performance metrics, event logs, and application logs from Windows-based workloads. This guide demonstrates how to configure data collection from IIS servers using Data Collection Rules (DCRs). Create the Log Analytics Workspace Navigate to Log Analytics workspaces in the Azure portal Select Create Choose your resource group (e.g., Zava IIS resource group) Provide a workspace name and select your preferred region Select Review + Create, then Create After deployment, configure RBAC permissions by assigning the Contributor role to users or service principals that need to interact with the workspace data. Configure Data Collection Infrastructure Create a Data Collection Endpoint: Navigate to Azure Monitor in the portal Select Data Collection Endpoints, then Create Specify the endpoint name, subscription, resource group, and region (match your Log Analytics workspace region) Create the endpoint Create a Data Collection Rule: Navigate to Data Collection Rules and select Create Provide a rule name, resource group, and region Select Windows as the platform type Choose the data collection endpoint created in the previous step Skip the Resources tab initially (you'll associate VMs later) Configure Data Sources Add three data source types to capture comprehensive telemetry: Performance Counters: On the Collect and Deliver page, select Add data source Choose Performance Counters as the data source type Select Basic for standard CPU, memory, disk, and network metrics (or Custom for specific counters) Set the destination to Azure Monitor Logs and select your Log Analytics workspace Windows Event Logs: Add another data source and select Windows Event Logs Choose Basic collection mode Select Application, Security, and System logs Configure severity filters (Critical, Error, Warning for Application and System; Audit Success for Security) Specify the same Log Analytics workspace as the destination IIS Logs: Add a final data source for Internet Information Services logs Accept the default IIS log file paths or customize as needed Set the destination to your Log Analytics workspace After configuring all data sources, select Review + Create, then Create the data collection rule. Associate Resources Navigate to your newly created Data Collection Rule Select Resources from the rule properties Click Add and select your IIS servers (e.g., zava-iis1, zava-iis2) Return to Data Collection Endpoints Select your endpoint and add the same IIS servers as resources This two-step association ensures proper routing of telemetry data. Query Collected Data After allowing time for data collection, query the telemetry: Navigate to your Log Analytics workspace Select Logs to open the query editor Browse predefined queries under Virtual Machines Run the "What data has been collected" query to view performance counters, network metrics, and memory data Access Insights to monitor data ingestion volumes You can create custom KQL queries to analyze specific events, performance patterns, or IIS log entries across your monitored infrastructure. Find out more at: https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/overviewDeploy and configure an Azure Application Gateway for load balancing and website protection.
Azure Application Gateway provides layer 7 load balancing with integrated Web Application Firewall (WAF) capabilities, enabling traffic distribution across backend servers while protecting against common web exploits like SQL injection and DDoS attacks. This guide walks through deploying an Application Gateway to front-end two Windows Server IIS instances in an availability set. Network Infrastructure Configuration The first step you need to take is to prepare your Azure network infrastructure for Azure Application Gateway deployment. You can do this by performing the following steps: Create Application Gateway Subnet Navigate to Virtual Networks and select your IIS VNet Select Subnets > Add Subnet Configure the subnet: Name: app-GW-subnet Starting address: 10.0.1.0 (or next available subnet range) Leave other settings at defaults (no private endpoint policies or subnet delegation required)app-gateway-iis-vms-narrated-itopstalk.txt Configure NSG Rules for Backend Traffic Select the first IIS VM's Network Security Group Create an inbound rule: Source: Application Gateway subnet (10.0.1.0/24) Service: HTTP Provide priority and descriptive name Repeat for the second IIS VM's NSG to allow traffic from the Application Gateway subnet on port 80app-gateway-iis-vms-narrated-itopstalk.txt Application Gateway Deployment Once the Azure network infrastructure is prepared, you can then deploy the application gateway and configure network traffic protection policies. Basic Configuration Search for Application Gateways in the Azure Portal Click Create > Application Gateway Configure basic settings: Resource Group: Same as IIS VMs Name: (e.g., ZAVA-app-GW2) Region: Same as IIS VMs Tier: Standard V2 IP Address Type: IPv4 only Select Configure Virtual Network and choose the IIS VNet Select the Application Gateway subnet created earlier Create a new public IPv4 address for the gateway frontend. Backend Pool Configuration On the Backends page, select Add a backend pool Provide a pool name Add both IIS VM private IP addresses to the pool. Routing Rule Configuration On the Configuration page, select Add a routing rule Configure the listener: Provide a rule name Create a listener with a descriptive name Protocol: HTTP Port: 80 Listener type: Basic Configure backend targets: Target type: Backend pool Backend pool: Select the pool created in the previous step Create new backend settings with port 80 Configure optional settings (cookie affinity, connection draining) as needed Specify a priority for the routing rule Complete the wizard to deploy the gatewayapp-gateway-iis-vms-narrated-itopstalk.txt Verification and Testing Navigate to Application Gateways and select your deployed gateway Copy the Public IP Address from the overview page Access the public IP in a browser and refresh multiple times to observe load balancing between IIS-1 and IIS-2 Navigate to Backend Pools to view backend health status for troubleshooting. Web Application Firewall Protection In your Application Gateway, navigate to Web Application Firewall Select Create a web application firewall policy Provide a policy name Enable Bot Protection for enhanced security Save the policy Review the policy's Managed Rules to confirm OWASP Core Rule Set and bot protection rules are active. The Application Gateway now distributes traffic across your IIS availability set while providing enterprise-grade security protection through integrated WAF capabilities. Find out more at: https://learn.microsoft.com/en-us/azure/application-gateway/overviewDeploying Windows Servers in an Azure Availability Set
Deploying Windows Servers in an Azure Availability Set This guide demonstrates deploying Windows Server an Azure Availability Set for Windows Server IIS workloads. An availability set logically groups virtual machines across fault domains and update domains within a single Azure data center. Fault domains provide physical hardware isolation (separate racks, power, and network switches), while update domains ensure Azure staggers platform maintenance, rebooting only one domain at a time with 30-minute recovery windows. VMs must be assigned to availability sets during creation and you cannot add existing VMs later. Creating the First VM Navigate to Azure Portal > Virtual Machines > Create Create a new resource group (e.g., "Zava IIS") Name the VM (e.g., "Zava IIS 1") and select region (e.g., East US 2) Under Availability Options, select "Availability set" > Create New Name the availability set and accept defaults (2 fault domains, 2 update domains) Configure local admin account (avoid using "Administrator") Select "No inbound ports" for security Enable Azure Hybrid Benefit if you have existing Windows Server licenses Verify Premium SSD is selected under Disks (required for 99.95% SLA) Note the virtual network name for subsequent VMs Under Management, disable automatic shutdown and hotpatch Under Monitoring, disable boot diagnostics Review and create the VMAvailability-Set-Audio-Pre-avatar.txt Creating the Second VM Return to Virtual Machines > Create Use the same resource group Name the second VM (e.g., "Zava IIS 2") Select the existing availability set created in step 4 above Match all settings from the first VM (admin account, no inbound ports, hybrid benefit, Premium SSD) Ensure the VM connects to the same virtual network as the first VM Disable auto shutdown, hotpatch, and boot diagnostics Review and create Ensure that the VMs are configured with Premium SSD to achieve the highest possible SLA of 99.999%. In a future post, we’ll cover how to configure Azure Application Gateway to load balance traffic across computers in an availability set as well as protecting against DDoS and OWASP top 10 attacks Learn more about Azure Availability Sets
Microsoft Entra Domain Services: Deploy, Join a VM, and Use Classic AD Tools
Microsoft Entra Domain Services (Entra DS) provides you with the functionality of managed domain controllers in Azure. This allows you to domain-join Windows Server VMs, use Group Policy, and manage DNS on a specially prepared vNet subnet without deploying and patching your own DC VMs. This post walks through: • Preparing your virtual network • Deploying Entra DS • Configuring DNS • Joining a Windows Server VM to the managed domain • Using AD DS and Windows Server DNS tools from that VM Prerequisites • An Azure subscription. • A Microsoft Entra tenant with a custom DNS domain verified (for example, zava.support). Entra DS uses this custom domain as the managed domain name. • Permission to create resource groups, VNets, and Entra DS. • Permission to manage Entra groups in the tenant (add administrators/configure RBAC). Step 1 – Create a resource group and virtual network 1. Create a new resource group in your chosen region to hold all Entra DS resources and VMs. 2. Create a virtual network (for example, zava-entra-dsvn) in that resource group (for example, address space: 172.16.0.0/16 (or a range that fits your environment). 3. Add a subnet dedicated to the Entra DS domain controllers (for example, zava-entra-dc). This subnet will host the managed domain controller resources created by Entra DS and you won’t actually deploy VMs there. Important Keep this DC subnet separate from your workload subnets. You can use NSGs, but avoid blocking Entra DS management traffic. Step 2 – Add a workload subnet for VMs 1. In the same virtual network, create a second subnet (for example, zava-domain-vms) for domain-joined workloads such as IIS VMs. This special subnet is where you’ll deploy the Windows Server VM that joins the Entra DS domain. Step 3 – Deploy Microsoft Entra Domain Services In the Azure portal, create a new Microsoft Entra Domain Services managed domain by performing the following steps: 1. Select the resource group you created earlier. 2. Confirm the DNS domain name (for example, zava.support)—this comes from your Entra tenant’s custom domain. 3. Choose the region (same region as the virtual network). 4. Keep the default Enterprise SKU unless you have a specific need for another. 5. On the Networking page: · Select the virtual network you created. · Select the DC subnet for the managed domain controllers. 6. On the Administration page note that the AAD DC Administrators group (legacy name shown in the portal) is effectively the Domain Admins equivalent for the managed domain. Any user you add to this group in Entra becomes a domain admin in Entra DS. 7. Configure synchronization scope between Entra and Entra DS. · All accounts (default) – synchronizes both cloud-only and synchronized users. · Cloud-only accounts – useful when you’re already syncing on-prem identities and you only want specific cloud accounts in Entra DS. 8. Review the Security settings page. By default: · NTLMv1 disabled. · You can enable/disable NTLM password sync, or effectively disable NTLM entirely. · RC4 encryption disabled by default. · Kerberos armoring enabled by default. · LDAP signing and LDAP channel binding enabled by default. 9. Review your configuration and create the Entra DS managed domain. Note after deployment, you cannot change: • The managed domain DNS name • Subscription • Resource group • Virtual network and subnet used by Entra DS Step 4 – Fix virtual network DNS with Entra DS health checks 1. Once deployment completes, open the Entra DS resource and go to View health. 2. Run the health checks. If the diagnostic reports that the virtual network DNS servers are not set to the Entra DS managed DC IPs, select Fix to automatically configure the VNet’s DNS servers. · In Entra DS, note the DNS server IPs (for example, 172.16.0.4 and 172.16.0.5). · In the virtual network’s DNS settings, confirm these IPs are configured as custom DNS servers. Tip Any VM in this virtual network that needs to join the managed domain must use these Entra DS DNS addresses. Step 5 – Add administrators to the AAD DC Administrators group 1. In the Entra admin center, go to Groups > All groups and locate AAD DC Administrators. 2. Open the group and add your primary admin account (for example, prime@zava.support) and add a dedicated domain admin–style account (for example, adds.prime@zava.support) to be the primary administrator for the managed domain. Important note: You’ll need to change the password of any Entra account you want to use in the managed AD DS domain after deploying Entra DS. This will configure password synchronization between Entra and Entra DS, allowing you to use the Entra account. If you don’t change the password, you’ll be unable to use the account with Entra DS even though it will function normally in other parts of Azure. This trips a lot of people up. Step 6 – Create a Windows Server IaaS VM on the workload subnet 1. In the Azure portal, create a new Windows Server VM (for example, an IIS server): 1. Place it in the same resource group. 2. Select the virtual network you created earlier. 3. Attach it to the workload subnet (for example, zava-domain-vms). 4. Configure a local administrator account (for example, username prime with a strong password). 2. On the Management blade, note the option “Login with Microsoft Entra ID”: 1. This enables direct Entra login to the VM but does not join the VM to the Entra DS domain. 2. For this walkthrough, you’ll join the VM to Entra DS using classic domain join so don’t need to enable this option. 3. Complete the wizard and deploy the VM. Step 7 – Connect to the VM and verify DNS 1. Once the VM is deployed, open the VM in the portal and select Connect > RDP. 1. Request a JIT RDP port opening if required. 2. Download the RDP file and open it with Remote Desktop Connection. 2. Sign in with the local administrator account you configured when deploying the VM and not your Entra account. 3. In the VM, open a command prompt and run: ipconfig /all 1. Confirm that the DNS servers are the Entra DS managed IPs (for example, 172.16.0.4 and 172.16.0.5). If DNS is wrong Double-check the VNet’s DNS settings and ensure the VM is attached to the correct virtual network and subnet, then restart the VM. Step 8 – Join the VM to the Entra DS domain 1. On the VM, open Server Manager and select Local Server. 2. Next to Workgroup, select the workgroup name to open System Properties (Computer Name tab). 3. Select Change… and then: · Under Member of, select Domain. · Enter the Entra DS domain name (for example, zava.support). 4. When prompted for credentials, use an account that’s a member of AAD DC Administrators, such as adds.prime@zava.support, and enter the password. 5. When you receive the confirmation that the computer has joined the domain, restart the VM. Step 9 – Sign in with an Entra DS domain account 1. After the VM restarts, reconnect via RDP using the VM’s public IP and: · Username: your domain UPN (for example, adds.prime@zava.support). · Password: the account’s password. 2. Confirm that you are signed in as a domain user in the Entra DS managed domain. Step 10 – Use AD DS and DNS tools on the domain-joined VM 1. Install and open Active Directory Users and Computers (RSAT) on the VM. · Browse the managed domain structure. · Notice containers such as AADDC Computers, AADDC Users, and groups like Domain Admins that map back to Entra groups. 2. Create an organizational unit (OU), for example IIS Servers, to contain IIS VMs. 3. Open Group Policy Management and: · Create a Group Policy Object targeting the IIS Servers OU. · Link and configure settings as required (hardening, IIS config, etc.). 4. Open the DNS Manager console on the VM, which now connects to the Entra DS–managed DNS servers. 5. Create a new Host (A) record, for example: · Name: iis3 · FQDN: iis3.zava.support · IP address: the appropriate internal address. 6. Open a command prompt and verify DNS resolution with: nslookup iis3.zava.support • Confirm it returns the correct IP address. Entra DS gives you familiar AD capabilities—domain join, Group Policy, and DNS—without the overhead of running and maintaining your own DC VMs in Azure. You can find out more at: https://learn.microsoft.com/en-us/entra/identity/domain-services/overview
