Exchange Server

Microsoft Exchange Server

Exchange Server

Microsoft Exchange Server Attacks: Investigation Underway into Potential Leaked PoC Code


Microsoft is investigating the possibility a partner leak may have made the ongoing Microsoft Exchange Server attacks worse. The company says it has observed no internal leaks and is drawing no conclusions about a third-party leak. However, The Wall Street Journal reports an investigation into the potential for a partner leak is ongoing.

Microsoft Exchange Server is in the midst of an attack through an exploit first used by the HAFNIUM group. More threat groups have since targeted the exploit. Microsoft has sent out patches for all versions of the service, including those out of support.

Microsoft says updating Exchange Server is the best way to avoid the exploit. Furthermore, the company has launched a tool to help customers know if they have been breached.

Now the company is said to be investigating if “sensitive information” came from “private disclosures it made with some of its security partners.”

PoC Blunder?

Microsoft is looking to see if the proof-of-concept (PoC) code for the exploit was sent privately between the company and partners of its Microsoft Active Protections Program (Mapp) was leaked. Speaking to ZDNet, the company says it does not believe the leak was internal:

“We are looking at what might have caused the spike of malicious activity and have not yet drawn any conclusions. We have seen no indications of a leak from Microsoft related to this attack.”

Microsoft did send the PoC code to cybersecurity partners on February 23, which was before any patch was released. This was to give those researchers time to detail the exploit. Microsoft says the ongoing attacks bear a resemblance to the internal PoC.

The company is now investigating if a leak happened, how it happened, and whether it was on purpose.

Tip of the day:

Did you know you can use Windows 10´s built in antivirus Microsoft Defender also with scheduled scans? In our tutorial we give you step-by-step instructions on how to program your personal scan-schedule to keep your free of malware.

Source Vanguard

read more
Exchange Server

Old Microsoft Exchange Server Versions Get Patch to Protect Against Ongoing Exploits


The attacks on Microsoft Exchange Server are currently a fluid situation. To help organizations protect themselves from exploits, Microsoft has now issued patches for versions of Exchange Server that are unsupported.

This round of patches follows fixes rolled out for the company for supported versions. Those already with patches are Exchange Server 2013, Exchange Server 2016, and Exchange Server 2019. With the latest round of security fixes, Microsoft is shoring up earlier Exchange versions.

These are versions of the service that had fallen out of support for being too old. That’s a rare move for Microsoft but the gravity of the situation is clear with over 30,000 organizations compromised by the attacks.

By using remote back access attacks against Microsoft Exchange Server, threat actors can access email accounts. 30,000 organizations have already been impacted by the vulnerability. All the critical vulnerabilities are found in Exchange Server 2019, 2016, and 2013. Only Exchange Online has escaped the flaw.

The vulnerabilities are as follows:

  • CVE-2021-26855: CVSS 9.1
  • CVE-2021-26857: CVSS 7.8
  • CVE-2021-26858: CVSS 7.8
  • CVE-2021-27065: CVSS 7.8


Earlier today, we reported the Biden administration has set up a taskforce to monitor the attacks. Microsoft says updating Exchange Server is the best way to avoid the exploit. Furthermore, the company has launched a tool to help customers know if they have been breached.

Security researcher Krebs on Security (Christopher Krebs) says more than 30,000 companies in the U.S. alone have been hit by the attack. He adds most of these organizations are small businesses and governments:

“If your organization runs an [Outlook Web Access] server exposed to the internet, assume compromise between [February 26 and March 3].”

Tip of the day:

If your PC keeps connecting to the wrong WiFi network, you can set WiFi priority to avoid the need to manually select access points over and over again.

Source Winbuzzer

read more
Exchange Server

Switching off legacy authentication for Exchange Online


Keeping legacy authentication enabled in your Microsoft 365 tenant should be avoided; however, going ahead and disabling has traditionally been difficult. Unless you already have a good understanding of your clients, it may present a risk.

Recent improvements to Exchange Online make this simple to configure, and you can now retrieve the information you need to identify potential clients that might be affected.

In this article, we will walk through the process to identify clients using legacy authentication, then utilize the new functionality available to Exchange Online to disable legacy auth for selected protocols.

Reviewing legacy sign-ins to Exchange Online

Before disabling legacy authentication for Exchange Online, it is essential to ensure that clients won’t be affected or prevented from signing in, or if they will, gather enough information so that you can inform people who will be impacted.

You can do this in the Azure Active Directory portal by reviewing sign-in logs using dedicated capabilities to filter based on legacy authentication. To do this, navigate to the Azure AD portal and then select Sign-ins under Monitoring.

