Right-Sizing Windows Session Hosts for a Call Center
A financial services call center has 520 agents in two shifts (300 concurrent peak). They run Windows 10 Enterprise multi-session on 14 AHV VMs, each with 16 vCPU and 64 GB RAM, and FSLogix profile containers on Nutanix Files. Agents use a CRM web app, Office 365, and a softphone. Login times average 95 seconds at shift start, and users report freezes during month-end reporting. CPU ready time is 8-12%, and host memory is 85% utilized. The profile containers are 30 GB each and stored on a single Nutanix Files share. Antivirus scans run at 8:00 AM. The team wants to add more vCPUs to each VM and increase the user density to 50 per host. They ask for a redesign.
1. Identify the likely causes of the slow logons and freezes, and recommend a session-host sizing and density model.
Read the worked answer
The 8-12% CPU ready time is already above a healthy target, and 85% memory utilization leaves little room for month-end spikes. Adding vCPUs and raising density to 50 users per host would worsen contention, not fix it. The 95-second logon is likely driven by FSLogix container attachment on a single busy share, antivirus scanning at shift start, and CPU and memory pressure while the logon stack runs. Right-size rather than overcommit: target CPU ready below 5%, keep memory below 80%, and set density based on measured per-user consumption. For task workers using a browser CRM, Office, and softphone, 25-30 users per 8-12 vCPU host is a more defensible starting point than 50 per 16-vCPU host. Add hosts to preserve N+1 and peak concurrency. Move antivirus scans off the 8:00 AM window and exclude FSLogix container paths.
2. How should FSLogix and the Nutanix Files share be redesigned?
Read the worked answer
A single Nutanix Files share holding 30 GB containers for 520 users is both a performance and operational risk. Separate profile containers from Office container data where appropriate, and distribute workloads across multiple shares or file-server VMs so one share does not absorb all logon I/O. Size capacity for growth, snapshots, and retention rather than only current usage. Configure SMB 3.1, continuous availability, and antivirus exclusions for FSLogix VHDX files. Use FSLogix profile-container size limits and cleanup rules to prevent runaway containers. Monitor share IOPS and latency during shift start, and test logon storms with a pilot group before changing density. If month-end reporting adds load, consider separate pools or priority settings for heavy users rather than mixing them with all agents on the same hosts.
3. What image and logon-acceleration changes would you recommend before increasing user density?
Read the worked answer
Build a lean golden image and update it through a controlled lifecycle. Remove unnecessary startup services and scheduled tasks, optimize the image with a supported optimizer, and keep only the CRM, Office, softphone, and required agents. Use Citrix MCS or Provisioning to stream the image, and pre-cache frequently used applications where supported. Enable FSLogix profile and Office container streaming, and schedule antivirus and update tasks outside shift start. Validate logon time with a load-testing tool that reproduces the 300-user peak, not with a single-user test. Measure CPU ready, memory pressure, storage latency on the FSLogix share, and logon duration before and after changes. Only increase density after the image and profile design meet the target, and keep enough hosts for N+1 and month-end peaks.