VMware Horizon Community
spetty7326
Contributor
Contributor
Jump to solution

Reboot Connection Server - Disconnects all PCoIP Clients

We are (luckily) early in a View 4.5 deployment, and don't have any production desktops in use as yet.  We recently upgraded from 4.1 to 4.5, and during the upgrade we rebooted our primary View Connection Server.  When we did that, the 10 or so PCoIP clients we had connected all disconnected - which caused us a lot of worry, as we plan to deploy several hundred.

From what I've read, PCoIP are supposed to be direct-to-client connections, and not need the broker after the connection is made.  I've looked for the "direct connection" setting, but don't see anything like that in View Admin.

Is it normal that all of the clients would disconnect on the loss of the broker?  Is there any way to prevent this?

Thanks,
Sean

0 Kudos
1 Solution

Accepted Solutions
mpryor
Commander
Commander
Jump to solution

This is expected behaviour, though we have had feature requests to change it. For a bit of background to the explanation, there are two session types in play here which I'll refer to as the broker session (authenticated session directly to the broker) and the desktop session (tracked user session on the remote desktop).

When you connect to a desktop session through the broker, it's associated with the broker session so that when the broker session expires (via explicit logout or the global timeout value that is set in the admin UI) it can forcibly disconnect the desktop session. Essentially, when you cleanly shut down the broker it will invalidate all the broker sessions it has, each one then checking for associated connected user sessions and issuing a disconnect request to the agent as with a normal expiry. In the case of a crash/hardware failure of the broker direct connect sessions will not be affected.

View solution in original post

0 Kudos
8 Replies
mpryor
Commander
Commander
Jump to solution

This is expected behaviour, though we have had feature requests to change it. For a bit of background to the explanation, there are two session types in play here which I'll refer to as the broker session (authenticated session directly to the broker) and the desktop session (tracked user session on the remote desktop).

When you connect to a desktop session through the broker, it's associated with the broker session so that when the broker session expires (via explicit logout or the global timeout value that is set in the admin UI) it can forcibly disconnect the desktop session. Essentially, when you cleanly shut down the broker it will invalidate all the broker sessions it has, each one then checking for associated connected user sessions and issuing a disconnect request to the agent as with a normal expiry. In the case of a crash/hardware failure of the broker direct connect sessions will not be affected.

0 Kudos
spetty7326
Contributor
Contributor
Jump to solution

Thank you.  That is certainly disappointing to hear, considering the number of clients we expect to deploy - which is probably quite small compared to most.  Our application and the users really don't have the luxury of just re-connecting once the broker is rebooted, and this could have disasterous consequences for us.  Is there any type of backup plan/procedure used as a best practice to mitigate this when/if it happens?  Should every thin client be built with a corresponding RDP connection?

Is there a way that I can file anything in support of this feature/change request?

Thanks for the quick answer.

0 Kudos
mpryor
Commander
Commander
Jump to solution

Is there any type of backup plan/procedure used as a best practice to mitigate this when/if it happens? Should every thin client be built with a corresponding RDP connection?

Since it's only relevant when the service is cleanly shut down (not in the event of hard power off or some other disaster), then it should be possible to plan in advance. If you have multiple connections servers for redundancy, you should remove the broker beforehand to ensure no users have gone through it. This is not PCoIP specific, RDP connections initiated by the broker will also be disconnected as requested.

Is there a way that I can file anything in support of this feature/change request?

Yes, VMware have a feature request form at http://www.vmware.com/contact/contactus.html?department=prod_request. As I said in my last comment though it has already been requested, and is already on our radar.

0 Kudos
rseabrooke
Enthusiast
Enthusiast
Jump to solution

Funny in view 4.x if you use RDP when you reboot a connection server it would not disconnect the view clients. I ran into the same problem with view 4.6 pcoip everybody got disconnected. I really wish vmware would put this high on a list of things to fix.

0 Kudos
Peter_Grant
Enthusiast
Enthusiast
Jump to solution

I think the View documentation should be changed to imply that the disconnection will happen. I've not checked View 4.6 docs but 4.5 implied that direct connection mode would not disconnect.

------------------------------------------------------------------------------------------------------------------- Peter Grant CTO Xtravirt.com
0 Kudos
CyberTron123
Enthusiast
Enthusiast
Jump to solution

I can confirm (at least on my setup) that if you are using direct connection (aka, not using "tunneled mode" ) then your clients won't be disconnected...however, the default setup is to go through the broker and then your clients will be disconnected.

This behavior is the same on 4.6 as on 4.5

0 Kudos
mpryor
Commander
Commander
Jump to solution

As a follow-up note (I was recently asked about this thread), this behaviour has been changed in View 4.6.1 onwards - if you're connecting directly to the desktop then you will not be disconnected when the broker initiating the connection is shut down. If you are using tunneling for RDP, or the PCoIP secure gateway feature, then you will still be disconnected.

0 Kudos
mittim12
Immortal
Immortal
Jump to solution

Thanks for the update.  

0 Kudos