Learn more: Introducing Certificate-Based Authentication for Exchange Online Remote PowerShell with Microsoft MVP Vasil Michev

In this section, you will see all sign-in attempts to Azure AD, including sign-in to all Microsoft 365 services from all your clients. We’ll first make sure the information we need is clearly displayed by adjusting the columns displayed by adding client app, as shown below:

client app

Next, we’ll use Add filters to add a filter based on client app:

add filters

The filter for client app will allow us to reduce the list shown to only relevant clients. To do this, expand the filter and from the drop-down list only select the protocols listed under Legacy authentication clients:

Legacy authentication clients

This list is likely to show us both successful and unsuccessful sign-ins. Whilst unsuccessful sign-ins are a concern; we will focus on successful sign-ins to gain insight into what should be real sign-ins from our users. We’ll do this by using Add filters to add a filter based on Status:


We’ll then change the filter for Status to only show results that are a Success:

Status: success

You will then see what may be a long list of sign-ins from legacy authentication clients to Exchange Online. You can expand this using the Date filter to up to one month to gain more insights and use Download to export a list for review.

In the example below, we can see that many users widely use exchange Activesync. Therefore before disabling this protocol, we’ll need to move them to a modern-authentication capable client such as the Outlook App.

Learn more: How to Migrate Exchange Mailbox Permissions with Mike Weaver

If you examine the list and want to understand which legacy authentication protocols are not in active use and can be immediately disabled, then re-open the Client app filter and unselect protocols shown in your results. By unselecting Exchange Activesync, we will be able to see other protocols in active use then easily:

Exchange ActiveSync

We will repeat the process by removing other protocols in active usage until no results are shown. In the example below, we have discovered quickly that only Activesync and Exchange Web Services are in use, and there are no sign-ins over the last month from any other clients.

Exchange ActiveSync and Exchange Web Services

Selectively switching off legacy authentication

After discovering which protocols are not in active use, we are in a position where it becomes low-risk to disable legacy authentication.

Instead of using Exchange Online PowerShell, we can now use the Microsoft 365 admin center to disable legacy authentication for Exchange Online on a protocol-by-protocol basis affecting all users. To do this, navigate to Settings>Org Settings and choose Modern authentication from the services list. In the Modern authentication page, we’ll disable the legacy protocols no longer in use:

Modern authentication

You’ll note in the example above; we’ve disabled legacy authentication for IMAP4, POP3, Exchange Online PowerShell, and Autodiscover. For Exchange Online Powershell, this means you must use either the V2 module or the deprecated V1 module that supports MFA. By disabling legacy authentication to Autodiscover, we will prevent additional legacy clients from attempting to discover Exchange Online information.

Because we know legacy Activesync is in use in our organization and there is a small amount of active legacy Exchange Web Services usage, we’ll leave these protocols enabled.

Once we are happy with the settings, we’ll choose Save to apply these to all Exchange Online clients.

Disabling Legacy Authentication for all Exchange Online services

Using our sign-in log information, we will upgrade or reconfigure discovered clients to use modern authentication. After re-running the steps to filter Azure AD sign-ins and confirming we no longer have any active usage of legacy authentication, we’ll re-visit the Microsoft 365 admin center and disable legacy authentication for all Exchange Online protocols:

Modern authentication options

Further improving security for Microsoft 365 and Exchange Online

Disabling legacy authentication to Exchange Online isn’t the panacea of Microsoft 365 security – it is just one step towards helping keep the environment secure from particular threats, like password spray attacks.

Suppose you have Microsoft 365 E3, Microsoft 365 Business Premium, EMS E3, or Azure AD Premium licenses. In that case, you should consider configuring Conditional Access in your environment to selectively enable Azure Multi-Factor Authentication or configure rules to only allow access to your environment from Intune enrolled devices, Hybrid Azure AD domain-joined PC – or other criteria, such as IP address.

However, suppose you don’t have Conditional Access available. In that case, you may want to consider using Azure AD Security Defaults or (if you need it on a per-user basis) Office 365 multi-factor authentication. Azure AD Security Defaults is particularly useful if you wish to have a guided process over 14 days rather than immediately. It also provides additional MFA protection to privileged administrative actions in your tenant.

Source Practical365

read more
Exchange Server

Exchange Retention and Communication Compliance Updates


While we are eagerly awaiting the usual storm of announcements during Ignite week, some minor but essential releases have been completed over the past few weeks. So, let’s spend the next few minutes covering them in some detail.

