12 Replies Latest reply on Apr 5, 2018 4:51 PM by Roger1

    Firefox - Mozilla Maintenance Service

    Roger1 Specialist

      We currently are using Application Personalization for Firefox personalization -  Personalizing FireFox  - which grabs {CSIDL_APPDATA}\Mozilla.  It works like a champ.  We have a requirement to keep Firefox up-to-date and we have deployed the Mozilla Maintenance Service (Workstations only) to perform this automatically without prompting users.  From what I've found this service looks for {CSIDL_APPDATA}\Mozilla\Firefox\profiles.ini in the real file system rather honoring the AppSenseVirtual location.  If I exclude this file to make this work, it looks like it'll create a new profile folder on the end point.  This can cause DB bloat and lost info since it will include a new profile path:  {CSIDL_APPDATA}\Mozilla\Firefox\profiles\<randomID>.default


      Since this is on physical endpoints only, I think I'll do a sync-down for the app group at desktop created via Export-EMPManagedAppData -App "$group".  When they run Firefox, it should update/upgrade as needed and sync any changes back to the app group.  This will continue to allow them to roam settings to Citrix.


      The other option may be to set use a WSG (or hybrid WSG and App group) but I'd much rather steer clear of this if possible.


      If anyone has already done the heavy lifting on this, I'm interested to see how you solved it.  Thoughts/suggestions?


      EM 10.1 FR3 HF1



      Regarding the blog below, I assume there is still no way to add wildcards to WSG inclusion/exclusion paths? 


        • 1. Re: Firefox - Mozilla Maintenance Service
          randyb1 SupportEmployee

          You're correct in that you can't use wildcards.  We did come up with a way to capture Firefox as a WSG, and to better filter out the things you DON'T want to capture.  The key to doing this is to force Firefox to use a specific profile name.  I'm attaching two files for you.


          The policy file is a template you can import into your EM policy.  This can be placed in the "Desktop Created" sub-trigger under Logon.  It creates the PROFILES.INI file and forces Firefox to use a specific profile (called firefox.default).


          The WSG file is a template you can import into EM personalization.  The settings all refer to the specific files/folders that need to be captured underneath "firefox.default".


          The only big caveat to using this template is that if you've already got user data in the Firefox application group, there's no easy way to save those user settings and migrate them into the new WSG.  Users will have to start with new Firefox profiles when you implement this.

          • 2. Re: Firefox - Mozilla Maintenance Service
            Roger1 Specialist

            Thanks Randy - good info.  I'll check it out.  I bet I can script something to get all this sorted for my users with data.


            I found the updater references prefs.js.  I'm not sure how it uses it or if the specific file packaged in our build of Firefox is the actual reason for the update not kicking off.  Regardless, it seems to much prefer files in their real location for this to work every time. 

            • 3. Re: Firefox - Mozilla Maintenance Service
              Maarten_VLD Rookie

              Hi Randy,


              Good find. For the caveat, you can build 2 registry value checks as followed:


              Script is as followed:

                   $NewFolder = "$env:APPDATA\Mozilla\Firefox\Profiles\firefox.default"

                   $CurrentFolder = Get-ChildItem -Force "$env:APPDATA\Mozilla\Firefox\Profiles" -ErrorAction SilentlyContinue | Where-Object { ($_.PSIsContainer -eq $true) -and  ( $_.Name -like "*.$default*") } | Select-Object FullName

                   robocopy $CurrentFolder.FullName $NewFolder /MIR /w:0 /r:0


              Make sure to keep these 2 registry values in your new Windows personalization group for Firefox and to temporary have 2 Windows personalization groups for Firefox (old and new one). Have this running for a week or 2 and delete the old personalization group afterwards. Your old group will be deleted due to the "ProfileCleanupDelayDays" setting.

              • 4. Re: Firefox - Mozilla Maintenance Service
                randyb1 SupportEmployee

                Hi Maarten, thanks for sharing your efforts here.  I'll definitely take a look at this in my lab.


                I don't see an action to export the Firefox application group settings to the local profile.  Did you do that in another step, or how did you accomplish getting the settings into the real file system?

                • 5. Re: Firefox - Mozilla Maintenance Service
                  Maarten_VLD Rookie

                  Hi Randy,


                  The fact that you are using a Windows Settings group to personalize Firefox, says it will be copied to the real file system when logging on. If you log on, the data which is stored in your personalization database for Firefox (for example "%APPDATA%\Mozilla\Firefox\Profiles\YOURPROFILENAMEHERE", will be copied to the real file system. I did not have to configure anything to make the copy actions work.

                  • 6. Re: Firefox - Mozilla Maintenance Service
                    randyb1 SupportEmployee

                    The new WSG is in the real file system.  But the data you're migrating from the original application group would be in the virtualization bubble, not the real file system.

                    • 7. Re: Firefox - Mozilla Maintenance Service
                      Maarten_VLD Rookie

                      Oh, you are still using an application group? After Firefox version 55, it will crash once you try to start it up (known bug). However, you can try to copy it from the AppSenseVirtual folder to the new real file system location. This is not the most clean solution, but it can work if you can store all the variables into parameters in Powershell for the logged on user. Both the application and WSG must be enabled for personalization within your environment to make this work. Maybe best to put all of this in a Process Started trigger to not slow down logons, should anyone have a really large Firefox profile...

                      • 8. Re: Firefox - Mozilla Maintenance Service
                        randyb1 SupportEmployee

                        Roger stated in the original post that he's using an application group.  My suggestion was to use a WSG, but that I didn't have a way to migrate the data from the old application group.  I thought your reply was a way to do that, but I couldn't see where you were pulling the application data from.  That's where I was confused.

                        • 9. Re: Firefox - Mozilla Maintenance Service
                          Roger1 Specialist

                          Good information!  I have been so swamped I haven't had a chance to look at this yet.  It looks like a WSG will be the only solution going forward.  Maybe I can use this as leverage to move away from Firefox to only IE and Chrome (at least in Citrix).  Wonder how long we have before Chrome stops app personalization (I only do bookmarks)?  It's late - I'm signing off for the night... Thanks again.

                          • 10. Re: Firefox - Mozilla Maintenance Service
                            Roger1 Specialist

                            I've just about got something scripted and tailored to our environment with your suggestions.  If it works, I'll post it.  The condition for Firefox is great for a VDI environment where apps are usually static.  However on a workstation, problems could arise with how the conditions are evaluated on each trigger (lock for example). 



                            A user logs into a laptop and installs Firefox.  Won't their WSG data be over-written with the new minimal data on lock/log off?  I believe it's a rip and replace with SyncUp on lock/log off and SyncDown on logon.  Got any special tricks to avoid this or get their data down with the install while keeping the WSG condition?  I would love a separate export/import PowerShell feature like App personalization.  Sync-DesktopSettings only pushes data to the server from my experience.

                            • 11. Re: Firefox - Mozilla Maintenance Service
                              randyb1 SupportEmployee

                              Regarding Chrome.  We have WSG templates for that as well, and use that more often that application personalization.  Certain versions of Chrome have had issues in the past with application personalization.


                              So the condition we have on the Firefox WSG looks to see if the process exists on the machine.  If it's not there at logon, the WSG will NOT be sync'd during that session.  If the user installs the software, nothing gets sync'd at logoff, because the condition failed at logon.  However, upon the next logon, the condition will pass, and the user's settings will be brought down from the personalization database and placed into the user's profile.

                              • 12. Re: Firefox - Mozilla Maintenance Service
                                Roger1 Specialist

                                Chrome was definitely problematic with full app personalization - but luckily has been good with just bookmarks.  That said, they announced they will stop 3rd party DLL injections in the future.  Chrome to stop third-party software injections because they make it crash | Ars Technica Time to move over to a WSG soon. 


                                Awesome - I thought everything was evaluated at each trigger point.  I use a similar method to only sync up select conditioned WSGs on lock/log off but never at logon (except the first).  Still building and testing FF but looks like it's all going to work well.  Appreciate the replies!