Why Traditional VDI Support Is Failing and What IT Teams Should Do About It

A technician opens a ServiceNow incident. The employee on the other end is locked out of an application, losing work, and waiting. The technician tries to launch a remote session on the virtual desktop, and the agent is not there. The non-persistent pool refreshed overnight. The VM started clean. The ticket is open, the clock is running, and there is no way in.

This is not a one-off. IT teams running VDI solutions at enterprise scale hit this wall with enough regularity that it has stopped being a surprise and started being an accepted frustration, absorbed into the noise of daily operations rather than traced back to its actual cause. The agent disappeared because VDI's architecture made it disappear, and the remote support tool was never built to handle that.

The gap between what legacy remote support tools were designed to do and what modern VDI environments actually require has been widening for years. It widened quietly while organisations ran persistent VDI, where the failure mode is slower and less obvious. It widened faster as non-persistent pools became the preferred deployment model for cost and manageability reasons. It is widening fastest right now, in 2026, as organisations migrate from on-premises VDI to cloud-native infrastructure and carry their support tooling assumptions with them unchanged. The support layer has not caught up, and the cost of that mismatch lands directly in the incident queue, in the ServiceNow data layer, and in every AI-assisted workflow that depends on clean resolution data to function.

Why Non-Persistent VDI Breaks Agent-Based Remote Support

Non-persistent VDI is built around one core guarantee: every user who logs in gets a clean, controlled environment. The mechanism that enforces it is the pool refresh. Every VM reverts to its golden image, the approved snapshot with the OS, applications, and configurations locked in. Anything installed or written during a user session is discarded. This is the feature, not a flaw.

The problem is that remote support tools built on a persistent-agent model treat virtual desktops exactly the way they treat physical machines. They assume a pre-installed agent is sitting on the endpoint, listening for connection requests, available whenever a technician needs to initiate a session. On physical desktops, that assumption holds. On persistent virtual desktops, it holds most of the time. On non-persistent session hosts, it fails on a schedule: every pool refresh, automatically.

TeamViewer, Bomgar/BeyondTrust, and ScreenConnect all operate on this same foundational assumption. The agent is the entry point. Without it, there is no session.

When the pool refreshes and the golden image is restored:

• The agent installed during a previous session is gone
• The VM is reachable and the employee can log in
• The technician finds nothing to connect to

This is not a misconfiguration and it is not a VDI configuration error a helpdesk engineer can fix. It is the predictable output of a persistent-agent architecture meeting a stateless session host. This is the agent orphan: a VM that is reachable, running, and occupied by an employee with an open ticket, with no agent for a technician to connect to.

The Security Case Against Persistent Agents

The architectural weakness is not limited to VDI connectivity failures. Bomgar/BeyondTrust's persistent-agent model is the same attack surface that enabled the December 2024 breach of the U.S. Treasury Department, where state-linked threat group Silk Typhoon exploited a command injection vulnerability in BeyondTrust Remote Support to access workstations and unclassified documents. The same underlying vulnerability class resurfaced as CVE-2026-1731 in February 2026, with active exploitation observed across self-hosted Bomgar appliances, with attackers using the compromised agent process to create domain admin accounts and move laterally across enterprise networks.

The persistent endpoint agent is not just an operational liability in VDI environments. It is a standing attack surface. Organisations running TeamViewer, Bomgar, or ScreenConnect on their VDI infrastructure carry both risks simultaneously: the session failure that happens at every pool refresh, and the vulnerability exposure that comes with maintaining a persistent agent footprint across the endpoint estate.

How a Failed Session Corrupts the ServiceNow Data Layer

The failure does not stop at the failed connection attempt. It propagates directly into the ServiceNow incident record and into every AI workflow that depends on it.

• The technician cannot launch a session from inside the ServiceNow incident record. The resolution path degrades to escalation, a phone call, or a ticket closed with a note that explains the connection failed but not what the underlying problem was.
• Now Assist ingests that incomplete data. Knowledge articles either go unwritten or get drafted from shallow call notes that substituted for a session that never happened.
• Every orphaned agent produces a ServiceNow incident record that tells the AI layer almost nothing useful, and those records accumulate over time into a dataset that actively undermines the value of the Now Assist investment the organisation has already made.

