Few weeks ago, I was working on a migration project between two independent domains. The project by itself was huge because there were multiple teams working on too. In this project, we had to migrate the Active Directory including the SID history, Exchange SAP Skype for business and much more other things.
However, because of the migration project was big, we did not make a big bang cut over migration.
During the Project, we created a two-way trust between the old and the new world. This allowed us, migrating in a smooth way with less user interruptions.
My part was the migration of Exchange. In the project period the MX where still pointing to the old Exchange environment. I have also created in the old Exchange environment a source- and in the new Exchange Environment a target Mail address for the migration with quest.
However, everything was working well – except email auto forwarding between the two Exchange environments.
To show you an example of the issue we had, see below:
Ezio (active on the old environment) had an Outlook rule that all mails sent to him should be forwarded to Desmond (active on the old environment) and Angelina (new environment). However, the forwarding to Desmond worked well and as expected, but Angelina did not receive any email.
If Ezio is sending a normal email or a Meeting request to Angelina, everything works fine, only the forwarding rule did not work.
The problem in this case is that I had to configure a remote domain for automatic replies in the source environment.
What is a remote Domain?
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.
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.
- 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
How to set a remote Domain?
First, to configure a remote Domain for Exchange, we need the Exchange management shell.
Before we set a remote domain, we need to have a look, if and which remote Domains are already set, to do this we can use the following PowerShell command:
Get-RemoteDomain
However, here we get a list of all current remote domains in our environment. If the one we wanted to create is already listed in the Shell output, we may have another problem.
If not, we can create a new entry by using the following command:
New-RemoteDomain -DomainName contoso.com -Name contoso
After creating the remote Domain, I need to allow the auto reply to the remote domain:
Set-RemoteDomain Contoso –AutoReplyEnabled $true
If we also want to allow automatic forwards to the remote domain, what was the problem in my migration case, we also need to run the following command:
Set-RemoteDomain Contoso –AutoForwardEnabled $true
As the last step, we can control now which settings we have done for our specific domain. To do that, we can run the command below, to see the current settings:
Get-RemoteDomain Contoso | fl
Conclusion
In my specific case, this was the solution. However, remote domains are one of those essential configuration elements for Exchange that administrators may need to review and/or change from time to time. Not all configuration options will necessarily be used but administrators should be aware of the options for future use.
Photo by Nathan Dumlao on Unsplash