01 / SYMPTOM

The existing image could no longer provide a reliable upgrade path

The Windows 11 image had stopped receiving Microsoft updates and remained on 22H2.

Attempts to create and publish a replacement image failed at different stages:

  • Some PVS targets stalled while setting the IP address on the boot NIC.
  • Some targets encountered a CVhdMp.sys blue-screen failure.
  • Some images completed the Windows boot but did not register correctly as VDAs.
  • Packaging-layer changes that appeared successful did not always remain stable after publication.

The failures were not limited to one component. The complete image path had to be reviewed, starting with the virtual machine template.

02 / TEMPLATE COMPATIBILITY

The template did not match the working environment

The template in the affected environment was compared with the template from a working environment.

The comparison identified differences in firmware, security configuration and virtual network hardware. The corrected template was standardised on:

  • UEFI firmware
  • Secure Boot
  • vTPM
  • VMXNET3 network adapter

The working template was copied and adapted rather than continuing to modify the older template.

The same template configuration was used for:

  • App Layering OS-layer packaging
  • Platform-layer packaging
  • Published PVS target devices

Using the same template maintained consistent firmware and virtual hardware across the complete build path. This avoided combining a UEFI-based OS layer with BIOS-based targets or introducing different NIC types between packaging and production.

03 / ELM AND OS-LAYER REBUILD

The App Layering environment was upgraded before rebuilding the image

The Enterprise Layer Manager was upgraded from:

25.7.0.1006

to:

26.3.0.1002

The OS-layer rebuild was then completed against the corrected UEFI, Secure Boot, vTPM and VMXNET3 template.

The main OS-layer steps were:

  1. Created a new OS-layer version using the corrected packaging template.
  2. Confirmed that the packaging VM used UEFI firmware and the expected virtual hardware.
  3. Updated Windows from the older 22H2 baseline.
  4. Installed the required Windows updates.
  5. Confirmed that the operating system had reached Windows 11 25H2.
  6. Checked Device Manager and the network configuration for stale or ghost network devices.
  7. Finalised the OS layer under ELM 26.3.

This produced a clean 25H2 OS-layer baseline before the Citrix components were added.

04 / PLATFORM-LAYER REBUILD

The platform layer was rebuilt instead of carrying forward the existing dependencies

The platform-layer maximum size was increased from 10 GB to 50 GB before the rebuild. The additional capacity was required for Windows servicing, Citrix components and temporary installation files during packaging.

A new platform-layer version was created against the rebuilt 25H2 OS layer.

The platform layer was rebuilt from the known-good Citrix CU5 baseline and then updated with:

  • Citrix VDA CU7
  • PVS Target Device 2203 LTSR CU7.1
  • VMXNET3 as the active network adapter
  • The required domain and controller configuration

During packaging, the virtual machine's domain trust was found to be broken. The secure channel was repaired with:

Test-ComputerSecureChannel -Repair -Credential (Get-Credential)

The command returned:

True

Domain login was tested again before the platform layer was finalised.

Remove stale network devices

The packaging VM contained stale network adapters from earlier template and layer versions.

Hidden network adapters were reviewed with:

Get-NetAdapter -IncludeHidden |
    Format-Table Name, InterfaceDescription, Status, MacAddress

The installed network devices were also checked with:

Get-PnpDevice -Class Net |
    Format-Table Status, FriendlyName, InstanceId -AutoSize

Stale E1000, Intel and old VMXNET3 devices were removed. Only the active VMXNET3 adapter required by the current template was retained.

The packaging VM was then restarted and checked again before the platform layer was finalised.

05 / PUBLISHING AND VALIDATION

Fresh targets were used to validate the rebuilt image

The corrected OS and platform layers were published as a new test image. Fresh PVS targets were created from the corrected target template rather than reusing machines built from the older template chain.

PVS and Windows startup

We confirmed that:

  1. The target obtained its network configuration.
  2. The PVS bootstrap located the correct vDisk.
  3. The target completed the PVS network boot.
  4. Windows 11 25H2 started without the earlier boot-NIC delay or CVhdMp.sys failure.

VDA registration

After Windows started, the Citrix VDA configuration was checked. The BrokerAgent service, controller configuration and VDA registration information were validated. The target subsequently registered with the Delivery Controllers.

User access

The following tests were then completed:

  1. Interactive domain login to the target.
  2. Published-resource launch through Citrix Workspace.
  3. Reboot and registration without manual intervention.
  4. Additional target creation from the same published image.

The rebuilt targets completed the PVS boot, started Windows and registered successfully.

06

LESSON

A Windows 11 layered-image upgrade depends on the compatibility of the complete build path. The hypervisor template, firmware mode, virtual hardware, ELM version, OS layer, platform layer, Citrix agents and PVS targets must be aligned.

In this case, rebuilding from a known-good template produced a stable 25H2 image. Continuing to modify the older image chain would have retained too many legacy dependencies and made each failure harder to isolate.