Exchange Online support for “when labeled” retention

First, let’s briefly talk about the feature announced as part of Message Center post MC216379, namely the fact that Exchange Online now supports retention based on the date the label was stamped on an item.

Traditionally, Exchange’s retention policies have always acted based on the date the item was created or received, with some exceptions as detailed in the official documentation. When Office 365 introduced the new-style retention labels/policies, they offered some novel options, such as the ability to calculate the retention age based on the date the item was last modified or the label was stamped on it. A more advanced option that allowed organizations to configure event-based retention was released later on. Up until now, however, Exchange Online only supported the “traditional” when created approach.

In June, Microsoft announced that they’ve started rolling out an update through the service to allow this additional retention option to work against items stored in Exchange Online mailboxes. To make this possible, the Managed Folder Assistant has been patched to process items with the “stamp date” in mind.

Therefore, admins need to complete no additional actions to enable this functionality. However, you can verify that it’s working as expected by creating a retention label with the when it was labeled setting, then check whether the corresponding items are retained or deleted within the expected timeframe, based on the date the label was stamped on them. Don’t forget that the MFA in Exchange Online runs on a seven-day work cycle, so you can expect some delay here.

So how do we go about checking this new functionality? First, head over to the Security and Compliance Center or the new Compliance Center and create a retention label when it was labeled option configured, as shown on the screenshot below.

Next, publish the policy to some or all mailboxes and wait for the complete distribution process. Then you have to wait some more for Exchange’s Managed Folder Assistant to reprocess the mailbox and make the new labels/tags available. As those are “new style” retention tags, you will not find them under OWA -> Options -> Mail -> Retention policies. Nevertheless, they will become available once the mailbox has been processed.

Exchange when applied

When this happens, you will see the newly created Exchange when applied tag available in the right-click menu in OWA and/or Outlook. All you need to do then is to assign the tag to some item and wait for it to be processed. Since we want to test the when it was labeled setting, it makes sense to tag an older item with it, such for which the when created scenario would cause the item to expire immediately. If the new label works as expected, the item should remain available for three days after being tagged, give or take. Of course, you can also tag some other items to use as a control group. In my scenario, three different items were stamped with the Exchange when applied tag/label, one received (created) a minute ago, one created a week ago, and one even older.

Even though I’m running a somewhat older version of Outlook (semi-annual targeted channel, so version 2002 at the time of writing this post), the new label and corresponding expiration period are displayed correctly in the client, as shown on the screenshot below (left-hand side). OWA might not reflect the expiry date correctly initially (right-hand side). Even though the correct label information is displayed on the info tip (top of the message screen), the expiration date is shown as Never, which should not be the case given the label is configured with three-day retention period. After a relog or two, the correct date is eventually displayed.

As expected, after the retention period has expired, the three tagged messages were deleted and are currently residing in the RecoverableItems subtree (see screenshot below). The items were received (created) at different times, so their “creation” dates differ, and if we were using the old-style labels/tags, they would have been removed at different times. Since the newly created label is configured with the “when labeled” setting though, and all items were stamped at the same time, they were all processed at the same time too, which is precisely the behavior we would expect.

In a nutshell, this is how the recently introduced new option for retention labels work in Exchange Online. While this might seem like a minor change and very straightforward to implement, the important thing to note here is that Microsoft is bridging the gap between how different workloads handle retention labels, and we are now one step closer to a truly “unified” retention experience.

New Communication Compliance features

The other exciting news we’ll cover is around a few recent releases, either as previews or in GA, within the Communication compliance feature set. Let’s start with the newly introduced granular roles. Back when the Communication Compliance solution was intially launched, granting access to it was a somewhat convoluted process, as it required access to multiple different roles, which at the time were not combined into any of the default Role Groups. Microsoft has addressed this as part of Roadmap item #61068, which just finished rolling out across the service.

While we’d expect the new roles (and role groups) to be available from within the Compliance Center, where the Communication Compliance solution lives, this is not the case. Even two years after the launch of the new standalone Compliance and Security portals, the experience within those remains very limited when it comes to managing permissions, so for any permission-related tasks, you should head to the good old Security and Compliance Center.

On-Demand Webinar: Introducing Certificate-Based for Exchange Online PowerShell

Once there, you will find a total of five Role Groups related to Communication Compliance, as showcased on the screenshot below. Each of these Role Groups contains one or more Roles, correlating to the different tasks you can perform as part of the feature, with the Communication Compliance Role Group having the widest set of permissions assigned.

