Chad Herman

How are you deploying it? I believe I had to deploy it before Explorer started for it to take affect. Also, I just realized I haven't tested that key on 24H2 yet, only 23H2.

Try setting the following registry key. [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\QuietHours\PostOOBETimer] "FirstRunTime"=hex:00,00,00,00,00,00,00,00

Try setting the following registry key. [HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Notifications\QuietHours\PostOOBETimer] "FirstRunTime"=hex:00,00,00,00,00,00,00,00

That worked! Thank you so much!

Has anyone used the option webviewMode when creating custom URIs for the HTML Access? Per the docs, the following should work but the sidebar is still available. https://horizon.mycompany.com/?applicationId=myApp&action=start-session&webviewMode=true https://docs.omnissa.com/bundle/HorizonHTMLAccessGuideV2406/page/ConfiguringHTMLAccessforEndUsers.html#using_uris_to_configure_html_access_web_clients

I ran into a similar situation when we first deployed instant clones. I was having issues where the computer object was created on one domain controller in a site but the provisioned desktop contacted a different DC in the same site. Since it all happens so fast the DCs in the same site didn’t replicate the computer object fast enough and GPOs were failing. To get around this I had to weaken the UNC hardened paths on the golden image and then I would reconfigure it on the provisioned desktop after the user logged in. So for example, on the golden image: Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" -Name "\\*\SYSVOL" -Value "RequireMutualAuthentication=0, RequireIntegrity=0" -Force Then on the provisioned desktop after the user logged in: Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths" -Name "\\*\SYSVOL" -Value "RequireMutualAuthentication=1, RequireIntegrity=1" -Force Before I shutdown and snapshot the GI, I also removed the following file which seemed to help with some GPO related issues too. C:\Windows\System32\GroupPolicy\Machine\Registry.pol

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.