Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Help with Ed Crowley Server Move 2

Status
Not open for further replies.

StockcarsRus

IS-IT--Management
Jun 9, 2003
100
US
The Ed Crowley method.

This is the method that I would like to use. I am unfortunately in a situation, where I am not Exchange educated. I was thrown into this position, with a running Exchange 2000 server, and now it is sooooo slow and my boss wants me to move it to a bigger and better server. I have read the method several times, and I must tell you that I am lost on the first step. If you would be so kind and would help me, would you please expand on the numbered points for me with some more details as how to do these steps.

The current server is running Exchange 2000 SP2 and I have 50 mailboxes. Our internet email is picked up by users Outlook from our ISP, so we don't host our own internet email. There are some public folders, but only a few. The server has no connectors configured. It is just a pretty basic setup. The current server is not the domain controller. I would like to start by moving over my own mailbox, and then move everyone else later.

Any help would be appreciated.

Thanks so much

 
1. How does the old exchange server know that the new server is an exchange server also. Is this a part of the setup on the new server?
2. My current exchange server is not the AD server for the organization. Is it really just a matter of skipping the blue written portion of the instructions?
3. Step #7, how do you create new mailbox stores and public folder stores on the new server?
4. Step #9, Users are not allowed to create public folders, do I need to do this step?
5. Step 12, how do you modify the recipient update service to point to the new server? What happens when you do this?
6. Step #17, can I just move my own mailbox, and change my outlook setting to retrieve mail from the new server to see if it works? If it does not work, can my mailbox be moved back to the old server?
7. Step #22 do you need to do this only if you host your internet email? We use an ISP and get our email through pop in outlook 2000.

As I said, I have been thrown into this position, and I am struggling. Any help is greatly appreciated.

Thanks
Debbie
 
Every object in the directory has a distinguished name (DN) that includes the organization and site under which the object was created. Moving a server means that you have to rename every object in the directory on the server you're moving; you also have to adjust the old site's directory to reflect the absence of objects that you moved along with the server. You can’t do this manually because most of the objects whose names you need to adjust aren't visible in Microsoft Exchange Administrator.
The Exchange Move Server Wizard (MSW) handles the task, performing the following steps:·
MSW updates every object in the server's directory to reflect the new site and organization the server is moving to. Each object gets a new DN and placeholder address.
MSW keeps objects' old addresses so that an object can get mail at either the old or new address after the object moves; the Message Transfer Agent (MTA) is responsible for resolving the addresses and delivering mail to the proper location. ·
MSW updates the messages stored in the private Information Store (IS) on the server so that all stored messages have the correct address for any item modified in step 1. ·
MSW checks for duplicate names or objects because moving a server into another organization may result in some duplication. ·
MSW removes the server from the original site (and possibly organization), removing references to the server's objects from the original directory. ·
MSW adds the server to the new organization and site, creating them if necessary. You can split one organization into two if you use MSW to move a server to an organization that didn’t previously exist. You have some tasks to perform after MSW finishes its work; for example, you have to restart the MTA on the server you've moved, clean up public folder replicas, and reset permissions.
MSW can do four jobs, each of which is useful under some circumstances:·
It can rename a site by moving the last (or only) server in the site to a new site with a new name. ·
It can split an existing site by moving one server out of a multiserver site into a new site with a new name. ·
It can move a server from one multiserver site to another one without removing the original site. ·
It can merge two sites with different names into a single site. For example, when two companies merge and their existing organization names aren't the same, one company can use MSW to join the other company's organization, then both of the companies can create sites in the same organization. In general, you can rename and merge sites only when you have one server in each of the sites. You can collapse a site onto a single server by moving mailboxes, connectors, and public folders to one server in the site and removing the other servers. After you’ve done that, you can disconnect the site from its organization, use MSW to create a new site in the organization, then rejoin the original site to the organization. As a final bonus, MSW can also change the NT domain and service account information for a server, whether you're moving it or not.
Before you use MSW, you should also know what it can’t do (the good news is that MSW checks for, and warns you about most of the following limitations before it proceeds):·
You can’t use MSW to move servers running Exchange Server 5.5, Exchange Server 5.0, or Exchange Server 4.0 without Service Pack 1 (SP1) or later. You also must upgrade all of the servers in the original site, as well as any bridgeheads in the destination site, to Exchange Server 5.5. ·
MSW can't move the Internet Mail Service (IMS) or Key Management Server (KMS), nor can it move any connectors or gateways (including third-party gateways and extension products). You must remove connectors or gateways before you do the move. ·
You can’t run MSW on computers linked in a Microsoft Cluster Services (MSCS) cluster. ·
You can’t run MSW in the middle of a replication cycle—you should run it only after replication has been completed. ·
You can't change languages when moving. If you want to move a German server, use the German MSW, or you will lose all of your localization information. ·
Messages that are queued when the MSW runs may be bounced, so you can't effectively run the MSW when you have a large queue of pending messages. ·
Users must decrypt any encrypted stored mail before an MSW move because they won't have access to their keys after the move. ·
MSW doesn't update a number of things in the private IS, including message signatures, public folder permissions, public folder contents, and client-side Outlook rules. ·
MSW doesn't update things that depend on the server name, including link and server monitors, Outlook Web Access (OWA), and Network News Transfer Protocol (NNTP) news feeds.
 
