Attempting to launch a VMware Horizon View virtual desktop after successfully authenticating fails with the error: “Your user account is disabled.”

This blog post serves as an update to the following I wrote back in April 2018:

"Your user account is disabled" error is thrown after upgrading VMware Horizon View to 6.2.0 or 6.2.1
http://terenceluk.blogspot.com/2016/04/your-user-account-is-disabled-error-is.html

I finally got the go-ahead to upgrade the environment and did not want to move from 6.0.1 to the latest 7.4.0 in one shot so I decided to upgrade to 6.2.0, then upgrade the agents to 6.2.1, upgrade servers to 7.4.0 and finally upgrade the agents to the latest version. Knowing that I was going to run into the error as described in the post above, I allocated extra time for troubleshooting because I wasn’t convinced that this was a bug due to the limited information available and the comments people left on the post. What I ended up discovering through troubleshooting was that this wasn’t a bug but rather an Active Directory domain issue so I hope to provide this update in case someone runs into the same issue.

Problem

You’ve completed an upgrade of VMware Horizon View and noticed all functions operate as expected aside from users trying to connect from external via the Security Server, who are from another domain in the same Active Directory forest. The error below is what they receive when they attempt to connect:

Your user account is disabled.

These users from another domain but in the same Active Directory forest have no issues connecting from the internal network.

Solution

Before I begin, let me provide information as to how the domains are configured.

Active Directory Forest Root Domain: contoso.com

Domain in the same forest but separate tree: fabrikam.com

The domain in which the Horizon View environment is deployed in is contoso.com but fabrikam.com users use this environment as well. Users from contoso.com can authenticate without any issues but fabrikam.com users cannot authenticate via the View Security server.

Seeing that users were able to connect from the internal network but not external, I logged onto the View Connection server that is paired with the View Security server handling external connections, reviewed the event logs and found the following error:

Log Name: System

Source: NETLOGON

Event ID: 5516

Level: Error

The computer or domain BMVV01 trusts domain fabrikam.com. (This may be an indirect trust.) However, BMVV01 and fabrikam.com have the same machine security identifier (SID). NT should be re-installed on either BMVV01 or fabrikam.com.

The above error log led me to believe that we may have a duplicate SID issue between the View Connection server paired with the View Security server and the fabrikam.com domain controllers (all domain controllers share the same SID) so I went ahead to PsGetsid64.exe from the SysInternals tools to compare the SIDs and confirmed that they were all identical:

There are several ways address this but the way I resolved the issue was deploy a new View Connection server with a unique SID, and then swap out the server with the duplicate SID.

My understanding as to why the desktop fails to launch for the user is because authentication takes place between the View Connection server and the domain controller but because both servers have the same SID, the process fails and View falsely believes the user’s account is disabled.

Hope this helps anyone who may encounter this problem.

Launching a virtual desktop via VMware Horizon View 6.2.0 HTML Access fails with the error message: “ERR:p:bad method”

Problem

You’re able to successfully authenticate via the login page for HTML access:

… but notice that launching a virtual desktop will immediately fail with the error message:

ERR:p:bad method

Solution

This error stumped me for quite some time as I was unable to find any related forum posts or KB articles and what ended up being the issue was that the Google Chrome browser I was using could not launch the desktop:

Version: 66.0.3359.139 64-bit

Attempting to use an alternate browser such as Microsoft Edge successfully launched the virtual desktop:

I proceeded to try using the problematic Google Chrome browser to launch a VMware Horizon View 7.4.0 virtual desktop and was successful so this problem appears to be limited to 6.2.0.

Attempting to recompose a VMware Horizon View 6.x desktop fails with the error status: java.lang.InterruptedException

I recently had to investigate an issue with a few VMware Horizon View 6.x desktops that failed to recomposed and was stuck in an error state with the status java.lang.InterruptedException and would like to share my troubleshooting steps in this blog post.

Problem

An attempt was made to recompose a desktop by the process fails with the desktop in an Error Status:

Clicking on the icon beside the Error status brings up the following details:

java.lang.InterruptedException

Pairing state:

Configured by:

Attempted theft by:

Launching the console of the virtual desktop displays the following:

Solution

I’ve come across this issue twice in the past and the first option to try is manually power off the desktop and leave it for a few minutes to see if vCenter is able to proceed with the recompose.  If the recompose operation does continue and completes then one of the possible causes for this is if an administrator had inadvertently interrupted the recompose operation by manually powering the desktop on.

If shutting the virtual desktop down doesn’t work then navigate into the virtual desktop’s summary tab in the Horizon View Administrator console to see if the snapshot used for the Base Image still exists because I’ve noticed in the past that this can happen if the master image no longer has the snapshot and a recompose or refresh operation is executed for the desktop. From here, try to issue another recompose with a different snapshot that exists on the master image and if that doesn’t work then recreate the machine completely.  In situations where the machine has a profile disk for a user that needs to be preserved, proceed to detach the profile disk and recreate a desktop with the profile disk.

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

Operation System: Windows 10 Enterprise 2015 LTSB

Monitors: 3 x Dell P2414Hb (1920 x 1080)

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

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

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

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.

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

PCoIP Secure Gateway

Use PCoIP Secure Gateway for PCoIP connections to machine

PCoIP External URL

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….

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.

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:

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

The following is the native 7.4.0 build:

VMware-viewconnectionserver-x86_64-7.4.0-7400497.exe