• State Not Answered
  • Replies replies
    7
  • Subscribers subscribers
    21
  • Views views
    880
  • Users 0 members are here
  • Locked Locked
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

TG920

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?

  • 0

    I have not tried with Nam 5 as yet, I am still 4.5, but planning an upgrade soon.  I personally, given its a major release, wouldbuild the new servers install all the bits required, pull in backup of the config for IDP and gateways then test offline in a lab make sure it works nothing strange, then would promote those VM's into use, reconfigure IP addresses etc if needed.

  • 0  

    Hi!

    I understand your pain since I did quite a lot of upgrades from 4.5.x to 5.

    First of all, I would suggest staying on supported versions of OS otherwise stuff will go wrong. This means you need to do upgrade in small steps.

    Put old system first to RHEL 7.9, which is supported on both AM 4.5.x and 5.x and then upgrade to 5.x and only then upgrade to RHEL 8.

    Regarding testing of new setup, I think your best bet and friend is VM snapshot. Especially if you are using risk engine, since it has been changed in 5.x and behaves differently. In my experience, until you upgrade all admin consoles and IDPs to 5.x you will have problems with risk-based authentication.

    On the bright side, with all the upgrades I did not have any problems with federations, at least not with SAML, which are most of the federations I have at my customers.

    Kind regards,

    Sebastijan

    Kind regards,

    Sebastijan

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

  • 0   in reply to 

    A quick warning, changing admin console IP address is not so simple because all devices are trying to talk to admin console using IP address. Only official way is to install new secondary admin console and then promote it to primary.

    Kind regards,

    Sebastijan

    If you found this post useful, give it a “Like” or click on "Verify Answer" under the "More" button

  • 0 in reply to   

    Yeah, usually in the lab I do build with Production IP addresses, but separate in host only etc so I can test etc. Seems to have worked for me in the past :-)

  • 0

    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.

  • 0

    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.

  • 0 in reply to   

    We had a long struggle with keeping the OS version in the timeframe of Product version.  You have to read the release notes of each one, I think you can upgrade from 4.5 to 5.x, but you have to pay attention to the supported operating system version, or do it in smaller patch levels, to get your OS in sync to what is supported all along the way.

Resources

Support
Documentation
Learning Services
Partner Programs
Privacy
Compliance
Help
Company
Privacy Policy
Terms of Use
Cookies Preferences
Accessibility
Anti-Slavery Statement
Support
Contact Us
Careers
Code of Business Conduct and Ethics
The opinions expressed above are the personal opinions of the authors, not of OpenText. By using this site, you accept the Terms of Use. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.), Hewlett Packard Enterprise Company, or Micro Focus. As of January 31, 2023, the Material is now offered by OpenText, a separately owned and operated company. Any reference to the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks is historical in nature and the HP, Hewlett Packard Enterprise/HPE, and Micro Focus marks are the property of their respective owners.