Virtual Desktop Infrastructure
“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
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
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
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
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
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
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
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
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
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
Organizations that count on us
Mesa Airlines · Haydon Construction · BECU · Bozeman Health
The right fit, not the easiest sale
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.