You should upgrade your Horizon Client for Mac, the latest available is 4.7.0.
After logging in to a pool from the menu bar select Connection>Settings. Then for each pool you will have a Full Screen drop down. You can pick between Use All Displays, Use Single Display and Use Selective Displays.
Hello,
Seeing an interesting issue and I want to know if anyone is experiencing the same thing. In our environment we have a GPO that disables DPI Synchronization. When connecting from a high resolution device such as a Surface Book, everything looks really tiny. Even with Allow Display Scaling checked. If we toggle Display Scaling off and back on it scales as expected. If you log off and back on you again, need to toggle display scaling off and on. We are using the 4.7 Horizon Client and the 7.3.1 Horizon Agent. We notice this on both Windows 7 and Windows 10 VM's.
If we use DPI Synchronization alone it effects the performance of the VM. Mouse moves slower and graphics are not a crisp.
Thanks
Jeff
Off topic again, but, hoping someone can point me in the right direction yet again.
When coming in from the outside via the UAGs, our desktops are stating USB Redirection is Not Available. However, going to the UAGs from internal, it works. From our legacy security servers, we can access USB redirection internal or external. My network security team SWEARS the same firewall rules are in place for the UAGs, as was for the security servers, specifically port 32111. Is there a setting on the UAGs themselves I am missing?
I'm pretty much positive it's a firewall rule as, again, I come in from our secure network it works, outside network it breaks. Basically solidifying the idea the UAGs CAN do it, it's just about what road I'm taking in.
And I think we already found it. On the connection brokers, "HTTP(S) Secure Tunnel" was unchecked. We tested this via the security servers, meaning when we unchecked it they broke in the same manner. Technically we're still seeing the issue even after checking them, but, I think now it has to do about what we're configuring on F5. There's a field asking what FQDN users will use to connect to the environment. We put in the LTM FQDN there (even though users technically go to a GTM, the GTM literally just hands them on to an LTM), but, starting to think that's a misconfig and we should just go GTM all the way.
I put RDSH host farm pool so I don't have all these features.
It's for this reason that I ask you if there is any solution to do that like VDI pool where it's possible to change a lot of settings.
Hi All and thanks in advance for your attention and time.
My question is why is the Horizon Client 233MB's in size. When extracted the actual 32 bit app is 1.4MB's. What is the additional bloat that is included in this executable? Am I in the clear just deploying the 1.4MB client to 32 bit and 64 bit systems? Thanks again.
-Alex
markbenson I just wanted to let you know that we just tested with UAG 3.2.1. It correctly accepts and uses the pfx certificate for both the SSL cert and admin SSL cert during the powershell deployment. Thank you for fixing this!
We were previously on 3.0 and had to wait for 3.2.1 to fix the RADIUS bug. I did find a new bug though, what's the correct way to report that?
We upgraded to 7.4.0 and confirmed that the bug is resolved. We tried 7.3.2 but had to rollback due to an unrelated bug with zero clients.
The only port we allow externally to our F5/UAG is TCP 443 and USB redirection is working for us. We have all three of the tunnels unchecked on our connection servers.
We were seeing something similar with Horizon Agent 7.1.0. Sometimes display scaling wouldn't work. The user would have to uncheck and then check display scaling. Sometimes a restart of the VM that they were connecting to was needed. We just upgraded to 7.4.0 and are in the process of rolling out the agent to see if it helps.
So Ben thanks for the reply. Let me go over our architecture a bit, see how maybe we're differentiating.
From the outside when I try to get in, I get that a tunnel connection could not be established and to try again. I'm testing by bypassing the GTM and going directly to the external LTM. If I check the box for tunnel connections on the brokers, I can get in, but, I won't be able to do USB pass through.
Hopefully this isn't too crazy to read through. Hopefully you can spot what we're missing.
To re-clarify, our security guys are saying the same firewall rules should be in place for the UAGs on the DMZ, as was the security servers. With the boxes checked and coming through the security servers, I can do USB.
Is this setting incorrect/moot for this topic? On the F5 for the LTM. I ask because again we're looking at using UAGs now:
Little bit further. When we switch to using :443 instead of :8443 for the tunnel server, we get a cert error as seen below. It's odd because we're using SSL offloading at the F5, and a wildcard cert. If I don't do tunneling, just straight up PCoIP or BLAST, I can get in fine. Same cert would be in place, so, little thrown off there. Still working through it though. It's ironic because the UAGs are green all the way haha.
We actually have a nearly identical deployment with a few exceptions.
I think you might need to allow TCP 32111 from the UAG to the Horizon Agent. See line 11.
Current Infrastructure:
ESXi/vCenter: 6.0u2
Connection Server: 7.4
Agent: 7.1
Gold Image: Win7 sp1
When I upgraded Horizon 7.0.3 to to 7.4 the connection server will throw the timeout error below:
2018-03-01T13:09:22.765-08:00 ERROR (0E58-1788) <WFE-06> [WaitForInternalTemplateAction] Internal Template: vm-25841 customization appears to not have succeeded. State = error
2018-03-01T13:09:22.766-08:00 ERROR (0E58-1788) <WFE-06> [WaitForInternalTemplateAction] Hit an error in waiting for internal template com.vmware.vdi.logger.Logger.error(Logger.java:92)
com.vmware.daas.cloneprep.common.CPException: Internal Template: vm-25841 customization appears to not have succeeded. State = error
at com.vmware.daas.cloneprep.action.WaitForInternalTemplateAction.execute(WaitForInternalTemplateAction.java:132)
at com.vmware.daas.cloneprep.workflowengine.ActionLink.execute(ActionLink.java:216)
at com.vmware.daas.cloneprep.workflowengine.Task.executeNextAction(Task.java:478)
at com.vmware.daas.cloneprep.workflowengine.WorkflowEngine.processReadyQueue(WorkflowEngine.java:883)
at com.vmware.daas.cloneprep.workflowengine.WorkflowEngine.run(WorkflowEngine.java:651)
at java.lang.Thread.run(Thread.java:748)
I have installed every agent release on the gold image from 7.0.3 to 7.4 and anything > 7.1 will throw the publishing error. Was there anything that changed from the 7.1 to 7.2 release that I am missing that could be causing this? Any help would be appreciated.
I had this exact issue. The only fix is to use HW version 11. ESXi 6.5 + HW 13 + Windows 10 1607 will not work. The issue is video memory, I can't remember the exact number, but if you set the video memory in the VM configuration any number (ex: 128mb), the VM will actually only see 4KB (you can find the log in the ESXi server logs). When you try to resize the screen, this is what caused the BSOD. Usually happens when you are reconnecting to the VDI and the screen size slightly changes.
Thanks for the reply, Ben. I've been told by our network security guys that "all the UAGs have port 32111 to all the desktops IP pools has been confirmed to be open".
I still think we most likely have something misconfigured at the F5 level, but, my theory was weakened a bit today. When I tried going DIRECTLY to one of the UAGs via the Horizon client, and upon authenticating, I was met with "tunnel reconnection is not permitted". So even eliminating the F5, there's something still screwed up.
Would it matter if in the "TLS Server Certificate Settings" when I uploaded my cert, if I only did it for the Admin interface and not the Internet interface? I'm at a point now where authenticating either externally via the F5 LTM, or internally to 1 direct UAG without F5, gives me the same error about certificate mismatch:
But again, we're using a wildcard on the F5, that was also uploaded to the UAGs. But as I think back it was only with the admin interface box checked. Would it even matter?
I should clarify also:
With the "Tunnel External URL" being FQDN:443, I get the cert error. With it being FQDN:8443, I get the tunnel reconnection is not permitted error. For now I've been leaving it as :443.
You need to apply a valid certificate that matches the FQDN that the users are connecting to. The management interface is ideal but not required (They only just added support for replacing the management certificate).
You might want to review the documentation on certificates. There are some gotchas with wildcard certs.
