Is there a better way to handle roaming profiles?

[FMCUSystemAdmins]

Originally asked on r/firefox:

Hello,

We support the three major browsers in our environment: Chrome, Edge, and Firefox. For all three, we have respective profile roaming settings implemented through Group Policy. Chrome and Edge are basically set and forget.

The method we're using for Firefox is more clunky and not as reliable, as we've found. We have customized the .ini file located under %APPDATA\Mozilla\Firefox\profiles.ini to point Firefox to a file share where we house all user Firefox profiles. Since configuring this, we've realized that Firefox is heavily disk I/O dependent when it comes to the profiles. This is exacerbated by the disk I/O having the networking overhead of being on a file share. General usage of Firefox is slower than compared to Chrome and Edge. If connection to the file share is lost, Firefox becomes unresponsive and will most likely require a relaunch. Sometimes it locks up the entire system causing the user to need to logout and back into Windows.

When it comes to our laptop users, to prevent their Firefox from being unusable when disconnected from our network (since the profile cannot be reached on the file share), we have Offline Files configured to essentially cache the Firefox profile locally. This is just another moving part to manage and adds to the clunkiness of the solution.

I have not seen any other alternatives in the policy settings and the only other documentation on how to achieve roaming profiles is here. However, that option is still subjected to the network and disk I/O overhead and we'd have to take into consideration all other applications that use %APPDATA%, which isn't happening.

We do not have these problems with Chrome and Edge. Is redirecting disk I/O from local to remote really the best way to achieve roaming Firefox profiles?

[mkaply]

Unfortunately this is an area that we've never really prioritized:

https://bugzilla.mozilla.org/show_bug.cgi?id=1395705

Is all of your profile data ending up on the share, not just the Roaming part?

[FMCUSystemAdmins]

Yes, since we're modifying the "Path" property in the profiles.ini file to point to the share, it's the entirety of the profile.

[mkaply]

So I talked to the team and there are environment variables that separate the local and non local parts:

XRE_PROFILE_PATH and XRE_PROFILE_LOCAL_PATH

So you could set XRE_PROFILE_LOCAL_PATH to something on the actual machine and avoid some of the churn.

They also wondered about "just mount[ing] their network share at %APPDATA\Mozilla\Firefox?"

[FMCUSystemAdmins]

Would we take advantage of those environment variables by having them set via SET XRE_PROFILE_LOCAL_PATH=<\local\path> or equivalent through GPO so it exists before Firefox launches? Then Firefox is aware of the variable, will read it, and use the path accordingly?

Unsure what you mean with mounting the share at that path, are you talking about a symlink or something like that?

[mkaply]

Would we take advantage of those environment variables by having them set via SET XRE_PROFILE_LOCAL_PATH=<\local\path> or equivalent through GPO so it exists before Firefox launches? Then Firefox is aware of the variable, will read it, and use the path accordingly?

Correct.

Unsure what you mean with mounting the share at that path, are you talking about a symlink or something like that?

Yes. the suggestion was that only %APPDATA\Mozilla\Firefox me mapped to the network share which would be the roaming part.

[FMCUSystemAdmins]

Thanks for your patience, had to move this to the back-burner for a bit.

Came back to it and found that XRE_PROFILE_LOCAL_PATH by itself does nothing. Came across this comment, and sure enough, the same logic applies today. XRE_PROFILE_LOCAL_PATH only kicks in when XRE_PROFILE_PATH is also used.

Initial experience with setting XRE_PROFILE_LOCAL_PATH to a local path does seem to hasten Firefox's responsiveness, both on relaunching with tab restoration and general usage. Will test a bit more, then see if we can optimize our laptop users' experience for "disconnected" states.

Thank you!

[mkaply]

That's great to hear!