The horrors of migrating to Domino when Single Item Recovery is in use on Exchange

Here's a new one for ya, true believers.

The past couple of weeks I have been involved with migrating email users from a recent acquisition my company made to Domino from Exchange.  This is a process I have done many times in the past and when using CMT from Binary Tree, it's a very straight forward but drawn out task. However, this time posed a bigger challenge. One that I have never encountered before.  And it was a pain.

Like migrations in the past, I've relied on someone who understands the dark arts of Exchange to supply me with a .PST copy of the mail files for each of the users.  This migration was no different and I had a support person on site do that for me.  But after migration was done, I was getting a lot of reports that peoples calendars were all buggered up.  Upon investigation, I looked at a users Notes calendar and saw something similar to this:

Ya.  That doesn't look right, does it?

But when I opened their .PST file in Outlook, those repeating calendar items were only in there once.  I also noticed that in the .PST files, there were also folders called "Recoverable Items".  Have never seen that before in my migrations, it was off to the interwebs!  After consulting Google, I found the answer.  The Exchange server was set up to use Single Item Recovery, (you can read more about it here. The more you know!).  In Exchange, Single Item Recovery is a function that allows users to delete and edit things in their mail file while keeping a copy of everything they do tucked away in a "dumpster".  As what normally happens with calendar entries, there were a lot of edits to those repeating meetings, so when the onsite tech person did a standard migration to a .PST it included all of the "dumpster" data with it.  When CMT opened the .PST and started the migration tasks, it saw the information in those Recoverable Items folders and acted upon it like any other data, hence all of the deleted emails and calendar entries were merged into the Domino mail file and caused a mess.  Harrumph.

Luckily, CMT has a great function that keeps track of all the migrated items and will remove them from Domino if needed.  I had to go through and do that for all those users.  I then posed the question to Binary Tree if there was some way to do the migration without migrating anything in the Recoverable Items folders but was told that it can't.  CMT will do anything in the .PST.

So after some more Googling, the team found the the magic key.  The .PST's needed to be generated with the following Powershell command.

New-MailboxExportRequest -Mailbox UserName -ExcludeDumpster:$True -FilePath \\filelocation\UserName.pst

Once my onsite person migrated the Exchange data to new .PST files, they now didn't contain that "dumpster" data and were then migrated into Domino just fine.  Whew.  

So if there is ever an instance in my future where I have to migrate a .PST to Domino, the first question I'm going to ask is is Single Item Recovery is in use.  And if there is ever an instance where you have to do a migration, never overlook this either.

A postcard from along the "Migration Trail" - Revisited

While I'm sitting in my hotel room awaiting completion of a few mega .pst files to finish being converted into a Domino mail database, I remembered I wrote a post about migration a while back.  Kind of weird that it's almost 3 years to the day I wrote it.  Even more funny that most of the post still holds true.  But this time, I did have to travel.  I have to be in the office tomorrow morning at 6 A freakin M to make sure everyone is working properly.  So, if you are about to start your life as a Digital Moses, this is the way I recommend it.

Tuesday, April 14, 2009

A postcard from along the "Migration Trail"

Since Lotusphere 2009 ended my life has been a mix of mail migrations and other weird life stuff, hence the blog silence. So with a migration project about 85% done, I figured it was time for me to resurface in the blogsphere and jot down my thoughts.
One thing I am learning about mail migrations now more then in migrations past is that it can be a REALLY long process to complete at times. Especially when you don't have access to the Exchange servers that you are freeing those individuals from. Currently when I need to move a user to Notes, I have to get the third party outsource folks to cut me a .PST and send it over to me. Now when there are a few small mail files with not a lot of documents, it's a quick process for CMT, (yes, I am giving props to a vendor in a blog post. They have a good product and they deserve the notice), to complete. But when the mail file has t-h-o-u-s-a-n-d-s of documents to migrate, it takes a while.
So my advice for those Domino Admins that are tasked with playing "Digital Moses" and leading people to the promised land of Domino, fear not. The task, while a long a drawn out one at times, can be done. Just have patience and follow these steps:

