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?
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.)
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).
We did the same thing 2003 SBS to 2011 SBS without migrating. There was a lot of strange things from a slew of "IT consultants" on the 2003 box and we wanted to change the name of the domain.
If you use a PC client bound to the 2003 box, login to each account, open Outlook, let it cache all of the exchange data, then export as PST file, save these to a network volume or drive. Setup your accounts on the new server, use a PC client bound to the new server and import the PST files.
All your calendar, mail, etc will move over. you will need to ensure people don't try to reply to old e-mails as they will still reference the old domain.
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:
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).