Why the Agent Problem Is Invisible at Procurement and Costly in Production

The agent failure is almost entirely invisible during evaluation. Pilot testing for remote support tools typically runs against endpoints where the tool is expected to work cleanly: physical desktops, persistent virtual desktops, or endpoints pre-configured to accommodate the agent install.

Non-persistent pool behaviour is rarely included in a pilot scope because the evaluation team is focused on demonstrating connectivity and session quality, not stress-testing against VDI's failure modes. The tool passes procurement. It installs cleanly. Technicians connect without issue. The contract gets signed. Then it goes into production against the full fleet, including non-persistent pools that were never part of the pilot, and the failure mode surfaces.

The question that should have been asked before procurement: does your current remote support tool require a persistent agent install on the endpoint, and what happens to that agent when the endpoint loses its persistent state? That answer, left unasked, is now being supplied by the incident queue.

Why the Root Cause Stays Hidden Until It Is Too Late

The failure surfaces in production as a connectivity issue rather than an architectural one. Technicians see "cannot connect to VM" and try a different approach: call the employee, ask them to restart, try again later. Sometimes it works, because the same VM was assigned from the pool before the next refresh cycle. The pattern looks intermittent, like a network issue or a configuration inconsistency, and by the time someone traces it back to the pool refresh schedule, the assumption that this is a tool problem rather than a VDI problem is already embedded in how the team talks about it.

While diagnosis stalls, ServiceNow accumulates noise:

• Every failed session creates an incident record with incomplete resolution data
• Every ticket that closes with a vague note contributes to a dataset that teaches Now Assist the wrong patterns
• Every knowledge article that goes unwritten because the session never happened is a gap that does not appear in any dashboard but is felt every time a similar issue comes in and the technician has to start from scratch

For organisations that have already invested in Now Assist, or that are building toward AI-powered service management in ServiceNow as a strategic capability, this compounding effect is serious. A remote support model that systematically fails to complete sessions in non-persistent VDI environments is systematically failing to produce the data those AI workflows require.

Persistent VDI Has the Same Problem at a Different Scale

It would be a mistake to read the non-persistent failure mode and conclude that persistent VDI environments are insulated from this problem. They are not. The failure mode is different, quieter, and easier to absorb at small scale, but at enterprise scale it produces the same operational drag through a different mechanism.

In a persistent VDI environment, the agent survives pool refreshes because the VMs retain state. The same user logs back into the same VM; the agent installed during initial setup is still there. This is why persistent VDI does not surface the agent problem during pilot or in the early months of deployment.

Persistent VDI means every VM is a separately managed endpoint, and that creates four compounding problems at enterprise scale:

• Every VM requires its own agent install, its own update cycle, and its own health check
• Endpoint licences accumulate per VM rather than per user, so licensing cost scales with the number of virtual machines, not the number of people being supported
• Update failures leave stale agents on machines that are technically reachable but running outdated software, a security surface that does not announce itself until something goes wrong
• The VM inventory does not map cleanly to ServiceNow's CMDB, introducing its own documentation gap separate from anything the tool itself does wrong

At 500 employees, this is manageable. At 5,000 or 10,000 employees on persistent virtual desktops, it becomes a significant management surface with its own failure modes.

Azure Virtual Desktop Combines Both Problems in the Same Tenant

AVD adds a third scenario that organisations frequently fail to account for when they plan their support model. AVD supports two distinct host pool types simultaneously:

‍

An organisation can have both types in the same tenant, serving different user populations, sometimes within the same team. A remote support tool that handles personal host pools correctly may fail entirely on pooled host pools, and technicians may have no reliable way to identify which type they are dealing with when a ticket comes in. The failure is unpredictable from the technician's perspective and invisible from the employee's perspective until the session attempt fails.

Whether the deployment is persistent VDI, non-persistent VDI, or AVD with mixed host pool types, the conclusion is the same: legacy remote support tools were designed for physical endpoints with fixed identities. VDI removes that fixed identity in different ways at different scales, and the tool that assumes it exists will fail when it does not.

The Remote Support Question That Belongs in Every VDI Migration Review

