Accidental Exchange 2007 Failover
On Thu, 18 Aug 2011 08:56:36 +0000, trueUser wrote: >I am using Exchange 2007 for our email messaging solution. On the different network we have another Exchange 2007 installed whos only purpose is to host Mitel Pbx public folders thats it. These two networks are completely separate but they can communicate with each other. Yesterday, my primary exchange server was unable to send mails (intended for external domains) but was working fine for local users. I check the Message Tracking and discovered that all the mails are going to other exchange server instance (Mitel) and checked the Exchange (Mitel) and its que was overloaded with all the undelivered emails. This Exchange (Mitel) is used locally to store public folders and it cannot send mails outside. Then why is it included as a "Source sever" on your Send Connector? >My question is that, Why this failover occured, There's no "failover". You've listed both machines as capable of delivering e-mail to the Internet. >Why the Exchange (Mitel) took over for external email sending. Becasue you said it was capable of doing so. >I also discovered a public connector in exchange (Mitel) that should have delivered the emails outside but it couldn't. So it's a firewall confioguration problem? The 2nd server isn't permitted to use port 25/tcp for outbound connections? If that's true then remove the 2nd server fro your Send Connector (or allow it to use port 25/tcp for outbound connections) >I solved the problem by rebooting the main exchange and then when it came back I rebooted the Exchange (Mitel) one and it seemed to work fine. But in the process I lost all the mails in Que of Exchange (Mitel). That solved nothing. >This all process doesn't make any sense to me. Any help will be highly appreciated. See above. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP
August 18th, 2011 6:16pm

Hello Guys, I am using Exchange 2007 for our email messaging solution. On the different network we have another Exchange 2007 installed whos only purpose is to host Mitel Pbx public folders thats it. These two networks are completely separate but they can communicate with each other. Yesterday, my primary exchange server was unable to send mails (intended for external domains) but was working fine for local users. I check the Message Tracking and discovered that all the mails are going to other exchange server instance (Mitel) and checked the Exchange (Mitel) and its que was overloaded with all the undelivered emails. This Exchange (Mitel) is used locally to store public folders and it cannot send mails outside. My question is that, Why this failover occured, Why the Exchange (Mitel) took over for external email sending. I also discovered a public connector in exchange (Mitel) that should have delivered the emails outside but it couldn't. I solved the problem by rebooting the main exchange and then when it came back I rebooted the Exchange (Mitel) one and it seemed to work fine. But in the process I lost all the mails in Que of Exchange (Mitel). This all process doesn't make any sense to me. Any help will be highly appreciated. Thanks
Free Windows Admin Tool Kit Click here and download it now
August 19th, 2011 5:15am

Hello Rich, Thanks for your reply, Mitel-Exchange has send connector as internet which you advice that it needs to be disabled so the emails could not be accepted anymore for main (Exchange) server. I am fairly new in Exchange Technology has taken over role from some one else so struggling with already deployed network. I have both servers defined in EMC>>Server Configuration>>Hub Transport>>Receive Connectors (is this usual), another thing i realized that when i create a mail box in main server a same account is also created in Mitel-Exchange. I checked the firewalls both servers has unrestricted access (outbound) to internet. Only the Mitel-Exchange does not have public interface while the main server do. I know I have lost many emails in the process but the previous administator told us this solution.
August 19th, 2011 6:04am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics