Steps for upgrading older GMS 2014 into GMS 18.1.x

If you have this setup on some VMware, then stop GMS services, PSQL and make a snapshot for a recovery if something goes wrong.

Following steps bellow in order as they are listed is essential. Failing to run any of them, skipping, would lead into damaging present GMS system very often beyond a repair possibilities.

As a first step run pgupdate script (pgUpdate) located in /opt/novell/datasync directory. Once this is done, verify that all still can be started and it works.You can verify what PSQL version is GMS using via login into PSQL environment:

psql -U datasync_user mobility

and that would display a PSQL version info.

Once this step succeeds, do in-place upgrade of SLES11 into SLES12 SP4. You must register new server with SCC to get access to online repositories via SuSE channels. Some python files are needed from there during upgrade of GMS process. After that again verify that all can be started still and is working fine.

Now is the time you can upgrade GMS part. Use GMS 18.1.1. either official build or ask Support Center to get newer ISO image. Use then this ISO image file on your SLES12 server for upgrade process.

If you had problems with GMS2014, it might be perhaps better to build a new SLES12 SP4 server and get new GMS 18.1.x installed to start with instead of dragging old info from already partly broken or unreliable GMS2014 system.

Note please, GMS is not designed for any fault tolerance approach. This means you shall preferably not have the same user on old and new GMS servers whilst both are running. If you plan some transient state between old and new GMS servers, first delete the user from old GMS server prior you add this user to a new GMS server. This is very essential step to clear old GMS information from a GW user database, within GWEvent Container section.

You need to delete users from old GMS servers to clear this part of GW user databases. Otherwise a POA will still pretend to contact old GMS server and would keep on failing.