Attempting to use the Invoke-Command PowerShell cmdlet to remotely install an application hangs indefinitely without starting the installation

Problem

You’ve enabled PSRemoting on a remote server or desktop and attempt to use the Invoke-Command PowerShell cmdlet to remotely install an application with the following cmdlet:

Invoke-Command -computername wkst-122 -ScriptBlock {Start-Process -FilePath 'C:\temp\agent\VMware-viewagent-x86_64-6.2.1-3284564.exe' -ArgumentList '/S /V"/qn' -Wait}

… but the cmdlet executes and hangs indefinitely without starting the installation on the remote computer.  You do notice that the msiexec.exe process is briefly displayed on the target computer’s task manager when the cmdlet is executed but it disappears after a second.

Solution

The first two obvious items to check are:

1. Ensure PSRemoting is enabled
2. The installation file is not on a UNC share as it must be copied locally on the target computer

The one item that is not as obvious and had me stumped for an hour is to ensure that the executable is not blocked. 

If you are copying the executable from a file server then executing the install command then ensure the executable on the file server is unblocked and if you already have the file on the target computer then ensure that the file is unblocked.

Recomposing a VMware Horizon View virtual desktop fails with the error: "No network communication between the View Agent and Connection Server. Please verify that the virtual desktop can ping the Connection Server via the FQDN"

Problem

You attempt to recompose a VMware Horizon View virtual desktop but notice that it fails with the following error:

No network communication between the View Agent and Connection Server. Please verify that the virtual desktop can ping the Connection Server via the FQDN

Solution

There could be various causes for this error but one of the common ones I’ve come across is when there is a problem with the virtual desktop’s network adapter.  For this recent environment I worked on, I noticed that the Summary tab of the virtual desktop did not have a value for the IP Addresses field:

Logging into the virtual desktop allowed me to immediately recognize that Windows no longer recognized the network adapter and therefore none were displayed in the Network Connections console:

Device Manager also displayed the Ethernet Controller in the Other Devices node indicating it was not installed:

To correct the issue, I simply right clicked on the Ethernet Controller item, selected Update Driver Software…:

Selected Search automatically for updated driver software:

Allowed Windows to search and install the vmxnet3 driver:

Verified the ethernet adapter is now listed under Network Adapters:

Restart desktop now that it has network connectivity, verified that vCenter began displaying the tasks required for completing the recompose and that the View Administrator console indicated that customizations are being applied:

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