The more I do, the more I learn

Just learnt some more important lessons recently after being involved in another SBS Migration. In most cases these days we migrate existing clients using the SBS Swing Migration kit put together by Jeff Middleton. If you are in the business of upgrading Windows networks then I strongly suggest you take a look at Jeff’s site ( and invest, since it is going to save you hours of work.


During the forklift of Exchange Server databases from the old server to the new server we discovered that they wouldn’t mount. The reason was that the distinguished name of on the old server was different than the new server. The old server looked like /o=first organization /ou=first organization.. while the new server read /o=business name /ou=first organization. The reason for this? Well, it turns out the old server was an OEM installation which meant that Exchange had been configured BEFORE the client details had been entered. Thus, even using the Swing Migration kit, the same server name and domain name there was an issue. The situation can be rectified using LegacyDn, which allows you to change these values. Now, you have to be careful using this tool as the following Microsoft KB article says and make sure the values from the old server match the new server. We also found that after making the changes you need to reboot the new server so that the values will be flushed through the AD.


After the reboot you will also probably need to disconnect all the existing user mailboxes and then re-connect them so that all the details are correct. A pain, I know but it did the trick. So the lesson here is that if you are migrating from an OEM installation of SBS then more than likely you should run LegacyDn to record the Exchange database details just in case there is name mismatch after the migration.


Now, during the migration process we had some issues with Exchange public folders and I was trying to mail enable them while using Remote Desktop from a workstation. Now for some reason the option to run the Exchange tasks wasn’t being displayed when I hit the right mouse button on the public folder. Turns out that it won’t display unless I am using Remote Desktop as the console session. To to this you need to run:


%SystemRoot%\system32\mstsc.exe /console


It seems that there are somethings that just don’t work unless you are remoted in as the console session. So lesson two is that if you plan to do any administrative work on a server via remote desktop (especially during a migration) always remote in as the console session.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s