The version of the Client Access server selected is not supported

When running the Hybrid Configuration Wizard in an Exchange 2010 environment (I reproduced this with Exchange 2010, but didn’t try this with Exchange 2013 or Exchange 2016) the following error message is generated:

unsupported version

The version of the Client Access server selected, <ServerName>, is not supported. Please go back and select a server that is supported or upgrade the server to a supported version. If Exchange Server 2010, please install the wizard on the same machine.

Note. The HCW is not run on the Exchange 2010 since it requires .NET Framework 4.6.2 and this version of .NET Framework is not supported on Exchange 2010. Even worse, I’ve seen issues with Exchange 2010 after installing .NET Framework 4.6.2 so it’s a bad idea after all.

Running Exchange 2010 on a server with .NET Framework 4.5.x installed is fully supported, but the HCW won’t install on such an Exchange 2010 server since HCW depends on .NET Framework 4.6.2 and the following error message is generated:

unable to install or run this application

So, we are in a deadlock situation. HCW requires .NET Framework 4.6.2 which is not supported on the Exchange server, and when running the HCW on a non-Exchange 2010 server with the correct version of .NET Framework it fails with an error message.

We have been working with Microsoft CSS (product support) on this case. While it should be fixed in the HCW in the first place, under supervision of CSS the following workaround is available.

If you have HCW open and face this error, press F12 and a few other options appear as can be seen in the following screenshot:

HCW Error

If you click Open Logging Folder you get to the folder where the HCW Logs are stored. If you open the correct logfile and search for *ERROR* you can find something similar to:

server error

Obviously the HCW does an incorrect version check (at least when not running on the Exchange 2010 server itself) so it stops. Version checking is something that was built recently into the HCW so Microsoft can check for N-2 version of the implemented Exchange version.

Back to the error message, if you click Open Process Folder a new HCW command prompt is opened on the correct location:

HCW Prompt

Now when you start the Hybrid Configuration Wizard from the Command Prompt you can use the /dv switch (Microsoft.Online.CSE.Hybrid.App.exe /dv) and now the HCW will not do a version check and continue running and finish successfully.

Important note. This was done under the supervision of Microsoft CSS and should not be done by customers directly. If you are running into this issue, please contact Microsoft support to get the right support. Before you know things break beyond repair (and beyond support).

More information

Updated: December 6, 2018

 

Autodiscover in an Exchange interorg migration with Quest QMM

Outlook clients get their configuration information using the Autodiscover protocol from the Exchange server where their mailbox resides and the underlying Active Directory. This works fine, until you are in an interorg migration scenario using the Quest Migration Manager (QMM) for Exchange.

When using Microsoft tools (ADMT, Prepare-MoveRequest.ps1 and New-MoveRequest) the source Mailbox in Exchange is converted to a Mail-Enabled user at the moment of migration finalization. At the same moment the Mail-Enabled User property targetAddress is stamped with the SMTP address of the Mailbox in the new forest. SMTP works fine now, and also Autodiscover will follow the SMTP domain that’s in the targetAddress property. This is true for an interorg migration on-premises, but it is also true when moving Mailboxes from Exchange on-premises to Exchange Online in a hybrid scenario.

When using Quest tooling things are a bit different. The source Mailbox is not converted to a Mail-Enabled User, but it continues to exist at a regular Mailbox. The Outlook profile on the desktop is converted using the CPUU tool using local Autodiscover.xml files so that the Outlook client no longer connects to the old Mailbox but to the new Mailbox.

This works fine for the existing client, but when a user gets a new laptop, or has to configure the Outlook profile again, Outlook will use the Autodiscover process and thus connect to the old Mailbox. Since this isn’t converted to a Mail-Enabled User, Outlook will find the (old) Mailbox, it will stop searching (and thus will not follow the targetAddress property) and return the configuration information for the old Mailbox.

