Cool Solutions

NetWare to OES2 Linux Migration Guide


January 18, 2008 4:50 pm





Back in June of 2007, I wrote a migration guide for NetWare to OES1. While there are similarities between the OES1 and OES2, there are also major differences. For the sake of a complete HowTo on migration, I have included those similarities here so the reader does not have to jump between multiple documents. What is not covered in this article are the enhancements you can apply, such as AutoYaST, to increase the efficiency of your own migration experience.

Note: At the time of writing of this article, ZENWorks Desktop Management 7 SP1 is not supported with OES2. There is a IR1 Hotfix to be released in latter January 2008 that will address issues related. I have included the installation of ZENWorks 7 because it is my personal experience that Application Objects are not affected and because earlier versions of ZENWorks do not support eDirectory 8.8.2 and vice versa.

Please make modifications to the data, where noted, to reflect your own organization’s structure.

Other resources

Novell Open Enterprise Server 2 Migration Best Practices Guide


The services to be migrated include:

  • Data – User and other shared
  • ZENWorks – Applications and policies
  • Backup – RSYNC
  • After the migration is completed and tested, decommission of existing NetWare servers

The steps to perform the migration are listed here:

  1. Preparing your current environment.
  2. Installation of OES Linux to a new server following specific instructions to ensure proper NSS volume creation under EVMS management.
  3. Securing the new OES Linux server.
  4. LDAP authentication for local user access.
  5. Data migration.
  6. DNS/DHCP migration.
  7. ZENWorks Desktop Management v7 SP1 – Optional.
  8. RSYNC modification – Optional.
  9. NetWare Server Decommission.
  10. Workstations.

1. Preparing your Environment

OES2 installs eDirectory 8.8.2 and can affect other applications in your environment. To see a list of which Novell applications are compatible with eDirectory 8.8 and which are not, look here.

If you have a version of ZENWorks prior to 7 SP1, I would suggest upgrading to this version prior to introducing eDirectory 8.8 into your tree. eDirectory 8.8 does not replicate attributes of prior versions of ZENWorks.

OES2 migration will migrate versions of NetWare from 5.1 and later. For purposes of this article, we will be migrating NetWare 6.5 SP6.

2. OES2 Linux Installation and Configuration

With the release of SuSE Linux Enterprise Server 10 SP1 and OES2, Novell has separated the two products and OES2 Linux is a separate CD. This means that when you do your OES2 installation, you will add this CD to the installation of SLES 10 SP1. OES2 can be installed either during the SLES 10 SP1 installation or added to the server at a later time.

This portion does NOT walk all the way through an OES Installation. It is intended to specify critical changes that must be made to the default installation of OES Linux to ensure the migration is transparent to the user.

Adding OES2 to the Installation

