I’ll start by saying I am not a fan of Mozilla Firefox as a browser. I never have been and it’s unlikely I ever will be. For home use or as a secondary web browser it does a good enough job but as a primary web browser I find it a little too flakey and, if I am honest, there are just too many quirks for me that stop it working well in a managed environment.
The customer that I am currently consulting at offer users a choice of Internet Explorer 11 or Firefox ESR and users are continually calling the service desk with issues like:
“My bookmarks have been lost”
“Pressing enter in the search bar doesn’t do anything”
“<site name> won’t open using Firefox”
It’s no secret that I’ve spent a lot of my professional life working in end user computing, specifically with AppSense DesktopNow (or Ivanti User Workspace Manager depending on whether you’re old school or not) and the goal is always to keep the profile as small and lightweight as possible. A small, well managed configuration can make the difference between a 25 second logon and a 60 second logon and you don’t have to go far to see real world examples of this. Take a look at James Rankins blog, Avanite’s corporate blog or a variety of other EUC experts and you will find references to Web Browsers slowing down logins.
Back to Firefox, the first and most pressing issue is the fact that Firefox creates a default profile with a random profile name the first time a user opens the application. In the screenshot below, you can see that Firefox created a profile named rx16ltys.default on its first launch.
The problem with this is that any attempts to exclude files or folders from the Firefox profile to keep the managed data as small as possible becomes a problem because this name is unpredictable. For example, if I wanted to exclude the crashes folder I couldn’t because I would need to create a wildcard exclusion mid-way through the path, for example, %APPDATA%\Mozilla\Firefox\Profiles\*\crashes which is not possible within Environment Manager.
There are no policy actions within Firefox that allows an administrator to pre-populate the profile name. So, what can be done about this? I posted a question about this on the Mozilla community forums because there is no formal Mozilla support facility and Mike Kaply, the creator of the Firefox Customization tool (https://mike.kaply.com/category/mozilla/) replied suggesting using firefox.exe -createprofile to create a profile within the correct location. This looks like it would work in a greenfield deployment where I could start from scratch. Unfortunately, I am trying to make Firefox work at a customer who has been using this as a primary browser for some time now. The fact it’s the primary browser means I can’t reset the profile across the board without causing a significant incident.
So again, I ask… what can be done? Well… this is how we are tackling the situation. First off I have a script that opens the profiles.ini file and reads the profile name from the file. This script is configured as a custom condition within Environment Manager and depending on what the profile name is either exits with an exit code of 0 or 1 depending on what the condition is looking to do.
Now, as I have already alluded to, we are managing Firefox with its random profile name already. This means that each user will have a profile stored within the Environment Manager database. This complicates things a bit because I need to run any further actions against the local and managed versions of the profile. Initially I compiled the script into two executables, on called firefox.exe and one called firefox_profile.exe. The idea here was that firefox.exe would run and because it was a managed process would interact with the bubble and the firefox_profile.exe wasn’t managed so would interact with the local profile. This worked but as soon as we started extending the pilot, we had reports of the executables being flagged by the Antivirus software. Back to the drawing board.
Next, we switched things up and tried to use the AppSenseSpecial switch to run the script inside the Firefox bubble. Again, this worked, and I was comfortable with the solution but ultimately decided against it because AppSenseSpecial is notoriously difficult to use and my concern is that if I move on from the organization there won’t be anyone that understands how it works.
At this point we were running low on ideas. The challenge is the fact its managed and a dynamic profile. What can we do? And then it came to me… why not export the settings out of the database using the export-empmanagedappdata cmdlet manipulate the data in the local profile and then re-import the application using the import-empmanagedappdata cmdlet. This worked a treat… here are the actions I used to achieve the profile rename.
Firstly, exporting the data:
Once the data is exported we can run the following PowerShell script to rename the path:
Finally, import the settings back into the Ivanti Environment Manager Personalization database:
This now opens the door for us to add paths like to our exclusions list and be safe in the knowledge that the users profile will be firefox.default.
It may not be firefox.default on the first login but it definitely will be on the second and the Personalization Server cleanup process will make sure any random profile crashes are removed over time.
I’m not a brilliant scripter so if anyone wants to improve on my scripts please feel free to update these and share them.