1. Use a good product like CMT for Notes. It's a powerful package with a lot of options to configure for how you want your migration to go.
2. Set expectations ahead of time as much as possible. Let the populace know that it's not just a copy/paste type of operation. Let them know that this is a single threaded operation of taking messages one at a time and converting them.
3. Think outside the box when it comes to how you migrate users. For example, I didn't have to travel to each of the remote locations that we've installed a new Domino server at. I set up a temporary Domino server locally at the home office in a VM, created the mail files on that server and then moved the users to their remote home server before migration, but NOT deleting the replica that is left behind. When it came time to migrate them, I configured CMT to convert the files to the server that is local to me and then let Domino replicate the data down to that location. Don't forget, you can configure Domino to compress network traffic between servers and clients when configured correctly and that can save some time and strain on your WAN.
4. No matter how hard you try to communicate to users before the migration to move everything they need from their local archive in Outlook to the Exchange server, they are going to leave something behind. Hold onto the .PST's for a while so you can easily investigate the "are you sure you migrated everything over" calls. Screenshots showing the old Outlook file and the Notes mailbox looking exactly the same take care of those issues real quick.

So there you have, my postcard of thoughts from along the mail "Migration Trail". Like most things, the old saying "there's more then one way to skin a mongoose" applies to this too. You may have some ways of doing this differently and if it works for you, great! Just post it on a blog so we can all learn from it too ;-)

 **DISCLAIMER** - My company does not endorse other products like this openly.  I am purely writing this as a Domino Administrator that is glad his life if made easier with a product that works well.

A postcard from along the "Migration Trail"

Since Lotusphere 2009 ended my life has been a mix of mail migrations and other weird life stuff, hence the blog silence. So with a migration project about 85% done, I figured it was time for me to resurface in the blogsphere and jot down my thoughts.
One thing I am learning about mail migrations now more then in migrations past is that it can be a REALLY long process to complete at times. Especially when you don't have access to the Exchange servers that you are freeing those individuals from. Currently when I need to move a user to Notes, I have to get the third party outsource folks to cut me a .PST and send it over to me. Now when there are a few small mail files with not a lot of documents, it's a quick process for CMT, (yes, I am giving props to a vendor in a blog post. They have a good product and they deserve the notice), to complete. But when the mail file has t-h-o-u-s-a-n-d-s of documents to migrate, it takes a while.
So my advice for those Domino Admins that are tasked with playing "Digital Moses" and leading people to the promised land of Domino, fear not. The task, while a long a drawn out one at times, can be done. Just have patience and follow these steps:

1. Use a good product like CMT for Notes. It's a powerful package with a lot of options to configure for how you want your migration to go.
2. Set expectations ahead of time as much as possible. Let the populace know that it's not just a copy/paste type of operation. Let them know that this is a single threaded operation of taking messages one at a time and converting them.
3. Think outside the box when it comes to how you migrate users. For example, I didn't have to travel to each of the remote locations that we've installed a new Domino server at. I set up a temporary Domino server locally at the home office in a VM, created the mail files on that server and then moved the users to their remote home server before migration, but NOT deleting the replica that is left behind. When it came time to migrate them, I configured CMT to convert the files to the server that is local to me and then let Domino replicate the data down to that location. Don't forget, you can configure Domino to compress network traffic between servers and clients when configured correctly and that can save some time and strain on your WAN.
   
4. No matter how hard you try to communicate to users before the migration to move everything they need from their local archive in Outlook to the Exchange server, they are going to leave something behind. Hold onto the .PST's for a while so you can easily investigate the "are you sure you migrated everything over" calls. Screenshots showing the old Outlook file and the Notes mailbox looking exactly the same take care of those issues real quick.

So there you have, my postcard of thoughts from along the mail "Migration Trail". Like most things, the old saying "there's more then one way to skin a mongoose" applies to this too. You may have some ways of doing this differently and if it works for you, great! Just post it on a blog so we can all learn from it too ;-)