When configuring an Exchange Hybrid environment, the Hybrid Configuration Wizard (HCW) handles the majority of the heavy lifting. Despite the automation of the HCW, my colleagues and I have noticed there are some settings related to “Remote Domains” that don’t always end up properly configured.
The Hybrid Configuration Wizard (HCW) has evolved since its initial release in SP2 for Exchange 2010; with each update to Exchange 2010 or Exchange 2013, it’s possible that the logic used by the HCW has been updated. So while it’s difficult to say what specific settings were configured by the HCW at the time your organization ran it, I’ve noticed that at least the current version of the Exchange 2013 HCW does not seem to properly configure “Remote Domains”.
If left misconfigured, you may find that features such as “Out of Office” and “Voting Buttons” do not function as expected in an Exchange Hybrid environment.
What is a “Remote Domain”?
Remote Domains are an organizational setting that allow you to control certain message types such as “Out of Office” and “Non-Delivery Reports”. In an Exchange Hybrid environment, they are configured independently in both the on-premises and Exchange Online organization. For more information on Remote Domains, check out: “Remote Domains in Exchange Online”.
Misconfigured Remote Domains in Exchange Hybrid
Below are the on-premises remote domains as recently configured in an environment using the Exchange 2013 CU6 HCW:
DomainName AllowedOOFType TNEFEnabled
---------- -------------- -----------
* External
lab4.iwitl.com External
lab4.mail.onmicrosoft.com External
…and here they are in Exchange Online as configured by the Exchange 2013 CU6 HCW:
DomainName AllowedOOFType TNEFEnabled
---------- -------------- -----------
* External
Below are the on-premises remote domains as recently configured in an environment using the Exchange 2010 SP3 HCW:
DomainName AllowedOOFType TNEFEnabled
---------- -------------- -----------
* External
lab1.iwitl.com External
lab1.mail.onmicrosoft.com InternalLegacy True
…and here they are in Exchange Online as configured by the Exchange 2010 SP3 HCW:
DomainName AllowedOOFType TNEFEnabled
---------- -------------- -----------
* External
lab1.iwitl.com InternalLegacy True
lab1.mail.onmicrosoft.com External
The Remote Domains configured by the Exchange 2010 HCW appear to be correct whereas the Exchange 2013 Remote Domains look to be misconfigured.
What’s The Impact?
The impact of misconfigured Remote Domains can largely go unnoticed, especially since the person most impacted is going to be the recipient who may not report the issue to the sender or support.
Out of Office (AllowedOOFType)
The “Out of Office” message in Exchange allows the user to setup separate responses for senders that are “inside” or “outside” your organization. This allows you to provide a more generic message to external parties while providing more detailed message or personal contact information to your coworkers. When your Remote Domains are not configured properly, you’ll find that everyone, internal and external, receives the “outside” message.
What’s interesting about this setting is that with the above 2013 settings configured by the HCW, you’ll actually receive misleading information from the Out of Office “mail tip”. When you go to send a message cross-premises, the mail tip will show the “internal” Out of Office but Exchange will actually return the “external” message.
Voting Buttons (TNEFEnabled)
Perhaps not a frequently used feature but Outlook allows you to create a poll using “voting buttons”. The idea is you email a question with either the default or custom voting buttons enabled and you can then track the recipient’s responses from the message in your “Sent Items”. If your Remote Domains are not configured properly, you may find that the recipient does not see the actual buttons to submit their vote. The problem seems to only occur for on-premises to cloud messages when configured using the above 2013 settings.
Resolution
Correcting the Remote Domains issue is not terribly difficult. Essentially you need to create/modify the appropriate Remote Domain and then properly configure the “AllowedOOFType” and “TNEFEnabled” settings.
To correct Out of Office messages sent to cloud users and the missing voting buttons, we need to change “AllowedOOFType” to “InternalLegacy” and set “TNEFEnabled” to “$true” for our coexistence domain. We can do that by using the “Set-RemoteDomain” command below in the on-premises Exchange organization:
Set-RemoteDomain "Hybrid Domain - lab4.mail.onmicrosoft.com" -AllowedOOFType InternalLegacy -TNEFEnabled $true
To correct the cloud side, we need to first create a Remote Domain and then set the appropriate properties:
New-RemoteDomain "lab4.iwitl.com" -DomainName "lab4.iwitl.com"
Set-RemoteDomain "lab4.iwitl.com" -AllowedOOFType InternalLegacy -TNEFEnabled $true
Note: As you make these changes to Remote Domains, there can be a delay before you see the changes fully implemented. So don’t be surprised in your first couple tests if you receive both the internal and external Out of Office messages.
Summary
- Remote Domains control certain message types at an organizational level
- The Hybrid Configuration Wizard configures Remote Domains during setup
- Your Remote Domains could be misconfigured and it could easily go unnoticed by most
- Misconfiguration of Remote Domains can impact “Out of Office” and “Voting Buttons”
- Delays may occur before changes to Remote Domains actually take effect
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
thanks a lot
one of the best if not the best blog around for 365
enjoy reading every single post
Thanks
Thanks, I appreciate the feedback.
If you have multiple accepted domains within Office 365, should you be defining an InternalLegacy Remote Domain for each of those domains?
For example on-premise has something.com.au & something.com as authoritative domains, meaning on-premise would have an InternalLegacy Remote domain of something.onmicrosoft.com
cloud would then have InternalLegacy Remote domains specified for both something.com.au & something.com
correct?
Yes, you would have a remote domain for each accepted domain.
Thanks for the confirmation. This is definitely something that got missed when we ran HCW.
Hi Joe – for the remote domains, I’m hoping you can clear something up for me. Would we need a remote domain in the tenant and on prem for each of smtp domains we have as authoritative? I’m going with ‘yes’ but when we ran the HCW, we were only working with a few of our domains at first and so there are several I need to now manually set up. As an example, abc.com and efg.com – in the tenant have a InternalLegacy Remote domain configured for each, and also on prem, since we will have users for those SMTP domains in both the tenant and on prem? Thanks, your posts have been helpful to us!