Logo
programming4us
programming4us
programming4us
programming4us
Home
programming4us
XP
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server
programming4us
Windows Phone
 
Windows Server

Exchange Server 2010 : Setting Up Message Routing (part 2) - Using and Configuring Send Connectors

- Free product key for windows 10
- Free Product Key for Microsoft office 365
- Malwarebytes Premium 3.7.1 Serial Keys (LifeTime) 2019
5/9/2011 6:48:17 PM

3. Using and Configuring Send Connectors

Send connectors are configured on Hub Transport or Edge Transport servers. The Send connector on a Transport server represents a logical gateway through which outbound messages are sent to the next hop on the way to their destination. No explicit Send connectors are created by default when the Hub Transport or Edge Transport server role is installed. However, implicit and invisible Send connectors are automatically computed based on the site topology and are used to route messages internally between Hub Transport servers.

End-to-end mail flow requires that Edge Transport servers be subscribed to the Active Directory site by using the Edge subscription process. If your organization has an Internet-facing Hub Transport server or an unsubscribed Edge Transport server, you need to manually configure Send connectors to establish end-to-end mail flow.

A Send connector created on a Hub Transport server is stored in Active Directory and is available to all Hub Transport servers in the organization. If a Send connector is configured to send messages to an external domain, any Hub Transport server in the organization routes a message for that domain to a source server for that connector. The message is then relayed to the destination domain.

3.1. Send Connector Usage Type

You can use the New Send Connector Wizard in the EMC or an EMS command based on the New-SendConnector cmdlet to create a Send connector.  When you use the EMC, you need to specify a usage type for the connector. When you use the EMS, the default usage type is set to Custom.

The usage type determines the default permissions that are assigned on the connector and grants those permissions to trusted security principals, such as users, computers, and security groups. A security principal is identified by a security identifier. The usage type also defines the default smart host authentication mechanism. Note that if DNS resolution delivery is selected for a Send connector instead of a smart host, no smart host authentication mechanism is configured. Send connector permissions and smart host authentication mechanisms are discussed in detail later in this lesson. The available usage types are as follows:

  • Custom This usage type has no default permissions and no smart host authentication mechanism. You would select the Custom usage type for a Send connector on an unsubscribed Edge Transport server that sends email to a Hub Transport server. You would also select the Custom usage type for a cross-forest Send connector on a Hub Transport server that sends email to an Exchange Server 2010 or an Exchange Server 2007 Hub Transport server, or to an Exchange Server 2003 bridgehead server in a second forest. You would also select this usage type for a Send connector on a Hub Transport server that sends email to a third-party smart host and for an Edge Transport server that sends email to a third-party smart host or to an external relay domain.

  • Internal The default permission sets for this usage type are ms-Exch-Send-Headers-Organization, ms-Exch-SMTP-Send-Exch50, ms-Exch-Send-Headers-Routing, and ms-Exch-Send-Headers-Forest. Default permissions are granted to Hub and Edge Transport servers, externally secured servers, the Exchange Legacy Interop universal security group, and Exchange Server 2003 and Exchange 2000 Server bridgehead servers. The Default smart host authentication mechanism is Exchange Server Authentication. You would select this usage type for a Send connector on a subscribed Edge Transport server that sends email to a Hub Transport server or to an Exchange 2003 bridgehead server. This connector is automatically created by the edge subscription process, and if email is being sent to an Exchange 2003 bridgehead server, that server needs to be configured as a smart host.

  • Internet The default permissions set for this usage type is Ms-Exch-Send-Headers-Routing. Default permissions are granted to anonymous user accounts and there is no smart host authentication mechanism. You would select this usage type for a Send connector on an Edge Transport server that sends email to the Internet. Note that a Send connector that is configured to send email to all domains is created automatically when the Edge Transport server is subscribed to the Exchange organization. If you wanted to send email directly on to the Internet from a Hub Transport server, you would need to configure a Send connector with the Internet usage type. However, this is not considered best practice.

  • Partner The default permissions set for this usage type is Ms-Exch-Send-Headers-Routing, and default permissions are granted to partner servers. The smart host authentication mechanism is not applicable because this usage type is selected when you establish MTLS authentication with a remote domain. You would apply the Partner usage type to a Send connector on an Edge Transport server that sends email to a domain with which you have established MTLS authentication.

