Exchange Server 2003 Std Migration 3

[Dayzt]

Hey there, Exchange pros! I would like some comments and suggestions/help with our upcoming exchange server migration. I'll cover as much of the details below as I can - please let me know if i'm forgetting anything...

'Old Server'
- OS - Windows Server 2003 Std, SP2
- Exchange - MS Exchange Server 2003 Std, SP2
- Exchange accounts - 86 accounts, public folders

'New Server'
- OS - Windows Server 2003 Std, SP2, fresh install
- Exchange - MS Exchange Server 2003 Std, fresh install, SP2

Our old server is in a different city and the plan is to move Exchange from the 'Old Server' to our 'New Server' in our home office. Both servers are on the same domain.

Questions:

1. Can we do some sort of full backup on the 'Old Server' and use that backup file to 'restore' it onto the new server to complete the information store and public folder migration? Is this faster than manually moving all the accounts?

2. Users in our remote offices use RPC over HTTPS to access email on their Outllook clients - what things (and where) do we need to change on the client machines and on the domain to have them connect to thier mail on the new server after the migration?

3. The Exchange server(s) is and will be (New Server) backend servers, so they aren't exposed directly to the internet (don't have a second NIC configured with an outside IP address). Where on the network do i need to make changes so OWA requests hit the correct (New Server) backed Exchange server?

4. Any idea how long a migration of this type and size will take? We plan to schedule email downtime across a weekend to do the migration, but would like to have some idea how long (barring any problems) it will take.

5. Can we somehow have both the old and new Exchange 2003 servers running at the same time on the domain without any conflicts or problems, just in case there are major problems that force us to fall back to the old server?


Thanks in advance for the help! Some of the answers to these questions I think I may already know, but I wanted some expert advice... =)

 

[fuego007]

This is actually quite simple. When you install Exchange on the new server, it will become a member of your existing 'site' (Exchange 5.5 term, I know). You can then simply move the mailboxes from the old server to the new.

If you plan to decomission the old server, search Microsoft's site for instructions on removing the first server in the site, as there are things you MUST do before removing the old server. One thing the article won't tell you, is that once you've moved all public folders, RUS, etc. from the old server, all you have to do is go into ESM, right-click the old server's name, and select 'delete'.

Exchange databases in 2003 are not portable like they are in 2007. You could restore a backup to a recovery storage group on the new server, but that would probaly take longer than the process I just outlined.

One last note: do not attempt to move mailboxes larger than 2 GB over a WAN connection. If things go wrong Microsoft won't help you and you could lose the mailbox(es).

When all else fails, read the book!

 

[Dayzt]

Thanks fuego! 'This is actually quite simple..' - that's exactly what I was wanting to hear!!! =)

A few questions/comments regarding your reply...

1. The server we're moving from will not be decommissioned (i don't think) as it is also acting as a DC and a file-server on the domain. Can I just leave it there for a short time (1 month maybe) with the mailstore dismounted in case for some reason we need to restore it??

2. Could I possibly do the mail-store recovery on the new server into a recovery storage group (like you mentioned) and then move (or copy) them from there into the new server's active mailstore? The reason I ask that, is because it would be nice to be able to move everything at once with one file (mail-store backup file) in order to avoid moving those large accounts seperately...

 

[58sniper]

This has been discussed here many times. Install Exchange on the new server, and move the mailboxes. Follow KB 822931 TO THE LETTER.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[ShackDaddy]

You could leave the older server in place as long as you like. Just make sure that when you are pretty sure you are done with it, to uninstall Exchange from it. If you remove the DC role from it or rename the server, you will make it much harder to uninstall Exchange from it, so put off either of those things till you've done the proper uninstall procedures.

No, you can't migrate the mail via RSG. The RSG has to match the DNA of a LOCAL storage group, and it won't take a backup from a different server. On Exchange 2007 the rules change a bit, and there's some portability of databases between servers.

Dave Shackelford
ThirdTier.net

 

[Dayzt]

Should I dismount the original mailstore prior to starting the move, or does it need to be mounted to perform the mailbox moves?

 

[58sniper]

It must be mounted.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[Dayzt]

