Tag Archives: Exchange Online

Exchange 2016 End of (mainstream) support

As you should (must) know, Exchange 2010 support will end this October. At that point, Microsoft will stop all support for Exchange 2010, including all security fixes. If you are still running Exchange 2010, you must act now and start moving to Exchange 2016 or to Office 365. For an Exchange 2010 to Office 365 migration I have written a couple of blogs before:

Moving from Exchange 2010 to Office 365.

Moving from Exchange 2010 to Office 365 Part II.

But what most people don’t realize is that Exchange 2016 mainstream support will also end this October. From that point forward, Exchange 2016 will be in extended support. This means no more Cumulative Updates and only Security Updates will be released when there updates are marked as ‘critical’.

Note. There’s no direct upgrade path from Exchange 2010 to Exchange 2019, so if you want to follow this route, you must move to Exchange 2016 first, followed by a migration to Exchange 2019.

If you move to Office 365 and have moved all your Mailboxes to Exchange Online, things are getting interesting. In this situation, you still need at least one Exchange server on-premises for management purposes. Microsoft supplies a free Exchange 2016 hybrid license for this situation (there is no free Exchange 2019 hybrid license!), and Microsoft is committed to support this configuration. At least until the moment a final solution is delivered by Microsoft to remove that last Exchange server from your on-premises organization. According to Microsoft, “this does not increase your risk profile in any way” as stated in their article “Exchange Server 2016 and End of Mainstream Support”.
If you still have mailboxes on-premises, the Microsoft recommendation is to move to Exchange 2019. Mainstream support for Exchange 2019 will end on January 1st, 2024, and extended support for Exchange 2019 will end on October 14, 2025 (this is the same date as end of extended support for Exchange 2016).

What to do

  1. If you are still on Exchange 2010, I would urge you to move to Exchange 2016 as soon as possible. Mainstream support for Exchange 2016 will stop this October, but according to Microsoft you are still safe since Security Updates will be released when needed. There’s no direct need to upgrade to Exchange 2019 at this moment, but this is something you must consider the upcoming time. I do know customers however that only want products that are in mainstream support, so if you are in this boat you must move to Exchange 2019 of course.
  2. If you are running Exchange 2013, you must start moving to Exchange 2019 anytime soon for optimal support and skip Exchange 2016.
  3. If you are in an Exchange 2016 hybrid scenario and all your mailboxes are in Exchange Online, you are safe to stay in this situation until Microsoft releases a final solution for that dreaded last Exchange server on-premises for management purposes.
  4. If you are in Exchange 2016 hybrid and you still have mailboxes on-premises, you must move this to Exchange 2019 hybrid to stay in a supported configuration. Please keep in mind that Microsoft only supports the version n-1 in a hybrid scenario, which means automatically Exchange 2019 after this October.

 

 

New Exchange Online PowerShell v2

When using PowerShell with Exchange Online you can use the ‘good old traditional’ way to connect to Exchange Online:

$ExCred = Get-Credential 
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell/ -Credential $ExCred -Authentication Basic -AllowRedirection
Import-PSSession $Session

This is not a recommended way to connect to Exchange Online using your tenant admin account, it uses basic authentication (will be decommissioned in 2021) and MFA (number one prerequisite for tenant admin security!) is not possible.

The second option is the Exchange Online Remote PowerShell Module which you can download from the Exchange Online Admin Center (use Internet Explorer for this download!) as shown in the following screenshot:

Exchange Online PowerShell Module

This is a separate PowerShell module you can start and use the Connect-EXOPSSession command to connect to Exchange Online. This PowerShell module users Modern Authentication and supports Multi-Factor Authentication.

The latest (and newest) option is the Exchange Online PowerShell V2 module. This module works far more efficient with large datasets than the previous PowerShell modules for Exchange Online. It also supports Modern Authentication and Multi-Factor Authentication.

To install the Exchange Online PowerShell V2 module you first have to install the PowerShellGet module using the Install-Module PowershellGet command:

Install-Module PowershellGet

Followed by the Install-Module -Name ExchangeOnlineManagement command:

Install-Module ExchangeOnlineManagement

When installed you can use the Connect-ExchangeOnline command to connect to Exchange Online. When MFA for your admin account is configured it will automatically use it:

