Office 365 Outlook on the web (OWA): controlling “opt-in” for early versions and new experiences

Recently, Microsoft announced they are releasing the ability for users to “opt-in” for new OWA, or Outlook on the Web, experiences themselves by switching a toggle that will be made available to them in the interface.

Toggle blog.png
Image courtesy of Microsoft.

While I personally applaud the ability to try new features early, leaving it up to the users to decide whether or not to try out new features might not always be the best solution –especially if they leverage a (centralized) IT support organization which may not (yet) be able to support new capabilities (or even be aware of them). Although it wouldn’t be a huge problem per se, it might generate some unwarranted calls to the support staff…

Luckily, Microsoft learned from earlier mistakes and is providing the ability to control the presence of this toggle through the OWA Mailbox Policy assigned to the user.

My suggestion would be to update the default OWA Mailbox Policy to disable the toggle by default and create a new policy and assign it to a (small) group of test users (e.g. the ones enabled for Targeted Release) which could take advantage of the option. That way you limit the exposure in your environment and keep it available to users best suited to evaluate new experiences which will be coming to everyone else when it’s released more widely, later.

To update the OWA Mailbox Policy, connect to Exchange Online Powershell and run the following command:

Set-OwaMailboxPolicy “<OWA Mailbox Policy Name>” -OutlookBetaToggleEnabled $false

Unfortunately, there is no “OutlookBetaToggleEnabled”-parameter for the New-OwaMailboxPolicy cmdlet. Therefore, you’ll have to create a new policy, and update it afterwards should you require a separate policy for some users that would be allowed to take advantage of this feature.

Blog Office 365

New hybrid Organization Config Transfer-feature (OCT) announced

Yesterday, Microsoft announced the Organization Config Transfer feature (OCT) in the Hybrid Configuration Wizard. The feature is expected to start showing up starting late June 2018. In an ongoing effort to improve the Wizard, I believe this is a step in the right direction. Ever since the HCW was first conceived, running the HCW resulted in a series of steps which you had to (manually) run through to ensure that the Exchange Online configuration matched the on-premises configuration.

For example, you had to recreate the retention policies and tags that existed in the on-premises organization if you wanted to continue to use them in Exchange Online (and not to lose them during a migration!). The same was true for other policies like the OWA Mailbox Policy or ActiveSync Policy.

With the OCT feature, the HCW will automatically take care of that and copy the settings of the following elements to Exchange online for you:

  • Retention Policy
  • Retention Policy Tags
  • OWA Mailbox Policy
  • Mobile Device Mailbox Policy
  • Active Sync Mailbox Policy

Note: in this version of the HCW, it will only copy “new” policies. These are policies that do not exist in Exchange Online. If a policy with the same name already exists in Exchange Online, or when you update the policy in the on-premises organization after it has been copied to Exchange Online, the OCT-feature will not “sync” the policy or updates thereof across. As per statement from Microsoft, this is something for the next version of the feature.

Some might say this is only a small addition to the HCW, and while it might not (yet) benefit existing Hybrid customers, it’s a welcome addition for any consultant working on getting customers across to Exchange Online as it makes life just a little easier!

I’m looking forward to what Microsoft has more for hybrid in the future. Remember BRK3155 at Ignite 2017? There was a ton of cool new stuff announced, but only little has been delivered so far… Let’s see what Microsoft might deliver for Ignite 2018 as, traditionally, there seems to be a sprint to get a lot of new features out of the door ahead of the annual conference of conferences.

Looking forward to seeing you there!


Blog Office 365

How to leverage (multiple) migration endpoints to speed up migrations to Exchange Online

Last week, at Microsoft’s Tech Summit in Amsterdam, I gave a talk about running Exchange Hybrid connections over the long term. In that session, I talked about securing a hybrid deployment and – somewhat related – how to best and securely publish migration endpoints to the Internet.

Following that session, someone reached out to me asking me for more guidance on the topic. Except from what I have written about migration endpoints in the Office 365 for IT Pros e-book, I couldn’t find much else on the topic, so I figured I might elaborate on it a bit further. You can read more about it over on the blog of the ENow folks.

This being said, additional information beyond what’s described in this article can be found in the Office 365 for IT Pros e-book, which you can get here, if you’d like.


Blog Office 365

Messages more marked as spoofed (and moved to Junk e-mail) in Office 365? You’re not alone!

