Solutions Engine Blog

Exchange 2010 Connectors: Part IV

By Exchange MVP Krishna Kumar

Part 4: Foreign, Linked and Routing Group Connectors

There are several connectors available in Microsoft Exchange server 2010. Thus far, we have covered Send connectors and Receive connectors and learned how to create each kind using both the Exchange Management Console and the Exchange Management Shell. But what about the other kinds of Exchange 2010 connectors? In my conclusion of this Four-Part series, I will review Foreign, Linked and Routing Group Connectors and walk you through the steps of creating and configuring each one.

Foreign Connectors

Foreign connectors are used to communicate with third party systems. Rather than use SMTP to communicate with these systems, Foreign connectors use drop directories to communicate. For example, if Exchange 2010 wants to communicate with a third party system (which could be a server or an application), then it leaves the message in a drop directory on the Hub Transport server or Network Share. The third party application then retrieves the message from the drop directory, and processes the emails.

Alternatively, if a third party application wants to send a message into Exchange 2010, then it performs a similar action using the replay directory, which exists on the Hub Transport server. Correctly formatted email message files that are copied to the Replay directory are then submitted for delivery.

Foreign connectors are stored in Active directory and are available to all the Hub Transport servers in the organization, which then use foreign connectors to route emails to destination folders for a given address space. For redundancy, multiple Hub Transport servers can be added to the connector so that if one server fails or is otherwise unavailable, then the email will be routed using an alternate Hub Transport server.

In Exchange 2010, foreign connectors use Delivery Agent connectors to route email to the foreign systems. Delivery Agent connectors ensure that the messages intended for foreign systems are inserted into the appropriate queues on the Hub Transport servers that are used for delivering such messages. After the messages are queued, the delivery agent is invoked by the Connection Manager, and the agent handles the actual delivery of the message to the foreign system.

Creating and Configuring a New Foreign Connector

For the sake of speed, we will handle this task using the Exchange Management Shell. Once the shell is open, run the New-Foreignconnector command, which is extensively documented on TechNet:

New-Foreignconnector -identity “ForeignConnector” -AddressSpaces “fax:*” -SourceTransportServers “Hub01.domain.com”,”Hub02.domain.com”

In Figure 17, we are trying to create a foreign connector for the Fax application, with the address space Fax:*, while making use of just a single Hub Transport server called Kexch. Naturally, any fax messages would use this connector:

New-Foreignconnector -name “foreignconnector” -addressspace fax:* -sourcetransportserver Kexch

Once you have created the connector, you can easily modify it based on your requirements using the Set-foreignconnector cmdlet. Below I have specified the drop directory for my new connector, and set the maxmessage size to 10 MB.

Set-Foreignconnector -Identity “Foreignconnector” -Maxmessagesize 10MB -dropdirectory C:\DropDirectory

Linked connector

As the name suggests, a Linked Connector exists when a Receive Connector is linked to a Send connector. Thus, it is a relationship rather than an actual connector itself, and it exists for a very good reason. A Linked connector is used when you have third-party anti-spam and anti-virus systems (such as Postini) processing your messages at a vendor’s location or on a different server. In this type of situation, you need to ensure that all the incoming email passes through the third party appliance and that it receives those emails back once the email scanning and filtering is completed. This is what the Linked connector enables.

You can create Linked connectors on Hub Transport or Edge Transport Servers and, thankfully, you can use them without changing your existing configurations, such as your MX records or Sender Policy Framework, etc. Below is the process for creating Linked connectors on the existing network:

Let’s take a quick look at the setup in Figure 18

Sendconnector:25 and Receiveconnector:25 are the two connecters configured to send and receive all email between the internal network and the Internet. When we want our email to be scanned by anti-spam servers, we need to create and configure the connectors between our internal network and those external servers, and then create an appropriate link to our existing connectors.

First, we need to create the new Sendconnector:26, and link it with the Receiveconnector:25, and configure the Send connector to deliver incoming email (from step 1 in the image) to the anti-spam solution (step 2 in the image). Next, we need to create the new Receiveconnector:27 to receive email back from the anti-spam solution (step 3), and deliver that email to the internal Exchange server, which will then distribute the email to the appropriate users (step 4).

That sounds simple enough, so let’s create the new Sendconnector:26 and Receiveconnector:27 connectors, and configure the link between Receiveconnector:25 and Sendconnector:26

Creating and Configuring Linked Connectors