Connect-ExchangeOnline

The differences between V1 and V2 are clearly visible in the commands. All V2 commands contain EXO, like:

  • Get-Mailbox vs Get-EXOMailbox
  • Get-Recipient vs Get-EXORecipient
  • Get-MailboxStatistics vs Get-EXOMailboxStatistics
  • Get-CASMailbox vs Get-EXOCASMailbox

This means that all scripts you have written for use with Exchange Online need to be changed to reflect the V2 commands.

For a complete overview you can use the Get-Command *EXO* to retrieve all PowerShell commands that contain EXO (still very limited 🙂 ):

Get-Command EXO

The Exchange Online PowerShell V2 module is still in preview, the current version is 0.3582.0 which you can check using the Get-Module ExchangeOnlineManagement command:

Get-Module ExchangeOnlineManagement

The Exchange Online PowerShell v2 module is a work in progress, but it the future of PowerShell in Exchange Online, so you should keep an eye on this development.

More Information

Use the Exchange Online PowerShell V2 module – https://docs.microsoft.com/en-us/powershell/exchange/exchange-online/exchange-online-powershell-v2/exchange-online-powershell-v2?view=exchange-ps

Configure OAuth authentication in Exchange 2016

As long as I can remember the Hybrid Configuration Wizard finishes successfully, and itgenerates the error about the OAuth portion of the hybrid configuration.

Configure Intra-Organization Connector

HCW8064 – The HCW has completed, but was not able to perform the OAuth portion of your Hybrid configuration. If you need features that rely on OAuth, you can try running the HCW again or manually configure OAuth using these manual steps.

The Learn more option redirects to the Microsoft page Configure OAuth authentication between Exchange and Exchange Online organizations. I used that article for the PowerShell commands in this blogpost.

OAuth is used cross-premises to logon to other services, on behalf of the user. So, if you are logged on to some Microsoft service, this service can use OAuth to access services in Exchange on-premises and vice versa.

Example of these cross-premises services are:

  • Message Records Management (MRM).
  • Exchange in-place eDiscovery.
  • Exchange in-place Archiving.
  • Teams calendaring.

The HCW can configure Azure Active Directory for OAuth authentication, it can create the IntraOrganizationConnectors, but it cannot export and import the (self-signed) certificate on the Exchange server, nor can it (or does it) create the authorization server objects in Active Directory. So, time to test, guided by the Microsoft article and write down my experiences.

Note. This only works for Exchange 2013 and higher, I have been working on this in a mixed Exchange 2016 and Exchange 2019 environment.

Configuring OAuth between Office 365 and Exchange Online involve a number of steps.

Create Authorization server objects in Exchange on-premises

To create the authorization server objects in your on-premises environment enter the following commands in the Exchange Management Shell.

New-AuthServer -Name "WindowsAzureACS" -AuthMetadataUrl "https://accounts.accesscontrol.windows.net/contoso.com/metadata/json/1"
New-AuthServer -Name "evoSTS" -Type AzureAD -AuthMetadataUrl https://login.windows.net/contoso.com/federationmetadata/2007-06/federationmetadata.xml

Your verified domain contoso.com (in the command) should be something like exchangelabs.nl, and not <your tenant name> as outlined in the Microsoft article.

New-AuthServer

Enable the partner application for use with Exchange Online

The partner application was created in the previous step (the first command) and this should be enabled. Do this using the following command in Exchange Management Shell (on-premises):

Get-PartnerApplication | ?{$_.ApplicationIdentifier -eq "00000002-0000-0ff1-ce00-000000000000" -and $_.Realm -eq ""} | Set-PartnerApplication -Enabled $true

Export the Exchange authorization certificate

Authentication cross-premises is using certificates, so the on-premises certificate needs to be exported to Azure Active Directory. In case you were wondering where the CN=Microsoft Exchange Server Auth Certificate certificate was coming from when running the Get-ExchangeCertificate command in Exchange Management Shell, here you go.

Use the following PowerShell commands and store them in a PowerShell script called ExportAuthCert.ps1 or something and run it. This should export the OAuth certificate to a file called OAuthCert.cer.

