Has anyone managed to get Azure Hybrid PVS Catalog...
# citrix-provisioning
r
Has anyone managed to get Azure Hybrid PVS Catalogs working in VMware, following the steps in the Citrix docs but running into some issues. doc: https://docs.citrix.com/en-us/provisioning/2402-ltsr/configure/create-hybrid-joined-catalogs I have managed to create the catalog although the type in Studio is set as MCS (as per the docs), however what this does is when creating a device is give it an identity disk, so instead of having the single write cache disk and streaming the vdisk it now has 3 disks (20mb disk, 16mb identity disk and 20GB write cache disk). I have also noticed it keeps falling back to write cache on server, not cache in memory. I am not sure if I have set it up incorrectly or if this is the expected behaviour?
j
Hi Ray, if you are following steps in the doc , PVS will be using MCS API to create the PVS catalog , that is why you can see the identify disk. The advantage of that is all VMs will be achieving HAAD immediately, rather than waiting for up to 90 minutes
For caching back on server, looks like it is because the SAN policy is net set properly. Please refer to https://docs.citrix.com/en-us/provisioning/7-15/install/about-san-policies.html, to ensure the cache disk will be brought online when VM boots up .
r
Thank you Jitao, I will give this a try today. I was also wondering about the section on "New-AcctADAccount" and "Set-AcctAdAccountUserCert", should this be a service account that is used?
j
I have an easier process for the hybrid join. 1. Define the Tenant ID in GPO. 2. Modify the scheduled task \Microsoft\Windows\Workplace Join\Automatic-Device-Join to run at startup and at login. This will generate the Azure PRT. 3. When sealing the image to deliver to non-persistent do a dsregcmd /leave before the shutdown. Also if you are using Entra ID SAML on your netscaler I have an article on using that with FAS for the Azure PRT. https://www.jeffriechers.com/wiki/azuread-prt-with-fas-certificates/
r
Thanks @Jeff Riechers! We have been trying that approach but finding that the non-persistent machines do not re-join correctly all the time, some can take up to 90 mins to Hybrid join again after being rebooted. Thats what lead me down this path of the PVS hybrid catalog
j
With the dsregcmd running at startup it should auto register. What errors were you getting in Azure AD, or the event log when it wouldn't register?
r
This is the error we see after initial boot. Eventually it will join but varies between 30-90mins.
j
I usually would get that happening if the dsregcmd /leave wasn't run on the image before deploying. Even if the maintenance machine is booted and then shutdown it always needs to have dsregcmd /leave in the shutdown process. You may even want to add that as a scheduled task on shutdown of the machine. Then the provisioned machines leave and then join on shutdown and restarts.
r
okay interesting because our maintenance image is not actually hybrid joined at the moment, its only the non-persistent VDA's that are synced with AD Connect for hybrid join. Maybe I can try join the maint image and try again.
j
If you have the Workplace Join scheduled task it is going to join the maintenance machine, that leave is the important part otherwise you can have all your machines trying to register with the same device ID, and can cause this lag as it moves it around different machines.
r
I have looked and cannot see our maintenance machine in Entra at all but will try run it anyway, another interesting point is if I remove the persistent objects out of Entra and reboot them the join works fine. On the second reboot then we get the error again.
j
On non-persistent they re-generate a new device id, so it also could be that entra is preventing adding another device id to the existing machine name. So adding a scheduled task on shutdown to execute "dsregcmd /leave", from entra will help in the long term as well.
r
ahh okay cool thank you, will give it a try 🙂
b
@Ryan Swanepoel just look for the device ID. Also worth to mention is that you need connectivity without any SSL Interception to device.login.microsoftonline.com. I guess the startup task runs in the SYSTEM context?
r
ooo the SSL interception is a good route to look at! We do have that in place. Yes the task does run at startup
b
Internet connectivity is allowed for the computer account? Check if the specific useraccount for the task has internet access to the following sites:
<http://login.microsoftonline.com|login.microsoftonline.com>
<http://aadg.windows.net.nsatc.net|aadg.windows.net.nsatc.net>
<http://autologon.microsoftazuread-sso.com|autologon.microsoftazuread-sso.com>
<http://secure.aadcdn.microsoftonline-p.com|secure.aadcdn.microsoftonline-p.com>
<http://device.login.microsoftonline.com|device.login.microsoftonline.com>
👍 1