Deploy profile containers as a storage and identity service, then prove that a user receives the correct persistent profile on another session host. Faster sign-in is useful only if settings persist, concurrent access is controlled and one user cannot read another user's profile.
This is a new-lab pilot for two RDS session hosts, an existing domain and an empty dedicated SMB share. Existing profile migration, concurrent multi-session access and production profile deletion are outside scope. No FSLogix installation or registry change was executed for this draft.
1. Establish the pilot contract
Record exact Windows and FSLogix builds, applicable licensing eligibility, supported application versions and the selected storage provider. Confirm that the application vendors support the RDS configuration. Maintain the same application versions on both session hosts before testing roaming.
Use two ordinary synthetic users and separate administrative access. Define what must roam: a harmless desktop preference, a file in the user's documents and a setting in the actual application. Define the required sign-in/out behaviour and what should happen when storage is unavailable.
Profile containers place the Windows profile in a virtual disk on supported storage. A full profile container also includes the Microsoft 365 profile data addressed by the separate Office container model; do not assume both are necessary. Profile container setup: https://learn.microsoft.com/en-us/fslogix/tutorial-configure-profile-containers
2. Prepare storage and access boundaries
Create a new share using the organisation's approved file-service procedure. Confirm capacity, backup ownership, file-service availability, DNS and time synchronisation. Reserve room for profile growth and simultaneous sign-in I/O, not merely the sum of today's empty containers.
Review both share and filesystem permissions. Microsoft's storage permissions guide: https://learn.microsoft.com/en-us/fslogix/how-to-configure-storage-permissions distinguishes root access for authorised users, permissions inherited by each created profile, and administrative access. Apply the reviewed ACL design to the empty pilot share. Never paste a recursive inheritance-reset command against a populated production profile tree.
Before enabling FSLogix, test that pilot user A can create its authorised test directory and cannot open user B's private directory. Repeat in the reverse direction. Use the same access identities that will mount the containers, not an administrator whose privileges mask a faulty ACL.
The source documentation flags Windows Kerberos encryption changes affecting SMB profile access. Check the current patch and account/encryption compatibility of the storage provider. Do not weaken authentication or remove updates to make a pilot pass. Identity failures can look like profile-storage faults.
3. Configure only the required pilot settings
Install the approved FSLogix build on both disposable session hosts. After recording the initial configuration, use the supported administrative mechanism to configure HKLM\SOFTWARE\FSLogix\Profiles.
| Value | Type | Pilot intent |
|---|---|---|
Enabled |
DWORD | 1, enable profile handling |
VHDLocations |
MULTI_SZ or REG_SZ | One allocated pilot UNC path |
VolumeType |
REG_SZ | VHDX |
ProfileType |
DWORD | 0, default single-connection design |
For documentation, the fictional path is \\profiles-lab.example.invalid\profiles. Allocate the actual path privately. These settings are documented in the configuration reference: https://learn.microsoft.com/en-us/fslogix/reference-configuration-settings.
Set the maximum container size from a measured application requirement and a storage budget. A maximum virtual-disk size is not a guarantee that that much physical capacity is available to every user simultaneously. Record allocation and growth observations during the pilot.
Do not enable DeleteLocalProfileWhenVHDShouldApply on an existing user population as part of this guide. It can remove local profiles. Use new pilot accounts without valuable local data. Changing naming options in an established estate can also make existing containers appear absent; keep naming stable throughout the experiment.
4. Prove attachment and persistence
Ensure pilot user A has no active or disconnected session on either host. Sign in to the first host and identify the profile attachment in FSLogix's logs. Create the harmless test file and application preference, then sign out fully. Disconnecting an RDP window is not the same as signing out.
Confirm the first session has ended and the container is no longer held by that session before signing in to the second host. Verify the same file and preference appear. Change them on the second host, sign out, and verify the updated state on the first.
Repeat with user B. Confirm each sees only its own profile. Keep a short matrix containing user alias, host, sign-in/out times, attachment outcome, persistence outcome and denial-test result. Do not put actual identities or complete logs into a public article.
A visible desktop alone is not success: a fallback local or temporary profile can look normal initially. Correlate the session with the expected container path and the logged attachment result.
5. Separate profile time from total sign-in time
Collect the FSLogix profile log for the exact test interval. Follow the user's load/unload sequence and its process identifier rather than scanning only for the final error. Microsoft documents profile text logs and Event Viewer channels in its diagnostics guide: https://learn.microsoft.com/en-us/fslogix/troubleshooting-events-logs-diagnostics.
Record at least three timing boundaries: authentication begins, profile attachment completes, and the required application becomes usable. Group Policy, shell startup, application initialisation and remote display can add time after attachment.
Compare first creation, returning sign-in and concurrent sign-ins as separate workloads. Keep the profile contents and session-host application build stable. A fresh empty profile is not a fair comparison with a mature user profile containing substantial application data.
Correlate slow attachment with SMB latency, storage capacity, antivirus/filter activity and ESXi contention. Treat each as a hypothesis. Do not add broad endpoint-security exclusions without the product-specific supported design and approval.
6. Rehearse bounded failures
Use a pilot-only network rule or isolated storage service to simulate unavailability without affecting other users. Define the expected fail-closed or fallback behaviour from the reviewed FSLogix settings before the exercise. Observe the actual session result and recovery after service returns.
For a locked-container error, determine whether another session still owns the disk. Preserve log evidence and reconcile session state. Do not delete the VHDX, break a file lock or detach a mounted disk while a user may still be writing.
For capacity failures, distinguish the guest-visible profile volume limit from the SMB backend's remaining space. Expanding a container cannot solve a full datastore. Manual compaction or filesystem repair requires a separate offline recovery plan.
Acceptance and rollback
Accept the pilot only after cross-host persistence, cross-user isolation, predictable storage-failure behaviour and application correctness pass. Record sign-in distribution, simultaneous-user count and backend headroom. A speed claim requires a repeatable matched baseline.
To reverse pilot configuration, sign out the pilot users cleanly, verify containers are detached, then restore the previous policy/settings on the disposable hosts. Retain profile data according to the test retention decision. Disabling FSLogix does not automatically migrate container contents into local profiles.
Related topics: SMB diagnosis, RDS application performance and independent profile backup.
Learning notes
- A correct desktop can still be using the wrong profile source.
- Sign-out and RDP disconnection have different effects on profile ownership.
- Profile attachment time is only one part of the user's sign-in experience.
Sources and review status
See the source ledger, author self-check and series index. Independent review and lab validation remain pending.