Jump to content
Welcome to our new Citrix community!
  • 0

Azure SSO problems (AzureAdPRT=NO) on AAD hybrid-joined PVS desktops

Jeremy Hanson


Hi all, we have been dogged by this problem for a few months now. Somewhere around 5%-10% of users will log into a PVS 1912Cu3 windows 10 desktop which has been AAD hybrid-joined, they will be able to use Office and Teams desktop apps, but they are lacking the Primary Refresh Token (azureADPRT= NO in dsregcmd /status). When they try and visit a site configured with Azure SSO they get the dreaded “you can’t get there from here” failure message for conditional access, because this PRT is missing. Logging out and picking up a new desktop sometimes fixes it but often it will take them several logoffs to fix.


We have a ticket open with Microsoft and we believe we are doing all the right things according to their documentation and have got some trusted third parties to validate our practices as well:


-We do a dsregcmd /LEAVE on the gold image before sealing it


-Desktops have the SYSTEM account configured with our proxy details and perform a dsregcmd /join on startup, which is apparently successful


-we have added a longer “settlementperiodbeforeuse” on the delivery groups in question to make sure everything has time to run/work


-We use FSlogix profile containers and exclude all of %localappdata%\Packages and %localappdata%\TokenBroker


-We delete the following reg entries at logoff to ensure they are not roamed in the user profile



HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin


-we use Zscaler “one click” configuration for Microsoft 365, but…


-Important URLs are explicitly added to our proxy bypass list anyway






-We have AAD Connect syncing the OUs with these machines


-We are federated with ADFS on-prem, we have never used device authentication in ADFS  so we see a few errors in the AAD event log about this but 90%+ of users are working so it seems like a red herring.


-We have tried tinkering with the timing of the dsregcmd /join and are confident all network connectivity is available by the time it runs.


Has anyone had any experience of getting this to work reliably?


All opinions welcome!!

Link to comment

1 answer to this question

Recommended Posts

  • 0

Update - found the solution, I am adding it here in case anyone else finds this.


We were triggering our own "dsregcmd /join" at startup, specifically using the "network available" trigger in Appsense, we have done this for a couple of years to make sure we are AAD hybrid joined and can use Microsoft 365 and conditional access.


There is also a Microsoft scheduled task "\Microsoft\Windows\Workplace Join\Automatic-Device-Join" which is meant to do this job. We found that in some cases this was running at the same time as our own dsregcmd /join, when they went through at the same time they were both recognised by AAD and some kind of duplicate IDs or thumbprints were registered in Azure for the desktop. This would break the process of the device authenticating and acquiring the Primary Refresh Token, and SSO would then fail.


We changed our own join step to call this scheduled task instead, and the internal task scheduler logic makes sure only one instance can run at once.

  • Like 1
Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Create New...