When you begin your new installation, you choose your language and you will be presented with the following screen. Click New Installation and click “Include Add-On Products from Separate Media.” Choose CD on the next screen and YaST will prompt you for your OES2 CD.


  1. When the installation reaches the Installations Settings screen, delete the recommended partitions and the partition table on the system disk so that the device can be marked to use EVMS as the volume manager instead of LVM.
    1. In the list of Installation Settings, select Partitioning.
    2. In the Partitioning menu, select Create Custom Partition Setup, then click Next.
    3. Select Custom Partition – for Experts, then click Next to open the Expert Partitioner options.
    4. Select Expert > Delete Partition Table and Disk Label, then click Yes twice to continue through the Warning advisories.

      This deletes the recommended partitions and the partition table on the system disk.
  2. Create a primary partition on the system disk to use as the boot partition.
    1. Click Create.
    2. From the list of devices, select the device you want to use for the boot partition, ex: /dev/sda, then click OK.
    3. Select Primary Partition, then click OK.
    4. Select Format, then select the native Linux file system you want to use, such as Ext3.
    5. In Size (End Value) field, specify 300 MB.
    6. Set the mount point to /boot.
    7. Click OK.

      The partition appears as a logical device in the devices list, ex: /dev/sda1.
  3. Create a second primary partition on the system disk to use for your swap and system volumes as follows:
    1. Click Create.
    2. From the list of devices, select the device you want to use for the second primary partition, ex: /dev/sda, then click OK.
    3. Select Primary Partition, then click OK.
    4. Select Do Not Format, then select Linux LVM (0x8E) from the list of file system IDs.
    5. In Size (End Value field), set the cylinder End value to the size of your disk minus what you want to use for swap., ex: 12GB
  4. Leave unpartitioned space available.
  5. Click OK.

    The partition appears as a logical device in the devices list, ex: /dev/sda2.
  6. Modify the volume management type from LVM to EVMS for the second primary partition you created in Step 3 as follows:
    1. At the bottom of the page, click EVMS.

      Available partitions for EVMS appear as devices under /dev/evms, such as /dev/evms/sda2.
    2. In the EVMS Configurator, select the LVM partition created in Step 3, then click Create Container.
    3. In the Create EVMS Container dialog box, select the partition, specify the container name (such as system), then click Add Volume to create the lvm/system container, where system is the container name.
    4. Click OK.

      The EVMS Configurator displays the lvm/system container you just created, its size, and free space.
  7. Create the swap volume in the lvm/system container as follows:
    1. Select lvm/system, then click Add.
    2. In the Create Logical Volume dialog box, select Format, then select Swap from the File System drop-down menu.
    3. Specify swap as the volume name.
    4. Specify the size of the swap volume as 2 GB.
    5. Specify the mount point as swap.
    6. Click OK.
  8. Create the system volume in the lvm/system container as follows:
    1. Select lvm/system, then click Add.
    2. In the Create Logical Volume dialog box, select Format, then select the file system to use from the File System drop-down menu, such as Ext3.
    3. In the Volume Name field, specify a volume name, such as sys.
    4. Specify the Size of the system volume as the remaining space available in the lvm/system partition by clicking Max.
    5. Specify the mount point as / (root volume).
    6. Click OK.
  9. Click Next to return to the list of devices.
  10. Below is an example of the physical and logical devices you should see.

    Device Size F Type Mount Start End Used By
    /dev/sda 149 GB ST34001A 0 19456
    /dev/sda1 300 MB F Linux native /boot 0 38
    /dev/sda2 20.0 GB Linux LVM 39 2649 EVMS
    14.9 GB F EVMS /
    2.0 GB F EVMS swap
  11. Click Next to return to the Installation Settings page.
  12. From the Installations Settings screen, click Software > Details, then select the following software options – These are the basic options I chose for my use. You can modify this depending on your needs.
    Basic Runtime System
    Graphical Base System
    Linux Tools
    Authentication Server (NIS, LDAP, Kerberos)
    Basic Sound Libraries and Tools
    Gnome System
    Novell eDirectory
    Novell iManager
    Novell Linux User Management
    Novell iPrint
    Novell NetStorage
    Novell NSS
    Novell NCP Server
    Novell Backup Services (SMS)
    Novell Health Monitoring

    Select Search and in the search field, type Locate and then search. On the right side, “findutils-locate” will appear. Also add DHCP Server and RSYNC, if desired. Click Accept.

  13. Scroll down the list and select the TimeZone for this server’s location and then click Runlevel. Select Runlevel 3 – No GUI on console.
  14. Continue with the OES installation.
    IMPORTANT: After the install is complete, make sure to perform the mandatory post-install configuration of the related system settings to ensure that the system device functions properly under EVMS. Otherwise, the system fails to boot properly.

After the Install

After the OES installation is complete, you must perform the following tasks to ensure that the system device functions properly under EVMS:

Disable boot.lvm and

Disable boot.lvm and so they do not run at boot time. EVMS now handles the boot.

  1. In YaST, click System > Runlevel Editor > Expert Mode.
  2. Select boot.lvm.
  3. Click Set/Reset > Disable the Service.
  4. Select
  5. Click Set/Reset > Disable the Service.
  6. Click Finish, then click Yes.

    Do not reboot the server yet!

    Enable the boot.evms Service

    The boot.evms service should be enabled automatically after the install, but you should verify that it is enabled.
    1. In YaST, click System > Runlevel Editor > Expert Mode.
    2. Select boot.evms.
    3. Click Set/Reset > Enable the Service.

      The B runlevel option is automatically selected.
    4. Click Finish, then click Yes.

      Do not reboot the server yet!

    Edit the /etc/init.d/boot.evms Script

    1. Open the /etc/init.d/boot.evms script in a text editor.
    2. Add the following lines to the Stop section:
      mount -n -o remount,rw /
      echo -en "\nDeleting devices nodes"
      rm -rf /dev/evms
      mount -n -o remount,ro /

      The Stop section looks like this after the edit:

              echo -n "Stopping EVMS"
              mount -n -o remount,rw /
              echo -en "\nDeleting devices nodes"
              rm -rf /dev/evms
              mount -n -o remount,ro /
              rc_status -v
    3. Save the file.
      Finally! Reboot the Server
  7. Now reboot the server to activate post-install configuration settings.