To fix this, we have to export the Autodiscover information from the new Exchange organization to the old organization. I found an old blogpost written by Andread Kapteina (Senior Consultant at Microsoft) in the Google cache (since his blogs no longer exist at the Microsoft Technet Site) about this scenario in an interorg Exchange 2007 to Exchange 2010 migration, but I found that it is also valid in an interorg Exchange 2013 to Exchange 2016 migration. And it should be valid in every interorg Exchange migration from Exchange 2007 and higher.

Export-AutodiscoverConfig

To export the Autodiscover configuration from the new Exchange 2016 to the old Exchange 2013 organization, execute the following commands on the Exchange 2016 server:

$OldCred = Get-Credential OldForest\administrator
Export-AutodiscoverConfig -DomainController <NewForestFQDN> -TargetForestDomainController <OldForestFQDN> -TargetForestCredential $OldCred -MultipleExchangeDeployments $true

The -MultiplExchangeDeployments options should be set to $true since both forests contain an Exchange organization.

The Exchange Management Shell does not report anything back, so no need to show it here 😊

When we look in the AD Configuration container we can now see two SCP records:

  • One record can be found under CN=Services, CN=Microsoft Exchange, CN=<Organization>, CN=Administrative Groups, CN=Exchange Adminstrative Groups (FYDIBOHF23SPDLT), CN=Servers, CN=<ServerName>, CN=Protocols, CN=Autodiscover, CN=<ServerName>. This will contain the regular SCP information that Outlook needs to connect to the existing Exchange organization to retrieve its information.
  • The second record can be found under CN=Services, CN=Microsoft Exchange Autodiscover, CN=<FQDN of new Forest>. This will contain information regarding the target (i.e. new Exchange 2016) forest that the Outlook needs for migrated Mailboxes.
    This second record can be seen in the following screenshot:

CN=Microsoft Exchange Autodiscover

The keywords property of the SCP record contains the Accepted Domains of the new Exchange 2016 organization, like Exchangefun.nl, Corporate.Exchangefun.nl and target.qmm (the Quest target domain). This means when a new Accepted Domain is added to Exchange 2016, the Export-AutodiscoverConfig command needs to be run again.

The serviceBindingInformation property contain an LDAP link to the Exchange 2016 forest where Outlook clients can find information from the migrated Mailboxes.

Granting permissions

To avoid issues with Outlook clients of not migrated Mailboxes (that need to retrieve information from the old Exchange 2013 organization) we have to hide the exported SCP for these users. At the same time, we have to hide the original SCP record in Exchange 2013 for Mailboxes that have been migrated to Exchange 2016 (and where Outlook should NEVER receive old Exchange 2013 information).

To achieve this, create a Universal Security Group with a name like “Migrated_Users”, remove the Authenticated Users group from the exported SCP and grant the Migrated_Users Security Group Read permissions on this object as shown in the following screen shot:

Remove Authenticated Users

At the same time we have to grant an explicit deny Read permission to the Migrated_Users Security Group on the original SCP record as shown in the following screenshot:

Explicit Deny

Summary

Now when a Mailbox is migrated using QMM and the CPUU tool, add the user to the Migrated_Users Security Group. At this moment its Outlook client will no longer find the original (Exchange 2013) SCP record but the exported SCP record. Outlook will then connect to the target Active Directory forest with Exchange 2016 and retrieve the correct information.

Note. It took us quite some time when testing this scenario with different versions of Outlook (2010, 2013 and 2016) but the scenario explained here turned out to be working fine with these versions. But please test in your own test environment with various clients as well.

More information

 

Your message couldn’t be delivered because you weren’t recognized as a valid sender

Today a customer ran into an interesting issue. A user was not able to send out email to external recipients (this was already the case for a couple of weeks) but internal email, both in Office 365 as well as hybrid Exchange 2010 did work fine.

The NDR that was returned to the user said:

