dj_relentless
asked on
Messages remaining in routing group connector
I have this incredibly strange problem with exchange between 4 sites.
I have 4 sites. Each was configured in its own administrative group.
Our main office has a routing group connector for each of the 3 servers in the other offices.
Yesterday I changed the exchange organisation to native mode and since then the offices have had lots of problems sending mail within the organisation.
If I send a blank test message from one of the sites the message will arrive but there are messages in the queue that will not come through.
In the event logs I've seen this event logged once in a while.
Message delivery to the host 'x.x.x.x' failed while delivering to the remote domain '_693a5a4ec6af5d4081f63b04 3f920e7a_D ' for the following reason: The semaphore timeout period has expired.
I also see this log
Message delivery to the host '192.168.0.4' failed while delivering to the remote domain '_693a5a4ec6af5d4081f63b04 3f920e7a_D ' for the following reason: The connection was dropped by the remote host.
I don't see any other logs that would indicate a problem.
When I look at the main servers smtp connector I see sessions from the remote servers, you can see the sessions have been connected for over 300 seconds. Its like the connection is made and then it just stays open.
When sending from the head office server to any of the others it works fine but the other way its very tempremental.
I've run the exchange trouble shooting tool and it reports no problems.
I've using symantec enterprise, I've verified I'm not using internet email scanning plugin.
The server are connected via cisco ipsec tunnels, all ports are good.
I'm really puzzled on this. Like I said it worked fine until I went into native mode and of course. Theres no going back.
I have 4 sites. Each was configured in its own administrative group.
Our main office has a routing group connector for each of the 3 servers in the other offices.
Yesterday I changed the exchange organisation to native mode and since then the offices have had lots of problems sending mail within the organisation.
If I send a blank test message from one of the sites the message will arrive but there are messages in the queue that will not come through.
In the event logs I've seen this event logged once in a while.
Message delivery to the host 'x.x.x.x' failed while delivering to the remote domain '_693a5a4ec6af5d4081f63b04
I also see this log
Message delivery to the host '192.168.0.4' failed while delivering to the remote domain '_693a5a4ec6af5d4081f63b04
I don't see any other logs that would indicate a problem.
When I look at the main servers smtp connector I see sessions from the remote servers, you can see the sessions have been connected for over 300 seconds. Its like the connection is made and then it just stays open.
When sending from the head office server to any of the others it works fine but the other way its very tempremental.
I've run the exchange trouble shooting tool and it reports no problems.
I've using symantec enterprise, I've verified I'm not using internet email scanning plugin.
The server are connected via cisco ipsec tunnels, all ports are good.
I'm really puzzled on this. Like I said it worked fine until I went into native mode and of course. Theres no going back.
ASKER
I double checked this and set all the other offices to their specific ips and recreated the connectors. No difference.
I forgot to mention that I've run winroute and verified everything looks happy. All routing connectors say they have connections.
I forgot to mention that I've run winroute and verified everything looks happy. All routing connectors say they have connections.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Your a legend. I had sat there staring at the anti virus software, routing connectors and event logs until my eyes were sore (which was from 2pm until 9:30pm last night). Nothing is worse than working late and going home knowing you didn't achieve anything.
I checked the cisco firewall responsible for the vpn and low behold it was set to inspect smtp traffic. Disabled and the connector kicked into life and cleared the queue. I'm checking our other sites now and it looks like they all have the same inspection set on the firewalls.
I checked the cisco firewall responsible for the vpn and low behold it was set to inspect smtp traffic. Disabled and the connector kicked into life and cleared the queue. I'm checking our other sites now and it looks like they all have the same inspection set on the firewalls.
Simon.