It’s a question that comes up a lot in discussions with customers: ‘Should I use persistent or non-persistent desktops?’. It is a question that has been around for well over a decade but as technologies in this area improve the question re-emerges.
Persistency and non-persistency are normally used to refer to how a machine is provisioned and maintained.
A non-persistent machine: Any changes made to that machine (physical or virtual) are removed on reboot and the machine reverts to its previous state. In order to apply changes to that machine image, it must be switched to a writable mode.
- Pros: These machines generally run from a shared image. Updates only need to be applied to the shared image, not on each target machine, resulting in reduced maintenance effort and a reduction in storage consumption.
- Cons: Not suitable for certain use cases e.g. User Installed Applications (UIA) or Developers (or similar) that need to apply system level changes ad hoc. It also requires personalisation of the cloned machines to ensure they are compatible with some management platforms e.g. In-machine anti-virus agents.
For a long time, non-persistent machines have been the preferred option administrators.
A persistent machine: Any changes made to that machine are retained after the next boot.
- Pros: The are some caveats that come with using a shared image that are avoided with a full persistent machine e.g. personalisation tasks on boot. These machine types are also needed if the machine is located outside of the datacentre or needs to operate offline.
- Cons: The management overhead increases as each machine is managed as a single entity. Traditionally fully persistent machines consume more storage capacity than a non-persistent offering.
What the User Wants
Persistency can also refer to an end-user experience from their desktop or set of applications. Most, if not all, end-user’s want the persistent experience. They want the changes they made to their browser settings, their desktop shortcut alignment or a new application they installed, to be ‘as they left them’ when they next login. The exception to this rule may be the kiosk user who only needs one-off access to an application, but they are the exception to the rule.
What the User Needs
The reason I make the distinction between the machine provisioning and the user experience types of persistency, is that the two do not necessarily need to align. By this I mean that most users can be provided with a persistence user experience but only ever log onto a non-persistent machine. On the other hand, there are other users, normally in the minority, that require the persistency to exist at the machine level i.e. User Installed Applications (UIA) or system-level settings changes.
As with most design decisions, it should always come back to the use case and their requirements. What do your users need? What are you trying to achieve? From there, an educated assessment can be made on the required technologies. Here are some examples:
The reason that profile size is a distinguishing factor between Groups A and B is that most traditional profile solutions in non-persistent environments require a user’s profile to be copied from a profile share into a user’s session at login and copied back out to the profile share at log off. The larger the amount of data to be copied, the longer the login and log off process may take. The more time logging in or logging off the less time in which that user can be productive. Some profile solutions can mitigate this issue by loading a functioning desktop first, while the profile copy continues in the background. However, the application that requires that profile data will still have to wait for the copy to complete. The most famous example of where User Group B separates from User Group A is with the Microsoft Outlook OST file roaming issue.
The Outlook OST File Roaming Issue
Most Office 365 customers run without on-premises Exchange servers. There are some running in a Hybrid mode i.e. on-premises Exchange servers with an Office 365 subscription but, again, these are in the minority. If Office 365 customers want to use the full Outlook client, they will want to switch on Cached Exchange Mode to ensure optimal performance. Switching on Cached Exchange Mode creates on OST file within the user’s profile which holds a synchronised copy of a user’s Exchange mailbox. The Outlook client reads directly from the OST file ensuring that the client is not affected by any network connection disruptions to the Exchange backend. Depending on the duration configured, this OST can grow to a considerable size e.g. +10GB. In non-persistent environments you can imagine the impact of moving a file of this size in and out of every user session at log on and log off.
Solutions for Persistence with a Non-Persistent Image
There are a number of solutions available that not only address the OST file roaming issue but also allow administrators to provide increased levels of persistency while still using a non-persistent image. These solutions all involve attaching a user specific virtual disk at log on and detaching it at log off. Instead of copying in a profile, the entire profile or a subset of the profile is served from this virtual disk. The time taken to mount a 10GB disk to a machine is significantly shorter than a 10GB file copy, hence login times are shortened considerably.
As can be seen from the above table, there are several solutions available in the market that can provide an additional level of persistency over and above what comes as standard from a profile solution like User Environment Manager (UEM) or Workspace Environment Manager (WEM). These solutions allow administrators to blend the ease of management of the non-persistent/shared image model with varying levels of persistency to enhance the end-user experience.
Risks of User Installed Applications (UIA)
There are some considerations/risks that come with enabling User Installed Applications (UIA) e.g. Citrix User Layer or VMware AppVolumes Writable Volumes.
Future Updates: Providing a user with the ability to install applications and make system level changes on a non-persistent machine, using a persistency disk, opens the risk of conflicts in the future. A new version of Windows 10 is released every 6 months. In theory the base images will need to be updated every 6 months. Every time the base image is updated administrators will need to run the gauntlet of something a user has installed into a persistency disk conflicting with the updated Windows 10 version.
Support: As soon as you allow non-IT users to install applications onto a machine within a managed environment the question of support arises. If the user breaks an underlying productivity application by installing an update over-the-top, what is the support model? Should you delete the user persistency disk and allow the user to start again or troubleshoot the issue in-VM? What is the back-up and recover process? How do you achieve multi-site or HA? These are questions that need to be answered/addressed during the planning phase of any user-persistency feature deployment.
An Alternative Option
As modern storage solutions offer improved de-duplication and compression capabilities, the storage capacity benefits of shared-image VMs over full clone VMs has reduced. In addition, the ability to manage off-domain Windows 10 as a mobile device (Modern Management) through Unified Endpoint Management (UEM) solutions like VMware Workspace ONE, Microsoft InTune and Citrix EndPoint Management means that the management of large Windows 10 deployments has also simplified. Using a UEM solution to manage on-domain as well as off-domain Windows 10 devices is now a possibility. That goes for the User Installed Applications (UIA) use case through VDI too.
VMware Workspace ONE
Workspace ONE from VMware is currently the leading UEM solution in the market. As well as offering the management of Windows 10, iOS, MacOS, Android, ChromeOS, Blackberry QNX and a range of rugged and wearable devices from one platform, it also provides secure access to SaaS and on-premises applications and data to users and devices outside of the corporate network. Sitting on top of this UEM platform is a cloud-hosted, AI-driven automation and intelligence engine called Workspace ONE Intelligence. Workspace ONE Intelligence allows you predictively manage the security posture of devices managed by Workspace ONE and dynamically remove or re-instate access to corporate resources based on that posture.