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.
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 contoso.com in addition to the default remote domain. In this scenario, the settings configured in the contoso.com remote domain will be used for messages that are sent to recipients with contoso.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 contoso.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 contoso.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 contoso.com, the administrator could run the following command:
New-RemoteDomain -Name “Contoso” -DomainName contoso.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 Fabrikam ordinarily have fabrikam.com SMTP addresses, but contoso.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 fabrikam.com or contoso.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 Fabrikam 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 Fabrikam 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 Fabrikam 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