Finally, you can decide what capabilities will be available for the desktops of this Desktop Policy, and what happens when a user finishes a VDI session:
Session capabilities can be restricted to prevent information leaks, use of restricted resources, etc... The available capabilities are:
Besides, the flexVDI Client accepts command line arguments that enable or disable some of these capabilities. In each case, the most restrictive setting applies (like disabling the clipboard or a shorter inactivity timeout).
This page also lets you specify up to three actions that will take place once the user has disconnected from its desktop and the session ends. For each operation you must specify an amount of time and an action. Then, the action will be performed on the desktop that amount of time after the session ends. If the user connects again before the time of an operation elapses, the action is not executed. The possible actions are: pause, suspend, stop, shutdown and destroy. Stopping a desktop will send an ACPI signal so that the guest's OS can orderly halt the machine, while a shutdown happens immediatelly. Pause, suspend, stop and shutdown will leave the desktop in a state that is recoverable. Furthermore, the guest will be started again when its user connects. On the other hand, if a desktop is destroyed it will be shut down and its state removed. When the user connects again, a new desktop will be created for him or her.
Updating a Desktop Policy's template
One of the most common tasks of a flexVDI administrator is to update the template assigned to a Desktop Policy. This can consist in updating the software, installing new programs, applying some patches, etc... In general, any action that modifies a template's disk images. The problem is that a template cannot be directly modified. It must be first converted into a standalone guest, and in order to do so it must have no cloned guests. As a result, a pre-condition to modify the template of a Desktop Policy is to destroy all the desktops cloned from that template. This also means that your desktops must be volatile. More on how to configure your guests so that they are volatile in this page of this guide.
However, in order to avoid destroying the desktops of users that are currently using them while you modify the template, the preferred way of updating a Desktop Policy's template is the following:
- In the Guest / Host / Pool section, locate the template to modify, and make a new copy of it with a different name. A best practice is to append the date to the name of the template, like "Windows7_20171130".
- Convert the copy of the template into a normal Guest, and launch it (with "Run once", so it does not restart after shutdown).
- Open the console of the new Guest, and make any desired changes, as you would normally do on any computer.
- After completing the changes, shutdown the Guest and convert it into a template again.
- In the VDI section, open the context menu of the Desktop Policy, and modify it so that it uses the new template.
From now on, when new desktops are created under this Desktop Policy, they will make use of the new template. The desktops that were already running with the old template will not be affected. Then, you can configure your Desktop Policy so that the desktops are destroyed when the users disconnect, so that the next time they connect an updated desktop will be created for them. Once all the desktops cloned from the original template are destroyed, it can be deleted if desired.