Verify the System Services

After the post-install configuration is complete and you have rebooted the server, make sure the server is operating as expected.

Create NSS Volume

From the command prompt, type nssmu to start the NSS Management Utility.
Select Pools, press Insert and create a new Pool. Call it VOL or whatever your standard dictates. Designate all the free space to it.

Select Apply and the Escape back to the main menu.

Select Volumes, press Insert and create a new volume. Name it VOL1 (for example) and place it in the pool you created earlier. Designate all the space to this volume and select apply.

Select the volume and press F4 to update eDirectory, otherwise you won’t see the new volume in the tree. Press Esc to exit the utility.

3. Securing the New OES Linux Server

These recommendations are optional and should be used as, at least, a guide to securing your server. Refer to your organization’s security policies regarding hardening your servers.

GRUB Boot Loader

Password protect the boot loader to prevent editing of the boot environment or passing kernel level commands to the system at boot time. Use the md5crypt command within GRUB to encrypt a password. Then use this hash to edit the menu.lst file and insert the password line as shown below.

Be sure NOT to use the same password as root or any other user password on the system. If you “fat finger” the password without testing it first you will not be able to make changes to the boot process upon boot up!

# grub

  GRUB version 0.97 (640K lower / 3072K upper memory)

[ Minimal BASH-like line editing is supported. For the first word,
 TAB lists possible command completions. Anywhere else TAB lists 
 the possible completions of a device/filename. ]

grub> md5crypt

Password: *******
Encrypted: $1$vUYoM$OAxm9NVNUBsCeP1dl50


vi /boot/grub/menu.lst

color white/blue black/light-gray
default 0
timeout 8

password --md5 $1$vUYoM$OAxm9NVNUBsCeP1dl50
title linux
  kernel (hd0,0)/boot/vmlinuz root=/dev/sda1 vga=795


Password protect changes to the BIOS to prevent changing the boot order of the device. In production booting from CD or floppy should be disabled.

Tuning Network Kernel Parameters

There are a few parameters that can be applied to the kernel through the proc file system to improve protection of the server.

Modify /etc/sysconfig/sysctl to add these options along with the default configuration options.

net.ipv4.ip_forward = 0 -- Disables IP forwarding.
net.ipv4.conf.all.accept_source_route = 0 -- Disables source routing.
net.ipv4.tcp_syncookies = 1 -- TCP syn flood protection parameter.
net.ipv4.tcp_max_syn_backlog = 4096 Additional TCP syn flood protection.
net.ipv4.conf.all.rp_filter = 1 Enables anti-spoofing protection.
net.ipv4.conf.all.send_redirects = 0 Disables the sending of ICMP redirects.
net.ipv4.conf.all.accept_redirects = 0 Disables receipt of ICMP redirects.
net.ipv4.conf.default.accept_redirects = 0 Disables ICMP redirects for newly activated.

Warning Banners

Include this warning message for all direct methods of connection to the server.

/etc/motd Add this banner to this file

/etc/issue Add this banner to this file also. Below is an example that you can use.

Change My Company to your Organization – It’s lengthy, but you know the legal guys..

My Company owns this computer system and restricts access and use to authorized persons only. Use of and/or access to this system and/or any information obtained via this system is subject to My Company policies and procedures governing such use and access. Unauthorized or improper use of or access to this system, or any portion of it, either directly or indirectly, or any attempt to deny service to authorized users or to alter, damage, or destroy information, or otherwise to interfere with the system or its operation, is strictly prohibited. Any party using or accessing, or attempting to use or access, this system without express authority from My Company may be subject to severe disciplinary action and/or civil and criminal penalties in accordance with applicable state and federal law (including, but not limited to, the Computer Fraud and Abuse Act of 1986 and the Electronic Communications Privacy Act). My Company representatives may monitor and record use and access for quality assurance, security, privacy compliance, regulatory compliance i.e. HIPAA, Sarbanes Oxley, and performance, except as prohibited by law. Any person who uses or accesses this system expressly consents to such monitoring and recording. My Company or its representatives may furnish information obtained by its monitoring and recording activity to law enforcement officials if such monitoring and recording reveals possible evidence of unlawful activity.

