This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Upgrade Best Practices

I've been doing upgrades for quite a few years and after running into numerous issues upgrading into the 5.0.X version, I thought I'd reach out to the community and see if anyone else has come across a good upgrade plan to migrate services to new hardware and upgrade the software. 

In the past I would upgrade the Admin Console by running a backup and removing the backup file from the server. I would shut down the Admin Console then fire up a new VM (with newer OS) with the same host name and IP address, install the originating Access Manager version, perform a restore and do any necessary upgrades to get to current or which ever version we needed to get to. 

This had worked great until 5.0.X and RHEL 8 came around. I could not install older version of AM onto RHEL 8 and upgrading on the original Admin Console to 5.0.X would 'forget' to back pieces up and subsequently not restore leaving corrupt CAs, missing App Marks and visual errors when going to the Access Gateways cluster pages.

For testing purposes, I would also add a new server into the IDP and AG cluster and use host file redirects to do the testing before either upgrading the original or deprecating the old one from the cluster all together. This has been a crap shoot now and is explicitly called out in the documentation as something that should never be done, at last without making any changes. With that said, how does one go about testing 150+ federations when 80% do not have a non-production equivalent? I am to believe we are just going to upgrade all the IDPs and 'hope' that everything works on the other side? There needs to be some migration path to take and I'm just not seeing one from the official documentation other than the big bang/pull the band-aid off - that is unless I'm missing something. 

Anyone have any input on a better direction for a hardware migration/version upgrade?

Parents
  • i did 2 upgrades from 4.5.5 to 5.0.3 with the necessary steps in between (either go to 4.5.6 minimum to go to 5.0.3 directly or go to from 4.5.5 to 5.0.1 to upgrade to 5.0.3)

    Both my upgrade paths failed the first run, either on de risk-based-access rules not allowed to have spaces in them or the OpenID/Connect client information missing after the upgrade. The later one was fixed with a LDIF export of the cluster information up front and a restore of the OAuth part after the upgrade.

    VM snapshots were my saving in both cases.

    As stated earlier some of the risk-based rules run on the admin console, so as long as these are unavailable or not upgraded yet the risk based rules will not work.

Reply
  • i did 2 upgrades from 4.5.5 to 5.0.3 with the necessary steps in between (either go to 4.5.6 minimum to go to 5.0.3 directly or go to from 4.5.5 to 5.0.1 to upgrade to 5.0.3)

    Both my upgrade paths failed the first run, either on de risk-based-access rules not allowed to have spaces in them or the OpenID/Connect client information missing after the upgrade. The later one was fixed with a LDIF export of the cluster information up front and a restore of the OAuth part after the upgrade.

    VM snapshots were my saving in both cases.

    As stated earlier some of the risk-based rules run on the admin console, so as long as these are unavailable or not upgraded yet the risk based rules will not work.

Children
No Data