The set of individual roles are depicted below. Exploring them via PowerShell has the added benefit of surfacing their descriptions, which the devs have neglected to expose in the UI. Apart from the roles shown below, the Data Classification Feedback Provider role, used to provide feedback to the trainable classifiers, is added as part of the Communication Compliance Admins (shown only as Communication Compliance in the UI) Role Group.

Thanks to the new granular roles, we now have an easier separation between investigators (who can see the full message content), analysts (can only see metadata), viewers (access to reports only) and so on. You can find additional notes about the new roles and recommendations of which role to use to find scenarios in the official documentation.

Apart from the role improvements mentioned above, we now can anonymize user names within policy matches. You can toggle the corresponding setting by navigating to the Communication Compliance tab, hitting the Communication Compliance settings button on top, and landing on the Privacy page. The configuration itself is self-explanatory, as shown below:

Another recently launched improvement is the ability to detect repeated behavior over time, as detailed in Roadmap item #61067. Yet another useful feature is the ability to detect adult, racy and gory content as part of images exchanged between participants (Roadmap item #64189). Some caveats apply: the image must be between 50KB and 4MB in size, its dimensions must be greater than 50×50 pixels, and must be either a JPEG, GIF, BMP or PNG format.

The last feature we want to mention is the ability to Remove Teams messages (Roadmap item #66100) and replace them with a generic policy tip, indicating a violation. This functionality applies to Teams chats and channel messages, including those sent to private channels.

So how about testing all these? After updating my policies to include the new adult/racy/gory classifiers, I added some NSFW content in private chat and a team. The good news is that two out of the three images I inserted were flagged as violations, which is a good outcome, considering I didn’t bother to check whether they are within the accepted ranges for size/dimensions. The bad news is that the review experience currently has some issues and makes it impossible to see what content the  message was flagged for.

Not only the built-in viewer failed to display the images, but downloading the original resulted in only getting a zip file with a single summary.txt item, which contains just the below error:

Doc_Num              Doc_ID   Custodian              SubjectOrTitle       File_Name             File_Type               Error_Message

1              9543875d71744ef4a42f2cc609ff466dd0dbff433771a0b39eaffb08569076e9                      0-weu-d1-ea6ae215cd9093dabf2e5fd6e6d1c9f4.jpg                    jpg          The remote server returned an error: (404) Not Found.

This issue seems to be around the review UI, opening the underlying Supervisory mailbox in OWA, and reviewing the content there works as expected. Hopefully, the observed behavior was a temporary fluke or the result of an incomplete feature rollout.

On the positive side, the user was flagged immediately as a repeat offender, and the Remove messages from Teams functionality executed immediately and flawlessly. The screenshot below shows the experience of removing the messages via the Review UI and what the end user sees within the Teams client.

In summary, we’ve received some useful improvements to the Communication Compliance solution, both in terms of making sure the right people can see just the correct data and the overall review experience.

Source Practical365

read more
Exchange Server

Microsoft Authenticator on Android Finally Gets Ability to Change Passwords


Microsoft Authenticator for Android is receiving an update to add a much-requested new feature to the tool. Specifically, users can now change their passwords directly in the application. Android users have been waiting a long time for this ability.

Microsoft brought the feature to its Authenticator app on iOS earlier this year. At the time, the company promised it would also come to the Android variant. After a longer than expected delay, the feature is available.

For users who leverage two-factor authentication (2FA) on Microsoft 365, this is a welcome addition. When using the Microsoft Authenticator app, more information about accounts is visible. For example, the phone sing-in tool is shown. This is a one-time password issued by Microsoft. The cost can be used for a single authentication.

Also directly in the app, users can now update security information for accounts, including change the password.

“As part of our commitment to continually improve our customer experiences, we revamped the UX of how accounts are represented in the Microsoft Authenticator app. We heard from customers that staying informed about your account security should be simple and seamless, and we’ve been listening,” the company explained in March.

Available Now

Microsoft launched its Authenticator app back in 2016. The service provides native two-factor authentication on devices when accessing a Microsoft Account. Since the launch, numerous features have been added, including a phone sign-in ability, fingerprint support, password free login, and Apple Watch support.

To use the new password feature, users must be running the latest version of Microsoft Authenticator. If you’re new to the app, you can download if from the Google Play Store here.

Source Winbuzzer

read more
Exchange Server

Windows 10: How to Uninstall the Microsoft Store (aka Windows Store)


Windows 10 ships with plenty of universal apps, which are native to the platform. Some users may not need Universal Windows Platform (UWP) apps and want to remove them. We already showed you how to remove unwanted bloatware apps on Windows. However, what if you want to remove the Windows Store entirely? In this guide we will show you how uninstall Windows 10 apps using PowerShell.

While Microsoft’s Windows 10 native apps are not bloatware in the strictest sense, they are often pre-installed, and some users don’t want them. Luckily, Microsoft allows you to remove Windows 10 Bloatware easily.  If you want to remove the Microsoft Store, it’s not quite as simple.

Microsoft obviously doesn’t want Windows 10 users removing its app store. As such, this app can’t be removed completely, but you can hide it by using PowerShell. The method also works to block Windows Store apps.

It is worth noting that the Windows Store is called the Microsoft Store these days, although the rebranding is unimportant to functionality. The store remains ingrained in Windows 10 and you can use it to download UWP apps.

The Microsoft Store is primarily used to manage the relatively new “Universal Windows Platform Apps” (UWP apps). Similar to the Apple App Store or the Google Play Store for Android, you can add free and commercial apps to Windows at the push of a button.

However, many users prefer the traditional method of downloading desktop applications and don’t use the Store. If you are one of those users, we will show you how to uninstall Windows 10s app store. We will also explain how to reinstall the Windows Store whenever you want.

How to Remove the Microsoft Store app in Windows 10

First you open the PowerShell as administrator via the Start context menu that can be reached with the key combination “Windows + X“.

Windows 10 - Run Windows PowerShell as Admin
Windows 10 – Run Windows PowerShell as Admin

Then enter the following command in the PowerShell window, which will automatically uninstall the Microsoft Store app:

Windows 10 - PowerShell - Uninstall Microsoft Store
Windows 10 – PowerShell – Uninstall Microsoft Store

Reinstall Windows Store and other pre-installed apps

To restore the Microsoft Store if necessary, the following command in the PowerShell is sufficient:

Get-AppxPackage-AllUsers|Foreach{Add-AppxPackage-DisableDevelopmentMode-Register“$($ _. InstallLocation)\AppXManifest.xml”}

In addition to the store app, this also brings back all other pre-installed Windows 10 apps. You can then easily uninstall other unwanted apps with a click of the mouse.

Windows 10 - PowerShell - Restore Preinstalled Apps
Windows 10 – PowerShell – Restore Preinstalled Apps

Source Winbuzzer

read more
Exchange Server

Microsoft Edge 81 Launches on Stable Channel, Bringing Collections to All


After a short Covid-19 related delay, Microsoft Edge 81 is available on the stable channel. The update holds features an improvements the beta channel has been testing since February, with Collections the stand out addition.

For the unfamiliar, Collections is essentially Microsoft’s answer to extensions like Pocket. You can drag and drop any text, page, or image into an organized sidebar, while also adding supplementary notes. Once finished, you access it through the browser or export it to Word or Excel and get working. They sync across all devices so you can access an online shopping list on your phone when you’re out and about, for example.

The idea is for Collections to appeal to just about anyone, but if you don’t the icon in your browser bar Microsoft has introduced the ability to hide it with this build. It has also rolled out a host of improvements to the browser, with the most interesting listed below:

  • “Application Guard. Extensions support now available in the container.
  • The F12 Dev tools are localized in 10 new languages, so they will match the language used in the rest of the browser.
  • Added support for Dolby Vision playback. On Dolby Vision-enabled Windows 10 Build 17134 (April 2018 Update), websites can show Dolby vision content.
  • Microsoft Edge can now identify and remove duplicate favorites and merge folders with the same name. To access the tool, click the star on the browser’s toolbar and select “Remove duplicate favorites”. You can that confirm changes and any updates to your favorites will be synced across devices.
  • The new solid InPrivate blue pill in the top right corner helps reassure users they are browsing InPrivate.
  • Open external links in the correct browser profile. Select a default profile for links opened for external apps to open in from edge://settings/multiProfileSettings.
  • Added a warning that alerts users who sign into a browser profile with an account after being previously signed in with another account. This warning will help prevent unintentional data merging.
  • If you have payment cards saved in your Microsoft account, you can use them in Microsoft Edge while filling out payment forms. The cards in your Microsoft account will sync across desktop devices and the full details will be shared with the website after two-factor authentication (CVC code and your Microsoft identity.) For further convenience, you can choose to securely save a copy of the card on the device during authentication.
  • Line Focus is designed for users who like to focus on a limited part of the content as they read. It lets users keep the focus on one, three, or five lines at a time and dims out the rest of the page to let users read without distraction. Users can scroll using touch or arrow keys and the focus shifts accordingly.
  • Microsoft Edge is now integrated with Windows Speller on Windows platforms 8.1 and above. This integration provides greater language support, with access to more language dictionaries and the ability to use Windows custom dictionaries.
  • When PDF documents are opened using Microsoft Edge, users will now be able to create highlights, change color, and delete highlights.”

Considering the global pandemic, there’s a lot to be enjoyed here. The improvements touch most major aspects and bring back some Edge HMTL favorites like extended PDF support. You can read the full list of additions in the official documentation.

Source Winbuzzer

read more
Exchange Server

How to licence Exchange Hybrid servers


As part of your Exchange Hybrid deployment you might introduce new Exchange Servers into your organization. If you’ve planned your deployment correctly, then these will be covered by Hybrid Exchange licences included within your Office 365 Enterprise subscription.

When you don’t need a Hybrid licence

First and foremost, you must consult Microsoft or your licensing specialist for correct guidance for whether you are licensed correctly. However, there is as a key scenario where you will not need to acquire Exchange Hybrid licences.

If you are running Exchange Server 2010, 2013, 2016 or 2019 then you already have Exchange Hybrid capabilities built in to your Exchange Servers today.

Your Client Access services will be used for Autodiscover services and Exchange Web Services based communications. This includes redirecting clients to the cloud, Federated Sharing for Free/Busy and Mailbox Moves. Your Hub Transport services also have the capability built-in to manage Hybrid mail flow between Office 365 and your Exchange Server.

Adding additional servers to your organization to support Exchange Hybrid is a common piece of bad advice shared regularly. If you have a healthy Exchange 2010+ organization today, then you almost certainly have everything you need and will not need to licence Hybrid Servers.

When you do need a Hybrid licence

If you are running Exchange Server 2003 or 2007 you will need to add Exchange 2010 or 2013 servers if you want to perform a Hybrid migration. As those servers don’t have any Hybrid components built-in, then for many organizations it means a part-migration to a newer version of Exchange Server. Typically, this means implementing co-existence with the newer version, and migrating some client-facing services across, such as Autodiscover, Exchange Web Services, ActiveSync and Outlook Anywhere.

It’s important to note that when you add Exchange Hybrid servers to your Exchange 2003/2007 organization you cannot move any mailboxes to the servers if you wish to qualify for a “free” Exchange Hybrid licence. That means you can’t (for example) stage mailboxes from Exchange 2003 to Exchange 2010 first, before moving them to Office 365.

Another key scenario where you are likely to need a Hybrid licence is after you have completed your migration from Exchange Server 2010 to Office 365. After moving your final mailboxes and if you have them, Public Folders, you will decommission Exchange Server 2010. Most organizations will keep Azure AD Connect in place after the migration completes, which means Hybrid Identity (where AD remains the master) is in place. You will therefore require require Exchange Server to manage those attributes – and potentially to relay SMTP email, too. This of course is a great use of an Exchange 2016 or higher server.

Finally – and it comes as a surprise to some organizations – if you have never had Exchange within the organization then you might need to install Exchange Hybrid servers for attribute management within the local AD. As mentioned above – if you use Azure AD Connect, you will have Hybrid identity in place. Many organizations running Domino today and migrating to Office 365 find they need to install an Exchange Hybrid server (or two) and utilize the free Hybrid licence.

Acquiring Exchange Hybrid licences

The process to acquire an Exchange Hybrid licence has recently changed. Previously, you would request Exchange Hybrid licences from the Office 365 portal. This of course, made it easy to request the licences you needed in advance in the same way you licenced Exchange Servers traditionally within your organization.

If you are licensing new Exchange Servers for Hybrid today, the process has changed. You will now licence new Exchange Hybrid servers within the Office 365 Hybrid Wizard.

When you run the Wizard, you will be able to choose the option Licence this server now to apply the Exchange Hybrid licence:

After choosing to licence the server, you’ll be provided with the option to copy product key if you need to apply the Hybrid licence key manually (for example, using the Exchange Admin Center, or PowerShell).

read more
Exchange 2016Exchange Server

How to use Mail Contact object to enable outgoing SMTP relay

download (1)

Consider the following scenario – you have a need to deliver email to and from an application server that receives email via SMTP. You want to use Exchange Online Protection, the SMTP domain of the application server can send email via SMTP, however it isn’t routable or contactable via the internet, and therefore can’t receive replies to messages sent. Your organization’s email is setup in a Hybrid configuration with on-premises Exchange Server, which is configured to allow your application servers to relay email outbound via Office 365.

One way to allow your application server to receive email from the internetvia Exchange Online is by using a Mail Contact object. This will accept email to Exchange Online, and then relay the mail back to on-premises for delivery to your application server. In this post, we’ll show you how to achieve this, and how to resolve common issues you might encounter.

Example configuration of SMTP relay

In our example scenario, we’ve got an application server sending messages as Application.Mailbox. It has two different email addresses – the internal address used within the application server, and the address defined within Office 365.

In this example, our Office 365 email address is:

The internal application server email address is: Application.Mailbox@resdomain.local

Contact Object
Contact Object

So that the Office 365 email address can be used to relay mail back to the on-premises application server, the non-routable email domain needs a specific connector configured to route messages to the application server’s specific on-premises domain.

It’s important to note that you could instead add the domain to the hybrid connector, but we don’t recommend this. This is because if you re-run the Hybrid Configuration Wizard, which you may need to do periodically, the domain will be removed from the connector created and managed by the hybrid wizard.

The other key component of allowing email to route from Office 365 back to on-premises is ensuring that the on-premises environment is able to send the email to the application server, as shown below:

Routing Email Externally

In a configuration like this, we’ll also expect that because the application server needs to send SMTP messages, the on-premises Exchange environment can be used for relay via the Hybrid configuration, as shown below:

Routing Email Externally

After implementing this configuration, email can be sent and received from the application server. And all may appear well, initially…

Some emails are reported as spam or not delivered

After time, one common issue that may be reported is that there are mail delivery issues with some mail servers on the internet.

Generally, you will check that records, like your SPF records are set up correctly. You check and find that SPF is setup correctly and you are not on any bad reputation lists. Email delivery in general is fine.

However, sending a test email via the Application server and analysing the headers shows some interesting results.

Send Test Email

After sending a test message to replicate the issue, open the message headers in a client like Outlook. You can then copy and paste the headers into the Microsoft Message Header Analyser.

This is a useful tool, as it helps you easily examine the properties contained in the message headers and quickly identify the offending issue. In the example below, we’ve highlighted what appears to be the underlying issue:

Return Path

You’ll see above that we can see in the Return-Path, the envelope ‘from’ address, is set to the internal resdomain.local domain.

While this is valid on the internet, many receiving mail servers will consider an invalid Return-Path domain enough of a reason to mark the message as spam, or completely reject the message.

As this example is a lab environment, it is possible to easily reconfigure the network and Office 365 so that messages can be relayed directly from the application server. We’ll change the configuration for testing purposes to the configuration shown below:

Direct Test

Upon making the configuration changes, we’ll re-perform the SMTP relay test, as shown below:

Direct Test

After the message is received, we’ll follow the same investigation process as before and examine the message headers once the email has been successfully received. Routing directly, rather than via Exchange Hybrid shows that this time the Return-Path is as expected:

Proper Return Path

So, what’s going on?


Look at the unusual capitalisation of the Return-path in the first example and note that it’s exactly the same as the emboldened address in the Mail Contact object (the reply address):

SMTP Bad Default Reply to Address

Exchange on-premises is receiving the email then using the Mail Contact object as the envelope-from address when relaying it through to Office 365. It is not changing the reply address seen by the user, so at first glance everything behaves as expected.

Although Office 365 has the same Mail Contact object, the behaviour is not the same. Exchange Online is not changing the envelope address.

You could consider relaying all your application servers through Office 365 and Exchange Online directly. However this configuration isn’t suitable for many organizations, because it requires extensive firewall changes including allowing application servers to directly communicate over the internet.

Instead, we’ll choose to correct this by updating our application servers’ contact object within the Exchange on-premises environment. You’ll find the most straight-forward fix here is to set the correct address as the reply-to address in the Mail Contact, as shown in the example below:

SMTP fixed reply to address
read more
Exchange Server

How to keep your emails out of the recipient’s spam folder


Email is still as important as ever, despite the click-bait headlines and numerous communications start-ups claiming that email is dead and <insert fad here> will be the future of office communication. Email is so popular that even Spam Email is still a thing, accounting for 14.5 billion messages a day in 2017 – 45% of all email messages. Luckily companies like Microsoft have become experts at filtering the wheat from the chaff when it comes email and we hardly ever notice the barrage of spam thrown against our email servers. Unfortunately, sometimes a legitimate email may end up in a spam folder – which is bad news if you’re relying on that email to convey something important to a customer or supplier.

Email servers, such as those managed by Microsoft for Office 365, rely on a range of open standards and technologies to separate the good emails from the spam. As an email administrator, it is incredibly important that all the systems that your company uses to send emails are correctly configured to use these standards to ensure that your outgoing emails don’t end up in the recipient’s quarantine or spam folder.

Most email administrators understand that a big proportion of their outgoing emails come from a user’s Outlook or email client and are routed out via Office 365 or their local Exchange email server. However, it is always surprising to learn that these same email administrators have no idea what other systems send email out on behalf of their company’s domain name.

This post will walk you through configuring the two most effective technologies to ensure that your outgoing email is successfully delivered. These technologies are known as Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM).