In the command below, we are creating a new Send connector and using the linkedreceiveconnect command to link the new connector with the existing Receiver. The -SmartHosts parameter allows you to enter the details of the anti-spam server. DNS routing needs to be disabled. Normal Send connectors are configured with DNS for delivering emails to the remote domains. This Send connector is linked with the receive connector to forward email to specific servers; thus, there is no need for DNS routing, which is set to $false. Smart host authentication is set to Externalauthoritative. Externalauthoritative authentication is used when the connection is fully secured between the Exchange server and Smart Host (Anti Spam Server). Once Externalauthoritative is set, then any client can connect to the Exchange sever as an Authorized Server. Below is the Powershell command to create the new Sendconnector:26 and link it with receiveconnector:25 to deliver all the incoming emails from the internet to the smart host.

New-SendConnector -Name “Sendconnector:26″ -LinkedReceiveConnector “Edge01\Receiveconnector:25″ -SmartHosts antispam -SmartHostAuthMechanism Externalauthoritative -DNSRoutingEnabled $False -MaxMessageSize unlimited

Now let us create the new Receive connector for receiving email back from the anti-spam server. The new-receiveconnector cmdlet below creates a new connector with externalauthoritative authentication and the remoteIPrange set to the anti-spam server.

New-Receiveconnector -name “Receiveconnector:27″ -AuthMechanism externalAuthoritative -RemoteIPRanges antispam

Routing Group Connectors

Routing Group connectors (RGC) are used to facilitate internal mail flow between Exchange 2010/2007 servers and Legacy Exchange 2003 servers. An RGC does not needed between Exchange 2010 and 2007 since communication happens automatically. Bidirectional instances of these connectors are installed by default when you introduce a new Exchange 2010 Hub Server into the Exchange Organization. In other words, Routing Group connectors are created during the installation: one for mail flow between Exchange 2003 and Exchange 2010, and one for mail flow between Exchange 2010 and Exchange 2003.

Exchange 2003 uses a link state routing table to maintain how email is routed within the organization. This table is updated when the routing group master effects a change in the mail routes.

Link State routing is not used at all in Exchange 2010, which instead communicates with the Hub server directly and uses the AD site cost to determine the shortest routing path. We can create multiple Routing Group connectors between Exchange 2003 and Exchange 2010, but if we do, we will need to make sure to suppress Link state updates so that message looping does not occur when we recalculate a route.

Next, we will discuss how to create new Routing Group connectors and how to modify them to add additional source and target servers for redundancy in the event of a server failure.

The New-Routinggroupconnector cmdlet below creates a new Routing Group connector. In terms of settings, the Sourcetransportserver and TargetTransportservers need to be specified, and the Bidirectional setting controls whether this connector allows for two-way or one-way mail flow. If bidirectional is set to $true, then two connecters will be created, as a reciprocal connector is created in the target routing group.

New-RoutingGroupConnector -Name “RGCBidirection” -SourceTransportServers “Hub2010a.domain.com” -TargetTransportServers “Bridgehead2003.domain.com” -Cost 100 -Bidirectional $true

For redundancy, we can add multiple source and target transport servers into the existing “RGCBidirection” connector using the Set-RoutingGroupConnector cmdlet:

set-RoutingGroupConnector -Identity “RGCBidirection” -SourceTransportServers “Hub2010a.domain.com”, “Hub2010b.domain.com” -TargetTransportServers ” Bridgehead2003a.domain.com”,” Bridgehead2003b.domain.com”

Lastly, if you want to get the complete status on the newly created and configured routing group connectors, use the Get-RoutingGroupConnector cmdlet like so:

Get-Routinggroupconnector -identity “RGCBidirection”
format-list

If you want a deeper understanding of the New-RoutingGroupConnector cmdlet, extensive details are once again available from Microsoft TechNet. Likewise, there is a lot of information available on the Set-RoutingGroupConnector and Get-RoutingGroupConnectorcmdlets.

Conclusion

I hope this article has been informative and was able to provide administrators with a deeper understanding of all the Exchange 2010 connectors, configurations and their applications.

In this article series, I have taught you how to create and configure connectors using both the Exchange Management Console and the Exchange Management Shell. Creating and configuring connectors using PowerShell is always easy, but remember to make sure that all the required parameters are used correctly. Some connecters, such as the Linked connectors, cannot be created using the Exchange Management Console, only PowerShell. Creating and managing connectors via the Management Console provides limited options. PowerShell Set-* and Get-* cmdlets allows exploring various advanced options which cannot be performed with the Management Console. Set-* Powershell cmdlets allow connectors to be configured at a granular level.