I have justÂ completed what initially sounded likeÂ a fairly straight-forward project – install Exchange 2007 and migrate 35 mailboxes from Lotus Notes. The migration would be one-shot – so no need for a coexistance phase.
Such a small migration didn’t seem to warrant the purchase of Quest or Transend – and besides, the Microsoft recommendation is to use their very own, freely supplied Transporter. Having only ever used the IMAP migrator before, and with no problems,Â I went blithely into the project, assuming it would all be straight forward.
Well let me tell you – next time I’m going to push for the 3rd parties! Getting Transporter working was hard, keeping it working was hard, and certain emails were, for no apparent reason, un-migratable. However, if you do find yourself having to work with this tool, here are a few tips.
I installed Transporter on a workstation, and we then took an image and installed it to a second workstation so I could have a backup. The migrations were so slow and buggy that the second station was a lifesaver – and even then it took 3 days to move the 35 boxes!
Both workstations had 2GB of RAMÂ and seperate 100MBit network cards to connect to the networks hosting the Notes and Exchange servers. They were running Windows XP.
- AÂ Lotus Notes client, which has, most recently,Â been logged in using the Notes accountÂ for the migration. The Notes account must have minimum of Read access to names.nsf, catalog.nsf, and all the mail DBs.
- The Exchange Management Console, along with all the powershell and hotfix requirements for that.
I had various bizarre errors on the way to getting the tool working. I posted about it on the appropriate technet forum, so if you’ve come here looking for answers you may well have seen this already: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=3937164&SiteID=17
..is hopeless, don’t even bother. Here are the scripts I wrote to get the mailboxes migrated, and set some full access permissions.
The MailboxÂ Migration
After realising how slow the migration would be (15 mins for a 500MB mailbox) I made a plan to do a pre-migration on a thursday and friday, followed by an incremental migration (just the mail arrived since thursday morning) on the Sunday. The mail routing was changed on friday afternoon, at close of business.
The biggest problem I had with the migration itself was that it stopped working after a period of time. Once this error started appearing:
An item has failed property validation and will be ignored. Identifier: (Name: item name) Error details:Required property is empty. Property:TargetServer..
then it was all over for that session. I would have to shut down the Transporter Command Tool and start all over again. This meant I had to babysit the entire migration, rather than what I’d hoped to do – ie., leave itÂ running as a batch job.
The failure rate seemed to be around 0.1-0.2% – doesn’t sound too bad, but in a mailbox of 15,000 items this could equate to 30 items left behind. I had to spend a lot of time trawling the logs to manually produce a report for each userÂ listing the unmigrated items. If any were important the user was oblidged to go into Notes, find the item, and forward it to themselves. I expect that this would be completely unacceptable inÂ many environments.
The encrypted messages were expected to fail, and I think this would be the case with the 3rd party utilities as well, butÂ how to explain the ones whereÂ the error wasÂ simply “could not create item”? There were some other errors which may or may not have been associated,Â saying “type must be specified for non-SMTP addresses” – however I could find no way to specify the type, and the messages themselves didn’t appear to be any different from others that were migrated successfully.
There is also a problem with reoccuring calendar items.Â If you’re going to use this tool, make sure you warn your users that they will probably need to recreate their reoccuring events.
Transaction Log Files
Another gotcha was the huge growth in transaction log files when pumping this much data into the Exchange server. A full backup followed by incremental backups every 15 minutes (no, really) kept the situation under control.
Address Book Migration
I managed theÂ shared address book migration by exporting to a csv file and then creating contacts in AD using a couple of scripts. As usual one method was not enough – the powershell cmdlet New-MailContact won’t work if the contact doesn’t have an email address – however it is perfectly possible to create non-mail contacts manually or with vbscript.
The personal address books were migrated using the Transporter. Initially I thought that part was pretty good – however it turned out the user’s personal distribution lists did not get migrated, and for some users this was a real problem. I thought to use something like this scriptÂ to create the lists from a PST, but in the end time was too short, and some poor mug had to create them by hand.
But not before running into this Outlook restriction.
It was all harder and buggier than I expected, with absolutely no documentation on the various error messages encountered – however I did get there in the end, with only a little bloodshed. I might use the Transporter again for a small, low-key migration – but for anything larger, time sensitive, or involving a co-existance phase, I will strongly recommend using a 3rd party utility.