Blog
Persistent vs non-persistent VDI: key differences explained
Persistent VDI gives every user a dedicated desktop. Non-persistent resets after each session. Learn when to use each, and why most enterprises run both.
Table of Contents
- What is persistent VDI?
- What is non-persistent VDI?
- Persistent vs non-persistent VDI
- Why non-persistent VDI should be your default
- Profile management
- Golden image patching vs per-VM patching
- Security trade-offs
- Cost of storage
- Running a hybrid of persistent and non-persistent VDI
- Managing persistent and non-persistent VDI at scale
Overview
You're rolling out 500 virtual desktops across three departments. The developers need customized environments with persistent toolchains. The contact center agents need standardized sessions that reset every shift. Finance wants to know why you're provisioning twice the storage you actually need.
The answer to all three, usually, is the same. Most users should get non-persistent desktops. A smaller set should get persistent ones. The storage difference between the two is the single biggest cost lever in the decision. This guide explains what persistent and non-persistent virtual desktops are, when each one makes sense, and how to keep both running at scale without blowing the desktop budget.
The choice also maps directly to how Microsoft structures Azure Virtual Desktop, its cloud VDI platform. In Azure Virtual Desktop, Microsoft calls these two models personal host pools (persistent) and pooled host pools (non-persistent). The industry-standard "persistent" and "non-persistent" terms map cleanly onto both.
What is persistent VDI?
Persistent VDI assigns each user a dedicated virtual machine that retains all data, settings, applications, and configurations across sessions. When a user logs off and logs back in the next day, everything is exactly where they left it. Architecturally, this is a 1:1 model. One user maps to one VM.
In Azure Virtual Desktop, a personal host pool is the implementation. Each user is assigned to a specific session host in a 1:1 mapping, and user activities, files, and settings persist on the VM's OS disk after sign-out.
Think of it like assigning a physical laptop to each employee. They install their tools, organize their desktop, and the machine is theirs.
Benefits of persistent VDI
- Personalized user experience. Users retain settings, files, desktop layouts, and application configurations between sessions, with no reconfiguration each time they connect.
- Familiar workflow for IT. Persistent desktops can be managed much like physical machines using Windows Update, Microsoft Configuration Manager, and similar tools.
- Application compatibility. Apps that require local installation, persistent registry keys, or machine-specific licensing work naturally in persistent environments.
- BYOD flexibility. Users on personal devices can connect to their dedicated virtual desktop and pick up exactly where they left off, making persistent a strong fit for BYOD strategies.
- Compliance audit trails. In regulated environments where audit trails must tie user activity to a specific machine, the 1:1 mapping simplifies compliance documentation.
- Administrative privileges. Microsoft's security recommendations call for a personal host pool with a dedicated session host when users require local admin rights, rather than granting those rights on a shared multi-session VM.
Drawbacks of persistent VDI
- Higher storage costs. Every user gets a dedicated OS disk, and user data accumulates over time.
- Configuration drift. Users and admins modify registries, install updates unevenly, and add software, so each desktop diverges from the original image.
- Complex patching. IT must patch each individual VM, often using the same update management tooling required for physical endpoints.
- Backup requirements. Each VM stores unique user data, so a full backup strategy is required. Losing a VM without backup means losing that user's environment.
- Linear scaling overhead. Adding capacity means provisioning entirely new VMs, each with its own OS disk, user assignment, and ongoing management.
- Higher resource consumption. Each user occupies a full VM whether they're actively working or idle.
Persistent VDI use cases
Persistent VDI fits best where users need long-term customization and dedicated compute resources. Common scenarios include:
- Developers and engineers running customized toolchains and IDEs
- Architects and designers using GPU-accelerated applications like AutoCAD or Revit
- Clinicians accessing electronic medical record systems that require persistent local state (see healthcare-specific virtual desktop guidance)
- Financial analysts working with complex spreadsheet models and proprietary trading platforms
- Users in regulated BYOD organizations who need a consistent environment across devices
What is non-persistent VDI?
Non-persistent VDI delivers standardized virtual desktops from a shared golden image. When a user logs off, their session resets to the default state. The next time they connect, they may land on a different VM entirely, and it will look identical to any other session in the pool.
This is a many-to-one architecture. Many users share a common desktop image, and no single VM is assigned to any individual.
In Azure Virtual Desktop, this is a pooled host pool. User sessions are load-balanced across available session hosts using either breadth-first or depth-first algorithms. User profiles and critical data are persisted outside the VM using external storage, typically FSLogix.
Think of it like a hotel room. You check in, use the room, and check out. The next guest gets a freshly prepared room from the same template.
Benefits of non-persistent VDI
- Simplified management. Updates and patches are applied to a single golden image. When the image is updated, IT redeploys session hosts from the new version.
- Lower storage costs. Without individual OS disks accumulating user data, storage requirements drop significantly.
- Stronger security baseline. A compromised session is eliminated on reboot, returning the VM to a clean state.
- Easier scalability. All VMs are identical and interchangeable, so scaling up means deploying more instances of the same image.
- Multi-session support. Azure Virtual Desktop pooled host pools support Windows Enterprise multi-session, letting multiple users share a single session host simultaneously.
Drawbacks of non-persistent VDI
- Limited personalization without tooling. Out of the box, sessions reset everything. Users lose customizations, cached credentials, and application preferences unless a profile management layer is deployed.
- Application compatibility gaps. Apps that require local installation, persistent registry entries, or machine-specific activation can struggle.
- Profile management dependency. The environment depends on profile management infrastructure (FSLogix for most Azure Virtual Desktop deployments), which adds its own configuration and operational work.
- Shared resource contention. When multiple users share session hosts, a single user running a resource-intensive process can affect the experience for others on the same VM.
Non-persistent VDI use cases
Non-persistent VDI works best for standardized, task-based workflows:
- Contact centers and BPOs (business process outsourcers) with shift-based staffing
- Kiosk deployments for airline check-in, customer self-service, or medical data entry
- Training facilities and student labs where environments must reset between users
- Retail and warehouse task workers running a defined set of applications
- Temporary employees or contractors who need time-bound access without custom environments
Persistent vs non-persistent VDI at a glance
| Factor | Persistent VDI (personal) | Non-persistent VDI (pooled) |
|---|---|---|
| Architecture | 1:1, one user per VM | Many:1, shared golden image |
| User data | Saved on VM OS disk across sessions | Reset after logout; stored externally via FSLogix |
| Personalization | Full customization retained | Standardized; profile tools add personalization |
| Storage | Higher; individual OS disks per user | Lower; shared image with external profile storage |
| Cost | Higher initial and operational costs | Lower; multi-session and shared images reduce spend |
| Management | Complex; per-VM patching and updates | Simplified; update one golden image, redeploy |
| Security posture | Larger attack surface from accumulated state | Stronger baseline; sessions reset to known-clean state |
| Scalability | Scales linearly with management overhead | Scales efficiently with shared resources |
| Boot time | Slower due to accumulated state | Faster from shared template |
| Disaster recovery | Per-VM backup required; failover is complex | Simpler multi-region patterns via Azure-native business continuity and disaster recovery (BCDR) guidance |
Why non-persistent VDI should be your default (and when persistent is worth it)
Pick non-persistent unless you have a reason not to.
Non-persistent VDI is cheaper to run, easier to manage at scale, and more secure out of the box. One golden image gets patched, and every new session inherits the patch. Multi-session puts multiple users on one VM. Storage is shared. Compromised sessions get rebooted away. For the majority of a typical enterprise workforce (task workers, contact center agents, general office staff), non-persistent covers the need without persistent's operational overhead.
Persistent VDI is the right choice when the workload earns it. That means one of four situations. Users need local admin rights and will install their own software. Applications require persistent registry keys or machine-specific licensing. GPU-heavy workloads keep long-lived state (CAD files in progress, render caches, development environments). Or compliance requires per-user-per-machine audit trails. These are real cases. They're also a minority of the typical workforce.
In practice, the split across a 500-desktop rollout usually looks something like 75–85% non-persistent and 15–25% persistent. The enterprise strategy answer is to assume non-persistent as the default, then build the business case when a role genuinely needs persistent.
Making a decision about VDI?
For a closer look at the underlying desktop choice in Azure Virtual Desktop, see when to use session-based vs personal desktops.
How profile management makes non-persistent VDI feel persistent
User experience is usually the biggest objection to non-persistent VDI. If every session resets, how do users keep their settings, favorites, and application state?
FSLogix profile containers are the answer for most Azure Virtual Desktop deployments. FSLogix stores a complete user profile in a single VHD or VHDX container on a network share. At sign-in, the container attaches to the session dynamically, so the user profile appears exactly like a native local profile. At sign-out, it detaches. The next time the user connects to any VM in the pool, the same container mounts again.
A non-persistent session can feel persistent to the user. Outlook cache, OneDrive files, browser favorites, and application preferences follow them from session to session without tying them to a specific VM.
FSLogix comes pre-installed on all Windows Enterprise multi-session images at no additional cost. The IT admin is still responsible for configuring the profile container and picking the right storage backend. Azure Files is the recommended storage for most environments. Azure NetApp Files is the option when ultra-high performance is required.
One caveat worth knowing: FSLogix and App Attach do not currently support hibernation, so personal host pools using FSLogix can't use the hibernation scaling feature.
Golden image patching vs per-VM patching
The patching model changes immediately when you move between persistent and non-persistent VDI. The operational gap between the two is one of the biggest arguments for non-persistent as the default.
For non-persistent VDI, patching is centralized. IT updates the golden image, tests it, and redeploys session hosts from the new version. Every desktop built from the updated image is immediately at the current patch level. Azure Compute Gallery is recommended for production environments, with image versioning and replication across regions.
For persistent VDI, patching mirrors the physical desktop experience. Each VM must be updated individually. Desktops that were offline during a patch cycle need separate remediation. Over time, the fleet of persistent VMs drifts further from a consistent baseline, and catching up gets harder every quarter.
Azure Virtual Desktop provides native options for image versioning and session host redeployment. Citrix and Omnissa (formerly VMware Horizon) document their own golden image workflows. The practical question for teams running these at scale is who owns the day-to-day execution (image creation, version rollback, session host refresh) and whether that work sits in one place or across several Microsoft admin surfaces.
App Attach can simplify application delivery in non-persistent environments. It attaches applications from packages to user sessions dynamically, rather than baking them into the golden image. That reduces image bloat and supports per-user application assignment across host pools.
Security trade-offs between persistent and non-persistent VDI
Persistent and non-persistent VDI create different security trade-offs. Neither one is universally more secure. The right answer depends on the workload and threat model.
Non-persistent environments benefit from ephemeral sessions. A compromised session is eliminated on reboot, returning the VM to a clean state. IT teams maintain one golden image's security baseline instead of patching hundreds or thousands of individual VMs.
Persistent environments carry a larger attack surface because user-specific changes, installed applications, and accumulated state all persist between sessions. Each VM has to be maintained like a physical endpoint. The benefit is that persistent VDI is the right fit when users genuinely need local admin privileges. Microsoft's security recommendations call for a personal host pool in that case rather than admin access on a shared multi-session VM.
Most enterprise security strategies benefit from running non-persistent for the majority of users, with persistent reserved for workloads that specifically require it.
The storage math: why persistent VDI can double your line item
This is the answer to Finance's question.
Persistent VDI stores user data directly on each VM's OS disk. A 500-user persistent deployment means 500 OS disks, each sized for an individual user's working set, each accumulating app installs and user data over time, each requiring its own backup policy for disaster recovery. Microsoft's business continuity and disaster recovery guidance notes that personal VMs can hold user data and need replication and backup to preserve that state. That's real storage, and it's why the line item climbs.
Non-persistent VDI separates compute from user data entirely. The VMs are stateless. Profile data lives on external storage shared across the pool, and the session hosts themselves can use shared golden-image disks or, for stateless workloads, ephemeral OS disks on local VM storage. (Ephemeral OS disks for Azure Virtual Desktop are currently in public preview for pooled host pools with session host configuration. Check current availability and preview limitations before committing to that path.) Across the same 500-user deployment, the storage count drops dramatically. The per-user working state moves off individual OS disks and onto one shared profile storage backend.
If 400 of those 500 users don't need persistent desktops and you provision them non-persistently, the storage line item in Finance's spreadsheet can shrink by 40–60% without changing the end-user experience. That's usually the single largest cost lever in the persistent-vs-non-persistent decision. For a deeper look at the components, see our guide to AVD total cost of ownership.
Know the TCO
This step-by-step wizard tool gives you the total cost of ownership for AVD in your organization.
Running a hybrid of persistent and non-persistent VDI
Most large organizations don't pick one. They run both.
A typical hybrid deployment gives non-persistent pooled desktops to most users (contact center agents, task workers, general office staff) and reserves persistent personal desktops for developers, engineers, and roles that need dedicated compute or long-term customization. The same underlying infrastructure, whether on-premises or in Azure, can support both models at the same time.
When planning a hybrid environment, the key architectural decisions are:
- Picking the right profile management configuration for each pool type
- Sizing storage backends appropriately for the combined workload
- Running separate patching workflows (golden image updates for pooled, per-VM updates for personal)
- Designing BCDR strategies that account for the different failover requirements of each host pool type. Personal desktops don't reassign easily even when the underlying VM is unavailable.
Managing persistent and non-persistent VDI at scale
Running Azure Virtual Desktop host pools at scale means keeping persistent and non-persistent environments straight across several Microsoft admin surfaces. Azure Portal, PowerShell, Microsoft Learn, and more. Golden image workflows, profile management, patching cadences, cost monitoring, and host pool changes all need to stay consistent.
Nerdio Manager is a management layer for Azure Virtual Desktop. It brings host pools, images, profiles, costs, and session host operations into one console, so teams can manage persistent and non-persistent desktops from one place while building on Microsoft-native capabilities.
Two capabilities matter specifically here because they tie back to the decisions above.
First, Nerdio's desktop image lifecycle management is the day-to-day home for golden image work (creation, update, versioning, and redeploy) across both personal and pooled host pools, building on Azure Compute Gallery and the session host update feature. In independent testing by Dr. Tritsch IT Consulting, updating a custom image in Nerdio took 37 seconds and 13 clicks compared to 5 minutes 9 seconds and 146 clicks natively.
Second, Nerdio's patented auto-scaling dynamically scales compute and storage based on real-time usage, powers down idle resources during off-peak hours, and switches OS disk tiers during idle periods. That's the lever that turns the storage math at the top of this article into actual savings on the Azure bill. Independent ESG analysis found enterprise customers can save up to 55% on Azure compute through auto-scaling. Sage, for example, saw 62–65% savings on VM direct costs and grew from 200 to 1,000 customers without adding headcount after deploying Nerdio Manager.
Next steps: persistent vs. non-persistent VDI
If you're sizing a persistent-vs-non-persistent split and want to pressure-test the numbers, start with the free AVD modeler tool or a Nerdio Manager demo to see what Finance's line item looks like under each model.
Frequently asked questions about persistent vs non-persistent VDI
Resources
Learn more about Azure Virtual Desktop