The Hybrid Join Cascade: When the PRT Challenge Still Isn’t Done
- Edwin de Bruin
- 6 minuten geleden
- 3 minuten om te lezen
Over the past few months, I’ve been looking into some of the trickier issues in environments that combine Omnissa Horizon Instant Clones, Hybrid Azure AD Join, App Volumes and even TrueSSO.
A true resonance cascade

For issues with PRT when federated EntraID to Omnissa Access and when using TrueSSO read my previous post: The Hybrid Join Incident: Recovering the Lost PRT
1. PRT unpredictability and the “Wait for Hybrid Join” setting
One of the biggest headaches in Instant Clone environments is that the Primary Refresh Token (PRT) isn’t always available when users log in
.
The root cause is simple: the Instant Clone often hasn’t finished Hybrid Join yet. If the machine isn’t fully registered, the PRT might not get issued.
The fix is the “Wait for Hybrid Join” setting in the Horizon Agent. When it’s enabled, the agent makes sure the VM completes Hybrid Join before the user logs in. With that in place, PRT issuance becomes predictable and reliable.
Important note: enabling Wait for Hybrid Join can impact pool availability. If there are issues with Hybrid Join (for example, network or Entra sync problems), the pool might dry up, because VMs won’t be marked ready until the join completes. Make sure to monitor the pool when enabling this setting, especially in large environments.
LoginVSI test results
We tested this using LoginVSI, and the difference is huge:
Setting | Successful PRTs | Failed PRTs |
Wait for Hybrid Join ON | 400 / 400 | 0 |
Wait for Hybrid Join OFF | 130 / 400 | 270 failures |
Enabling this setting basically removes all randomness in PRT issuance. This setting is available in Horizon 2406+ agent, and for ESB customers, Horizon 2503 is the first ESB release that includes this option.
2. App Volumes packaging: Hybrid Join and package pollution
Another issue comes up with App Volumes packaging machines. During packaging, the VM sometimes tries to do a Hybrid Join because of the SCP record in Active Directory. This SCP is created when you configure Hybrid Azure AD Join via Microsoft Entra ID Connect, and basically every Windows 10, Windows 11, and Windows Server 2016+ machine resolves this record and will attempt to register itself in Entra ID.
If the machine isn’t synced to Entra, this join will fail. Normally, that failure isn’t a problem.
The real issue is when that failed join attempt gets captured in the packaging process.
Later, when that AppStack is deployed to users, it can cause unpredictable behavior. We even witnessed "dsregcmd /leave" beeing executed, resulting in the the device beeing removed from EntraID and we needed to wait for a resync of the object before the join would succeed again.
Mitigation
The main way to prevent this is to stop packaging machines from performing Hybrid Join. You can do this in two ways:
set the following GPO to disabled
Computer Configuration > Administrative Templates > Windows Components > Device Registration > Register domain-joined computers as devices
or by using registry:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin
"AutoWorkplaceJoin"=dword:00000000
Alternative: don’t domain join the packaging VM at all. If it’s not domain joined, it can’t see the SCP and won’t try to Hybrid Join.
Either way, the goal is the same: keep the packaging VMs from attempting Hybrid Join
Conclusion
Hybrid Join is the way forward to get for example Teams v2 SSO but keep the following in mind:
PRT instability happens when Instant Clones log in before Hybrid Join completes. Enabling “Wait for Hybrid Join” fixes this. important Note Monitor the pool, because if there are Hybrid Join issues, VMs may not become ready, and the pool could dry up.
App Volumes packaging might cause issues when packaging VMs attempt Hybrid Join. Failed joins can get captured in the AppStack and cause unpredictable behavior. At the moment if the packages are polluted repackaging seems to be the only solution. We continue the search for an alternate solution cause depending on the number of Appvolume packages this might be a lot of work.
Special thanks
I did not battle this alone, so special thanks go out to Jeroen Oud battling the Appvolumes issue and Sanjay Soebedar together with Mario Braakman for their endless testing.
So, thanks guys and to quote Barney Calhoun: “About that beer I owed ya…”