Both technologies require you to add some special records into the DNS zones for the domain names that you are sending email from. The recipient’s email server analyses the headers of each email message and looks up these DNS records to try and match details of the sending email server against what you have configured. If the sending email server passes these tests, it is incredibly unlikely that the message will be marked as spam or suspicious.

Audit your outgoing emails
Before you can get started on configuring these items, you need to make a full list of all the domain names and email servers that your outgoing messages come from. Obviously, there will be your normal email service, such as Office 365 or Exchange, but it’s important to capture the other 3rd parties that may be sending emails from your domain such as:

  • CRM systems
  • Marketing Automation Systems
  • Helpdesk ticketing systems
  • Notification and alert services

You will need to configure SPF and DKIM for all these services. Luckily, in 2018 most major providers have great support and documentation for configuring SPF and DKIM.

Implementing SPF for Office 365

Now that you have a documented list of all the places your email gets sent from, you can start by setting up SPF for your Office 365 environment. To get started, log into your DNS provider and create a TXT record for the root of the domain that you are sending email from. You will need to consult your DNS providers documentation for instructions on how to create a TXT record.
In the value area, you will need to add the actual SPF record. For most Office 365 customers, the record will look like this:

It can be broken down into three components:

You will need to add an include: part for every other email service that sends email from this domain name. The example below allows email to originate from Office 365, Amazon Web Services and a mail server with the IP Address of