Copy the /etc/issue file to /etc/

For SSH connections edit the /etc/ssh/sshd_config file. Below is the what needs to be changed to point the banner at the /etc/ file.

# vi /etc/ssh/sshd_config

# no default banner path
Banner /etc/
#VerifyReverseMapping no

# override default of no subsystems

SSH configuration

In addition to setting a banner as above, it should be restricted to version 2 of the protocol only. SSH version 1 has some inherent weaknesses and so should be avoided. Edit this file and make the changes listed in Bold. Most settings are fairly self explanatory. No hosts should be automatically trusted through the rhosts types of authentication or even with a machine based certificate as with the RSA variants. Root should not be allowed direct access. For administration, you should connect to the machine as a regular user and then SU to root for additional needed rights.

#Port 22
Protocol 2
#ListenAddress ::
SyslogFacility AUTH
#LoginGraceTime 600
PermitRootLogin no
#StrictModes yes
RhostsAuthentication no
# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in 
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
PermitEmptyPasswords no

Further Securing Remote Login

In addition to the restrictions made on SSH, we should also further disable remote interactive login for root in case, mistakenly or maliciously, telnet or some other method of tty access was enabled again. Modify the /etc/securetty file. All lines except the TTY1 should be commented out. This is needed for console access. SSH is running its own daemon and is not affected by these settings.

# This file contains the device names of tty lines (one per line,
# without leading /dev/) on which root is allowed to login.
# for devfs:

Now this file should be protected by executing the following:

chown root:root /etc/securetty 

chmod 400 /etc/securetty 

this makes it so that only root can read the file and nobody can write to it, even root, until root chmod’s the file with more permissions again.

Modification to /etc/inittab

/etc/inittab has several settings in it that should be hardened. Disable Ctrl-Alt-Delete from shutting down the server, edit the default run level, protect the server even in Single User mode, and disable extra console login daemons (Ctrl-Alt-Fx) to further protect console access. See the settings made in Bold.

# The default runlevel is defined here

# First script to be executed, if not booting in emergency (-b) mode
# what to do in single-user mode
ls:S:wait:/etc/init.d/rc S

# what to do when CTRL-ALT-DEL is pressed. Comment to disable.
#ca::ctrlaltdel:/sbin/shutdown -r -t 4 now
The "3" in the id:3:initdefault line designates that the default run level is level 3 which does not load the GUI. The GUI can be loaded as necessary with the "startx" command but should not remain loaded or load by default on the server.

The line beginning with “~~:S” is the command for what to do in single user mode. (i.e. typing “single” as a boot parameter in grub — which now requires password access anyway). Change the “respawn” command to “wait.” This will prompt for the root password before continuing.

The “ca::ctrlaltdel:/sbin/shutdown –r –t4 now” line is the command to execute when Ctrl-Alt-Delete is pressed. This should be commented out as shown to disable this functionality and prevent someone with physical access from shutting down the machine without a valid login.

Xwindows – GUI protections

Although X-windows is not loading by default on the server, this could be changed easily by an administrator and it is available to load manually by changing run levels or typing “startx” at the console prompt. Therefore, implement the following extra safeguards:

Disable XDMCP
Remote machines should not be able to get an X terminal login window. Edit the following lines in /etc/X11/xdm/Xaccess to prepend them with a “!” as shown.

!*   #NO host can get a login window
!*   CHOOSER BROADCAST  #NO indirect host can get a chooser

Disable listening on port 6000

This prevents the X system from listening for X events from remote machines. Local X access at the console is not affected. Edit the config file /etc/X11/xdm/Xservers as shown below adding the “-nolisten tcp” switch to this line.

:0 local /usr/X11R6/bin/X :0 vt07 -nolisten tcp

Restrict cron and at

Cron and at daemons run processes on the system as root so access to them as well as the crontab command and files so that malicious code can’t be “scheduled.” The binaries are also world executeable and SUID to root so they can be dangerous. Restrict access to them with the following steps.

  1. Create cron.allow and at.allow files

    These files will restrict access to cron to only the users listed in the files. All others will be denied. The only user in the list should be root. These files don’t exist by default so you can create them with the echo command as follows. Delete any deny files. (/var/spool/cron/deny)
  2. # echo root > /etc/cron.allow
    # echo root > /etc/at.allow
  3. Modify permissions on cron/at related files
    Since all cron and at files are read and written to by processes that are SUID root, normal users on the system will not ever need to have direct access to the files so they should be secured to prevent tampering.
  4. # chown -R root:root /etc/cron* /var/spool/cron
    # chmod -R go-rwx /etc/cron* /var/spool/cron