Delivery has failed to these recipients or groups:
jaapwess@gmail.com
Your message couldn’t be delivered because you weren’t recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it’s no longer allowed to send messages outside of your organization. Contact your email admin for assistance.

delivery-has-failed

At first, the only I read was “Your message couldn’t be delivered because you weren’t recognized as a valid sender” so it took me some time to figure out what was wrong.
It’s not a permission issue (was my first thought) but Exchange Online Protection is blocking the account because of spam.

Even in a hybrid scenario with centralized mail transport this can happen, because Exchange Online outbound mail (to Exchange 2010 on-premises) is still handled by Exchange Online Protection.

To check the outbound spam and the user that is blocked, open the Exchange Online Admin Center, select protection in the navigation bar and click the action center tab. Here you can see the user account that is blocked, including the reason and date for blocking as shown in the following screenshot:

eac-protection-action

For this specific user:

Reason:
OutboundSpamLast24Hours=122;OutboundMailLast24Hours=128;OutboundSpamPercent=953;Last Message MessagetraceId:4495783e-13af-483c-b8d2-08d643c0f46c

Date:
11/6/2018 8:22 AM

So, it was already blocked for 9 days and 122 outbound spam messages were detected the last 24 hours.

I asked the local IT guys to go to this specific workstation, perform an ant-virus run to clean-up the workstation so I can unlock the account.

