Tag: Provisioning Server 7 posts

Finding in the Wild | When Identical Machine SIDs Suddenly Become a Citrix Problem

For years, this was completely normal in Citrix environments: Create a golden image → use MCS or PVS to provision hundreds of VDAs → done. Machines from the same image may share the same local machine SID .

For years, this was completely normal in Citrix environments:
Create a golden image → use MCS or PVS to provision hundreds of VDAs → done.

Machines from the same image may share the same local machine SID.
Usually, that was not a major problem.

After all, each computer has its own Active Directory computer account with a unique domain SID.

With stricter Windows security hardening, however, this old architectural assumption becomes interesting.

What can happen?
When two cloned VDAs communicate, certain machine-to-machine connections may be blocked because their local identities are identical.

For example, this may affect:
❌ RDP between VDAs
❌ SMB / file sharing
❌ Printer sharing
❌ Certain NTLM/Kerberos scenarios

The Windows event log may show LsaSrv Event ID 6167.

And this is where it gets interesting:
The VDAs are correctly domain joined.
The AD computer accounts are unique.
DNS is correct.
Kerberos also initially looks fine.
Yet the connection is blocked.

Why?
Microsoft is increasingly tightening machine identity validation.
A design decision that was unproblematic for cloned Windows systems for years suddenly collides with more modern Windows security hardening.

This does not affect an obscure Citrix feature.

It affects one of the basic principles of:
MCS and PVS: creating many machines from a single golden image.

Citrix itself is now emphasizing the security of local persistent accounts in shared MCS/PVS images and explicitly recommends not creating such accounts in the master image.

What does this mean in practice?
If communication suddenly fails after Windows security updates between two VDAs in the same catalog:
Do not immediately dismantle firewalls, DNS or Citrix policies. 😉

Also check:
System event log → LsaSrv
and particularly Event ID 6167.

For me, this is a good example of why golden-image architectures now need testing against more than just new Citrix versions.

Finding in the Wild | PVS 2507 – When the Device License Suddenly Disappears

At a customer, I recently encountered an old acquaintance: “No device license is currently available for this computer. A system shutdown will be initiated in 720 hours. ” A classic PVS error message. With PVS 2507 + LAS

At a customer, I recently encountered an old acquaintance:
“No device license is currently available for this computer. A system shutdown will be initiated in 720 hours.”

A classic PVS error message.
With PVS 2507 + LAS, however, it is worth taking a closer look.

For example, the community has an interesting report involving PVS 2507 on Windows Server 2025:

Licensing initially works, but after approximately 23 hours PVS loses its licensing. Running the PVS Configuration Wizard again restores it. Until the following day.

A community finding? Yes.

But Citrix has now also officially fixed several interesting PVS licensing issues in 2507.1 CU2:
🔴 CVADHELP-31063
After migration to Citrix License Activation Service (LAS), PVS could incorrectly report Not entitled. Processing of expiration dates and time zones was among the factors involved.
🔴 CVADHELP-31165
Even time differences between PVS servers could cause device licensing issues. With CU2, PVS now tolerates up to 15 minutes of clock difference.

Another familiar issue after a LAS migration is :
Cloud vs. on-premises licensing.

For CVAD on-premises + PVS + UHMC/Platform licensing, check that PVS is actually configured for on-premises use and that the corresponding PVS_CCS / PVSD_CCS entitlements exist.

My current PVS 2507 licensing checks therefore look like this:
✅ Check the exact PVS build
✅ Account for 2507.1 CU2 / known fixes
✅ Check LAS status and entitlements
✅ Check cloud vs. on-premises
✅ Check PVS_CCS / PVSD_CCS
✅ Compare NTP/clock settings across all PVS servers
✅ Consider the Stream Service after licensing changes

Only then would I start investigating the conventional route through ports, firewalls and the license server.

The interesting part:
The error message is old.
Its possible causes are not.

Anyone simply following the old CTX132198 checklist for PVS 2507 may easily overlook the newer LAS/2507-specific causes.

Finding in the Wild | PVS + Secure Boot – A Small CU2 Feature That Could Become Important in 2026

Citrix Provisioning 2507.1 LTSR CU2 is here. Among the usual fixes is a change that I find much more interesting for PVS environments than the version number suggests: 👉 Support for Microsoft Windows UEFI CA 2023 Why is

Citrix Provisioning 2507.1 LTSR CU2 is here.

Among the usual fixes is a change that I find much more interesting for PVS environments than the version number suggests:

👉 Support for Microsoft Windows UEFI CA 2023

Why is this important?

Microsoft is currently renewing the certificate chain behind UEFI Secure Boot. Some existing Secure Boot certificates date back to 2011, and Microsoft is gradually migrating Windows to the new 2023 certificates.

This is exactly where it becomes interesting for Citrix PVS.

PVS must understand the new Secure Boot world

