Messaging 6.3 Migration

I would like to get some of the experts opinions on here regarding our Comms 5 migration. We are upgrading/migrating a 40,000 user mail environment from Sun One Directory 5.1 and Messaging Server 5.2(schema 1) to Directory 6.0 and Messaging 6.3 (schema 2) plus adding Calendar services. I have followed these steps as seen in the forums(which seems to match our requirements):

1. install directory server.

2. Run comms_dssetup.pl and select Schema 1.

3. export/import my ldif file. (3 Files the DC root suffix(o=internet), the OSI root suffix(o=abc.com),

4 Run commdirmig

5. install Access Manager/Identity Server

6. install/configure messenger and calendar

The problem I run into is the commdirmig does not seem to do anything, or not finding what it expects in the directory. Here is my syntax:

./commdirmig -t 1 -D "cn=directory manager" -w /opt/SUNWcomm/bin/pass -X server -p 389 -a /opt/SUNWcomm/bin/migration.ldif2 -b "o=internet" -r "o=abc.com" -v

The commdirmig runs for a few seconds then stops with nothing in the ldif file. The following are the only entries in the commdirmig.log file:

Wed May 30 14:00:27 EDT 2007 ^^ sun.comm.dirmig.commDirMig.migrateDirectory(commDirMig.java:151)

Wed May 30 14:00:27 EDT 2007 ^^ sun.comm.dirmig.commDirMig.main(commDirMig.java:89)

The following is the what it seems to be searching for in the Directory, which is not there:

[06/Jun/2007:10:06:17 -0400] conn=24 op=1 msgId=2 - SRCH base="ou=default,ou=organizationconfig,ou=1.0,ou=iplanetamauthldapservice,ou=se rvices,o=internet" scope=0 filter="(|(objectClass=*)(objectClass=ldapsubentry))" attrs=ALL

[06/Jun/2007:10:06:17 -0400] conn=24 op=1 msgId=2 - RESULT err=32 tag=101 nentries=0 etime=0

I have no ou=services,o=internet branch, should that be there?

In the Migration Guide under the 'Single Server - Migrate to Native mode' the steps seem to be

1. upgrade Messaging Server from 5.x to 6. Which for our case is on a new server so we are just doing a fresh install of Messaging 6.3.

2. Run the comm_dssetup.pl

3. Install Access Manager 6.1

4. Install DA

5. Run commdirmig to migrate from schema 1 to schema 2.

We are essentially migrating to a completely new environment with all new hardware and softwar, then migrating the users and mailboxes from the old environemnt to the new environment in a short outage. Any help would be greatly appreciated.

Thanks

[2510 byte] By [mdpiot1a] at [2007-11-27 6:36:46]
# 1
You have to tell imsdirmig where your "internet branch" is.by default, it was "o=internet".I can't know where yours is, and neither can imsdirmig, unless you tell it.
jay_plesseta at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 2

Thanks for the quick reply Jay. I Just want to double check, when you say imsdirmig, you are referring to the commdirmig script? Two of the required parameters are

-b OSIRoot the root suffix of the OSI (Organization) Tree

-r DCRoot specifies the root suffix of the DC Tree

I specified for -r o=internet under which the only two entries are:

dc=com,o=internet

dc=abc,dc=com,o=internet

Then for the -b I specified o=abc.com, the domain we are migrating is o=mail.abc.com,o=abc.com.

Is there something else I am supposed to be specifying? Thanks for your help.

mdpiot1a at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 3

Yeah, I don't do enough of these to remember the actual commands.

commdirmig it is.

Since commdirmig isn't looking in the right place, the obvious thought I had was that you weren't specifying it correctly.

The good news is that Schema 2 isn't all that hard to handle.

If you export just your users/groups tree, you can install the server for schema 2, and then just import your users after you specify your domains and such. That's pretty easy t handle, and just ignore the dirmig tool.

jay_plesseta at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 4
Ok, I'll give that a try and the only other data i would need to copy over then is the personal address book entries under o=pab. I'll let everyone know how this works out.
mdpiot1a at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 5

The one part of this I am trying to understand is what does the commdirmig tool do then? I thought one thing it did was update the users entries by adding in the appropriate needed attributes for schema 2.

If I run the comm_dssetup.pl and specify schema2, then import my users/group tree(which come from a schema 1 directory) will the entries be all set to go for schema 2 with access manager?

mdpiot1a at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 6

Honestly, I've never quite gotten the dirmig tool, either.

I've migrated from 4.1 to 5.1 to 5.2 to 6.1, 6.2, etc.I've never used the dirmig tool in any of the names it had.

Schema 1 is one variation/subset of Schema 2.If you're worried about missing an attribute, check the automatically created user entry for the admin user, and see if there's anything missing in your user entries, and add 'em.

jay_plesseta at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 7

We just upgraded from 5.2 to 6.3 and used schema 2 immediately. The difference was in some object classes for each person's record.We created a new email user on the new system and then compared that record to a record from the old system. We inspected how the record's objectclasses varied. Then we did a "db2ldif" dump on the old machine; removed everything except user records and inserted the new objectclass lines and a couple of lines like "inetCOS" and "mailAllowedServiceAccess" via a text editor macro (I like emacs :-). for each record. We then did an ldapadd and voila, our new database was populated.

The groups were a different story. Since schema 2 used two records for each group, we decided to recreate the group records by hand and then used ldapmodify to add the user's to each group. Since we had only about 90 groups, that was not such a big deal for us. Your Mileage May Vary.

I wrote a few Perl scripts that pulled and separated the old database records so that we could easily import them to the new database. I'm willing to share.

Hal

halsria at 2007-7-12 18:04:48 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...