3.2. Send Connector Address Space

The Send connector address space, specified, for example, in the AddressSpace parameter of the New-SendConnector EMS cmdlet, specifies the names of domains to which the Send connector routes mail. You need to specify the AddressSpace parameter unless the Send connector you are creating is linked to a Receive connector. If a linked Receive connector is specified by using the LinkedReceiveConnector parameter, the value of the AddressSpace parameter must be $null. Receive connectors are discussed later in this lesson.


Note:

THE ADDRESSSPACE PARAMETER

You can use AddressSpace or AddressSpaces interchangeably with the New-SendConnector cmdlet. Both parameters specify one or more address spaces.


The syntax for entering an address space is as follows:

<AddressSpaceType>:<AddressSpace>;<AddressSpaceCost>


Note:

Notice that the first symbol in the address space syntax is a colon and that the second is a semicolon.


On an Edge Transport server, the address space type must be SMTP. On a Hub Transport server, it may be SMTP, X400, or another text string. If you omit the address space type, SMTP is assumed.

For SMTP address space types, the address space that you enter must be RFC 1035 compliant, for example, *.*.com, and *.adatum.com. For X.400 address space types, the address space that you enter must be RFC 1685 compliant, such as o=ThisSite;p=ThisOrg; a=adatum;c=us. For all other values of address space type, there are no format restrictions on the text for the address space.

The valid input range for the address space cost is from 1 through 100. A lower cost indicates a better route. This parameter is optional; if you omit the address space cost, a cost of 1 is assumed. If you enter a non-SMTP address space that contains the semicolon character (;), you must specify the address space cost.

If you specify the address space type or the address space cost, you must enclose the address space in quotation marks (“), for example, “SMTP:adatum.com;1.”

You can specify multiple address spaces by separating the address spaces with commas, for example, contoso.com,fabrikam.com or “SMTP:adatum.com;1”,“SMTP:Fabrikam.com;2”.


Note:

NON-SMTP ADDRESS SPACE

If you specify a non-SMTP address space type on a Send connector configured on a Hub Transport server, you must use a smart host to route email by specifying a value for the SmartHosts parameter, and you must set the DNSRoutingEnabled parameter to $false.


The following EMS command creates a Send connector named SendConnector01 with a usage type of Internet that sends email to all .com Internet sites:

New-SendConnector -Internet -Name SendConnector01 -AddressSpace "SMTP:*.com;1"


Figure 4 shows the output of this command.

Figure 4. Creating a Send connector


The following EMS command reconfigures the Send connector SendConnector01 to send email to an address space of the adatum.com domain and all its subdomains:

Set-SendConnector -Identity SendConnector01 -AddressSpace *.adatum.com


Note:

CHANGING THE USAGE TYPE

You cannot reconfigure the usage type using the Set-SendConnector cmdlet. To do this, you need to delete the connector using the Remove-SendConnector cmdlet and then re-create it with a different usage type. You can (optionally) use the Usage parameter in the New-Send-Connector cmdlet to specify the usage type for a new Send connector, but this parameter does not exist for the Set-SendConnector cmdlet.


The following EMS command lists the properties of the Send connector SendConnector01:

Get-SendConnector -Identity SendConnector01

Figure 5 shows the output of this command.

Figure 5. Listing properties for a Send connector



Note:

DISABLING OR REMOVING A SEND CONNECTOR

If you want to temporarily disable a Send connector, you would use the Set-SendConnector EMS cmdlet and set the Enabled parameter to $false. If you use the Remove-SendConnector parameter, this deletes the Send connector, and you would subsequently need to create it again.


3.3. Send Connector Permissions

When a security principal establishes a session with a Send connector, the Send connector permissions assigned to that security principal determine the types of header information that can be sent with the email message. If an email message includes header information that is not allowed by the Send connector permissions, those headers are stripped from the message. Table 2 describes the permissions that can be assigned on a Send connector to security principals. You can use the Add-ADPermission EMS cmdlet to modify the default permissions for a Send connector.

