Slow logons on Profile Management, 38 Citrix policies, and a new FSLogix requirement

What the evidence already tells you. The delay sits in profile load and folder redirection, the average profile is 1.8 GB with a 12 GB tail, 22 redirected folders point at the same share, and antivirus reads the same files at logon. That combination explains 90-140 seconds without any further mystery: logon is performing tens of thousands of small SMB operations while a scanner opens each file.

Measure before changing:

• Breakdown from Director's logon duration for the p50 and p95 user; confirm which component dominates at peak versus off-peak.
• Profile size distribution by user and department, to identify the tail population; the top 5% of profiles usually drive most tickets.
• Share IOPS and latency sampled during the 09:00 window, not averaged over the day.

Remediate, in order:

1. Enable Profile Management's streaming so files are fetched on access rather than at logon, and review the streaming exclusion list and folder-streaming setting together - streaming changes behaviour and needs a pilot.
2. Split the load: put redirected folders on their own share (or DFS namespace target) away from profile containers, and enable access-based enumeration.
3. Add antivirus exclusions for the profile share, the Profile Management directories and the VDA paths, and move the logon-time scan out of the logon path entirely.
4. Address the tail explicitly: users with multi-gigabyte profiles are poor candidates for roaming profiles; give them persistent machines or container-based profiles rather than trying to optimise a 12 GB profile.
5. Check active write-back, and measure logoff as well as logon - a fast logon that hides a 3-minute logoff is not a fix.

Target: p95 logon under 30 seconds in the 09:00 window, verified over a full week, not a one-off test.

Scope the split precisely. FSLogix Office 365 containers capture Outlook cached mode data, OneDrive and Teams data inside a VHD(X) mounted at logon. Everything else - the rest of AppData, desktop, documents and the redirected folders - stays with Profile Management. That is a supported, commonly used combination, but only if neither technology captures the same path.

Configuration rules:

• Exclude from Profile Management every folder the container owns: the Outlook and Office cache locations, OneDrive, Teams and the Office file cache. Add them to the Profile Management directory exclusion list and remove any folder redirection that points at them.
• Do not redirect OneDrive or Outlook cache to the profile share "just in case" - double capture is the classic cause of corrupted OSTs and 10-minute logons.
• Put the containers on the approved second share, not the profile share. Different access pattern, different IOPS profile, different backup requirement. Size the VHD(X) with room to expand and choose a container size policy that does not silently truncate.
• Set the container volume wait timeout deliberately, and decide the behaviour when the container is unavailable - failing the logon with a clear message is usually better than starting Outlook with a fresh OST that will be thrown away.
• Keep the FSLogix agent version and GPO settings under the same change control as the Profile Management ADMX; both are per-machine drivers and a mismatch across a mixed VDA estate produces user-specific faults that are hard to reproduce.

Validate with real behaviour, not a smoke test: log in a pilot user, confirm the OST and OneDrive data land in the container and are absent from the Profile Management profile, measure logon and logoff at peak, and test search, Outlook indexing and a container that fails to attach.

Precedence is resolved per setting, not per policy. For each individual setting, Citrix evaluates which policies apply to the session - based on the policy's filters and the session's attributes (Site, Delivery Group, user, client IP, client name) - and among the policies that both apply and contain that setting, the one with the highest priority wins. Priority is the order you see in Studio, and the general guidance is that more specific policies receive higher priority than broader ones.

Diagnostic steps:

1. Identify both policies and their priority numbers. If one is filtered to the Delivery Group and the other to a user group, determine which filters actually match the affected session - a policy that does not match cannot win on priority alone.
2. Use the resultant-policy view in Studio (or the policy modelling tool) for a real user in a real Delivery Group at 09:00 against a test account, rather than reasoning about it from the console.
3. Confirm whether the setting is a user or computer setting and whether it is also being set by an Active Directory GPO - overlapping OS-level settings are a separate conflict surface from Citrix policy precedence.

Clean-up recommendation:

• Collapse to a small number of policies with one purpose each, named for that purpose, and document the intended resultant value in a table that the service desk can read.
• Set broad defaults once at Site level and use Delivery Group filters only where behaviour genuinely differs; 38 plus 11 policies is an accumulated-debt problem, not a policy-engine problem.
• Add a change check that flags a new policy setting a value already set elsewhere, so the next conflict is caught at design time rather than by a ticket about users being disconnected at four hours.

Report back to the service desk with the resolved value and the policy that produced it, so the same question does not get re-investigated.