Posted: 2 Mar 2005

The Deployment team at Novell has begun creating a series of papers explaining exactly how they have deployed Open Enterprise Server in some very specific scenarios. Here's how they did it in a NetWare 4.11/4.2 tree. If you have anything to add to this piece, you can visit the Cool Wiki and edit away on the wiki version of this piece. Eventually we'll incorporate the wiki edits into the Vault version of this Beige Paper.

Introduction

Novell supports two different kernels with Open Enterprise Server (OES). They offer a Linux version based on the SUSE LINUX Enterprise Server9 SP1, and a NetWare version based on NetWare 6.5 SP3.

Because NetWare 4.x servers used the IPX protocol stack and did not support the LDAP server, OES NetWare must first be deployed in an all-NW4.x tree before deploying OES Linux, to get infrastructure sufficiently in place to deploy OES Linux. If the tree contains NW51sp8 or later versions of NetWare, OES Linux can be deployed into the tree as long as the Deployment Manager steps are run.

Novell does not support IPX or SCMD running on Linux. Once the environment is sufficiently upgraded to OES NetWare and IP, OES Linux can be installed into the environment. This document describes one implementation scenario.

Here are the steps that were taken to bring a 4.11.2 (sp9) tree up to OES NetWare. There may be various ways to do this, and hopefully this example will help others who may have similar environments.

Preparing the Network and Servers

Patch all NW4.11 and NW4.2 to Support Pack 9. NetWare 4.10 is not supported in a mixed tree with NW6.5, so any servers using that version should be upgraded or removed from the tree.

Deploying OES into the 4.2.11sp9 tree

Run Deployment Manager Steps

Step 1

Make sure your NetWare client has been installed with IPX support. The default client install will not install IPX. Run Deployment Manager on a Windows workstation from root of 65OS CD, and select "Search tree for eDirectoryNDS versions". Update NDS versions on the entire tree.

As an alternative method to running this wizard, these files can be copied manually from NIPRODUCTSNDSUPDATE411, then just unload and reload ds.nlm.

Step 2

Next run the PPrepare for New eDirectory" wizard from the Deployment Manager.

Once this is finished, verify your servers have 6.21 NDS loaded and SGuid. Do a "modules ds.nlm" at the console to check.

Step 3

Now if this is to be the first NW6.5 server inserted into the tree, it is a good idea to update your schema and let it synchronize throughout the tree. You can use the Schema Update wizard found in the Deployment Manager. Then run the DSTRACE steps found in TID 10066604.

Don't forget this!

Warning - these next two steps are very important. Please do not forget to do this on an all 4.x tree!

1. Run Dsrepair Adv Options Global Schema Operations | Post NetWare5 Schema Update on Master server.
2. Then run the Rebuild Operational Schema on the Master replica server from the local DSREPAIR option.

Make sure Replica ring is synchronized and NDS is healthy.

InstallingUpgrading OES Servers

As we conducted this scenario in the lab, we next installed a new NW6.5sp3OES server into the existing tree, and it installed successfully. NW6.5sp3 and OES NetWare are installed from the same CD. During the product selection phase you will be given a choice of which one to install based on if you want the newer versions of iManager, Quick Finder (formerly Web Search) or Virtual Office.

Next a NW4.2 RW replica of root server was upgraded to NW6.5sp3 via the down-server upgrade. This can be done in two ways:

• Method #1: using the IPX client and attaching to a server hosting the NW65sp3 files. In which case a drive is mapped to the build location and Install /Upgrade is launched.
• Method #2 : booting off the NW65sp3 CD and pressing a key to intervene during the initial CD boot, then pressing P, and then entering [inst: /upgrade] hit enter, then hitting I to launch the down-server upgrade.

Next the Master of root was upgraded using the same method.

Next a down-server upgrade was performed on the last replica of root a 4.11sp9 server. These servers were all upgraded successfully.

Novell recommends using the Migration Wizard to migrate the 4.x server to NW6.5/OES or the Server Consolidation Utility to move data off to a new OES server.