More information about all the options available within the SPF record can be found on the OpenSPF website.  You can validate that the record has been correctly applied using nslookup in a Windows command prompt window or PowerShell.  Simply open nslookup, set the lookup type to TXT using the set type=txt command, and then lookup the domain name as per the example below.

Spam Folder

You can check that the syntax of your DNS record is correct by pasting it into any one of the SPF syntax checking services that you can find online.  You will need to be aware that the SPF record has limitations in the number of servers or DNS lookups that can be added and there are a few other gotchas that you should look to avoid.

Once you have had your SPF record in place for a few weeks without problems, you can look to switch the ~all SoftFail at the end of the record to a more robust HardFail of -all.

Implementing DKIM for Office 365

Whilst SPF is a great technology for identifying IP addresses of email servers that are allowed to send email on behalf of a domain, it does have several limitations. I recommend that you also implement another technology called DKIM which takes email authentication one step further by signing an email message with a digital signature.

When DKIM is configured, each outbound email has a digital signature stamped into the message headers.  When an email message is received by the receiving email server, it looks up the DKIM public key from the domains DNS record and uses it to verify the DKIM signature it found.  If the signature is verified, the server knows that it was sent from a mail server that is authorised to use that domain and allows it through.

To enable DKIM in Office 365, you will need to create two CNAME DNS records in the hosted zone for your domain.  You will need to follow the instructions from your DNS provider to achieve this. 

The two records you need to create will look something like this:

The two parts you will need to fill in are:

<domainGUID>The domain GUID is the same as the one that is in your MX record, usually the first part of it.  For example:
<initialDomain>The Initial Domain is the domain you used to sign up to Office 365, and ends in  For example:

Again, you can verify that you have set the records correctly using nslookup:

Now that the records are published, you need to enable DKIM for the domain via PowerShell.  First connect to Exchange via Online PowerShelland run the following command:

Domain is the name of the custom domain that you want to enable DKIM signing for. For example, for the domain

You can validate that this is configured correctly by logging into the Exchange console and clicking on the Protection section.

Now that you have configured DKIM for Office 365, I highly recommend you also do this for all your other 3rd party mail services that you identified in your audit.  Each of these will have their own, but similar, way of configuring DKIM. For example here is how you can do it for SalesForce and HubSpot.

Alternatively, you can send an email from Outlook to an external email address and look at the mail headers.  Here you can see the SPF and DKIM headers in an email message I sent to my Gmail address:

If all your checks have passed you’re done!  Now your messages are incredibly unlikely to be marked as spam, and it will ensure that anyone spoofing your domain from unauthorised servers will have those messages flagged and blocked.

read more