Over the past couple of months, I have been involved with migrating remote NetWare servers to Open Enterprise Server 2 (OES2) Linux. During this time, there are some lessons that have been learned that hopefully this article will be able to help you, the reader, perform your own migrations more smoothly and avoid some of the pitfalls we encountered.

For organization purposes, I have put the issues and resolutions into group headings based on purpose, like printing or DHCP. There will be general issues and how we overcame them in their own heading.

There are now many sources for information on migrating NetWare to OES2, of which I have authored several, so your choices are not limited to just the Novell documentation, although very helpful. The forums are a very good source for, “What do I do’s” and “What does this mean?” questions. I will be addressing specific issues that were encountered repeatedly and what was done to correct or resolve the problem.


Locater Objects and disappearing Zones

When installing or configuring OES 2 in a production tree with DHCP already present, when specifying the context of the dhcpLocator and dhcpGroup objects, ensure you specify the up-most location of the existing dhcp objects, when you run your DNS/DHCP utility, the zones will appear to be ..gone.

If this happens, don’t panic, your zones are still there in the tree, it’s just you’ve defined a new locater and it doesn’t know about the existing zones. If you use iManager or ConsoleOne, you’ll see the zone and subnet objects in the tree.

Remove the newly created locater objects in the contexts you specified when you installed or configured DNS/DHCP and then start your DNS/DHCP Utility and everything will appear as it should.

DHCP Daemon Fails to Load

When running dhcpd on the OES2 Linux server the first time fails and reports the error, “insufficient credentials.”

The admin account that was used to initially install and/or configure DHCP in OES2 has changed his/her password in eDirectory or is no longer valid.

Utilizing services for OES2 on Linux that use eDirectory access require an admin or equivalent account for the service to access eDirectory. This key pair is encrypted and stored in a hash on the SLES server and is used by these services. If the account’s credentials change, then the access fails.

Launch YaST and OES Configuration and enter credientials for an account, we used a system type account, with admin equivalence and exempt from Universal Password Policies to ensure normal password change intervals are not enforced.

Upon saving your configuration, the service loads normally.

Location of DHCP Objects Post-Migration

After the migration of a location that includes migrating DHCP, you will notice that in the base container, or your base Organization, there will be an object called,


This is the DHCP service objects for OES-DHCP Linux. This service can be moved to the desired container as long as it can be walked from the root to the DHCP server object itself. In other words, if your DHCP Server object is located in OU=NewYork,OU=Eastern,O=US, you can place the DHCP Service object in any of these containers. If you placed your DHCP Service object in OU=DHCPStuff,OU=Eastern,O-US, the DHCP Server object would need to search to a lateral container and it wouldn’t find it.

If you create a new DHCP Service object in the tree, you can specify the container that the object is created.

Both scenarios were performed during the migration and it was found that creating new DHCP services and subnets was more efficient and using the migration utility.


Migrating from NDPS to iPrint produced it own challenges. Once again, migrations were performed with the migration utility and some were performed by simple creating new IPP printer objects. And Again, it was found more efficient in both reliability and time to create the iPrint objects, Driver Store, Print Manager and Printers from scratch, especially in smaller locations. If you have a large, 100+ printers, definitely use the migration utility.

Assigning printers to users was used by running an LDAP search against the users in a particular container and retrieving their current NDPS printer assignments.

ldapsearch -x -h [servername] -D "cn=admin,o=org" -W -b "ou=newyork,o=org"  objectclass=inetorgperson ndpsPrinterInstallList ndpsDefaultPrinter >newyork.ldif

This command will create a text file with the users DN and the printers assigned.

It also informs you which printer is the user’s default printer.

It will look something like this:

## newyork.ldif

# extended LDIF
# LDAPv3
# base <ou=NewYork,o=Org> with scope subtree
# filter: objectClass=inetorgperson
# requesting: ndpsPrinterInstallList ndpsDefaultPrinter

