10 minutes
An employee reports that logging in is slow. You ask when it happens and are told: “Sometimes. Usually in the morning.” If you ask which application is affected, the answer is: “Pretty much everything.” Of course, when you’re there yourself, it works just fine.
Anyone who manages a remote workstation based on Citrix, RDS, or Parallels is familiar with this pattern. A malfunction has a beginning and an end. Slow performance doesn’t. It creeps in, gradually gets worse, and only comes to light when it becomes truly unworkable. By that point, months of changes, updates, and enhancements have piled up on top of it, and there’s no longer a starting point to fall back on.
Troubleshooting performance issues is therefore like peeling an onion. You peel away layer by layer; you rarely find the culprit right away, and it’s only after removing several layers that you see how the small details come together to create the problem. That takes time. In this article, you’ll learn why that’s the case, which layers to peel back, what metrics to track to find the issue faster next time, and how to prevent a lurking problem from costing you days of production time.
Why does it take longer to fix slowness than to fix a system failure?
A system failure and a performance issue may seem similar, but they behave completely differently. That difference determines how long your investigation will take.
A system failure
- Has a clear point in time when it started
- Does it display an error message or a log entry?
- Is reproducible—you can demonstrate it to someone
- Usually affects everyone at the same time, so escalation happens automatically
- Often has a single cause
Inertia
- Has no beginning; it developed gradually
- Does not generate an error message; technically, everything works
- Cannot be reproduced on demand
- Varies by user, location, and time of day
- Almost never has a single cause, but rather a combination of minor anomalies
That last point is where most of the time is spent. You’ll find a timeout that occurs just a little too often, a driver that’s a version behind, or a share that responds more slowly than the rest. Each detail on its own is too minor to raise a red flag. Only when you compare them side by side do you see the pattern, and it turns out that one or two are the real culprits.
What happens when each department looks only at its own dashboard?
At a client where I spent weeks investigating such a report, the following happened. The network administrators saw no saturation and pointed to the storage team. The storage team showed latency that was well within the norm and pointed to the virtualization administrators. They saw plenty of free memory and CPU and pointed to the image.
All three were right. Within their own metrics, everything looked fine. But no one was looking at the part in between—and that’s exactly where the problem lay. Each department peeled back one layer and passed the onion on to the next.
This isn’t a matter of unwillingness. It’s a consequence of how responsibilities are divided. As long as no one is tasked with examining the entire chain, that cycle will keep turning, and no one will peel through it. In organizations with multiple suppliers, the effect is even stronger, because each party also has a commercial interest in proving that it isn’t their fault.
What risks do you face if this inertia persists?
Inertia feels like an inconvenience, not a risk. In practice, it costs more than most organizations realize.
Direct loss of production
A study by Markteffect, commissioned by Sharp, shows that nearly a quarter of Dutch workers spend at least 15 minutes a day dealing with IT problems, with slow systems and network connections being the biggest annoyance. The average loss amounts to just over six euros per employee per day, which adds up to billions annually. Source: ICT Magazine.
Do the math for your own organization. Fifteen minutes a day for fifty employees adds up to more than twelve hours of lost productivity per day. That’s one full-time employee who isn’t contributing anything, day after day, without anyone even creating a ticket.
Reports That Never Come In
A survey by SPS of more than 1,000 Dutch employees revealed that 91 percent experience IT problems at the office and that slow software response times are the biggest annoyance. A quarter spend more than an hour per week dealing with IT problems. Source: HR Praktijk.
The problem is that this time rarely gets recorded in your ticketing system. People grab coffee while logging in, start up their applications in advance during their coffee break, and accept this as just the way things are. As a result, your service desk sees only a fraction of what’s actually going on.
Wrong Investment Decisions
If you don’t know where the time is going, buying more resources is the most tempting solution: more memory, faster storage, additional hosts. Sometimes that helps. More often than not, though, you’re just shifting the problem and have made an investment that doesn’t address the root cause.
Users who seek their own solutions
When the remote workstation becomes too slow, people start finding ways around it. They save files locally, use private cloud services, or email files to their personal addresses. As a result, a performance issue quietly turns into a security and compliance problem.
How do you troubleshoot a performance issue layer by layer?
I always work from the user backward. That’s the only logical order, because that’s where the complaint originates. You’ll encounter these layers in a remote work environment:
- The endpoint: the laptop, thin client, or tablet, including drivers, local security software, and the client version
- The connection: bandwidth, latency, packet loss, Wi-Fi versus wired, remote work connections
- The access layer: gateway, load balancer, authentication, and multi-factor authentication
- The login process: profile, group policies, logon scripts, drive mappings, printers
- The session itself: image, installed applications, agents, antivirus, power management
- The hosts: CPU ready time, memory overcommitment, workload placement
- Storage: latency, IOPS, snapshots, background tasks such as backups
- The backend: file servers, databases, application servers, license servers
With each layer, you rule out possibilities and note what stands out. It feels like you’re at a standstill, but that’s exactly what the work entails. It’s also why a thorough analysis can take days or even weeks when nothing has been measured. You’re then reconstructing a situation that occurred months ago.
What do you need to measure to identify trends rather than isolated incidents?
Measuring only after complaints have already been received yields a number without any point of comparison. You’ll know, for example, that a login takes sixty-five seconds, but you won’t know if that’s abnormal. Without a baseline, you’re groping in the dark.
What you need is systematic measurement across the entire chain, recorded daily. Consider:
- Logon duration, broken down by step so you can see which part is taking the most time
- Application launch times by application
- Session latency to the user
- Network latency and packet loss between the key points in the chain
- Response times to databases and file servers
- Storage latency and IOPS, including during backup windows
- Profile size and its growth over time
- Host load, including CPU ready time
The value lies not in the individual numbers, but in the trend. A login rate that gradually increases over six months is not an isolated incident but a shift. You can take action on that before users start complaining.
If you only measure one layer, you’ll miss exactly where things go wrong. A small change somewhere in the chain can have major consequences further down the line. A few extra milliseconds of latency on a database connection won’t show up on any graph, but with thousands of queries per session, that adds up to minutes of wait time on the user side. You can only see that connection if you measure the chain as a whole.
What are the common objections to structural monitoring?
“Our vendor already monitors it”
That’s usually true, but it’s limited to the availability of servers and services. Green means the machine is running, not that the user is up and running within thirty seconds. Ask your provider to show you last month’s logon duration.
That’s just another tool that no one looks at
A valid point. A dashboard without an owner is a waste. So agree on who will spend five minutes reviewing it weekly and what threshold warrants a discussion. Without that agreement, you’re better off skipping the monitoring altogether.
We’re too small for this kind of monitoring
It’s the scale—not the need—that primarily determines the tools you need. With thirty users, you can already gain a lot of insight using the built-in tools in your platform, supplemented by periodic measurements. Compare the cost of that to weeks of searching and days of lost production.
No one is complaining, so everything must be fine
That’s the most dangerous assumption. People report an app that crashes, but they don’t report a login that takes a minute longer. Silence in your ticket system doesn’t mean it’s fast.
We’re moving to the cloud anyway
A migration changes the chain, but it doesn’t make it disappear. Latency, profile processing, application startup, and backend response still exist and sometimes even become more sensitive. Without a baseline, you won’t know after the migration whether things have gotten better or worse.
What checklist do you follow when slowness is reported?
Follow these steps as soon as the first report comes in—don’t wait until it escalates.
- Record who reports the issue, at what time of day, from which location, and on which device
- Ask about the specifics: Is the login process slow, a specific application, or everything?
- Check if this is happening for multiple users; actively asking always yields better results than waiting
- Check for any recent changes, updates, or new features, and compare them against the timeline
- Measure the login duration at each step for a test user at the same time the complaint was reported
- Walk through the layers from the user to the backend, and note anything that stands out at each layer—even the small details
- Compare the findings side by side and look for the cumulative effect rather than a single cause
- After implementing the solution, set up a measurement so you’ll have a starting point next time
What are the benefits of a health check for your Citrix, RDS, or Parallels environment?
New Yard specializes in the digital workplace for small and medium-sized businesses. I personally conduct health checks on Citrix, RDS, and Parallels environments, visit clients on-site, and—in addition to providing advice—handle licensing and implementation. This means that any issues identified don’t just remain in a report—they can actually be resolved.
During a health check like this, I examine the architecture of the environment, the design of the login process, the load on the hosts and storage, the configuration of profiles and policies, and the versions and lifespans of the components. You’ll then receive an overview of what’s working well, what needs attention, and where the risks lie. If you do this annually, you’ll naturally build up a history and be able to anticipate changes rather than reacting to them after the fact.
How do you know if your environment is ready?
If you can’t tell right now how long the average login took last month, you don’t have a baseline. In that case, the question isn’t whether you’ll end up spending weeks searching for a solution—it’s when.
There’s another reason to look into this now. Many SMBs are running on versions of Citrix, RDS, or Parallels that are nearing the end of their support lifecycle, and migrating without prior measurement data is a gamble. You won’t know afterward whether the new environment performs better than the old one.
Schedule a no-obligation introductory meeting at newyard.nl. We’ll take a look at your environment together, and I’ll explain what I would measure and what a health check can do for you. No obligations, no sales pitch.