5 Replies Latest reply on Nov 10, 2017 4:02 PM by Landon Winburn

    Best practice to Migrate from Personalization to Registry Hiving

    Eddie.Santana Apprentice

      We currently use Personalization. I want to migrate over to Hiving. I am looking to do a catch all approach without sacrificing login/off times. I find catchall may be easier when onboarding new apps.

      We are a physical W10 shop with Citrix 2k12r2 Xenapp (Shared SRV OS) for remote access.

       

      1) Would Hiving slow anything down?

      2) How should I handle the few folders from %appdata% folders. Continue to use Personalization?

        • 1. Re: Best practice to Migrate from Personalization to Registry Hiving
          Landon Winburn ITSMMVPGroup

          What version of EM are you on? If your on 10.x and have not upgraded from 8.x then the Windows Setting Groups use registry hives by default and don't have any of the issues of the FBR. If your on 10.x I'd stick with traditional personalization.

          • 2. Re: Best practice to Migrate from Personalization to Registry Hiving
            Eddie.Santana Apprentice

            We are on 10.1.3 upgraded From 10.0.

             

            There has been numberous and random issues with Outlook PST and Adobe In which the application doesn’t operate as expected. Then I Stop the EM service on the PC- fixed.

            Also on boarding Apps is time consuming. I am not concerned with Just-in-time. I would rather do a Just-in-case by doing a catch all.

            Also I have been running into IIS size limit. I have apps that reside in %appdata% that needs to roam with user.

            Traditional roaming profile is not an option since we are run mainly a Cloud based Infrastructure and don’t want to deal with File server.

            • 3. Re: Best practice to Migrate from Personalization to Registry Hiving
              randyb1 SupportEmployee

              So I'm a bit confused by your questions and explanation.

               

              First off, hiving registry settings means saving those settings to a file.  That file must then be stored somewhere.  If you're collecting these files in the personalization database, then as Landon mentioned, that is unnecessary in version 10.x, as there's no longer a dependency on FBR files.  If you're saving the files to a file share, that conflicts with your cloud-based infrastructure.  So it pretty much rules out any need for hiving.

               

              Onboarding apps can be time consuming, but it's important in order to keep profile sizes small.  If you don't configure your application groups and Windows settings groups properly, profile sizes will get very large.  This will very quickly lead to the IIS size limit, as you're already having issues with.

               

              Finally, as for %APPDATA%, this is where most applications store user settings.

               

              You may want to review the following Best Practice document around personalizing applications: BP05 - Application Personalization Process

              1 of 1 people found this helpful
              • 4. Re: Best practice to Migrate from Personalization to Registry Hiving
                Eddie.Santana Apprentice

                Sorry I was confusing Application Personalization and Windows Personalization.  It seems like there are  basically the same except one launches with it’s specific exe launch And other at Windows launch  Correct?

                 

                Me and the environment are fairly new to Appsense. We had a vendor perform the implementation.  I will review the article  you provided.

                 

                In article it states it can convert the finding for Filezilla (as an example) into  Application Group. Possible to have it as Windows Personalization?

                • 5. Re: Best practice to Migrate from Personalization to Registry Hiving
                  Landon Winburn ITSMMVPGroup

                  The difference between application personalization and windows setting groups is application personalization happens on process start and stop and is sandboxed. The settings are redirected into the c:\appsensevirtual cache and then saved/restored from that location. By doing this you offload this work from logon and it happens real time. The other benefit is you can roll back application settings without having to log off and back on.

                   

                  Windows personalization or Windows Setting Groups (WSGs) save settings at logoff and restore them back to the real file system and registry at logon. This impacts logon times as it all must happen before the windows explorer shell is allowed to load. For this reason its best to keep these as lean as possible and use application personalization as much as possible unless an application doesn't play nice with the hooking in application personalization.

                   

                  As far as converting application groups to WSGs, no that functionality isn't there. You'd have to do it by hand.