With PVS 2507.1 LTSR CU2, Citrix now supports Secure Boot with images signed using the new Windows UEFI CA 2023 certificate.

Initially, this sounds like a small compatibility fix.

But it is not necessarily.

Anyone familiar with PVS knows:

💥 If the boot chain is wrong, there is no Citrix session.

We are no longer discussing logon duration, profiles or HDX performance.

The target simply does not boot.

Another interesting change

When a target device starts, PVS now automatically detects whether the system booted using:

BIOS or UEFI

.

This information is saved in the device record and is also available through farm telemetry.

I find this particularly useful in larger or long-established PVS farms.

Different firmware and boot configurations are surprisingly common there.

What would I check now?

Anyone using PVS + Windows 11 or Windows Server 2025 + Secure Boot should definitely keep CU2 on their radar.

Before a rollout, I would test in particular:

👉 Secure Boot + Windows UEFI CA 2023
👉 Target device boot
👉 PXE / BDM
👉 Existing vDisks
👉 Hypervisor firmware / UEFI configuration
👉 Boot after promoting a vDisk version
👉 Failover to a second PVS server

With changes like these:

The vDisk has worked for years is no guarantee that the future Secure Boot chain will also work.

My takeaway

For me, PVS 2507.1 CU2 is therefore more than just:

Another cumulative update with a few bug fixes.

Support for Windows UEFI CA 2023 is a classic future-readiness topic.

Microsoft is changing the Secure Boot trust chain.

Citrix is following suit with PVS.

And once a target fails to start after a Windows/Secure Boot update, an inconspicuous release-note entry suddenly becomes an important feature. 😎

Finding in the Wild | PVS + XenServer – Cores per Socket

A small detail that can lead to extended troubleshooting with Citrix PVS on XenServer. When provisioning VMs through the CVAD Setup Wizard, the number of vCPUs must match the CPU topology of the XenServer template. The vCPU count

A small detail that can lead to extended troubleshooting with Citrix PVS on XenServer.

When provisioning VMs through the CVAD Setup Wizard, the number of vCPUs must match the CPU topology of the XenServer template.

The vCPU count must be a multiple of Cores per Socket.

Example:

Cores per Socket: 4
PVS Wizard: 6 vCPUs ❌
PVS Wizard: 8 vCPUs ✅

With an invalid combination, the VM is provisioned but cannot subsequently boot.

XenServer may report:

VCPU_max must be a multiple of platforms:cores-per-socket

The tricky part:

The VM exists.
The PVS target exists.
The vDisk assignment looks correct.

Troubleshooting can quickly focus on PXE, BDM, streaming or the vDisk, although the actual issue is the VM’s CPU topology.

Citrix continues to track this as PVS-1126.

👉 So, for PVS targets that do not boot on XenServer, always check:

vCPU ↔ Cores per Socket.

A small setting with a big impact. 😉

Finding in the Wild | Citrix PVS – A VMware Tools Update Disables the Master Image

An apparently straightforward VMware Tools update on a Citrix PVS master image, and suddenly the network connection is gone. The problem: the virtual machine uses a VMXNET3 network adapter that also carries the PVS streaming traffic. ❌ The

An apparently straightforward VMware Tools update on a Citrix PVS master image, and suddenly the network connection is gone.

The problem: the virtual machine uses a VMXNET3 network adapter that also carries the PVS streaming traffic.

❌ The symptoms

– The VMware Tools update starts normally.
– During installation, the VMXNET3 driver is updated.
– The network connection is interrupted.
– The PVS target loses access to its streamed vDisk.
– The update fails or the system becomes unresponsive.

🔍 Root cause

Citrix PVS depends on a continuous network connection to the vDisk.

VMware Tools updates the VMXNET3 network driver, among other components. If that driver is reinitialized during active PVS streaming, the target may lose its connection to the Provisioning Server.

The result: a driver update interrupts the very connection through which the operating system receives its data.

🛠️ My solution: a temporary second network adapter

Instead of performing the update over the active VMXNET3 adapter, I use an additional E1000E adapter.

1. Create a new PVS maintenance version.
2. Add an E1000E network adapter in VMware.
3. Register the E1000E adapter’s MAC address in the PVS console.
4. Boot the master image through the E1000E adapter.
5. Update VMware Tools, including the VMXNET3 driver.
6. Shut down the system and restore the original VMXNET3 configuration.
7. Change the MAC address back in PVS and remove the E1000E adapter.
8. Start the master image again and validate streaming.

✅ The result

During the update, PVS streaming runs through the temporary E1000E adapter.

The VMXNET3 driver can be updated without reinitializing the streaming adapter currently in use.

After the update, the system runs through VMXNET3 again.

💡 My takeaway

In a conventional VM, updating a network driver is usually routine.

With Citrix PVS, the same operation can effectively disconnect the running operating system from its own disk.

Sometimes a second network adapter is the decisive difference between a failed update and successful maintenance.