Table 2. Send Connector Permissions
Send Connector Permission Description
ms-Exch-Send-Exch50 Allows the session to send a message that contains the EXCH50 command.
Ms-Exch-Send-Headers-Routing Allows the session to send a message that has all received headers intact.
Ms-Exch-Send-Headers-Organization Allows the session to send a message that has all organization headers intact.
Ms-Exch-Send-Headers-Forest Allows the session to send a message that has all forest headers intact.

3.4. Send Connector Scope

You can use the scope of a Send connector to control the visibility of the connector within the Exchange organization. By default, all Send connectors that you create are usable by all the Hub Transport servers in the Exchange organization. However, you can limit the scope of any Send connector so that it is usable only by other Hub Transport servers in the same Active Directory site.

You can use the EMS IsScopedConnector parameter in the New-SendConnector cmdlet or the Set-SendConnector cmdlet. When the value of this parameter is $true, the connector can be used only by Hub Transport servers in the same Active Directory site. When the value of this parameter is $false, the connector can be used by all Hub Transport servers in the Exchange organization.

For example, the following EMS command configures the Send connector SendConnector01 so that it can be used only by Hub Transport servers in the same Active Directory site:

Set-SendConnector -Identity SendConnector01 -IsScopedConnector $true

3.5. Using DNS Resolution to Deliver Email

You can configure Send connectors so that they deliver email by using DNS address resolution or by routing the email to a smart host. When the Send connector is set to use DNS Mail Exchange (MX) resource records to route mail automatically, the DNS client on the source server must be able to resolve public DNS records. By default, the DNS server that is configured on the source server’s internal network adapter is used for name resolution.

You can configure a specific DNS server to use internal and external DNS lookups by using the EMC to modify the DNS settings on the Exchange server properties. If you configure a DNS on the Transport server to use external DNS lookups and use the New SMTP Send Connector wizard in the EMC to create a Send connector, you can select Use DomainName System (DNS) “MX” Records To Route Mail Automatically on the Network Settings page of the wizard. Whether you select this option or the alternative Route Mail Through The Following Smart Hosts, you can choose to select the Use The External DNS Lookup Settings On The Transport Server check box.

You can configure a Send connector to use DNS resolution by setting the UseExternalDNSServersEnabled parameter with the Set-SendConnector or New-SendConnector EMS cmdlets. When this parameter is set to $true (the default is $false), the Send connector uses the external DNS list that you can specify by using the Set-TransportServer EMS cmdlet with the ExternalDNSServers parameter, such as follows:

Set-TransportServer -Identity VAN-EX1 -ExternalDNSServers 192.168.30.2,10.10.50.10
Set-SendConnector -Identity SendConnector01 -UseExternalDNSServersEnabled $true

3.6. Using a Smart Host to Route Email

You must specify a smart host if you select the Internal usage type for a Send connector. When you route mail through a smart host, this host handles delivery to the next hop in the delivery destination. You can use an IP address or the fully qualified domain name (FQDN) of the smart host to specify the smart host identity. The smart host identity can be the FQDN of a smart host server, an MX record, or an Address (A) resource record. If you configure an FQDN as the smart host identity, the source server for the Send connector uses DNS name resolution to locate the smart host server.

If you specify the Internet usage type for a Send connector, the smart host for that connector may be a server that is hosted by your Internet service provider. The smart host for a Send connector with the Custom or Internal usage types may be another email server in your organization or an email server in a remote domain.

The following EMS command creates a Send connector named Contoso that transmits messages through a smart host named smarthost.contoso.com to Contoso’s mail domain mail.contoso.com (note that the usage type is Internet and that you would create such a connector on an Edge Transport server):

New-SendConnector -Internet -Name Contoso -Addresspaces smtp:mail.contoso.com
-Smarthosts smarthost.contoso.com


When you route mail through a smart host, you must specify how the source server will authenticate to the smart host computer. You cannot require security settings for a Send connector unless a smart host destination is specified.

Table 3 lists the smart host authentication mechanisms that you can configure for a Send connector.