4. LDAP Authentication Through eDirectory

Managing and maintaining passwd files can be a real beating. To make life easier, especially if you have a number of OES2 Linux servers about, configure local authentication to use LDAP and eDirectory, then simply add designated users/admins, to the LUM group and they’ll have local access. Also, root and other predefined local accounts are not affected. Follow the steps below.

  1. 1.Type yast at the command line
  2. Select the “Network/Advanced” section and then > LDAP client.
    Select “Use LDAP”.

    Add the LDAP server in the server field and the search base of where users are located. For example:

    Base DN: o=[org]
     Addresses of LDAP Servers:
     Select LDAP TLS/SSL. 
     Select “Advanced Configuration”
     User Map: o=[org]
     Password Map: o=[org]
     Group Map: dc=[org]
     Password Change Protocol: nds
    	Group member Attribute: member
    Select “Administration Settings” from the top of the box.
    	Configuration Base DN: o=[org]
    	Administration DN: o=[org]
    Select “Accept”
    Save your changes with by clicking Finish.
  3. 2.Edit the file /etc/nsswitch.conf and modify the following lines:
    passwd:		compat nam
    	group:		compat nam
    	passwd_compat: 	ldap	files
    	group_compat:	ldap	files

OES2 Migration

With the release of OES2 Linux, there are a number of migration utilities that have simplified the process. There are both Command Line and GUI versions that function basically the same and you can use to your own preference.

5. Data Migration

We will be migrating user data to a server that is in the same eDirectory tree and in the same container. We will use the GUI utility for presentation purposes.

From the OES2 Linux server, run YaST, select Open Enterprise Server and File Migration Utility.

Select Create New Project.

Specify the path to where you want the project file to be saved, or click Browse and select the path.

Click Forward.

Enter the Source Server (NetWare) IP address and the admin equivalent account in LDAP format and password. Ensure that Authenticate using SSL is checked.

Click Forward.

Click Add and select the Source and Target volumes you wish to migrate. Note: if you do not choose, the first volume on the list will be migrated.

Click Forward.

This screen is helpful if you can’t migrate all the data at one time and have to finish the migration at a later date. Or if there are certain files you do not wish to be migrated, like Mpegs or a user’s vast music collection.

If you have no changes to the default, click Forward.

This is your summary screen. Verify your migration setting and when you are satisfied, click Migrate.

Progress screen shows you the actual migration of the data. Once complete, you can view the log to see details. Click Close.

ACLs are also migrated with this utility.


The migration of DNS and DHCP is much improved with OES2 and much, much simpler. I will try to explain the process, since there’s not a lot of steps involved.


  • Ensure that DNS is not running on the NetWare server.
  • Login to iManager.
  • Click DNS and then DNS Server Management.
  • From the drop-down menu, select Move DNS Server and click OK.
  • Select the DNS Server name from the drop-down list. This will be the OES2 Linux Server.
  • Use the Object Selector to select the NCP (NetWare) server that will be migrated.
  • Click Move.

All primary zones associated with old DNS server will be migrated.


Start YaST, select Open Enterprise Server and Migrate Novell DHCP Server.

In the source server, put the NetWare server, in the target, OES2 Linux server.

In the DN for DHCP Server to be Migrated field, put the full DN for the source server.

NOTE: If you leave this field blank, ALL DHCP servers will be migrated to the OES2 Linux server.

Click Accept to start.

When complete, a message will pop up indicating success.

If there were any errors, you can examine the /var/log/dhcp-migration.log file on the OES2 Linux server. I recommend you look in any case, just to be sure.

7. ZENWorks Desktop Management v7 SP1 – Optional

Insert the ZDM 7 SP1 CD in the new server and browse to the mount point from the command line.


Copy the file, to /root/.

Edit the file and modify the following lines:


Remove Comment from:


USER_SUPPLIED_SERIAL_NUMBER=[Enter your Activation Code Here]

Save the file and change directories to /media/cdrom

Type the following to install ZDM7 on your server:

./setup -f /root/

