Are you the publisher? Claim or contact us about this channel


Embed this content in your HTML

Search

Report adult content:

click to rate:

Account: (login)

More Channels


Channel Catalog


Channel Description:

Most recent forum messages

older | 1 | .... | 829 | 830 | (Page 831) | 832 | 833 | .... | 904 | newer

    0 0

    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.


    0 0

    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


    0 0
  • 02/27/18--17:40: Re: Rebooting UAGs
  • 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.


    0 0
  • 02/27/18--19:52: Re: Rebooting UAGs
  • 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.


    0 0
  • 02/28/18--00:44: Re: MultiScreen
  • 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.


    0 0

    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


    0 0

    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?


    0 0

    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.


    0 0
  • 02/28/18--21:52: Re: Rebooting UAGs
  • 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.


    0 0

    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.


    0 0
  • 03/01/18--05:35: Re: Rebooting UAGs
  • So Ben thanks for the reply. Let me go over our architecture a bit, see how maybe we're differentiating.

     

    • We have all users pointed to a GTM which is split DNS. Right now we're focused on externals, so, we'll stick to that. Externally when you hit the GTM, you are handed off to an LTM in either DC1 or DC2. Under each of those LTMs, are 2 UAG servers. So DC1UAG1/DC1UAG2, DC2UAG1/DC2UAG2.
    • The UAGs are each configured to point at an internal LTM for their Connection Server URL. Inside that LTM, we have 2 brokers designated for external access. This way we are not doing any 1 to 1 mapping. So the DC1 UAGs are pointed at DC1BrokerLTM, DC2 UAGs are pointed at DC2BrokerLTM. Again these LTMs are in front of 2 connection brokers isolated for external access.
    • For the PCOIP External URL field we're using the IP of the UAG LTM.
    • For Blast External URL we're using the UAG LTM FQDN:8443.
    • For Tunnel Eternal URL we're using the UAG LTM FQDN:8443.
    • We have all 3 boxes unchecked on the isolated connection brokers.

     

    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.


    0 0
  • 03/01/18--06:17: Re: Rebooting UAGs
  • 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:

     


    0 0
  • 03/01/18--06:53: Re: Rebooting UAGs
  • 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.

     

     

     


    0 0
  • 03/01/18--10:11: Re: Rebooting UAGs
  • We actually have a nearly identical deployment with a few exceptions.

    • We are a single datacenter at the moment with no GTM. Our internal teams are working on deploying GTM and then I will switch to that.
    • We use Blast Extreme instead of PCoIP
    • We do not tunnel our UAG through the F5. From Load Balancing across VMware Unified Access Gateway Appliances we are doing "Method 2 - Multiple Port Number Groups". You can see my discussion on that here Traffic flow when load balancing UAG. Essentially we have a VIP on LTM using the Horizon iApp that points to the two UAG. The Blast External URL on each UAG is the public address of the individual UAG instead of LTM.

     

    I think you might need to allow TCP 32111 from the UAG to the Horizon Agent. See line 11.

    View TCP and UDP Ports


    0 0

    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.


    0 0

    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. 


    0 0
  • 03/01/18--16:25: Re: Rebooting UAGs
  • 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.


    0 0
  • 03/01/18--16:46: Re: Rebooting UAGs
  • 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?


    0 0
  • 03/01/18--16:47: Re: Rebooting UAGs
  • 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.


    0 0
  • 03/01/18--21:43: Re: Rebooting UAGs
  • 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.

    Selecting the Correct Certificate Type


older | 1 | .... | 829 | 830 | (Page 831) | 832 | 833 | .... | 904 | newer