$ThumbPrint = (Get-AuthConfig).CurrentCertificateThumbprint
If((Test-Path $ENV:SYSTEMDRIVE\OAuthConfig) -eq $false)
{
md $ENV:SYSTEMDRIVE\OAuthConfig
}
CD $ENV:SYSTEMDRIVE\OAuthConfig
$oAuthCert = (dir Cert:\LocalMachine\My) | ?{$_.ThumbPrint -Match $ThumbPrint}
$CertType = [System.Security.Cryptography.X509Certificates.X509ContentType]::Cert
$CertBytes = $oAuthCert.Export($CertType)
$CertFile = "$env:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
[System.IO.File]::WriteAllBytes($CertFile, $CertBytes)

ExportAuthCert

Note. The Export-ExchangeCertificate command doesn’t work in this scenario since the self-signed certificate isn’t exportable.

Import the Exchange authorization certificate into Azure AD

The next step is to import the OAuthCert.cer certificate into Azure AD. Connect to the Microsoft Online service (Connect-MSOLService, if you don’t have this installed you can use the Install-Module MSOnline command) and run the following commands when connected:

$Cred = Get-Credential
Connect-MSOLService -Credential $Cred
$CertFile = "$ENV:SYSTEMDRIVE\OAuthConfig\OAuthCert.cer"
$objFSO = New-Object -ComObject Scripting.FileSystemObject
$CertFile = $objFSO.GetAbsolutePathName($CertFile)
$CER = New-Object System.Security.Cryptography.X509Certificates.X509Certificate
$CER.Import($CertFile)
$binCert = $cer.GetRawCertData()
$CredValue = [System.Convert]::ToBase64String($binCert)
$ServiceName = "00000002-0000-0ff1-ce00-000000000000"
$P = Get-MsolServicePrincipal -ServicePrincipalName $ServiceName
New-MsolServicePrincipalCredential -AppPrincipalId $P.AppPrincipalId -Type asymmetric -Usage Verify -Value $credValue

This will import the self-signed certificate from the Exchange server into Azure AD so it can be used for mutual authentication.

I did not run the commands mentioned above on my Exchange server but on my Azure AD Connect server since the MSOL module was loaded on that server. For importing the certificate file I had to use the following command accessing the certificate file (instead of the $ENV:System variable):

$CertFile = "\\AMS-EXCH01\C$\OAuthConfig\OAuthCert.cer"

Register endpoints in Azure Active Directory

The last step is to register the endpoints of your on-premises Exchange environment into Azure Active Directory. You can use the following commands to register the endpoints:

$ServiceName = "00000002-0000-0ff1-ce00-000000000000";
$x = Get-MsolServicePrincipal -AppPrincipalId $ServiceName;
$x.ServicePrincipalnames.Add("https://webmail.exchangeserver.com/");
$x.ServicePrincipalnames.Add("https://autodiscover.exchangeserver.com/");
Set-MSOLServicePrincipal -AppPrincipalId $ServiceName -ServicePrincipalNames $x.ServicePrincipalNames;

Instead of webmail.exchangeserver.com and Autodiscover.exchangeserver.com you must use your own local FQDNs of the Exchange server (shown below in the verification screenshot).

You can use the the following command to check if this was configured correctly.

Get-MsolServicePrincipal -AppPrincipalId 00000002-0000-0ff1-ce00-000000000000 | select -ExpandProperty ServicePrincipalNames

As shown in the following screenshot:

Register Endpoints

Note. Over the years I have run the HCW several times. Domains have been added, but not (automatically) deleted in Azure Active Directory.

IntraOrganizationConnectors and AvailabilityAddressSpace

The Hybrid Configuration Wizard created the IntraOrganizationConnectors (both in Exchange 2016 as well as Exchange Online) and configured the AvailabilityAddressSpace. There’s no need to create these, but you have to check them using the Get-IntraOrganizationConnector and the Get-AvailabilityAddressSpace commands)

Verify the OAuth configuration

To verify the OAuth configuration you can use the Test-OAuthConnectivity command. You must do this on the on-premises Exchange server and in Exchange Online.

On the on-premises Exchange server use the Exchange Online Uri and a mailbox on-premises:

Test-OAuthConnectivity -Service EWS -TargetUri https://outlook.office365.com/ews/exchange.asmx -Mailbox onprem-user@exchangeserver.com -Verbose | Format-List

