Salvaging Old Exchange 2003 deployment

By troy ·
I have a situation where the hardware running our Ex2k3 Enterprise server is no longer sufficient. The mail store is about 50GB for less then 30 users. The actual data may only be around 12GB, but it hasn't had an offline backup done in over 5 years (and my spam filter was out for 3 weeks!!!!). I attempted to do one, but the size of the store stopped me since the Dell 2600 only has specific SCSI connectivity and the drives (transaction and store .... and I accidently erased 7GB of logs a month ago) are full. There are no IDE channels, and not even extra molex power connectors. I tried an add in SATA controller and had to get an old AT p/s to power the drives, but nothing has worked (compression and checking the store), and moving that size of store is too difficult. I spent an entire weekend with the mail route disabled while I tried; so I am no longer interested in attempting that solution (worked 36 hours straight and continued once I slept for a couple of hours).
I have decided to bring up a new server (which is done), and move users and eventually decommission the old server. My problem lies in trying to get this done, and have both machines receive email. I can only get one (the master) to receive email and deliver it to the mailbox. If my user resides on the new (member) it gets stuck in the smtp queue. I have not done any modifications to any exchange setup other than the initial install, which left me with what looks like a functioning exchange deployment. I am not able to cluster these machines, so all I want is mail to be delivered to one server, and have exchange determine on which server the mailbox resides, and to deliver it to them. This way I will have time to work on mailbox's that do not move easily. There is some corruption on my original store that I am unable to fix right now. Once most of the users are off it, I can try some more fix's, but it is almost impossible to work on due to HDD restrictitons. Any help would be great.

Original Box: Server 2003 SP1-Exchange Ent SP2
New Box: Server 2003 R2/SP2 - Exchange Ent SP2


PS: I do not want to simply add the store to larger SATA drives because as I said it has errors, and teh store is so large it isn't easily managed anymore. It is time to start fresh, enforce mailbox size limits and prep for a 2010 migration.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Answers

Collapse -

Microsoft Technet is your friend

by CG IT In reply to Salvaging Old Exchange 20 ...

This how-to article explains how to move an exiting exchange to new hardware.

The best method for what you want to do.

note: you will always run into space problems with Exchange unless you institute quotas on mailboxes, run the mailbox manager frequently and have users backup to pst files for objects [calendar events, contacts, and mail] they can not live without.

Collapse -

Good plan; look at your Connectors

by Churdoo In reply to Salvaging Old Exchange 20 ...

I believe that what you are trying to do is the best solution based on what you've described.

You should only need to add a connector for the servers to talk to each other. In other words, with a properly created connector for server-server communication, the scenario that you desire, i.e. messages coming into the organization into the existing server and Exchange figuring out where it should go and delivering to the mailbox potentially homed on the other server should work fine.

Likewise, the same connector will facilitate a user homed on the new server sending outbound email which will transfer to the existing server to be sent outbound correctly from the old server.

Look at your connectors and post more about their configuration. Also, know that is a great resource for MS Exchange tutorials and information.

Good luck!

Collapse -

yeah but.....

by CG IT In reply to Good plan; look at your C ...

he needs to move the stores and mailboxes to a new server, then decommission the old one.

imo the best method is to move the existing exchange server database,stores and mailbox to the new server, rather than creating connectors.

Right now, the original Exchange server knows about the new one. Exchange does this automatically. The original one still does all the chores for mail and hosts the database, stores and mailboxes. Moving those to the new server will allow him to decommission the old one without any problems.

Collapse -

I think we may be saying the same thing

by Churdoo In reply to yeah but.....

But he did say that the two servers are up and presumably he made server #2 part of the same Exchange organization -- yet when he rehomes a mailbox from server #1 to server #2, that user's inbound emails do not transfer from server #1 to server #2 and they just sit in an SMTP queue and never get to the mailbox homed on server #2.

