Chad Herman

What type of desktops are these, instant clones? Do you see anything in the Windows event logs (application or system) regarding anything related to this?

I ran into the exact same clock skew issue when integrating with ADFS; even though the UAGs, Horizon, ADFS are all synced with our NTP servers. I ended up changing the 'NotBeforeSkew' value to '1' on the relying party in ADFS and I never had the issue since.

Does anyone have experience with using this? https://docs.omnissa.com/bundle/UnifiedAccessGatewayDeployandConfigureV2312/page/Clientcustomexecutables.html I’m looking to use this feature with deploying the ControlUp Remote DX plugin but I’m running into issues. This works perfectly fine with Windows but I’m having issues attempting it on MacOS. I’ve worked with ControlUp and Omnissa support but both are pointing fingers at each other. The Mac Horizon client downloads the .pkg file successfully but it fails to proceed with the installation. I can see the following errors in the Horizon client logs. CdkPKG_DumpFile: Succeeded to expand pkg file '/Users/admin/Library/Application Support/VMware Horizon View Client/Code Cache/457dbbdf-4cc9-46ec-81ed-196113beb3ce/ControlUpRemoteDX-VMware.pkg'. Error is '(null)' CdkPKG_GetFileInfo: App bundle id is '(null)' version is '(null)', name is 'DISTRIBUTION_TITLE'. CdkPKG_GetFileInfo: Can't get product version or id or name. CdkInstall_GetInfoAsync_block_invoke: Failed to get PKG file '/Users/admin/Library/Application Support/VMware Horizon View Client/Code Cache/457dbbdf-4cc9-46ec-81ed-196113beb3ce/ControlUpRemoteDX-VMware.pkg' installation information. CdkInstallInfoCacheTask_SetInstallationFileInfo: assertion 'NULL != fileInfo->installedInfo.name' failed CdkInstallInfoCacheTask_UpdateInstalledInfo: assertion '!cdk_str_empty0(installationInfo->id)' failed Has anyone successfully deployed a .pkg to MacOS via this feature? If so, what are you deploying? Maybe I can compare a successful .pkg to the one that’s failing to help determine what’s missing.

PEMs always go in the following order. - intermediate 2 - intermediate 1 - root If you have just one intermediate, the root would be at the bottom and the intermediate at the top. You can also make a copy of your pem and rename it to adCA.cer and open it in Windows to validate the chain shows as expected.

I'm fairly certain I remember running into a similar issue in the past. IIRC, make sure your adCA.pem file contains the root and intermediates within it. I believe it needs to contain the full chain. In the meantime, you could disable certificate validation until you get it resolved so logins work again.