When complete, dismount the CD.

In ConsoleOne, edit each NAL object to reflect the new path to the files on OES2 Linux Volume.

8. RSYNC – Optional

Migrating RSYNC is fairly uneventful accept for granting the proper POSIX acls to the NSS file mounts instead of default eDirectory acls.

Here is what needs to be changed and/or added and where.

On your main RSYNC Server, in the SYS:SYSTEM directory, there are several NCF files beginning with RS_. These files have numbers following the prefix that corresponds to a time that the file is executed. Find which file has the branch server reference in it and change that file to reflect the following:


rsync -vprtuz –stats –delete –volume=VOL1:
NETWARE_SERVER_NAME::NETWARE_SERVER_NAMEUsers /BACKUP/Branch_name/Users –timeout=360 –bwlimit=256


rsync -vprtuz –stats –delete –volume=VOL1: 
OES2_SERVER_NAME::OES2_SERVER_NAMEUsers /BACKUP/Branch_name/Users –timeout=360 –bwlimit=256

Change the NETWARE_SERVER_NAME to OES2_SERVER_NAME in the file for that branch you are migrating.

On the new OES Linux server, edit the file /etc/rsyncd.conf

Make the following changes:

uid = admin
gid = root
transfer logging = true
log format = %h %o %f %l %b
log file = /var/log/rsyncd.log
slp refresh = 300

	path = /media/nss/VOL1/users
	comment = (Branch name) Users
	read only = no
	chroot = no
	timeout = 60

	path = /media/nss/VOL1/share
	comment = (Branch name) Share
	read only = no
	chroot = no
	timeout = 60

Save this file and exit.

9. Decommission NetWare server

In ConsoleOne, remove the R/W replica from the NetWare Server.

Right-Click the Container Object for the branch and select Properties.

Click the Login Script Tab and change any reference to the NetWare server to reflect the OES Server –

From the console of the NetWare server, type NWCONFIG and press Enter.

Select Directory Options|Remove Directory Services from this server

Press Enter on the warning and Yes to remove Directory Services. Choose .Root. as the reference point. Authenticate and complete the removal. Exit NWCONFIG and type EDIT C:\AUTOEXEC.BAT. REMark out the statement to load server.exe. Save the file and exit EDIT.

Down the Netware Server and power it off.

In ConsoleOne, remove any objects not removed by nwconfig relating to that server.

10. Workstations

The only changes that need to be made on the workstations is, if you specify a Preferred Server, it will need to be changed to reflect the new OES2 Linux Server.


Open Enterprise Server 2 has many improvements for migration from NetWare AND Windows to OES2 Linux, including tree to tree migration. And with OES2 SP1, Domain Services for Windows will add to the migration possibilities.

3 votes, average: 4.67 out of 53 votes, average: 4.67 out of 53 votes, average: 4.67 out of 53 votes, average: 4.67 out of 53 votes, average: 4.67 out of 5 (3 votes, average: 4.67 out of 5)
You need to be a registered member to rate this post.

Categories: Uncategorized


