Funambol and Migration into Exchange

We got an inquiry about Funambol and how after migration data we inserted wasn't being sync'ed by Funambol but calendar items created directly in Outlook were. After we looked up what Funambol was (usually we see folks use ActiveSync) and the client did some rooting around on their own, we had a reason.

Here's what happens.

You know our UNDO process?

In going into Exchange 2007 we insert the keyword "mmconv102659080256Z" into the Mileage field of an Exchange calendar object.

Why did we choose the Mileage field? Because it's easy to surface when using Exchange Web Services. So in the event we need to do an UNDO we can search through every mailbox and remove only the data we inserted. Very convenient, and a very good safety net.

BUT Funambol is looking at that field and analyzing it to make sure it's actually a Mileage (i.e., a numeric string). So looking at an alphanumeric string is causing it confusion.

Two possible solutions:

1. Post migration: Just remove the Sumatra tags. Of course, do not do this until AFTER you've validated the data.
2. Pre-migration: Choose a different tag that's purely numeric (e.g., "99999999999")

Either one will get you there.

We also insert data into the Billing field (for the technically inclined, they're the GUIDs of the calendar objects so we're sure we're acting on the correct objects when migrating).

We also know of at least one other application that uses the Mileage field for internal purposes - so keep an eye out.

Validating 5000+ Users?

If you're doing a migration into Exchange 2003 or 2007 with more than 5000 users (and this showed up in this case with a migration of over 10,000), and you're using the same database regularly, use the Access "Compact and Repair" option between insertion runs.

The client doing this noticed a marked degradation in Validating user accounts after 5000 users. Investigating we determined a few code fixes that speed the process, but also that the best thing you can do is Compact and Repair the database.

Cool method for cleaning test Exchange databases

We really like it that we deal with smart people.

Case in point: Adam Smith at Yale who created a script called ‘clean-mailbox-database-sumatra.ps1’ that finds the databases on 'your-server' and dismounts them. It then finds and removes all *.edb files in e:\mailbox and then mounts the databases.

clean-mailbox-database-sumatra.ps1:
________________________________________________________________________
#Find all mailbox databases on your-server and dismount them
Get-MailboxDatabase -server your-server Dismount-Database -Confirm:$False

#Find all of the .EDB files and remove them
Get-ChildItem -Path e:\mailbox -Recurse -Include *.edb Remove-Item

#start all mailbox databases
Get-MailboxDatabase -server your-server Mount-Database
________________________________________________________________________

This would not be something to do on your production system (unless you REALLY wanted to clean it), but for a test lab dedicated to a calendar migration it's faster and easier than our selective Undo.

Many thanks, Adam!