Note – The NW4.2 down-server upgrade to OES is not officially supported, but in certain critical situations, a customer can work with Novell Technical Services staff to use this technology.

After these upgrades, three servers were migrated to NW6.5OES with the Migration Wizard 6.5. Please download the latest Migration Wizard 6.5 to ensure you have a fix to an issue has caused some failures during the eDirectory migration. Migration Wizard 7.x.0 cannot be used to migrate 4.x servers. Before running the Migration Wizard, load Clibaux on the 4.x server. These migrations completed successfully as well as post-installs of products.

Last a 4.2 server was consolidated with the first new NW65sp3 server with its data, rights, and home directories copied over using Server Consolidation Utility 3.x. (We always recommend you get the latest versions of these utilities from the Novell download site.) Before running the Server Consolidation Utility, load Clibaux on the 4.x server.

After the home directories were copied over to the new server, we used hbware's Homes utility to quickly fix up the home directories, so users would automatically login to the new server. In our configuration the users used a container login script with "MAP ROOT F:=%HOME_DIRECTORY." After this server had its data moved, it was removed from the tree using Load Install | Directory Options | Remove Directory Services from this Server.

At this point all of the servers in the tree are now at the NetWare 65sp3OES level.

Converting to NTP

At this point, the Time server which was previously using timesync was converted to NTP. We simply changed the sys:system imeserv.ncf file to now load XNTPD rather than timesync.nlm. We then changed the root time provider's etc tp.conf file by uncommenting the following entries:

(So in this case the 127... address is telling the time provider to get time from its local clock.)

Next, all other servers had the Timeserv.ncf file changed to load XNTPD now and comment out Timesync. Then these servers were pointed to the Time Provider server by adding this entry to their ntp.conf files:

Next unload timesync on all the servers and load xntpd. Within a few minutes time should be synchronized on all the servers. The NTPDATE IPADDress_of_TimeProvider can also be executed on each server to quickly slam the time to that of the Time Provider. Next run dsrepair | Time Synchronization and it now shows all servers insync and shows NTP as the time method.

Note – NetWare NTP is also backward compatible with Timesync. In one test we changed the tree from Timesync to NTP while we still had some servers running IPX Timesync because they had not yet been upgraded to OES. These servers were still able to synchronize time to the NTP Time Provider via IPX and Timesync. Of course the 6.5OES time server had to have the dual IPIPX Protocol stack in order for this to work.

Removing IPX

At this point all the servers have a dual stack using both IP and IPX. Since all the 4.x servers are now gone from the tree, IPX is no longer needed. In this scenario, the IPX modules and bindings were remarked out of the autoexec.ncf, and/or bindings disabled in Inetcfg.

Down-server Upgrade caveats

Here are some issues that were hit randomly on different down-server upgrades, that were able to be resolved through workarounds, but not necessarily duplicatable in our labs.

1. When upgrading the Master an error was hit trying to install eDirectory toolbox (embox?). After the upgrade a post-install of embox successfully completed.
2. A -608 error was encountered during the SSL certificate creation on the Master server down-server upgrade. A DSREPAIR to repair replicas fixed the problem, and we were able to retry and get the certificates created.
3. Another issue was synchronizing time with the 4.2 time server via IPX. This was not duplicated in other environments, but the information is listed here in case you encounter this.
   
   Here are the details. During the 65sp3 install we went to adv on the timesync screen and gave it the name of the IPX time server and checked the secondary box. After doing this we found that time was still out of sync. After some fiddling around we went into Monitor and found the time source entry had some corrupted characters. Once the corrupted characters were removed and timesync was reloaded, then time was synchronized.
4. Restarting the down-server upgrade. If the down-server upgrade fails for any reason, and it is necessary to reboot and try the upgrade again, you must add the /nocheck option, otherwise the upgrade will think your server is already at NW65 and will not let you proceed to do the upgrade.
   
   Example: Use the install parameter- [inst: /upgrade /nocheck]