Disclaimer: This content is not supported by Micro Focus. It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test it thoroughly before using it in a production environment.


  1. By:hmartin

    Your Migration Guide is very useful, but I see no mention of iFolder3.x.

    In OES1 this just plain didn’t work. We struggled for weeks and were then advised on the Forums to install iFolder 3.x on a NON-EVMS partition.

    We tried this and it worked until we rebooted the server after a power failure and no-one has been able to login to it since.

    Question – Does iFolder 3.x now work on OES2 or is it yet another fantastic product which Novell have shelved?

    • By:jawilliams

      iFolder 3.6 (with a soon to be released update) is available on OES2 with a host of new features and much improved functionality including:

      Multi-Server support
      Multi-Domain support
      Multiple storage locations
      Improved sharing
      Greatly enhanced web access
      Reporting tools
      New administration console

      This list is not complete. We will also be releasing an updated iFolder client for Windows Vista (32 and 64) as well as a Mac OS X client.

      Hope this helps!

  2. By:mfaris01

    First of all, thanks, I appreciate the feedback.

    iFolder 3.6 is now part of OES2 and does not require separate licensing.

    I did not include it because my organization is just now finding a need and it will be implemented later this year. Which also meant I had no real world experience with it.

    I have worked with it in the lab and iF 3.6 has several new requirements. It runs on Linux only and requires edir 8.8.2.


  3. By:rpwalter

    1st thank you for your article, but I do not agree with your recommendations for the installation routine.

    We install only SLES first, check if the system is ok and if reboot and power down works. We do not use EVMS – and not on the system drive. The standard machine has a drive for the system and additional drives for data volumes, e.g for volumes with nss; this is not a problem today. I think most enterprise servers are connected to a SAN. Then we install OES2 step by step: 1st we check the tree, 2nd we install eDirectory and NRM, check these applications and look if the tree is still healthy, then all other needed products.

    • By:mfaris01

      I used this for a remote, single server one might find at a branch office location. I agree with you on an enterprise server residing in a DC, connected to a SAN device. We have remote servers that are single OU and service less than 20 users.
      Thanks for the feedback.

  4. By:paulthing

    I have a question about ZENWorks and eDir 8.8 compatibility. In your guide you wrote:

    If you have a version of ZENWorks prior to 7 SP1, I would suggest upgrading to this version prior to introducing eDirectory 8.8 into your tree. eDirectory 8.8 does not replicate attributes of prior versions of ZENWorks.

    We would like to add some OES2 servers with eDir 8.8 into our tree. We will keep our replica servers eDir We are planning an upgrade to ZENWorks 7 SP1 but that will not be ready for a long time. The OES2 (8.8.x) servers will be in the tree, but not replica servers.

    Do you think this will cause a problem with ZENWorks?

    • By:stappend

      I’ve done this very thing and its fine, as long as your replicas remain on One thing to note, if you have less than three replicas in a partition then when you install the OES2 server into it, it will try and become one. I had that problem, it took some effort to fix.

  5. By:Anonymous


    This seems to deal with migrating from Netware to OES2. We are about to migrate from OES (sles 9) to OES2. Does anyone know the process for this, ie will the SCU on OES2 work equally well with OES to OES2 migrations ?


  6. Great information here. Many of these examples worked well in the labs I have been doing for customers. Keep in mind many customers will be moving from 32bit SLES9 on 64 bit hardware to 64 bit SLES10 sp2 on 64 bit hardware. Server to server migration with the target server tools would be your easiest path. In the case of single server inplace upgrades you will need to do some home work before you attempt at 32 bit OS to 64 bit OS swap. Remove all the OES applications from startup before you upgrade the OS. Then install the OES2 application stack.
    Clustering is another popular configuration, for customers that are running mixed NetWare and OES SLES9 nodes, I would plan on stopping this practice before moving to OES2sp1/SLES10sp2 this winter.

  7. By:anonymous

    Just like SLES10SP1 allows installing OES2 as an add-on module to make OES2-Linux, is there a similar method to install OES2 on top of Netware6.5 to make OES2-Netware?

    Netware 6.5 SP7 does not seem to prompt user to install add-on module as does SLES10 during install procedure, and runs to completion.

    Any idea?

    • By:mfaris01

      You can’t. NetWare is it’s own OS kernel and NW 6.5 SP7 is the latest version of that OS. OES 2 Linux is an addon for SLES 10 Linux. I think you’re confused because after NetWare 6.5 SP4, Novell referred to this product as Open Enterprise Server, which is true. Although, OES Netware and OES Linux are both Open Enterprise Server, they are still completely different OSes with similar features and functionality. More than likely to ease the transition from NetWare to OES2 Linux.

      Anyone else care to add to this?
      I think this may be more common than we think. My friend thought that BorderManager ran on Linux because the OS “Version” command stated Open Enterprise Server.

  8. By:lbonk

    Is there an updated document on this process, since EVMS has been dropped from SLES 11?

    Thank you!


    while performing the upgrade, the process needed to be interrupted, after the dib migration.
    now the netware 6.5 was locked, but a dsrepair fixed it.
    However the oes2 server is also locked and i did not find a way to unlock it
    any idea

  10. By:UNESCWA

    I found the below rollback option, but it did not work (sure the command that i used was with my server options)
    the server replied “This option is not allowed in OES”

    Anybody any clues other than reinstalling the server and OES


    /opt/novell/eDirectory/bin/ndsconfig add -t ‘treename’ -n ‘ou=context.o=novell’ -a ‘admin.novell’ -p -d /var/opt/novell/eDirectory/data/dib -D /var/opt/novell/eDirectory -B -L 389 -l 636 -o 8028 -O 8030 –config-file
    Now just re-execute the same command but add -w