VMware Horizon Community
caryers
Contributor
Contributor

VDI Desktops in a Disconnected State

Is there a View (6.2.3) best practice that indicates that Windows 7 VDI desktops should be logged off by the VIew media pool settings after 24 hours if left in a disconnected state or else there may be corruption within the ADAM database? We are running our VDI environment on vCenter 6. Are there any best practices documented for this as well?

Thanks in advance...

Scott

Reply
0 Kudos
5 Replies
pari2k3
VMware Employee
VMware Employee

You can set it on pool settings

Automatically logoff after disconnect

Immediately. Users are logged off as soon as they disconnect.

Never. Users are never logged off.

After. The time after which users are logged off when they disconnect. Type the duration in minutes.

The log off time applies to future disconnections. If a desktop session was already disconnected when you set a log off time, the log off duration for that user starts when you set the log off time, not when the session was originally disconnected. For example, if you set this value to five minutes, and a session was disconnected 10 minutes earlier, View will log off that session five minutes after you set the value.

Documentation for VMware Horizon 7 version 7.0

Reply
0 Kudos
caryers
Contributor
Contributor

Thanks for the reponse. However, I know where the settings are and how they work and interact with each other. My question to the community if there is Best Practice parameter to set the Logoff setting for Windows 7 VDI desktops? Ea. if I place 7,200 hours (which is 5 days) to force logoff of a disconnected VDI desktop, will this possibly corrupt the ADAM database? Is 7,200 to high, etc? What is the best practice parameter here...Thanks in advance...Scott

Reply
0 Kudos
TheRickOlson
Contributor
Contributor

We've not yet implemented the "after...." setting, though I may start doing so.  Trying to schedule maintenance on desktops that are disconnected gets frustrating because the maintenance jobs will skip desktops in use (we utilize Unidesk for layering).  Also, VDI may be far superior to traditional desktops (and they are IMO), but they're still Windows.  Windows will still need to be restarted every once in a while.  What I'm currently pondering is whether I should institute a 2-hour auto-logoff or a 4-hour.  If a user disconnects while in the office and begins traveling home, I can see them being more than 2 hours before they get settled and able to reconnect.  Four hours might be a bit easier to begin setting up.  It's probably best to start with a longer time and see if anyone complains, and then tighten it up to something more reasonable.  If a user is disconnected for 5 days and reconnects, chances are their machine may not perform at its optimum anyway.

Just my 2 cents!

Reply
0 Kudos
caryers
Contributor
Contributor

We use Unidesk(2.10.x) as well. We used to leave this setting to the default NEVER back when we where a View 5 shop. I am looking to see what VMware documentation indicates about using this parameter. We are currently set for 12 hours, but want to increase it to 24 or higher once again. Yes, we know windows needs a good reboot every now and then, but every 4 or 6 hours is just overkill.

Reply
0 Kudos
Ray_handels
Virtuoso
Virtuoso

I don't think there is a best practice to be honest. For as far as I'm concerned it's more of a " Do i have enough machines to cope with endless sessions"  and do the sessions work well when moving around from place a to place b.

What we noticed (just an example and can be fixed but something to consider) is if you move from a PCoIP based session (for example using a Zero Client) to a Blast based session you might end up with audio not working properly because the PCoIP sessions uses it's own driver (if you installed it) and blast can't use it but it is selected in that session resulting in no audio at all.

Also, when you look at the European market there are a lot of part time employees. The big plus for VDI in pooled mode is that you only need to have the resources for those machines that are actively being used.

I did work with Unidesk for a while but we ended up choosing Appvolumes because it can create the machine on user base during logon and my understanding of Unidesk is that every user needs to have it's own machine.

If the latter one is the case with Unidesk or you have dedicated machines I don't think you need to set a max (other than the occasinal management) to kill the session.

Reply
0 Kudos