Announcing Trusted Launch for Virtual Machines for Windows Server Insiders
Trusted Launch for virtual machines We are excited to announce Trusted Launch for virtual machines (TVMs) in Windows Server Insider Preview. Trusted Launch is a security feature you can enable when creating Hyper-V Generation 2 VMs. It enables Secure Boot, installs a virtual Trusted Platform Module (vTPM), protects vTPM state at rest, and supports boot integrity verification (ability to verify if the VM started in a well-known good state). Further, when the VM runs in a Failover Cluster, the vTPM state is automatically made available when the VM live migrates or fails over to other nodes in the cluster – this ensures the VM remains available after migration or failover. This is unlike a Generation 2 VM with a vTPM, which will not start after migration or failover to another node in the cluster – the TPM state protection key needs to be moved to the destination node manually so the VM can start. With boot integrity verification, the entire boot path is measured and boot integrity is verified by Microsoft Azure Attestation service. This helps detect any alterations to the boot path or boot components. Such alterations, e.g. implanting malware in the boot path, can be detected by boot integrity verification. Increasingly attackers prefer implanting malware in the boot path for a variety of reasons: the OS layer is usually well protected, while firmware – as highly privileged code – can be used to alter what gets loaded (boot loader and drivers). Such alterations are not easily detectable by anti-virus software running at the OS layer. Boot integrity verification helps detect such alterations so a relying party (such as an app or service) can take suitable remediation actions, e.g. shutting down the VM. Boot integrity verification is an important part of establishing trust by verifying that the virtual machine started in a well-known good state. Insider preview TVMs are available for preview starting with Windows Server Insider preview build 29621. This initial preview only supports some of the Trusted Launch capabilities: Secure boot, vTPM, and vTPM state protection (at rest). You can create and manage TVMs using PowerShell. Guest state protection: The guest state (including the vTPM state) for each TVM is protected using a unique key that is stored in a KSP (Key Storage Provider) local to the server. Without this key, the VM will not start. Moving the VM to another server is not supported in this release. Not supported in this release: Moving TVMs to another server. TVMs in Failover Clusters or Hyper-V Replica. Boot integrity verification. Support for TVMs in Windows Admin Center (WAC). Instructions At a high-level, the steps involve: Install Windows Server Insider preview build on your server Enable Hyper-V Enable Trusted Launch feature Verify guest state protection 1. Install Windows Server Insider preview build Trusted Launch for virtual machines is available starting with the Windows Insider preview build number 29621. Install this build or a later build on your server. (Join Windows Server Insiders if you haven’t already!) 2. Enable Hyper-V (if it is not already enabled) Install-WindowsFeature -Name Hyper-V -IncludeManagementTools -Restart After enabling Hyper-V, the server needs to be restarted. 3. Set registry key property value (required to enable the Trusted Launch feature) New-Item -Path "HKLM:\SOFTWARE\Microsoft\AszIgvmAgent" -Force New-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\AszIgvmAgent" -Name "TvmWinServer" -Value 1 -PropertyType DWord -Force Setting the above regkey informs relevant system components that the Trusted Launch feature is being used in a Windows Server environment. 4. Enable Trusted Launch feature Enable-WindowsOptionalFeature -Online -FeatureName "IsolatedGuestVm" -NoRestart 5. Verify if IgvmAgent is running IgvmAgent (Isolated Guest Virtual Machine agent) is a system-level service that helps support Trusted Launch capabilities. Get-Service -Name "IGVmAgent" The output should show Status as Running. If the Status is Running, you can skip to next step. If the Status is not Running, please report the issue. Add the following event logs to the report: Event Viewer: Applications and Services Logs => Microsoft => Windows => IGVmAgent => Operational Event Viewer: Applications and Services Logs => Microsoft => Windows => IGVmSystem => Operational You can open Event Viewer via the Run dialog: Press Win + R → type "eventvwr.msc" → press Enter 6. Create an external virtual switch (if you don't already have one you can use) Create and configure a virtual switch with Hyper-V | Microsoft Learn To see available external virtual switches: (Get-VMSwitch | Where-Object { $_.SwitchType -eq "External" }).Name 7. Create TVM If you already have a virtual hard disk (VHD or VHDX) for a Gen 2 VM with an installed guest OS, run: New-VM -Name <VMName> -Generation 2 -GuestStateIsolationType TrustedLaunch -SwitchName <virtual switch name> -VHDPath <path to vhdx> -Path <path to where VM config files will be stored> Else, run: New-VM -Name <VMName> -SwitchName <virtual switch name> -NewVHDPath <path to where new VHD will be stored> -NewVHDSizeBytes 40GB -Generation 2 -GuestStateIsolationType TrustedLaunch -Path <path to where VM config files will be stored> Then, add to the VM a virtual DVD drive containing an ISO image for the guest OS (Windows or Linux OS-compatible with Hyper-V Gen 2 virtual machine). Add-VMDvdDrive -VMName <VMName> -Path <Guest OS ISO image path> Note: The guest OS will be installed when the VM starts up. When connecting to the VM you will be prompted to install the guest OS from the DVD drive. Make sure that the DVD drive is at the top of the boot order specified in the firmware so the VM will boot from the DVD drive. For more information, see New-VM. 8. Verify VM guest state isolation type (Get-VM -name <VMName>).GuestStateIsolationType should return "TrustedLaunch". 9. Verify guest state protection To verify guest state protection, stop IGVmAgent service and restart the VM. Without IGVmAgent in Running state, a TVM with guest state protection will not start. Call to action Trusted Launch brings foundational VM security — Secure Boot, a vTPM, and protected guest state — to Windows Server, helping safeguard your VMs against boot-level and firmware threats. Please try out TVMs and provide your feedback via the Windows Server Insiders Forum. — Christina Curlette and Ram Jeyaraman (and the Windows Server team)
Issue with winlogon on Remote Desktop Services:
We are investigating intermittent session establishment failures on Windows Server 2019 servers used as CyberArk PSM / RDS hosts. At unspecified intervals, new privileged sessions fail to establish or are disconnected during the initial session/logon phase. The issue is intermittent and affects new sessions. Existing sessions may continue to work. The strongest and most consistent correlation identified so far is: Microsoft-Windows-TerminalServices-LocalSessionManager/Operational – Event ID 36 Application / Microsoft-Windows-Winlogon – Event ID 4005 We observed that TerminalServices-LocalSessionManager Event ID 36 can occur without a subsequent Winlogon Event ID 4005. However, every observed Winlogon Event ID 4005 is correlated with TerminalServices-LocalSessionManager Event ID 36 in the same incident window. This suggests that Event ID 36 is a consistent precursor or required condition for the Winlogon 4005 cases. Environment Operating system: Windows Server 2019 Role: CyberArk PSM / RDS session host Issue type: intermittent failure during new RDP/PSM session initialization Impact: affected users cannot establish privileged sessions or are disconnected during session startup Similar issue exists on previous windows server 2012 R2 and was fixed : August 16, 2016 – KB3179574 (During virtual channel management, a deadlock condition occurs that prevents the RDS service from accepting new connections.) https://support.microsoft.com/en-us/topic/august-2016-update-rollup-for-windows-8-1-and-windows-server-2012-r2-d472b5d5-4b3a-8e6e-c22a-f62fed604caf I'm looking forward for any ideas how to resolve this issue. Many thanks!!PowerShell DSC Pullserver stops working with SQL database
After updating Windows Server 2025, our DSC Pull Server stopped communicating with its SQL backend database. The issue was not present before the update, and reverting to the previous version of Microsoft.PowerShell.DesiredStateConfiguration.Service.dll immediately restored normal functionality. With the newer DLL version, the service starts successfully and the endpoint remains available, but no connection is established to the SQL Server database. As a result, database initialization does not occur, required tables are not created or updated, and node registration fails. No database sessions are observed on the SQL Server during registration attempts, indicating that the service does not reach the SQL connection phase. We compared the previous working DLL version with the updated version and confirmed that the regression is introduced by the newer DLL. Replacing the updated DLL with the earlier version consistently restores SQL database connectivity and normal Pull Server Operation.How to check RDP access to the server
Hello, I have a virtual machine running Windows Server 2019 Datacenter with Active Directory, and all users access it via RDP. No specific access configurations have been set up; I wanted to know if it is possible to check how many times a specific user has connected and from which IP address—is that possible? Also, I wanted to ask if it is possible to determine whether a specific user copied files to their local PC using copy/paste during a session. Thank you
Server 2016 Windows Update disabled?
I have Windows 2016 and 2019 Servers. All in in the same OU and getting the same Group Policy. This is confirmed via gpresult. I am using GP to disable Automatic Updates. This looks to be working in 2019: But with Server 2016, it says this: Should I expect these servers to update?PS script for moving clustered VMs to another node
Windows Server 2022, Hyper-V, Failover cluster We have a Hyper-V cluster where the hosts reboot once a month. If the host being rebooted has any number of VMs running on it the reboot can take hours. I've proven this by manually moving VM roles off of the host prior to reboot and the host reboots in less than an hour, usually around 15 minutes. Does anyone know of a powershell script that will detect clustered VMs running on the host and move them to another host within the cluster? I'd rather not reinvent this if someone's already done it.
Did Microsoft make a mistake? WinServer 2022 Standard and up.
Microsoft removed functionality of Windows Deployment Service. I know their are ways to to get around this but they either are hackjobs or deploying your own windows with PE. as far as i know of writing this. I know I could go linux. they have a simple cd to follow. Or Mac has their own version for macs. but not microsoft. They THREW it away for some stupid reason. Do I really have to do a VM or worse ditch DNS & DHCP?Hyper-V Virtual TPMs, Certificates, VM Export and Migration
Virtual Trusted Platform Modules (vTPM) in Hyper-V allow you to run guest operating systems, such as Windows 11 or Windows Server 2025 with security features enabled. One of the challenges of vTPMs is that they rely on certificates on the local Hyper-V server. Great if you’re only running the VM with the vTPM on that server, but a possible cause of issues if you want to move that VM to another server. In this article I’ll show you how to manage the certificates that are associated with vTPMs so that you’ll be able to export or move VMs that use them, such as Windows 11 VMs, to any prepared Hyper-V host you manage. When a vTPM is enabled on a Generation 2 virtual machine, Hyper-V automatically generates a pair of self-signed certificates on the host where the VM resides. These certificates are specifically named: "Shielded VM Encryption Certificate (UntrustedGuardian)(ComputerName)" "Shielded VM Signing Certificate (UntrustedGuardian)(ComputerName)". These certificates are stored in a unique local certificate store on the Hyper-V host named "Shielded VM Local Certificates". By default, these certificates are provisioned with a validity period of 10 years. For a vTPM-enabled virtual machine to successfully live migrate and subsequently start on a new Hyper-V host, the "Shielded VM Local Certificates" (both the Encryption and Signing certificates) from the source host must be present and trusted on all potential destination Hyper-V hosts. Exporting vTPM related certificates. You can transfer certificates from one Hyper-V host to another using the following procedure: On the source Hyper-V host, open mmc.exe. From the "File" menu, select "Add/Remove Snap-in..." In the "Add or Remove Snap-ins" window, select "Certificates" and click "Add." Choose "Computer account" and then "Local Computer". Navigate through the console tree to "Certificates (Local Computer) > Personal > Shielded VM Local Certificates". Select both the "Shielded VM Encryption Certificate" and the "Shielded VM Signing Certificate." Right-click the selected certificates, choose "All Tasks," and then click "Export". In the Certificate Export Wizard, on the "Export Private Key" page, select "Yes, export the private key". The certificates are unusable for their intended purpose without their associated private keys. Select "Personal Information Exchange - PKCS #12 (.PFX)" as the export file format. Select "Include all certificates in the certification path if possible". Provide a strong password to protect the PFX file. This password will be required during the import process. To perform this process using the command line, display details of the certificates in the "Shielded VM Local Certificates" store, including their serial numbers. certutil -store "Shielded VM Local Certificates" Use the serial numbers to export each certificate, ensuring the private key is included. Replace <Serial_Number_Encryption_Cert> and <Serial_Number_Signing_Cert> with the actual serial numbers, and "YourSecurePassword" with a strong password: certutil -exportPFX -p "YourSecurePassword" "Shielded VM Local Certificates" <Serial_Number_Encryption_Cert> C:\Temp\VMEncryption.pfx certutil -exportPFX -p "YourSecurePassword" "Shielded VM Local Certificates" <Serial_Number_Signing_Cert> C:\Temp\VMSigning.pfx Importing vTPM related certificates To import these certificates on a Hyper-V host that you want to migrate a vTPM enabled VM to, perform the following steps: Transfer the exported PFX files to all Hyper-V hosts that will serve as potential live migration targets. On each target host, open mmc.exe and add the "Certificates" snap-in for the "Computer account" (Local Computer). Navigate to "Certificates (Local Computer) > Personal." Right-click the "Personal" folder, choose "All Tasks," and then click "Import". Proceed through the Certificate Import Wizard. Ensure the certificates are placed in the "Shielded VM Local Certificates" store. After completing the wizard, verify that both the Encryption and Signing certificates now appear in the "Shielded VM Local Certificates" store on the new host. You can accomplish the same thing using PowerShell with the following command: Import-PfxCertificate -FilePath "C:\Backup\CertificateName.pfx" -CertStoreLocation "Cert:\LocalMachine\Shielded VM Local Certificates" -Password (ConvertTo-SecureString -String "YourPassword" -Force -AsPlainText) Updating vTPM related certificates. Self signed vTPM certificates automatically expire after 10 years. Resetting the key protector for a vTPM-enabled VM in Hyper-V allows you change or renew the underlying certificates (especially if the private key changes). Here are the requirements and considerations around this process: The VM must be in an off state to change security settings or reset the key protector The host must have the appropriate certificates (including private keys) in the "Shielded VM Local Certificates" store. If the private key is missing, the key protector cannot be set or validated. Always back up the VM and existing certificates before resetting the key protector, as this process can make previously encrypted data inaccessible if not performed correctly. The VM must be at a supported configuration version (typically version 7.0 or higher) to support vTPM and key protector features. To save the Current Key Protector: On the source Hyper-V host, retrieve the current Key Protector for the VM and save it to a file. Get-VMKeyProtector -VMName 'VM001' | Out-File '.\VM001.kp' To reset the key protector with a new local key protector: Set-VMKeyProtector -VMName "<VMNAME>" -NewLocalKeyProtector This command instructs Hyper-V to generate a new key protector using the current local certificates. After resetting, enable vTPM if needed: Enable-VMTPM -VMName "<VMNAME>" It is important to note that if an incorrect Key Protector is applied to the VM, it may fail to start. In such cases, the Set-VMKeyProtector -RestoreLastKnownGoodKeyProtector cmdlet can be used to revert to the last known working Key Protector. More information: Set-VMKeyProtector: https://learn.microsoft.com/en-us/powershell/module/hyper-v/set-vmkeyprotector
ntoskrnl.exe and build version not getting updated after applying KB5078740 on server 2025
I have installed the latest March patch kb5078740 on server 2025 which was upgraded from server 2022. the patch is showing installed but the ntoskrnl.exe and build version is still showing 10.0.26100.4652. Qualys is detecting it as patch not installed based on file version which should be 10.0.21600.32522. Please let me know how to fix this issue.
Virtual printer in windows server 2019 standard is not shown after configuration
Hello, I am, trying to configure a virtual printer in a Windows server 2019 standard edition that is deployed in OCI cloud. This instance has windows server license included in the pricing. The problem comes when after ending the process of configuration this virtual printer is not displayed in "Devices and printers" any idea why is this happening? Regards, Ana
