Ensuring meeting requests stay in tact when Exmerging 2003 to 2010

We are upgrading our server (SBS 2003, 5 year old server) to a Enterprise Server 2008 R2 with Exchange 2010. The firm we have enlisted to assist with the migration has suggested we don’t try and migrate but rather create a new domain and then bring stuff across. I don’t know a lot about it, but he is using Exmerge to transfer mailboxes from the old server into the new server, which is fine. The worry that I have is that calendar invites which are currently in, will have their link broken in the new setup, as users + resources are recreated (and I think they are referred to by an ID rather than email address?). Preliminary testing of a couple of mailboxes seemed to suggest this is the case (though could be some other issue that we are facing).

Do you have any advice on how to get exmerge to retain the correct references, so that when I update a meeting request with me, Bob and the Staff Room, they all get the updated request? Is there any utilities to use, or some technique?

From serverfault RodH257

• Invitations/Events that are sent intra-exchange will lose the connection to the invitees. There's no way around it (using exmerge). Exchange keeps track of these connections by their LDAP DN; which will be different in the new domain. Most places that run SBS don't have too many troubles with this, so nobody has really put the effort in to making a better solution (especially since a direct upgrade retains the LDAP DNs and connection; but there's plenty of reasons to not do a direct upgrade).

  Evan Anderson : I'd be curious to hear the reasons that you'd be against a direct upgrade. Migrating away from SBS to full versions of products has always been pretty straightforward. (Migrating *into* SBS, or from one version of SBS to another, is a different story, and fraught with silliness...)

  RodH257 : the firm suggested that there is likely to be things brought across from our 5 year old SBS installation, errors, anomalies etc and that it was better to start afresh. I don't know any better so just went with that. Is there any way to manually edit the calendar entry to change the LDAP DN to an email address? or in the API so I could create my own tool?

  Evan Anderson : I think they either don't know what they're talking about or want a "solution" that offers more billable hours. (I hate to sound so blunt, but I've seen too many bungled and needlessly complicated migrations and I have no tolerance anymore.) In an E2K3 environment the "LegacyExchangeDN" is what's referenced, not the LDAP objects' DN. There aren't "supported" APIs for modifying the LegacyExchangeDN on objects, per se. Nothing in your existing Active Directory can't be cleaned up and migrating your email in a "move mailbox" migration would be the best thing. Give 'em my number.

  Chris S : I really don't know the details of this case, so I'm putting a bit of faith in the consultant (that could be misplaced, but I'm not calling anyone out without being sure). I've seen a few SBS installations where a string of former "admins" made so many 'interesting' changes there was no way I could guarantee they were all fixed in one afternoon. Simultaneously, the used environment was so simple that recreating everything took less time than installing the server software. Could they have been migrated and cleaned up, sure; but it would have taken longer than an afternoon.
  From Chris S

• The firm you've enlisted to assist you is wrong, in my opinion, for suggesting that you ExMerge the data in the first place. There's no way, using ExMerge, not to make a mess of your existing data. You're also going to end up with a totally new Active Directory domain, so you're going to have to employ tools like ADMT or USMT to maintain the user's experience.

  Migrating from SBS 2003 to W2K8 would be very straightforward. Likewise, Migrating to Exchange Server 2010 from Exchange would also be straightforward.

  • Install a replica Windows Server 2008 R2 DC after performing the necessary domain schema preparation.

  • Install the new Exchange 2010 server and move mailboxes from Exchange 2003.

  • Migrate all the data off of the SBS Server.

  • Uninstall Exchange 2003 from the SBS Server and perform an orderly retirement of Exchange 2003.

  • Transfer the FSMO roles from the SBS Server to a W2K8 machine. SBS will begin to STOP because of licensing problems, but you'll have more than enough time to DCPROMO back to a standalone server, then shut it down.

  Once you've migrated the SBS-specific GPOs, etc, in the Active Directory can be removed and it can be cleaned up.

  Depending on how much data you have this could be an afternoon's work. When you're done, all your client computers are still joined to the domain and all the Exchange data still works as expected. (If you really want to be fancy you can add a "swing" through a temporary domain controller and end up with a new file server that has the same name as the old SBS Server machine.)

  Malnizzle : +1 only thought here is that maybe their AD is so cluttered, that the firm could be trying to kill two birds with one stone and trying to get a fresh AD because of that, just a thought

  Evan Anderson : There's nothing, short of short-sighted schema modifications, that can't be fixed in an AD domain.
  From Evan Anderson

• I can't really comment on whether it was worthwhile or not, I'm not an expert at this, so we just trusted what we were told. It's all migrated now, and working correctly.

  To answer my own question, I discovered a solution for converting the X400 addresses in the 2003 Server to SMTP addresses so that meeting responses work correctly.

  Here is how I did it:

  1. Open the users profile, when I did it, I used the PST files from Ex Merge, but you can just login to outlook as the user.
  2. Save the calendar as an iCal using File > Save As (outlook 2007 and above do iCal export I believe). You need to set it to do the whole calendar, and also select the options for private items (and attachments, though they don't always work in iCal)
  3. Exporting to iCal, if you open it in notepad, converts the x400 addresses to SMTP, which is the key.
  4. Now when you have the users new mailbox setup on the new server, login as them (I created a profile in outlook for each user).
  5. Download MFC Mapi from Codeplex. Open this tool, and connect to session.
  6. Go to Mailbox Store > Top of Information STore > Calendar.
  7. Select all calendar items and delete (I chose send to recycle bin, just in case) (doing this allows you to easily delete all calendar items without being prompted to send a cancellation)
  8. Go to outlook and import the iCal file you exported.

  It was a bit of a process, so I only did it for people in the office that were likely to have a few of them. You could export only the certain meeting request for others. It was essential I did this for our directors who have a ton of meeting requests that would have been broken. Also resources (as long as you recreate the resources with the correct SMTP address on the new server).

  From RodH257