1Y0-A16 · Question #259
Where should the Profile Manager user store reside?
The correct answer is A. Centralized Network Share. See the full explanation below for the reasoning.
Question
Where should the Profile Manager user store reside?
Options
- ACentralized Network Share
- BClient Device
- CXenApp Server
- DProvisioning Server Write Cache
How the community answered
(25 responses)- A72% (18)
- B8% (2)
- C4% (1)
- D16% (4)
Community Discussion
17
Ingrid P.Jun 26, 2026The correct answer is A, Centralized Network Share. Profile Manager needs to load the user profile from a location that any XenApp server in the farm can reach at logon time, so storing it on a central network share is the only architecture that makes this work across multiple servers. If you put the store on the client device (B), roaming breaks the moment the user connects from a different machine. Storing it on a specific XenApp server (C) creates a single point of failure and means profiles are inaccessible if that server is down or if the user lands on a different one. The Provisioning Server write cache (D) is a runtime disk cache for streamed server images, not a persistent store for user data, so it would be wiped on reboot anyway. Make a card for this one with the cue "Profile Manager user store location" and the answer "centralized network share, because any server in the farm must be able to read and write it at logon." Review it at your first, fourth, and tenth day intervals since this comes up across multiple Citrix exam objectives.
Brenda K.Jun 8, 2026This is a quick win, bank it in under 30 seconds and move on. The correct answer is A, Centralized Network Share. Profile Manager needs to follow the user across any server they land on in a XenApp farm, so the store has to live somewhere every server can reach, which is a centralized network share. If you put it on the client device (B) you break roaming entirely, on the XenApp server (C) it stays trapped on one node and never follows the user to another session host, and the Provisioning Server Write Cache (D) is discarded at reboot so your profile data would vanish. Centralized network share is the only location that survives reboots, scales across multiple XenApp servers, and keeps profile data consistent no matter which server handles the next logon.
Bao N.Jun 9, 2026Solid breakdown, and worth adding that in practice you want that share on DFS or at least a clustered path so a single file server going down does not wipe out logon capability for the whole farm.
Kemal J.Jun 15, 2026Centralized Network Share is the right call here, and if you have seen what happens when someone puts the store on the XenApp server itself and that server goes down for patching, you already understand why. Quick check though: what version of Profile Manager are you working with, and are you also separating the user store path by OS or just dumping everything into one flat share?
Wesley A.May 17, 2026Centralized Network Share, A, and I almost talked myself out of it on the real exam because I kept second-guessing whether the write cache made more sense for performance reasons. The whole point of Profile Manager is that the user store has to follow the user across sessions and servers, so it has to live somewhere every XenApp server in the farm can reach, which rules out the client, the individual XenApp server, and the provisioning write cache right away.
Brenda K.May 19, 2026Good instinct catching yourself, Wesley, but clock that one as a 30-second answer and move on because any option that breaks roaming kills the whole point of Profile Manager before you even finish reading the distractors.
Fatima Z.Jun 26, 2026The "Client Device" option is a sneaky trap because you might think "hey, the profile lives WHERE the user logs in," but that is exactly backwards from what Citrix wants. Profile Manager needs that store on a Centralized Network Share so the same profile follows the user across every server in the farm, no matter which XenApp box picks up the session.
Kemal J.Jun 28, 2026Correct on the centralized share being mandatory, though worth flagging that even with a network share configured, if your Citrix Profile Management path has a trailing backslash or an unresolved variable like %USERNAME% that the service account cannot expand, you end up with every session writing to the root of the share and nobody figures it out until the CDF trace.
Samuel O.Jun 26, 2026Centralized share makes sense, but are you clear on why local storage fails roaming users?
Hiroshi T.May 25, 2026The D option trips people up because write cache sounds like a plausible place for user data to land, but that cache is non-persistent by design and gets discarded on reboot. Per the Citrix Profile Management documentation, the user store must reside on a centralized network share so that the profile is accessible regardless of which server the user lands on, making A the only defensible answer here.
Viktor S.May 27, 2026Hiroshi is right on the core point, but worth being explicit about why A matters beyond just centralization: without that network share as the single source of truth, profile delta sync between sessions on different VDAs simply has nothing authoritative to merge against.
Viktor S.May 18, 2026Got A right away because I had broken roaming profiles the week before, taught me fast.
Brenda K.May 18, 2026Real-world pain is the best teacher, but make sure you also know the clean-path steps cold, because the exam will describe a scenario where nothing is broken yet and you have to pick the right order of operations before anything goes wrong.
Bao N.May 30, 2026XenApp Server keeps the profile store closest to where sessions actually run.
Brenda K.Jun 2, 2026Bao, good instinct on proximity but that logic actually points to A, because profile stores need to be on a dedicated file server accessible across all XenApp servers, not on the XenApp Server itself, which would silo profiles to a single session host and break roaming when users land on different servers.
Imani T.Jun 9, 2026The write cache on the Provisioning Server is the right call here because that is exactly where user-specific data gets written during a streamed session, so storing the Profile Manager user store there keeps everything in one place and avoids the latency you get hitting a separate network share. I have seen people argue for A but that introduces a single point of failure and adds network hops that slow down logon times, which is the whole problem Profile Manager is supposed to solve in the first place.
Kemal J.Jun 11, 2026Imani, the PVS write cache is ephemeral and gets discarded at session end, so it cannot persist profile data across logons, which is why the Profile Manager user store has to live on a stable UNC network share (A) that survives reboots and is reachable from every VDA in the site.