Questions to Ask When Implementing VDI
For the person scoping a virtual desktop rollout before any hardware or subscription is ordered, whether that is in-house IT or a consultant brought in for the design. The 51 questions run in the order the answers are needed: users and goals first, then applications and devices, desktop design and sizing, network and security, licensing and cost, and last the pilot and go-live. Expect to split them between the project's sponsor, the managers of each user group, your own infrastructure and security teams, and whichever vendor or integrator is quoting.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Users and goals
What problem is VDI meant to solve here, and what would we do if it were not on the table?
Why ask it
Remote work, a hardware refresh, fast onboarding of contractors and keeping data inside the data center each point to a different design. If the sponsor names several, ask which one wins when they pull apart, because the cheapest build and the most locked-down build are rarely the same one.
Which groups of users are in scope, and what does each group do all day?
Why ask it
Push for groups defined by the work: call center agents, engineers, clinicians on shared stations, back-office staff. A headcount by department hides the fact that two people on one team can need very different desktops, and these groups become your desktop pools later.
How many people are signed in at the busiest moment, and when is that moment?
Why ask it
Hosts, and many licenses, are sized on concurrency, not on headcount. Pull the peak from sign-in logs if you can, since managers tend to guess high for their own team and forget where shifts overlap.
Where do people work from: offices, home, client sites, other countries?
Why ask it
Every location is another network path to test. For anyone working abroad, there may also be rules about where data can be displayed or held, so ask the organization's compliance or legal contact how that works there before you promise access.
What will people connect from, and who owns those devices?
Why ask it
Thin clients, repurposed PCs, personal laptops and tablets each carry a different support load. Personal devices also open the question of what may be copied out of the session, which comes up again under Network and security.
Is there a date this has to be live by, and what set that date?
Why ask it
Common causes are an operating system going out of support, a lease on the old PCs running out, an office move or a new site opening, and each leaves a different amount of slack. Work backward from the date with hardware lead times and a pilot that spans a busy period in the plan, then see whether one group could go live first and the others after it.
Who are the contractors, seasonal staff and outside partners, and how fast do they come and go?
Why ask it
Short-term users are often the best case for a virtual desktop and the worst case for a license bought per named person. Last year's joiners and leavers, month by month, let the vendor price the swing instead of the average.
What does a bad day on the current desktops look like, and how often does one happen?
Why ask it
Slow logins, a laptop that died on the road, an application that lives on one machine under a desk: these complaints are the baseline the new desktop will be judged against. Time a login and write down each manager's top three gripes now, while there is still something to compare with.
Which users should stay on a physical PC?
Why ask it
People who work offline, drive lab or shop-floor equipment, or travel where the connection is poor are usually better left alone. Agreeing a written list of exclusions early stops the whole project from being judged by its few hardest cases.
Apps and devices
Can we get a full list of applications for each user group, including the ones IT never installed?
Why ask it
The official list misses spreadsheet macros, browser extensions, tools a department bought on a card and the utility someone downloaded years ago. Run an assessment agent on the existing PCs for a few weeks and compare what it finds with what the managers told you. The gap between the two lists is where the surprises are.
Which applications are licensed to a device, a USB key or a hardware ID?
Why ask it
Software tied to one physical machine may stop working, or stop being permitted, on a desktop that is rebuilt every night. For each one, ask the publisher whether virtual desktop use is allowed and how they count it, and keep the reply.
Which applications will the publisher not support on a virtual or shared desktop?
Why ask it
Running and being supported are separate things. Put the question to each publisher with the exact version and the desktop operating system you plan to use, single-user or multi-session, and move any business-critical application without a clear yes to the front of the pilot.
Which applications need a graphics card, or run badly without one?
Why ask it
CAD, video editing and medical imaging are the obvious ones. Browsers, video calls and office suites lean on graphics acceleration too, so have the assessment tool report GPU use on today's PCs before anyone decides which pools get graphics hardware.
How will applications get onto the desktop: installed in the image, layered, streamed or published on their own?
Why ask it
Each application baked into the image means rebuilding that image whenever it updates, and each one delivered separately means another product to run. Whoever packages applications today will still be doing it afterward, so find out how many hours a month it takes them and put that in the plan.
How will video calls, softphones and headsets behave inside the session?
Why ask it
Real-time audio and video is commonly where people first decide the virtual desktop is worse than the PC they had. Get the vendor to name the calling tools that can hand media off to the local device on the endpoints you own, then try a call with the headsets already on people's desks.
Which peripherals have to work: scanners, signature pads, card readers, label printers, extra monitors?
Why ask it
Get the make and model of each, and walk the floor yourself, because managers forget the device nobody thinks about until it stops. Redirection behaves differently from one class of device to the next, and a single check scanner that will not pass through can keep a whole branch on PCs.
What has to print from the virtual desktop, and where?
Why ask it
Printing needs a small design of its own: drivers, the default printer following the person from desk to desk, and home printers. Test two cases with the managers: someone who moves floors mid-week and someone working at the kitchen table. For the second, check first whether those documents may be printed at home at all.
Which applications keep data or settings on the local drive?
Why ask it
On a pooled desktop, anything written to the local disk is gone at sign-out. These applications need a profile rule, a redirected folder or a persistent desktop, and the reliable way to find them is to watch where they write, since the documentation often does not say.
Design and sizing
Does every group need a whole desktop, or would a few published applications on their existing device be enough?
Why ask it
A group that spends the day in two or three applications may be better served by publishing just those to the PC or tablet they already have, and each group handled that way is one less pool of full desktops to size and maintain. A whole desktop earns its cost where people run many applications side by side, or where the endpoint is a thin client with nothing else on it.
Does each group need a persistent desktop of its own, or can it share pooled desktops that reset?
Why ask it
Pooled desktops are simpler to patch and lighter on storage. Persistent ones keep whatever the user installs and are managed much like PCs. What people install or change for themselves today is the deciding detail, and it usually differs from one group to the next.
Will the desktops run on our own hardware, in a hosted service, or a mix of the two?
Why ask it
Your own hardware means buying capacity up front and running the platform. A hosted desktop service is a recurring bill with less say over the platform. Find out what that bill does while desktops sit idle overnight, and where the applications' data lives, since a desktop a long way from its database feels slow however well it is sized.
Which hypervisor, directory, storage and management tools do we already run, and do the new desktops have to fit them?
Why ask it
Reusing what the team already knows saves training and sometimes licenses, but it also narrows which VDI products are on the list. Record versions and remaining support dates as well as product names, and get a straight answer on whether fitting in is a hard rule or a preference.
How much processor, memory and disk activity does each group really use today?
Why ask it
Measure it on the current PCs across a whole business cycle, month-end included. A vendor's light, medium and heavy user profiles are a fair opening guess, but the design should be signed off on your own figures.
How many users per host does the design assume, and what happens to that number when a host fails?
Why ask it
Ask to see the arithmetic. A design that only fits when every host is healthy has no room for a failure or a maintenance window, so find out how many spare hosts are included and what users would notice while one is out.
What do people do when the VDI platform itself is down?
Why ask it
A broken PC stops one person. A failed broker or storage array can stop everybody at once. The sponsor has to say how long the business can go without desktops, because that figure decides whether a second site belongs in the budget, and until one exists there should be an agreed fallback, even if it is a shelf of spare laptops.
What happens first thing in the morning when everyone signs in together?
Why ask it
Simultaneous logins, a mass restart after patching and scheduled scans all land on shared hardware at once. Check whether desktops are started ahead of the shift, and get the target login time as a number of seconds you can test in the pilot.
What storage sits under the desktops, and what figures was it sized on?
Why ask it
Desktops write to disk constantly and in bursts, so capacity in terabytes tells you little. The sizing should state the input and output rate and the latency assumed per desktop, and whether profiles and user files sit on separate storage from the desktop disks.
How will each person's profile and settings follow them from one desktop to the next?
Why ask it
The profile method has a direct effect on how long sign-in takes. Bring today's profile sizes to the conversation, agree what will be left out of them, and have the vendor show what happens when one person has two sessions open on the same profile.
How will the base image be built, patched and rolled back?
Why ask it
One image can sit behind hundreds of desktops, so a bad update reaches all of them together. You want a named owner for the image, a patch schedule, a test group that gets each version first and a rollback measured in minutes.
What gets backed up, and how would we restore one person's files or desktop?
Why ask it
Pooled desktops can be rebuilt from the image, so what needs protecting is the image itself, the profiles, user files and any persistent desktops. Have the vendor walk through bringing back a single deleted folder and a single corrupted profile, because those are the everyday requests and a full rebuild is the rare one.
Network and security
What bandwidth and latency do the branch offices and home users really get?
Why ask it
Measure at the sites, at a busy hour, instead of reading the figure off the circuit contract. Then ask the vendor what delay and packet loss their display protocol can absorb for your most demanding group, and lay the two sets of numbers side by side.
How will people reach their desktop from outside the company network?
Why ask it
The usual routes are a gateway, a VPN or the provider's own access service. You need to know whether it takes installed client software or works in a browser, and exactly what is exposed to the internet. Bring the security team in for this one, because it is the piece they will want to review before anything else.
What happens to a session when the connection drops?
Why ask it
This matters most for people on Wi-Fi, mobile data or patchy home broadband. Ask how long a disconnected session stays alive, whether unsaved work survives and how reconnecting looks to the user, then pull a network cable during the pilot to check.
Once the desktop moves to the data center, what still sits at the local site?
Why ask it
The desktop ends up next to the servers and far from the branch printer, the local file share and the site's own internet line. Everyone's web browsing now leaves from the data center or the provider's network, so confirm that the internet link, firewall and web filter there can carry it.
What should a virtual desktop be able to reach on the network, and what should it be kept away from?
Why ask it
A branch PC sat outside the server network, while a virtual desktop runs right beside the servers. Decide for each group which systems its desktops may reach and whether one group's desktops can see another's, and treat a pool for contractors the way you would treat a guest network.
How will users sign in, and is a second factor required from outside?
Why ask it
Start with which identity system is the source of truth and whether single sign-on carries through to the applications inside the desktop. If the business relies on smart cards or tap-in badges, test those early. A second password prompt inside the desktop is the kind of small thing users bring up on day one.
What may pass between the user's device and the virtual desktop: clipboard, files, USB drives, printing?
Why ask it
This is a decision for whoever owns the data, not a default for IT to pick. Take the channels one at a time for each group, since a contractor on a personal laptop and a finance clerk on a thin client warrant different answers.
Which regulations, contracts or audit requirements apply to these desktops and the data shown on them?
Why ask it
Have the compliance lead name them and say what evidence an auditor would expect, such as session logs or proof of where the desktops are hosted. Requirements differ by industry and by location, so take the answer from the people accountable for it there and not from a vendor's checklist.
How will the desktops be protected and monitored without slowing down every host?
Why ask it
Endpoint protection designed for separate PCs can start scanning every desktop on a host in the same minute. The security team should confirm whether their tool has a mode for virtual desktops, the VDI vendor should supply its recommended exclusions, and the two need to agree on one list.
Licensing and cost
Do our current operating system and office software agreements cover running them on virtual desktops?
Why ask it
Rights to run a desktop operating system virtually, and office applications on shared machines, are often separate from the rights that came with the PCs, and they can change again when someone else hosts the desktops. Ask your licensing reseller to confirm in writing against your actual agreement.
How is the VDI software itself licensed: per named user, per concurrent user, per device or per host?
Why ask it
Set your peak concurrency figure against each model the vendor offers. Then ask which pieces are in the edition quoted and which are extra, since monitoring, application delivery and profile tools are frequently sold a tier up.
Which parts will the vendor or integrator build, and which are left to our own teams?
Why ask it
A virtual desktop touches servers, storage, networking, identity, the desktop image and application packaging, and quotes often cover only some of those. Go down that list with the vendor and write a name beside each item. The ones with no name are the gaps in the plan.
How much growth is built in, and what does the next hundred users cost?
Why ask it
Acquisitions and seasonal hiring rarely arrive in neat increments. What you want from the vendor is the step costs: the user count at which another host, another storage shelf or a higher license band becomes necessary.
What does one desktop cost per month over the life of the platform, with everything counted?
Why ask it
Everything means hosts, storage, graphics hardware, every license, the endpoint devices, network upgrades, support contracts and the staff time to run it. Put that beside what a managed PC costs today. If nobody knows that second number, working it out is the first job.
Pilot and go-live
Who is in the pilot, and does it include the hardest users as well as the friendly ones?
Why ask it
A pilot made up of IT staff tells you very little. Include a skeptic from each group, someone at the site with the worst connection and whoever runs the heaviest application, and keep it going through a month-end or another peak.
What will the pilot measure, and what result means we stop?
Why ask it
Agree on the numbers beforehand: login time, application launch time, call quality, tickets per user and a simple rating from the users themselves. Set the failing score with the sponsor before the pilot begins, since it is much harder to call a halt once the hardware has been paid for.
In what order will groups move across, and can someone go back to their PC if it goes badly?
Why ask it
Starting with the group that has the simplest applications and the most to gain builds confidence and a set of fixes for the harder groups. Keep the old PCs for a fixed period, and decide in advance who can authorize a move back.
Who supports the desktops after go-live, and what do they have to learn first?
Why ask it
The service desk needs new skills: shadowing a session, resetting a desktop, telling a network fault from an overloaded host. Settle whether the desktop team or the server team owns the platform, or tickets will bounce between them.
How will we spot a slow desktop before the user calls?
Why ask it
Look for monitoring that records login duration, session delay and host load for each user. Someone has to be named to watch it, and it should be able to pull up one person's session from yesterday afternoon, which is when the complaint usually refers to.
What do users need to be told and shown before their first day on it?
Why ask it
Where files are saved, why a USB stick may be blocked, how to reconnect after a drop and how it works from home. Managers know which of those will upset their team most, so ask them, and put that item first on the one-page handout.
What happens to the old PCs, and what will the endpoints be three years from now?
Why ask it
Turning existing PCs into thin clients puts off a purchase, but they still need patching and will still wear out. Settle who manages the operating system on the endpoints and whether their replacement is in the budget, since that line is easy to leave out of a business case built around the data center.
Running a VDI requirements round
Practical guidance for the conversation itself
Who gets which questions
The business sponsor
Take the sponsor the opening question and the go-live date from Users and goals, the outage question in Design and sizing, the cost-per-desktop question and the pilot's stop criteria. Sponsors answer in outcomes and money, so leave the host counts out and come away with priorities, a tolerance for downtime and a budget that includes the endpoints.
The users' managers
Managers know the working day: shift patterns, the odd device on the counter, the application only two people can operate. Meet them group by group with most of Users and goals and the peripherals, printing and video call questions from Apps and devices, and ask to sit beside a user for an hour, since what you see will correct what you were told.
The vendor or integrator
Design and sizing, the protocol and remote access questions and all of Licensing and cost belong here. Send the measured figures ahead of the meeting and ask for the sizing arithmetic in writing, so that a later change in user numbers can be traced through to hosts and cost.
Your own infrastructure and security teams
Storage, network, identity and security staff will have to run what gets built, and each can veto it late if they first hear of it at design sign-off. Give them the Network and security group and the image, profile, backup and monitoring questions early, and record who owns each answer.
What to measure before the sizing meeting
Usage on the PCs people have now
An assessment agent left on a sample of machines from every user group for a few weeks gives you processor, memory, disk and graphics use, plus the list of what actually runs. Make sure the window takes in a busy period such as month-end, or the design will be built around a quiet fortnight.
Sign-in peaks
Directory or remote access logs will show how many people are signed in hour by hour. Chart a normal week and the busiest week of the year for each group, and hand the vendor the peaks, not the averages.
Network readings from the real sites
Test bandwidth, delay and packet loss from each branch and from a few home connections at a busy time of day. One poorly connected site is better found on a spreadsheet than in the second week of the rollout.
The license paperwork
Collect the current agreements for the operating system, the office suite and every application on the inventory before the licensing conversation. The reseller or publisher can only confirm what is covered against the documents, and their answer should come back in writing.
Turning the answers into a requirements document
One page per user group
For each group, record the number of people, peak concurrency, locations, endpoint devices, applications, peripherals, whether the desktop is pooled or persistent, and what may be copied in or out. A design that cannot be traced back to these pages is a guess.
Numbers in place of adjectives
Fast logins and good call quality cannot be tested. A login under an agreed number of seconds at the Monday peak can, and so can a video call that holds up from the weakest branch. Wherever an answer came back as an adjective, go back and ask for the figure.
A decision log with names
Clipboard policy, the list of users left on PCs, the pilot's failing score and the fallback period are decisions, and someone outside IT should own most of them. Note who decided and on what date, because these are the points that get reopened three months in.
Where VDI requirements go wrong
Sizing on headcount or on averages
Headcount oversizes a shift-based workforce and averages undersize the nine o'clock rush. Concurrency at the peak, measured per group, is the figure the hosts and many of the licenses hang on.
Treating every user as the same desktop
A single pool for the whole organization is easy to draw and hard to live with. The engineer, the call center agent and the traveling manager want different resources, applications and policies, and the differences are cheaper to design in than to bolt on.
Leaving the applications until after the hardware is ordered
One unsupported or dongle-bound application can change the choice between pooled and persistent desktops, or between single-user and shared hosts. Finish the inventory and the publisher checks before the sizing is fixed.
Promising savings before the costs are counted
Virtual desktops tend to move spending from the desk to the data center or to a monthly bill, and whether the total falls depends on licenses, endpoints and the staff needed to run the platform. Hold any savings claim until the per-desktop figure has been worked out both ways.
A pilot that cannot fail
If the pilot group is hand-picked, the measures are vague and nobody has agreed what a bad result looks like, the pilot will pass and the rollout will find the problems instead. Write the failing conditions down while stopping is still cheap.