# TKing, NewYork, Org
dn: cn=TKing,ou=NewYork,o=Org
ndpsPrinterInstallList: cn=HP4000-1,ou=NewYork,o=Org
ndpsPrinterInstallList cn=HP4000-2,ou=NewYork,o=Org
ndpsDefaultPrinter: cn=HP4000-1,ou=NewYork,o=Org#1246908645#1

# RJames, NewYork, Corp
dn: cn=RJames,ou=NewYork,o=Org
ndpsPrinterInstallList cn=HP4000-1,ou=NewYork,o=Org
ndpsPrinterInstallList cn=Xerox5632-3,ou=NewYork,o=Org
ndpsDefaultPrinter: cn=Xerox5632-3,ou=NewYork,o=Org#1246728603#1

what we want to do is take this list and modify it to reflect the new IPP Printers and then do an LDAP Modify to add them to each user.

If we create an IPP printer and then assign it to a user, there is an eDirectory pointer that is assigned for that printer. In ConsoleOne, if we look at the user we assigned the IPP printer, and click the Other tab, we can see this code pointer.

Look at the attribute, iPrintiCMPrinterList. Expand the attribute and there will be a 10 digit number. Write this number down. Now, below that 10 digit number will be a numeric value of 1 or 5. 1 means the printer is assigned to that user. 5 means that that printer is the user’s Default Printer.

Create a new ldif file, I used the existing output from the query. Replace ndspPrinterInstallList: with iPrintiCMPrinterList: append #[ten-digit-code]# to the end of the entry and place a 1 or a 5, remembering that only one printer can be the Default. It should look similar to this:

iPrintiCMPrinterList: cn=HP4000-1,ou=NewYork,o=Org#1246908645#1

Add to each user entry, iPrintiCMPrinterFlags: 1, this allows the modification of the users IPP printer assignment.

Remove the line stating the ndpsDefaultPrinter

The above users entries should look similar to this:

## newyork.in

# extended LDIF
# LDAPv3
# base <ou=NewYork,o=Org> with scope subtree
# filter: objectClass=inetorgperson

# TKing, NewYork, Org
dn: cn=TKing,ou=NewYork,o=Org
iPrintiCMPrinterList: cn=HP4000-iPrint-1,ou=NewYork,o=Org#1246908645#5
iPrintiCMPrinterList: cn=HP4000-iPrint-2,ou=NewYork,o=Org#1246908645#1
iPrintiCMPrinterFlags: 1

# RJames, NewYork, Corp
dn: cn=RJames,ou=NewYork,o=Org
iPrintiCMPrinterList: cn=HP4000-iPrint-1,ou=NewYork,o=Org#1246908645#1
iPrintiCMPrinterList: cn=Xerox5632-iPrint-3,ou=NewYork,o=Org#1246908645#5
iPrintiCMPrinterFlags: 1

Now, once you have your printers created and the PrintManager and Driver Store are loaded and running, run the following command from the OES 2 Linux server to add the users’ printers.

ldapmodify -x -h [servername] -D cn=admin,o=corp -W -f /path/newyork.in

If you don’t get any errors, you can verify the settings in ConsoleOne or through iManager – iPrint User Management

Removal of the old NDPS printers from the user’s local profile is fairly simple. Once your migration is complete, remove the NDPS Manager and the NDPS printers will be removed from the users’ workstation the next time they log in. You must still delete the NDPS objects from the tree manually.

The above process for printer query and assignment was developed for our team by Michael Bruner. Pretty Sweet process and a big time saver.

File System

File system migration is fairly straightforward, keeping in mind some gotchas that could pose a potential hair-pulling session.

  • Make sure that any virus scanning software on both the Source and Target server is offline and not running. Although it would catch any potentially infected files, some features could prevent the file copy altogether and ultimate failure of your migration.
  • Migrate non-user data first. Directories like, Zenworks and static type directories can be migrated without worrying about them changing while the migration is in progress. We migrated this data during the day and then the user data after hours and this saved a lot of time waiting for 10+GB of data to copy from one server to the other.
  • Migrate user data separately and perform a preliminary migration during regular hours, then perform a Sync of the data after hours to catch any files that might have changed.
  • Once all the data has been migrated to the new OES 2 Linux server, dismount your data volume on the NetWare server. This will prevent users accidentally mapping a drive or having a local mount point to the old server.
  • Unless you are doing a Transfer ID migration, change your login script to reflect the new servername once the data is migrated. This will also prevent remote access users, VPN, etc, from logging to the old server while you are still finishing up. Disabling login on the old server will only prevent you from migrating anything.


