Virtual Desktop Infrastructure

VDI lives or dies on the architecture.

“It is almost never the product. It is how it was deployed.”

Desktops in your datacentre, with only the screen image travelling — done well. We have seen, rebuilt and modernized a great many VDI estates, and the problem has almost always been the way the thing was designed.

What it is

Virtual Desktop Infrastructure, in plain terms.

The desktop is a workload running in your datacentre. Everything else about VDI follows from that one fact.

Icon

The desktop runs in the datacentre

A full Windows or Linux desktop executes on a host you own, not on the machine in front of the person. Compute and storage sit where you can see them.

Icon

Only the screen image travels

Keystrokes and clicks go one way, pixels come back the other. Nothing of substance crosses the wire, which is why the network matters so much.

Icon

One image, many desktops

Desktops are built from a managed image rather than configured one at a time. Patching moves from an estate-wide exercise to a single change.

Icon

The endpoint stops mattering

A device that holds no data is a device you can lose. Replacing it is a hardware task, not an incident.

The option that decides everything else

Persistent or non-persistent?

This is the first real decision in a VDI design, and it sets your storage bill, your patching model and your support load. Most estates end up running both, for different groups of people.

Persistent

One desktop per person, kept

Best for

Engineers, developers, executives and anyone who installs their own tooling or keeps meaningful local state.

Each user gets a dedicated desktop that survives reboot, exactly as a physical machine would. It is the easiest migration to explain and the one users complain about least.

What you get

  • User-installed applications persist
  • Local customization is kept
  • Closest to the machine people already have
  • Simplest path off physical desktops

The tradeoff

Storage grows with headcount, because every user carries a full disk. Patching happens per desktop, so configuration drift comes back — you have moved the estate, not solved it.

Non-persistent

Built at logon, discarded at logoff

Best for

Task and knowledge workers on a standard application set — clinical workstations, contact centres, shift work, branch staff.

Desktops are created from a golden image each session and thrown away afterwards. Identity and personalization are layered back on at logon, so the user still gets their own environment.

What you get

  • One image to patch, estate-wide
  • Far smaller storage footprint
  • A known-good state every single session
  • Recovery is a reboot, not a rebuild

The tradeoff

It stands or falls on profile management and application layering. Anything not deliberately captured is gone at logoff, and users who install their own software cannot.

Where it runs

Three places to put it.

The persistence decision is about the desktop. This one is about the infrastructure under it, and the two are independent.

On-premises

Your own datacentre

The classic model, and still the right one where data residency is non-negotiable or where you have hardware with life left in it. You own the capacity and the refresh that comes with it.

Hosted

Cloud infrastructure, your control

The same architecture running on cloud compute, so capacity moves without a purchase order. You still own the design, the image and the policy.

Hybrid

Both, deliberately

Steady-state users on-premises and burst, seasonal or project capacity in cloud. Done well it is the cheapest shape; done by accident it is the most complex.

Where VDI actually fails

It is almost never the product.

We have been called in to rebuild a great deal of VDI over the years, and the pattern barely varies: the platform was fine and the architecture under it was not. These are the four decisions that get made wrong.

Icon

Profile management

Decided late, or not at all. If the user’s settings, files and application state do not follow them cleanly, nothing else in the design will save it.

Icon

Storage and IOPS

Sized for the average rather than the morning everybody logs on at once. It is the single most common reason a design that passed its pilot falls over in week one.

Icon

Graphics

GPU treated as an estate-wide question when it is a per-user one. Discovering which people need it after the hardware is bought is an expensive conversation.

Icon

Network and latency

Where users sit relative to the datacentre is an input to the design. The protocol adapts well, but it cannot invent bandwidth or remove distance.

What we see when we are called in

The rebuilds all look the same.

Our team has seen, rebuilt and modernized a lot of VDI estates. The failure is rarely exotic — it is almost always the way the thing was deployed in the first place.

Scaled by multiplication

It was sized for the pilot

Fifty users worked, so the numbers were multiplied by twenty. Concurrency, login storms and storage behaviour do not scale linearly, and the first busy Monday is where everyone finds that out.

One size for everyone

Nobody segmented the users

A single desktop design was built for a workforce that does several different jobs. It ends up over-specified for most people and still wrong for the ones who needed something particular.

Decided at the keyboard

The design was never written down

Choices were made during the build rather than before it. Two years on nobody can say why anything is the way it is, so nothing can be safely changed.

None of these are platform problems, which is why replacing the platform almost never fixes them. A rebuild is an architecture exercise, not a reinstall.

What we see when we are called in

The rebuilds all look the same.

Our team has seen, rebuilt and modernized a lot of VDI estates. The failure is rarely exotic — it is almost always the way the thing was deployed in the first place.

Scaled by multiplication

It was sized for the pilot

Fifty users worked, so the numbers were multiplied by twenty. Concurrency, login storms and storage behaviour do not scale linearly, and the first busy Monday is where everyone finds that out.

One size for everyone

Nobody segmented the users

A single desktop design was built for a workforce that does several different jobs. It ends up over-specified for most people and still wrong for the ones who needed something particular.

Decided at the keyboard

The design was never written down

Choices were made during the build rather than before it. Two years on nobody can say why anything is the way it is, so nothing can be safely changed.

None of these are platform problems, which is why replacing the platform almost never fixes them. A rebuild is an architecture exercise, not a reinstall.

Why organizations choose LKMethod

Desktop delivery is the work we have done longest.

Based in Arizona, LKMethod is an infrastructure architecture and managed services firm. We work in regulated verticals, where a desktop estate that underperforms is a clinical, financial or operational problem before it is an IT one.

We have rebuilt the alternative

A great deal of our VDI work has been fixing somebody else’s deployment. That is where the method came from — it is not a theory about how these go wrong.

Sized from your data, not a calculator

Concurrency, IOPS and application behaviour are measured in your estate before anything is specified. Vendor sizing tools assume an average user who does not work at your company.

Citrix Premier Partner

Deep technical expertise in application and desktop delivery, built over decades rather than quarters. This is the work we have done longest.

Where we work

HealthcareFinancial ServicesAviationConstructionHospitalityEducationGovernment

Organizations that count on us

Mesa Airlines · Haydon Construction · BECU · Bozeman Health

The right fit, not the easiest sale

Building it, or fixing the one you have?

Either conversation starts the same way. Thirty minutes with a solution architect, a look at how your people really work, and an honest view of what the architecture should be.