Okay, I'm not sure what you are saying. I should not use the Crowley method, but do the server move using MSW? I'm sorry, but I am more confused than I was. If someone would please answer the questions that I had about the Crowley method, that would help me so much.

Thanks
 
Every object in the directory has a distinguished name (DN) that includes the organization and site under which the object was created. Moving a server means that you have to rename every object in the directory on the server you're moving; you also have to adjust the old site's directory to reflect the absence of objects that you moved along with the server. You can’t do this manually because most of the objects whose names you need to adjust aren't visible in Microsoft Exchange Administrator. The Exchange Move Server Wizard (MSW) handles the task, performing the following steps:
MSW updates every object in the server's directory to reflect the new site and organization the server is moving to. Each object gets a new DN and placeholder address.MSW keeps objects' old addresses so that an object can get mail at either the old or new address after the object moves; the Message Transfer Agent (MTA) is responsible for resolving the addresses and delivering mail to the proper location.MSW updates the messages stored in the private Information Store (IS) on the server so that all stored messages have the correct address for any item modified in step 1.MSW checks for duplicate names or objects because moving a server into another organization may result in some duplication. MSW removes the server from the original site (and possibly organization), removing references to the server's objects from the original directory. MSW adds the server to the new organization and site, creating them if necessary. You can split one organization into two if you use MSW to move a server to an organization that didn’t previously exist. You have some tasks to perform after MSW finishes its work; for example, you have to restart the MTA on the server you've moved, clean up public folder replicas, and reset permissions. MSW can do four jobs, each of which is useful under some circumstances:
It can rename a site by moving the last (or only) server in the site to a new site with a new name.It can split an existing site by moving one server out of a multiserver site into a new site with a new name. It can move a server from one multiserver site to another one without removing the original site. It can merge two sites with different names into a single site. For example, when two companies merge and their existing organization names aren't the same, one company can use MSW to join the other company's organization, then both of the companies can create sites in the same organization. In general, you can rename and merge sites only when you have one server in each of the sites. You can collapse a site onto a single server by moving mailboxes, connectors, and public folders to one server in the site and removing the other servers. After you’ve done that, you can disconnect the site from its organization, use MSW to create a new site in the organization, then rejoin the original site to the organization. As a final bonus, MSW can also change the NT domain and service account information for a server, whether you're moving it or not. Before you use MSW, you should also know what it can’t do (the good news is that MSW checks for, and warns you about most of the following limitations before it proceeds):
MSW can't move the Internet Mail Service (IMS) or Key Management Server (KMS), nor can it move any connectors or gateways (including third-party gateways and extension products). You must remove connectors or gateways before you do the move.You can’t run MSW on computers linked in a Microsoft Cluster Services (MSCS) cluster.You can’t run MSW in the middle of a replication cycle—you should run it only after replication has been completed. You can't change languages when moving. If you want to move a German server, use the German MSW, or you will lose all of your localization information.Messages that are queued when the MSW runs may be bounced, so you can't effectively run the MSW when you have a large queue of pending messages.
Users must decrypt any encrypted stored mail before an MSW move because they won't have access to their keys after the move. MSW doesn't update a number of things in the private IS, including message signatures, public folder permissions, public folder contents, and client-side Outlook rules. MSW doesn't update things that depend on the server name, including link and server monitors, Outlook Web Access (OWA), and Network News Transfer Protocol (NNTP) news feeds.
 
