Updated Release of the Transporter Suite

Well, I believe it will be a very interesting option in the future, but at this moment it is a little bit hard to install this tool in our production messaging environment with this kind of feedback.

Keep the good work guys, but don't ask us to use this tool without some kind of support ;)

Thanks

Is anyone else having performance issues with Transporter? The Hub Transport (where it's installed) appears to eat a CPU core while migrating users (brand new Xeon Quad Core 1.8GHz, not the fastest but still not exactly sluggish) and takes an age (20mins) to do 4,000 small emails with no attachments using command line PowerShell with 'quiet' switches.

The same copy - on a client PC running Outlook using the old "IMAP to Exchange profile drag and drop" trick, is so much faster - leading me to believe our performance problems could be caused by PowerShell, which hardly strikes me as streamlined having worked with creating and calling PowerShell Engines and Pipelines in C#. (No this isnt an option for a bulk migration, we have to have minimal user interaction)

Even if you do multiple mailboxes at once, and each uses a core, there is no way this will scale to doing over 2,000 users mailboxes in a reasonable time - some of which have over 10,000 mails.

We are also getting many warnings, possibly where subjects are blank and similar instances noted above by others. So even if we manage to get the mail in we arent at all confident about the quality of the data transferred.

Add to that the lack of proxyauth support (surely this was tested against non Exchange IMAP!?) mentioned above and things are going to be very very difficult.

Please Microsoft, give those of us willing to make the switch from a competitor a good way to do it. I spent a lot of time convincing people how great Exchange 2007 would be and plan to implement the full UM/OCS experience, hopes are high and I need to deliver something better than a crib sheet for users to perform a DIY migration.

hi bogit,
a0005 LOGIN "adminaccnt/testuser" "blahblah" is the way you logon to Exchange 2003 via IMAP using admin credentials (we use this syntax with the tool imapsync successfully) Maybe this works only for Exchange <2007 (KB 937359 says it doesn't work with 2007 any more) and the dev team didn't consider using PROXYAUTH functionality because you don't need it for the systems they tested with (only Exchange?)
anyway thank's for giving us the opportunity to discuss our problems here and maybe the guy who did this reads it and gives us a fix for that. a0005 LOGIN "admin/user" "adminpassword" doesn't work on Cyrus IMAP server :-( and I don't think that is the fault of Cyrus in this case.
Fabian

Update on the admin auth problem:

After sniffing the network traffic to work out what the hell the transporter suite is attempting to do with the admin account:

* OK [CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT LANGUAGE XSENDER X-NETSCAPE XSERVERINFO AUTH=PLAIN] testmailstore.kent.ac.uk IMAP4 service (Sun Java(tm) System Messaging Server 6.2-9.02 (built Apr 20 2007))
a0004 CAPABILITY
* CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ NAMESPACE UIDPLUS CHILDREN BINARY UNSELECT LANGUAGE XSENDER X-NETSCAPE XSERVERINFO AUTH=PLAIN
a0004 OK Completed
a0005 LOGIN "adminaccnt/testuser" "blahblah"
a0005 NO Authentication failed
a0006 LOGOUT
* BYE LOGOUT received
a0006 OK Completed

adminaccnt is the admin user, testuser is the user I'm trying to migrate, blahblah is the password.

I've never seen this format of imap login before and I can't find any reference to it - anyone any ideas?

What I really need is:

LOGIN "adminaccnt" "blahblah"
PROXYAUTH "testuser"

:-(

@I-AM: use the exclusion options in the xml file to avoid migration of those folders
@bogit: Administrator credential login doesn't work at our szenario neither. We've got a support call for that problem (login on to Cyrus IMAP4 Server) but I don't think that this will lead to success. I'm VERY disappointed about the fact that this tool has so many problems we have to deal with in the extremly short time frame of our migration! We will have to use an open source tool to migrate to 2k3 and from there to 2k7. This su***! And I can't really understand why the Transporter suite is unable to do proper folder mapping like INBOX to oldmail. This is something you have to consider before you release such a tool. People are relying on those tools guys! Don't make the same mistakes as with Exchange RTM.

We are looking at using this tool for migrating from Sun Imap server (JES3). While it appears to work ok in a quick test with the users password I can't get it working with an admin account at all. Interesting to see others reporting the same.

Has anyone got this to work without requiring the users account details on the source server? That's not going to be an option for us :-(

We are in the start/test of migration process from Communigate Pro(which has its own MAPI connector).

Before the last week, I used e2k3 and its Migration Wizard as IMAP transporter. I've found that some messages became empty after migration (winmail.dat parsing problem, I see). But all Tasks and Contacts Items where looking fine!

This week I AM trying to use Inet Transporter for Inet Mailboxes - all messages migrated very good.
But!!!
Now I can't migrate Contacts and Tasks!

Can anybody tell me
how to convert migated Tasks and Contacts to readable format.
or
how to make this tools to process only some folders, not all imap box
or
may be, there are any properties, that can I set in FolderMap.xml for folders to get good migrated Tasks and Contacts (ex. Do not parse = True)
???

Hi!

Our problem with the mails containing umlauts is solved. The colon in the displayname was not escape coded and therefor they were not migrated. We got a fix for that but we also discovered further problems. The feature with the administrator password to connect as a user to it's mailbox doesn't seem to work for us (as Onedin if you scroll up). That's kind of strange as the administrator has full permission on the users' mailboxes and the administrator password feature works with the Open Source tool imapsync so we don't understand why it doesn't work with the Transporter Suite.

I know this is not a support forum but it ssems as a lot of people have the same kind of problems here and it would be great if we could solve this out some way.

Fabian

Update from me:

Microsoft has worked diligently on this issue and we've resolved some of the issues I was having. We're actually seeing three distinct issues.

1. mails that are large (resolved) were not making it through. Resolution was to update the machine.config with maxRequestLength set higher. Be careful though, lol, I apparently messed up big time doing this once before. Note I have not been able to make this work by altering web.config in the EWS directory...
2. mails that have undisclosed recipient lists are not making it through. I believe Microsoft is working on this issue.
3. mails that have alternate character sets, particularly in the subject line, are not making it through. I believe Microsoft is working on this issue too.

Hi folks. I've been working with Microsoft support on this but thought I would post anyway. We're doing a migration to Exchange 2007 from SunOne (IMAP) 5.x. The tool does work (with individual username and password combinations... we haven't been able to get the admin password to work in this case) and the "story" is a lot better than a tool like Transend where you have to create a profile for each target user (thus you have to know the destination username and password too).

But we do see dropped mail. I've worked with Erik A. briefly and I'm working with MS on it. So far the dropped mail includes mail missing properties like the subject line, and mail that's very large, like 50MB mails. Unfortunately our customer has no mail send limits as a research institution. That said, we have set all Exchange settings for maximum message size to unlimited.

At the end of the day the workaround may be to have a good backup before we do this, and if the client screams, restore the email. It would just be better to be able to say "this tool will not drop any emails, regardless of how big they are or how blank certain properties may be in the source system".

Any thoughts or ideas from the community appreciated.