About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A local profile remains on the computer where it was created. That can be entirely acceptable for a stateless or deliberately nonpersistent workflow. It becomes a limitation when users expect settings or files to follow them to another host. Adding a second server does not automatically break every application; it exposes requirements that should have been stated earlier.
Choose the profile model by listing the state that must persist, where it must follow the user and what should happen when its storage is unavailable. Host count alone does not answer those questions.
Start with the state, not the product
Microsoft's Windows profile overview describes a profile as registry-based preferences plus profile folders and files. Different applications use those locations differently.
| State | Question to answer | Consequence for the design |
|---|---|---|
| Documents and exported reports | Must these follow the user or already live in an application/file service? | Folder redirection or an application repository may meet this requirement without roaming the entire profile |
| Registry and AppData settings | Must preferences, templates and application configuration follow the user? | Documents redirection alone is insufficient |
| Application caches and Microsoft 365 data | Must they persist, and is the proposed roaming method supported by each application? | Verify application and profile-product guidance, size and storage load |
| Disposable session state | Is a fresh profile acceptable and are all business records stored elsewhere? | A deliberately local/nonpersistent design can be valid after testing |
Folder Redirection moves selected folders to another location. It is not a complete roaming profile. If only Documents is redirected, application settings that remain in a local profile still differ between hosts.
Compare the four models
A local profile is simple and host-specific. If users reconnect to an existing session, the broker can return them to that session's host. That does not guarantee that every later new session uses the same machine. Decide explicitly whether a fresh host-local profile is acceptable.
A roaming profile synchronises the user's profile with a server copy at sign-in/sign-out according to the configured design. Check profile size, supported application behaviour and concurrent-session requirements. Do not assume every cache or modern application is suitable for ordinary roaming merely because it sits under a profile folder.
A User Profile Disk (UPD) is a per-user, per-collection virtual disk on a central share. Microsoft's secure data storage guidance states that it follows users only within that collection, and that enabling or disabling UPD applies to all users of the collection. It is not a universal profile roaming across unrelated collections, nor an individual opt-in switch within one collection.
An FSLogix profile container redirects the Windows profile into a virtual disk on a supported storage provider. Microsoft's configuration guidance says SMB is the most common provider, not the only supported storage option. A full profile container already includes Microsoft 365 application data and the benefits of the separate ODFC container; a second Office container is not required by default.
Choose from support and failure behaviour
UPD can be a candidate when persistence is required within one collection and collection-wide enablement suits the users. FSLogix can be a candidate when its profile model, supported applications and operations fit the estate. Neither selection follows automatically from having two, four or ten hosts, or simply from using Microsoft 365.
For an SMB-based design, confirm supported identity/authentication, share and file permissions, storage availability, expected simultaneous sign-ins, container size and backup/recovery responsibilities. These are design inputs, not instructions to reset permissions on a live share. Microsoft also requires eligible FSLogix licensing; confirm the applicable entitlement and supported version before deployment.
Ask what happens if storage is unavailable or a container remains locked. Will sign-in fail clearly, wait, or create another profile? Which result is acceptable for the business? Do not choose permissive fallback merely to make the sign-in screen disappear, because the user may then save important state somewhere unexpected.
Prove the selected model
In an isolated test, save sample documents and settings, sign out, start a new session on another eligible host and check the exact state that should return. Test an application update and the approved storage-failure scenario, with recovery to the expected profile. Record sign-in results, data locations and user-visible errors.
For implementation detail, see the existing FSLogix profile-container deployment article alongside the current Microsoft requirements. This comparison does not replace a supported deployment or recovery plan. No profiles, storage permissions or failure tests were changed or executed for this article.
Related service: ThinPoint remote access.
This article was originally published on .