Update 21/03/2018: Microsoft have dialed back on how quickly messages are marked as spoofed and, thus, moved to the Junk E-Mail folder. However, the guidance is to still properly implement SPF/DKIM/DMARC to be future proof. After all, at some point in the (near) future, Microsoft plans to turn up the aggressiveness of the filtering again -rightfully so. However, let’s hope not before communicating more clearly about this!

Over the past few days, there has been an uptake in the number of people reporting an higher-than-usual amount of legitimate messages being moved to the Junk E-Mail folder. In addition, they are marked as being spoofed as well:

While (re)moving spoofed messages is not a bad thing, moving (seemingly) legitimate messages is!

So far, there has been no formal statement from Microsoft on the matter. However, a last-minute addition to the Office 365 roadmap states that new anti-spoofing features are rolling out, therefore possibly hinting what might be causing this particular behavior:

Image: ATP Roadmap – Source

Until Microsoft confirms, we can only speculate whether the new feature is, indeed, the culprit. Fellow-MVP Brian Reid, tweeted that changes were made to Exchange Online Protection (cfr. Roadmap item), and that those trigger a new filtering behaviour where unauthenticated messages are automatically marked and junked. In other words: all messages that have not (correctly) published any of the message authentication mechanisms (SPF/DKIM/DMARC), are at risk of being flagged as spoofed.

Some of my fellow MVPs have noticed the same, and have also reported on it. Amongst them is Paul Cunningham, who runs, where he published an article on the matter. On that same article, Terry Zink – the owner of the anti-spoofing feature in O365 – commented, stating the following:

Image: Terry Zink’s comment – Source

Especially the last sentence is interesting: “However, the long tail of smaller senders has proven problematic”. For now, we can only guess what “smaller sender” means. My best guess would be that if you’re only sending a few messages a day. If true, that would mean a large number of the small/medium organization could fall in that category and therefore be (negatively) affected by the changes.

I look forward to seeing a more elaborate statement from Microsoft on this, possibly further outlining what you can do to revert/alleviate the impact form legitimate messages being marked.  For now, it seems you have the following options:

  1. Ask your users to add the senders to their safe list. On a side-note, this means that other protection features are bypassed too; therefore allowing actually spoofed messages to land in your inbox, should you ever receive one from such source
  2. Request the sender to correctly implement SPF, DKIM, DMARC; if possible all of them [correctly].

As Terry mentions, a lot of signals are being collected to determine if a message is legitimate or not. However, I also see an increase of messages being marked and junked, despite SPF being implemented correctly. Perhaps the machine learning systems Microsoft is using, need a bit more tweaking…?

The fact that your messages might end up in someone’s Junk E-mail folder is entirely on you. If you haven’t implemented any of the aforementioned authentication mechanisms, you’re doing things wrong. Whilst I cannot argue that setting up SPF, DKIM and/or DMARC is the right thing to do, I also cannot ignore the fact that a lot of senders haven’t done so correctly/properly/at all (choose whatever applies).

As such, more legitimate emails are now being caught whereas they should not be. The behavioral change in EOP/ATP, which seems to be causing quite the stirr, should have been communicated more clearly by Microsoft. At the very least, they should have given administrators the opportunity to prepare for this change, communicate it to their users or – if not already – implement SPF/DKIM/DMARC.

In the end, all Microsoft is trying to do is improve security for Office 365 recipients (and beyond). There’s no doubt that the industry is moving towards a more restrictive way of filtering messages to counter the new methods attackers use, and perhaps Microsoft was the first to do so. Instead of fighting this change, I’m all for making sure that you’ve correctly setup message authentication; but I also believe Microsoft could have addressed this a little more gently.

If you need help implementing SPF, DKIM or DMARC, feel free to reach out. In the meantime, make sure to look at this article from Paul where he covers SPF, and how to set it up.

Blog Identity & Security Office 365

Microsoft releases new “Tenant Restriction” capability

A few days ago, Microsoft announced the General Availability of the “Tenant Restriction” capability. Although I have not been able to play with it so far, I wanted to take a few moments to reflect on the usefulness of the feature following a debate I had with a customer questioning me why they would be interested in something like this.

