Be prepared and ready to upgrade to Open Enterprise Server 2018 (SP1)


Upgrading to Open Enterprise Server (OES) 2018 and 2018 SP1 (2018.1) is a breeze... if you're prepared beforehand...


There are basically 2 manners to get an existing server from a previous version of Open Enterprise Server towards version 2018(.1):


In place upgrade (


TransferID migration (


Both are valid upgrade paths, but still have their proper set of pre-checks and gotchas.


Though they are documented, this document tries to ease the burden to go through all of them and locate them, in some cases elaborate on them.


Before even adding your first OES2018(.1) server in the tree, please be aware of these things that might bite:

    • eDirectory supports 512 and 386 bit PKI keys, OES does not.


    • eDirectory 9.x supports 256 bit tree SDI keys, OES2018 does not.


    • Cool Tool "sdidiag" to re-key the tree key upgraded to 128 or 168 (instead of 56 from an older NetWare built tree) bit: use sdidiag 2.7 on SLES11-based OES, preferably 2015.1.


    • With eDirectory 9.x there are 2 certificates using SHA256, the second adding AES. This is no good with OES, so perform the PKI upgrade before the upgrade to OES2018(.1).

General Preparation


Before starting any upgrade to OES2018(.1), this set of checks is valid for any given upgrade path, method:

    1. Verify eDirectory health for TimeSync and the local database(s) of all servers involved

      ndsrepair -E

      ndsrepair -T

      ndsrepair -R


    1. Verify Network TimeSync health

      "date" Should show the current time

      NTP source servers (at least 3, using iBurst) should be reachable

      All servers should be using the same time source(s)


    1. Verify the PKI material for all servers involved up to and including the tree's CA (see initial note).


    1. Verify the DNS setup (servers FQDN and NetBIOS names).


    1. Make sure that all servers involved are fully patched.


    1. Make sure that the server to be upgraded is migrated to a common proxy user for all services.


    1. The Admin User(s) must be LUM-enabled on all OES servers.


    1. The Common Proxy User must be used for LUM (!OES2018SP1 requirement!)

      Start with: /opt/novell/oes-install/util/ to check what's "broken" according to it and fix manually if required.

      If that fails: (


    1. It is recommended to perform a "Top Down" upgrade of the tree or replica ring (master replicas first, then work towards the other servers).

      Be aware: in a single replica ring, do not mix eDirectory 8.7 (or older) and 9


    1. In case the server was altered in the /etc/pam.d/ for instance to disallow local logins, undo these changes, as they may interfere with the upgrade process.

For an in place upgrade

    1. Preparation:

      Make sure that the server is in a Supported Upgrade Path

      Be aware: Non-OES packages are retained, but might not work after upgrading

      Make sure to meet the Upgrade Requirements (

      In case the server is a cluster node: stop and disable cluster services and disconnect all shared storage until the server is fully upgraded.


    1. Upgrade:

      Upgrade the server as documented (


    1. Upgrade verification:

      Verify the upgrade, as documented (


    1. Perform the Post Upgrade tasks:

      Complete the OES installation and Upgrade tasks, as documented (


    1. Additional Post-Upgrade steps:

        • Check for orphaned rpms:

            • Any OES or SLES rpm from a previous release may cause unwanted phenomena and should be removed. Some iManager plugin are exceptions and can be retained.*

            • Other Micro Focus products and 3rd party packages that were installed not using a repository are listed as orphaned rpms too.

              These need to be validated for retention and upgraded if required.

          • There are several means to get the orphaned rpms listed, here are some possibilities:

            yast sw_single > packages > orphaned

            zypper packages --orphaned

        • Verify eDirectory health
          ndsrepair -E
          ndsrepair -T
          ndsrepair -R

      • In case of a server with Multi-Path configured at forehand:

        the /etc/multipath.conf needs to be (re)configured in such a way that all the internal disks by WWID are blacklisted, so multipath cannot control them.

        (Be aware that each time the /etc/multipath.conf is modified, mkinitrd needs to be executed afterwards.)

For a TransferID migration


Please be aware:

    • This is the only manner to get a NetWare server migrated to OES Linux.


    • When migrating a NetWare server, with user data on the SYS volume, do not migrate the data to the OES' SYS volume but only migrate the user data preferably towards an other NSS volume.


    • In addition do not migrate the Legacy NetWare admin tools.


    • iFolder can not be migrated to OES2018 or later (only up to OES2015SP1).




    1. Prepare the Source Server as documented (

        • Create a back-up of the eDirectory dib as the last step if the TransferID migration is to nullify the local eDirectory and power off the source server.

        • Back-up the trustees as a precaution

        • In case unsecure LDAP connection is desired, reconfigure the LDAP group to allow this.

        • Delete and purge unused, obsolete data

        • Verify the LUM configuration

        • Verify the user used for the migration is LUM-enabled

        • Make sure the SMDR / TSAFS connection is available for the migration

          eg.: nbackup -U "admin.context" -R --list-tsa-version

        • If not NetWare: Setup SSH key access and verify with server name and IP

        • Shutdown as much apps as possible, like antivirus and backup solutions

        • In case of NetWare: Unload and comment out DSMETER.NLM

      • Add Source and destination servers to the hosts file.


    1. Prepare the Destination Server as documented (

        • Install as a Premigration Server

        • Install and configure all services that will be migrated

        • In case CIFS and DST are to be migrated: ncpcon set REPLICATE_PRIMARY_TREE_TO_SHADOW = 1

        • If the source server has a VLDB replica, add one to the destination server.

        • Add the Source and destination servers to the hosts file.

      • Setup SSH key access - test with server name and IP.

Some additional preparation steps on the source and destination server that are required in case the migration is involving NSS for AD are documented .


Performing the actual Migration can be done in three documented manners:

Graphical User Interface (GUI) (

Command Line Interface (CLI) (

Remotely (


These Post Transfer ID Migration tasks might be required:

Joining the Target Server to an Active Directory Domain (

Cleanup obsolete eDirectory Objects (

DFS Junctions are not Restored (


Additional Information:


* the *-plugin rpms are iManager plugins for products no longer retained with OES2018. If there are older servers in the tree with these products, and it's required the OES2018 server should be able to manage these products on the older server, these can and may be retained. If this is not required, they can be removed too.


To get a list of the rpms left behind from a previous OES or SLES release:


rpm -qa --queryformat "%-35{NAME} %-35{DISTRIBUTION} %{VERSION}-%{RELEASE}\n" | sort -k 1,2 -t " " -i | grep -v 'Open Enterprise Server 2018' | grep -v 'SUSE Linux Enterprise 12' | grep -c 'OES_2018_Update' | grep -v 'gpg-pubkey'


This command will also list 3rd party applications.


HP's cciss drivers are no longer shipped with SLES12 and onwards.


From SLES 12 onwards we create /dev/cciss/* by udev rules stored under /usr/lib/udev/*


More details in this note:


How To-Best Practice
Comment List