Clifford O'Rourke

Im fairly certain this issue is resolved with 2406

You cant reach support? Is that you cannot create an SR? Ive seen a case similar to this recently where postgreSQL for windows was deployed on the Horizon Recording Server. I suggested to deploy postgreSQL on a separate Linux VM as postgres uses UTC and it may have been conflicting with the Server NTP time/date. I have yet to hear from the TSE about the status of this test.

You should be able to see the login information in the audit reports from the Access dashboard

Can you open an SR for this please @BillClark We can troubleshoot the issue more in depth.

@Anobix67 What isthe Horizon version you are running? (SESSION:9381_***_6921)..... is for a desktop session @BillClark You could lok for entries such as: [REST_AUTH_LOGOUT_SUCESS] "User <ad.domain>\Username has logged out from Horizon Server REST API" Or [RestApiAuthFilter] Send response for /view-vlsi/rest/v1/logout elapsed time:<4> msecs Or [EventLogger] Info_Event:[VLSI_USERLOGOFF_REST]

If the issue occurs again can try following this KB: https://kb.omnissa.com/s/article/2076107 Old i know but the same applies.

Most likely is not able to register with AD corrrectly. A reinstall of the connector installer should be sufficient providing you have the correct files downloaded from the Access appliance. Is a CA signed certificate being used or the default self signed?

You can use the ViewDBChk tool as per: https://kb.omnissa.com/s/article/2118050 If the above fails to resolve your issue with the VM's stuck in deleting sates in Horizon Admin UI you can try the following KB: https://kb.omnissa.com/s/article/2015112 If you still have the issue you can open an SR with us.

I have checked other versions of Horizon....8,9, 8.12 and do not see an issue with admin UI timeouts. I do not have access to 8.11 right now. Can you see anything in the Connection Server debug logs located in C:\ProgramData\VMware\VDM\Logs for the time of the timeout being set ...or the isue occurring?

It does sound like there is definitley some sort of lag for the VM you are using. If you check the VM in vCenter, all is ok with the VM settings?...Network, storage e.t.c? Do you have any templates to create a new VM or cloning an existing VM that produce the same kind of issue? Are there any errors in the event viewer for the VM with the issue?

Along with DEM there is App Volumes (Both products of the Horizon Suite) where when configured DEM will communicate with App Volumes and a user writable volume will be created for Outlook .ost file. This feature is present for a number of years now.

Hi, Is both the Agent and Manager configured to use the same port? Are there any DNS related issues between the Manager and Agent machines? You can open an SR with us where we can work to resolve your issue.

You can open an SR where we can assist you on this issue with the new Teams application.

These links relating to App Volumes operations are broken currently as the content needs to be updated as far as I am aware. It is being worked on currently. Once the content has been updated the KB's will be available in Omnissa. There is no ETA on this yet im afraid.

Attempting to provision an App Volumes Package from the base image would not be supported. A clean VM without the Horizon Agent installed is needed with a clean snapshot to revert back to after each captured package. You can try adding the appplication .exe to the HookInjectionWhitelist located in HKLM\SYSTEM\CurrentControlSet\Services\svdriver\Parameters in the base image. For example, you can add the .exe to the list as follows: *\<application.exe>||* Restart the base image, run ipconfig /release and ipconfig /flushdns, power down and take a snapshot. Once the image is pushed to the desktop pool you can test by attaching a package to a user again to see if the issue persists. If the issue is still present, open an SR with us and we can perform some troubleshooting to see if we can get a resolution for you.