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:
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 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.