With View, you can continue to use the application provisioning techniques that your company currently uses, and you can use Mirage. Two additional considerations include managing server CPU usage and storage I/O and determining whether users are permitted to install applications.
If you push applications out to large numbers of remote desktops at exactly the same time, you might see significant spikes in CPU usage and storage I/O. These peak workloads can have noticeable effects on desktop performance. As a best practice, schedule application updates to occur during off-peak hours and stagger updates to desktops if possible. You must also verify that your storage solution is designed to support such workloads.
If your company allows users to install applications, you can continue your current policies, but you cannot take advantage of View Composer features such as refreshing and recomposing the desktop. With View Composer, if an application is not virtualized or otherwise included in the user's profile or data settings, that application is discarded whenever a View Composer refresh, recompose, or rebalance operation occurs. In many cases, this ability to tightly control which applications are installed is a benefit. View Composer desktops are easy to support because they are kept close to a known good configuration.
If users have firm requirements for installing their own applications and having those applications persist for the lifetime of the remote desktop, instead of using View Composer for application provisioning, you can use instant clones together with App Volumes. Another solution is to create full-clone dedicated desktops, allow users to install applications, and then use Mirage to manage and update the desktops without overwriting user-installed applications.
Also use Mirage to manage locally installed offline desktops and their applications. For more information, see the Mirage Documentation page.