Migration Procedure for NMS4.15p7(NDS4.16) to iMS5.2(IDS5.1)
Hello,
I'm lost in this matter, because the sun documentation is too confusing concerning this procedure.My question is:
Can i migrate from Netscape Messaging Server 4.15 Patch7 using Netscape Directory Server 4.16 to iPlanet Messaging Server 5.2 with iPlanet Directory Server 5.1P1 or Netscape Directory Server 4.16?If Yes,HOW?
I am in Hurry. I need to know if this migration is possible or not.
Thanks in advance
Bests Regards
[496 byte] By [
706990] at [2007-11-25 8:47:01]

This should be possible. I think the best way to do it would be to first upgrade to 5.2 per the arcane instructions and then once that is done upgrade your DS's. Remember, Once you upgrade to 5.2 you will be running with TWO 4.16 Directory Servers (your original, which holds all the users/groups, and the one which is installed with 5.2- it holds the config data), that confused the hell out of me the first time I ran through it. So you should upgrade both of those. The docs for DS5.1 should have instructions for upgrading from 4.16.
Especially with my very simple set up. I just had one directory of users and groups, one domain, etc. I found it easier to export out the people and groups into LDIF files and write a sed script that "fixed" all the extries to match the 5.2 format. Then I just installed 5.2 clean and imported in the users and groups into the new schema and I was done. I didn't have to mess with the two directory servers, mulit-schema support or anything else like that. The few hours I spent write the scripts and testing more than made up for the headache of the migration doc's.
It is confusing, can you share the sed script you wrote.Thanks
#Old top level org domain was o=HCS
#Now storing in o=employees,dc=hcs
#replace this live with your old and new domains.
s/o\=HCS/o\=Employees\, dc\=hcs/g
#
#Delete all object classes except top, use that to add all new entries
/objectclass\: person/d
/objectclass\: organizationalPerson/d
/objectclass\: inetorgperson/d
/objectclass\: mailrecipient/d
/objectclass\: nsmessagingserveruser/d
/objectclass\: nslicenseuser/d
#
#Delete the nsmsgdisallowaccess: imap pop http setting
/nsmsgdisallowaccess/d
#Delete all nslicensedfor
/nslicensedfor\: msg/d
/nslicensedfor\: news/d
/nslicensedfor\: cert/d
/nslicensedfor\: calendar/d
/nslicensedfor\: slapd/d
#search for the top and replace it with all the entries needed
s/objectclass\: top/objectClass\: top\
objectClass\: person\
objectClass\: organizationalPerson\
objectClass\: inetOrgPerson\
objectClass\: inetUser\
objectClass\: ipUser\
objectClass\: nsManagedPerson\
objectClass\: userPresenceProfile\
objectClass\: inetMailUser\
objectClass\: inetLocalMailRecipient\
inetUserStatus: active\
mailUserStatus: active\
nswmExtendedUserPrefs\: meAutoSpell\=true\
dataSource: NDA 4.5 Delegated Administrator/g
#Change the memberurl, must do this before we can change the DN
#you'll need to look at your memberURL and replace
#the old dn with new DIT
s/ldap\:\/\/\/o\=HCS/ldap\:\/\/\/dc\=hcs/g
#Change all HCS DN entries to match the new DIT
#replace his live with your old DN and new DIT
s/o\=HCS/o\=Employees\, dc\=hcs/g
#
#Delete all object classes except top, use that to add all new entries
/objectclass: groupofuniquenames/d
/objectclass\: mailgroup/d
/objectclass\: mailgroupmanagement/d
/objectclass\: groupofurls/d
/mgmanjoinlocaltype\: MOG/d
/mgrpmsgrejectaction\: REPLY/d
/mgrpbroadcasterpolicy\: NO_REQUIREMENTS/d
#
#search for the top and replace it with all the entries needed
s/objectclass\: top/objectClass\: top\
objectClass\: groupofuniquenames\
objectClass\: inetmailgroup\
objectClass\: inetmailgroupmanagement\
objectClass\: inetlocalmailrecipient\
objectClass\: nsManagedMailList\
objectClass\: groupofurls\
nsMaxUsers\: 5000\
nsNumUsers\: 0\
mailDeliveryOption\: members\
preferredLanguage\: en\
inetMailGroupStatus\: active/g
#need to change the mg entries to match the new format
s/mgmanjoinability: Closed/mgmanJoinability: NONE/g
s/mgmanmembervisibility\: Closed/mgmanMemberVisibility\: NONE/g
#Need to fix the allowedBroadcaster entries
s/[m-M]grp[a-A]llowed[b-B]roadcaster\: uid\=/mgrpAllowedBroadcaster\: ldap\:\/\/\/uid\=/g
Above you will find the two scripts I wrote to convert from the old schema (4.1) to the new schema (5.2) for people and groups.
You should find a script in your slapd diretory called something like "peopletoldif" and "groupstoldif" run those programs and grab the resoluting files out of the ldif directory. Remove the top level entries in that file (There will be a top DN "o=YourOrg" and a "ou=People, o=YourOrg" remove those entries so that only people and groups remain.
Then run
"sed -f MigratePeople.sed People_2003_02_03.ldif >people.ldif"
You'll probably have to fix the sed scripts to fix anythin other than the default schema stuff (i.e. if you've added posixaccount and such, you'll have to fix the script to look for those entries as needed) My LDAP didn't have anything other than just the basic info for the people and that's about it. Once you install the 5.1 directory server and the 5.2 iMS, you can use the console application to import in the edited ldif files and test test test. Keep these things in mind...
1. My LDAP sctructure is VERY simple, no extentions, very simple groups, nothing strange, single tree only 4K entries.
2. My iMS install was PRE-Personal Address Book, you will have extra work if you use PAB, I can't help you there.
3. Use the files as a reference, they worked for me, they may not for you. Use them at your own risk.
4. Install all this stuff on a test server and test things out first. There are a LOT of changes in 5.2 and you should make sure everything works. There are a lot of things you have to index (check my previous posts for info) to get things up to speed.
Groups are the odd ones, you should really check those out well and think about NOT migrating them, but recreating them, it may be easier if you have issues with the sed scripts.
Once you have imported in the users and groups and you've testes things out, you can then migrate the message store as per the directions in the migration guide.
It's not too hard then, once you install iMS on the production systems, have imported the users, you copy or move over the mail store, rename a few db files and reconstruct the mail boxes, all should be fine. I would suggest testing this on the test server as well.
Test Test Test!!!
These are the steps I followed for my migration:
1. Install iDS 5.1 Patch 1
You can just install patch 1, it is a full install
2. Run ims_dssetup.pl on iDS install
3. Install iMS 5.2
4. Install Patch 1 for iMS 5.2
5. Change iMS 5.2 to Driect LDAP mode instead of dirsync
6. Install iES 6 (web server needed for Delegated Admin)
7. Install iDA 1.2p1 (Delegated Admin for web based user/group management)
5. Create two users to test (created user dadmin and test)
6. create indexes needed for direct LDAP mode, increase memory allocation for LDAP server (use console app)
7. Shut everything down and back up directories
8. Start everything back up
9. run sed script and import people.ldif and groups.ldif
10. Migrate store
11. test test test!
NOTES: You should use the -k flag (I think it's the k flag) for all installs and save the resulting install scripts so when you need to reinstall, you can use that script with the silent install flag and it will install EXACTLY as it did before.
You should shut down and back up the install directories BEFORE migrating the users, groups and store. That way if the sed scripts don't work, you can delete the directories and restore and try again. This will save you a lot of time installing and reinstalling. Also, the install scripts save time too. I installed everything in the directores like this:
/netscape/iDS
/netscape/iMS
/netscape/iES
/netscape/iDA
I can tar up those directories really quickly and restore them when I mess them up.
Follow the randmonly placed directLDAP info to increase performance. There is some info in the migration guide, some in the admin guide and some in the command reference guide. You MUST index the proper fields or performance will be very bad. I indexed the following:
inetUserStatus
mailUserStatus
inetMailGroupStatus
mailEquivalentAddress
mailRoutingAddress
mailMsgMaxBlocks
mailQuota
mailMsgQuota
mailProgramDeliveryInfo
mailDeliveryFileURL
maildeliveryfile
mailConversionTag
mailDeliveryOption
vacationStartDate
vacationEndDate
mailForwardingAddress
memberURL
rfc822mailmember
mailAccessDomain
mailMessageStore
preferredLanguage
mailAllowedServiceAccess
Also, read the migration guide. It's very full of useful info about the new DIT structure and how things work.
All of the above was on solaris 8, if you have NT, those sed script probably won't work. I tested out these scripts and installs over the course of 3 weeks before final deployment.
I tested on a server with the EXACT SAME config as the deployment server. Same name, same IP address, everything. It was on a seperate network obviously to prevent duplicate IP addresses. This ensured as few problems with migrating as possible.
Some things I ran in to:
DO NOT USE VANITY DOMAINS! They will hit your LDAP server HARD. Create the other domains once your server is up and create the users and forward the mail to the other users. Vanity domains came "free" with 4.15, but with 5.2 in direct LDAP mode, the MTA has to query the LDAP server MANY times for each email receipient for data that usually isn't there. The performance hit is substantial.
Learn the new queue managment with the imsimta CLI app to monitor things.
Don't forget to imsimta cnbuild to rebuild the imta config files. whenever you change the config files for the imta, you'll probably have to run the cnbuild to make the changes, then restart the smtp processes.
The new webmail Messenger Express is less stable than 4.15. Mine core dumps a lot more than it did. Invalid indexes in the store are usually the cause. reconstructing the mailboxes usually fixes the problems. Sun support can help with that stuff. I use a little cron job to check for the processes and restart the webmail processes if they are gone.
Hello,
I just wanted to add my experience.
1.) Please DONT follow the migration guide. You will end up with two directory servers and a worse scenario than when you started.
2.) If you are on NT or dont want to use sed, just use the migration script that comes with IMS. Use imsdirmig executable migration script that is in <install files>/migrate/bin/msg/migrate/bin
This runs agains a 4.x directory server. I used a dummy server on my desktop,. imported the users ldif, set up multi- schema support, ran imsdirmig, exported the ldif file (o=yourorg.com only). Once you have this file all you have to do is find/replace o=yourorg.com with o=yourorg.com,o=isp
Install the 5.x directory, 5.x messaging, the IDA, and web server, (using o=yourorg.com,o=isp as the messaging defaul t DN). You should now be able to import the users from the ldif you just exported and ran the replace on.
then copy your message store, run reconstruct -m followed by reconstruct -r, startup the server and your done!
