If you would like to read the next part in this article series please go to Remote Domains in Exchange 2013 (Part 2).
Introduction
In the world of Microsoft Exchange, there are two types of domains that the administrator must understand and configure accordingly: accepted domains and remote domains. Accepted domains are SMTP namespaces for which Exchange is allowed to send or receive email. In the case of receiving email, accepted domains also include those SMTP namespaces for which Exchange will receive a message yet continue to send it onwards to other external email systems. Remote domains are simply those SMTP namespaces that are external to Exchange.
Back in 2011, I wrote a two-part article on accepted domains in Exchange 2010 here at MSExchange.org and had planned to write a related article on remote domains shortly after that, but for one reason or another that never happened. It’s now time to rectify that and here in this two-part article the subject of remote domains in Exchange 2013 will be covered.
Remote Domain Purpose
Broadly speaking, remote domains are used to control various aspects of messages sent to recipients in domains that are external to the local Exchange organization. Application of remote domain settings permit the following configurations to be applied to messages sent to the domain specified in the remote domain entry:
- The types of messages that are to be sent to that domain. The typical configuration items here are where an administrator chooses whether to send Out of Office and automatic forwards to the remote domain, but there are other configuration options here as will be explained later in this article series
- The message format. Remote domains offer several different configurable parameters that affect the message format, such as the Transport Neutral Encapsulation Format (TNEF) conversion settings and message encoding options that affect areas such as the MIME and non-MIME character sets and the line wrap size
- Whether simple display names are sent or not. This is where the recipient sees the sender’s display name versus only seeing the sender’s SMTP address
The Default Remote Domain
By default, when Exchange 2013 is first installed, a single default remote domain is created. To view the properties of this remote domain, the Exchange Management Shell command to use is the Get-RemoteDomain command and as can be seen from Figure 1-1, the output of this command reveals that the default remote domain has a domain name parameter value of *. This value specifies all remote domains rather than any specific remote domain.
Figure 1-1: The Default Remote Domain
One important rule for Exchange administrators to remember here is that the default remote domain settings will always be used unless other specific remote domains have been configured. For example, the administrator may create a new remote domain for neilhobson.com in addition to the default remote domain. In this scenario, the settings configured in the neilhobson.com remote domain will be used for messages that are sent to recipients with neilhobson.com SMTP addresses, rather than the settings configured in the default remote domain. However, since no other specific remote domains have been created, the settings configured in the default remote domain will still be used for messages that are sent to recipients with SMTP addresses other than neilhobson.com, such as tailspintoys.com SMTP addresses for example.
Remote Domain Commands
There are only four Exchange Management Shell commands that are used for remote domain administration. They are:
- Get-RemoteDomain. As seen in the previous section, this command is used to retrieve the settings of any existing remote domains
- Set-RemoteDomain. This command is used to alter the parameters of any existing remote domains. Examples of using this command will be seen throughout this article series
- New-RemoteDomain. The New-RemoteDomain command is used to create a new remote domain
- Remove-RemoteDomain. This command is used to remove an existing remote domain entry
In the previous section, the example given was where an administrator created a new remote domain for neilhobson.com. To do this, it’s simply a case of running the New-RemoteDomain command and the required parameters. In fact, the only required parameters are the Name and DomainName parameters, as all other parameters are optional. For example, to create a new remote domain for neilhobson.com, the administrator could run the following command:
New-RemoteDomain -Name “neilhobson.com” -DomainName neilhobson.com
To remove a remote domain, the administrator just needs to use the Remove-RemoteDomain command with the Identity parameter to identify the relevant remote domain to remove. Note that the value of the Identity parameter will correspond to the value of the Name parameter used to create the remote domain. It should also be noted that the default remote domain cannot be removed.
Controlling Out of Office Replies
Exchange 2013 supports both the internal and external types of Out of Office messages. Users get the option to specify whether their Out of Office message is sent to internal, external or both types of recipients, but the success of this Out of Office message transfer depends on what is permitted by the Exchange configuration. In Outlook Web App, the Out of Office message configuration choice is presented to users via the screen that can be seen below in Figure 1-2.
Figure 1-2: Setting Internal and External Out of Office Replies
An organization may choose to empower the users themselves with the decision of whether to send Out of Office messages to external recipients, or the remote domain may be configured by the administrator to block the sending of Out of Office messages to external recipients at that domain. External recipients in this scenario means recipients that have addresses from domains that are not configured as an accepted domain within the Exchange configuration. For example, consider the scenario where users in the Exchange organization for nghcloud.co.uk ordinarily have nghcloud.co.uk SMTP addresses, but neilhobson.com has also been configured as an accepted domain to provide SMTP addresses for some users as part of a different brand requirement. External recipients in this scenario would be any recipients that have SMTP addresses other than nghcloud.co.uk or neilhobson.com, such as tailspintoys.com for example.
To permit Out of Office replies to be sent to recipients from the tailspintoys.com domain, the Exchange administrator for nghcloud.co.uk would need to ensure that the remote domain applicable to tailspintoys.com would need to permit external Out of Office messages. The remote domain that applies to tailspintoys.com could be either the default * remote domain or a specific remote domain for tailspintoys.com. The remote domain parameter to view is the AllowedOOFType parameter, and this has a default value of External as can be seen from Figure 1-3. Here it can be seen that the Exchange administrator uses the following command to view the properties of the default * domain and filter for the AllowedOOFType parameter:
Get-RemoteDomain -Identity Default | fl *AllowedOOFType*
Figure 1-3: Default External Setting of AllowedOOFType
It may also be noticed that the AllowedOOFType parameter is displayed by default when viewing the properties of a remote domain, as can be seen earlier in Figure 1-1. Essentially, there is no real need to filter on the AllowedOOFType parameter when using the Get-RemoteDomain command.
A value of External means that the external Out of Office message will be sent to the specific remote domain. If an organization wants to send the internal Out of Office messages to remote domains, a value of Internal must be specified on that remote domain object. To block all Out of Office messages to the specific remote domain, the Exchange administrator can set the AllowedOOFType parameter to a value of None.
There are two other values for the AllowedOOFType parameter that reference legacy clients. The values of External and Internal relate to newer versions of the Outlook client. To consider Out of Office messages sent by clients running Outlook 2003 or earlier, the values of ExternalLegacy and InternalLegacy can be used. For example, suppose nghcloud.co.uk determines the requirement to send Out of Office messages from all versions of clients, including Outlook 2003, to all recipients in a specific remote domain. To permit this, the Exchange administrator for nghcloud.co.uk configures the specific remote domain such that the AllowedOOFType parameter is set to a value of ExternalLegacy. This is achieved using the following command:
Set-RemoteDomain -Identity Default -AllowedOOFType ExternalLegacy
Summary
That completes part one of this article on the subject of remote domains. In this article, the purpose of remote domains has been discussed as well as the existence of the default remote domain. Also, the common task of controlling Out of Office replies has been covered. In part two, the topics of controlling automatic replies, non-delivery reports and message formatting will be discussed, along with the per-user settings that can be used in conjunction with remote domain settings.
If you would like to read the next part in this article series please go to Remote Domains in Exchange 2013 (Part 2).