In Exchange Online, use the Exchange on-premises Uri with a mailbox in Exchange Online:

Test-OAuthConnectivity -Service EWS -TargetUri https://webmail.exchangeserver.com/metadata/json/1 -Mailbox Online-User@exchangeserver.com -Verbose | Format-List

The output is an extended list, but in the end you should see ResultType: Success and IsValid:True on your console:

Test-OAuthConnectivity

You have now configured the OAuth between Exchange Online and Exchange On-Premises.

 

Sender Domain Validation check in Exchange Online

In my previous blog External Senders with matching display names I explained a Transport Rule that checked for matching display names in order to prevent phishing and possible CFO Fraud.

Another interesting solution with Transport Rules is displaying a warning message when the sender’s domain could not be validated. For example, when a message from a sender who’s SPF record is missing or not valid, it would show something like “The sender of this message could not be validated and may not be the actual sender” as shown in the following screenshot.

In this example the SPF record of the exchangefun.nl domain was missing, hence the validation error.

  • The Transport Rule to achieve this is built on two conditions:
  • The sender is located outside the organization.

The Authentication-Results headers contains one or more of the following entries:

  • dkim=fail
  • spf=TempError
  • spf=PermError
  • spf=SoftFail
  • spf=Fail
  • spf=None

For the email mentioned below, the Authentication-Results header shows the following:

Authentication-Results: spf=none (sender IP is 176.62.196.243)
smtp.mailfrom=exchangefun.nl; wesselius.info; dkim=pass (signature was verified) header.d=Exchangefun.nl;wesselius.info; dmarc=permerror action=none header.from=exchangefun.nl;compauth=pass reason=105

Obviously, it fails on the spf=none entry.

To create a Transport Rule to do this, open the Exchange Online Admin Center and navigate to Rules under Mail Flow and click Add New Rule (the + icon). Use the More Options to add additional conditions to the Transport Rule.

The first condition is The sender is located and select outside the organization. The second condition is A message header includes and enter Authentication-Results for the name of the header and the DKIM and SPF entries mentioned earlier in the text of the message header. It should show something like this:

Click on Add Action and select Prepend a disclaimer. Enter a warning message like:

Warning: The sender of this message could not be validated and may not be the actual sender.

The text can be plain text or HTML formatted as shown in the following screenshot:

When you click Save the Transport Rule is saved in Exchange Online. It could take up to an hour to become effective. And when you receive a message where the domain validation failed a disclaimer is prepended to the email message:

Now you can look in the message header itself to figure out why validation failed. Hopefully this will give a heads-up to users there’s something wrong with the message (but it still can be legitimate message of course).

A special and warm thanks to my fellow MVP Michel de Rooij for his inspiration to write this blog 😉

 

External Senders with matching Display Names

One of my clients is experiencing phishing from where the external senders use a display name of one of the board members. An IT admin looks at the complete email address, but regular users are tempted to only look at the display name and will respond to the message. This way CEO/CFO fraud easily happens.

To avoid this, we can create a Transport Rule in Exchange Online that identifies external email with display names of internal recipients. So, when someone on the internet with a name like my name, a disclaimer is prepended to the message. This way recipients always know it is not an internal message and it will look something like this:

To create a transport rule there are two conditions:

  • Sender is located outside the organization.
  • From message header matches one or more internal display names.

If these conditions are met, a warning message is prepended to the email message.

Open the Exchange Admin Console and navigate to Rules under Mail flow. Create a new rule (use the More Options to add additional conditions. Select the external sender option and select the message headers matches option. Enter the ‘From’ header enter the display names as shown in the following screenshot:

In the Do the following… dropdown box select prepend the disclaimer option and enter a warning message, something like:

This message was sent from outside the company by someone with a display name matching a user in your organization. Please do not click links or open attachments unless you recognize the source of this email and know the content is safe.

You can use plain text or HTML formatting like I did:

When you click save the transport rule is saved, but it can take an hour before it becomes effective. When a new message arrives from someone with a similar display name a warning message is added to the email message.

Hopefully this will alert users that the email is not an internal message but comes from the Internet (but it can still be a valid message of course)