2 Replies Latest reply on Mar 6, 2015 7:56 AM by Landon Winburn

    Upgrading to 8.5 via Hiving

    Landon Winburn ITSMMVPGroup
      Brians reply to my post on how to apply the new WSGs during an upgrade in one step without duplicating your data inspired me to illustrate the steps needed to upgrade via the method he is using. I'm not saying one way is better than the other but I just wanted to list what is needed to make this successful.

      8.5 Upgrade Tips

      Essentially what is done is you convert from using DS/SD to a hiving configuration using only policy to manage these items. At this point personalization is only used for applications. You would then turn off DS/SD/Certs and delete all the data from the database. Upgrade everything to 8.5 and then enable the new WSGs you wish to use in personalization. The last step is to turn off all the hiving in policy. Below I will go into detail on how to do all this.

      For those that don't know, registry hiving is basically taking bits and pieces of the registry and saving them out into little miniature ntuser.dat files. Its basically the equivalent of running a "reg backup" to save the registry key and a "reg restore" to restore the registry key. Since registry hiving saves as native registry files they can be loaded and manipulated using standard Microsoft tools. This is a perfectly fine method of saving desktop settings and even application settings. In fact this is how the entire product captured profile information before the personalization server was introduced and for the people out there that say that AppSense stores settings in a non-standard format, you don't have to use personalization to manage your profile but you lose out on all the benefits of personalization such as archiving, rollback of individual applications as well as ease of configuration and scalability.

      Step 1: Save your settings to a share

      This step is really a couple phases. The first phase is a testing phase. You need to build out a policy that captures all of your desktop settings using hiving and folder copies and save all this out to a network share. This needs to be thoroughly tested as anything missed will be lost during this migration of settings. You should test this connected to a test personalization group with DS/SD/Certs disabled or while using a full test environment without DS/SD/Certs enabled to make sure you have everything captured correctly and the profile is being fully managed without the need of the personalization. In addition you need to train your helpdesk not to use the EM Browser Interface any more to manage desktop settings but instead go to the share and delete the files there if needed if an issue arises with the profile.

      Lets say this phase takes 2 weeks.

      The second phase to this step is to take your configuration you built out in testing and roll it out to production. You go through you change control request procedures and roll it out to production. This second phase requires that everyone logon at least once to capture the settings out to the share. This process could take 3-12 months as I have stated in the thread linked above and should be in line with your "InactiveProfileExpiryMonths" setting so that you properly take into account things like maternity leave and short term disability. Much like Brian stated you don't want users losing settings and generating helpdesk calls so this is critical.

      So phase 2 is now 3-12 months.

      Step 2: Disable Personalization

      The first phase of this step is actually quite simple but can be the most critical time during this transition. Hopefully all your testing from step 1 has paid off and you have your configuration spot on. Again we go through a change control request procedure to turn off DS/SD/Certs in personalization and then pull the trigger. Either the phones will be quite or they will light up, hopefully its not the latter.

      At this point let the dust settle for a while. Lets say 1-2 weeks to be safe.

      The second phase of this step is to actually delete all the DS/SD/Certs from your <= 8.4 database. This requires a bit of SQL knowledge or a few phone calls to support. Backup your SQL database and then hope for the best.

      Step 3: Upgrade to 8.5

      At this point you should be completely off personalization for DS/SD/Certs. We will need to upgrade the personalization servers and roll out the new agents at this time. The new agents can still use your old 8.4 config but will not be able to take advantage of the new triggers until a valid 8.5 config is applied. You have a couple options here. You can go *big bang* and just assign new agent and config together or you can roll out the agent with your existing config. If you roll out the agent with your existing config you will want to wait for the agent to fully deploy to all machines before updating your config to 8.5. Agent upgrades require a reboot but so does updating the config from the old 8.4 logon triggers to the 8.5 logon triggers so to minimize your required reboots you may want to roll the agents and the upgraded config out together, completely up to you.

      Again, all this should be tested prior and more change control requests. We'll be aggressive here and say this upgrade of the personalization servers and agents only takes 2-3 weeks to roll out to all your physical desktops. If this was provisioned Citrix or a View environment it would only be a single reboot.

      Step 4: Migrating settings into the new WSGs

      At this point your clients are fully deployed and you are using 8.5 infrastructure. The first phase will be to setup new WSGs in a test personalization group or test personalization server to capture all the items you were previously hiving to a share. Again, testing here is critical. You will need to test this with non-persistent profiles or machines and without hiving to make sure that everything is being captured. Again, testing here is key.

      The second phase is another migration of settings. This can be done via a run-once import at logon or with the same config. Both require a period of time to allow your users to logon. At this point you should whitelist your new WSGs.

      If you have decided to migrate with a run-once what you would do is setup your policy to import all the settings from the share at logon and then set a flag so it doesn't run again. The logoff actions to save at logoff would be removed and wouldn't be needed as everything would be saved into personalization at logoff. Next logon the flag would prevent the import of the settings from the share from happening again and the WSGs take over.

      If you decide to migrate without a run-once you just enable your WSGs for a period of time. Hiving in this case would still win and would ultimately be applying the settings as last write wins and policy runs after the WSGs are applied at logon. Another thing to note with this method is that if you need to manage a profile you have to do so on the share and in personalization as both are applied at logon.

      As with Step 1 this process requires that every user logon at least once. Again, the time this takes should be in line with your "InactiveProfileExpiryMonths" to account for things like maternity leave and is usually set to 3-12 months in most cases.

      Step 5: Remove the hiving and share

      The last step is a simple one. Just remove all the hiving actions from policy and you may delete the share used for hiving.


      Step 1: 3-12 Months
      Step 2: 1-2 Weeks
      Step 3: 2-3 Weeks
      Step 4: 3-12 Months
      Step 5: No time

      Total Time: 7 Months - 2 years
        • 1. Re: Upgrading to 8.5 via Hiving
          BChriscoli Expert
          Thanks for this Landon.. I didn't mean to start a ruckus :)
          Thankfully, anyone using your hiving template will be able to skip alot of the work as hiving is already in place.

          The majority of the timeline I agree with, however I think you are playing it safe with Step 1 and Step 4.
          I think it is unlikely that it would take 12 months for a user to logon and create a hive, or migrate settings into the db. If it did, then using an application once a year, its highly unlikely that missing settings would be a major issue.

          Our timelines are similar, but we're aiming to be fully 8.5 by September. If we have our fix for the web interface by then, we'll begin the migration back into WSGs. If not, we will continue to hive.
          That then would bring us in-line with an 8.6 upgrade next year after the peak and freeze seasons.
          • 2. Re: Upgrading to 8.5 via Hiving
            Landon Winburn ITSMMVPGroup
            All good man. My intentions with the first post was to illustrate how to do a straight upgrade to 8.5 without having to be forced into the "upgraded" junk, not really to cover every scenario. Its a neat trick...

            This post was more to show the steps needed for the hiving approach. I agree the timeline may be conservative on the high end but the point is you set the "InactiveProfileExpiryMonths" to something other than 0 for a reason and your timeline here should follow suite.

            Attached is the hiving template for those that would like to make this method easier.