Beige Paper: Migrating from NetWare 6.0 SP4 with NetMail 3.1f to OES Linux and NetMail 3.52
Novell Cool Solutions: Feature
Digg This -
Posted: 26 Jan 2006
The company is a medium sized ISP. Our task was to replace a single NetWare server running NetMail on old hardware, with a new OES Linux sever running on new hardware.
The old environment was a NetWare 6.0 SP4 sever with NetMail 3.1f. It was a single server tree with a single OU for all 7500 users. The hardware included a Dell RAID 5 with 30 GB. The file system was NSS. Using McAffee for virus protection.
We were migrating to OES Linux FCS with NetMail 3.52. The hardware is a HP duel Zeon P4 3 ghtz with 2 GB RAM and Raid 5 for a total of 546 GB of SCSI Storage with a Raiser file system. The new system is front ended with a SLES server running Spam Assassin and Amavis antivirus to preprocess all email.
We had to replace a NetWare server with a OES Linux server with NetMail overnight, and the users could not notice a difference or lose any incoming mail. We performed the migration overnight and when the users came in the next day everything worked, and no one was fired. This was a week long process, but the downtime was minimal and the actual migration took only a couple of hours. The migration was scheduled to occur during normal maintenance downtime in order to minimize network disruption.
Administrators should email the users and give them a heads up about the upcoming migration. If the users will delete old emails the file copy will be faster.
- First we ran Deployment Manager on a windows client from the OES NetWare CD to update the schema on the NetWare server.
- Verified that time was in synch (normal NetWare time synch verification, see NetWare documentation for time synch debugging).
- Installed new OES Linux server using the defaults which included the Reiser file system. Placed new server into the existing NetWare tree, making sure to use the same time source.
- After rebooting the Linux server make sure the eDir replicas were in synch.
- Install new NetMail 3.52 on the linux server, make sure that this installation of NetMail is servicing users in a different context than your old NetMail. You must not have two installations of NetMail servicing the same user context. That is bad.
- Configure new NetMail for your environment. Some gotchas we encountered were:
- WEBADMIN - Entering a user into the system should not be a two step process in WEBADMIN we have to go to two screens to enter the user then add their supporting info IE (Phone number, etc),
- WEBADMIN - The 7500 users are all in the same context and FIREFOX takes forever attempting to build the user list and eventually hangs, The workaround to put on a filter and then browse is a klunky two step process.
- WEBADMIN vs ConsoleOne - ConsoleOne actually works better for the customer because even though their is two screens for entering users it automatically takes them to that screen, The customer wants to stay with ConsoleOne because it is more usable than WEBADMIN.
- WEBADMIN - Customer needs a way to see which accounts are assigned to a specific Phone number. If the Phone number isn't paying or they move they can query on the phone number (same as account number in system), and disable all of those email accounts. Customer couldn't find a way in webadmin to do this.
- 48 hours before the migration we added a DNS entry for the new server. This gives time for this data to propagate to the rest of the network world. Make sure that NetMail is not running on the new server. This way everyone knows about both NetMail servers, but only the old server is accepting mail.
- Copying the data. We copied the data the day before the migration. This assured that we minimized the down time on the migration night. To do this we set up FTP on the NetWare server and exposed the data volume to the Linux server. Then we used wget with the ?timestamp option to copy all the data from the NetWare NSS volume to the Linux Reiser volume. When migrating the data make sure that the old and new servers are on the same network segment. We initially did not do this and even though the servers were local they were on different networks and the data was traveling over 20 hops and 2/3 of the United States (live and learn). This caused the data migration to be VERY slow, until we fixed it by adding another network card to the NetWare server. Do a sample file copy test to validate the data migration speed. We did not use Rsynch to copy the data because there is not a supported Rsynch version on 6.0.
- On the night of the migration we did not send out any warning emails because it would put new mail data in every users account and we wanted to minimize the deltas. We ran the wget ?timestamp one more time to fully synch the data. This took about 20 minutes because we had already captured all the data the day before - we only had to copy the deltas. Then we turned off NetMail on the NetWare server and did one last wget ?timestamp to assure data was in synch.
- Start NetMail on the Linux server and tell it to service the users context that was being serviced by the old NetMail server.
- Edit autoexec.ncf and remove IMS so NetMail will not start when the NetWare server was restarted.
- Send a few test emails to make sure it is all working, that mail was both coming in and going out.
- Promote the eDirectory R/W replica on the Linux server to Master, which demotes the NetWare replica to R/W.
- Power down the NetWare server and retest emails and make sure that eDirectory is happy (see eDirectory documentation)
- Bring NetWare server back up and follow eDirectory procedures to remove this server from the tree (see eDirectory documentation). If you do not do this you will have replicas out of synch and you will have to manually remove (through ConsoleOne) the server from the tree. We did not follow the eDirectory procedures and were getting eDirectory 699 trying to synch replica errors because eDirectory was trying to communicate to the non-existent server.
- Power down the NetWare server and use as boat anchor.
- Post installation known issues that we encountered:
- NetMail/IMANAGER integration - These should somehow automatically coexist on the same box and other OES components (ie switching to different port number etc).
- NetMail Performance on Shutdown is slow - Is there anything we can do to have these processes shut down faster for when we need to make changes and restart NetMail (licenses, mailbox size limitations, stuff in general), It was slow enough to generate calls if we need to restart.
- NetMail Bogus error messages - If NetMail and/or webadmin is already loaded and we attempt to start it we get a ton of unloading error messages so we thought things weren't working but it was because it was already loaded DUHH. It caused us 15 min of needless stress and pointless troubleshooting. :-) How about something like "xxxx processes already running"
- Another issue we have seen is the inability to restart a single NetMail daemon. For example, we needed to make a change to some settings for web access, and for those settings to be applied modwebd needed to be restarted. The admin guide says to kill the process with a -15, but that never shut down the process. Using a -9 did shut down the process, but unlike what is stated in the admin guide, IMS did not reload the process. We had to shut IMS all the way down and restart it just to get a couple of minor changes to work.
The new server has been up and running for two months without any problems.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com