Update. Some items from the protection and/or compliance center are moving to the Security & Compliance Admin Center (https://protection.microsoft.com). You can find the restricted users (i.e. users that are blocked from sending outbound email) under Threat Mangement | Review and Restricted Users.

SSL Certificate warning during or after Exchange server setup

When installing a new Exchange server (2013/2016/2019) in an existing environment, Microsoft recommends installing this new Exchange server in a separate Active Directory site, configure the server there and then move the server to its production Active Directory site.

The reason for this is Outlook and the Service Connection Point (SCP) in Active Directory. Somewhere during the installation process a new SCP is created in Active Directory, but when created it is not configured and points to the FQDN of the Exchange server instead of the more general Autodiscover.contoso.com/Autodiscover/Autodiscover.xml URL. When an Outlook client accidentally discovers this unconfigured SCP it will try to connect to the new server instead of the Autodiscover FQDN which will result in a certificate warning message similar to the following:

image404

To avoid this, the SCP should be configured as soon as it is created in Active Directory (and this is during setup itself).

Tony Murray, also an MVP, has written a PowerShell script (Set-AutodiscoverSCPValue.ps1) that will check the existence of the Exchange server object in Active Directory, and when it is created by the Exchange setup application, it immediately sets the correct Autodiscover value in its SCP.

When you run the script it will check every 5 seconds (time is configurable) for the newly created server object, and when it finds it, it will set the correct value as shown in the following screenshot:

set-AutodiscoverSCPValue

From this moment on Outlook client can safely discover this SCP record, and it will be automatically connected to the correct Autodiscover URL and therefore the SSL Certificate warning will not appear (assuming the original servers are configured correctly of course).

More information and download – https://gallery.technet.microsoft.com/office/set-autodiscoverserviceinte-3930e163

Configuring message hygiene in Exchange Online Protection

In the previous three blogs I explained how to implement Exchange Online Protection for inbound and outbound mail flow, and how to configure SPF, DKIM and DMARC when using Exchange Online Protection. In this blog post I’ll go more into detail on the message hygiene processing itself.

For a correct understanding of Exchange Online Protection, it is good to have an overview of its internals. This is shown in the following figure, where the various steps in message hygiene processing are clearly visible:

EOP-Internals

By default, EOP does a great job for message hygiene, but it is possible to configure it for specific needs. It is possible to manually configure Connection Filtering (blacklisting and whitelisting), Anti-Mailware, Transport Rules and Content Filtering. I will discuss these in the following sections.

Connection Filtering

The first step in any message hygiene solution is connection filtering. Non-trustworthy mail servers are denied access based on their IP address, connection filtering filters out the majority of all malicious email.

It can happen that you want to allow a particular mail server to deliver mail to your environment, even when its IP address is lists on block lists or denied access for some other reason. To allow this, you can add the IP address to the IP allow list. Vice versa, if there’s a mail server that sends malicious email that’s not blocked by the connection filter, you can add this IP address manually to the IP block list.

To do this, logon to the Exchange Admin Center, select protection and click on the connection filter tab. Click the pencil icon to edit the default connection filter policy. Use the + icon to add IP addresses to the IP allow list or the IP block list. You can add individual IP addresses with a /32 mask, or you can add ranges with a /24 mask or smaller. A total of 1273 entries can be added, one entry can be either an IP address or a range of addresses.

If you add an IP address to both lists, the allow list takes precedence.

edit-spam-filter-policy

Optionally you can select Enable safe lists. Microsoft subscribes to safe lists on the internet, publishing lists of IP addresses that are treated as safe. Using the safe lists you make sure that trusted senders are not treated as malicious senders, so it’s recommended to use the safe lists option.

Anti-Malware

The anti-malware policy in Exchange Online Protection is enabled by default, it can be viewed and edited by an Exchange administrator, but it cannot be deleted.

In the anti-malware policy, you can define the attachment filtering, detection response, internal and external notification, administrator notifications and you can customize notifications.

To access the default anti-malware policy, logon to the Exchange Admin Center, select protection in the navigation menu and click on the malware tab. Use the pencil icon to view or edit the default anti-malware policy, use the + icon to add a new malware policy. When you open a malware policy, click on settings and edit the settings according to your needs. This is shown in the following screenshot (click to enlarge):

anti-malware-policy

Click Save to store the new settings in Exchange Online Protection and activate them.

Mail flow rules

Mail flow rules, sometimes referred to as Transport Rules are rules in Exchange Online Protection that can take action on a message, based on certain criteria. Mail flow rules in Exchange Online Protection are similar to Transport Rules in Exchange server on-premises, and also similar to rules that you created in Outlook or OWA. Major difference is that Mail Flow rules work on messages in transit, while rules in Outlook only work on messages already delivered to the Mailbox.

Using Mail flow rules it is possible to apply disclaimers, to bypass spam filtering (useful for an abuse mailbox for example), modify messages, check for sensitive information etc. as shown in the following screenshot (click to enlarge):

several-rules

To add a disclaimer to outbound messages select Apply disclaimers… and follow the wizard. Give the disclaimer an easy name like Disclaimer (Outbound Only), select the sender is located and select Inside the organization and click on Enter Text to add the disclaimer text.

I’ve used the following text in the disclaimer:

This e-mail may contain confidential and privileged material. You are requested not to disclose, copy or distribute any information thereof. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. We accept no liability for damage related to data and/or documents which are communicated by electronic mail.

To prevent a ton of identical disclaimers to email messages that are sent back and forth I’ve included an exception to the disclaimer. Wen the mail flow rule detects the string “This e-mail may contain confidential and privileged material” the disclaimer won’t be added again.

This is shown in the following screenshot (click to enlarge):

outbound-disclaimer

Click Save to store the mail flow rule. Send an email from an Exchange mailbox to an external recipient and you’ll see the disclaimer is added as shown in the following screenshot (click to enlarge):

disclaimer-added

Note. The remaining signature text in the screenshot above is set by Outlook on the Web directly from the Mailbox.

There are multiple options for using mail flow rules in Exchange Online Protection, but most of them are company specific, and targeted towards compliance management.

Spam Filtering

Like any other message hygiene solution, Exchange Online Protection filters out spam messages. Using machine learning in Office 365 and the billions of messages that are processed each day it does a pretty good job.

By default, email messages that are identified are sent to the user’s junk mail folder. It does this based on an X-header that is added by Exchange Online Protection called X-Forefront-Antispam-Report. When this X-header contains the value SFV:SPM it is identified as spam.

x-forefront-antispam-report

The Exchange server then knows it’s a spam message and will store the message in the user’s junk mail folder. However, this works fine in a hybrid environment since both parties trust each other, when using EOP in front of an Exchange on-premises environment this is not the case. To achieve the same results, two transport rules need to be created on the Exchange on-premises environment to process these messages accordingly.

To create these transport rules in your on-premises Exchange environment run the following three commands in Exchange Management Shell:

New-TransportRule EOPJunkContentFilteredMail -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SPM" -SetSCL 6
New-TransportRule EOPJunkMailBeforeReachingContentFilter -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKS" -SetSCL 6
New-TransportRule EOPJunkMailInSenderBlockList -HeaderContainsMessageHeader "X-Forefront-Antispam-Report" -HeaderContainsWords "SFV:SKB" -SetSCL 6

When the transport rules are created, spam messages will be delivered into the junk mail folder.

How to test spam processing? Just like an Eicar ‘virus’ that you can use to test your anti-virus solution there’s a test spam message called GTube. GTube is a text string you can add to your email message, and mail servers will detect this string and mark it as spam. The GTube string is:

XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UBE-TEST-EMAIL*C.34X

After adding this string to an email message from Gmail to Exchange, EOP will mark it as spam, very useful.

So, Exchange Online Protection and Exchange will store spam messages in the user junk mail folder. It is also possible to store these messages in quarantine.
To enable the Quarantine option, logon to the Exchange Online Protection Admin Center, select protection in the navigation menu and click the spam filter tab. Use the pencil icon to open the default spam filter policy. In the spam and bulk action options select Quarantine message under the spam and high confidence spam drop-down box as shown in the following screenshot (click to enlarge):

spam-and-bulk-actions

This is an organization wide quarantine environment that’s available only to the tenant administrator. Logon to the Office 365 portal and select Security and Compliance under Admin centers. It is also possible to navigate directly to the Security and Compliance admin center via https://protection.microsoft.com. You’ll find the Quarantine under Threat Management and Review. By default, quarantined message will be kept for 15 days before they are deleted. This can be extended under the spam and bulk actions of the spam filter policy.

Quarantine

It is also possible to create a mailbox-based quarantine. Select the protection navigation option and click the spam filter tab. In the action pane on the right, scroll down and click the Configure end-user spam notifications option. In the pop-up box, check the enable end-user spam notifications checkbox, change the number of days (default is 3) a notification should be sent and the (default) language as shown in the following screenshot (click to enlarge):

end-user-notifications

When a user has messages in his quarantine a notification message is delivered to the mailbox with the quarantined messages. The messages can be released to the inbox and can be reported as not junk mail to Exchange Online Protection as shown in the following screenshot (click to enlarge):

quarantine-message

This way the users themselves can determine which messages are delivered to their inbox and which are not.

Blocked and Allowed Senders

It is possible to block or allow senders, this can be achieved on individual email addresses or on SMTP domains. To block or allow senders, in the Exchange Online Protection Admin Center select protection in the navigation menu and click the spam filter tab. Use the pencil icon to open the default spam filter policy and select block lists or allow lists. Here you can enter the email addresses or domains that should be blocked or allowed.

Summary

Exchange Online Protection is Microsoft’s cloud solution for message hygiene. It is automatically used in combination with any Office 365 subscription, but it can also be used in combination with an on-premises Exchange implementation or any other messaging environment.

In the first two blogs I showed you how to enable inbound and outbound message flow, in the third blog I showed you how to configure SPF, DKIM and DMARC to setup a secure message flow solution. When implemented correctly, the recipient’s mail server can validate the email messages and can identify which messages are spoofed and which are not (on behalf of your domain).

In this last blog post I showed you how to configure the message hygiene solution, how to fine-tune connection filtering, anti-malware settings, implement mail flow rules and how to configure quarantine on an individual user level.

Microsoft UC Specialist