Sign in with your Microsoft account
You'll use your Microsoft Account for everything you do with Office. If you use a Microsoft service like Outlook.com, OneDrive, Xbox Live, or Skype, you already have an account.
The goal of this post is to compile all publicly announced Office 365 service changes for 2020, especially those that may require admin action, into a single reference. These changes are listed below in chronological order, based on the “Action Required” date. Additional information and resources related to these changes are provided where applicable. Updates…
Microsoft Ignite
Download available decks and watch videos from Microsoft Ignite 2017 right here. Learn more
Microsoft Tech Academy
Offers free Learning Pathways and resources to build your Microsoft cloud skills and expertise. Get started
In Office 365 I often encourage customers to control user forwarding through the user of remote domains. You can find two of my blog posts on this topic here:
https://blogs.technet.microsoft.com/timmcmic/2015/06/08/exchange-and-office-365-mail-forwarding-2/
https://blogs.technet.microsoft.com/timmcmic/2015/04/19/office-365-determine-accounts-that-have-forwarding-enabled/
In a default installation a remote domain is defined in the service only for the * domain.
PS C:\> Get-RemoteDomain
Name DomainName AllowedOOFType
---- ---------- --------------
Default * External
The auto forwarding property can be adjusted to FALSE which prevents autoforwarding from succeeding even if configured by the end user.
PS C:\> Get-RemoteDomain | Select-Object AutoForwardEnabled
AutoForwardEnabled
------------------
False
I recently had a customer present with an issue where forwarding was not working. In this particular instance forwarding was not working when a mailbox in the service created a rule or was using forwarding SMTP address to a user that was not yet migrated. The recipients mailbox was located on premises in the same organization. Let us take a look at an example…
In Office 365 I have changed the forwarding SMTP address to be a proxy address of an object that has not yet been migrated. The forwarding smtp address property is treated in the same manner as an inbox rule setting a forwarding or redirect address. (For a details explanation of the different forwarding methods see my previously mentions posts).
Set-Mailbox Contact -ForwardingSmtpAddress journal@contoso.com
When the forwarding address as been set all emails directed to this mailbox should also be redirected to the forwarding address.
To test the forwarding using an external mailbox outside the organization I addressed an email to the mailbox where forwarding was enabled. Using message tracing I traced the message and noted that the status now shows as FAILED.
PS C:\> Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com
Received Sender Address Recipient Address Subject Status
-------- -------------- ----------------- ------- ------
4/9/2018 2:41:08 PM timmcmic@microsoft.com journal@contoso.com Test Failed
Using get-messageTraceDetail we can review the full path of the message including any drops.
PS C:\> $trace=Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com | Get-MessageTraceDetail
PS C:\> $trace
Date Event Detail
---- ----- ------
4/9/2018 2:41:11 PM Journal Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 2:41:11 PM Drop Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward address...
4/9/2018 2:41:11 PM Drop Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward address...
4/9/2018 2:41:11 PM Spam Diagnostics
In this instance we can see two drop events have occurred. We can review the specific details of one of the drop events.
PS C:\> $trace[1].detail
Reason: [{LED=250 2.1.5 RESOLVER.MSGTYPE.AF; handled AutoForward addressed to external recipient};{MSG=};{FQDN=};{IP=};{LRT=}]
This is interesting – the message trace details seem to indicate that the message was dropped to an external recipient. Why?
In this case the message is leaving the office 365 organization and therefore is considered external even though the message is destined to the on premises organization. Due to transport seeing the forwarding recipient as external – and the remote domain * being the only domain defined and having auto forwarding disabled – the message is turfed.
How can we fix this?
We can fix this by defining a remote domain for the internal namespace.
PS C:\> New-RemoteDomain -DomainName contoso.com -Name "Contoso Remote Domain"
Name DomainName AllowedOOFType
---- ---------- --------------
Contoso Remote Domain contoso.com External
PS C:\> Get-RemoteDomain "Contoso Remote Domain" | fl autoForwardEnabled
AutoForwardEnabled : True
The entire process can be retested after allowing time for replication. In this instance we will observe that the forwarded message is now delivered.
PS C:\> Get-MessageTrace -RecipientAddress journal@contoso.com -SenderAddress timmcmic@microsoft.com | where{$_.status -like "Delivered"}
Received Sender Address Recipient Address Subject Status
-------- -------------- ----------------- ------- ------
4/9/2018 3:06:30 PM timmcmic@microsoft.com journal@contoso.com Test Delivered
PS C:\> $trace=Get-MessageTrace -RecipientAddress journal@contoso.org -SenderAddress timmcmic@microsoft.com | where{$_.status -like "Delivered"} | get-messageTraceDetail
PS C:\> $trace
Date Event Detail
---- ----- ------
4/9/2018 3:06:33 PM Journal Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 3:06:33 PM Journal Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 3:06:33 PM Journal Message was journaled. Journal report was sent to journal@contoso.co...
4/9/2018 3:06:34 PM Send external Message sent to mail.contoso.com at IPAddress using TLS1.2 w...
4/9/2018 3:06:33 PM Spam Diagnostics
The new remote domain settings are being applied as expected.
