Viv SharmaThe host-pool decision should be based on user workload and operational model, not on whether a personal desktop feels more familiar. Pooled host pools normally deliver the best cost and resilience for task and knowledge workers. Personal host pools are appropriate when the user needs a dedicated VM because of application, performance, peripheral or support constraints.
Pooled versus personal
| Decision area | Pooled host pool | Personal host pool |
|---|---|---|
| Session model | One or more users per session host, with configurable maximum sessions. | One user assigned to one session host. |
| Load balancing | Breadth-first or depth-first based on session count. | User returns to their assigned host; automatic or direct assignment can be used. |
| Cost | Usually lower through multi-session density and autoscale. | Higher because capacity is dedicated to an individual. |
| Persistence | Hosts should be treated as replaceable; user state is externalised. | The VM is dedicated, but should still be recoverable and replaceable. |
| Application fit | Standardised apps that support multi-user and image-based delivery. | Apps requiring dedicated resources, user-specific installation or isolation. |
| Operational pattern | Image, application and policy changes are centrally controlled. | More VM drift risk unless the same image and management discipline is maintained. |
Choose by use case
Use pooled when
- Users have a common Windows and app baseline.
- Concurrency varies and autoscale can reduce cost.
- RemoteApp can meet the requirement.
- Hosts will be replaced from a managed image.
- Profile and user data can be externalised.
Use personal when
- A user needs dedicated compute or predictable performance.
- An application cannot safely share a multi-session host.
- Special peripherals or persistent local integration require a dedicated VM.
- User-specific software installation is a genuine requirement.
- Support needs an explicit one-user-to-one-VM boundary.
Where FSLogix fits
FSLogix Profile Containers redirect the complete Windows user profile into a VHD or VHDX on an SMB share. At sign-in, the container is attached to the session host and appears as a local profile. This allows users to move between pooled hosts without losing their Windows and Microsoft 365 application state.
Microsoft recommends a single Profile Container for most deployments. It includes Microsoft 365 application data, so a separate Office Data File Container is normally unnecessary. Use a dual-container design only when a tested operational requirement justifies the extra complexity.
Storage design
- Use Azure Files for most AVD deployments; consider Azure NetApp Files for demanding scale or performance requirements.
- Keep storage in the same Azure region as the session hosts to minimise latency.
- Size for concurrent sign-ins, profile growth, IOPS, throughput and file-handle limits—not only total capacity.
- Separate environments or very large populations across shares where scale or failure-domain requirements justify it.
- Use identity-based SMB access and configure both share-level RBAC and NTFS permissions.
- Protect the storage account with appropriate network controls, monitoring, soft delete and backup strategy.
Cloud Cache
Cloud Cache can write profiles to multiple storage providers and improve resilience when a single location is unavailable. It also increases design, cache, replication and troubleshooting complexity. Use it when a measured multi-region or storage-resilience requirement outweighs that complexity, and use low-latency SSD-backed storage for consistent performance.
Baseline configuration
$ProfileKey = "HKLM:\SOFTWARE\FSLogix\Profiles"
New-Item -Path $ProfileKey -Force | Out-Null
Set-ItemProperty -Path $ProfileKey -Name Enabled -Type DWord -Value 1
Set-ItemProperty -Path $ProfileKey -Name VHDLocations -Type MultiString `
-Value "\\storageaccount.file.core.windows.net\profiles"
Set-ItemProperty -Path $ProfileKey -Name VolumeType -Type String -Value "VHDX"
Set-ItemProperty -Path $ProfileKey -Name IsDynamic -Type DWord -Value 1
Set-ItemProperty -Path $ProfileKey -Name DeleteLocalProfileWhenVHDShouldApply `
-Type DWord -Value 1DeleteLocalProfileWhenVHDShouldApply is useful for preventing local-profile fallback, but it can remove an existing local profile. Validate migration and rollback on representative devices before production assignment.Permissions model
Users need permissions to create and use only their own profile folder. Administrators require controlled access for support and recovery. Do not grant broad write permissions that let users open or modify other users’ containers. Validate the access path from the session-host computer context and the signing-in user context.
Operate profiles as a service
- Monitor sign-in duration, container attach time, storage latency and capacity.
- Collect FSLogix logs from
C:\ProgramData\FSLogix\Logsand correlate them with AVD connection evidence. - Alert on profile fallback, locked VHDX files, storage authentication failures and excessive profile growth.
- Exclude cache data only when Microsoft or the application owner supports it; incorrect exclusions can break apps.
- Drain the user session and confirm the container is detached before maintenance or recovery.
- Test backup restore and profile recovery; a successful storage backup is not enough without a usable restore procedure.
Practical recommendation
Default to pooled host pools for standardised enterprise work and externalise state with FSLogix and OneDrive Known Folder Move where supported. Approve personal host pools as exceptions with a documented reason, owner and review date. Even personal hosts should be rebuilt from a controlled image, because “dedicated” should not become “unrecoverable”.