Most VDI modernisation conversations focus on the access layer: which hypervisor, which connection broker, which cloud platform, which licensing model. The remote support tool enters the conversation late, evaluated on a separate timeline by a separate team, measured against criteria that have nothing to do with the infrastructure decisions it depends on. That sequencing is where the problem embeds itself.

The support tooling inherits the VDI architecture's constraints without anyone having explicitly evaluated whether it can handle them. Every vendor in this space will answer yes to "can your remote support tool handle VDI?" The right question is more specific: does the remote support tool require a persistent agent install on the endpoint, and what happens to that agent when the endpoint loses its persistent state?

The answer to the second part is already determined by the architecture. The agent is gone at the next pool refresh, and the session model that depends on it is gone with it. This question belongs in the VDI architecture review before the migration decision is finalised:

• Migrating from Citrix to AVD does not fix the agent problem; it moves it to a new environment where pooled host pools are the default configuration
• Shifting from persistent to non-persistent pools to reduce infrastructure costs surfaces the agent problem for the first time in environments where it was previously invisible
• Modernising the VDI layer without modernising the support layer carries the broken model into the new environment intact

Why a Browser-Based, Session-Only Model Survives Where Agents Do Not

ScreenMeet addresses the persistent-agent problem at the level where the problem actually lives. The session launches from inside the ServiceNow incident record. The technician's identity and authorisation come from ServiceNow's directory. The employee receives a browser-delivered connection request on their virtual desktop. No agent is pre-installed on the VM. There is nothing on the endpoint for a pool refresh to wipe, because the session model does not depend on anything being on the endpoint in the first place.

The same workflow a technician uses to support a physical desktop works identically to support an employee on a non-persistent virtual desktop in a pooled AVD host pool. The pool refresh schedule, the host pool type, the VM's position in its lifecycle: none of it intersects with the session initiation path.

This model handles all three VDI scenarios through the same mechanism:

• On non-persistent VDI, nothing is installed on the VM, so the refresh cycle has no effect on the support model
• On persistent VDI, there is no per-endpoint licence to manage, no agent inventory to maintain, no update cycle to run against thousands of individually managed virtual machines
• On AVD with mixed host pool types, the browser that receives the connection request is present on every virtual desktop regardless of host pool type, so the support experience is consistent across the entire environment

No Persistent Footprint Means No Agent Vulnerability Surface

ScreenMeet holds SOC 2 Type 2 and ISO 27001 certifications. Because sessions are browser-based and session-only, there is no persistent agent installed on the endpoint. The attack surface that enabled the BeyondTrust Treasury breach and CVE-2026-1731 exploitation does not exist in ScreenMeet's architecture. No agent footprint means no agent to compromise, no standing process to hijack, and no update cycle that leaves stale software on machines across the fleet.

What This Changes for the ServiceNow Data Layer

When the session ends, ScreenMeet AI Session Summary generates a complete session record and writes it back to the ServiceNow incident record automatically. In a non-persistent VDI environment, this is where the architectural difference becomes consequential. The VM that hosted the session will be refreshed and returned to its golden image before the next user logs in. The session record is already in ServiceNow before that happens:

• Resolution notes
• Steps taken during the session
• Issue type and root cause
• Fix applied
• Time to resolution

Knowledge articles can be drafted from it. Trend analysis can include it. Now Assist functions because the data lives in the ServiceNow platform, not on an endpoint that no longer contains any trace of the session.

Every session ScreenMeet completes in a non-persistent VDI environment produces a complete ServiceNow incident record. Every session an agent-based tool fails to initiate produces an incomplete one. Over hundreds of incidents, that difference shapes the quality of every AI output that draws on the incident database.

How to Verify Whether the Problem Is Already in Your Data

The audit is the fastest path to an answer. The evidence is already in ServiceNow:

1. Pull any sample of incidents from the last 90 days that closed with a failed remote session or an escalation that bypassed a remote session entirely.

2. Cross-reference the VMs referenced in those tickets against your non-persistent pool inventory.

3.  If failed sessions cluster around non-persistent pool VMs, the agent problem is already present in your data labeled as a connectivity issue rather than an architectural one.

