GW14.2 on OES2015 SP1 In Place Upgrade to GW18.1 on OES2018

This is just one possible scenario which I still think worth documenting and sharing as the documentation on the upgrade paths and pitfalls from MicroFocus is not abundant to say the least. Pretty much all one can find by a direct Google search for "oes2015 to oes2018" are seven (7) links as of 04/19/2019 of which the following are of most interest in my opinion:

After reading all of the above and having had a support case opened with MicroFocus, which pretty much assured me everything should go smoothly with minor issues related to upgrading Apache from v2.2. to 2.4, I went ahead with the upgrade and ran into quite serious issues.

Here it goes.


GW14.2 on OES2015 SP1 with the latest patches applied running on ESXi 5.5, (9919047), VM HW version 8, NIC VMXNET3, NSS locally attached storage used for GW data


Perform the in-place upgrade of the OS and of the GW


1. Upgraded GW 14.2 to GW 18.1 with no issues
2. Started OES 18.1 Upgrade, received a warning the partitions were referenced by IDs, aborted the installation, booted back into OES2015, changed partition references in the FSTAB and in the Boot Loader to labels (by-label) using Partitioner and Boot Loader applications in YaST
3. Tested reboot in OES2015
4. Re-started the OES2018 upgrade
5. The upgrade stuck on the eDirectory upgrade phase. Specifically, it was complaining of its inability to synchronize time with the writable NDS replica holder, and of the admin authentication failure with "...error: 0" Error message related to the time synchronization issue showed a truncated time server FQDN
6. Made sure time synchronization was working fine from both ends. Ran DSREPAIR on NetWare, no issues
7. Changed credentials format (Validation succeeded) to no avail
8. Identified Apache was not starting. Repaired in a SSH session by partially following Please note, in the Resolution, part 3, paths are inaccurate, link syntax is incorrect. I opted to using MC to modify the paths respectively. Apache still did not start as OES2018 dropped iFolder support, so all iFolder and MONO configs (folder* and simian) needed to be removed from /etc/apache2/conf.d All other configs needed to be modified as the "Order allow, deny" construct was deprecated in Apache 2.4 Used as a reference. Apache started, still no fun. Specifically GroupWise failed to start
9. Aborted the installation
10. Determined NSS storage was not mounted. For example, _admin was blank which would not also nss or nssmu to execute
11. Logged in as root in SSH and ran YaST there. Went to Open Enterprise Server / OES Install and Configuration. Re-ran the upgrade process which did not complain of any time or authentication issues, and eventually succeeded. Please note, iManager installation takes particularly long time
12. Verified NSS storage mounted. GroupWise started


There are bugs in the GUI based upgrade script
  • VMikhelson wrote:

    > This is just one possible scenario which I still think worth
    > documenting and sharing as the documentation on the upgrade paths and
    > pitfalls from MicroFocus is not abundant to say the least.

    I'm sorry you encountered so many issues. We do appreciate your
    feedback though. Hopefully it will help others avoid some of the issues
    you encountered.

    The references you provided show how much has changed between
    SLES11/SLES12 and between OES2015/OES2018. After the fact it's
    difficult to know how things may have progressed had you adopted a
    different approach.

    Were you aware of this VMware knowledgebase article?
    VMware support for guest operating system upgrade (2018695)

    > VMware does not support the installation of major update releases on
    > an operating system as an upgrade in a virtual machine, such as
    > Windows 7 to Windows 8 or RHEL 5.x to RHEL 6.0. VMware recommends the
    > installation of a new major releases in a new virtual machine.

    Just because something is unsupported does not guarantee you will
    encounter issues but it is something to be aware of.

    If the OS documentation states an update is supported, that definitely
    offers a certain appeal. I have done many such updates without having
    encountered any issues at all but now I wonder if that is really the
    best approach.

    When major changes have been introduced into a new version of an OS, a
    vendor has to make some important decisions about how to deal with
    upgrading components and features from previous versions.
    - In most cases existing components are upgraded without any issues.
    - in other cases the upgrade may cause incompatibility issues which
    then have to be dealt with (systemd?).
    - in some cases it is impractical to change what is already in place
    (existing NSS32 pools?).

    Even if no major issues are encountered during an upgrade, it is likely
    that some compromises are being made behind the scenes. Because of
    this, when installing a new major release, I now believe our first
    choice should be a clean install of a new system along with a migration
    and only consider an upgrade of an existing system if a migration is

    Kevin Boyle - Knowledge Partner
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below this post.
    Thank you.