Lessons Learned: Move Server Wizard
August 24, 1999
There is adequate information available in various resources to provide you with a fairly smooth transition from one Microsoft Exchange Site and/or Organization to another. However there are some things that you can only learn by looking at the experiences of others that have used Move Server Wizard (MSW) in a production environment. This document is an effort to eliminate some of the issues that you may have not thought of.
Moving Public Folders
If you have read the documentation for the MSW, you are aware that MSW does not move your public folders. One way to keep these is to export the public folders into a Personal Folder (.PST) before you start the move. This will allow you to keep the content of the public folders offline and one the move is completed import the public folders back into the new site.
Things to note:
Personal Folders have a size limit of 2 Gig. If your public folders are larger than 2 Gig, you can not use the export option in Outlook. You will need to create multiple personal folders and actually copy the top-level folders in one at a time.
When you import the public folders back into the Public Information Store, the mailbox account that you use is now the owner of all the objects in the public folders. This means that the mailboxes that only had permission to edit their own items in the public folders won't be able to edit what used to be their posts. Look at the section on public folder permissions further down for a quick fix to this.
Public Folder Permissions
By using personal folders you are able to save the contents of the public folders, but not the permissions. If you use the PFAdmin utility found in the Back Office Resource Kit, Second Edition, you can export the ACLs to a file before the move. Using PFAdmin again after the move you can import the ACLs using the SETACL option. You will have to massage the file a lot to get it to work though.
Things to note:
Although you can find reference to the PFInfo utility in the BORK help file (Exchtool.hlp), you won't find it on the disk. For some reason, it didn't make it. However, if you had it, you wouldn't have to massage the import file since it will actually create a nice and neat file that you could use with the PFAdmin tool. The only way to get this tool is to contact Microsoft Premier Support and request it. It will save you a lot of time.
If you suspect that users that have "Author" and "Publishing Author" roles will have an issue with the fact that they can no longer edit objects that used to be theirs, before you use PFAdmin to import the ACLs, you may want to change all instances of the aforementioned roles to "Editor". Since this will give them more permissions than they had before, decide whether or not you want to give them the power to edit or delete all of the messages.
When you use the PFAdmin tool to import the ACLs, there are some things that can cause an import to fail:
Display Names and Check Name
Since Outlook doesn't modify your Display Name in your profile, even if you modify them at the mailbox level at the server, you may have some issues when your clients click on the "Check Name" button after the move.
To illustrate: At one of the sites that we ran MSW, the administrators had adopted a new naming standard that involved changing all the Display Names on the mailboxes. In our tests we had forgotten that this had happened. We had a utility that actually would do the same thing as clicking on the "Check Name" and had inserted it in the login script. Since the Display Name that the client had was different from the one that the server had, the utility failed.
Outlook Developers Kit
If your organization has a customized version of Outlook that runs when a logs into a new machine, you probably have the setup program point to one of your Exchange servers to find the user's mailbox. If this is the case, and you don't move the server it points to, then it won't find the mailboxes that were moved. You may need to take this into consideration. You may need to change your configuration.
Servers with Private Information Store Removed
If you have a server that has the sole purpose of being a Public Folder server, it is possible that you may have deleted the Private Information Store. The Move Server Wizard does not like this. You won't receive any errors in the move until the very end when the wizard tries to start the Information Store. You will receive an error notifying you that a service took too long to start. When you go to the Services applet in the Control Panel you will notice that the Information store has not started. Trying to start the service will notify you that "The Microsoft Exchange Information Store Service returned service specific error 1276."
The workaround is not to do this in the first place. Make sure that you always have the Private Information Store installed.
There is no problem when the Private Information Store is installed and the Public Information Store is not. After the move, if the server was the server to create the new site, the server will have a Public Information Store even though it didn't originally.
Move the Distribution Lists with the First Server
The default setting when you move the first server is to only move the Distribution Lists that have the owner on the server that is moving. Don't choose this option. Always move all the Distribution Lists in the site every time you move a server. It may take a little bit longer, but the time is usually minimal and the result is much safer than the alternative. When you move the second server, and every one after that, you will notice an additional screen that asks if you want to merge the Distribution Lists together. This is good. Do it.
Keeping your Reply SMTP Addresses
Move Server Wizard will change your default reply SMTP addresses to email@example.com. You probably don't want this to happen. The workaround may require that you join an existing site. If you don't already have a site to join there are a few things you can do.
Option 1 - You can install a new server that will be the first server in the site.
Install Exchange server with the standard installation that you have already existing, however create the server with the new organization and/or site value. After installation is complete and Service Pack 2 has been installed, follow the directions below to change your Site Addressing properties for SMTP.
Option 2 - The first server you move will have no or very few mailboxes.
This, of course, only works if you have multiple servers you are moving. This is ideal if you have a Public Folder server with very few mailboxes on them. Move as many mailboxes off of the server to another server to be moved later. After you move the server you will need to modify the mailboxes or Public Folders that send mail and fix the Default SMTP address. Also you will need to change your Site Addressing properties. You can follow the directions in option one above.
Option 3 - The hard way.
You can export all the objects that have Default SMTP addresses and modify the .csv file and import it in. If you are a whiz at Excel or perl scripts, this may be easy for you.
If you have modified the templates on the Exchange server before the move, you will lose all changes.
You've heard it before The most important thing you can do that will make you experience with the Move Server Wizard fairly smooth is to plan, plan, and plan. Make sure you have a backup plan as well for every portion of your plan. Ask yourself, "If this doesn't work, what would I do next?" Of course, no one wants to back completely out of the plan and restore from tape, but be confident that you can do this if you need to.