Actually the Ed Crowley way is as follows:
This method should create much less potential for grief because you can have practically zero perceived downtime. You can perform all of the steps below at your own pace and in just about any order, and most, if not all, of them during working hours. Furthermore, you can usually very easily back out of any of the steps if things don't go as expected. While not the easiest method technically, it is certainly the least risky and the least likely to deprive you of sleep.
Important Note: Exchange 4.0 and 5.0 "Standard Edition" did not permit multiple servers in the same site. If you have only one server and are running Standard Edition, then you'll need to upgrade to Enterprise, or add the Exchange Connector. You might want to ask your friendly neighborhood Microsoft representative to see if he might be willing to loan you a copy since all you need it for is to upgrade to version 5.5.
Important Acknowledgement: My thanks go to Rich Matheisen for his valuable input to this revision.
The method:
1. Bring up a new server as a new server in the same site with a different name of course.
2. In the old server's Information Store properties, change the location of the mailboxes' Public Folder server to be the new server. This will take care of any newly created public folders. (You'll have to stop and restart the Exchange services before this will take effect.)
3. Check all distribution lists to ensure that none of them specifically name the old server as their expansion server.
4. Move the mailboxes using the Exchange Administrator. Move all at once, one at a time, or at some rate in between. In many cases, you can move the mailboxes during working hours because each user is affected only during the time his own mailbox is the one being moved.
5. Create replicas of the public folders on the new server. When the contents of the folders have replicated (do wait a little while!), remove the replicas from the old server.
6. Move any connectors from the old server to another server.
6a. For each site-type connector on the server you're replacing, create a parallel connector to all connected sites on the new server, including adding the sites in the "Connected Sites" tab. On the server you're replacing, in the connector's "Connected Sites" tab, remove the sites. Recalculate routing. Verify that messages flow through the new connector. Then remove the connector definitions from old server and from the server at the other end of those connectors.
6b. For each IMS Internet connector, create MX records pointing to the IMS on the new server as appropriate, and change the cost on the old MX record so that it is higher than the new one. In the properties for the IMS on server you're removing, remove all Address Space entries. When you have checked and verified that all messages are flowing through the new connector, remove the old one, then recalculate routing again.
6c. For each replication bridgehead server on the server being replaced, change the local bridgehead server property to the new server. Adjust the replication partner's remote bridgehead server property to the new server as well.
6d. For any other type of connector, including Microsoft Mail, move them too.
7. Follow the steps in Q152959.
8. Leave the old server up for a while so MAPI clients connect to the new server automatically. It's true! You don't have to do anything to MAPI clients!
9. Notify POP3 and IMAP4 users of how to reconfigure their clients to point to the new server. (If you have a WINS and/or DNS alias for this address, point it to the new server.)
10. If the old server has a Key Management Server, you'll need to move that too.
11. Stop the Exchange services, then remove the server from the site.
 
GEEZZZ, Coldfusion strikes again(double posts). A lil more on the MSW.
Before you do anything, make online and offline backups of all the Exchange Server databases (i.e., dir.edb, pub.edb, and priv.edb) and any existing log files (some log files might include changes that haven’t rolled into the databases yet)

The Move Server Wizard was designed to provide a couple of different types of services:
· Split a large site into smaller sites by moving servers to a new site.
· Merge several smaller sites into fewer large sites.
· Move an Exchange server into a new organization.
This tool is powerful, but it requires careful planning, and it does come with some caveats. Look through the following sections on what the wizard can and cannot do. Judge for yourself if this tool will fix your problems. Regardless of your situation, though, this tool is not a point-and-click solution.
· It moves the entire server to a new or existing site (or organization). It does this by going through the directory database and the private information store database and replacing all instances of a site and organization name in all distinguished names (DNs) with the new site and organization name. Sound time consuming? It can be!
· It checks for duplicate directory entries that may occur as a result of moving a server and suggest a course of action.
· It will move distribution lists and custom recipients.
New primary proxy addresses are created based on the new site’s site addressing information, and the wizard keeps any secondary proxy addresses the user had from the old site.
After the user is moved, you will see a new proxy address in the user’s e-mail addresses with a type of X500 that has the old organization and site name. This is to redirect mail that may be addressed to the old distinguished name (DN); this is useful when some replies to an old message.
· It does not configure the Outlook client to automatically update the client profile. Since the distinguished name for the mailbox object changes, all client profiles will have to be re-created.
· The wizard does not move the public information store, the Exchange KMS, or connectors or gateways (which will have to be reinstalled).
· Offline Address Books are not converted; they must be regenerated, and users must download a new copy.
· Custom Attribute labels will not move to the destination site, but the data that is in those fields does. Don’t forget to set the labels back the way they were.
· Message signatures are stripped from messages. Encrypted messages should be decrypted prior to the move using the bulk decryption tool from the BackOffice Resource Kit; otherwise users will not be able to read their encrypted messages.
· Public folder permissions will have to be put back on the appropriate public folders for any users who were located on a server that moved.
Some mailbox rules may not behave as expected after the move. Clients will not have access to their Outlook client-side rules after the move.
Here is some useful information about using the Move Server Wizard:
· Read the Move Server Wizard documentation found in either the MVEXSRVR.HLP or MVEXSRVR.RTF files in C:\EXCHSRVR\BIN\MOVESRVR directory.
· Make sure the server you are about to move is running at least Exchange 5.5.
· The wizard makes many changes to the directory and private information store. Make sure that you have a complete backup prior to starting.
· Remove any messaging connectors and directory replication connectors prior to starting the wizard. This includes connectors such as the site connector, the Internet Mail Service, and any third-party connectors or gateways. Don’t forget to check other sites for connectors that point to the server to be moved.
· Prior to moving the last server in the site, make sure that all public folders have been moved to another site and the replicas have been removed from the last server to be moved.
· The server you are moving should have at least 500 MB of free disk space available to hold the temporary files that the wizard will create.
· Prior to the move, run ESEUTIL /G /ISPRIV and ISINTEG –TEST ALLTESTS to make sure that the private information store does not have any problems.
· Make sure that the server you are moving is not the site’s routing recalculation server or Offline Address Book (OAB) server.
· Prior to moving a server, users should decrypt any mail that was encrypted using Exchange Advanced Security. These users will be issued new keys when their server is moved.
· Prior to starting the wizard, remove any Windows and Exchange server virus-protection programs.
· Prior to starting the wizard, run Exchange Setup and remove the Microsoft Exchange Event Service.
· Prior to starting the migration, move any public folders to another server or site. You can keep local replicas in the site, but you must create replicas of public folders in the new destination site and rehome any folders that are in a site that will be going away.
· Do not try to migrate two servers simultaneously.
Though the move may occur much faster than this, estimate about 2GB per hour.
I experienced several false starts, though I admit that I did not give the documentation too much consideration the first time I ran it. If the server you want to move is not configured just right, the wizard will not progress.
Also, the first time I started the wizard, I was told that the Event Service had to be removed. After doing so and starting over, I was told that I had to remove the Microsoft Mail connector and the Internet Mail Service. It was at this point that I printed out the MVEXSRVR.RTF file, added it to my Exchange encyclopedia notebook, and read through it. I also searched the Microsoft Knowledge Base and found a lot of useful articles. I could have saved myself a few false starts by reading the documentation before I had started the first time.
Armed with a little more knowledge about the Move Server Wizard, I tried again and was told that since the server I was moving had the Key Management Service installed, it could not be moved. I had installed the KMS software, but had never configured it. Once again, I ran Setup and removed the KMS software.
I ran the wizard yet again and was told that all my public folders on this server will be removed. This is not a big deal for my test server, but in the real world I will have put replicas of all my folders onto another server, removed the replicas from the server about to be moved, and rehomed the public folders to their new home.
As you can see, there’s a bit of configuring that needs to be done before the wizard can really kick in. Once you have it right, you’ll see dialog boxes ask you to confirm the Exchange private information store file, public information store file, and a location for temporary files. Once you confirm the location of the databases and temp files, a dialog box appears asking you to provide either a server name that is part of an existing site or to create a new site or organization altogether.
If you provide a new organization or site name, you’ll be asked to confirm that you want to create a new site. If you provide a server name in an existing site, you’ll be asked to confirm the site and organization name that is obtained from the server name you specified. Then you’ll be asked to provide the site services account information.
Next you’re asked how you want to treat custom recipients and distribution lists during the move, and you must determine how to handle the primary Windows accounts for each mailbox. If the domain structure is not changing, you can keep the existing Windows accounts. However, you have the choice of specifying a different domain in which accounts will be created.
The wizard now examines the directory of the destination site for duplicate addresses and presents alternatives. If the object is a distribution list, I can choose to merge the distribution lists. The wizard will suggest an alternative name for the duplicate mailbox that is about to be merged into this site.
 
Prior to starting the actual move, a dialog box summarizes the actions that are about to take place and any warnings such as public folders existing on the server to be moved. Once you confirm that you understand the actions and warnings, the move will commence. Rather than just seeing an hourglass, you can actually see which portion of the move the Wizard is working on as well as a progress bar telling you what percentage complete the current portion is. By far, the longest part of the move is the portion where it updates the messages in the private information store. As usual, Microsoft’s estimate was nowhere near the actual time it took to run the migration process. The actual time was just over 32 minutes. The private information store database was 950MB. I recommend estimating about 2GB to 4GB per hour, which was pretty close, though your actual mileage may vary depending on the number of messages and the speed of your hardware. I did this test move operation on a single processor machine with IDE disk drives, so a server-class machine will be able to do a move much more quickly. If you change your site architecture using the Move Server Wizard, make sure you allow time for the changes to replicate throughout your organization before beginning your migration to Exchange 2000.
Some Q’s and A’s:
Q. I used the Move Server Wizard (MSW) to move an Exchange server from one site to another. Now, I no longer see the Offline Address Book (OAB) container in Microsoft Exchange Administrator. Where did OAB go?
A. MSW doesn't automatically update OABs. You need to perform the following steps to regenerate an OAB manually:
Wait until the target site for the move (i.e., the site you moved your server into) has completed a full replication cycle. Find the DS Site Configuration object, and open its Properties dialog box. At the Offline Address Book tab, select the server that you want to generate an OAB. Click Generate All.
This process completely regenerates an OAB, adds it as a container object if it isn't present, and replicates it throughout the organization.

Q. I used the Move Server Wizard (MSW) to merge two single-server organizations. Subsequently, one server flooded users with reminders and notifications for events that had already taken place. What happened?

A. One of the last tasks MSW performs is to open each user's private store inside the Exchange Server Information Store (IS) and remove the user's Reminders folder. If this cleanup process fails or is interrupted, you'll see event ID 9502 in the event log, which tells you that MSW didn't remove a particular user's Reminders folder. When MSW doesn't remove this folder, numerous outdated reminders bombard the user the next time he or she logs on. Microsoft has a hotfix for this flaw, or you can install Exchange Server 5.5 Service Pack 3 (SP3) or later to fix the problem.

How to "rehome" folders
Sometimes you may need to move a public folder from one server to another. For example, if a server in your site is going to be taken offline for an extended period of time, you may want to move its public folders to another server in your site. This process is known as rehoming public folders. Microsoft has provided a utility, PFAdmin, in the BackOffice Resource Kit for Exchange to allow easy rehoming. To rehome a public folder without the BackOffice Resource Kit, follow these steps:
1. Create a personal folder in Outlook.
2. Choose the public folder you want to move and copy the entire contents to the personal folder.
3. Delete the public folder.
4. Allow replication to take place so the deletion is replicated to all other sites within your organization.
5. Log on to a mailbox on the server where you want to home the public folder.
6. Create a new public folder that will become your rehomed public folder.
7. Copy the folder contents from your .pst file to the new folder and assign the appropriate permissions.

This is all I can think of right off hand. Couple ways top accomplish what you want.
Except maybe moving a Server to a new server with same name. But I believe I spotted that question earlier, so off to give a lil help.
 
jesus thats a lot of writing... cant read all that get seasick...

#7 you dont have to create those stores a default installation will do that for you default in the mdbdata folder on your C: drive.

#9 users can create folders under Public folders in outlook, but this step is just to move those (if any) to the new server so dont bother. what your are doing is pointing the stores to the new server and then as replication is done and as users logon the default place for their mailboxes and public folders will be on the new server.

#12 Under the "Recipient container"
here is a discription what its doing:
The Recipient Update Service (RUS) is a Microsoft® Exchange 2000 service that updates recipient objects within a domain with specific types of information. For example, the RUS updates recipient objects with e-mail addresses and address list membership at scheduled intervals. Usually an administrator is responsible for determining the intervals at which this service runs.
You are about to move to a new server so my advice is to just do it.

17# yes you can do it with your own mailbox only.

22# that is only if your mailserver handles all the mail and its send direct to it yes. However you have to change the POP software that you are using to point to your new mailserver so it handles the mail.

good luck
 
I am feeling very seasick myself! Thanks for the brief answers. I am going to give it a try and see how I do. Thanks for the good luck wish, I need all I can get!

Debbie
 
dont be nervous do as compgirlfhredi said, make a backup and then off you go.
Im sure it will work either way
 
If you are merely changing the existing Exchange Server hardware, the best way of doing it that I have found is that Backup and Restore method in any form is fraught with tension and necessitates a shut down of the Exchange Server. Where as the following method can be adopted which can be done easily, almost without any risk and at ones own pace (a different server name though):

Bring up the new hardware as Exchange Server in the same site (with a new server name of course)

Use ‘Move Mailbox’ option from the tools menu to move all the mailboxes to the new server. Clients will automatically re-home and nothing is required to be done at the client end.

Create new connectors and replicas of the Public folders in the new server. MX record, if applicable, should point to the new server.

After a few days (when everything is running smoothly and replication has taken place), shutdown the old server.

If everything is fine with the new Server, then remove the old server (Refer the relevant KB article for removing a server from a site).
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top