The logical diagram for how this operates looks like so: Breaking down silosĬontrolUp can break down silos by moving the timeout tracking from the operating system to ControlUp Automation. And if you are in a cloud environment more cost in each spun up VM. Each fragment is more overhead in the fixed costs, more overhead of administration time and effort, and more consumption of precious shared resources. We would have to fragment our environment even more. Now imagine you have more applications and each have requested their own timeouts. All so two different stopwatches can operate. This puts an additional strain on the hardware underneath. In this configuration, more resources are consumed as each server and session have fixed costs of CPU and memory. If a user has access to both applications than two user sessions must be created. With these opposite goals, we need two servers to set this up. Things like your standard office productivity applications. In other cases an administrator may want some applications to have long timeouts for a better user experience. However, it may be absolutely required due to the sensitivity put in these apps. This causes you to either relaunch your application or reconnect to your session which is actually a jarring experience. Low timeouts tend to be degrade the user experience because the user will get disconnected or logged off of the servers more often. If you work in environments with sensitive or privacy conscious applications, you may get requests for these application timeouts to be very low. This leads to more servers and less consistency in your infrastructure. Depending on the nature of your environment you may have to include additional servers (if you’re doing N+1 high availability) and if your secure app has a smaller user base, you’ll size your servers to reduce resource consumption. This would force you to either have the user accept more disruptions in the enforced disconnects or logoffs, or silo servers with different policies applied. You may want to set differing timeouts for a user depending on whether they are accessing a sensitive application or a simple office app. You can configure a user timeout policy, but that user will get that timeout without regard to what application or work they are doing. The challenge with the session timeouts is they are set without context. They apply to Remote Desktop Session Hosts, which includes Citrix Virtual Apps and Desktops (nee XenApp/XenDesktop), VMWare Horizon, and Windows for Virtual Desktop (WVD) servers. The different timeouts can be configured here, either per user or per machine. Once this timeout is exceeded the session is logged off. Another timeout is then started for how long a session is allowed to exist in this state. The disconnected state means the streaming of the image to the remote endpoint has stopped. Once the timeout hits it’s configured limit, the session is then disconnected. In ControlUp we show the current duration of the timeout in the “Idle Time (Mins)” column. When a user has no activity than the idle timeout starts counting. User activity like keyboard and mouse actions will reset the idle timeout to 0. When a session is in the “Active” state the idle timeout is 0. “Active”, “Active with Idle time” and Disconnected. Session TimeoutsĪ session, generally, has 3 states. There was always one reason to silo that I could not work around. When you are able to break down silos you’re thankful for the reduced effort in managing your environment. This made management of virtual machines easier, reduced configuration sprawl and made the environment more consistent. I worked extremely hard to minimize the number of silos in our environment. When I was a Citrix administrator, I hated having server silos.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |