Upgrading to eDirectory 8.7.3

  • 3393940
  • 25-Sep-2006
  • 14-Jan-2014

Environment

Novell NetWare 6.5
Novell NetWare 6
Novell NetWare 5.1
Novell NetWare Server NICI
Novell eDirectory 8.5 for All Platforms
Novell eDirectory 8.6 for All Platforms
Novell eDirectory 8.7 for All Platforms
Novell eDirectory 8.7.1 for All Platforms
Novell eDirectory 8.7.3 for All Platforms

Situation

Upgrading from previous versions of eDirectory to eDirectory 8.7.3
For Novell Directory Services (NDS) prior to eDirectory, see TIDs 10074187, 10074186, et al
Upgrading to eDirectory 8.7.3

Resolution

- Take a DIBSet before starting (DSRepair -RC)

- Use the eDir 8.7.3 IR3 Overlay CD from download (https://dl.netiq.com) | eDirectory 8.7.3 CD (ISO) Images. Then select the file for the required platform;
edir_873_ir3_nw.iso = NetWare
eDir_873_linux_solaris_aix_hpux.iso = Linux, UNIX, AIX, HP-UX, Solaris, SUSE LINUX, Red Hat
eDir_873_nw_win.iso = Windows
- Now patch to the latest eDirectory Service Pack supported by the platform version you are using
- Use the latest NICI download (https://dl.netiq.com)

- Ensure servers are up to date with the latest Service Packs (https://dl.netiq.com)

- Do a DS Healthcheck (KB 10060600)

- Decide whether to update NICI per server then upgrade DS or upgrade the whole tree to the latest NICI THEN upgrade DS - seeA NOTE ABOUT NICI, below

- Do a test run by building a new server (or test tree), import the production tree's schema and then upgrade it to make sure there are no clashes or whatever (this step is a dry-run to check out timings, number of reboots, etc).

- Set up some PINGs between servers on different sites - quickest way to tell if comms is flaky - see A NOTE ABOUT PING, below

- Start at with the Master of Root and work down

- For trees that have Master Root servers (i.e. where the Master Replicas of every single partition are all on one box, etc) it is a good idea to build a new server and add it to Root's Replica Ring, making it the Master. If the upgrade was to fail (power outage, hardware failure, etc) then only Root's replica ring gets broken, not every replica ring in the tree! This server can be removed later.

- Go slow: use +IN +SYNC + SCHEMA DSTrace switches and ensure life is good before embarking on the next server

- If you need to tune eDirectory 8.7.3 see KB 10091980 (and KB 10060669 to which it refers)

Additional Information

This TID is intended to be a living document, updated to reflect the latest developments and experiences when upgrading to eDirectory 8.7.3.

For the most up to date information check periodically for newer versions of this TID.
A NOTE ABOUT NICI
Without servers in the tree being at the desired level, 2.4.2 or higher (the latest, currently 2.6.4, is optimum) there is the possibility of the tree keys (SDI Keys) not synching properly throughout the tree to other servers. To understand the impact of the SDI key on the whole tree, please see the May 2002 AppNote entitled Understanding and Troubleshooting Novell's Security Infrastructure, available from https://support.novell.com/techcenter/articles/ana20020501.html

The SDI Key becomes increasingly important as features such as Simple Passwords, NFAP, and so on, are implemented.

Also bear in mind that the NICI modules provide other services to the Operating System and eDirectory such as encryption algorithms, cipher strength, etc, and so must be at a minimum level.

In Summary: Yes, it is best practice to upgrade all servers' NICI before installing edir 8.7.3 on the first box. This is because you are upgrading NICI not primarily because of an eDir prerequisite but to ensure that, like timesync, replication, etc, all servers have the current data (keys) PRIOR to the tree's upgrade.

A NOTE ABOUT PING
It is a good idea to set the "PING matrix" to send 1000 packets (-c with tping), of which NONE should get dropped. Running it at different times of the day, e.g. during peak login time and during a backup should give a more reliable picture.

However, running a PING with a frame size of 40 bytes (default on NW6) might help identify broken comms, but not flaky comms. There have been customers whose TCP comms consisted of small transmission units, and they suffered flaky comms/poor server response for months. It turned out that an intermediate router had a small MTU set, and a small path MTU was getting negotiated so as to avoid fragmentation.

By experimenting with the PING frame size you can determine the path MTU (or remote host MSS, if that's even smaller): PING with the DF (don't fragment) bit set (-l on Windows; -Mdo on Linux; -d on NW), and increase the frame size each time (-f on Win; -s on Linux/NW). There will eventually be a point where the MTU is breached and an ICMP is returned with something like "can't fragment -- try again with smaller size". 1400 bytes is a good starting point.

Formerly known as TID# 10093821

Change Log

14 Jan 2014 - mgould - changed Novell to NetIQ download links

Feedback service temporarily unavailable. For content questions or problems, please contact Support.