You can set it on pool settings
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
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!
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.
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.