Over the years we have engaged with thousands of customers doing VDI and one of the most common areas of confusion we encounter in the field is around choosing between persistent and non-persistent desktops. In this blog let’s explore the considerations for making that choice.
Many of you have been in the VDI world for a long time too, but just to level set, here are the canonical definitions:
There are also a segment of technologies that can help with personalization of “non-persistent” desktops so that user settings and even files can be preserved between user sessions landing on different desktops in the same pool. This makes the desktops feel like “persistent desktops” even though the virtual machines are stateless. Microsoft UPD (User Profile Disks) and Microsoft UE-V (User Experience Virtualization) are commonly used by Workspot customers.
There are various products in the market that move the user profile to a network location. There are also “layering” technologies that allow dynamic mapping of apps to the user in non-persistent desktops after the apps are captured in the right format. UEM (User Environment Manager) tools are used to capture the settings and apply dynamic policies in the desktop session. So, there are a plethora of options for customers to achieve their goals when it comes to addressing virtual desktop personalization.
Workspot supports both persistent and non-persistent desktop pools on Azure.
|Type of Pool||User assignment||User Personalization|
|Persistent or Dedicated Pool||User connects to the same virtual desktop every time||The user profile is part of the persistent OS disk|
|Non-Persistent or Floating Pool without any Profiles or Layering||User connects to any available virtual desktop in the pool. The desktops are 100% stateless.||No user personalization|
|Non-Persistent or Floating Pool with Profiles||User connects to any available virtual desktop in the pool. The desktops are made “stateful” with network profiles. Example: UPD||The user profile is attached to the virtual desktop on login. All the apps are part of the base OS disk.|
|Non-Persistent or Floating Pool with Layering technologies||User connects to any available virtual desktop in the pool. The desktops are made “stateful” with profiles and app layering technologies||The user profile and the entitled app layers are attached/unmasked in the virtual desktop on login|
Using Persistent Desktops
Smaller IT teams tend to adopt the same tools for physical PCs and virtual desktops. For example, this means that the tools used to patch the OS, to add/remove applications, to do asset management, and more, should be consistent for physical and virtual desktops. This provides consistent management and change management policies across all the Windows end points in the organization.
Power users, designers, developers, and executives are all common user types for persistent desktops. These users want fast login, 100% application compatibility and full administrative control over the desktop.
Microsoft SCCM and Intune are the most popular tools for managing persistent pools after initial provisioning.
Using Non-Persistent Desktops
Non-persistent desktops are used when the company wants “stateless” desktops. “Image Management” techniques are used to push updates to these desktops. The idea is to patch the master image and push that image to all the users on a regular basis to keep the desktops stateless.
Kiosk or lab environments typically need non-persistent desktops. University labs, hospital kiosks, and call centers are examples of common industry use-cases for non-persistent desktops.
Non-persistent desktops are also used frequently when the customer wants to support more users with fewer virtual desktops. For example, a university may have thousands of students, but no more than 50 users are active in the library at any point. In such a case, it is not a good idea to use “dedicated” assignments.
1) Security is better with non-persistent desktops
Non-persistent desktops in their purest form discard all the user state at user logoff. The user gets a clean desktop on every login and the base image is patched frequently. The desktops are also locked-down (no administrative privileges) and only a few applications are available to the end users. In such deployments, it is correct that non-persistent desktops are more secure. The big caveat is that this 100% stateless desktop is only applicable to a narrow set of use cases.
With network profiles and layering technologies, non-persistent desktops are technically stateful in nature. The desktops retain all the state on the network or on a writable volume. So, is IT scanning all the user profiles for downloaded content? What is the anti-virus and anti-malware policy for such desktops? If the desktop is assembled on-the-fly, with “stateful” user layers, the benefits of stateless desktops do not apply in any security context. Period.
2) Non-persistent desktops with layers simplify management of desktops
The ideal case is that IT is only handling a couple of applications, and the OS image is patched at fixed monthly or quarterly intervals, and the pools have tens of thousands of desktops. Yes, it’s a rosy picture and there are clear benefits in using some sort of 1-N image management in such a case. If your use case is served by one golden image, and the packaging overhead is minimal, then you win the prize!
However, if the company has hundreds or thousands of applications that are updated frequently or the company has strict requirements to handle critical patches, having two separate processes of dealing with physical PCs and VDI is not simplifying anything from the CIO’s perspective. How many base images are required? Is application layering mandatory to reduce the number of golden images? Do you want to support user installed apps? Who do you call when an application crashes? What kind of apps cannot be packaged in a layer – what about the vendor’s guest agent itself?
Application virtualization techniques such as isolation and layering are touted as the next-gen means of “simplifying desktop management”. How many consoles are required to implement non-persistent pools with application layers, UEM and profiles? How many databases and load balancers are required to deploy the first desktop pool? What changes are required when you have to deploy desktops at a new global site? How many desktops should be in the pool and how many apps need to be packaged before a company will see real benefits? It’s important to double click and review the steps required to get to the first desktop!
Marketing stories around instant-clones and just-in-time desktops trivialize the amount of effort required to “package” and “test” applications for compatibility. Have you asked about the performance overhead associated with application layering? Layers are embedded into the images at boot time and in some cases when the user logs in or when the application is launched. Managing the different scenarios is therefore very complex and doesn’t work for physical PCs at all. It is a big investment and if your organization is going 100% VDI, then the effort may provide a good ROI.
Stateless is the Holy Grail! Yes.
But in reality, it’s very hard to achieve truly stateless desktops and the proof points are not there. For most customers with limited IT staff, it provides diminishing returns if every application in the company has to be converted to a new format and expensive consultants are required to implement “user layers”. Will the application layers packaged in a proprietary disk format work in the cloud or a different hypervisor in the future?
3) Non-persistent desktops improve storage performance
Storage was the first big bottleneck for VDI adoption in the datacenter market. Various vendors introduced non-persistent desktops using linked-clones with a shared base OS disk to make sure that the read performance/boot storms are addressed with heavy caching on every host in the cluster.
With modern cloud architectures, every VM is guaranteed enough read/write IOPS to handle all sorts of IO storms. Thin or shadow clones have made linked-clones completely redundant. With all-flash arrays and widespread adoption of hyper-convergence and modern per-host caching in hypervisors, storage is not considered a bottleneck anymore. In summary, the storage performance was a valid argument in 2012 for adopting non-persistent desktops, but it is not applicable anymore from a storage perspective. Period.
4) Non-persistent desktops will result in lower cloud costs
The idea that shared infrastructure can be used to lower the costs is similar to the storage performance argument. Most modern hypervisors don’t use linked-clones under the hoods these days. “Shadow Clones” and “Deduplication” is available even for full-clones out of the box. Cloud vendors don’t provide different pricing for persistent and non-persistent desktops. Licensing for Windows 10 is also based on named users.
There is no one-size fits all. The simplest mode is persistent desktops in the cloud!
If you’d like non-persistent desktops, Azure desktops with UPDs provide the simplest personalization solution.
With Microsoft 365, and the secular adoption of “Windows as a Service” in the industry, we assert that the adoption of non-persistent desktops will decrease over the next five years for VDI and DaaS deployments. Most customers will buy a persistent “Virtual Surface PC” from Workspot on Azure, or a persistent “Virtual Desktop” from one of the cloud vendors, managed by Microsoft Intune.
80% of the use-cases can be solved using persistent desktops!
The notion of packaging every application in a separate layer and maintaining separate processes for patching physical PCs and virtual desktops has led to high IT overheads. Application virtualization was once promised as a panacea in the industry and despite a lot of promise it never achieved mainstream adoption. It is not used for 100% of the applications. Application layering is on the same path. Maintaining separate processes and IT staff for VDI functions has become a big problem for CIOs.
Wisdom is discovered by removing the unnecessary and looking beyond the short term buzzwords.
Only large companies with specialist IT staff can do a good job of acquiring the right skills and expertise to truly maintain personalized “stateless desktops” with layering technologies. So when should customers use non-persistent desktops in the cloud?
We believe that non-persistent desktops should be used extensively for emerging DaaS use-cases like Disaster Recovery (DR) and Highly-Available or Multi-site Deployments where IT wants to buy insurance against cloud downtime and natural disasters. In such cases, the burden of doing the heavy lifting to maintain profiles and file shares replication across sites will be delegated to the DaaS vendor.
Migration from Exchange (which required specialized IT skills) to Office 365 (dramatically simplified for IT!) is a perfect example in recent history that explains why CIOs are moving from VDI to DaaS. Please spend some time with the customer success representatives at your favorite DaaS vendor to help you decide between persistent and non-persistent desktops, and to ask all the hard questions so you get the solution that is best for your organization.