Chapter 4. Configuring transport services
You can configure your Microsoft Exchange Server 2013 organization with only Mailbox servers for message routing and delivery, or you can configure it with Mailbox servers and Edge Transport servers. When you use only Mailbox servers, these servers are responsible for:
Message routing and delivery within the organization.
Receiving messages from outside the organization and delivering them to Mailbox servers within the organization.
Receiving messages from Mailbox servers within the organization and routing them to destinations outside the organization.
When you use both Mailbox servers and Edge Transport servers, message routing and delivery works like this:
Mailbox servers handle message routing and delivery within the organization.
Edge Transport servers receive messages from outside the organization and route them to Mailbox servers within the organization which, in turn, deliver them to other Mailbox servers if necessary.
Mailbox servers receive messages from Mailbox servers within the organization and route them to Edge Transport servers, which, in turn, route them to destinations outside the organization.
When you use legacy Edge Transport servers in a hybrid deployment, your Edge Transport servers can be configured to handle communications between on-premises Exchange and Exchange Online. Here, the Edge Transport servers act as relays between your internal Exchange servers and Exchange Online, as long as the Edge Transport servers are externally accessible from the Internet on port 25. Additionally, at this time, only Edge Transport servers running Exchange 2010 Service Pack 2 or later support hybrid deployments.
The primary mail protocol used by Exchange Server 2013 is Simple Mail Transfer Protocol (SMTP). This chapter discusses how transport servers use SMTP for routing and delivery, in addition to how you can view and manage transport server configurations.
Real World
Microsoft recommends that you install the Edge Transport server role on a computer that is not part of the internal Active Directory domain. The server can, however, be part of an external Active Directory domain, which isolates the computer and is the most secure implementation. Although you can install the Edge Transport server on a domain-joined computer, the Edge Transport server role will always use Active Directory Lightweight Directory Services (AD LDS) to store recipient and configuration information for the Edge stack, and the underlying Windows stack will use Active Directory Domain Services (AD DS). To send and receive messages from your organization to the Internet, Edge Transport servers use Send connectors and Receive connectors.
Prior to installing the Edge Transport role, you need to set the Domain Name System (DNS) suffix for the server and install the AD LDS role. Generally, you’ll want to use a DNS suffix for your organization’s primary domain. To install the AD LDS role, use the Add Roles Wizard in the Server Manager. Accept the default settings during installation with one exception: you do not need to create an application partition because AD LDS will be configured for the Edge Transport server role when you install the role, and the required application partition will also be created at that time.
Working with SMTP connectors, sites, and links
SMTP connectors, Active Directory sites, and Active Directory links all have important roles to play in determining how Exchange routes and delivers messages in your organization. You can work with connectors, sites, and links in a variety of ways, but first you need to have a strong understanding about how connectors are used.
Connecting source and destination servers
Exchange Server 2013 uses SMTP connectors to represent logically the connection between a source server and a destination server. How you configure an SMTP connector determines how Exchange Server transports messages using that connection. Because each SMTP connector represents a one-way connection, Exchange Server uses both Send and Receive connectors.
A Send connector is a logical gateway through which transport servers send all outgoing messages. When you create a Send connector, it is stored in Active Directory Domain Services or in Active Directory Lightweight Directory Services as a connector object. Send connectors are not scoped to a single server; in fact, multiple servers can use a single Send connector for sending messages. Send connectors deliver mail by looking up a mail exchanger (MX) record on a DNS server, by looking up an Address (A) record, or by using a smart host as a destination. With DNS records, the DNS server settings you configure on the Transport server are used for name resolution. You can configure different settings for internal and external DNS lookups if necessary. See the Configuring Send connector DNS lookups section of this chapter.
A Receive connector is a logical gateway through which all incoming messages are received. When you create a Receive connector, it is stored in AD DS or in AD LDS as a connector object. Unlike Send connectors, Receive connectors are scoped to a single server and determine how that server listens for connections. The permissions on a Receive connector determine from which other servers the connector will accept connections. The authentication mechanisms you configure for a Receive connector determine whether anonymous connections are allowed and the types of authentication that are permitted.
When you install your Mailbox servers, Exchange 2013 creates the connectors required for mail flow within your organization; however, to send mail outside your domain, you must create a Send connector to send mail to the Internet.
If your organization also uses Edge Transport servers, Exchange creates the additional Send and Receive connectors during the Edge Subscription process. You can also explicitly create Send and Receive connectors or automatically compute them from the organization topology by using Active Directory sites and site-link information.
Real World
To enhance security and prevent malicious users from trying to determine internal infrastructure components, Exchange 2013 applies the header firewall feature to remove X-headers and routing headers from inbound and outbound messages automatically. X-headers are user-defined, unofficial headers added to messages during processing, filtering, or virus/spam checking that detail how a message was processed, filtered, or checked. Routing headers are standard SMTP headers that provide information about the various messaging servers used to deliver a message.
The exact headers removed from a message depend on the connector type. Receive connectors with the Internal type remove organization and forest X-headers from messages. Receive connectors with the Custom type remove routing headers (as long as permissions groups are not assigned). Internal or Partner type Send connectors remove organization and forest X-headers from messages. Custom type Send connectors remove routing headers (as long as permissions groups are not assigned).
Managing Active Directory site details
When routing messages, Exchange 2013 determines the ultimate destination for a message and then uses a least-cost method to determine how to route the message. By default, Mailbox servers use Active Directory sites and the costs that are assigned to the Active Directory Internet Protocol (IP) site links to determine the least-cost routing path to other Mailbox servers in the organization. You can also specify an Exchange cost for links.
After a Mailbox server determines the least-cost routing path, the server routes messages over the link or links in this path, and in this way, a source Mailbox server relays messages to target Mailbox servers. By default, when there are multiple Active Directory sites between the source and destination server, the Mailbox servers along the path between the source server and the target server don’t process or relay the messages in any way—with the following exceptions:
If you want messages to be processed en route, you can configure an Active Directory site as a hub site so that Exchange routes messages to the hub site to be processed by the site’s Mailbox servers before being relayed to a target server. The hub site must exist along the least-cost routing path between source and destination Mailbox servers.
If a message cannot be delivered to the target site, the Mailbox server in the closest reachable site along the least-cost routing path of the target site queues the message for relay. The message is then relayed when the destination Mailbox server becomes available.
Sometimes during routing, messages must pass through transport servers in a hub site that isn’t the ultimate destination but is part of the least-cost routing path. All transport servers in a hub site are considered part of the delivery group for that hop and a transport server is randomly selected to handle the message. As a message passes through a hub site, the randomly selected transport server queues and processes the message, routing the message along the least-cost path.
In cases in which a subscribed Edge Transport server is accessible only from the Active Directory site to which it is subscribed, messages must pass through a specific hub site to get to an Edge Transport server to be routed to the Internet or across premises. This happens because a subscribed Edge Transport server is only accessible from the Active Directory site to which it is subscribed.
Each routing destination has a delivery group that handles its message delivery. As discussed in Chapter 1 in the Front-end transport section, an Active Directory site can be a delivery group but so can a routable DAG, a Mailbox delivery group, a group of connector source servers, or a list of expansion servers for dynamic distribution groups. When a DAG is the delivery group, the DAG itself is a routing boundary and the mailbox databases in the DAG are the routing destinations services by the related delivery group. Thus, a message can be sent from a mailbox on any transport server in the DAG to a mailbox on that server or on any other server in the DAG directly. Because site boundaries don’t apply, the member servers can be in different sites as well.
When a site is the delivery group, Exchange 2013 can use delayed fan-out to reduce the number of message transmissions by identifying recipients that share part of the routing path.
When a site isn’t the delivery group, Exchange 2013 selects one site in the destination delivery group with the least-cost routing path as the primary site. If multiple least-cost routing paths are available, the path with the fewest number of hops is chosen. If multiple paths are still available, the site nearest the destination is chosen based on the site name. Specifically, Exchange 2013 selects the site with the lowest alphanumeric sort order. For example, Seattle Site 1 is chosen before Seattle Site 2 and Alpha Site is chosen before Beta Site.
You can use the Get-AdSite cmdlet to display the configuration details of an Active Directory site. If you do not provide an identity with this cmdlet, configuration information for all Active Directory sites is displayed.
Get-AdSite cmdlet syntax and usage provides the syntax and usage, in addition to sample output, for the Get-AdSite cmdlet. Note that the output specifies whether the site is enabled as a hub site.
You can use the Set-AdSite cmdlet to configure an Active Directory site as a hub site to override the default message routing behavior. When a hub site exists along the least-cost routing path between source and destination Mailbox servers, messages are routed to the hub site for processing before they are relayed to the destination server.
Set-AdSite cmdlet syntax and usage provides the syntax and usage for the Set-AdSite cmdlet. To enable a site as a hub site, set the –HubSiteEnabled parameter to $true. To disable a site as a hub site, set the –HubSiteEnabled parameter to $false. You must have Enterprise Administrator rights to use the –Name parameter to change a site’s name.
Managing Active Directory site link details
You can use the Get-AdSiteLink cmdlet to view the configuration information about an Active Directory IP site link. This configuration information includes the value of the Exchange-specific cost, the cost assigned to the Active Directory IP site link, and a list of the sites in the IP site link.
Note
A good resource to learn more about Active Directory sites and site links is Windows Server 2012 Inside Out (Microsoft Press, 2012). See Chapter 27, “Configuring Active Directory Sites and Replication,” and Chapter 32, “Active Directory Site Administration.”
Get-AdSiteLink cmdlet syntax and usage provides the syntax and usage, in addition to sample output, for the Get-AdSiteLink cmdlet. Use the –Identity parameter to retrieve the configuration information about a specific IP site link. If you do not provide an identity, the configuration information about all IP site links is returned.
By default, Exchange Server 2013 determines the least-cost routing path by using the cost that is assigned to the Active Directory IP site links. You can change this behavior by using the Set-AdSiteLink cmdlet to configure an Exchange-specific cost for Active Directory IP site links. After you configure it, the Exchange-specific cost is used to determine the Exchange routing path rather than the Active Directory–assigned cost.
Set-AdSiteLink cmdlet syntax and usage provides the syntax and usage, for the Set-AdSiteLink cmdlet. When there are multiple wide area network (WAN) paths between sites, you can set a higher site-link cost to reduce the likelihood that a link will be used and a lower site-link cost to increase the likelihood that a link will be used. You must have Enterprise Administrator rights to use the –Name parameter to change the name of a site link.
You can use the –MaxMessageSize parameter to set the maximum size for messages that are relayed across a specified link. The default value is “unlimited,” which allows messages of any size to be relayed. You can specify the units for values by using B for bytes, KB for kilobytes, MB for megabytes, or GB for gigabytes. The valid range for maximum size is from 64 KB to the largest value in bytes that can be set using a 64-bit integer (9,223,372,036,854,775,807).
Creating Send connectors
Send connectors are the gateways through which transport servers send messages, and only transport servers have Send connectors. Exchange automatically creates the Send connectors required for internal mail flow but does not create the Send connectors required for mail flow to the Internet. Send connectors are stored in Active Directory and are available to all transport servers in the Exchange organization by default.
As an administrator, you can explicitly create Send connectors for Internet mail flow and other necessary connectors, and then manage the configuration of these explicitly created Send connectors as needed. You cannot, however, manage the configuration of Send connectors created implicitly by Exchange to enable mail flow. The key reasons for creating Send connectors are to:
Control explicitly how message routing works within domains or between domains.
Control explicitly the hosts used as destinations or the way messages are routed over the Internet.
Send mail to systems that are not Exchange servers.
When you create Send connectors, you can encrypt message traffic sent over the link and require strict authentication. You can transmit messages to a designated internal server—called as smart host—or you can use DNS records to route messages. If you use a smart host, Exchange Server 2013 transfers messages directly to the smart host, which then sends out messages over an established link. The smart host allows you to route messages on a per-domain basis. If you use DNS records, Exchange Server 2013 performs a DNS lookup for each address to which the connector sends mail.
As part of the new architecture in Exchange 2013, Mailbox servers run the Transport service, and Client Access servers run the Front End Transport service. The Transport service is responsible for all mail flow, and the Front End Transport service acts as a stateless proxy for all external SMTP traffic. The Transport service on a Mailbox server can use a Send connector to route outbound messages through the Front End Transport service on a Client Access server in the local Active Directory site. In a large messaging environment, you may want to route messages in this way to simplify and consolidate mail flow.
If the Mailbox Server role and the Client Access Server role are located on the same server, mail routing occurs internally; otherwise, a Client Access server in the same site as the Mailbox server is selected. When an Active Directory site has subscribed Edge Transport servers, outbound mail is passed directly from a Mailbox server to an Edge Transport server, bypassing the Client Access servers in the site.
When you create a Send connector, you must define the address space, which determines when the Send connector is used as well as the domain names to which the connector sends messages. For example, if you want to connect two domains in the same Exchange organization—dev.cpandl.com and corp.cpandl.com—you can create a Send connector in dev.cpandl.com, and then add an SMTP address type for the email domain corp.cpandl.com.
Important
In previous versions of Exchange, you could link a Send connector to a specific Receive connector to control mail flow and routing; however, this option is deprecated in Exchange 2013 and Microsoft recommends that you don’t use this option as it will be removed in a future update or release of Exchange Server.
Send connectors can be used by multiple transport servers. When you create a Send connector within an Exchange organization, you can specify the Mailbox servers that are permitted to use the Send connector. When you create a Send connector on an Edge Transport server, the connector is configured only for that server.
Typically, the first Send connector you’ll create in an Exchange organization is one that enables mail flow to the Internet. To create a Send connector for Internet mail flow, follow these steps:
In Exchange Admin Center, select Mail Flow in the Feature pane and then select Send Connectors.
Tap or click New. This starts the New Send Connector Wizard, shown in Figure 4-1.
In the Name text box, type a descriptive name for the connector, such as Primary Internet Send Connector, and then set the connector type as Internet.
On the Network Settings page, confirm that MX Record Associated With Recipient Domain is selected, and then tap or click Next.
On the Address Space page, tap or click Add. In the Add Domain dialog box, SMTP is set as the address space type. In the Fully Qualified Domain Name box, enter * to specify that you are creating the connector for routing outbound mail to all external domains. By default, the address space cost is set to 1, which assigns the highest preference to the connector. If you plan to create other Send connectors, you may want to assign a higher cost to ensure mail is routed appropriately. For example, if you set the cost to 100 and the cost of other Send connectors to a value less than 100, this connector will be used only when no other connector would otherwise apply. Tap or click Save to close the Add Domain dialog box. Tap or click Next.
On the Source Server page, tap or click Add to associate the connector with the Mailbox server or servers that will be used to send mail to the Internet. In the Select A Server dialog box, select a Mailbox server that will be used as the source server, and then tap or click Add. Repeat as necessary to add more Transport servers. If you make a mistake, tap or click the Remove link next to the server name.
When you are finished selecting servers, tap or click OK to close the Select A Server dialog box, and then tap or click Finish to create the connector. You can verify that the connector is configured properly by sending mail to an external recipient and confirming that the message arrives.
By default, the new Send connector is enabled and configured to allow a maximum message size of 35 MB. To change the default maximum message size, open the related properties dialog box by double-tapping or double-clicking the connector’s entry in Exchange Admin Center. Next, enter the desired Maximum Send Message Size in the combo box provided and then tap or click Save. Valid maximum send message sizes range from 1 to 2096128 MB. If you don’t want the connector to have a specific limit, set the maximum size to 0.
To create other Send connectors, complete the following steps:
In Exchange Admin Center, select Mail Flow in the Feature pane, and then select Send Connectors.
Tap or click New to start the New Send Connector Wizard, shown in Figure 4-2.
In the Name text box, type a descriptive name for the connector, and then set the connector type. The available options are as follows:
Custom. Creates a customized Send connector for connecting with systems that are not Exchange servers.
Internal. Creates a Send connector for sending mail to another transport server in the organization, and sets the default permissions so that the connector can be used by Exchange servers. This connector will be configured to route mail by using smart hosts.
Internet. Creates a Send connector that sends mail to external users over the Internet. This connector will be configured to use DNS records to route mail.
Partner. Creates a Send connector that sends mail to partner domains. Partner domains cannot be configured as smart hosts. Only connections that authenticate with Transport Layer Security (TLS) certificates are allowed by default. Partner domains must also be listed on the TLS Send Domain Secure list, which can be set by using the –TLSSendDomainSecureList parameter of the Set-TransportConfig command.
On the Network Settings page, shown in Figure 4-3, select how you want to send email with the Send connector. If you select MX Record Associated With Recipient Domain, the Send connector uses the DNS client service on the Transport server to query a DNS server and resolve the destination address. Skip steps 5–8 if you select the MX Record option.
If you select Route Mail Through Smart Host, you have to specify the smart hosts to which mail should be forwarded for processing. Tap or click Add.
In the Add Smart Host dialog box, enter the IP address or the Fully Qualified Domain Name (FQDN) of the smart host. The Transport server must be able to resolve the FQDN.
Tap or click Save to close the Add Smart Host dialog box. Repeat steps 5–7 as necessary to add more smart hosts to this connector. If you make a mistake, select the smart host, and then tap or click Edit or Remove as appropriate. When you are finished, tap or click Next to continue.
Optionally, specify that you want the connector to use the external DNS lookup settings of the Mailbox server.
After you’ve configured smart hosts, you’ll see the Configure Smart Host Authentication Settings page. On this page, select the method that you want to use to authenticate your servers to the smart host.
Choose one of the following options, and then tap or click Next:
None. No authentication. Use this option only if the smart host is configured to accept anonymous connections.
Basic Authentication. Standard authentication with wide compatibility. With basic authentication, the user name and password specified are passed as cleartext to the remote domain.
Offer Basic Authentication Only After Starting TLS. When you use Basic Authentication, you can select this check box to enable basic authentication over TLS. In this case, TLS authentication is combined with basic authentication to allow encrypted authentication for servers with smart cards or X.509 certificates.
Exchange Server Authentication. Secure authentication for Exchange servers. With Exchange Server authentication, credentials are passed securely.
Externally Secured. Secure authentication for Exchange servers. With externally secured authentication, credentials are passed securely using an external security protocol for which the server has been separately configured, such as Internet Protocol security (IPSec).
Tap or click Next. On the Address Space page, shown in Figure 4-4, tap or click Add. In the Add Domain dialog box, you can use the following options to specify the domain names to which this connector will send mail:
Type. SMTP is the default address space type. Use this type for connectors routing mail to Exchange server and other SMTP servers. For routing mail directly to non-SMTP servers, specify the address space type of the server, such as X400, X500, or MSMAIL.
Fully Qualified Domain Name. The domain or domains to which this connector will send mail, such as adatum.com. With SMTP addresses, you can enter the wildcard character (*) directly in the address space as defined in RFC 1035. For example, you can enter * for all domains, *.com for all .com domains, or *.adatum.com for the adatum.com domain and all subdomains of adatum.com. With X.400 addresses, you must specify the address space as defined in RFC 1685.
Cost. The address space cost is used for relative weighting. Valid address space costs range from 1, which assigns the highest possible preference, to 100, which assigns the lowest possible preference. When you create a Send connector, the default address space cost is 1. If you set all address spaces to this cost, all address spaces have equal preference for routing mail.
Tap or click Save to close the SMTP Address Space dialog box. Repeat as necessary to add more address spaces to this connector. If you make a mistake, select the address space and then tap or click Edit or Remove as appropriate.
If you’d like to scope the Send connector to the current site, select the Scoped Send Connector check box. When a Send connector is scoped, only Mailbox servers in the same Active Directory site as the Send connector’s source servers consider that Send connector in routing decisions. Tap or click Next to continue.
Next, you see the Source Server page. Tap or click Add to associate the connector with Mailbox servers and Edge subscriptions. In the Select A Server dialog box, select a Mailbox server or an Edge subscription that will be used as the source server for sending messages to the address space that you previously specified, and then tap or click Add. Repeat as necessary to add more Transport servers. If you make a mistake, tap or click the Remove link next to the server name.
When you are finished, tap or click OK to close the Select A Server dialog box, and then tap or click Finish to create the connector. You can verify that the connector is configured properly by sending mail to an external recipient in a domain associated with the connector and confirming that the message arrives.
By default, the new Send connector is enabled and configured to allow a maximum message size of 35 MB. To change the default maximum message size, open the related properties dialog box by double-tapping or double-clicking the connector’s entry in Exchange Admin Center. Next, enter the desired Maximum Send Message Size in the combo box provided, and then tap or click Save. Valid maximum send message sizes range from 1 to 2048 MB. If you don’t want the connector to have a specific limit, set the maximum size to 0 or select Unlimited in the dropdown list.
When you create a Send connector, you can also enable front-end proxying. If you want to enable front-end proxying and route outbound messages through the Client Access servers in the local Active Directory site, open the related properties dialog box by double-tapping or double-clicking the connector’s entry in Exchange Admin Center. Next, select the Proxy Through Client Access Server check box, and then tap or click Save.
In the Exchange Management Shell, you can create Send connectors by using the New-SendConnector cmdlet. The –Usage parameter sets the Send connector type as Custom, Internal, Internet, or Legacy. The –AddressSpaces parameter sets the address spaces for the Send connector by FQDN or IP address. The –DNSRoutingEnabled parameter determines whether DNS records or smart hosts are used for lookups. To use DNS records, set DNSRoutingEnabled to $true. To use smart hosts, set –DNSRoutingEnabled to $false, and then use the –SmartHosts parameter to designate the smart hosts. To enable front-end proxying, set –FrontEndProxyEnabled to $true.
New-SendConnector cmdlet syntax and usage provides the syntax and usage for the New-SendConnector cmdlet. With basic authentication or basic authentication over TLS, you will be prompted to provide credentials. To scope the Send connector to the current Active Directory site, set the –IsScopedConnector parameter to $true.
Viewing and managing Send connectors
The Exchange Management tools provide access only to the Send connectors you’ve explicitly created. On Mailbox servers, Send connectors created by Exchange Server are not displayed or configurable. On Edge Transport servers, you can view and manage the internal Send connector used to connect to the Mailbox servers in your Exchange organization, as shown in Figure 4-5.
In Exchange Admin Center, you can view the Send connectors and manage their configuration. When you select Mail Flow in the Feature pane and then select Send Connectors, Send connectors you’ve created are listed by name and status. You can now do the following:
Change a connector’s properties. To change a connector’s properties, double-tap or double-click the connector entry, and then use the Properties dialog box to manage the connector’s properties. You’ll also be able to specify the maximum message size and protocol logging level. By default, the maximum message size is set to 35 MB and the protocol logging level is set to None.
Enable a connector. To enable a connector, select it, and then select Enable in the details pane.
Disable a connector. To disable a connector, select it, and then select Disable in the details pane.
Remove a connector. To remove a connector, select it, and then select Remove.
In the Exchange Management Shell, you can view, update, or remove Send connectors by using the Get-SendConnector, Set-SendConnector, or Remove-SendConnector cmdlets, respectively. Get-SendConnector cmdlet syntax and usage Set-SendConnector cmdlet syntax and usage Remove-SendConnector cmdlet syntax and usage provide the syntax and usage. With Get-SendConnector, if you don’t specify an identity, the cmdlet returns a list of all administrator-configured Send connectors.
Configuring Send connector DNS lookups
You can configure different settings for internal and external DNS lookups by configuring a Transport server’s External DNS Lookups and Internal DNS Lookups properties. External DNS Lookup servers are used to resolve the IP addresses of servers outside your organization. Internal DNS Lookup servers are used to resolve IP addresses of servers inside the organization.
In Exchange Admin Center, you can specify enable or disable external DNS lookups for each Send connector by selecting Mail Flow in the Feature pane, and then selecting Send Connectors. Next, double-tap or double-click the Send connector you want to configure. In the properties dialog box, select Delivery to display the Delivery options. The Use The External DNS Lookup… check box controls whether external DNS lookups are permitted. To allow external DNS lookups when the selected connector is used, select this check box, and then tap or click Save.
If you’ve enabled external DNS lookups for Send connectors, you can specify how external lookups should be performed for each Mailbox server in the organization. You also can configure internal DNS lookups for each Mailbox server in the organization. To configure DNS Lookup servers, complete these steps:
In Exchange Admin Center, select Servers in the Feature pane, and then select Servers. Next, double-tap or double-click the server you want to manage.
In the properties dialog box, select DNS Lookups to display DNS lookup options.
On the External DNS Lookups panel, shown in Figure 4-6, specify how external lookups should be performed:
To use DNS settings from the server’s network card or cards for external lookups, choose either All Network Adapters (All Available IPv4) to use all configured IPv4 settings or a specific network card to use the configured IPv4 settings of that card.
To use a custom list of DNS servers for external lookups, select Custom Settings. Next, tap or click Add. In the Add IP Address dialog box, type the IPv4 or IPv6 address of a DNS server to use for external lookups, and then tap or click Save. Repeat this process to specify multiple servers. Keep in mind that Mailbox servers perform lookups in the order the DNS servers are listed.
On the Internal DNS Lookups panel, specify how internal lookups should be performed:
To use DNS settings from the server’s network card or cards for internal lookups, choose either All Network Adapters (All Available IPv4) to use all configured IPv4 settings or a specific network card to use the configured IPv4 settings of that card.
To use a custom list of DNS servers for internal lookups, select Custom Settings. Next, tap or click Add. In the Add IP Address dialog box, type the IPv4 or IPv6 address of a DNS server to use for internal lookups, and then tap or click Save. Repeat this process to specify multiple servers.
Tap or click Save to apply your settings.
Setting Send connector limits
Send connector limits determine how mail is delivered after a connection has been established and the receiving computer has acknowledged that it’s ready to receive the data transfer. After a connection has been established and the receiving computer has acknowledged that it’s ready to receive the data transfer, Exchange Server attempts to deliver messages queued for delivery to the computer. If a message can’t be delivered on the first attempt, Exchange Server tries to send the message again after a specified time. Exchange Server keeps trying to send the message at the intervals you’ve specified until the expiration time-out is reached. When the time limit is reached, the message is returned to the sender with a non-delivery report (NDR). The default expiration time-out is two days.
After multiple failed attempts to deliver a message, Exchange Server generates a delay notification and queues it for delivery to the sender of the message. Notification doesn’t occur immediately after failure; instead, Exchange Server sends the delay notification message after the notification delay interval and then only if the message hasn’t already been delivered. The default delay notification is four hours.
With SMTP, you have much more control over outgoing connections than you do over incoming connections. You can limit the number of simultaneous connections and the number of connections per domain. These limits set the maximum number of simultaneous outbound connections. By default, the maximum number of connections is 1,000 and the maximum number of connections per domain is 20.
You can view or change the Send connector limits by completing the following steps:
In Exchange Admin Center, select Servers in the Feature pane, and then select Servers. Next, double-tap or double-click the server you want to manage.
On the Transport Limits page, shown in Figure 4-7, use the following options for retrying unsuccessful outbound connections:
Outbound Connection Failure Retry Interval (Seconds). Sets the retry interval for subsequent connection attempts to a remote server where previous connections have failed. The default is 600 seconds.
Transient Failure Retry Interval (Minutes). Sets the interval at which the server immediately retries when it encounters a connection failure with a remote server. The default is five minutes.
Transient Failure Retry Attempts. Sets the maximum number of times that the server immediately retries when it encounters a connection failure with a remote server. The default is six. If you enter 0 as the number of retry attempts or the maximum number of attempts has been reached, the server no longer immediately retries a connection and instead waits according to the outbound connection failure retry interval.
When messages that cannot be delivered reach the Maximum Time Since Submission value, they expire, and Exchange Server generates a Non-delivery report. To set the expiration time-out for messages, enter the desired message expiration value in the Maximum Time Since Submission (Days) text box. The default expiration time-out for messages is two days.
When messages are delayed longer than the allowed delay interval, Exchange Server sends a delay notification to the sender. To set the amount of time to wait before notifying senders of a delay, enter the desired wait time in the Notify Sender When Message Is Delayed After (Hours) text box. The default wait time is four hours.
To set an outgoing connection limit, select the Maximum Concurrent Outbound Connections check box, and then type the limit value. The default limit is 1,000 outbound connections. To remove outgoing connection limits, set the value to 0 or select Unlimited in the drop-down list.
To set an outgoing connection limit per domain, select the Maximum Concurrent Outbound Connections Per Domain check box, and then type the limit value. The default limit is 20 outbound connections per domain. To remove the outgoing connection limit per domain, set the value to 0 or select Unlimited in the drop-down list.
Tap or click Save to apply your settings.
Creating Receive connectors
Receive connectors are the gateways through which Transport servers receive messages. Exchange creates the Receive connectors required for mail flow automatically. The receive permissions on a Receive connector determine who is allowed to send mail through the connector.
Two Receive connectors are created on Mailbox servers, and three Receive connectors are created on Client Access servers. On Mailbox servers, the Default connector accepts connections from Mailbox servers running the Transport service and from Edge Transport servers, and the Client Proxy connector accepts connections from Client Access servers. On Client Access servers, the Default front-end connector accepts connections from SMTP senders over port 25, the Client front-end connector accepts secure connections over TLS and the Outbound Proxy front-end connector accepts connections from Mailbox servers when front-end proxying is enabled. As these default Receive connectors are created, you generally don’t need to create Receive connectors to receive mail from the Internet.
That said, as an administrator, you can explicitly create Receive connectors, and then manage the configuration of those Receive connectors as necessary. You cannot, however, manage the configuration of connectors created implicitly by Exchange to enable mail flow. The key reasons for creating SMTP connectors are when you want to:
Unlike Send connectors, Receive connectors are used by only a single, designated Transport server. When you create a Receive connector within an Exchange organization, you can select the Mailbox or Edge Transport server with which the connector should be associated and configure the specific binding for that connector. A binding is a combination of local IP addresses, ports, and remote IP address ranges for the Receive connector. You cannot create a Receive connector that duplicates the bindings of existing Receive connectors. Each Receive connector must have a unique binding.
Note
Exchange Server 2013 uses standard SMTP or Extended SMTP (ESMTP) to deliver mail. Because the ESMTP standard is more efficient and allows for extensions, SMTP connectors always try to initiate ESMTP sessions before trying to initiate standard SMTP sessions. SMTP connectors initiate ESMTP sessions with other mail servers by issuing an EHLO start command. SMTP connectors initiate SMTP sessions with other mail servers by issuing the HELO start command.
SMTP was originally defined in RFC 821, and ESMTP was originally defined in RFC 1869. With SMTP, the MAIL FROM and RCPT TO fields are limited to a maximum of 512 characters. With ESMTP, these fields can have more than 512 characters. Additionally, EHLO replies can include a status code, domain, and a list of keywords that indicate supported extensions.
Because the ESMTP standard is more efficient and allows for extensions, SMTP connectors always try to initiate ESMTP sessions before trying to initiate standard SMTP sessions. SMTP connectors initiate ESMTP sessions with other mail servers by issuing an EHLO start command. SMTP connectors initiate SMTP sessions with other mail servers by issuing the HELO start command.
To create a Receive connector, complete the following steps:
In Exchange Admin Center, select Mail Flow in the Feature pane, and then select Receive Connectors.
On the Receive Connectors page, select the server on which you want to create the Receive connector. Generally, when you want to control mail flow from external sources, you configure the Receive connector on a Front End Transport server rather than a back-end transport server. Thus, you normally would:
Configure a Receive connector for receiving messages from the Internet or an external partner on a Client Access server.
Configure a Receive connector for receiving messages from an internal messaging appliance or an internal Exchange server on a Mailbox server.
Start the New Receive Connector Wizard, shown in Figure 4-8, by tapping or clicking New. In the Name text box, type a descriptive name for the connector, and then specify the connector role. Select Hub Transport for a Receive connector that you want to associate with the Transport service on a Mailbox server. Or select Frontend Transport for a Receive connector that you want to associate with the Front End Transport service on a Client Access server.
Set the connector type. The available options are as follows:
Custom. Creates a Receive connector bound to a specific port or IP address on a server with multiple receive ports or IP addresses. It can also be used to specify a remote IP address from which the connector receives messages. Generally, a custom Receive connector is used to connect with systems that are not Exchange servers. You also can use custom Receive connectors to receive mail from a Mailbox server in another forest or from an SMTP transfer agent.
Internal. Creates a Receive connector to receive messages from another Transport server in the organization, such as may be necessary for communication between Mailbox servers or between Mailbox servers and third-party transfer agents. For Edge Transport servers, the Internal connector type sets the default permissions so that the connector can be used by Exchange servers. For Mailbox servers, it sets the default permissions so that the connector is configured to accept connections from Exchange servers.
Internet. Creates a Receive connector that accepts incoming connections from the Internet. This connector accepts connections from anonymous users.
Client. Creates a Receive connector used to receive mail from Exchange users. Only connections from authenticated Microsoft Exchange users are accepted by default. Typically used to connect clients not using Microsoft Office Outlook.
Partner. Creates a Receive connector used to receive mail from partner domains. Partner domains cannot be configured as smart hosts. Only connections that authenticate with Transport Layer Security (TLS) are allowed by default. Partner domains must also be listed on the TLS Receive Domain Secure list, which can be set by using the –TLSReceiveDomainSecureList parameter of the Set-TransportConfig command.
Tap or click Next. For Custom, Partner, and Internet Receive connectors, you can specify the local IPv4 and IPv6 addresses and the port on which mail can be received, as shown in Figure 4-9. By default, Custom and Internet Receive connectors are configured to receive mail over port 25 on all available IPv4 addresses configured for the server. Port 25 is the default TCP port for SMTP. To use a different configuration, select the default entry on the Local Network Settings page, and then tap or click Remove. You can now create new entries by tapping or clicking Add. In the Add IP Address dialog box, select All Available IPv4 Addresses to have the connector listen for connections on all the IPv4 addresses that are assigned to the network adapters on the local server. Alternatively, you can select all available IPv6 addresses or you can select Specify An IPv4 Address Or an IPv6 Address if you want to type an IP address that is assigned to a network adapter on the local server and have the connector listen for connections only on this IP address. As necessary, modify the listen port value. Tap or click Save.
On the Remote Network Settings page, shown in Figure 4-10, you can specify the remote IP addresses from which the server can receive mail. By default, Receive connectors are configured to accept mail from all remote IP addresses, which is why the IP address range 0.0.0.0–255.255.255.255 is set as the default entry. You’ll only want to change this behavior if you want to limit the servers that are permitted to send mail to the Transport server. To use a different configuration, select the default entry on the Remote Network Settings page, and then tap or click Remove. To specify the remote servers, tap or click Add. Next, in the Add IP Address dialog box, enter an IP address, an IP address range, or an IP address range in Classless Internet Domain Routing (CIDR) notation. Repeat this process as necessary to specify other acceptable IP addresses. Tap or click Save.
When you’re finished, tap or click Finish to create the connector. You can verify that the connector is configured properly by confirming that messages arrive from a sending server to which the connector applies.
By default, the new Receive connector is enabled and configured to allow a maximum message size of 35 MB. To change the default maximum message size, open the related properties dialog box by double-tapping or double-clicking the connector’s entry in Exchange Admin Center. Next, enter the desired Maximum Receive Message Size in the combo box provided, and then tap or click Save. Valid maximum receive message sizes range from 1 to 2047 MB--and you can’t specify that there is no limit.
When you create a Receive connector, you can also specify the maximum hops that a message can take before it’s rejected by the Receive connector. By default, a message can have a maximum of 12 local hops and a maximum of 60 hops in total. If you want to change the default maximum hop counts, open the related properties dialog box by double-tapping or double-clicking the connector’s entry in Exchange Admin Center. After you set the maximum number of local hops and the maximum number of hops in total, tap or click Save. The valid range for local hops is 1 to 50 and the valid range for hops in total is 1 to 500. If you don’t want the connector to have a specific limit for local hops, set the maximum local hops to 0. You can’t set the maximum hops in total to unlimited.
In the Exchange Management Shell, you can create Receive connectors by using the New-ReceiveConnector cmdlet. The –Usage parameter sets the Receive connector type as Client, Custom, Internal, Internet, or Partner. The –Bindings parameter sets the internal IP addresses and ports on which to listen. The –FQDN parameter sets the FQDN to advertise in response to HELO or EHLO messages. The –RemoteIPRanges parameter provides a comma-separated list of acceptable IP address ranges. The –Server parameter specifies the server on which to create the Receive connector.
As New-ReceiveConnector cmdlet syntax and usage shows, the required parameters for the New-ReceiveConnector cmdlet depend on the type of Receive connector you are creating. After you provide the required parameters, the remaining parameters can be used in the same way regardless of which type of Receive connector you are creating. You use –AuthMechanism to specify the authentication type. With Basic Authentication or Basic Authentication Over TLS, you will be prompted to provide credentials. If a server hosts both the Mailbox Server role and Client Access Server role, use -TransportRole to specify the role with which the Receive connector should be associated.
Viewing and managing Receive connectors
To view all available Receive connectors for a server, select Mail Flow in the Feature pane, and then select Receive Connectors. Next, on the Receive Connectors page, select the server you want to work with. Receive connectors are listed by name, status, and role, as shown in Figure 4-11.
Change a connector’s properties. To change a connector’s properties, double-tap or double-click the connector entry, and then use the Properties dialog box to manage the connector’s properties.
Enable a connector. To enable a connector, select it, and then select Enable in the details pane.
Disable a connector. To disable a connector, select it, and then select Disable in the details pane.
Remove a connector. To remove a connector, select it, and then select Remove.
When configuring Receive connector properties, you can specify the security mechanisms that can be used for incoming connections on the Security page. Use any combination of the following:
Transport Layer Security. Allows encrypted authentications with TLS for servers with smart cards or X.509 certificates.
Enable Domain Security (Mutual Auth TLS). When TLS is enabled, you can also enable domain security to require mutual authentication.
Basic Authentication. Allows basic authentication. With basic authentication, the user name and password specified are passed as base64-encoded text to the remote domain. Base64-encoding is cleartext and should not be confused with encryption.
Offer Basic Authentication Only After Starting TLS. Allows basic authentication only within an encrypted TLS session.
Integrated Windows Authentication. Allows secure authentication by using NT LAN Manager (NTLM) or Kerberos.
Exchange Server Authentication. Allows secure authentication for Exchange servers. With Exchange Server authentication, credentials are passed securely.
Externally Secured. Allows secure external authentication. With externally secured authentication, credentials are passed securely by using an external security protocol for which the server has been separately configured, such as IPsec.
Also when configuring Receive connector properties, you can specify the security group that is allowed to connect on the Permission Groups panel of the Security page. Use any combination of the following:
Anonymous Users. Allows unauthenticated, anonymous users to connect to the Receive connector.
Exchange Users. Allows connections by authenticated users who are valid recipients in the organization (Mailbox servers only).
Exchange Servers. Allows connections by authenticated servers that are members of the Exchange Server Administrator group.
Legacy Exchange Servers. Allows connections by authenticated servers that are members of the ExchangeLegacyInterop group (Mailbox servers only).
Partners. Allows connections by authenticated servers that are members of partner domains, as listed on the TLS Receive Domain Secure list.
In the Exchange Management Shell, you can view, update, or remove Receive connectors by using the Get-ReceiveConnector, Set-ReceiveConnector, or Remove-ReceiveConnector cmdlets, respectively. Get-ReceiveConnector cmdlet syntax and usage Set-ReceiveConnector cmdlet syntax and usage Remove-ReceiveConnector cmdlet syntax and usage provide the syntax and usage. With Get-ReceiveConnector, you can return a list of all available Receive connectors if you don’t specify an identity or server. If you want to see only the Receive connectors configured on a particular server, use the –Server parameter.
Creating Inbound and Outbound connectors with Exchange Online
Exchange Online uses Inbound and Outbound connectors, rather than Receive and Send connectors. Inbound connectors control mail flowing from the Internet, a partner, or a specific server. Outbound connectors control the flow of mail sent by recipients in the organization. When mailbox users in the online organization are sending mail, you can use Outbound connectors to direct messages to a server that applies additional processing before delivering the mail to its destination.
When you run the Hybrid Configuration Wizard to create a hybrid organization that combines an on-premises Exchange organization with an online Exchange organization, a Send connector is created automatically in the on-premises Exchange organization to route mail to Exchange Online and a Receive connector is created automatically to receive mail from Exchange Online. Similarly, an Outbound connector is created automatically in the online Exchange organization to route mail to on-premises Exchange, and an Inbound connector is created automatically to receive mail from on-premises Exchange.
The automatically created Inbound and Outbound connectors have the connector type set as On-Premises. To view and manage inbound or outbound connectors, access Exchange Admin Center for Exchange Online. Next, select Mail Flow in the Feature pane, and then select Connectors, as shown in Figure 4-12.
You can create additional Inbound and Outbound connectors to control mail flow from and to trusted partners. These additional connectors have the connector type set as Partner, rather than On-Premises. By default, connectors use opportunistic TLS for connection security. This means connectors try to use TLS security for connections but if TLS cannot be used, they establish a standard SMTP connection instead.
To create Inbound or Outbound connectors, you have several options. If you are working with Exchange Admin Center, you can tap or click the Add option under Inbound Connectors to open the New Inbound Connector dialog box, or you can tap or click the Add option under Outbound Connectors to open the New Outbound Connector dialog box. Next, use the options provided to configure the connectors much as you would configure Send and Receive connectors.
You also can connect to Exchange Online in Windows PowerShell and then use the New-InboundConnector or New-OutboundConnector cmdlet to create a connector. Each connector type has corresponding Set, Get, and Remove cmdlets as well. These are Set-InboundConnector, Get-InboundConnector, and Remove-InboundConnector in addition to Set-OutboundConnector, Get-OutboundConnector, and Remove-OutboundConnector.
Configuring transport limits
Exchange Server 2013 automatically places receive size, send size, and other limits on messages being routed through an Exchange organization. The limits you can control include:
Message header limits control the total size of all message header fields in a message. Header limits primarily apply to Receive connectors, although they also apply to messages in the pickup directory used by the Transport service. Header fields are plain text, and so the size of the header is determined by the total number of header fields and characters in each header field. Each character of text is 1 byte.
Message receive size limits control the total size of messages that can be received, which includes the message header, message body, and any attachments. Exchange uses a custom message header (X-MS-Exchange-Organization-OriginalSize:) to record the original size of a message when it enters the Exchange organization. Although content conversion, encoding, and agent processing can change the size of the message, Exchange uses the lower value of the current or original message size to determine whether the limit applies.
Message send size limits control the total size of messages that can be sent, which includes the message header, message body, and any attachments.
Attachment size limits control the maximum size of each individual attachment within a message.
Recipient limits control the total number of message recipients, with an unexpanded distribution group counted as a single recipient. When a message is composed, recipients are listed in the To:, Cc:, and Bcc: header fields. When a message is submitted for delivery, these recipients are converted into Rcpt To: entries in the message.
Note
Unlike other limits, exceeding a recipient limit doesn’t automatically mean a message will be rejected. The message may be accepted for the first N recipients and then resent by the SMTP server in groups of N recipients until the message is delivered to all recipients.
A message that exceeds any applicable limit is rejected and a non-delivery report is issued to the sender with an error code, status, and description. Transport limits are configured for the organization as a whole, for individual send and receive connectors, for specific servers, for specific users, and for specific Active Directory site links.
As part of your planning for message size limits, you need to consider that base64 encoding will be applied to attachments and any binary data in messages. Base64 encoding increases the size of the attachments and the binary data by approximately 33 percent and in this way increases the total size of a message. Thus, attachments with a total original size of 27 MB could cause a message to exceed a send or receive limit of 35 MB.
Setting organizational transport limits
Organizational transport limits apply to all transport servers in the organization, which includes Exchange 2013 Mailbox servers, Exchange 2010 Hub Transport servers and Exchange 2007 Hub Transport servers. By default, the maximum message size that can be received or sent by recipients in the organization is 10,240 KB and messages can have no more than 500 recipients.
You can view or change the default limits for the Exchange organization by completing the following steps:
In the Exchange Admin Center, select Mail Flow in the Feature pane, and then select either Receive Connectors or Send Connectors.
In the main pane, select the More button (which has 3 dots for an icon), and then tap or click Organization Transport Settings. In the Organization Transport Settings dialog box, the Limits page is selected by default, as shown in Figure 4-13.
To set a maximum number of recipients limit, type the desired limit in the Maximum Number Of Recipients combo box. The valid input range is 0 to 2,147,483,647. If you use a value of 0, no limit is imposed on the number of recipients in a message. Note that Exchange handles an unexpanded distribution group as one recipient.
To set a maximum receive size limit, type the desired receive limit in the related combo box. The valid input range is 0 to 2047.999 MB. If you use a value of 0 or select Unlimited in the dropdown list, no limit is imposed on the message size that can be received by recipients in the organization.
To set a maximum send size limit, type the desired send limit in the related combo box. The valid input range is 0 to 2047.999 MB. If you use a value of 0 or select Unlimited in the dropdown list, no limit is imposed on the message size that can be sent by senders in the organization.
Tap or click Save to apply your settings.
In the Exchange Management Shell, you assign the desired transport limits by using the Set-TransportConfig cmdlet, as shown in Setting transport limits. The –MaxReceiveSize and –MaxSendSize parameters set the maximum receive size and maximum send size, respectively. The -MaxRecipientEnvelopeLimit parameter sets the maximum number of recipients in a message. When you use the –MaxReceiveSize and –MaxSendSize parameters, you must specify the units for values by using KB for kilobytes, MB for megabytes, or GB for gigabytes. Your changes are made at the organization level and apply to the entire Exchange Server 2013 organization.
You can control the maximum message size and maximum attachment size for all Mailbox servers in the organization by using transport rules. To do this, use the -MessageSizeOver and -AttachmentSizeOver parameters of New-TransportRule or Set-TransportRule.
Setting connector transport limits
The transport limits of a connector apply to any message that uses a specified connector for message delivery. Exchange 2013 automatically sets transport limits on Send and Receive connectors. Most connectors have a maximum message size limit of 35 MB by default. The exceptions are the Default Frontend and Outbound Proxy Frontend Receive connectors, which have a 36 MB limit by default.
You can view the current maximum message size limits for all send connectors by entering the following command in Exchange Management Shell:
get-sendconnector | fl name, maxmessagesize
To view the current maximum size of all receive connectors, enter:
get-receiveconnector | fl name, maxmessagesize
You can modify the default maximum message size limit by using the -MaxMessageSize parameter of the New-ReceiveConnector, Set-ReceiveConnector, New-SendConnector, and Set-SendConnector cmdlets.
Receive connectors also have default limits on the maximum number of recipients and the maximum header size. Most of the default Receive connectors have a limit of 200 recipients by default. The exception is the Default Receive connector which has a limit of 5,000 recipients by default.
The default Receive connectors and any other Receive connectors you create automatically have a 128 KB maximum header size limit. Although Exchange adds headers to messages during content conversion, encoding, and agent processing, the number of recipients in a message is the most common reason a message exceeds the maximum header size limit. Each character in a recipient’s name and email address counts against the limit. If a message is rejected because it exceeds the maximum header size limit, the sender should receive a non-delivery report. This non-delivery report may contain an error status code of 4.4.7, which can help you identify the problem as relating to the maximum header size limit.
In the shell, you can view the current recipient and header size limits for all receive connectors by entering:
get-receiveconnector |fl name, maxheadersize, maxrecipientspermessage
You can modify the recipient and header limits by using the -MaxRecipientsPerMessage and -MaxHeaderSize parameters of the New-ReceiveConnector and Set-ReceiveConnector cmdlets.
Setting server transport limits
The transport limits of a server apply to any message processed by the server. If a user’s mailbox is on a particular Mailbox server, the maximum header size and maximum number of recipient limits for the pickup directory apply. You can configure these limits on a per-server basis as discussed in Chapter 5 in the Configuring messaging limits for the Pickup directory section.
Per-server transport limits also apply to Client Access servers. The maximum message size for Outlook Web App is 33 MB. Exchange ActiveSync and Exchange Web Services have maximum message size limits of 10 MB and 64 MB respectively. To change these values, you must edit the appropriate web.config configuration file on each Client Access server. The configuration files are formatted with XML and can be edited in any standard text editor, including Notepad.exe.
Important
Before you make any changes, you might want to create a copy of each of the original configuration files. In Notepad, you can use the Find feature on the Edit menu to search. As the default search starts at the current position, make sure you start your searches at the top of the document. One way to ensure you are at the top of the document is to press Ctrl+Home while working in Notepad.
Setting Exchange ActiveSync limits
The %ExchangeInstallpath% variable is an environment variable set when you installed Exchange server. You’ll find the web.config file for Exchange ActiveSync in the %ExchangeInstallpath%ClientAccessSync folder. In this web.config file, the MaxDocumentDataSize key sets the maximum size of data that can be received by the ActiveSync protocol, and the MaxRequestLength value sets the maximum size of data that can be received from an ActiveSync client.
You can open the configuration file for editing in Notepad by entering the following command at a command prompt:
Notepad %ExchangeInstallpath%ClientAccessSyncweb.config
Or entering the following at the shell prompt:
Notepad $env:ExchangeInstallpathClientAccessSyncweb.config
Real World
If you’re using Exchange Management Shell rather than a standard PowerShell prompt, keep in mind Exchange Management Shell does not run in elevated, administrator mode by default because your login credentials are used to create an implicit remoting session. Although you can run Exchange Management Shell in administrator mode, a new session for remoting won’t be implicitly established until you run the first Exchange command.
After you open the web.config file, search for MaxDocumentDataSize, and then set the related value to the desired maximum size in kilobytes (KB). Next, search for MaxRequestLength to set the related value to the desired maximum size in bytes. The related entries are:
<add key="MaxDocumentDataSize" value="10240000"> ... </add> <httpRuntime maxRequestLength="10240" />
When you are finished making changes, save and close the configuration file. Keep in mind that when you save the changes to the configuration file, the related web application is restarted automatically.
Confirm that Exchange ActiveSync is working as expected by entering Test-ActiveSyncConnectivity at the shell prompt. If there’s a problem with Exchange ActiveSync, check your edits or restore the original configuration file.
Setting Exchange Web Services limits
You’ll find the web.config file for Exchange Web Services in the %ExchangeInstallpath%ClientAccessexchwebews folder. In this web.config file, the MaxAllowedContentLength value sets the maximum size of HTTTP content requests and the MaxReceivedMessageSize value sets the maximum size of messages that can be accepted by Exchange Web Services.
You can open the configuration file for editing in Notepad by entering the following command at a command prompt:
Notepad %ExchangeInstallpath%ClientAccessexchwebewsweb.config
Or entering the following at the shell prompt:
Notepad $env:ExchangeInstallpathClientAccessexchwebewsweb.config
After you open the web.config file, search for each occurrence of MaxReceivedMessageSize to set the related value to the desired maximum size in bytes. You must set a MaxReceivedMessageSize value for each HTTP and HTTPS binding and authentication combination. Although there are 16 entries for MaxReceivedMessageSize in total, you don’t want to modify the two entries for UM bindings.
Next, search for MaxAllowedContentLength and then set the related value to the desired maximum size in bytes. When you’re finished making changes, save and close the configuration file. Keep in mind that when you save the changes to the configuration file, the related web application is restarted automatically.
Confirm that Exchange Web Services are working as expected by entering Test-WebServicesConnectivity at the shell prompt. If a problem occurs with Exchange Web Services, check your edits or restore the original configuration file.
Setting Outlook Web App limits
You’ll find the web.config file for Outlook Web App in the %ExchangeInstallpath%ClientAccessOwa folder. In this web.config file, the MaxAllowedContentLength value key sets the maximum size of HTTTP content requests, MaxReceivedMessageSize value sets the maximum size of messages that can be accepted by Outlook Web App and MaxRequestLength value sets the maximum size of data that can be received from an Outlook Web App client.
You can open the configuration file for editing in Notepad by entering the following command at a command prompt:
Notepad %ExchangeInstallpath%ClientAccessOwaweb.config
Or entering the following at the shell prompt:
Notepad $env:ExchangeInstallpathClientAccessOwaweb.config
After you open the web.config file, search for MaxAllowedContentLength, and then set the related value to the desired maximum size in bytes. Next, search for MaxReceivedMessageSize, and then set the related value to the desired maximum size in bytes. There are two entries for MaxReceivedMessageSize: one for HTTP and one for HTTPS. Finally, search for MaxRequestLength to set the related value to the desired maximum size in kilobytes. The related entries are:
<requestLimits maxAllowedContentLength="35000000" /> ... <binding name="httpsBinding" maxReceivedMessageSize="35000000"> ... <binding name="httpBinding" maxReceivedMessageSize="35000000"> ... <httpRuntime maxUrlLength="500" maxRequestLength="35000" requestValidationMode="2.0" enableVersionHeader="false" />
When you are finished making changes, save and close the configuration file. Keep in mind that when you save the changes to the configuration file, the related web application is restarted automatically. Confirm that Outlook Web App is working as expected by entering Test-OwaConnectivity at the shell prompt. If a problem with Outlook Web App occurs, check your edits or restore the original configuration file.
Real World
By default, IIS uses overlapping recycling of worker processes when restarting applications and application pools. With overlapping recycling, new worker processes are started to accept new requests from HTTP.sys while current worker processes are marked for recycling but continue handling existing requests. When all existing requests are handled, the original worker processes shut down.
Completing Transport services setup
After you install Mailbox servers running Exchange Server 2013, you need to finalize the configuration of Transport services by creating and configuring a postmaster mailbox and performing any other necessary tasks. For Exchange organizations with only Mailbox servers, you should optimize anti-spam features. For Exchange organizations with Edge Transport servers, you need to subscribe the Edge Transport servers to your Exchange organization.
Configuring the postmaster address and mailbox
Every organization that sends and receives mail should have a postmaster address. This is the email address listed on nondelivery reports and other delivery status notification reports created by Exchange Server. The postmaster address is not set by default; therefore, you must manually set it.
To view your Exchange organization’s postmaster address, enter the following command at the Exchange Management Shell prompt:
Get-TransportConfig | Format-List Name,ExternalPostMasterAddress
This command lists the postmaster address for the organization, as shown in this sample output:
Name: Transport Settings ExternalPostmasterAddress : [email protected]
If you don’t set the postmaster address, the address typically is set to $null, except when you have an Edge Transport server that hasn’t been through the Edge Sync process. To change the postmaster address, you can use the –ExternalPostMasterAddress parameter of the Set-TransportServer cmdlet, as shown in this example:
Set-TransportConfig -ExternalPostMasterAddress "[email protected]"
If you want the postmaster address to be able to receive mail, you must either create a mailbox and associate it with the postmaster address or assign the postmaster address as a secondary email address for an existing mailbox.
You also can view or change the organization’s postmaster address by completing the following steps:
In the Exchange Admin Center, select Mail Flow in the Feature pane, and then select either Receive Connectors or Send Connectors.
In the main pane, select the More button (which has 3 dots for an icon), and then tap or click Organization Transport Settings to display the Organization Transport Settings dialog box.
On the Delivery page, the current postmaster email address is listed (if any). If you want to change the postmaster address, enter the address you want to use, and then tap or click Save.
Real World
On the Delivery page, you also can specify the delivery status notification (DSN) codes that should be monitored. The postmaster receives a copy of any non-delivery reports delivered to internal senders with these codes. Codes you may want to have monitored include:
4.3.1. Issued when there are insufficient resources on the Mailbox server, usually as a result of a resource problem. Note that the report may state an out-of-memory error when the actual error that occurred was caused by a full disk.
4.3.2. Issued when the system is not accepting network messages often caused by a frozen queue. To resolve the problem, unfreeze the queue.
4.4.7. Issued when a message expires before it can be relayed or delivered, typically occurring as a result of a time-out during communication with a remote server. It also can indicate a message header limit has been reached, so the sender may need to reduce the number of recipients in the message.
5.3.5. Issued when a server is improperly configured, specifically when the server is configured to loop mail back to itself. To resolve the problem, check the server’s connectors for loops.
5.4.6. Issued when a routing loop is detected, specifically when the delivery of a message generates another message and that message then generates another message, and so forth. If the message generating loop continues more than 20 times, this error is issued. To resolve the error, check the mailbox rules associated with the recipients and senders to determine how automatic message forwarding is configured.
Configuring shadow redundancy
Shadow redundancy ensures that messages are protected from loss the entire time they are in transit by creating a copy of a message and retaining this copy while a message is in transit. If any transport server along the route fails to report a successful delivery, Exchange resubmits the message for delivery to ensure that the message continues through to its destination.
By default, shadow redundancy is enabled in the Transport service on all Mailbox servers. Unlike Exchange 2010, Exchange 2013 makes a redundant copy of any message it receives before acknowledging receipt. This important change ensures the message will be delivered even if the receiving server were to shut down immediately after acknowledging receipt of a message. Prior to this change, a message could possibly be lost if the receiving server were to shut down after acknowledging receipt of a message but before creating a copy of the message.
Thanks to shadow redundancy, as long as you have multiple transport servers (and multiple Edge Transports if you’ve deployed legacy Edge Transport servers), you can remove any transport server that fails and not have to worry about emptying its queues or losing messages. You also can upgrade or replace a Mailbox or Edge Transport server at any time without the risk of losing messages. If you have a single Mailbox server, you should drain all SMTP queues on the server before performing maintenance. The same is true if you have a single Edge Transport. This ensures that there is no risk of message loss, even without shadow redundancy. Keep in mind that if you have a single transport server, and it fails and must be replaced, you’ve likely lost data if you can’t restore the mail.que file.
Important
Shadow redundancy requires multiple servers. Your Mailbox servers can be stand-alone servers or they can be part of a database availability group. However, with stand-alone servers, each Active Directory site with Mailbox servers must have two or more stand-alone servers. Although there must be multiple members of a database availability group for shadow redundancy to work, the members of that group can be in different Active Directory sites.
When you work with shadow redundancy, a key concept to understand is that the primary transport server has ownership of the messages in its shadow queue. The first primary owner is always the server on which the message originates. As the message travels through the transport pipeline, different transport servers may become the primary owner of a message. In addition, if a primary owner fails, another server can take over as the primary.
Shadow redundancy is implemented according to high availability transport (HAT) boundaries in the organization. Each Active Directory site with Mailbox servers in the organization is a HAT boundary, as is each Database Availability group in the organization. Within a HAT boundary, two copies of a message are always in transit: the original and the redundant copy.
It’s important to point out that the original copy and the redundant copy exist on different servers. When a Mailbox server receives a message, it makes a redundant copy of the message on another Mailbox server in the HAT boundary before acknowledging receipt of the message. With database availability groups, the Transport service prefers creating the redundant copy in a remote site to ensure site resilience.
The basic process works like this:
The primary server transmits a copy of the message to the Transport service on another Mailbox server, and the Transport service on the other Mailbox server acknowledges that the copy of the message was created successfully. The copy of the message is the shadow message, and the Mailbox server that holds it is the shadow server for the primary server. The message exists in a shadow queue on the shadow server.
After the primary server receives acknowledgement from the shadow server, the primary server acknowledges the receipt of the primary message to the original SMTP server in the original SMTP session, and the SMTP session is closed.
The primary server transmits the message. If the primary server transmits the message outside the HAT boundary and the receiving SMTP server acknowledges successful receipt of the message, the primary server moves the primary message into its Safety Net queue. Otherwise, if the ultimate destination for the message is within the HAT boundary, the primary message is moved into the Safety Net queue when the message is accepted by the Transport service on a Mailbox server that holds the ultimate destination for the message.
The shadow server moves the shadow message to its Safety Net queue.
This process is complex and can be difficult to understand, so let’s take another look at the process. Step-by-step, the process works like this:
An SMTP server transmits a message to the Transport service on a Mailbox server in the Exchange organization. The receiving Mailbox server becomes the primary server for the message, and the original message is the primary message.
While the original SMTP session with the SMTP server is still active, the Transport service on the primary server opens a new, simultaneous SMTP session with the Transport service on another Mailbox server in the HAT boundary.
The primary server transmits a copy of the message to the Transport service on the other Mailbox server. The copy of the message is the shadow message, and the Mailbox server that holds it is the shadow server for the primary server. The message exists in a shadow queue on the shadow server.
After the primary server receives an acknowledgement from the shadow server that confirms the copy of the message was created, the primary server acknowledges the receipt of the primary message to the original SMTP server in the original SMTP session, and the SMTP session is closed.
The primary server transmits the message. The primary server and the shadow server stay in contact with each other to track the progress of the message.
When the primary server successfully transmits the message and the receiving SMTP server acknowledges successful receipt of the message, the primary server updates the discard status of the message to show delivery is complete and relays this to the shadow server.
The shadow server moves the shadow message from the shadow queue to its Safety Net queue.
In the Exchange Management Shell, you configure shadow redundancy for the on-premises Exchange organization by using the Set-TransportConfig cmdlet, as shown in Setting shadow queue options. The related parameters are used as follows:
MaxDumpsterTime. Only used by Hub Transport servers in a coexistence scenario. Specifies the maximum amount of time that a delivered message will remain in the transport dumpster for possible resubmission. The default is seven days.
MaxRetriesForLocalSiteShadow. When member servers in a database availability group span multiple Active Directory sites and ShadowMessagePreferenceSetting is configured to prefer remote sites, you can use this option to control how many times the primary server tries to create the shadow copy on a server in the local site after failing to create the copy in a remote site. By default, this option is set to 2. If the preference is for LocalOnly, this option controls the number of times the primary server tries to create the shadow copy on a server in the local site before failing and rejecting the message with a transient error.
MaxRetriesForRemoteSiteShadow. When member servers in a database availability group span multiple Active Directory sites and ShadowMessagePreferenceSetting is configured to prefer remote sites, you can use this option to control how many times the primary server tries to create the shadow copy on a server in a remote site before trying to create the shadow copy on a server in the local site. By default, this option is set to 4. If the preference is for RemoteOnly, this option controls the number of times the primary server tries to create the shadow copy on a server in a remote site before failing and rejecting the message with a transient error.
RejectMessageOnShadowFailure. Determines whether a primary message can be accepted or acknowledged without a shadow copy being created first. This option is disabled by default. If you enable this option and a shadow copy cannot be created, the primary message will be rejected with a transient error. Enable this option only when you must ensure a shadow copy of a message is always created and multiple Mailbox servers exist in each HAT boundary.
ShadowHeartbeatFrequency. Sets the amount of time a transport server waits before establishing a connection to the primary server to check the discard status of shadow messages. The default value is two minutes. Set this value according to the size of your Exchange implementation, the level of messaging traffic, and the relative latency on the network. For example, in a large global organization where transport servers handle an extremely high volume of messages, you might want to set a longer time interval, although the default may suffice for a smaller organization.
ShadowMessageAutoDiscardInterval. Sets the amount of time a server retains discard events for successfully delivered shadow messages. Primary servers queue discard events until they are checked by the shadow server or until the discard interval has elapsed, whichever comes first. The default value is two days. Set the value according to the size of your Exchange implementation, the level of messaging traffic, and the relative reliability of your network. For example, in a large global organization where transport servers handle an extremely high volume of messages on a highly reliable network, you might want to set a shorter discard interval, whereas the default may suffice for a smaller organization.
ShadowMessagePreferenceSetting. When member servers in a database availability group span multiple Active Directory sites, you can use this option to control remote site preferences. By default, this option is set to PreferRemote. Here, the primary server attempts to create a shadow copy on a server in a remote site. If this fails, the primary server attempts to create a shadow copy on a server in the local site. Alternatively, you can specify that the copy should only be made in the local site or only in a remote site. To do this, set the value to LocalOnly or RemoteOnly respectively.
ShadowRedundancyEnabled. Enables or disables shadow redundancy. If you don’t use shadow redundancy, you can use this parameter to disable the feature. Ideally, you’d only disable the feature temporarily or in situations in which you have a single Exchange server implementation and are experiencing problems related to this feature. By default, shadow redundancy is enabled.
ShadowResubmitTimeSpan. Specifies how long a shadow server waits before deciding that the primary server has failed and assumes ownership of messages in the shadow queue for that server. The default value is three hours. Set this value according to the size of your Exchange implementation and the relative amount of latency on the network. For example, a large global organization might want to set a longer time span, whereas the default may suffice for a smaller organization.
When working with shadow redundancy, Safety Net, and queues, you also want to consider:
ConnectionInactivityTimeout. Configured for each Send and Receive connector by using Set-SendConnector and Set-ReceiveConnector. Sets the maximum time that an open SMTP connection between servers can remain idle before timing out. This value must be smaller than the ConnectionTimeout value. For Send connectors, the default is 10 minutes. For Receive connectors, the default is 5 minutes for the Transport service on Mailbox servers and the Front End Transport service on Client Access servers, but only one minute for Edge Transport servers.
ConnectionTimeout. Configured for each Receive connector using Set-ReceiveConnector. Sets the maximum time that an SMTP connection can be open between servers, even if the source server is transmitting data. The default is 10 minutes for the Transport service on Mailbox servers and the Front End Transport service on Client Access servers, but only 5 minutes for Edge Transport servers.
MessageExpirationTimeout. Configured for the Transport service on each Mailbox server using Set-TransportService. Specifies how long a message can remain in a queue before it expires. The default value is two days.
When configuring these settings, you’ll want to consider the relative latency and speed of the network as well as level of messaging traffic. If a slow or congested network has high latency, you may need to configure higher timeout values. Keep in mind, however, that each open connection uses resources and that each connector allows a finite number of open connections. By default, with Send connectors, the maximum number of connections is 1,000 and the maximum number of connections per domain is 20.
Configuring Safety Net
All Mailbox servers use Safety Net to maintain a queue of messages that were recently delivered to recipients. As discussed in “Working with Exchange Server message queues” in Chapter 1 and in the previous section of this chapter, this feature works in conjunction with shadow redundancy. The primary server that sends a message maintains the primary Safety Net queue while a second server, called the shadow server, maintains the shadow Safety Net queue.
In the Exchange Management Shell, you configure Safety Net with these parameters in mind:
SafetyNetHoldTime. An organization-wide option configured for Set-TransportConfig. Specifies how long a successfully processed message is retained in the Safety Net queue. The default value is two days. Unacknowledged shadow messages expire after the sum of the SafetyNetHoldTime and the MessageExpirationTimeout elapses. Set this value according to the size of your Exchange implementation and the relative amount of latency on the network. For example, a large global organization might want to set a longer time span, although the default may suffice for a smaller organization.
ReplayLagTime. Configured on individual mailbox database copies for Set-MailboxDatabaseCopy. Specifies how long the Exchange Replication service waits before replaying log files that have been copied to the passive database copy. By default, this option is not set. To ensure no data is lost and messages are available for resubmittal from the Safety Net queue, the replay lag time must be less than or equal to the safety net hold time.
MessageExpirationTimeout. Configured for the Transport service on each Mailbox server using Set-TransportService. Specifies how long a message can remain in a queue before it expires. The default value is two days.
ShadowRedundancyEnabled. Set using the Set-TransportConfig cmdlet. Enables or disables shadow redundancy for the Exchange organization. As Safety Net relies on shadow redundancy, you also disable Safety Net if you disable shadow redundancy.
You can use Exchange Admin Center to view or change the Safety Net hold time as well. Select Mail Flow in the Feature pane, and then select either Receive Connectors or Send Connectors. In the main pane, select the More button (which has 3 dots for an icon), and then tap or click Organization Transport Settings. This displays the Organization Transport Settings dialog box. Tap or click Safety Net. Finally, in the Safety Net Hold Time text box, enter the number of days that messages should be held in Safety Net queues and then tap or click Save.
Enabling anti-spam features
By default, Edge Transport servers have anti-spam features enabled and Mailbox servers do not. In an Exchange organization with Edge Transport servers, this is the desired configuration: you want your Edge Transport servers to run anti-spam filters on messages before they are routed into the Exchange organization. After Edge Transport servers have filtered messages, you don’t need to filter them again, which is why Mailbox servers have this feature disabled.
If your organization doesn’t use Edge Transport servers and has only Mailbox servers, you can enable the anti-spam features on Mailbox servers that receive messages from the Internet so that you can filter incoming messages for spam. However, if incoming mail has any prior anti-spam filtering, you don’t need to filter messages again.
The following anti-spam agents are available for the Transport service on Mailbox servers to use:
Content Filter agent
Protocol Analysis agent
Recipient Filter agent
Sender Filter agent
Sender ID agent
You can install and configure these agents by doing the following:
Log on to the Mailbox server you want to configure.
In Exchange Management Shell, run the following command:
& $env:ExchangeInstallPathScriptsInstall-AntiSpamAgents.ps1
After you install the anti-spam agents, you must restart the Exchange Transport service. In the shell, you can do this by running the following command:
Restart-service MSExchangeTransport
Repeat steps 1 – 3 for each Mailbox server that should filter messages.
Configure organization-wide transport settings that identify any internal SMTP servers that should be ignored by the Sender ID agent. Typically, this includes any Mailbox server in which you’ve enabled the anti-spam features. Use the -InternalSMTPServers parameter of Set-TransportConfig to identify each server by its IPv4 address. Here are examples:
Set-Transportconfig -InternalSMTPServers @{Add="192.168.10.52"} Set-Transportconfig -InternalSMTPServers @{Add="192.168.10.52","192.168.10.64"}You can verify that the servers were added by running the following command:
Get-TransportConfig | fl InternalSMTPServers
Once you’ve installed the anti-spam agents, you can enable or disable the anti-spam features on Mailbox servers by using the Set-TransportService cmdlet. To enable these features, set the –AntispamAgentsEnabled parameter to $true. To disable these features, set the –AntispamAgentsEnabled parameter to $false.
The following example shows how you can enable anti-spam features on a Mailbox server named CorpSvr127:
Set-TransportService –Identity 'CorpSvr127' –AntispamAgentsEnabled $true
Next you need to restart the Microsoft Exchange Transport service on the server. In the shell, you can do this by running the following command:
Restart-service MSExchangeTransport
You can now configure the transport server’s anti-spam features as discussed in the Configuring anti-spam and message filtering options section in Chapter 5. When you turn on anti-spam features, a transport server can automatically get updates for spam signatures, IP reputation, and anti-spam definitions through automatic updates, as long as you’ve done the following:
Conformed to Microsoft’s licensing requirements
Enabled Automatic Updates for use on the server
Specifically enabled and configured anti-spam updates
To obtain anti-spam updates through automatic updates, Microsoft requires an Exchange Enterprise Client Access License (CAL) for each mailbox user. You can configure automatic updates by using the Windows Update utility in Control Panel. Press Windows key + I, tap or click Control PanelSecurity, and then tap or click Windows Update to start this utility. You can also configure Automatic Updates through Group Policy.
Subscribing Edge Transport servers
When your Exchange organization uses Legacy Edge Transport servers and you want to use the Edge Synchronization feature, you must subscribe the Edge Transport server to your Exchange organization prior to performing other configuration tasks on the Edge Transport server. Creating a subscription allows the Microsoft Exchange EdgeSync service running on designated Mailbox servers to establish one-way replication of recipient and configuration information from your internal Active Directory database to the AD LDS database on an Edge Transport server. After you create an Edge subscription, synchronization is automatic. If problems occur, however, you can force synchronization or remove the Edge subscription.
Creating an Edge subscription
A subscribed Edge Transport server receives the following from the EdgeSync service:
Send connector configurations
Accepted domain configurations
Remote domain configurations
Safe Senders lists
Recipients
Any manually configured accepted domains, message classifications, remote domains, and Send connectors are deleted as part of the subscription process, and the related Exchange management interfaces are locked out as well. To manage these features after a subscription is created, you must do so within the Exchange organization and have the EdgeSync service update the Edge Transport server.
Also as part of the subscription process, you must select an Active Directory site for the subscription. The Mailbox server or servers in the site are the servers responsible for replicating Active Directory information to the Edge Transport server.
You can create a subscription for an Edge Transport server by completing the following steps:
Log on to the Edge Transport server for which you are creating a subscription by using an administrator account.
At the Exchange Management Shell prompt, type the following command:
New-EdgeSubscription -filename "C:EdgeSubscriptionExport.xml"When prompted, confirm that it’s okay to delete any manually configured accepted domains, message classifications, remote domains, and Send connectors by pressing A (which answers Yes to all deletion prompts).
Copy the EdgeSubscriptionExport.xml file to a Mailbox server in your Exchange organization.
Log on to a Mailbox server in your Exchange organization by using an account with Exchange administration privileges.
On the Mailbox server, start the Exchange Management Console. Expand the Organization Configuration node, and then select the Mailbox node.
In the details pane, the Edge Subscriptions tab lists existing subscriptions by Edge Transport server name and associated Active Directory site.
Press and hold or right-click an open area of the details pane, and then select New Edge Subscription. This starts the New Edge Subscription Wizard, as shown in Figure 4-14.
On the New Edge Subscription page, tap or click Browse to the right of the Active Directory Site text box. In the Select Active Directory Site dialog box, choose the Active Directory site for replication, and then tap or click OK.
Real World
Mailbox servers in the Active Directory site you select must be able to resolve the IP addresses for the Edge Transport server. You need to ensure that subnets have been created in Active Directory Sites And Services and that DNS is configured to resolve the fully qualified domain name of the Edge Transport server. Mailbox servers in the site must also be able to connect to the Edge Transport server over TCP port 50636.
Tap or click Browse to the right of the Subscription File text box. In the Open dialog box, locate and then select the Edge Subscription file to import. Tap or click Open.
On the New Edge Subscription page, if you don’t want to create the required Send connectors now, clear Automatically Create A Send Connector For This Edge Subscription, and then tap or click New to begin the subscription process. If you want to create Send connectors now, just tap or click New to begin the subscription process.
On the Completion page, tap or click Finish. Initial synchronization will begin, as discussed in “Synchronizing Edge Subscriptions.”
After you’ve completed steps 1–5, you can use the New-EdgeSubscription cmd-let to start a subscription. New-EdgeSubscription cmdlet syntax and usage provides the syntax and usage. By default, the –CreateInboundSendConnector parameter is set to $true, which ensures that a Send connector from the Edge Transport server to Mailbox servers is created. By default, the –CreateInternetSendConnector parameter is set to true, which ensures that a Send connector to the Internet is created.
Getting Edge subscription details
In the Exchange Management Console, you can view Edge subscriptions by expanding the Organization Configuration node, selecting the Mailbox node, and then tapping or clicking the Edge Subscriptions tab. Each Edge subscription is listed by Edge Transport server name and associated Active Directory site as shown in Figure 4-15.
As Get-EdgeSubscription cmdlet syntax and usage shows, you can use the Get-EdgeSubscription cmdlet to get information about Edge subscriptions as well. If you do not provide an identity with this cmdlet, configuration information for all Edge Subscriptions is returned.
Synchronizing Edge subscriptions
During the configuration of an Edge subscription, you specified an Active Directory site to associate with the subscription. Mailbox servers in this site run the EdgeSync service and are responsible for synchronizing configuration data between Active Directory Domain Services and AD LDS on the Edge Transport server. By default, the EdgeSync service synchronizes configuration data hourly and recipient data every four hours.
If you’ve just created a new subscription and synchronization has occurred, you should verify that replication is taking place as expected by completing the following steps:
On the Edge Transport server, start the Exchange Management Shell.
Verify that a Send connector was created to send Internet mail by typing the command get-sendconnector. As shown in the following example and sample output, you should see an Inbound connector and an Internet connector for EdgeSync:
get-sendconnector
Identity AddressSpaces Enabled -------- ------------- ------- Primary Send Connector {SMTP:*.cpandl.com;1} True SD1 Send Connector {SMTP:*.adatum.com;1} True EdgeSync - Seattle-First-Site to Int {smtp:*;100} True EdgeSync - Inbound to Seattle-First- {smtp:--;100} TrueVerify that there is at least one entry for accepted domains by typing get-accepteddomain as shown in the following example and sample output:
get-accepteddomain
Name DomainName DomainType Default ---- ---------- ---------- ------- cpandl.com cpandl.com Authoritative True
If you suspect there is a problem with synchronization and you want to start immediate synchronization of configuration data for all Edge subscriptions, complete the following steps:
If you are running the command on the Mailbox server, you can omit the –Server parameter.
Verifying Edge subscriptions
The easiest way to verify the subscription status of Edge Transport servers is to run the Test-EdgeSynchronization cmdlet. This cmdlet provides a report of the synchronization status, and you also can use it to verify that a specific recipient has been synchronized to the Active Directory Lightweight Directory Service on an Edge Transport server.
Test-EdgeSynchronization cmdlet syntax and usage provides the syntax and usage for the Test-EdgeSynchronization cmdlet. By default, the cmdlet verifies configuration objects and recipient objects. To have the cmdlet verify only configuration data, set –ExcludeRecipientTest to $true. Use the –VerifyRecipient parameter to specify the email address of a recipient to verify.
Removing Edge subscriptions
If you replace or decommission an Edge Transport server, you no longer need the related Edge subscription and can remove it. Removing an Edge subscription
Stops synchronization of information from the Active Directory Domain Service to AD LDS.
Removes all the accounts that are stored in AD LDS.
Removes the Edge Transport server from the source server list of any Send connector.
You can remove an Edge subscription by completing the following steps:
Log on to a Mailbox server by using an account with Exchange administrator privileges.
In the Exchange Management Console, expand the Organization Configuration node, and then select the Mailbox node.
In the details pane, on the Edge Subscriptions tab, press and hold or right-click the subscription that you no longer need, and then select Remove.
When prompted to confirm, tap or click Yes.
In the Exchange Management Shell, you can remove an Edge Subscription by passing the identity of the subscription to remove to the Remove-EdgeSubscription cmdlet. Remove-EdgeSubscription cmdlet syntax and usage provides the syntax and usage.