Virtual Desktop Infrastructure Explained

A technician opens a ServiceNow incident. The user's VDI session crashed mid-workflow on a non-persistent desktop, reset on logoff, and is now gone. No machine state to inspect. No persistent agent to query. No path from the ticket into the session that caused the problem.

This is not a VDI failure. It is VDI behaving exactly as designed.

VDI was built to centralize compute, lock down data residency, and make endpoints interchangeable. The support session was never part of that design. That gap is structural and cannot be configured away. It has direct consequences for every IT service desk running ServiceNow.

What Virtual Desktop Infrastructure Actually Is

In a VDI environment, a desktop operating system, along with its applications and compute, runs inside a virtual machine hosted in a data center or cloud. The physical device a user holds receives only a display stream.

The endpoint is a screen. The VM behind it is the system IT manages, patches, secures, and diagnoses when something breaks. The endpoint itself does no processing and holds no work data.

Three terms come up repeatedly in VDI conversations, and each describes a different thing:

1. Virtual Desktop Infrastructure (VDI): The organization owns and runs the server infrastructure. VMs live in the organization's data center or private cloud.

2. Desktop as a Service (DaaS): Same virtual desktop model, but a third-party provider runs the backend. Azure Virtual Desktop and Citrix Cloud are the most common examples. If your organization runs VDI on AWS itself, that is still VDI. VDI becomes DaaS when the provider manages the infrastructure for you.

3. Virtual Private Network (VPN): An encrypted tunnel between a device and the corporate network. No desktop virtualization occurs. Processing and data stay on the user's physical machine.

VPN and VDI both enable remote access, which is why they are often discussed together, but the underlying architecture is fundamentally different. A VPN extends network reach to an endpoint. VDI moves the entire computing environment off the endpoint. That difference is what gives VDI its compliance advantages and what makes VDI support harder than most organizations expect before they have deployed it.

Read more to understand full comparison including enterprise browsers 

Persistent vs. Non-Persistent VDI: Why the Distinction Matters for Support

Ask IT professionals why VDI is hard to support and they describe symptoms. Ask which type they are running, and the answer usually explains everything.

Persistent and non-persistent Virtual Desktop Infrastructure are not just two configurations of the same system, from a support perspective, they are entirely different issues -

‍

Persistent VDI behaves like a physical endpoint from a support perspective. A dedicated VM sits at a stable address, holds its state between incidents, and can be inspected after the fact. Support tooling built for physical desktops mostly works here.

Non-persistent VDI breaks all of that deliberately. A user's machine at 10 AM may be a completely different VM by 2 PM. When the session ends and the desktop resets to its golden image, the error logs, the configuration state, and everything a technician needs to understand what happened disappear. There is no stable, individually addressable machine in this model. That is how the model was designed.

That is where support tooling fails. Vendors did not build it badly. They built it assuming a machine persists. In non-persistent VDI, that assumption is false.

Read more about the VDI support bottleneck here

What Virtual Desktop Infrastructure Was Designed to Solve

VDI is not popular because it is easy to manage. It is popular because it solves specific problems that other architectures handle less cleanly.

1. VDI Keeps Sensitive Data Off the Endpoint by Design

In financial services, healthcare, and government, data must stay within a defined boundary. VDI provides a structural guarantee: all processing happens on the server and only a display stream reaches the endpoint. A contractor on a personal laptop in a coffee shop sees pixels. Corporate data stays in the data center. For regulated industries with strict data residency requirements, VDI is often the only architecture that satisfies the requirement without additional compensating controls.

2. One Golden Image Means IT Patches the Fleet by Updating a Single Template

With non-persistent VDI, there is one golden image: a single template containing the OS, approved applications, and the security configuration IT defines. Every non-persistent desktop clones from the golden image at login. IT updates the image once and every user gets the change at their next session. No patching individual endpoints, no chasing machines that were offline during the update window, no configuration drift across a fleet of thousands. For organizations that have managed large physical desktop environments, this operational difference is significant.

3. When Compute Leaves the Endpoint, the Device Itself Stops Mattering

When compute lives in the data center, the physical device stops mattering. Thin clients, hardware the organization would otherwise retire, personal devices employees already own: all deliver the same desktop experience. For organizations trying to extend hardware refresh cycles or onboard contractor workforces without issuing corporate equipment, this is a concrete cost argument.

What VDI Costs: Infrastructure, Latency, and Specialist Skills