I think the only thing missing in his case, is server-server message transfer for whatever reason (he didn't describe his routing group or connector configuration).

So he needs to be able to successfully have a test user homed on server #2 receive emails just like those on server #1, i.e. inbound emails come into server #1, server #1 looks up and realizes mailbox is homed on server #2, server #1 transfers message to server #2, server #2 places message in mailbox. Likewise test user homed on server #2 needs to be able to send outbound email which will transfer to server #1, and then send outbound through the same SMTP virtual server as those homed on server #1.

Once this is working, he can replicate all public folders to both servers and start rehoming user mailboxes to server #2, and he can do the rehoming process over several hours, days, or weeks, as his own schedule desires. Once he has successfully rehomed all mailboxes, he can transfer inbound/outbound mail processing to server #2 and begin the server #1 decomissioning process (remove public folder replicas from server #1, relocate system folders for free/busy and OAB, rehome RUSS, and probably some other things which I'm not remembering at the moment) which is covered step-by-step in articles on

Just needs to get the server-server message transfer happening first.

edited: sorry I know this is a little verbose, just trying to be thorough for the sake of the OP and others.

Good luck!

Collapse -

.... exactly....

by troy In reply to I think we may be saying ...

I just posted again.... but I agree Churdoo, that is exactly my plan. I expect this process to take a couple of days at the least, hence the need for both mail stores to be resolvable.

Collapse -

I don't think we are Churdoo

by CG IT In reply to I think we may be saying ...

If you install a new exchange server on a network with an existing exchange server, both will recognize each other. This is done automatically But the first Exchange server that has the database, information stores, mailboxes, distribution lists, routing groups, does all the work. If he didn't cluster, didn't setup front end back end, then the second one is simply another Exchange server and doesn't do much of anything except be there. This isn't like a domain controller where each are peers with replication. This is because typically an single instance of Exchange server can handle large #s of users. So Exchange is by default, designed for a single instance. Not multiple instances of Exchange. Multiple instances of exchange is for front end backend or clustering. Not multiple instances of exchange that run in tandem with each other.

His problem is simply storage and moving to new hardware will solve that.

But I'm a little behind on Exchange atm.

Collapse -

Yes move to new hardware, however

by Churdoo In reply to I don't think we are Chur ...

I agree with most of what you said, and I do agree and understand that they do not replicate like DC's ... however Exchange is designed as an enterprise level email system and as such is certainly designed to have multiple Exchange servers in an exchange organization, whether front-end/back-end or not, and whether clustered or not.

The only way I know of to replace exchange server hardware, broad strokes, is to bring up the new hardware as a new distinct server in the existing exchange organization (and I agree, at this point it's simply there), re-home user mailboxes and public folders to it, and then decommission/retire the old one by re-homing all of the other functionality as applicable (mail flow, free/busy, OAB, RUS, etc.) to another server in the exchange organization, and finally decommission the old. While storage is his main problem, you cannot simply move the priv and pub databases from one exchange server to another without going through this process.

Collapse -

True which is the method to move to new hardware

by CG IT In reply to Yes move to new hardware, ...

the way I read he was trying to work out is having both as peers [round robin style] and this does not work with Exchange unless you do front end back end or cluster[2 node].

Collapse -

My plan is...

by troy In reply to yeah but.....

I think Churdo and you are both on the same page. The important thing is to be able to have users on either machine receive email. When I try to move 30 users, 10 might fail and need to reside on the original (I expect this to happen), all the others will be on the new server, which will have a new store created with their mailboxes in the new store (with acceptable space usage). Once I am able to conquer the problematic users, and move the public folders over, I will decommission the old machine.

Churdo, I tried to add a routing connector and it said I needed to have 2 routing groups which I then created. I 'cut' the new sever from the members folder and pasted it in the new routing group and it became master, and asked if I wanted to make a new one on the remote server. I said yes, and I tried the whole process again, and it never got delivered to the new server. Any ideas?


PS: thanks for the replies already...

Collapse -

SMTP queue?

by Churdoo In reply to My plan is...

Well you didn't have to add a new routing group, and could have done this in the original RG, but having separate routing groups won't hurt anything either.

You had said that the messages get hung in an SMTP queue? Do you have any customizations in your SMTP virtual server on your server #1 in order to send outbound mail through your ISP, for example alternate SMTP port (instead of port 25) or SMTP AUTH credentials? I suspect something in your SMTP virtual server properties is what's causing your problem.

Related Discussions

Related Forums