Pages

Monday, April 30, 2018

Adding a 3rd monitor to a Dell Wyse Z90QQ10 thin client connecting to a VMware Horizon View 6.2 virtual desktop causes slow video performance with mouse movement and typing delays

Update – July 2, 2018

Please see my following blog post for an update to this issue:

Poor multi-monitor performance using Dell Wyse 7020 Windows 10 IoT with VMware Horizon View 6.x to 7.x
http://terenceluk.blogspot.com/2018/07/poor-multi-monitor-performance-using.html

----------------------------------------------------------------------------------------------------------------------------------------------------

I recently ran into a strange issue with a VMware Horizon View 6.2 environment where adding a 3rd monitor caused the performance to severely degrade to a state where the virtual desktop was almost unusable.  The time constraints I had due to other various projects did not allow me to perform further troubleshooting so the solution I have isn’t what I would prefer but I’ll update this post when I have more time to thoroughly investigate the issue.

Hardware

Thin Client: Dell Wyse Z90QQ10 Thin Client

imageimage

Operation System: Windows 10 Enterprise 2015 LTSB

image

Monitors: 3 x Dell P2414Hb (1920 x 1080)

Horizon View Client: VMware Horizon View Client 4.7.0 build-7395453

image

Problem

The thin client and virtual desktop was running optimally until we attached the 3rd Dell P2414Hb monitor, which lead to noticeable keyboard and mouse lag.  The Windows 10 IOT thin client also started displaying this message in the background:

Close programs to prevent information loss

Your computer is low on memory. Save your files and close these programs:

VMware Remote MKS

image

The user wouldn’t notice this because they don’t typically minimize the virtual desktop but if they did and clicked the Close program button then the View Horizon Client would eventually close and terminate their session.

Solution

As mentioned earlier in the post, I haven’t had the time to continue troubleshooting but what allowed us to fix this performance issue while still providing 3 monitors was swap the 3rd Dell P2414Hb monitor with a lower resolution 1280 x 1024 one.  This is not ideal and isn’t a supported configuration for View 6 but isn’t explicitly mentioned as not being supported in View 7 as shown in the following VMware Horizon View documentation:

Monitors and Screen Resolution
https://docs.vmware.com/en/VMware-Horizon-7/7.5/horizon-architecture-planning/GUID-8A29C7A6-8A99-49E3-B596-4A61F969250A.html

Using Multiple Monitors (View 6)
https://docs.vmware.com/en/VMware-Horizon-6/6.2/com.vmware.horizon-view.planning.doc/GUID-FC4A3F61-7C8B-4F08-87AE-007E2A598169.html

I’ll update this post when I have the time to perform more testing but I hope this would help anyone who may face this same issue

Thursday, April 26, 2018

Updating the public DNS record for VMware Horizon View remote access through Security server displays a black screen and disconnects with: “The connection to the remote computer ended.”

Problem

You’ve recently had to reroute VMware Horizon View remote access traffic through the Security Server because of an ISP change so the firewall rules were updated for the external IP NAT and then you proceed to change the public DNS record but remote connectivity now fails with:

  1. User successfully authenticates
  2. The desktop launches
  3. A black screen is displayed for 5 to 10 seconds
  4. The connection terminates with the error message: The connection to the remote computer ended.

image

Solution

One of the common causes to this issue is if the PCoIP External URL configuration for the View Security Server and View Connection Server settings were not updated with the new external IP address.  The following are screenshots of the fields that will need to be updated:

PCoIP Secure Gateway

PCoIP External URL

image

PCoIP Secure Gateway

Use PCoIP Secure Gateway for PCoIP connections to machine

PCoIP External URL

image

Saturday, April 14, 2018

Using Azure AD credentials to sign into Atlassian site with SAML integration configured fails with: "Sorry, but we’re having trouble signing you in. AADSTS70001: Application with identifier ‘https://auth.atlassian.com/saml/D4327……’ was not found in the directory…”

Problem

You’ve completed configuring Azure Active Directory integration with Atlassian Cloud using SAML as per the following Microsoft document:

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-saas-atlassian-cloud-tutorial

However, you notice the sign on process fails with the following error when you are redirected to the https://login.microsoftonline.com authentication portal:

Sorry, but we’re having trouble signing you in.

AADSTS70001: Application with identifier ‘https://auth.atlassian.com/saml/D4327……’ was not found in the directory 90f21aaa-b870….

image

This page then quickly reidrects you to the following https://id.atlassian.com/login/callback?continue... page:

Oops, there was an error logging you in.

Hmm... we're having trouble logging you in. You'll need to talk to your Organization admin - tell them we sent you, and that there appears to be an issue with the identity provider entity ID used for your SAML single sign-on configuration.

image

Solution

This error is usually caused by an incorrectly entered Identity provider Entity ID URL in the SAML configuration on the Atlassian portal. In the case of this example, the URL was missing a / at the end and correcting this would fix the issue:

image

Friday, April 6, 2018

Problems after upgrading VMware Horizon View to 7.4.0

Referring the following blog post I wrote a couple of months back:

VMware Horizon View 7.4.0 virtual desktops does not automatically power on after upgrade
http://terenceluk.blogspot.com/2018/02/vmware-horizon-view-740-virtual.html

… the environment I had upgraded to VMware Horizon View to 7.4.0 continued to have desktop power on policies, which required chronic weekly reboots to resolve so I ended up opening a ticket with VMware to have them review the issue. The case was eventually escalated to the engineering team and the following was the response I received:

We would like to inform you that our Product Development Team reviewed the logs and figured out that it is an issue with VcCache.

The escalated engineer told me that our options were to try a patched build that hasn’t been fully tested for production environments or wait for the next version and since there wasn’t an official release date for the next version, we opted to try the patched build.  I’ve scheduled the upgrade to go on this weekend and will update this post in a week with the results.

In addition to the desktop power on issue, the VMware engineer also mentioned that other customers have experienced refresh task and provisioning issues with 7.4.0, which this patch fixes.  For reference, the following are the details of the patched build file:

VMware-viewconnectionserver-x86_64-7.4.0-14570406.exe

image

imageimage

The following is the native 7.4.0 build:

VMware-viewconnectionserver-x86_64-7.4.0-7400497.exe

image

imageimage