Routing Group Connector Issue

We have a problem with a routing group connector in Exchange 2003 and was hoping someone could help.

We have a central Exchange 2003 Enterprise edition XS server at head office, we have a remote office with a standard edition exchange 2003 server, both running on Windows Server 2003. Each XS is in it's own routing group and we have setup routing group connectors in each routing group.

The routing group connector at the remote office has no problems sending emails back to head office, however, the routing group connector at the head office will send some emails to the remote office then stop working. We have to create a new routing group connector with a higher priority in order for the trapped emails to go out, however, this new routing group connector soon stops working in the same way. We have to continually create new routing group connectors for emails to go to the remote office.

When we highlight the routing group connector it just says No additional information available.

Does anyone know how to resolve this?
bahill14Asked:
Who is Participating?
 
SembeeCommented:
The linkstate is changing to down, and then doesn't come back up.

Anything scanning the traffic? AV, firewalls with SMTP scanning features etc?

When the connection has gone down, can you telnet to port 25 of the other server by all three... :

telnet ipp.add.re.ss 25
telnet servername 25
telnet host.domain.com 25

Simon.
0
 
SembeeCommented:
I was going to type out a long answer... then remembered I blogged on it.
http://www.sembee.co.uk/archive/2007/02/19/40.aspx

Check the SMTP Virtual server config - set it to the specific IP address rather than all unassigned. Then recreate the RGCs.

Simon.
0
 
bahill14Author Commented:
Hi Simon,

thanks for getting back to me so quickly. Have checked and we had set the specific IP address at both the head office and remote office SMTP virtual servers, can you think of anything else?

Kind regards,

Brett
0
Ultimate Tool Kit for Technology Solution Provider

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy now.

 
SembeeCommented:
Do you get anything logged when the connector fails?

Simon.
0
 
bahill14Author Commented:
Thanks, have checked the event logs on both servers and there's nothing,
Brett
0
 
SembeeCommented:
You may have to turn up diagnostic logging to get anything to log that is of use. If it is happening frequently you shouldn't need to run diagnostic logging for every long to catch the error and see if anything is shown.

Simon.
0
 
bahill14Author Commented:
Hi Simon,
I've enabled logging on the Head office server and attached the event logs. There are currently two routing group connectors setup on this server to connect to the remote office exchange server, remote office exchange server IP address is 10.128.1.10. These routing group connectors are called FBR 7 and FBR 8, as you can see they keep going up and down. Please let me know if you need anything else,
kind regards, Brett

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 974
Time: 21:16:16
On Master side, the following connector's linkstate is down. Process Id: 444 Process location:
C:\WINDOWS\system32\inetsrv\inetinfo.exe ConnectorDN: CN=FBR 8,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 977
Time: 21:07:18
Following connector fails to connect to its target bridge head. CN=FBR 8,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Connection Manager
Event ID: 4006
Time: 21:07:18
Message delivery to the host '10.128.1.10' failed while delivering to the remote domain  
'_c18a68244b6954478c6fca956d40ea70_D' for the following reason: The semaphore timeout period
has expired.

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 977
Time: 20:22:48
Following connector fails to connect to its target bridge head. CN=FBR 7,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Connection Manager
Event ID: 4006
Time: 20:22:48
Message delivery to the host '10.128.1.10' failed while delivering to the remote domain  
'_b58122a536a71a4e8cc9aae37044e96c_D' for the following reason: The semaphore timeout period
has expired.

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 973
Time: 20:16:16
On Master side, the following connector's linkstate is up. Process Id: 444 Process
location: C:\WINDOWS\system32\inetsrv\inetinfo.exe ConnectorDN: CN=FBR 8,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 978
Time: 20:08:50
Following connector now is ok to connect to its target bridge head. CN=FBR 8,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 974
Time: 19:24:26
On Master side, the following connector's linkstate is down. Process Id: 444 Process
location: C:\WINDOWS\system32\inetsrv\inetinfo.exe ConnectorDN: CN=FBR 8,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 977
Time: 19:15:17
Following connector fails to connect to its target bridge head. CN=FBR
8,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Connection Manager
Event ID: 4006
Time: 19:15:17
Message delivery to the host '10.128.1.10' failed while delivering to the remote domain  
'_c18a68244b6954478c6fca956d40ea70_D' for the following reason: The semaphore timeout period
has expired.

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 978
Time: 18:27:19
Following connector now is ok to connect to its target bridge head. CN=FBR
7,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Routing Engine/Service
Event ID: 977
Time: 18:26:17
Following connector fails to connect to its target bridge head. CN=FBR
7,CN=Connections,CN=Edinburgh,CN=Routing Groups,CN=Buccleuch Group,CN=Administrative
Groups,CN=BuccleuchIT,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=buccle
uchit,DC=local

Source: MSExchangeTransport
Category: Connection Manager
Event ID: 4006
Time: 18:26:17
Message delivery to the host '10.128.1.10' failed while delivering to the remote domain  
'_b58122a536a71a4e8cc9aae37044e96c_D' for the following reason: The semaphore timeout period
has expired.

Source: MSExchangeTransport
Category: Connection Manager
Event ID: 4006
Time: 18:16:46
Message delivery to the host '10.128.1.10' failed while delivering to the remote domain  
'_e6035aafe731124da9b539c5ee70b75c_D' for the following reason: The semaphore timeout period
has expired.







0
 
bahill14Author Commented:
Simon thanks very much for your help but managed to resolve the problem ourselves. It was a networking issue!

We sniffed the network traffic to discover that the head office XS was sending it's packets to the remote office through a route that was dropping packets over 2000 bytes in size. This must have been interfering with the head office XS routing group connector RPC calls to the remote office XS. The remote XS was returning the packets via a different route that didn't have that problem that's why it's routing group connector was ok. Once we altered the route and the large packects stopped getting dropped the routing group connector problem was sorted!

Would like to offer you some points for helping us eliminate possible causes, not sure how to do it though!

Cheers, Brett
0
 
SembeeCommented:
Post in the support topic area (top right corner) and ask the moderators.
I think the way that they do it is to drop the number of points available, then accept an answer. I might be wrong, I don't tend to notice what is going on with points, I have 14 million or something of the things.

Simon.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.