MICROSOFT XPS DOCUMENT WRITER
Good Day! Does anyone know who to install the same MICROSOFT XPS DOCUMENT WRITER that installs on WINDOWS 10/11 on SERVER 2025. An application needs it to send emails with attachments via OUTLOOK. None of the drivers available to install manually are the same as the one on WINDOWS 10/11. Thank you!
DCs not replicating across VPN
I am at a loss here. I have looked at every CMD option I can find, verified DNS and cannot get my DCs replicating across the VPN. I don't understand how I was able to join the domain but now the connectivity is a problem. So here is my setup: 2 DCs in Site (my building) 2 DCs in Datacenter connected by IPSec VPN I can ping the IP, the DNS name, the short name, and the domain from all DCs regardless of location. I have verified on each DNS server that the name servers are correct and resolved. I have run nltest, dcdiag, syncall, repadmin, etc. The only error that keeps showing up in most commands is 1722 network error. RPC unavailable. Topology incomplete. One oddity that I found was that on the DCs in the datacenter Sites and Services was missing one of the local DCs. I added it manually but there are no NTDS Settings for it. I have flushed DNS, reregistered DNS, restarted the servers. All Windows firewalls are set to ANY ANY for domain services. My WAN firewalls are ANY ANY between the sites I have no idea what to look for next. Please if anyone has ideas let me know. Also I have already build new servers multiple times and this keeps happening.
What's the deal with Kerb3961?
Howdy, everyone! I wanted to write this blog post to discuss the new Kerb3961 library introduced in Windows Server 2025 / Windows 11 24H2. It is (hopefully) making encryption type (etype) usage within Kerberos much easier to anticipate and understand. Let's start with... What is Kerb3961? Kerb3961, named after RFC3961, is a refactor of the Kerberos cryptography engine in its own library. This library is now the authoritative source of: Etype selection Etype usage Etype management For the average IT administrator, the part that is going to be most interesting is #1. The Kerb3961 policy engine is what will authoritatively determine what etypes are available given different Kerberos key usage scenarios. Whereas in previous Windows releases, there were instances of hard coded etype usage due to technical limitations at the time of implementation. Kerb3961 still leverages existing Kerberos etype configuration group policy: Network security Configure encryption types allowed for Kerberos - Windows 10 | Microsoft Learn. However, it no longer honors the legacy registry key path of: HKEY_LOCAL_MACHINE\CurrentControlSet\Control\Lsa\Kerberos\Parameters REG_DWORD SupportedEncryptionTypes As a reminder, the group policy mentioned above is used to configure the supported encryption types for a machine account. The machine then propagates this information into Active Directory (AD) where it is stored in the msds-SupportedEncryptionType attribute for the account. It has no effect on non-etype related Kerberos settings such as those outlined in Registry entries about Kerberos protocol and Key Distribution Center (KDC) with the exception of the DefaultDomainSupportedEncTypes registry key. The biggest change is the reduction of hard-coded etype usage. We have heard the frustrations of customers who are trying to eliminate RC4 usage, and the seemingly unexplainable instances of RC4 usage with their environments. This new library removes these hard-coded dependencies and aggregates all those decisions into one place. With the goal of: More secure Kerberos operations by default More predictable Kerberos etype usage More stable etype additions More stable etype removals For example, if we had not done this refactor, the DES deprecation and on-going work towards RC4 deprecation would not be possible. Why did this need to happen? Kerberos was added to Windows in the early 2000's as a part of beginning the move away from NTLM and into modern cipher usage. Over these decades, there have been incredible strides in security hardening that the original developers could not have foreseen. As a result, some of the design decisions made during that initial implementation impacted our ability to reliably change the way Kerberos operates. This can be seen in things like: Kerberos changes for CVE-2022-37966 Kerberos changes for CVE-2022-37967 Additionally, with the long tail of code in this area and the etype that has been historically used, it had become a near impossibility to add or remove a cipher due to how the etypes were directly associated in Kerberos. What does this mean going forward? The Kerb3961 library has key implications going forward. The biggest one is the removal of hard-coded cipher usage and a stronger adherence to the administrators’ configured encryption types. The environment will operate as configured. Meaning IT administrators can have a high degree of confidence that their configurations will be honored. This increases the amount of knowledge required by administrators. Misconfigurations, previously hidden by loose adherence to the configured etypes, will now be exposed. For more information about Kerberos etype selection, refer to the Kerberos EType Calculator. What needs to be done? To configure an environment requires understanding what etypes are used within an environment. To help aid in this endeavor, we have improved Key Distribution Center (KDC) auditing. 4768(S, F) A Kerberos authentication ticket (TGT) was requested. - Windows 10 | Microsoft Learn 4769(S, F) A Kerberos service ticket was requested. - Windows 10 | Microsoft Learn We have also published two PowerShell helper scripts that leverage these new events. The goal of these scripts is to allow for easier identification of both etype usage and account key availability. These scripts are published on the Microsoft Kerberos-Crypto GitHub repository, where, going forward, we will be using scripts and information published there to better interface with the community. We acknowledge that substantial changes can introduce regressions and friction points for those with mature environments. It is our goal to allow for a smooth adoption of these new features and prevent any unnecessary pain for our already overworked and under-appreciated system administrators. Please be sure to leverage Feedback Hub to share your experiences with us. If you would like to see any of these features early, we highly recommend leveraging the Windows Insider Program and opting into Continuous Innovation and sharing feedback directly with the development team. We understand that this can be challenging, and Microsoft is committed to ensuring that the knowledge needed to make an informed decision about what is right for your environment.
Windows update failure Error 0x8024200B
Windows server 2022 standard version 21H2 Installed 08/04/2025 OS Build 20348.3807 KB5063880 installation failed. Error 0x8024200B Latest servicing stack installed 10.0.20348.4160 Can't get the update to install, been through the entire guide on how to reset windows update etc. The only solution I can find is to reset windows and reinstall the OS, but surely that is a bit drastic for a security update, especially since the server was installed only 5 months ago? Any help would be useful please!Introducing the VM Conversion tool in Windows Admin Center – Public Preview
As organizations update their infrastructure, a growing number are seeking adaptable, Microsoft-supported solutions that address current requirements while laying the path for future cloud and AI adoption. Azure provides an agile, scalable, cost-effective platform for infrastructure and innovation. Whether by modernizing to cloud technologies like Windows or Linux VMs, containers, Azure VMware Solution or PaaS services, Azure offers a world-class cloud experience. However, we recognize that some organizations must retain workloads on-premises due to data compliance, governance, or other regulatory requirements. For customers wanting to adopt Windows Server and Hyper-V for this use case, we are excited to provide a new option within Windows Admin Center, the VM Conversion tool, in public preview now. This agentless, cost-free tool streamlines the conversion of virtual machines from VMware to Windows Server with Hyper-V, providing customers flexibility with their on-premises virtualization environments while enabling a seamless transition path to Azure when desired. With minimal infrastructure requirements, the tool is particularly beneficial for small and medium-sized organizations. Additionally, with minimal setup time you can download the new VM Conversion tool extension in Windows Admin Center and begin converting virtual machines in under five minutes. Figure 1- VM Conversion tool in Windows Admin Center 🔑Key Features : Agentless, appliance-free discovery After establishing a connection to the virtualization environment, the tool conducts discovery of all virtual machines without requiring agents or appliances and does so in a non-intrusive manner. Minimal downtime The VM Conversion tool enables initial data replication while the source virtual machine remains operational, thereby preventing any interruptions to ongoing applications. After completing this initial replication, on user consent, the source VM is powered down so a subsequent replication pass can capture any data changes made during the first phase. This two-step process ensures that the cutover time from the source to the target VM is minimized. Group servers You can select and migrate up to 10 virtual machines at a time. This reduces manual effort and accelerates the transition to Windows Server. Boot configuration The tool automatically maps BIOS-based virtual machines to Generation 1 and UEFI-based machines to Generation 2, preserving boot configurations and ensuring compatibility. OS agnostic The tool supports conversion of both Linux and Windows guest OS VMs to Windows Server host. Multi-disk VM support Virtual machines that use several virtual hard disks—common in production environments—are fully supported. The operating system, data, and application disks all migrated together, so manual setup is not needed. ⚙️How It Works To ensure a smooth and reliable transition, the tool performs a comprehensive set of built-in prechecks. These checks validate critical VM attributes such as disk types, boot configuration (BIOS or UEFI), destination disk, memory requirements, and several more. By identifying potential issues early, administrators can proactively address them—minimizing the risk of migration failures and reducing downtime during the final cutover. The VM Conversion tool uses change block tracking (CBT) to efficiently replicate data from one virtual disk format to another. During the initial seeding phase, a full copy of the virtual machine is created while it remains online. This minimizes downtime and ensures data integrity. Before the final cutover, a delta replication captures all changes made since the initial copy, ensuring the destination VM is fully up-to-date post conversion to Hyper-V hosts. 🚀Ready to Take the Next Step? The VM Conversion tool is available now in the public feed of Windows Admin Center. You can install it directly from the Extensions settings in Windows Admin Center. To get started, ensure you're running the Windows Admin Center v2 GA release. 📘 For detailed setup instructions and prerequisites, refer to the Public Preview Documentation. 📍 Summary The VM Conversion tool offers a simple, supported path for organizations to streamline VM conversion to Hyper-V virtualization environments. With no added cost and minimal setup, it empowers customers to streamline VM migration and prepare for the cloud at their own pace. Support for Azure Arc-enabled servers is also planned for future releases, further enhancing hybrid management capabilities. We’re continuously evolving the VM Conversion tool based on user feedback. Please continue to share your feedback here and help us prioritize our efforts for future releases. Happy converting!Server 2016 Essentials coexisting with Server 2022 Standard
I am in the process of replacing an older Server 2016 essentials with a Server 2022 Standard. The 2016 Essentials server is today acting as the primary domain controller for the domain. My plan is to: 1. install the new Server 2022 Std 2. Join it to the existing domain as a Backup Domaincontroller 3. Promote the new server to PDC 4. Move contents and applications on the Essentials 2016 server 5. Demote the old 2016 Essentialsserver 6 Decomission the old server. 7. Lift the entire domain to a higher level. So the question is. Can these servers co-exist as domain controllers in the same environment or do I have to have another approach to the server change? Best regards, David
No SET-Switch Team possible on Intel X710 NICs?
Hello, we have lot of servers from different vendors using Intel X710 DA2 network cards. They work fine in standalone and they work fine if we create switch independet teams using Server Manager, Regardless of Dynmic or Hyper-V Port. But sadly we can't use these teams in Server 2025 because have to create SET-Switch Teams instead. But as soon as we create an Hyper-V SET-Switch Team with X710 cards, they have limited to no network communication. They still can communicate with some servers, are slow with some ohters, and can't communicate with some at all. Especially communication to other servers, which also use X710 cards with SET-Switches, is zero. SET-Teams with other cards like E810 work just fine. I've read several times that the X710 cards just wont work with SET, even since Server 2016. But I can't really give up on this, since we would have to replace a lot of them. We have tried to disable a lot of features like VMQ, RSS, RCS... but couln't make it work. Firmware and Drivers are the most recent, but it happens with older versions too. Does anyone have a solution? Thank you!Failed test VerifyReferences
Hello everyone, We are using Windows Server 2019 Standard as the primary and currently only domain controller. Previously, there were several additional domain controllers, but they have all been demoted. dcdiag test VerifyReference returns me the following error: Starting test: VerifyReferences Some objects relating to the DC 18DC06 have problems: [1] Problem: Missing Expected Value Base Object: CN=NTDS Settings,CN=18DC06,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=vk, DC=local Base Object Description: "DSA Object" Value Object Attribute Name: serverReferenceBL Value Object Description: "SYSVOL FRS Member Object" Recommended Action: See Knowledge Base Article: Q312862 [1] Problem: Missing Expected Value Base Object: CN=18DC06,OU=Domain Controllers,DC=vk, DC=local Base Object Description: "DC Account Object" Value Object Attribute Name: msDFSR-ComputerReferenceBL Value Object Description: "SYSVOL FRS Member Object" Recommended Action: See Knowledge Base Article: Q312862 ......................... 18DC06 failed test VerifyReferences Please advise on how to further investigate and resolve this issue. Thanks in advance.Shielded VM Template Creation in a Hyper-V Guarded Fabric
To set up a shielded virtual machine template on a Hyper-V guarded fabric, you need to prepare a secure environment (Host Guardian Service, guarded hosts) and then create a BitLocker-protected, signed template disk. This document assumes that all Windows Server instances used are running Windows Server 2022 or Windows Server 2025. Prerequisites and Environment Setup Host Guardian Service (HGS): Deploy an HGS cluster (typically 3 nodes for high availability) in a separate Active Directory forest dedicated to HGS. For production, HGS should run on physical (or highly secured) servers, ideally as a three-node cluster. Ensure the HGS servers have the Host Guardian Service role installed and are up to date with software updates. Attestation Mode: TPM-Based: Ensure that HGS is configured for TPM-trusted attestation. In TPM mode, HGS uses each host’s TPM 2.0 identity (EKpub) and measured boot sequence to verify the host’s health and authenticity. This requires capturing each Hyper-V host’s TPM identifier and establishing a security baseline: TPM 2.0 and Boot Measurements: On each Hyper-V host, retrieve the TPM’s public endorsement key (EKpub) and add it to the HGS trust store (e.g. using Get-PlatformIdentifier on the host and Add-HgsAttestationTpmHost on HGS). HGS will also require a TPM baseline (PCR measurements of the host’s firmware/boot components) and a Code Integrity (CI) policy defining allowed binaries. Generate these from a reference host and add them to HGS so that only hosts booting with the approved firmware and software can attest successfully. Host Requirements: Each guarded host (Hyper-V host) must meet hardware/OS requirements for TPM attestation. This includes TPM 2.0, UEFI 2.3.1+ firmware with Secure Boot enabled, and support for IOMMU/SLAT (for virtualization-based security). On each host, enable the Hyper-V role and install the Host Guardian Hyper-V Support feature (available in Datacenter edition). This feature enables virtualization-based protection of code integrity (ensuring the host hypervisor only runs trusted code), which is required for TPM attestation. (Test this configuration in a lab first as VBS/CI can affect some drivers). Guarded Fabric Configuration: Join Hyper-V hosts to the fabric domain and configure networking so that guarded hosts can reach the HGS servers (set up DNS or DNS forwarding between the fabric domain and HGS domain). After setting up HGS and adding host attestation data, configure each Hyper-V host as a guarded host by pointing it to the HGS cluster for attestation and key retrieval (using Set-HgsClientConfiguration to specify the HGS attestation and key protection URLs and any required certificates). Once a host attests successfully, it becomes an authorized guarded host able to run shielded VMs. HGS will release the necessary decryption keys only to those hosts that pass health attestation. Step 1: Create and Configure the Template VM (Gen 2) Prepare a Generation 2 VM: On a Hyper-V host (it can be a regular host or even a non-guarded host for template creation), create a new Generation 2 virtual machine. Generation 2 with UEFI is required for Secure Boot and virtual TPM support. Attach a blank virtual hard disk (VHDX) for the OS. Install Windows Server on this VM using standard installation media. Partition and File System Requirements: When installing the OS on the template VM, ensure the VHDX is initialized with a GUID Partition Table (GPT) and that the Windows setup creates the necessary partitions: there should be at least a small System/EFI boot partition (unencrypted) and the main OS partition (which will later be BitLocker-encrypted). The disk must be a basic disk (not dynamic within the guest OS) and formatted with NTFS to support BitLocker. Using the default Windows setup on a blank drive typically meets these requirements (the installer will create the EFI and OS partitions automatically on a GPT disk). Configure the OS: Boot the VM and perform any baseline configuration needed. Do not join this VM to any domain and avoid putting sensitive data on it as it should be a generic base image. Apply the latest Windows Updates and install any required drivers or software that should be part of the template OS (e.g. common management agents). Ensuring the template OS is fully updated is important for a reliable shielding process. Enable Remote Management: Because shielded VMs can only be managed remotely (no console access), consider configuring the template to enable Remote Desktop and/or PowerShell WinRM, and ensure the firewall is configured accordingly. You may also install roles/features that many VMs will need. However, do not configure a static IP or unique machine-specific settings in this template as those will be supplied via an answer file during provisioning. Step 2: Generalize the VM with Sysprep Run Sysprep: In the VM, open an elevated Command Prompt and run: C:\Windows\System32\Sysprep\Sysprep.exe /oobe /generalize /shutdown Choose “Enter System Out-of-Box Experience (OOBE)”, check “Generalize”, and set Shutdown option to “Shutdown” if using the GUI. This strips out machine-specific details and prepares the OS for first-boot specialization. The VM will shut down upon completion. Do Not Boot After Sysprep: Leave the VM off after it shuts down. The OS on the VHDX is now in a generalized state. Do not boot this VM again (doing so will boot into OOBE and break its generalized state). At this point you have a prepared OS disk (the VHDX) ready for sealing. (Optional) Backup the VHDX: It’s a good idea to make a copy of the sysprep’ed VHDX at this stage. After the next step (sealing the template), the disk will be BitLocker-encrypted and cannot be easily modified. Keeping an unencrypted copy allows you to easily update the template image in the future if needed. Step 3: Protect and Seal the Template Disk (Shielded Template Wizard) Next, seal the template VM’s OS disk using the Shielded VM Template Disk Creation process. This will encrypt the disk (preparing it for BitLocker) and produce a signed catalog so that the disk’s integrity can be verified later. Install Shielded VM Tools: On a machine with GUI (this can be a management server or even Windows 11 with RSAT), install the Shielded VM Tools component. On Windows Server, use PowerShell: Install-WindowsFeature RSAT-Shielded-VM-Tools -IncludeAllSubFeature (and reboot if prompted). This provides the Template Disk Wizard (TemplateDiskWizard.exe) and PowerShell cmdlets like Protect-TemplateDisk. Obtain a Signing Certificate: Acquire a certificate to sign the template disk’s Volume Signature Catalog (VSC). For production, use a certificate issued by a trusted CA that both the fabric administrators and tenants trust (e.g. an internal PKI or a certificate from a mutually trusted authority). The certificate’s public key will be referenced later by tenants to trust this template. (For a lab or demo, you can use a self-signed cert, but this is not recommended for production.) Import the certificate into the local machine’s certificate store if it’s not already present. Launch the Template Disk Wizard: Open Template Disk Wizard (found in Administrative Tools after installing RSAT, or run TemplateDiskWizard.exe). This wizard will guide you through protecting the VHDX: Certificate: Select the signing certificate obtained in the previous step. This certificate will be used to sign the template’s catalog. Virtual Disk: Browse to and select the generalized VHDX from Step 2 (the sysprep’ed OS disk). Signature Catalog Info: Provide a friendly name and version for this template disk (e.g. Name: “WS2025-ShieldedTemplate”, Version: 1.0.0.0). These labels help identify the disk and version to tenants. Proceed to the final page and Generate. The wizard will now: o Enable BitLocker on the OS volume of the VHDX and store the BitLocker metadata on the disk (but it does not encrypt the volume yet as encryption will finalize when a VM instance is provisioned with this disk). o Compute a cryptographic hash of the disk and create a Volume Signature Catalog (VSC) entry (which is stored in the disk’s metadata) signed with your certificate. This ensures the disk’s integrity can be verified; only disks matching this signed hash will be recognized as this template. Wait for the wizard to finish (it may take some time to initialize BitLocker and sign the catalog, depending on disk size). Click Close when done. The VHDX is now a sealed template disk. It’s marked internally as a shielded template and cannot be used to boot a normal VM without going through the shielded provisioning process (attempting to boot it in an unshielded way will likely cause a blue screen). The disk’s OS volume is still largely unencrypted at rest (encryption will complete when a VM is created), but it’s protected by BitLocker keys that will be released only to an authorized host via HGS. Extract the VSC File (for Tenant Use): It’s recommended to extract the template’s Volume Signature Catalog to a separate file. This .vsc file contains the disk’s identity (hash, name, version) and the signing certificate info. Tenants will use it to authorize this template in their shielding data. Use PowerShell on the RSAT machine: Save-VolumeSignatureCatalog -TemplateDiskPath "C:\path\WS2022-ShieldedTemplate.vhdx" -VolumeSignatureCatalogPath "C:\path\WS2022-ShieldedTemplate.vsc" This saves the .vsc file separately. Share this .vsc with the VM owners (tenants) or have it available for the shielding data file creation in the next step. Alternatively to the wizard, you can use PowerShell: after installing RSAT, run Protect-TemplateDisk -Path <VHDX> -Certificate <Cert> -TemplateName "<Name>" -Version <X.Y.Z.W> to seal the disk in one step. The wizard and PowerShell achieve the same result. Step 4: Create the Shielding Data File (PDK) A shielding data file (with extension .pdk) contains the sensitive configuration and keys required to deploy a shielded VM from the template. This includes the local administrator password, domain join credentials, RDP certificate, and the list of guardians (trust authorities) and template disk signatures the VM is allowed to use. For security, the shielding data is created by the tenant or VM owner on a secure machine outside the fabric, and is encrypted so that fabric admins cannot read the contents. Prerequisites for Shielding Data: Obtain the Volume Signature Catalog (.vsc) file for the template disk (from Step 3) to authorize that template. If the VM should use a trusted RDP certificate (to avoid man-in-the-middle when connecting via RDP), obtain a certificate (e.g. a wildcard certificate from the tenant’s CA) to include. This is optional; if the VM will join a domain and get a computer certificate or if you’re just testing, you may skip a custom RDP certificate. Prepare an unattend answer file or have the information needed to create one (admin password, timezone, product key, etc.). Use the PowerShell function New-ShieldingDataAnswerFile to generate a proper unattend XML for shielded VMs. The unattend will configure the VM’s OS on first boot (e.g. set the Administrator password, optionally join a domain, install roles, enable RDP, etc.). Ensure the unattend enables remote management (e.g. turn on RDP and firewall rules, or enable WinRM) because console access is not available for shielded VMs. Also, do not hardcode any per-VM values in the unattend that should differ for each instance; use placeholders or plan to supply those at deployment time. Creating the .PDK file: On a secure workstation (not on a guarded host) with RSAT Shielded VM Tools installed, launch the Shielding Data File Wizard (ShieldingDataFileWizard.exe). This tool will collect the needed info and produce an encrypted PDK file. Owner and Guardian Keys: First, set up the guardians. “Guardians” are certificates that represent who owns the VM and which fabrics (HGS instances) are authorized to run it. Typically: The Owner Guardian is a key pair that the tenant/VM owner possesses (the private key stays with the tenant). Create an Owner guardian (if not already) via the wizard’s Manage Local Guardians > Create option. This generates a key pair on your machine. Give it a name (e.g. “TenantOwner”). The Fabric Guardian(s) correspond to the HGS of the hosting fabric. Import the HGS guardian metadata file provided by the hoster (this is an XML with the HGS public key, exported via Export-HgsGuardian on the HGS server). In the wizard, use Manage Local Guardians > Import to add the hoster’s guardian(s) (for example, “Contoso HGS”). For production, you might import multiple datacenter guardians if the VM can run in multiple cloud regions, include each authorized fabric’s guardian. After adding, select all the guardian(s) that represent fabrics where this VM is allowed to run. Also select your Owner guardian (the wizard may list it separately). This establishes that the VM will be owned by your key and can only run on hosts approved by those fabric guardians. Template Disk (VSC) Authorization: The wizard will prompt to add Volume ID Qualifiers or trusted template disks. Click Add and import the .vsc file corresponding to the template disk prepared in Step 3. You can usually choose whether the shielding data trusts only that specific version of the template or future versions as well (Equal vs. GreaterOrEqual version matching). Select the appropriate option based on whether you want to allow updates to the template without regenerating the PDK. This step ensures the secrets in the PDK will only unlock when that specific signed template disk is used. Unattend and Certificates: Provide the answer file (Unattend.xml) for the VM’s specialization. If you created one with New-ShieldingDataAnswerFile, load it here. Otherwise, the wizard may have a simplified interface for common settings (depending on version, it may prompt for admin password, domain join info, etc.). Also, if using a custom RDP certificate, import it at this stage (so the VM will install that cert for remote desktop). Create the PDK: Specify an output file name for the shielding data (e.g., MyVMShieldingData.pdk) and finish the wizard. It will create the .pdk file, encrypting all the provided data. The Owner guardian’s private key is used to encrypt secrets, and the Fabric guardian’s public key ensures that HGS (holding the corresponding private key) is needed to unlock the file. The PDK is now ready to use for provisioning shielded VMs. (You can also create PDKs via PowerShell with New-ShieldingDataFile for automation.) Note the PDK is encrypted such that only the combination of the owner’s key and an authorized fabric’s HGS can decrypt it. Fabric admins cannot read sensitive contents of the PDK, and an unauthorized or untrusted host cannot launch a VM using it. Keep the PDK file safe, as it contains the keys that will configure your VM. Step 5: (Optional) Prepare a Shielding Helper VHDX In some scenarios, especially if you need to convert an existing VM into a shielded VM or if you are not using SCVMM for provisioning, a Shielding Helper disk is used. The Shielding Helper is a special VHDX containing a minimal OS that helps encrypt the template disk and inject the unattend inside a VM without exposing secrets to the host. SCVMM can automate this, but if you need to do it manually or for existing VMs, prepare the helper disk as follows: Create a Helper VM: On a Hyper-V host (not necessarily guarded), create a Gen 2 VM with a new blank VHDX (do not reuse the template disk to avoid duplicate disk IDs). Install a supported OS (Windows Server 2016 or higher, a Server Core installation is sufficient) on this VM. This VM will be temporary and its VHD will become the helper disk. Ensure you can log into it (set a password, etc.), then shut it down. Initialize the Helper Disk: On a Hyper-V host with RSAT Shielded VM Tools, run the PowerShell cmdlet: Initialize-VMShieldingHelperVHD -Path "C:\VMs\ShieldingHelper.vhdx" This command should point to the VHDX of the helper VM. This injects the necessary provisioning agent and settings into the VHDX to make it a shielding helper disk. The VHDX is modified in-place (consider making a backup beforehand). Do Not Boot the Helper VM Again: After initialization, do not start the helper VM from Step 1. The VHDX is now a specialized helper disk. You can discard the VM’s configuration. Only the VHDX file is needed going forward. Reuse for Conversions / Non-VMM Deployments: For manually shielding an existing VM, you would attach this helper VHDX to the VM and use PowerShell (e.g. ConvertTo-ShieldedVM or a script) to encrypt the VM’s OS disk using the helper. The helper boots in place of the VM’s OS, uses the PDK to apply BitLocker and the unattend to the OS disk, then shuts down. The VM is then switched to boot from its now-encrypted OS disk with a virtual TPM. (Note: Each initialized helper VHDX is typically one-time-use for a given VM; if you need to shield multiple VMs manually, create or copy a fresh helper disk for each to avoid BitLocker key reuse). Step 6: Prepare the Template Disk and PDK on the Host Copy the VHDX and PDK: Transfer the sealed template .vhdx and the .pdk file to the Hyper‑V host (or a cluster shared volume if the host is part of a Hyper‑V cluster). For example, place them in C:\ShieldedVM\templates\ on the host. This ensures the host can read the files during VM provisioning. Verify File Trust: (Optional) Double-check that the template disk’s signature is recognized by the tenant’s shielding data. The template’s .vsc file (volume signature catalog) should have been used when creating the PDK, so the PDK will “trust” that specific template hash. Also verify that the HGS guardian in the PDK matches your fabric’s HGS public key. These must align, or the VM provisioning will be rejected by HGS. Note: The PDK is encrypted and cannot be opened by the fabric admin as it’s designed so that only HGS (and the VM owner) can decrypt its contents. The host will use it as-is during provisioning. Make sure you do not modify or expose the PDK’s contents. PowerShell to finalize the shielded VM setup. Set up the key protector on the existing VM. For a clean process, you can use New-ShieldedVM on the guarded host: New-ShieldedVM -Name "Finance-App1" ` -TemplateDiskPath "C:\ShieldedVM\Templates\WS2025-ShieldedTemplate.vhdx" ` -ShieldingDataFilePath "C:\ShieldedVM\Templates\TenantShieldingData.pdk" -Wait This single command will create a new VM named “Finance-App1” using the specified template disk and shielding data file. It automatically configures the VM’s security settings: attaches a vTPM, injects the Key Protector (from the PDK) into the VM’s security settings, and attaches the shielding helper disk to boot and apply the unattend. The -Wait flag tells PowerShell to wait until provisioning is complete before returning. Note: Ensure the VM name is unique in your Hyper-V inventory. The New-ShieldedVM cmdlet requires the GuardedFabricTools module and will fail if the host isn’t a guarded host or if guardians are not properly configured. It uses the host’s configured HGS connection to request keys when provisioning. If your shielding data’s unattend file included placeholders for unique settings (for example, a static IP address, custom computer name, etc.), you can supply those values with the -SpecializationValues parameter on New-ShieldedVM. This takes a hashtable mapping the placeholder keys to actual values. For instance: $specVals = @{ "@ComputerName@" = "Finance-App1" "@IP4Addr-1@" = "10.0.0.50/24" "@Gateway-1@" = "10.0.0.1" } New-ShieldedVM -Name "Finance-App1" -TemplateDiskPath C:\ShieldedVM\Templates\WS2025-ShieldedTemplate.vhdx ` -ShieldingDataFilePath C:\ShieldedVM\Templates\TenantShieldingData.pdk -SpecializationValues $specVals -Wait This would replace placeholders like @ComputerName@ in the unattend with “Finance-App1”, etc. Use this only if the unattend (inside the PDK) was set up with such tokens. In many cases, the shielding data might already contain all required settings, so specialization values are optional. Step 7: Monitoring Provisioning and First Boot Once the shielded VM deployment is initiated (either by WAC or PowerShell), the provisioning process begins on the guarded host. This process is automatic and involves several stages behind the scenes: The host registers a new Key Protector for the VM (containing the VM’s BitLocker key, sealed to the VM’s virtual TPM and the fabric’s HGS). It then contacts the HGS. HGS verifies the host’s health (attestation) and, if the host is authorized and healthy, releases the key protector to the host. The VM is initially started using a temporary shielding helper OS (often a small utility VHD). This helper OS boots inside the new VM and uses the unattend file from the PDK to configure the main OS disk. It injects the administrator password, domain or network settings, enables RDP/WinRM, and then finalizes BitLocker encryption of the VM’s OS volume using the VM’s vTPM. This encryption locks the OS disk so it can only be decrypted by that VM’s vTPM (which in turn is only released by HGS to trusted hosts). When specialization is complete, the VM will shut down automatically. This shutdown is a signal that provisioning is finished. The helper disk is then automatically detached, and the VM is now fully shielded. As an administrator, you should monitor this process to know when the VM is ready: In Windows Admin Center’s VM list, you may see the VM’s state change (it might show as “Off” or “Stopped” after the provisioning shutdown). You may not get a detailed status in WAC during provisioning. Refresh the view to see if the VM has turned off after a few minutes. Using PowerShell, you can query the status: run Get-ShieldedVMProvisioningStatus -VMName <Name> on the guarded host to check progress. This cmdlet shows stages or any errors during provisioning. (If the provisioning fails, the cmdlet or Hyper-V event logs will show error details. Common causes include guardian mismatches or unattend errors.) Once the VM has shut down indicating success, you can proceed to start it normally. In WAC, select the VM and click Start (or use Start-VM -Name <Name> in PowerShell). The VM will boot its now-configured OS. On first boot, it will go through final OS specialization (the standard Sysprep specialize/pass completion). Step 8: Post-Deployment Access and Management Your new VM is now running as a shielded VM. Key points for management: Limited Host Access: Because it’s shielded, the Hyper-V host admin cannot view the VM’s console or use PowerShell Direct on this VM. In WAC (or Hyper-V Manager), if you try to connect to the VM’s console, it will be blocked (you might see a black screen or an error). This is expected as shielded VMs are isolated from host interference. All management must be done through the network. Accessing the VM: Use the credentials set in the unattend/PDK to log on to the VM via Remote Desktop (RDP) or another remote method (e.g. PowerShell Remoting). Ensure the VM is connected to a network and has an IP (via DHCP or the unattend’s settings). The unattend should have enabled RDP or WinRM as configured earlier. For example, if the PDK joined the VM to a domain, you can RDP with a domain account; if not, use the local Administrator and the password from the shielding data. Verify Shielded Status: In WAC’s inventory, the VM should show as a generation 2 VM with a TPM. You can confirm it’s shielded by checking VM’s Security settings (they will show that the VM is using a Key Protector and is shielded, often the UI will have those options greyed-out/enforced). You can also use PowerShell: Get-VMSecurity -VMName <Name>. It should show Shielded: True and list the Key Protector ID, etc. Routine Management: You can manage the VM (start/stop/reset) in WAC like any other VM. Backups, replication, etc., should be done with shielded VM-compatible methods (e.g. use Hyper-V checkpoints or backup APIs as the VM’s disks are encrypted but manageable through Hyper-V). Fabric admins cannot alter the VM’s settings that would compromise its security (for instance, you cannot remove the vTPM or turn off shielding without the VM owner’s consent). Further Reading: Install HGS in a new forest | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-install-hgs-default Guarded fabric and shielded VMs | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-and-shielded-vms-top-node Capture TPM-mode information required by HGS | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tpm-trusted-attestation-capturing-hardware Guarded host prerequisites | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-guarded-host-prerequisites Review HGS prerequisites | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-prepare-for-hgs Create a Windows shielded VM template disk | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-create-a-shielded-vm-template Shielded VMs for tenants - Creating shielding data to define a shielded VM | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-tenant-creates-shielding-data Shielded VMs - Preparing a VM Shielding Helper VHD | https://learn.microsoft.com/en-us/windows-server/security/guarded-fabric-shielded-vm/guarded-fabric-vm-shielding-helper-vhd