The fix is not a configuration change, a deployment script, a firewall rule, or a call to vendor support. It is a different tool architecture, one that does not assume the endpoint will maintain a persistent state between sessions. The organisations that avoid this problem going forward are the ones treating the remote support tool as part of the VDI architecture decision, evaluated on the same timeline, against the same architectural constraints, by the same team making the infrastructure call.

The Architecture Decision That Does Not Wait for the Next Migration

VDI modernisation moves fast. Licensing decisions, cloud migrations, and pool configuration changes are being made right now, and in most organisations the remote support tool is not in the room when those decisions happen. It gets inherited, unchanged, by whatever environment the infrastructure team builds next.

The agent orphan problem does not announce itself in the architecture review. It announces itself in the incident queue, weeks or months after go-live, dressed as a connectivity issue that no one traces back to its cause until the pattern is impossible to ignore. By then, the ServiceNow data layer has already absorbed hundreds of incomplete records, Now Assist has been trained on the gaps, and the cost of remediation is higher than the cost of the question that should have been asked at procurement.

ScreenMeet exists at exactly the point where the agent-based model breaks down: the live session that legacy tools cannot initiate, the incident record that never gets written, the Now Assist recommendation that never gets generated because the resolution data does not exist. A browser-based, session-only model running natively inside ServiceNow does not depend on endpoint state, does not require an agent to survive a pool refresh, and does not leave the incident record empty when the VM comes back clean.

The VDI architecture is changing. The remote support layer should change with it, before the next migration confirms what the architecture already implies.

FAQ

1. Why does my remote support tool stop working after a VDI pool refresh?

Non-persistent pools revert every VM to its golden image on refresh. Remote support agents from TeamViewer, Bomgar/BeyondTrust, or ScreenConnect are installed software; they get wiped along with everything else. The VM comes back online, but the agent is gone. These tools were built for physical endpoints where the agent persists indefinitely. Non-persistent VDI removes that persistence by design, on a schedule, every refresh cycle. Reconfiguring the tool does not fix it. The architecture does not support it.

2. Our pilot showed no issues. Why are we hitting failures in production?

Pilots run against physical desktops or persistent VDI where the agent survives normally. Non-persistent pool behaviour is almost never tested before go-live. Failures in production present as intermittent connectivity problems rather than architectural ones, which delays diagnosis. The question that should have been asked before procurement, whether the tool requires a persistent agent and what happens to it at refresh, gets answered instead by the incident queue.

3. Does this only affect non-persistent VDI, or persistent environments too?

Persistent VDI avoids the hard failure but creates its own problem at scale. Every VM becomes a separately managed endpoint with individual installs, update cycles, and per-VM licensing. At 5,000 or 10,000 virtual desktops, the management overhead is substantial and stale agents accumulate quietly. AVD compounds this further: pooled host pools and personal host pools can coexist in the same tenant, making the support experience unpredictable across the same environment.

4. How does this affect our ServiceNow data and Now Assist?

Every failed session closes without a resolution record in ServiceNow: no session log, no documented steps, just a vague note or an escalation. That incomplete data goes into ServiceNow and Now Assist draws on it. At scale, the result is a degraded dataset that limits what AI-powered service management can deliver. The AI layer underperforms not because of how it was configured, but because the support tool upstream of it is consistently failing to produce complete records.

5. What should we look for in a remote support tool built for VDI?

One question covers most of it: does the tool require a persistent agent install on the endpoint? A tool that does will fail on non-persistent VDI regardless of how it is deployed. The model that works across all VDI types is browser-based and session-only: the session authenticates through ServiceNow, the employee connects via browser, and the session log writes back to the ServiceNow incident record automatically. Nothing is installed on the VM, so nothing is lost at refresh.

6. When should the remote support tool enter our VDI migration planning?

Before the migration is finalised, not after. Infrastructure reviews and support tool procurement almost always happen on separate timelines, and the mismatch surfaces in the incident queue after go-live. Moving to AVD, shifting to non-persistent pools, or leaving Citrix or VMware changes the constraints the remote support tool operates under. That question belongs in the architecture review, not the post-go-live retrospective.

‍