Let your users know that the first time they login the next day, that in general, the login will make some backend modifications and, if you run ZENworks Novell Application Launcher, (NAL), the client will re-cache everything and it’s going to take a few minutes. Also, SLP and iPrint will take a few moments to install any printers assigned prior to migration.

If you use RSYNC for backup, make sure that port 873 is open on the OES 2 Linux server. The errors you get are confusing and seem to be DNS related when it’s simply being blocked at the server.

Post Migration Issues

There are a couple of things that have been observed post migration, mostly related to the clients, mainly SLP. OES 2 uses OpenSLP and if you have an UNSCOPED setup, you’ll need to add the DA’s to each workstation’s registry either manually or through an application push. Same with the iPrint Client. Do these items a week to two weeks prior to migrating and you should have no “Tree or Server Cannot be Found” the morning after migration to OES 2 Linux.

We did not migrate iFolder, NTP or FTP as these were not part of my current environment. When the servers were built NTP was set up independently.


Migrating to OES 2 Linux has been a wonderful learning experience and also, a lot of fun. We had some nail biting moments and gained far more Linux knowledge than we had when we started. I hope this information is helpful to you in your own migration process.


(Visited 1 times, 1 visits today)
Tags: ,
Category: Open Enterprise Server on SLES, Technical Solutions
This entry was posted Tuesday, 14 July, 2009 at 1:38 pm
You can follow any responses to this entry via RSS.


  • Magic31 says:

    Hi Mike, thanks for sharing & good sum up of things to watch out for!

    To add some pitfalls we also encountered:

      Check the oplock setting:

    The default oplock setting (2) was giving issues with some applications after we migrated over. We’ve switched to setting the default to 1.
    As added extra set the NCP cross_protocol_locks to 1. – not sure if this would be a best practice, but so far these settings work best for our environments.

      nss resync:

    when directly moving a Netware NSS volume over to an OES2 Linux server (e.g. when dealing with SAN storage , Clusters or InPlace/Install over scenarios), we found that rights granted on [Root] & [Public] and also revoked rights assignments (where an assignment is made to an object without any rights selected) don’t get placed in the NCP trustee.xml. These have to be reset manually (as far as we’ve encountered).
    Always a good practice to first run a TRUSTEE.NLM export on the Netware side so you have all the rights documented if you need to check or reset them later.

      Bindery context setting:

    With Netware we’ve always had the (super) bindery context setting pointing the container holding the server (and sometimes also the users). This container often holds special accounts that, for instance, offer a flat login for these special accounts (like services on Windows needing access to a Netware UNC location)
    This setting is not used by default on OES2, you can set it by adding the ‘ n4u.nds.bindery-context ‘ parameter in the nds.conf file.

    Netware still has added value to keep it running alongside the new OES2 systems. If you rely on services like the SLPDA with eDirectory integration , (nw)FTP and legacy application or client support, don’t fase out all your Netware systems just yet. you might want to keep one up and running until all legacy systems are updated.


  • mfaris01 says:

    Thanks, Magic31! Nice additional insight. There was one thing I did not add, but will now, concerning McAfee and NSS Volumes.

    If you scan NSS volumes, and you should, (pesky Win32 users), Make sure you exclude the ._NETWARE directory and anything below it. McAfee will hold trustees. files open and not allow them to update and corrupt your NSS ACLs for that Volume.
    I don’t know about other VS software, but McAfee mentions this on their own site as an issue.
    Thanks again,

  • Leave a Reply

    Your email address will not be published. Required fields are marked *