We're running three RDS session hosts with FSLogix profiles stored on an SMB share. Each host runs Windows Server 2025 with 20 vCPUs and 96 GB of RAM, serving roughly 12–15 concurrent users. Outlook is in Cached Exchange Mode, and one host has an NVIDIA Tesla T4 for GPU acceleration.
The monitoring data looks excellent: CPU and memory usage are low, GPU utilization is minimal, storage latency and IOPS look healthy, and SMB/profile-share latency is generally below 1 ms over a 10 Gbit network. Despite that, users report sluggish applications, sticky-feeling Explorer and Outlook windows, and generally choppy sessions.
Our older Windows Server 2022 hosts often feel noticeably faster, even with more users. The 2022 environment does not use FSLogix, while the new hosts do. The hosts run as virtual machines on Proxmox 9, with storage on an SSD RAID 5 system. We have already excluded the profile share and recommended file types from our antivirus configuration.
Could FSLogix, antivirus/EDR inspection, virtualization, or a subtle source of intermittent latency explain this kind of behavior? What tests helped you identify the cause when normal performance counters looked fine?
4 Answers
The hypervisor and VM configuration are worth checking too. On Proxmox, compare CPU type, vCPU scheduling, host contention, storage-controller settings, and ballooning or memory pressure between the older and newer guests. A VM can show low guest CPU usage while still waiting on scheduling or storage at the host layer. Look for brief spikes in steal time, ready time, queue depth, or host-level latency rather than relying only on the guest counters.
First, compare users with FSLogix temporarily disabled. If the sessions immediately feel better, you’ve narrowed the issue down considerably. Monitoring averages can hide very short stalls, so a share can report excellent latency while users still experience brief pauses. Also compare the complete FSLogix configuration, profile-container locations, policies, and security exclusions between the 2022 and 2025 hosts rather than only checking the storage metrics.
I’d focus heavily on Defender or the EDR product. Incomplete exclusions can create small delays while profile containers, Office files, search data, or temporary files are being inspected. Make sure the exclusions cover the actual FSLogix processes, container paths, and relevant file extensions according to the vendor guidance. A ProcMon capture during a period of sluggishness may reveal repeated scans, access-denied retries, or a process waiting on a file operation.
ProcMon is especially useful here because it can show individual waits that won’t stand out in a one-minute monitoring interval. I’d capture both a working session and a slow session and compare the file and process activity.
The amount of CPU and RAM is more than enough for that user count, so adding resources probably won’t fix this. I’d also verify pagefile behavior, the vCPU-to-physical-core ratio, and whether the graphics configuration is actually helping the applications involved. Since the older hosts do not use FSLogix, a clean A/B test with the same user, applications, security policy, and session settings would be much more valuable than comparing aggregate utilization.
Testing a few users without FSLogix is next on my list. That should help separate a profile-container issue from a broader Server 2025 or RDS problem.