Table 3. Smart Host Authentication Mechanisms
Security Setting Description
None Anonymous access is allowed.
Basic authentication This requires a user name and password. Basic authentication sends credentials in clear text. All smart hosts with which this Send connector is authenticating must accept the same user name and password.
Basic authentication over TLS TLS encrypts the transmission of the credentials. The receiving server must have a server certificate. The exact FQDN of the smart host, MX record, or A record that is defined on the Send connector as the smart host identity must also exist in the server certificate. The Send connector performs Basic authentication only after the TLS session has been established. A client certificate is also required to support MTLS authentication.
Exchange Server authentication This uses Generic Security Services application programming interface (GSSAPI) and Mutual GSSAPI.
Externally Secured (for example, with IPsec) The network connection is secured using a method that is external to the Exchange server.

You must select at least one source server for a Send connector. The source server is the Transport server to which messages are routed for delivery through the selected Send connector. You can set more than one source server on a Send connector. When you specify more than one source server, this provides load balancing and redundancy if a server fails. The source servers associated with Send connectors that are configured for the Exchange organization can be Hub Transport servers or subscribed Edge Transport servers.

3.7. Configuring Maximum Message Size and Connection Inactivity Time-Out

You can configure the maximum size of messages sent through a Send connector. Take care to distinguish this from the maximum message size sent over an IP site link. By no means do all the messages that are sent through a Send connector pass over an IP site link. If a message is subject to both Send connector and site-link restrictions, the smaller of the two maximum message sizes is enforced.

You can use the MaxMessageSize parameter with both the New-SendConnector and the Set-SendConnector EMS cmdlets to specify maximum message size. The default value is 10 MB. To remove the message size limit on a Send connector, you can enter a value of unlimited.

You can also use the ConnectionInactivityTimeOut parameter with both the New-SendConnector and the Set-SendConnector EMS cmdlets to specify the maximum time that an idle connection can remain open. The default value is 10 minutes. To specify a value, you enter it as a time span in the format dd.hh:mm:ss, where d = days, h = hours, m = minutes, and s = seconds. The valid input range for this parameter is from 00:00:01 through 1.00:00:00.

The following command configures the send connector SendConnector01 with a maximum message size of 5 MB and a maximum time for which an idle connection can remain open for 20 minutes:

Set-SendConnector -Identity SendConnector01 -MaxMessageSize 5MB
-ConnectionInactivityTimeOut 00:20:00


Other -----------------
- Exchange Server 2010 : Setting Up Message Routing (part 1) - Routing Messages & Using Active Directory Sites and Site Costs for Routing
- SharePoint 2010 PerformancePoint Services : Securing a PerformancePoint Installation - Configure and Start the Claims to Windows Token Service
- SharePoint 2010 PerformancePoint Services : Securing a PerformancePoint Installation - Enable Constrained Delegation for Computers and Service Accounts
- BizTalk 2010 Recipes : Deployment - Enlisting and Starting Orchestrations
- BizTalk 2010 Recipes : Deployment - Enabling Receive Locations
- Exchange Server 2010 : Managing Transport Rules (part 5) - Implementing Moderated Transport
- Exchange Server 2010 : Managing Transport Rules (part 4) - Using Transport Protection Rules
- Exchange Server 2010 : Managing Transport Rules (part 3) - Configuring Disclaimers, Rights Protection & IRM
- Exchange Server 2010 : Managing Transport Rules (part 2) - Managing Transport Rules
- Exchange Server 2010 : Managing Transport Rules (part 1) - Using Transport Rules
 
 
Top 10
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 2) - Wireframes,Legends
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Finding containers and lists in Visio (part 1) - Swimlanes
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Formatting and sizing lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Adding shapes to lists
- Microsoft Visio 2013 : Adding Structure to Your Diagrams - Sizing containers
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 3) - The Other Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 2) - The Data Properties of a Control
- Microsoft Access 2010 : Control Properties and Why to Use Them (part 1) - The Format Properties of a Control
- Microsoft Access 2010 : Form Properties and Why Should You Use Them - Working with the Properties Window
- Microsoft Visio 2013 : Using the Organization Chart Wizard with new data
 
programming4us
Windows Vista
programming4us
Windows 7
programming4us
Windows Azure
programming4us
Windows Server