Last updated:
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.
