Mixed 2007/2003 org - unable to relay from 2003 thru 2007

blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
I'm currently building a 2007 site in one of our offices that has an existing 2003 RG. I have the Hub Transport set up with the RG connector set up with the 2003 RG bridgehead, a send connector for Internet email, and I modified the Default receive connector to accept Internet email per the instructions in this Technet article

How to Configure Internet Mail Flow Through Exchange Hosted Services or an External SMTP Gateway
http://technet.microsoft.com/en-us/library/bb738161(EXCHG.80).aspx

I tested relaying through this Hub server to the Internet and to recipients in the 2003 databases and it worked OK. But I ran upon this curiosity on the 2003 side last night when something happened to make the SMTP Connector for Internet email for the 2003 RG go offline for a few minutes. I guess it checked the routing topology and saw the Send connector as a valid route for email destined for external recipients - I would think this is good. The problem is that the Default connector on my Hub Transport rejected the message from users on the 2003 side with an "Unable to Relay" 550 message. My understanding was that this default connector is the connector used to transport mail between servers in the organization. I don't understand why it would reject valid users. Of course, once the SMTP connector on the 2003 server came back online this was no longer a problem, it reverted back to using that connector to send email to the Internet.

Am I missing something obvious here? I don't want to have to turn off the Hub Transport server but I might have to if the result when the 2003 Internet connector is unavailable is trying to send through a connector that won't allow the users on 2003 to relay.

Any ideas?

Thanks for reading.

Blargoe
IT guy since 12/00

Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
Working on: RHCE/Ansible
Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...

Comments

  • royalroyal Member Posts: 3,352 ■■■■□□□□□□
    You didn't manually create any type of connector in between the Exchange 2003 and Exchange 2007 Routing group, did you? The connector that is created when Exchange 2007 is installed should be left alone. If you did anything to it, you can re-create it using New-RoutingGroupConnector.

    So we know that the Send Connector that you are using to smart host to Exchange Hosted Services or whatever device you're smart hosting to is working fine because clients directly on Exchange 2007 are using it correctly. Am I correct about this? It's ONLY when users in the Exchange 2003 Routing group are trying to send mail?

    Ensure that on the Default Receive Connector it has the following permission groups: Exchange users, Exchange servers, Legacy Exchange servers.

    If you want users in the Exchange 2003 Routing Group to be able to send out of the Exchange 2007 group, you need to create a new Internet Connector in the Exchange 2003 Routing Group that tells it that mail sent to * to smart host that to the Exchange 2007 Connector.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
    royal wrote:
    You didn't manually create any type of connector in between the Exchange 2003 and Exchange 2007 Routing group, did you? The connector that is created when Exchange 2007 is installed should be left alone. If you did anything to it, you can re-create it using New-RoutingGroupConnector.

    Yeah, that's what happened. I modified the FQDN for EHLO, which from what I just read in the Help file is a big no-no for the default connector. I'm going to get the default back to the original default and do some more testing.

    Thanks royal.
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • HeroPsychoHeroPsycho Inactive Imported Users Posts: 1,940
    +1 for royal.

    For the record, you can add additional RG connectors for redundancy and to optimize mail routing, but don't mess with the one that's built by default. Bad things happen, as you are seeing.
    Good luck to all!
  • royalroyal Member Posts: 3,352 ■■■■□□□□□□
    Well, you can change it. But to one of three things. The FQDN of the server, the NetBIOS name of the server, or blank (via the EMS). Other than that, it should not be set to something else. If you trying to upgrade from RTM to SP1, if it's not set to one of those 3, your SP1 installation will fail.

    Also, just found this:
    http://technet.microsoft.com/en-us/library/aa996395(EXCHG.80).aspx
    Don’t modify the FQDN value on the default Receive connector named “Default <Server Name>” that is automatically created on Hub Transport servers. If you have multiple Hub Transport servers in your Exchange organization and you change the FQDN value on the “Default <Server Name>” Receive connector, internal mail flow between Hub Transport servers will fail.

    Sounds like one of the benefits of having an Edge Transport Server. Although I wonder if the Edge Transport Server routing would fail if you change it to something other than FQDN/NetBIOS/Blank.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
  • blargoeblargoe Member Posts: 4,174 ■■■■■■■■■□
    Well the only reason I had changed it was because I made the mistake of trying to also use that Default connector to receive Internet email and I didn't want my server's FQDN in the ehlo, but now that I went and set up a new connector and changed back the Default to the server fqdn everything seems to be working fine.

    We use a hosted filtering service and one thing that seems to be different is with 2003, I could just set the SMTP Virtual Server to "allow authenticated users to relay regardless of address", enter the internal app servers that needed to have relay permissions, and allow * to send through my server for the domains that I'm hosting, and that was enough for RECEIVING Internet email, because our perimeter firewall had the subnets for the filtering services in its table so I didn't need to define them on the server. On 2007, I have to enter all the IP ranges of the hosted filtering service in the remote hosts on my internet receive connector (or otherwise there's nothing blocking any host inside my network can relay), and create a separate connector for my internal servers that need to relay. Now that I understand that I'm squared away.

    Thanks again guys.
    IT guy since 12/00

    Recent: 11/2019 - RHCSA (RHEL 7); 2/2019 - Updated VCP to 6.5 (just a few days before VMware discontinued the re-cert policy...)
    Working on: RHCE/Ansible
    Future: Probably continued Red Hat Immersion, Possibly VCAP Design, or maybe a completely different path. Depends on job demands...
  • royalroyal Member Posts: 3,352 ■■■■□□□□□□
    Yep, that'd definitely another good way to get the FQDN displaying the way you want it. Leaving the Default Connector at default settings for internal routing but created a brand new Internet Receive Connector and enabled that for internet connections and enabled that for Internet Connectivity.
    “For success, attitude is equally as important as ability.” - Harry F. Banks
Sign In or Register to comment.