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.)

  • +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 – Malnizzle Jul 16 '10 at 2:47
  • 1
    There's nothing, short of short-sighted schema modifications, that can't be fixed in an AD domain. – Evan Anderson Jul 16 '10 at 2:55

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).

  • 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...) – Evan Anderson Jul 16 '10 at 1:20
  • 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? – RodH257 Jul 16 '10 at 1:27
  • 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. – Evan Anderson Jul 16 '10 at 3:00
  • 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. – Chris S Jul 16 '10 at 12:29

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:

  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).

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.