No they’re not. In fact, most desktops are persistent, they’re just not virtual. Other industry experts have already had this discussion many times and I think it’s my turn to sound off.
I have to be completely honest, I’m just plain tired of the headache that non-persistent just ends up causing from a management perspective, especially when a group of users is placed in the wrong use case bucket because the proper strategic use-case analysis wasn’t performed in the first place. Sometimes that stateless headache is totally worth it, and other times it isn’t. The concept of deleting a user’s desktop when they log off is noble from a clean and tidy “fresh desktop” configuration standpoint, but it also inherently causes a number of different issues that plenty of customers just can’t seem to get past in the long haul, especially if use case is incorrectly assessed initially. It takes a lot of administrative work to have a near-persistent auto-refreshing desktop experience, so let’s just break this down for a second with some simple pros and cons for each.
Non/Near Persistent Desktops
- Can meet very low RTO/RPO disaster recovery requirements with abstracted user files/app data
- In environments with rolling concurrent session counts it can reduce overall costs
- Will allow for the fastest provisioning of desktops (especially with project Fargo)
- Storage capacity requirements can be reduced because of natively thin desktops
- Logging onto recently refreshed desktops ensure a consistent operating environment
- Fits a large majority of task worker and non-desktop replacement use cases extremely well
- A UEM is required to persist application data and user files, staff must learn and become comfortable with the tool
- Application delivery and updates must (for the most part) be abstracted and delivered and updated quickly. This often times requires additional software and training (App-V, AppVolumes, Thinapp, etc)
- Any appdata problems that persist in the profile completely negate the “fresh desktop” stateless desktop idea
- Does not typically integrate well with traditional desktop management solutions such as SCCM, LANDesk and Altiris
- The smallest configuration change for a single user in a stateless desktop can result in hours of work for the VDI admin
- Applications that require a non-redirected local data cache must be re-cached at each login or painfully synched via the UEM
- Users live on their desktop, not partly on a share and partly in a desktop
- Consistent experience; the smallest changes (including those performed by the helpdesk) unquestionably persist
- Simple to administer, provision and allocate
- Fits all desktop replacement use cases extremely well
- Desktop administrators do not need to introduce new management tools
- The user pretty much never has to be kicked out of their desktop except for reboots required by patches, software installs
- Any disaster recovery requirements will add a lot of complexity, especially without OTV
- Non-metrocluster persistent desktop DR plans typically dictate 2 hour+ RTO for environments at scale
- Persistent is resource overkill for the task worker and occasional use non-desktop replacement use cases
- Can be cost prohibitive for rolling concurrent session counts it can increase overall infrastructure costs to give 1:1
- Year 2 operations can fail to be met; operational “this person left 2 years ago and is still on his desktop” type problems
- Relies on existing application distribution expertise
- Problems in the desktop must be handled with traditional troubleshooting techniques
- Without proper storage infrastructure sizing underneath, simple things like definition updates or a zero day patch can make an entire environment unusable
My big picture take aways:
Perform strategic business level EUC/mobility use case analysis up front. If an optimized method of delivering EUC is realized, select the best combination of desktop and/or server and software virtualization for the business. Once the technology has been selected, do the detailed plan and design for the chosen technology. Don’t slam both the strategic business analysis and the product design together because you need take a good hard look at what you actually need and where you can optimize before you put a blueprint together. As a part of the business use case analysis, ensure to get sign off on the virtual desktop availability and recoverability requirements. The outcome of such an analysis should provide information in regards to which specific departments will have a great outcomes with a virtualized desktop experience and which ones have less or no value.
Are you building an infra that will let you provision virtual desktops with amazing speed and IOPS galore? Great! That’s not the only goal. Make sure it’s merely a dependable component of a solution that is manageable and meets the business requirements.
Going with a non-persistent desktop to save on storage space is ludicrous, especially with the prevalence of high performing storage platforms with block level deduplication available today and the amazing low TCO of HCI.
The idea that a non-persistent desktop is easier to manage because of the available tools is complete nonsense. There are risks and rewards for both choices. For example, there are plenty of medical use cases that are terrific fits for non-persistent desktop because of the lack of personalization and individuality required; most of the time the staff members use kiosks so a generic desktop is nothing new to them. However, take a senior corporate finance officer who has a critical Access 97 database with custom macros and software dependencies that took a VBA consultant 1 year to write, and who also has more manually installed applications his desktop support has ever seen and you’re going to be a sad person if you put then on a non-persistent desktop.
If you ask me, once the DR complexity for persistent desktops is fixed, it will drastically shift the conversation again.
As usual, if there are any pros and cons I forgot, feel free to sound off, argue, high five me, or not.