Horizon View 7 Error "The connection to the remote computer ended"

[RickJSalt]

I have a lone user who is unable to connect to a virtual desktop with the Horizon View 7 client.  Others on the same network are able to access machines in the pool, but he gets an error "The connection to the remote computer ended."  I uninstalled and reinstalled the client, re-confirming connection server settings and whatnot, but with the same outcome.  He has two pools available to him in the client and the other one will deliver a desktop when it's clicked on.  The pool he uses the most gets the error.  He is able to get a machine via BLAST, using HTML access, so I have a work-around in place.  However, I would like to know what the cause of the error might be.  Any and all guidance will be appreciated.  Thanks!

[MatthewDay]

I've seen this error before where the Horizon Client version was not compatible with the Agent version. But, sometimes these horizon errors can be vague without the context of the logs to back them up.

Couple questions.

1. Is it possible to assign a test user permissions to the desktop pool that's having problems and then log on as the test user? Maybe do it once from a different client PC and then again on the problematic users client PC. This should tell you whether the problem is specific to that client PC, or anybody who accesses that desktop pool.

2. Any possibility the Agent versions are different on the 2 desktop pools he can access? Its weird that one works and the other doesn't.

[RickJSalt]

Well, I can get to the pool from my computer using the Horizon View Client, but now I've had two other users report the same error.  I have them using the HTML client for now, and I'm checking the parent machine and going to snapshot it again and then recompose the pool against that, and I'll check the pool settings.  As for question number 2, I have the same agent on my computer as that on other users, so it shouldn't be an agent mis-match issue.  It's bizarre since it's a rather spontaneous issue; the pool has been running fine ever since I created it months and months ago.

[RickJSalt]

I should also note that I have another floating pool that is set up the same way, for another group of users.  Some of those users also have access to the pool that is having this issue.  They can get a machine from the other pool with no trouble at all, so I'm befuddled.  I am recomposing the pool tonight and we'll see what happens tomorrow.

[alienjoker]

Hi,

Can you confirm if your pool is using disposable disks? The reason I ask is that I've experienced the exact same problem and after hours of root cause analysis with ProcMon, found that the logging levels on the RDPBridgeservice for TPAutoconnect were filling up the disposable disk. This then prevents the PCOIP service from being able to run successfully and the only way back onto the desktop was with HTML access.

I have existing SRs open with VMware on this as I've warned them that their logging levels are too aggressive in Horizon 7.0.x

Cheers

Andrew

[RickJSalt]

Andrew,

You may have hit the nail on the head; I do in fact use disposable disks.  I have them set to 2GB for each machine in the pool.   Have you heard back from anyone regarding this issue?  I'll do some poking around to see if there is a way to resolve this and reply back here if/when I figure it out.

Thanks for your input!

Rick

[RickJSalt]

Spoke too soon; had a user call to say she was getting a black screen when logging into a VM.  I reset all the powered up machines in the pool and went to her desk to try again.  No luck.  Tried getting via HTML with the same result, then a message came up to say that the machine had been disconnected.  I have nuked almost all the snapshots, but I think I will try deleting the snapshots altogether and recomposing the pool against a new snapshot of the parent.

[alienjoker]

Hi Rick,

Yup, lots of head scratching at VMware as you cannot turn down the VDM logging lower than what its already set at, yet the TP-AutoConnect logs grow exponentially at around 500KB every 10 minutes. I worked it out that over a 7 day Window, that with 1000 users, this will consume circa 500GB of unplanned capacity, not to mention the unwanted IOPs.

I have the following SR open: 16260979110

A quick test would be to free up some space (no more than 10mb needed just get a session back up again) on the disposable hidden drive and then see if you can reconnect to a disconnected session. What you'll find is that once the logs grow and the drives fill up again, the PCoIP session will disconnect.

As a workaround, I've now dumped using disposable disks, bumped up the size of the Master template to compensate for the relocated Pagefile,sys until VMware come up with a way to disable logging. Not ideal as we're still getting the hit on capacity and IOPs until the desktops are refreshed on logoff.

Cheers

Andrew

[alienjoker]

Just to double/triple check, VMs historically only clear down disposable disks under the following events (unless its changed in Horizon 7)

• Rebalance
• Refresh
• Recompose

A reset of the VMs won't necessarily clear the issue. If you could try refreshing them as opposed to resetting them, you might have more luck.

Thanks

Andrew

[RickJSalt]

I think I may have found the bugaboo.  There was a mapped drive that could not be located; when explorer.exe was loading, it got hung up trying to find it.  Eventually, the OS loaded; I found the registry entry for the drive, deleted it and restarted.  The parent machine came up in no time flat.  I've taken a snap shot and will recompose the pool against it.  We shall see what comes of it!