1. Infrastructure cost shifts; it does not disappear. Centralizing compute means investing in server hardware, high-performance storage, and network capacity. Storage I/O is a common performance bottleneck in VDI deployments, particularly at scale. The savings on endpoints are partially offset by what the organization spends in the data center.

2. Latency is physics, not a configuration problem. Users connecting from geographically distant locations will notice lag, particularly on graphics-intensive work. Tuning helps at the margins.

3. Troubleshooting the VDI stack requires skills that most desktop support teams do not have. When a hypervisor runs into resource contention or a connection broker fails, diagnosing the problem requires infrastructure knowledge distinct from traditional desktop support. Organizations that deploy VDI without building that expertise feel the gap acutely during their first major incident.

Why the IT Support Gap in VDI Cannot Be Fixed at the VDI Layer

VDI's scope ends at desktop delivery. VDI does not own the support session, the incident lifecycle, or the knowledge a technician generates when resolving a problem. In non-persistent environments, that knowledge exists only while the session is live. When the VM resets, the VM takes that knowledge with it.

The instinct in many organizations is to treat this as a tooling problem: deploy a remote support agent on the VDI image, the same way IT would on a physical endpoint. In non-persistent pools, any agent installed on a VM disappears at logoff. Correlating incidents across sessions becomes unreliable because the machine identifier changes between sessions. The context a technician needs, what the employee was doing, what error appeared, and what the technician had already tried, is gone before the ticket reflects any of it.

This is not a gap VDI can close. The support session was never inside VDI's scope. That layer has to live somewhere else. For ServiceNow shops, it has to live inside ServiceNow.

What launching from the ServiceNow incident record actually changes

ScreenMeet is the resolution layer VDI does not include. ScreenMeet does not run as a disconnected console alongside ServiceNow. It launches directly from inside the incident record, and that changes the operational mechanics of the support session in three specific ways.

1. In non-persistent VDI environments, the third point below matters more than the first two. The window between a session closing and a VM resetting is the only moment session context still exists. Once the VM resets, the evidence is gone — not archived somewhere inconvenient, but gone. The ordering below reflects how IT service desk managers experience these sessions; the note on why the third point is the most consequential in non-persistent environments comes immediately after.

2. The session opens from inside the incident record. The technician initiates the remote session without leaving ServiceNow. ServiceNow's directory supplies the technician's identity. No separate authentication. No switching to a different tool. No context lost between opening the ticket and connecting to the session.

3. Session activity writes back to the ticket automatically as structured data. Actions taken, resolution steps, and session duration are all recorded against the incident. Not entered by a technician into a notes field at the end of a long shift — written back by ScreenMeet the moment the session closes.

4. ScreenMeet's AI Summary converts the session log into knowledge base content before the VM resets. The AI Summary processes what happened during the session and generates KB articles that feed directly into Now Assist. In persistent VDI or physical endpoint environments, a technician can revisit the machine later. In non-persistent VDI, that option does not exist. The session closes, the VM reverts to its golden image, and every trace of what happened during that session disappears from the machine. ScreenMeet captures the knowledge before that window closes.

Where Virtual Desktop Infrastructure Fits in a ServiceNow Environment

Organizations running both VDI and ServiceNow have three layers to manage. Treating those layers as overlapping rather than distinct costs resolution time and destroys institutional knowledge.

The question for ServiceNow shops is not whether VDI is working. The question is whether the remote support layer is a native part of the ServiceNow incident lifecycle or a disconnected system that loses session knowledge the moment the VM resets.

In non-persistent VDI environments, only one of those approaches preserves what the technician just resolved. 

FAQs

1. What is the difference between VDI and a virtual machine?

A virtual machine is the underlying technology: software that emulates a physical computer on shared hardware, with a hypervisor managing the allocation of that hardware across VMs. VDI is the architecture that uses VMs specifically to deliver desktop environments to end users over a network. Every VDI session runs inside a VM, but most VMs, including servers, development environments, and test systems, have nothing to do with desktop delivery.

2. Does Virtual Desktop Infrastructure work well for remote employees?

Yes. Remote access is one of VDI's primary use cases. Employees connect to a data center desktop the same way whether they are in the office, at home, or in a different country. Performance degrades over high-latency connections for graphics-heavy workloads, but standard knowledge work runs well. VDI also sidesteps the BYOD security problem: because the endpoint receives only a display stream, corporate data never touches the personal device.