The Tenant Restriction capability, as the name already implies, allows an administrator to restrict access to a specific tenant. You might wonder how this is different from e.g. disallowing someone to authenticate by e.g. disabling their account? In the latter scenario, the user might not be able to use their account to login to e.g. Office 365, but that won’t prevent them from accessing other tenants (with other identities). From a data leakage point-of-view, the latter can be potentially dangerous. Maybe this is best explained with an example.

Let’s say a user called George works for Belgian Waffle House ltd. They have a tenant in Office 365 called “”. George also works for a non-profit organization called the Belgian Chocolate Lovers and, they too, have a tenant in Office 365 called “”. When no tenant restrictions have been configured, George can login to the tenant (as he should!), but nothing would prevent him from logging in into while at work. One might question why this is a problem, but let’s assume for a second that George first logged into the tenant and downloaded some corporate documents. Perhaps these documents describe a new merger plan between the Belgian Waffle House and some Swiss Chocolate maker… As a Belgian chocolate lover, he might be interested in that! Either way, after downloading the document, he then logs into the tenant and can upload the files there. The reason why he is able to login to both tenants is because the endpoint (e.g. is a single endpoint for all tenants, world-wide. Blocking the endpoint (e.g. through a proxy server) would also prevent George to login into the tenant.

Of course, there’s other ways to restrict access –but those pertain to accessing the tenant itself. For instance, an administrator can define a set of corporate IP addresses from which a user is allowed to authenticate into the corporate tenant. While this effectively prevents someone from accessing the tenant outside the corporate network, it doesn’t solve the problem described above.

The way this new Tenant Restriction capability works, is quite simple and the process isn’t really new. When a user authenticates to Azure AD (and thus a service which relies on Azure AD), the authentication platform will also look for a (HTTP) header called “Restrict-Access-To-Tenants“. The value of this header should contain all the tenants the user is allowed to access. If the tenant that the user is trying to authenticate to is listed, access is granted. If not, a warning message is displayed:

Image source: Microsoft.

A few things to reflect upon:

  • For this to work, there must be (some sort of) a proxy server between the user and the internet. Basically, anything that can add a header will do. If you want to ensure the limitation to access a tenant is maintained, e.g. also outside the corporate network, the user must always access the internet through a proxy server that injects the header. For this to work, other counter measures (such as ensuring the user cannot modify proxy settings etc.) must be present. Additionally, the proxy server must be accessible from outside the corporate network as well. One thing that would fit this requirement is a “proxy-as-a-service” such as e.g. ZScaler. But there’s others too.
  • The tenant restriction capability is not something you configure in Azure. Instead, it relies solely on your network infrastructure (proxy, ssl device, …) to inject the header. As such, the latter is quite important and you must consider the implications of doing so.
  • The feature only works with Modern Authentication. This is fine for the majority of Microsoft’s own application, but if you use other applications or even built-in ActiveSync apps, you must block access for those “legacy” apps if you want to maintain the restriction.
  • You can use the feature for free with Office 365, but have to buy a premium license if you want to restrict access to other applications relying on Azure AD for authentication.
  • The process described above only needs to be applied to the authentication process, hence thus only for the Azure AD endpoints. Users must not necessarily go through a proxy for access to e.g. SharePoint online or Exchange online.
  • Given the reliance on Modern Authentication, and because you cannot control how other tenants are setup, if those tenants still allow legacy authentication (e.g. basic auth), the restriction is bypassed (d’oh!). I hope/expect this to change in the future. However, if you also control the endpoint (and thus can control what applications can be used), it is still very effective.

As you can see, while the feature is pretty cool, it’s not 100% watertight. Perhaps that is a problem, perhaps not. It really depends on what your use case is for implementing it. However, if DLP is on your mind, every little thing can help and it can be an efficient way to stop the majority of the users of (accidentally) leaking sensitive data. Of course, it’s only a small cog in a much bigger machine as there’s many other features in Office 365 (and beyond) that can help you to prevent data leakage.

For more details, please read the announcement from Microsoft here.


Blog Office 365

A closer look at the “Minimal Hybrid Configuration” option

Just a few weeks ago, Microsoft announced a new feature in its line-up of hybrid Exchange capabilities: the Minimal Hybrid Configuration option. With the introduction of this new capability, Microsoft seems to have responded to a long-standing question from customers who can now move mailboxes to Office 365 without the need to deploy a ‘full’ Hybrid configuration.

Blog Exchange Hybrid Exchange Office 365

Exchange Hybrid Deployments and cross-premises Full Access permissions

Nothing but excellent news in the hybrid Exchange realm these days! Microsoft recently updated the support statement for cross-premises permissions in a hybrid deployment. As of now, Full Access delegate permissions are supported cross-premises. I know many customers will be delighted to hear this as this has been a big ask for quite some time now.

It’s important to understand that the support only applies to Full Access permissions, as stated here. Other permissions like Send-As, Receive-As or Send-on-Behalf are still not supported. Note that Microsoft is in the process of updating its documentation; you should see a more consistent message across TechNet over the next few days!

Although full access permissions have been reported to work intermittently, no cross-premises permissions were supported previously. As such, you could not rely on them working either. From what I understand, the plumbing was already in place for a while but the intermittent results were partially due to the Outlook client not honoring them quite as one would expect. Provided you have the November 2015 update to Outlook 2013, you should no longer run into any problems.

As you move mailboxes to Office 365, permissions are migrated along. If you already had permissions assigned before the move, there is nothing you need to do. Although the permissions were also migrated previously, you had to move connected mailboxes at the same time so they would be hosted in the same organization in order for them to work. Not too long ago, I was talking to a customer who started out with a handful of mailboxes to move to Office 365 but ended up with a huge migration batch because of the interweaved permissions… As of now, this is no longer needed, making planning for migration batches a lot easier!

You should now also be able to add the Full Access permissions after mailboxes have been moved. This means you can give an on-premises mailbox access to a mailbox in Office 365 and the other way around without having to set the permissions prior to moving the target mailbox to Office 365.

In order to explain things more clearly, I have put together a Q&A. I hope this helps!

Until later,


What cross-premises permissions are supported in a hybrid deployment today?

Full Access only. Other delegate permissions like Send-As, Receive-As or Send-on-Behalf are not. There are no changes to cross-premises calendar delegation either. That continues to work the same way it did before.

Will the permissions work both ways?

Yes. On-premises mailboxes can access Office 365 mailboxes and vice versa.

What do I need to do to make this work?

Nothing, really. Just make sure you are using an up-to-date Outlook client. For Outlook 2013, this means you need at least the November 2015 Cumulative Updates. Needless to say, the more up-to-date you are, the better!

In order to add permissions for a recipient in the other organization, you can either use PowerShell or the Exchange Admin Center. Unlike the EAC in Office 365, you cannot use the on-premises EAC to grant an Office 365 mailbox access to an on-premises mailbox. For that you must revert to using PowerShell.

How do I add permissions to an Office 365 mailbox for an on-premises recipient?

Follow these steps to add Full Access permissions to an Office 365 mailbox for an on-premises recipient:

  1. Login to the EAC in Office 365 (Exchange Online)
  2. Navigate to recipients > mailboxes and then select properties of the mailbox you want to add Full Access permissions for.
  3. In the properties window, navigate to mailbox delegation
  4. Scroll down to you get to the Full Access From there, use the recipient picker (plus-sign) to add the on-premises mailbox you wish to grant permissions to:
  5. Click save.

How do I add permissions to an on-premises mailbox for an Office 365 recipient?

As mentioned earlier, you cannot use the EAC to add permissions for an Office 365 recipient. Instead, you must use the on-premises Exchange Management Shell. Don’t worry it’s quite simple!

Add-MailboxPermission –Identity <On-Prem_mailbox_to_give_permissions_for> -User <O365_mailbox_to_give_permissions_to> -AccessRights FullAccess –AutoMapping $false

For example:

Add-MailboxPermission –Identity –User –AccessRights FullAccess –AutoMapping $false

Unlike for permissions in the same environment, the AutoMapping feature is not supported. Hence why I specified the –AutoMapping $false parameter. I suspect the permissions to work without adding the parameter too!

What will my users see?

There is no difference in how Outlook displays an Office 365 mailbox over an on-premises mailbox you have access to. However, an on-premises user might get prompted for credentials when trying to access a mailbox in Office 365. This is because, in the back, the Outlook client must establish a connection with the Office 365 service first.

How that looks, depends on a number of things like the version of the Outlook client, whether you use Modern Authentication and whether or not they already have another Office 365 mailboxes in their Outlook profile.

Blog Exchange Hybrid Exchange News Office 365