Another question... do I need to move or reinstall an SSL certificate on the new Exchange server in order for HTTPS access on the new mail server to work?? I noticed that on the gateway device where Exchange is currently running (haven't migrated yet) it's port forwarding incoming traffic from our DNS host on the SMTP (port 25 & 110) ports as well as the HTTPS port (port 443) to the inside IP address of that Exchange server's local NIC... I'm assuming this will need to be removed once the migration is complete and added onto the gateway device where the new Exchange server will be? (I will also be editing the 'A record' on our DNS host to point to the new Exchange server's outside NIC IP address...)

 

[58sniper]

Correct. Export the SSL cert on the old server, and import it on the new server. Everything else you mention sounds right.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[ShackDaddy]

When you export it, make sure you choose to export it "With the private key". I don't think that option is checked by default. Without the private key, you won't really have a working cert on the new server.

Dave Shackelford
ThirdTier.net

 

[Dayzt]

Okay... being that the old Exchange server is a 'backend' server, is this procedure still the same? Also, is this something I can do ahead of time - before the actual migration? Exporting and importing the cert won't remove the HTTPS functionality from the old Exchange server, will it? Sorry if that's a noob question...lol.

 

[58sniper]

That's correct. You can install the cert on the "new" server anytime without affecting functionality on the "old" server.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[Dayzt]

Thanks 58sniper... the kb822931 article you post earlier was great, and will be invaluable to this project!

 

[Dayzt]

Another question regarding this migration...

We have around 40 mailboxes on the original server that are over 200 MB in size. Because the original server is in a different city, the plan is to physically take the new Exchange server to the other office where the original server is, connect it to that server's network (so both exchange servers are on the same local network) and so the mailbox moves from there. Does this make sense? The idea is to make it as fast a move as possible.

Question: When I change the IP address on the new server in order to be in the same subnet as the old server, and then do the mailbox move, will it function properly once I take the new server back to the new office and change the IP address back again??

 

[58sniper]

How fast is the connection between offices? You can schedule those moves to go during off hours, and the users can still be online when the mailbox is moved.



Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[Dayzt]

The connection is not super-fast... during lunchtime yesterday (low traffic), I moved my own mailbox to the new server and it took around 40 minutes (57 MB). Rounding that number up to 60 MB, our mailboxes that are 900+ MB will take around 10 hours to move...lol...does that number make sense?

Also, if we physically take the new server and connect it side-by-side with the old server - will changing it's IP address effect the mailboxes' connection once we take the new server back to our office and re-attach it to our sub-domain?

 

[Dayzt]

....if we schedule it to run after hours, the problem is getting them ALL moved in time. This is a problem because the accounts which are moved to the new server cannot access 'webmail' until we change the port forwarding on our gateway to point HTTPS traffic to the new server. That's why we'd like to have everyone moved over in 1 weekend so the setting can be changed on the gateway afterwards.

...or is there another solution to this?

 

[ShackDaddy]

Exmerge them all out, which might take an hour.

Save the .pst files to a big USB thumbdrive or portable hard disk. Take that media over to the other server and copy all the .pst files to the local drive there.

Then go home. That night, do ANOTHER Exmerge operation against the original server but when you do it, choose to extract (not a copy like the last operation) all mail older than 24 hours, then move all the virtually empty mailboxes.

When they are moved, do another mass Exmerge operation on the new server to suck all those first-batch .pst files back into their original mailboxes, but this time they exist on the new server.

That's how I did it for an 77gb store with a server in California and another in Connecticut, except that I had to use FedEx....

p.s., I've also found it helpful to exclude /Notes and /Contacts from the Exmerge operation. They don't take up much space, but sometimes I've seen problems where a couple of items end up going missing.

Dave Shackelford
ThirdTier.net

 

[Dayzt]

Wow, thanks Dave! I'm testing this method right now with a small account (small PST generated) which I can manually copy over the internet to import back into their moved account, and it seems to be working great! (besides the fact that our internet connection is quite slow) I may do the first full exmerge a few more days in advance to make sure I can get the PST files down here in good time (probably FedEx as well) so I know I have the users' full PST onsite when I do the second clean-out exmerge and then the import locally... thanks again, this process will save us a ton!