Connecting Those Obscure Teams Channel Email Addresses

Updated 10 July 2023

A colleague posed the question of how to find what team a channel email address belonged to. This is more difficult than you might imagine because when Teams creates an email address for a channel (like 24482dde.office365itpros.com@na.teams.ms), the address doesn’t contain any hint that would allow you to connect the address to its channel. Teams can generate email addresses for any type of channel – regular, private, and shared, and the same kind of obfuscated addresses are used for all types. The Teams admin center doesn’t offer any way of reporting channel email addresses – the only out-of-the-box method to see a channel’s email address is with the Get Email Address option in the Teams client.

No matter, I said, PowerShell will do the trick. In fact, I’d been down this path before when I wrote about how to use audit records to know when channels get or lose email addresses. Part of that article looked at reporting the email addresses that exist for channels using a mixture of PowerShell and Graph API requests (the script is available from GitHub). The Graph requests are required because the Get-TeamChannel cmdlet doesn’t include the email address in the set of properties it returns.

Use the Graph to fetch Teams Channels

The script was one of my earliest efforts at using the Graph with PowerShell and like all code, a fresh eye sometimes creates better results. At least, that’s the eternal hope. I decided to use the Microsoft Graph PowerShell SDK this time around. I used version 1.10 of the Graph SDK for this project. You need the Graph Channel.ReadBasic.All permission to access channel settings. (update: I’ve checked the code against Microsoft Graph PowerShell SDK V2).

Three years ago, the Microsoft Graph PowerShell SDK wasn’t in great shape. Some would argue that it’s still not where it should be. I think the SDK has improved greatly, even if its documentation still sucks dirty canal water. In one respect, the biggest benefit of the SDK is that you don’t need to create an Entra ID registered app to hold the permissions needed to run Graph requests. Some of its cmdlets take care of pagination too.

For many people, the SDK is easier to use than running Graph requests. Once you’ve gotten the hang of API request formats, you’re able to switch between SDK cmdlets and Graph requests, much like people can switch between left-hand and right-hand drive cars. In any case, here’s the code I wrote:

Connect-MgGraph -Scopes Group.Read.All, Directory.Read.All, Channel.ReadBasic.All
[array]$Teams = Get-MgGroup -Filter "resourceProvisioningOptions/Any(x:x eq 'Team')" -All
If (!($Teams)) {Write-Host "Can't find any teams - exiting"; break} 
$Teams = $Teams | Sort-Object DisplayName
$ChannelsList = [System.Collections.Generic.List[Object]]::new()
[int]$i = 0
ForEach ($Team in $Teams) {
   $i++
   $ProgressBar = "Processing Team " + $Team.DisplayName + " (" + $i + " of " + $Teams.Count + ")"
   Write-Progress -Activity "Checking Teams Information" -Status $ProgressBar -PercentComplete ($i/$Teams.Count*100)
   [array]$Channels = Get-MgTeamChannel -Teamid $Team.Id 
   ForEach ($Channel in $Channels) {
     If ($Channel.Email) {
       $ChannelLine = [PSCustomObject][Ordered]@{  # Write out details of the private channel and its members
          Team           = $Team.DisplayName
          Channel        = $Channel.DisplayName
          Description    = $Channel.Description
          EMail          = $Channel.Email
          Id             = $Channel.Id }
       $ChannelsList.Add($ChannelLine) } 
  } #End Foreach Channel
} # End ForEach Team

Refining for Teams-Generated Email Addresses

So far, so good. The only complication is that the Get-MgTeamChannel cmdlet returns the primary SMTP address for the underlying Microsoft 365 group for a team’s General channel even if Teams generates an email address for the channel. In some respects, this is expected because the General channel is the heart of a team. However, you can’t use the group primary SMTP address to send email to the General channel. because Exchange Online delivers any messages sent to this address to the group mailbox.

To find the set of teams-generated addresses, we therefore need to apply an additional filter. This is straightforward because all teams-generated addresses end in “teams.ms,” the special domain used for this purpose. The command is:

$TeamsEmailAddresses = $ChannelsList | Where-Object {$_.Email -Like "*.teams.ms"}

Figure 2 shows the set of email addresses in my tenant. Most of them are used for testing, which accounts for some of the obscure channel names.

PowerShell Invaluable to Administrators

Situations like this underline the truth of the assertion that PowerShell is an invaluable tool for Microsoft 365 tenant administrators. No set of administration tools created by a vendor can be all-encompassing and PowerShell’s ability to fill in the gaps is what makes it so useful. Add in the ability to make Graph calls from PowerShell, and you have a very powerful tool indeed.

Learn more about how the Office 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Useful but Aging Cmdlet

I’m bemused when I see sites treat the Get-MailTrafficSummaryReport cmdlet as if it has some magical powers, like proclaiming it to be one of the top 10 cmdlets for email monitoring. The sad fact is that although the cmdlet is useful, it has aged without much progression over the last few years, which might be why Microsoft attempted to retire it in 2021. That venture failed because of customer feedback, but I’m insure why people feel so strongly about the cmdlet.

Summarizing Message Trace Data

Essentially, the Get-MailTrafficSummaryReport cmdlet takes the message trace data retained by Exchange Online for the last 90 days (give or take a day or two depending on background processing) and summarizes the data under various categories. The most popular are:

• TopMailSender: Report the number of messages sent by different mail-enabled objects, including user mailboxes, shared mailboxes, and guest accounts. Separate counts are given for each proxy address assigned to a mail-enabled object.
• TopMailRecipient: Report the number of messages received by different proxy addresses for mail-enabled recipients. As for senders, separate counts are available for each proxy address assigned to a mailbox.
• TopMalware: Report malware (like Win32/Tnega.SM!MTB) detected in inbound messages.
• TopSpamRecipient: Report the number of spam messages intercepted for mail-enabled recipients. I use different test accounts for articles. Within a week of publishing a test account’s email address in an article, I know that spam begins to arrive for that account. The report also shows spam addressed to mail-enabled recipients that no longer exist, like mailboxes belonging to deleted accounts.
• TopMalwareRecipient: Like spam, but these messages are deemed by Exchange Online Protection to contain malware.
• InboundTransportRuleHits: Report the transport rules which process inbound email. The report lists the individual rules and the number of messages processed by each rule. You can filter by the name of one or more transport rules by passing the names of the rules in the TransportRule parameter.
• OutboundTransportRuleHits: Report transport rules which process outbound email.

The cmdlet supports reporting for Data Loss Prevention (DLP) rule hits. I don’t use categories like OutboundDLPPolicyRuleHits (DLP rules detected a policy violation in an outbound email) as much as the categories listed above.

The statistics generated by the cmdlet come from a data warehouse. As such, the information is not real-time in the same way that running Get-MessageTrace can report the progress of a message sent a few seconds ago. Having a time lag for usage data isn’t unusual within Microsoft 365. The normal delay before data becomes available is around two days.

Example of Get-MailTrafficSummaryReport

Most articles covering Get-MailTrafficSummaryReport focus on the top senders and top recipients reports. Looking at something different, here’s how to run a report for outbound messages processed by transport rules. The outbound shows that the transport rule to apply a disclaimer to responses for calendar meeting requests is the most popular in my tenant.

Get-MailTrafficSummaryReport -Category OutboundTransportRuleHits -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2, C3

C1                                   C2                  C3
--                                   --                  --
Calendar Disclaimer                  SetAuditSeverityLow 201
Automatic BCC                        SetAuditSeverityLow 22
Block Email to Tenant Admin Accounts SetAuditSeverityLow 11
Block Power Automate                 SetAuditSeverityLow 7

The cmdlet output uses C1, C2, and C3 (columns 1, 2, and 3) as non-specific header names because the various reports generate different pieces of data. Sometimes C1 is used for email addresses, and sometimes, like in this example, for the names of transport rules.

Alternatives

The alternatives to using the Get-MailTrafficSummaryReport cmdlet include:

• Export message trace information to an external repository like Splunk. Organizations do this to retain data for longer than the 90 days supported by Microsoft and to gain more sophisticated querying capabilities. Here’s an example of a script written to extract large quantities of message trace data.
• Use the Microsoft Graph reports API to work with the same data as appears in the usage reports in the Microsoft 365 admin center. The data is limited to a 90-day horizon and the email usage data is nowhere near as comprehensive as message trace data and doesn’t include access to data about spam, malware, and rule-based activity. The major advantage of this approach is the ability to build a picture of overall user activity across multiple Microsoft 365 workloads.

My bet is that Microsoft’s focus will be on Graph-based usage reporting. It’s likely they will try to deprecate the Get-MailTrafficSummaryReport cmdlet in the future. With that in mind, I don’t plan to spend much time on this cmdlet going forward as I don’t anticipate any change in coverage or functionality. But if Get-MailTrafficSummaryReport does a job for you, continue using it until the future direction becomes apparent.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Handling Encryption, Signing, and Permission Controlled Email

A recent question in the Microsoft Technical Community about Data Loss Prevention (DLP) policies covered the difference between encrypted, permission controlled, and signed messages. In this instance, the DLP policy rule included an exception to allow a message containing some sensitive data to pass if encrypted. However, the exception wasn’t triggered for messages protected by Office 365 message encryption (OME) or sensitivity labels. The documentation covering email exceptions didn’t add much insight.

Email encryption has been around for years. S/MIME and PGP are two examples of commonly used email encryption technologies. First supported by Exchange Server 2003, S/MIME support for message encryption and signing is still available in Exchange Online, with the caveat that tenants must take charge of the details of deploying and managing S/MIME to users.

Microsoft acknowledges that its OME and sensitivity labels technologies are direct competitors to S/MIME. These products are based on Azure Rights Management rather than public key technology. For Office 365 tenants, Microsoft protection is easier to deploy and manage, and it can encrypt email sent to other Microsoft 365 tenants and external domains without the need for the receiving organizations to take any action.

It’s even possible to configure sensitivity labels to use S/MIME instead of rights management protection. This is a custom configuration for sensitivity labels that requires the unified labeling client (and Azure Information Protection licenses). I have never used this facility and do not know how well it works in practice.

Email Exceptions for DLP

All of which brings me to the set of email message type exceptions available for a DLP rule (Figure 1). When Microsoft started to develop service-wide Data Loss Prevention capabilities, the set of actions, exceptions, and conditions available for Microsoft 365 DLP policies was more limited for email than Exchange Online DLP. Over time, Microsoft 365 DLP processing capabilities became better and better. Building out the exceptions available in rule processing is an example of where improvements have occurred. A year or so ago, tenants could move their Data Loss Prevention focus away from Exchange Online transport rules (ETRs) to Microsoft 365 DLP without losing functionality.

Apart from wanting to maintain the same DLP processing for both on-premises and cloud email workloads, I don’t know of any obvious reason to continue using ETRs within Microsoft 365. That being said, some organizations have enormously complex DLP rules which require substantial effort to move to Microsoft 365 DLP policies. In some cases, these tenants will stay using ETRs until they’re forced to move.

What we learn from Figure 1 is that the available message types for DLP exceptions are:

• Signed messages (digital signature applied by S/MIME).
• Encrypted messages (S/MIME). See this Exchange 2010 documentation.
• Permission controlled (rights management).

Permission controlled is an odd term. I can understand why it’s used because rights management is all about granting permissions to users or groups to interact with content, but the term doesn’t tell the administrator that it means rights management. But it does, and despite the fact that rights management can encrypt email, using Encrypted as an exception won’t work for messages protected by OME or sensitivity labels.

Permission Controlled the Way to Go

For most organizations, the Signed and Encrypted message types are now firmly in the legacy category, and they’ll never need to deploy Data Loss Prevention rules to deal with these types. The majority will use OME and/or sensitivity labels and should therefore use the permission-controlled message type in DLP policy rule exceptions. I never knew this detail until now. Discovering new things about how Microsoft 365 works daily is one of the unique joys (or pains) of coping with the cloud. At least, I think it does…

Learn more about how the Office 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Groundhog Day for Send from Proxy Addresses

Microsoft’s January 25 announcement of a public preview for the send from email alias feature certainly confused many people, including me, because the feature first appeared last year. I wrote about the topic for Practical365.com on April 22, 2021 and the news was subsequently covered elsewhere.

Microsoft released message center notification MC252942 on April to confirm that OWA would support sending from a proxy address, with roll-out expected in early May. The feature is also covered in Microsoft 365 roadmap item 59437. According to 59437, sending from email aliases reached general availability in August 2021, only it didn’t. Or maybe it did, in a certain way.

It’s odd that Microsoft should rerelease a previously released feature a long time after it first appeared in tenants, but there is a certain logic behind the story. Here’s my take on the situation.

A Send from Email Proxies Primer

In a nutshell, if you want users to be able to send email from proxy addresses (email aliases), you update the Exchange Online organization configuration:

Set-OrganizationConfig -SendFromAliasEnabled $True

The setting applies to the complete tenant. There’s no way to restrict the ability to send email from aliases to certain mailboxes.

An Exchange Online mailbox can have multiple proxy addresses. Exchange could always deliver email to a mailbox based on any of its proxy addresses. After updating the Exchange Online configuration, users can send email using any of the proxy addresses assigned to their mailbox. The exact mechanism differs from client to client. For instance, in OWA, you must select the proxy addresses that you want to use in OWA settings (Figure 1) to populate a list of available addresses for the From field in the message compose screen.

Sending from email proxies is rated as a preview feature, so changes might happen before Microsoft regards send from email alias as a generally available feature. This is a cloud-only feature that Microsoft doesn’t intend bringing to Exchange Server.

Client Support

The original announcement covered OWA and no other client. This is understandable because client GUI must change to allow users to select a proxy address before sending a message. However, OWA didn’t get full support for send email from aliases until October 2021. Work was going on to upgrade Outlook desktop too, as evident in the beta release notes for Outlook for Windows issued on July 30, which cover a bug fix for tenants where the SendFromAliasEnabled configuration setting is True.

Microsoft’s new text says that OWA and Outlook for iOS and Android support send email from aliases, with plans to support Outlook desktop users by Q2 2022. The obvious conclusion is that it’s taken Microsoft longer than anticipated to update all the Outlook clients. Pulling together feature updates across multiple clients underlines the value of the One Outlook project, which is intended to allow much greater code sharing across Outlook clients, like the way the Room Finder works.

However, I think the delay is more likely due at the server level rather than clients. Exchange has processed email for a very long time; the origins of the code base for the SMTP-based transport service came from Exchange 2000, and although the Exchange Online code base is dramatically different because of new capabilities like support for DANE and DNSSEC and the introduction of a legacy SMTP endpoint, it’s always possible that assumptions existed in code that messages used only the primary SMTP address.

Engineers needed to find every path messages could take through the code to assess if all scenarios support sending from email proxies. If not, they needed to apply a fix. The complexity of the Exchange Online transport service is illustrated by the set of known issues described in Microsoft’s post. I assume that Microsoft will address some if not all these issues when send from email aliases reaches general availability.

My theory is that experience of using the original implementation unearthed several knotty bugs. It has taken Microsoft time to upgrade code in both servers and clients to reach the point where they’re confident that everything works as it should.

All’s Well That Ends Well

I don’t think the Microsoft announcement communicated the situation as clearly as they could have. Acknowledging the previous release would have clarified the matter. However, the fact remains that send from email aliases is a very useful and welcome feature to have, even in its preview state.

Learn about how Exchange Online and the rest of Office 365 works by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

No Action Visible

I had a problem with actionable messages generated by Microsoft Teams not working properly in Outlook desktop. In the overall scheme of things, this isn’t a huge issue, but it became an irritation because nothing was obviously wrong. The problem was that I could interact with actionable messages using any other client than Outlook desktop. Here’s the story.

Actionable Messages in Yammer and Teams

Actionable messages contain a JSON payload in the message body to allow the recipient to respond to an application based on the content (hence the name) using “action buttons” associated with the commands necessary to execute an action, like respond to a message. The technology has been available for several years. For example, a Yammer actionable message allows the recipient to react to a message posted to a community or post a response of their own (Figure 1).

Much the same happens for Teams Missed Activity messages, where recipients can respond to chats or channel conversations (Figure 2). Teams generates these messages based on the option selected by the user in the Notifications section of Teams settings.

Apart from the magic involved in interpreting the JSON payload and presenting it in an attractive manner in Outlook desktop, OWA, and Outlook mobile, the other major technology needed is the HTTP response to update the target application with the action chosen by the recipient.

Deploying the Actionable Message Debugger

The problem I had was that Outlook desktop stubbornly refused to allow interaction with Teams missed activity messages while OWA and Outlook mobile worked properly. Instead of being able to reply to Teams conversations from Outlook desktop, the messages offered to use a deeplink to launch the application positioned in the conversation (for instance, Teams missed activity messages included only a Reply in Teams button). Although Teams actionable messages had problems, Yammer actionable messages worked normally.

I found a mention of a similar problem happening in another context. Unfortunately, the recommended check against the system registry to uncover permission issues with the Office add-in store produced no joy. However, it led me to install the Actionable Messages Debugger for Outlook and deploy it as an integrated app via the Microsoft 365 admin center (Figure 3).

Soon afterwards, the debugger showed up in Outlook. I don’t know why, but suddenly things started to work properly. Apparently, the mere presence of the debugger or using the add-in to examine the properties of a message (Figure 4) resolved the problem. Or did it?

I

Of course, software doesn’t work on a whim (or maybe it does, which would explain some oddities observed over the years). Authentication is a more fundamental reason. After all, an actionable message must be capable of posting its command for the magic to work. I had switched my Teams desktop client to another tenant (I have guest accounts in too many tenants; shared channels should help, when they become available).

It’s logical to assume that if Outlook desktop finds that the same account used to connect to Exchange Online is not connected to Teams, it will assume that it cannot process actions and so revert to the Reply to Teams command. If the user takes this option, they must authenticate to access Teams. OWA and Outlook Mobile seem to use connections to the home tenant, so they’re unaffected by switching to other host tenants. The issue doesn’t affect Yammer: its browser client probably works like OWA.

I hate not understanding why features do not work as they should. At least now I have a reasonable explanation and can go and do something more productive.

Debugging Information

You probably will not use the debugger unless you’re developing an Outlook add-in or need to gather information for a support call. The information presented by the debugger will mean a lot to those who understand what the JSON content should look like and how it should behave, but maybe not for others. To demonstrate what you might find, here’s an example of an actionable card error captured by the debugger:

{
-
"ActionableMessageStamping": {
-
"Errors": [
"Adaptive card signature validation failed - Sender of the email does not match sender in the signed card. Originator:78c6dd9c-1fe2-40ba-ae94-19729f11547d, OAMAppName:xxxGroup"
],
"Infos": [ ]
},
   "CardEnabledForMessage": false,
   "ClientName": "Outlook",
   "ClientVersion": "16.0.14827.20088",
   "InternetMessageId":           
   "<DB9PR04MB8445D745EBCC517C2CA20D8EFD509@DB9PR04MB8445.eurprd04.prod.outlook.com>",
   "EntityExtractionSuccess": true,
   "SignedAdaptiveCard": true,
-
"MessageCardPayload": {
"found": false,
"type": null
},
-
"AuthHeader": {
"results": "dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=office365itpros.com;",
"authAs": "Internal"
}
}

Organization Control for Actionable Messages

The Exchange Online organization configuration contains a setting (SmtpActionableMessagesEnabled) to control the use of “action buttons.” The default is True, meaning that email clients allow users to respond to buttons inserted in email by Microsoft 365 applications. If you wanted, you can run Set-OrganizationConfig to set the value to False to disable actionable messages.

Set-OrganizationConfig –SmtpActionableMessagesEnabled $False

I can’t think of a good reason to disable actionable messages, but you never know when the need might arise. That’s I can’t think of a good reason to disable actionable messages, but you never know when the need might arise. That’s the joy of discovering poorly documented parts of Microsoft 365, just like finding out why Teams missed activity messages won’t work when you switch to use a guest account in another tenant.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Update Intended to Make Dynamic Groups More Reliable

Update March 8: Microsoft published MC340293 to announce the feature. It’s odd that they do so some months after people saw the functionality work in their tenants. Microsoft says that they will begin the general roll-out the feature in April 2022.

A LinkedIn post discusses Modern Dynamic Distribution Groups (also known as dynamic distribution lists) and says that Microsoft is going to roll out this upgrade for these very useful objects in January with worldwide completion due in March. The fundamental change is to move away from on-demand resolution of group queries to resolve and store group membership daily.

The reasons cited to make the change are to Reduce mail delivery latency by removing the need to resolve the queries against the Exchange directory each time someone addresses the group. Because they cover a limited set of well-known conditions, it’s usually easy for Exchange to resolve precanned filters to find a set of mail recipients. However, custom filters can be reasonably complex and their resolution can slow the ability of the Exchange transport service to route messages. Microsoft believes that making the change to pre-resolved recipient lists will also Improve service reliability.

According to Microsoft, they released details of the change in message center notification MC289967 in early November. I never saw this notification and no trace of it exists in my tenant. However, everything seems to be working as reported in my targeted release tenant. Microsoft says that full roll out will start in early January and should be available everywhere in March 2022.

Less Dynamic but Still Valid

Of course, creating recipient lists for dynamic distribution groups makes them less dynamic and depends on an assumption that group membership doesn’t change often. In most cases, the assumption is true: organizations do not update directory attributes every few days and the membership of dynamic groups probably doesn’t vary all that often.

A side effect of the change is that when administrators create new dynamic distribution groups or update the filters of existing groups, it can take up to two hours before Exchange Online calculates the membership of the new group and makes it available for use. This is different to previous behavior when Exchange could use a new or updated filter immediately it was updated in the directory. The new Exchange Admin Center already flags the need to wait to administrators (Figure 1). True to its word, when I created a new dynamic distribution group, it was available almost exactly two hours later.

To see when Exchange Online last computed the membership of dynamic distribution lists, run the Get-DynamicDistributionGroup cmdlet and examine the CalculatedMembershipUpdateTime property. The results shown below were obtained at 15:00 on 10 December 2021 at, so membership was approximately 18 hours old at that point.

Get-DynamicDistributionGroup | Format-Table DisplayName, CalculatedMembershipUpdateTime

DisplayName                              CalculatedMembershipUpdateTime
-----------                              ------------------------------
Company-DDG                              09/12/2021 20:50:06
Dublin users                             09/12/2021 20:50:06
Office 365 Gurus                         09/12/2021 20:50:06

Moving away from on-demand membership resolution means that Exchange Online now uses the same approach to calculating dynamic group membership as Azure AD uses for its dynamic groups. No great issues have been reported by organizations struggling to deal with Azure AD group memberships, so there’s no reason to believe that problems will surface with Exchange Online.

New Get-DynamicDistributionGroupMember Cmdlet

Because Exchange Online now calculates the membership of dynamic distribution groups daily, the membership of these groups is available without having to run the Get-Recipient cmdlet to resolve the group query. For example, instead of fetching the recipient filter from the group and using it as an input to the Get-Recipient cmdlet like this:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity Architects).RecipientFilter

Name           RecipientType
----           -------------
Ben.James      UserMailbox
Brian Weakliam UserMailbox
James.Joyce    UserMailbox
Marc Vilas     UserMailbox
TRedmond       UserMailbox
Vasil.Michev   UserMailbox

You can use the Get-DynamicDistributionGroupMember cmdlet instead:

Get-DynamicDistributionGroupMember -Identity Architects

Name           RecipientType
----           -------------
TRedmond       UserMailbox
Marc Vilas     UserMailbox
Vasil.Michev   UserMailbox
Brian Weakliam UserMailbox
Ben.James      UserMailbox
James.Joyce    UserMailbox

Although they’re not returned in the same order, the two cmdlets produce the same set of mail-enabled recipients.

The Get-DynamicDistributionGroupMember cmdlet is available in the Exchange Online management module (and based on Microsoft documentation, the cmdlet has been around since mid-August 2021, even if no one noticed). However, no email client yet supports the ability to:

• Expand the membership of a dynamic group and insert each member as a separate recipient in the header of a message.
• View the membership of a dynamic group through the address book.

As of November 2022, no Outlook client supports these features.

Trivia note: The Microsoft Exchange PowerShell Cookbook, published in 2015, includes a function called Get-DynamicDistributionGroupMember which uses Get-Recipient to resolve a recipient filter against the directory.

Not Much Impact

Only Microsoft can say if the change to precalculated membership speeds message delivery and increases the robustness of the Exchange Online transport service. It’s easy to see how performance will improve, but you’d assume that Exchange had mastered the resolution of membership queries by now (dynamic groups first appeared in Exchange 2003). In any case, the change won’t make any difference to end users. Some might notice if Microsoft updates Outlook to support membership expansion of dynamic groups, but others will never see a difference.

Keep up to date with developments like new PowerShell cmdlets by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Use a Mail Flow Rule BCC All Messages Matching Rule Criteria to Another Recipient

Sometimes when I am at a loss for a topic to write about, I look at the Microsoft Technical Community forums to see what’s going on there. Which brought me to the following question:

“My boss needs all my outgoing emails to have him BCC’d onto them. If I don’t have an automated BCC to all emails I compose, reply to and forward, I know there’ll be message I forget to add him to.”

On the surface, you might wonder why a manager would want to be a BCC recipient on all outgoing messages for their employees. It’s a kind of big brother supervision technique. However, there is value in automatically copying messages. For instance, you might want to send copies to:

• A central CRM system to track customer engagement.
• A shared mailbox (or Microsoft 365 group) so that other team members can see customer queries and other interactions.
• An external system to index and archive messages.

I’m sure other reasons exist. The point is that the ability to copy messages to a destination automatically without user intervention or knowledge is a reasonable request.

Available Methods

The potential methods available to solve the problem include:

• Inbox rules. Apart from the fact that the rules wizard doesn’t support BCC copying (this can be done using Visual Basic for applications), an obvious problem is that the user can see the inbox rules and can remove the rules without administrator knowledge.
• Third-party tools. Although effective, third party tools might only cover certain email clients (and specific software versions) and probably incur cost for purchase and support.
• Transport (mail flow) rules. This method is the only one that you can guarantee will process messages sent by all email clients. The downside is that an administrator must configure the rule. However, if the rule settings are flexible, this should be a one-time operation.

Mail Flow Rule BCC is Best Option

Overall, mail flow (transport) rules are the best solution. They’re part of Exchange Online so don’t cost anything, and they cover all bases.

The basic outline for the rule is very simple:

• Look for messages sent by a specific user.
• Copy those messages to a BCC recipient.

I recommend using a distribution list to identify the originators of messages to be copied. This allows the rule to cover multiple users and means that administrators don’t need to update the rule when people leave the organization. The responsibility for maintaining the distribution list can be given to the manager, who can update list members through Outlook or OWA.

The same logic appears to hold for the BCC recipient, and it would be nice to use a distribution list here. Unhappily, that transport rules don’t support using a distribution list or Microsoft 365 group as the target for BCC copies. However, transport rules do support shared mailboxes as BCC targets, and shared mailboxes offer some advantages over copying messages to the manager’s mailbox.

• The manager can open the shared mailbox using OWA, Outlook, and Outlook mobile and a clear separation exists between BCC messages and normal email traffic delivered to the manager’s mailbox.
• If the manager moves to another position, they can hand the shared mailbox over to their replacement.

If you decide to use a shared mailbox, make sure to assign the manager full access to the mailbox. With this permission, they’ll be able to open the shared mailbox as a shared folder in OWA. Outlook desktop detects the presence of the full access permission and will add the shared mailbox to the set of resources it opens automatically.

So much for the theory, let’s create the rule.

Creating and Refining the Mail Flow Rule BCC

Mail Flow rules are managed through the Rules section under Mail flow in the Exchange Online admin center. When you create the rule, use the send messages and save a copy for review template. This presents a simplified version of the creation UI appropriate for a send and capture rule. In Figure 1, I’ve selected to:

• Apply the rule if the sender is a member of the BCC Employees distribution list; and
• Bcc the message to the BCC Destinations recipient (shared mailbox). Any valid email address will work as the BCC recipient and you can enter several addresses for different types of recipients.

Setting the rule to Enforce causes the Exchange transport system to apply the rule. Because of the way Exchange Online spreads mailboxes in an Microsoft 365 tenant over several mailbox servers, it can take up to 30 minutes before the new rule is distributed and becomes effective on all servers. The same interval occurs for rule changes, so build this time into your testing regime.

When the mail flow rule is effective, the Exchange transport system copies all messages sent by anyone in the monitored distribution list to the BCC recipient. Figure 2 shows the shared mailbox following the arrival of some BCC messages. The BCC Destinations shared mailbox looks like any other mailbox in the set of resources available to the manager, making this a convenient way to monitor inbound traffic generated by employees.

In passing, you’ll note the use of plus addressing to identify email coming from a specific source in the copied message shown in Figure 2.

The Need for Exceptions

Although everything works, the problem is that the manager could spend a lot of time reviewing email that they don’t need to. For example, if the employee sends a personal message, should the manager see that email? This is an issue that organization culture, HR processes, the need to respect privacy, and employee sentiment all influence. An organization might decide that employees should not use email for personal reasons, but that’s hard in today’s always connected world.

We can improve the transport rule by building in an exception to allow the employee to mark email as personal. For instance, the rule could allow any email with a certain word in the message subject to pass without being copied. To prove the point, I added an exception to the transport rule to allow users to mark private email by including P: in the subject (Figure 3).

Mail Flow Rule BCC Works But…

The mail flow rule works, but I wonder if it’s a good use of management time to review every message sent by users. A better solution might be a mail flow rule which checks for specific words or phrases (like “quotation” or “purchase”) in email and BCCs those messages. In any case, the technology works and it’s available in all Exchange Online plans.

Learn about maximizing the use of Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

Despite the central importance of Exchange Online in many Microsoft 365 tenants, it’s natural that some administrators might not have grasped the finer details of mailbox management. There’s lots to look after elsewhere from SharePoint Online sharing permissions to the many management policies used by Teams. One detail that I often think is overlooked is the role played by mailbox plans, specifically how mailbox plans affect mailbox settings.

Four Mailbox Plans for Each Tenant

Every tenant comes equipped with four mailbox plans, which you can see by running the Get-MailboxPlan cmdlet. These plans accommodate the different variations of Exchange available in different Office 365 and Microsoft 365 products.

Get-MailboxPlan | Format-Table DisplayName, IsDefault, Name

DisplayName              IsDefault Name
-----------              --------- ----
ExchangeOnlineEnterprise      True ExchangeOnlineEnterprise-8fc1c029-5e32-485e-9810-179fb4701447
ExchangeOnlineDeskless       False ExchangeOnlineDeskless-bc1e76cc-4c0b-491c-a518-3a0a43cbf78e
ExchangeOnline               False ExchangeOnline-12c139bc-eafa-4a43-b4d2-e285f83e075d
ExchangeOnlineEssentials     False ExchangeOnlineEssentials-1a1bf516-90d5-4c4b-a047-5b3544ad9826

The role of the mailbox plan is to be a template holding settings for mailbox properties. When you create a new mailbox, the new mailbox inherits settings from the mailbox plan chosen by Exchange Online. Most mailboxes are created along with new accounts via the Microsoft 365 admin center. When this happens, Exchange Online uses the license assigned to the account to select the mailbox plan to apply to the new mailbox. Table 1 shows the match-up between licenses and mailbox plans.

Default Plan

In the output for Get-MailboxPlan shown above, the Exchange Online Enterprise plan is marked as the default. If you create a user mailbox without a license, Exchange Online uses the default plan to populate its settings. Mailboxes which don’t need licenses, like shared and resource mailboxes, use the Exchange Online mailbox plan. An administrator can specify the mailbox plan to use when creating a new mailbox with the New-Mailbox cmdlet.

Updating Mailbox Plans

The Set-MailboxPlan cmdlet configures settings in mailbox plans while the Get-MailboxPlan cmdlet reports the settings. Because the idea behind mailbox plans is to configure basic mailbox settings, not every property configurable with the Set-Mailbox cmdlet is available in a mailbox plan. The settings cover:

• Mailbox quotas and warning thresholds.
• Message send and receive size.
• Deleted items retention period.
• Mailbox retention policy.
• User role assignment policy.

In this example, we use Set-MailboxPlan to update the Exchange Online enterprise plan to update the largest supported message size for send and receive to 125 MB, change the deleted item retention period from 14 to 30 days, and assign a new default mailbox retention policy.

Set-MailboxPlan -Identity ExchangeOnlineEnterprise -MaxSendSize 125MB -MaxReceiveSize 125MB -RetainDeletedItemsFor 30.00:00:00 -RetentionPolicy "General Mailbox Retention Policy"

Somewhat frustratingly, although Get-MailboxPlan returns a large set of mailbox properties and values, Set-MailboxPlan is unable to update most settings listed by Get-MailboxPlan. If you want to update a mailbox property outside the set supported by Set-MailboxPlan, you must run Set-Mailbox after creating the mailbox. For instance, you might want to write a value into one of the custom attributes.

Modifying the settings of a mailbox plan does not affect existing mailboxes. If you want to change settings for existing mailboxes, you’ll need to run the Set-Mailbox or Set-CASMailbox cmdlets. However, if the license assigned to a user mailbox changes, Exchange Online applies the settings for the relevant plan to the mailbox.

CAS Mailbox Plans

Each mailbox plan has a corresponding CAS mailbox plan. This mimics the relationship between Set-Mailbox and Set-CasMailbox where the first cmdlet updates essential mailbox settings while the second deals with connectivity. In this instance, the Set-CASMailboxPlan cmdlet allows administrators to control the following settings.

• Enabling Exchange ActiveSync.
• Enabling IMAP4 and POP3.
• OWA mailbox policy.

The protocol settings only disable or enable connections. They do nothing to force modern authentication (and as we know for Apple iOS clients, even when an email app supports modern authentication, it might not be used).

Here’s an example of disabling the POP3 and IMAP4 protocols in all mailbox plans. Given Microsoft’s well-founded focus on the elimination of basic authentication for email connectivity, it’s probably a good idea to disable these protocols for new mailboxes. You can always enable the protocols on a per-mailbox basis if someone convinces you that they have a good reason to use these ancient protocols (suitably upgraded for modern authentication).

Get-CASMailboxPlan | Set-CASMailboxPlan -PopEnabled $False -IMAPEnabled $False

You can check the protocol settings by running the Get-CASMailboxPlan cmdlet to return the different protocol settings:

Get-CASMailboxPlan -Identity ExchangeOnlineEnterprise | Format-List DisplayName, ImapEnabled, PopEnabled, MapiEnabled, ActiveSyncEnabled, OwaEnabled, OutlookMobileEnabled

Name                 : ExchangeOnlineEnterprise
ImapEnabled          : False
PopEnabled           : False
MAPIEnabled          : True
ActiveSyncEnabled    : True
OWAEnabled           : True
OutlookMobileEnabled : True

Surprisingly, you can’t control access to Exchange Web Services (EWS) through a mailbox plan. This is one of the protocols you’ll need to disable by running Set-CASMailbox after creating a mailbox.

To check how many mailboxes have each mailbox plan, we can check the plan registered for each mailbox. Note that the filter used to find mailboxes requires the distinguished name for the mailbox plan.

$MbxPlans = Get-MailboxPlan
ForEach ($Plan in $MbxPlans) {
   $Dn = (Get-MailboxPlan -Identity $Plan.Name).DistinguishedName
   # Find mailboxes with the plan
   [Array]$Mbx = Get-ExoMailbox -Filter "MailboxPlan -eq '$Dn'" -Properties MailboxPlan -ResultSize Unlimited
   If ($Mbx) {
     ForEach ($M in $Mbx) {
      $ReportLine  = [PSCustomObject][Ordered]@{ 
         Name           = $M.DisplayName
         UPN            = $M.UserPrincipalName
         Plan           = $Plan.DisplayName }
   $Report.Add($ReportLine) }
   }
} #End ForEach
$Report | Group Plan | Format-Table Name, Count

Name                     Count
----                     -----
ExchangeOnlineEnterprise    43
ExchangeOnline              17

Mailbox Plans Summary

Mailbox plans help Exchange Online to run a little smoother by making sure that some essential settings are in place for new mailboxes. It’s likely that you will need to do some further tuning of mailbox settings post creation and it would be nice if Microsoft expanded the set of updatable settings in mailbox plans to make the plans more powerful. At least PowerShell is available to fill the gaps left by Microsoft, a role that’s as important today as it was when Exchange 2007 was the first major server product to support PowerShell many years ago.

Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Some Manual Intervention Might Still be Required

Message center notification MC291056 (updated October 19) covering a simplified configuration for Domain Keys Identified Mail (DKIM) in Microsoft 365 Defender for Office 365 was a good reminder to check that all the domain names registered for my tenant were in good health.

DKIM uses a private key to include an encrypted signature in a domain’s outbound email. The public key for the domain is published in its DNS records. Receiving domains use the public key to decode the signature in messages to confirm that email comes from the domain it appears to be from rather than a spoof attempt. You can choose to use either 1024-bit or 2048-bit DKIM keys.

Microsoft configures DKIM for the tenant service domain automatically (the onmicrosoft.com domain assigned to each tenant). If a tenant has one or more custom domains, as most Office 365 tenants do, administrators should configure DKIM for each domain used for email (accepted domains).

All outbound email sent from Exchange Online is signed with DKIM. Exchange Online uses the service domain name if DKIM is not configured for a custom domain (like Office365itpros.com). It’s better for email authentication if the domain used for DKIM matches the domain sending email. Hence the logic behind the need to check that all your custom domains are configured.

Check Your Domains

The first place to check is the Domains section of Settings in the Microsoft 365 admin center. I look there to make sure that Microsoft 365 considers each of the registered domains to be healthy. This has nothing to do with DKIM because Microsoft 365 doesn’t take DKIM into account when it checks a domain. However, it’s good to make sure that Microsoft 365 doesn’t consider any of the domains to have problems with their basic set of DNS records. Interestingly, I noted that the details available for a domain now include the set of Groups and Teams which use the domain for their primary SMTP address (Figure 1).

Although this information is easy to find elsewhere, it’s good to have it here in case you want to remove a domain and need to reassign SMTP addresses to keep email flowing. In passing, the Apps section lists Azure AD registered apps which use the domain as a required URL.

A New DKIM Page

MC291056 notes the introduction of a new DKIM configuration page in the Microsoft 365 Security Center. The page lists the accepted domains for the tenant and allows administrators to select individual domains to enable or disable DKIM (Figure 2).

Everything was in order except for the tonyredmond.email domain. The domain works for email, but DKIM wasn’t enabled because the CNAME records for the domain weren’t published in DNS. This status is also viewable in PowerShell by running the Get-DkimSigningConfig cmdlet to check the domains:

Get-DkimSigningConfig  | ? {$_.Enabled -ne $True } | Format-Table Domain, Enabled, Status, LastChecked

Domain                            Enabled Status        LastChecked
------                            ------- ------        ------------
tonyredmond.email                   False CnameMissing  20/01/2016 18:58:29

Microsoft’s documentation explains what needs to be done. Because GoDaddy is the domain manager, I had to create the CNAME records in DNS for the DKIM signatures for the domain. You can get the values for the CNAME records using the Get-DkimSigningConfig cmdlet:

Get-DkimSigningConfig -Identity tonyredmond.email | Select -ExpandProperty Selector1CNAME
selector1-tonyredmond-email._domainkey.xxxxxx.onmicrosoft.com
Get-DkimSigningConfig -Identity tonyredmond.email | Select -ExpandProperty Selector2CNAME
Selector2-tonyredmond-email._domainkey.xxxxxx.onmicrosoft.com

A quick visit to GoDaddy’s Domain Manager and the two records were inserted (Figure 3).

After adding the records to DNS, it will take a little time to propagate the new data to Microsoft 365. An hour is usually enough. After Microsoft 365 knows about the CNAME records for DKIM for the domain, you can enable DKIM by moving Sign messages for this domain with DKIM signatures from Disabled to Enabled (Figure 4).

Of course, you can enable the domain using PowerShell.

Set-DkimSigningConfig -Identity tonyredmond.email -Enabled $True

Key Rotation

When a domain is enabled for DKIM, you can also configure it for key rotation. The documentation for the Rotate-DkimSigningConfig cmdlet says that you don’t need to do this because Microsoft 365 rotates private and public keys automatically to reduce the chance of an attacker compromising the keys used to sign messages. This assertion might cover the service domain, but I don’t see any problem in going ahead and rotating DKIM keys for all custom domains used to send email. Happy signing!

Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

Manage the Mailboxes of ex-Employees

Updated 19 September 2023

As reported in September, a listing of inactive mailboxes is now available in the modern Exchange Online admin center. This prompted some discussion about the management of inactive mailboxes, with some pointing to Microsoft’s recommendation to create an inactive mailbox retention policy to specifically manage inactive mailboxes. While retention policies are not a new feature as alleged by Microsoft, the page contains some good points to consider.

Shared mailboxes are also a valid method of retaining the mailboxes of ex-employees. I don’t discuss that alternative here.

Inactive Mailbox Retention Primer

Briefly, an inactive mailbox is a mailbox belonging to a deleted account. If you run the Get-ExoMailbox cmdlet to return the set of inactive mailboxes, you might see some with a value for the ExternalDirectoryObjectId property, the pointer which connects an Exchange Online mailbox to an Entra ID (Azure AD) account.

Get-ExoMailbox -InactiveMailboxOnly | Format-Table DisplayName, ExternalDirectoryObjectid

DisplayName                                  ExternalDirectoryObjectId
-----------                                  -------------------------
Dongli Pan 
Dylan Webb
Ed Banti
Frank Clonan
Imran Khan                                   b8eef43d-6854-4d77-9e03-745cf2e11e11

The mailboxes with ExternalDirectoryObjectId values belong to user accounts deleted within the last 30 days. During this period, administrators can recover the accounts and reconnect the mailboxes. Once the 30 days lapse, Entra ID permanently removes the account and Exchange Online nullifies the connection between the two objects.

Multiple holds (litigation, in-place eDIscovery, or retention policy) can be present for an inactive mailbox. These holds must be placed while the mailbox is active. Even after their user accounts disappear, inactive mailboxes remain in place until the last hold lapses. At that point, the Managed Folder Assistant cleans up and removes the mailbox.

Administrators can still recover data from inactive mailboxes or restore an inactive mailbox to connect it to a brand-new account, but the link between the original account and mailbox is gone. In a nutshell, inactive mailboxes are a great way for organizations with Office 365/Microsoft 365 E3 and E5 licenses to keep information for ex-employees until the need for their mailboxes disappear. You don’t have to pay anything for inactive mailboxes, no matter how much storage their primary and archives (including auto-expanding archives) occupy.

The Advantage of a Retention Policy for Inactive Mailboxes

A retention policy for inactive mailboxes is often used to gradually clear out information from inactive mailboxes on the basis that old information loses its value to the organization over time. To achieve this goal, the retention policy will:

• Apply only to inactive mailboxes. You can identify the mailboxes individually or by using a distribution list. Up to 1,000 individual inactive mailboxes can be added to a single (static scope) retention policy. If you want to add more, you can create multiple policies. Retention policies using adaptive scopes don’t have the same limitations, and you can identify inactive mailboxes by searching for their mailbox state. Because this process happens automatically and on an ongoing basis, you don’t have to worry about adding new inactive mailboxes to the retention policy.
• Remove content after a set period. Usually, this period ranges from six months to two years. In certain regulatory or legal conditions, an organization might retain mailbox contents for longer periods (I’ve heard of situations where inactive mailboxes are kept for ten years).

If you use a distribution list to add mailboxes to a retention policy with a static scope, remember that this is a one-time operation. Microsoft 365 reads the mailboxes from the list membership and adds them as separate Exchange locations to the retention policy. Any further additions or removals from the distribution list are not synchronized with the locations in the retention policy. Also, Microsoft 365 adds the managers of the distribution list to the policy. All of the above means that using a distribution list to populate a retention policy is strictly a method to add multiple locations to a policy rather than a means of maintaining the set of Exchange locations used by the policy.

The Managed Folder Assistant (MFA) processes inactive mailboxes along with active mailboxes. For instance, if the retention policy mandates the removal of information older than a year old, MFA will scan the mailbox to find any items older than a year and remove these items each time it processes the mailbox. Note that MFA might have to apply several retention policies to an inactive mailbox. If this is the case, the longest retention period applies.

Microsoft says that the advantages of having a specific policy are:

• You can configure the retention policy to retain mailbox content only as long as necessary to meet your organization’s requirement for former employees.
• It’s a good way to identify inactive mailboxes because the retention policy will only be applied to inactive mailboxes.

The first point is correct. The second is technically correct but depends on administrators applying the policy to mailboxes before deleting their user accounts. You can’t apply a retention policy to a mailbox once it becomes inactive. Any attempt through the administrative GUIs or PowerShell fails because the inactive mailbox is not recognized as a valid target.

Microsoft also makes the point that if you use a specific retention policy for inactive mailboxes, you can update the retention settings in one place to apply the new values to all inactive mailboxes. I think this is fair.

Finding Inactive Mailboxes with a Specific Retention Policy

I have doubts about Microsoft’s assertion that having a specific retention policy for inactive mailboxes is a good way to identify inactive mailboxes. Running Get-ExoMailbox -InactiveMailboxOnly is the best way to find the set of inactive mailboxes. To find the set of mailboxes to which a retention policy applies, you would have to examine the InPlaceHolds property of each mailbox to see if it is stamped with the identifier of the retention policy. Something like this would work:

# Find the identifier for the retention policy
$Policy = Get-RetentionCompliancePolicy -Identity "Retention Policy for Inactive mailboxes" | Select-Object -ExpandProperty ExchangeObjectId
# Build search string
$CheckGuid = "mbx" + $Policy.Guid.SubString(0,8) + "*"
[array]$Mbx = Get-ExoMailbox -InactiveMailboxOnly -Properties InPlaceHolds
If (!($Mbx)) {Write-Host "No inactive mailboxes found - exiting"; break} 
Write-Host ("Processing {0} inactive mailboxes..." -f $Mbx.Count)
ForEach ($M in $Mbx)  {
    $Holds = Get-ExoMailbox -Identity $M.UserPrincipalName -Properties InPlaceHolds -InactiveMailboxOnly | Select-Object -ExpandProperty InPlaceHolds
    If ($Holds -like $CheckGuid) { 
        Write-Host ("The in-place hold for Inactive mailboxes applies to mailbox {0} ({1})" -f $M.DisplayName, $M.UserPrincipalName )
    }
} #End ForEach

Note that you’ll need to run the Connect-IPPSSession cmdlet first to connect to the compliance endpoint before running Get-RetentionCompliancePolicy to fetch the identifier for the retention policy. Running this PowerShell will report the exact set of inactive mailboxes assigned the retention policy, so there’s some value in that. Then again, if you use the one retention policy and assign it to mailboxes before deleting their Azure AD accounts, the Get-ExoMailbox cmdlet will return the same set.

Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Read Receipts Is a Very Old Email Feature

I haven’t thought about email read receipts for years. It’s a very old email feature that goes back to the days when unreliable SMTP and X.400 connections linked organizations together and you never quite knew if email got through to its destination. The reliability of computer networks today means that read receipts are less important, or maybe it’s just that other communication methods have replaced some email traffic, like Teams. The introduction of read receipts for Teams in early 2020 doesn’t count because the read receipt for chats is more of a “seen” indicator than a message returned to a sender to confirm that an addressee has opened an email (Figure 1).

Helping a Police Chief

Which brings me to a request from an Office 365 for IT Pros reader. Apparently, a police chief is sick and tired that their email sent to some recipients is not being responded to. They want to know when the addressees open the messages he sends. The request was to be able to turn on automatic read receipts for mailboxes and disable the ability of users to change the setting.

Read receipt is a message option, like delivery receipt (confirming the delivery of a message to a mailbox). When set, the read receipt shows up in the message properties as a Disposition-Notification-To header with the return address to receive the read receipt (Figure 2). A blast from the past EHLO blog post from 2011 explains more.

The presence of the Disposition-Notification-To header is what prompts clients to check if they should ignore the request, send the receipt automatically, or ask the user if they’d like to send the receipt. The immediate problem in satisfying the user request is that Exchange Online considers read receipts to be a client-side function. In other words, the action to respond to the sender is invoked when a recipient uses a client to open a message with a read receipt requested. Clients have different settings to control how to respond.

OWA Read Receipt Settings

Take OWA for example. It’s easy to configure the user settings for read receipts through the Message handling section in OWA settings (Figure 3).

There’s also an Exchange Online PowerShell cmdlet to do the job. For instance, let’s assume that we want a set of users to always send read receipts when requested. This code uses the CustomAttribute12 property to hold the value “RR” to indicate that a mailbox should be in the set. We can use a server-side filter to find the mailboxes and call the Set-MailboxMessageConfiguration cmdlet to update the read receipts setting.

# Find mailboxes to update and then update their read receipt setting to always send read receipts
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter {CustomAttribute12 -eq "RR"}
If ($Mbx.Count -eq 0) {Write-Host "No mailboxes found"; break}
ForEach ($M in $Mbx) {
   Write-Host "Setting mailbox read receipt configuration for" $M.DisplayName
   Set-MailboxMessageConfiguration -Identity $M.UserPrincipalName -ReadReceiptResponse AlwaysSend }

Using RBAC to Remove Read Receipt Settings from OWA

Although administrators can update user mailbox settings to control read receipts, it does nothing to stop users changing the read receipt options through OWA settings. To block that happening, we need to remove the read receipt options from the GUI. Exchange Online has a well-developed role-based access control (RBAC) system to control features available to users. RBAC works through the user role assignment policy set on user mailboxes. These policies enable or disable features by controlling the cmdlets available to users. For instance, I’ve written in the past about how to use RBAC to stop people updating their OWA autosignature.

To stop users changing the read receipt setting, we need to:

• Create a new RBAC role based on the regular set of user options.
• Remove the entry in the role for the cmdlet used to update read receipt settings (Set-MailboxMessageConfiguration).
• Remove the entry in the role for the cmdlet used to fetch add display the read receipt settings (Get-MailboxMessageConfiguration).
• Create a new user role assignment policy containing the roles usually granted to users with the exception that we replace the base options with the edited version which blocks the ability to update the read receipt settings.

All of this sounds complicated, but it’s a system that worked well since its introduction in Exchange 2010. Here’s the PowerShell code to do the work listed above:

New-ManagementRole MyBaseOptions-NoRR -Parent MyBaseOptions

Set-ManagementRoleEntry MyBaseOptions-NoRR\Set-MailboxMessageConfiguration -Parameters ReadReceiptResponse -RemoveParameter

Remove-ManagementRoleEntry MyBaseOptions-NoRR\Get-MailboxMessageConfiguration

New-RoleAssignmentPolicy -Name PolicyWithNoRR -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoRR -Description "User Role Assignment Policy to block users updating read receipt settings"

The last thing to do is to assign the user role assignment policy to the mailboxes we want to block. This is done with the Set-Mailbox cmdlet:

Set-Mailbox -Identity Chris.Bishop -RoleAssignmentPolicy PolicyWithNoRR

Thirty minutes or so later, the new policy will take effect. You’ll know that it works if you go to OWA settings and don’t see the options to update the read receipt settings (Figure 4).

To bring the solution together, you can add the Set-Mailbox command to the code described above to update the read receipt setting and assign the user role assignment policy for the set of target mailboxes.

ForEach ($M in $Mbx) {
   Write-Host "Setting mailbox read receipt configuration for" $M.DisplayName
   Set-Mailbox -Identity $M.UserPrincipalName -RoleAssignmentPolicy PolicyWithNoRR
   Set-MailboxMessageConfiguration -Identity $M.UserPrincipalName -ReadReceiptResponse AlwaysSend }

Controlling Read Receipts in Outlook

Our problem is solved if OWA is the sole client in use. Unhappily, that’s probably not the case. Clients like Outlook for Windows, Outlook for Mac, and Outlook mobile might be in use, as might third-party clients. Every client has its own method to control the processing of read receipts. For instance, Figure 5 shows the settings in Outlook for Windows (click to run version).

For historic reasons, most Outlook for Windows settings are stored in the system registry. A check of the settings available in the administrative templates for Outlook reveals that the read receipts are controlled by the receipt response  DWORD value at HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Mail. The values are:

• 0: Always send a response.
• 1: Never send a response.
• 2: Ask the user before sending a response.

You can update the value manually by editing the registry (Figure 6), which is fine for a test case. In production, you’re likely to use a group policy object (GPO) or other technique to deploy the policy setting to client workstations.

Once the policy is in place, Outlook greys out the options to control read receipts.

Client-Side Feature Dependant on Client-Side Controls

In summary, read receipts are a client-side feature invoked by the presence of the Disposition-Notification-To message header. Because it’s a client-side feature, any attempt to force the client to process read receipts in a particular manner depends on the controls available in a client. We can satisfy the police chief’s request for OWA and Outlook for Windows. I see no way to do this for Outlook mobile and didn’t investigate Outlook for Mac or any of the many other email clients which can connect to Exchange Online using Exchange ActiveSync (EAS), IMAP4, or POP3 (hopefully without using basic authentication). Now you know what you should look for, checking how to deal with other clients is an exercise for the reader!

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Client-Side Completion for a Server Feature Delivered in April 2021

Exchange Online delivered support for sending email from proxy addresses (mailbox aliases) in April 2021. At least, the server-side part of the equation was happy to process messages sent using proxy addresses. It can take a little time for clients to catch up. A proxy address is an SMTP address assigned to a mailbox. Usually, people use the primary SMTP address for all outgoing messages (and the primary address is often the same as their Microsoft 365 sign-in address, or user principal name, so it’s easily remembered). Secondary proxy addresses are used in situations like:

• Mergers and acquisitions: Email addresses like the ones used at an acquired company.
• Life events: Email addresses with previous versions of someone’s name (like a married surname).
• Organizational addresses: Email addresses with functional titles, such as a departmental manager.

Exchange Online can deliver email addressed to any proxy address to the mailbox.

Supposed to Happen in May

MC252942 (published April 27) announced that OWA would support sending from proxy addresses in early May. Well, that didn’t happen, which was surprising because OWA is usually at the forefront of delivering new features for Exchange Online. Being able to develop and publish new functionality more quickly than Outlook desktop can is one of the reasons why OWA is core to Microsoft’s One Outlook initiative.

Microsoft 365 roadmap item 59437 describes the feature as “rolling out” starting in August. I haven’t seen the new setting appear until this week, so it’s possible that its deployment is still in progress.

OWA Option to Select Proxies

It was possible to send email previously with OWA using a proxy address by typing the proxy address in the From field in the new message screen. However, people often don’t know what proxy addresses are available to them, so while OWA could send messages from proxies, it wasn’t as easy as it could be. This has now been addressed with the arrival a new setting in OWA options to allow users to choose the set of proxy addresses they would like to use (Figure 1).

The address at the top of the list is the primary SMTP address for the mailbox. In my case, it appeared twice (a bug). A user can’t unselect their primary SMTP address as it remains the default for sending. If they want to use a different primary address, they’ll have to ask an administrator to update their account. It’s good practice to make the previous primary address a secondary proxy to ensure that Exchange Online can deliver responses or new messages sent to that address.

It’s wise to check the Always show From option in OWA settings as this will make it easier to select one of the chosen proxies.

Sending From a Proxy

Once you’ve selected the set of proxy addresses that you’d like to use (and made sure that the From field is exposed), it’s easy to select a proxy to use because OWA shows the available set in a drop-down list (exposed by clicking the From button) in the compose message screen. The list (Figure 2) includes:

• The primary SMTP address for the mailbox (the default).
• The proxy addresses selected in OWA options.
• Other addresses previously used to send email. Typically, these are addresses for other user and shared mailboxes where the user has Send As or Send on Behalf of permission.
• The option to add another email address (for instance, for a mailbox you’ve just been given the permission to send from).

Select the proxy to use and compose the message as normal. When Exchange Online sends the message, it populates the From and Return-Path values in the message header (Figure 3).

Small Changes Make a Difference

There’s nothing earthshattering in this update. The Exchange transport system has always been able to deliver email addressed to any valid proxy address assigned to a mailbox. The heavy lifting occurred in April when Exchange Server updated transport to allow it to accept messages sent from proxy addresses. It’s nice that OWA is making it easier for people to use the feature.

Keep up to date by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Artificial Intelligence at its Finest

In message center MC281368 (August 27), Microsoft announced the introduction of “tone detection” as a new capability within the Microsoft Editor component in OWA. Microsoft explains that tone detection will “offer writing refinements to suggest changes to tone. These suggestions will allow the user to communicate more clearly and in a desired tone to deter misinterpretation.” In other words, Editor monitors what you type as you compose messages, and if it considers that your tone is getting a tad snarky or offensive, Editor steps in with suggestions to make your text less provocative with an “improved conversational tone.” This is Microsoft 365 roadmap item 86539.

Microsoft said that the roll-out of tone detection should finish at the end of September 2021, so the feature should be available to all tenants now. However, “English – United States” appears to be the only language which supports tone detection in the set of Editor options exposed by OWA. This is usual as it takes time to refine the basic models to detect certain kinds of text in different languages.

Behind the Scenes

Microsoft Editor (a writing assistant that provides spelling, grammar, and other intelligent writing suggestions) already analyzes text as users type messages in OWA and the Microsoft 365 apps for enterprise to deal with spelling and grammatical errors. In 2020, Microsoft introduced text predictions, first in OWA and later in the desktop apps. Predicting what text comes next is a complicated business and depends on plenty of server horsepower to generate and refine the trainable algorithms from user input. Recurrent neural networks analyze the patterns in user writing to recognize how people put sentences and phrases together. This knowledge creates learning models to deliver the suggestions made as Editor observes what’s input into messages. Over time, the models improve as they process more messages. After a while, Editor will know the probability that someone will follow one phrase with another in email and how they stitch words together in sentences.

Outlook stores model data in a hidden folder in user mailboxes. The data is inaccessible to clients and isn’t shared with Microsoft. The model data is anonymized and does not hold personal details and “no message content is transmitted or stored outside of your organization,” which is how it should be.

Enabling Tone Detection

Not everyone is impressed with the thought of intelligent software analyzing and improving their writing. Fixing spellings and making sure that crass grammatical errors don’t creep into text is fine but telling someone that an automated assistant can improve the tone of their writing is a different matter.

Before Editor applies tone detection, you must enable it in the Editor settings. In a message compose screen, you can expose the Editor settings by clicking the Editor icon (if not, click the […] menu and choose Editor). Tone detection is the last option. So far, “Politeness” is the only setting under tone detection (Figure 1). The fact that tone detection gets its own category makes me think that Microsoft has some additional settings in the works.

After consenting to allow Editor to monitor message text for politeness, we can try things out by creating a new message complete with some potentially rude statements (Editor might not share your definition of what is rude). To be sure to get Editor’s attention, I composed some blunt and forthright commentary on the usefulness of a recipient (Figure 2).

Editor duly stepped in to advise I might be impolite and suggested some alternate text, and that’s when the weakness of the algorithm revealed itself. The suggested alternative did not capture the meaning or intent of the original text. I said something impolite under my breath and tried again. This time Editor was more successful, and the suggested text matched the impolite version more closely (Figure 3).

Time Needed for Model to Improve

My email writing style tends to be blunt. I don’t like wasting words (too many articles to write). As such, I thought that Editor would pick up more instances of impoliteness than it has done over a week’s use. As noted above, some of the recommendations are off base. I think the number of flawed suggestions will decrease over time. At least, that’s the promise of artificial intelligence and learning models, isn’t it?

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Expanding the Scope of Microsoft Viva

Message Center notification MC282545 (published September 2) announces the expansion of the Microsoft Viva brand to replace the Insights moniker used for MyAnalytics, Outlook Insights, and the Cortana daily briefing email. It’s all part of the strategy to bring the technology used to analyze signals gathered from user activity within Microsoft 365 under the Microsoft Viva brand.

Viva Insights is the new name in town for insights derived from user email and calendar activity. This trend has already surfaced in the Viva Insights app for Teams, which surfaces the same user-based analysis of behavior as available in MyAnalytics, wrapped up with some mediation and mindfulness videos and audios from Headspace and some additional functionality for a virtual commute to close the working day.

What’s Happening in the Viva Insights Rebrand

In practical terms, the announcement means:

• The daily briefing message from Cortana now comes from Viva. Microsoft says that the content will be expanded with recommendations to help users prepare for the day and week ahead.
• The MyAnalytics digest will now come from Microsoft Viva and be delivered monthly rather than weekly. The first edition of the digest (Figure 1) turned up in my (targeted release) tenant. on September 5. Microsoft says that the new digest will “aggregate insights across these four outcomes: focus, wellbeing, network, and collaboration.” Like the weekly digests from MyAnalytics, the monthly digests are injected directly into user mailboxes and don’t pass through the Exchange Online transport system, which means that they’re not subject to inbox or transport rules.

• A new Viva Insights home page will be available to Microsoft 365 users.
• The Outlook Insights add-in will be rebranded as Viva Insights.
• The MyAnalytics settings available in the Microsoft 365 admin center (Figure 2) to control the defaults for new accounts will soon have the Microsoft Viva branding. The same will happen for the MyAnalytics user dashboard where individual users can see insights derived from their activity and control if they can access the dashboard, receive the monthly digest, and use the Outlook insights add-on.

Microsoft says that the changeover and rebranding should be complete in all tenants by the end of November.

Controlling User Insights Settings

The Viva rebranding will respect existing user and admin settings. To control the settings for individual users (mailboxes), you can:

Turn Viva Analytics on or off for individual mailboxes by running the PowerShell code in this article. Users can re-enable Analytics afterwards if they wish. As explained in the article, administrators can use the Set-MyAnalyticsFeatureConfig cmdlet to remove access to individual features. For instance, many users don’t like the twice-monthly digest message containing an analysis of personal work patterns. You can block the digest email while allowing users access to the Analytics dashboard and Outlook add-in by running a command like:

Set-MyAnalyticsFeatureConfig -Identity Vasil.Michev@office365itpros.com -PrivacyMode "opt-in" -Feature digest-mail -IsEnabled $False

Remove the Insights by MyAnalytics service plan from individual user licenses using the PowerShell script described in this article. It’s likely that Microsoft will rename the service plan in the future to reflect the Viva brand. Users cannot reenable Analytics after the service plan is removed from a license.

We don’t know yet if Microsoft plans to rename the Set-MyAnalyticsFeatureConfig and Get-MyAnalyticsFeatureConfig cmdlets (in the Exchange Online management PowerShell module) used to control individual mailbox settings. It wouldn’t surprise me if this happened or if Microsoft combined the controls with those exposed by the Set-VivaInsightsSettings cmdlet, currently only used to configure access to the Headspace feature.

Item Insights

Although the information extracted from user email and calendar activity now comes under the aegis of Microsoft Viva, the same is not true (yet) for the document (item) insights used in apps like Delve and the Office 365 profile card. If you want to disable item insights for user accounts, you need to update the tenant configuration using the Microsoft Graph by following the advice contained in this article.

Sensible Rebranding?

Branding exercises can be confusing (think of the absolute clarity Microsoft achieved when it renamed Office 365 Pro Plus to Microsoft 365 apps for enterprise). In this instance, it probably makes sense to bring everything relating to email and calendar insights together under the Viva brand. Come November, it probably won’t make a different as those who use insights won’t care too much that they then have the Viva moniker.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Part of New Strategy to Move SMTP Connections to TLS 1.2

On August 18, Microsoft announced that they will disable Transport Layer Security (TLS) 1.0 and 1.1 connections to Exchange Online “in 2022.” SMTP clients will need to use TLS 1.2 to connect to Exchange and send email. This is the latest step in a journey which began in 2018 when Microsoft began advising customers to move away from TLS 1.0 and 1.1 on the basis that these versions of the protocol have known vulnerabilities. Effective October 31, 2018, Microsoft deprecated TLS 1.0 and 1.1 for Microsoft 365. Of course, deprecation doesn’t mean removal or stopping. It’s an intention that something will be removed in due course.

The Exchange Online team began to publish advice to customers to help them analyze TLS usage in their tenants in March 2019. At that point, June 2020 was the target date for disabling TLS 1.0 and 1.1 across Office 365. As it turned out, Exchange Online ceased support for TLS 1.0 and 1.1 in July 2020. The next step was the publication of MC229914 on 14 December 2020 where Microsoft announced they would gradually remove support for TLS 1.0 and 1.1 connections starting January 11, 2021, saying:

“We’ll be gradually making the change and so initial impact could be messages getting delayed and only when the change is completed will messages fail to be delivered to their destinations.”

Alas, the best-laid plans of mice and men sometimes run into roadblocks. Microsoft could not proceed, possibly due to the combination of customer pushback and a global pandemic.

Microsoft’s New Plan to Encourage TLS 1.2

Although Exchange Online no longer supports TLS 1.0 and 1.1, some SMTP clients still use these versions to send email to Exchange Online mailboxes (Microsoft refers to “significant usage.” To overcome the problem of customers which haven’t been able to move away from TLS 1.0 and 1.1, Microsoft’s new plan is to:

• Stop supporting TLS 1.0 and 1.1 connections for the regular smtp endpoint used to accept inbound email to Exchange Online (smtp.office365.com). This is what will happen sometime in 2022.
• Allow tenants with good business reasons to continue to use obsolete TLS to accept the risk by configuring their tenant to accept these connections.

In other words, Microsoft is transferring responsibility to tenants to decide whether they want to risk accepting inbound email which might be a potential vector for attack. The risk is justifiable when organizations need some extra time to update applications (including email clients) and hardware devices which depend on TLS 1.0 or 1.1 to connect to Exchange Online to send email via SMTP.

Tenants that decide to take the risk must:

• Use PowerShell to run the Set-TransportConfig cmdlet in the Exchange Online management module:

Set-TransportConfig -AllowLegacyTLSClients $True

• Configure clients to use a new endpoint: smtp-legacy.office365.com.

I’m sure Microsoft is betting that most tenants will simply switch over to TLS 1.2. Those that need to keep using the older protocols can do so while they upgrade components (including PowerShell scripts). Overall, it seems like a plan that can work because organizations get to choose what they do.

Blocking Old TLS Connections Now

Tenants that want to switch early and block obsolete TLS connections can do so now by running Set-TransportConfig to update the setting to $False (it is $True by default until Microsoft switches off TLS 1.0 and 1.1. Before doing this, it’s a good idea to check the Inbound messages report in the Mail flow reports section of the new EAC (Figure 1). When I checked, I discovered that 2 of 700 messages delivered in the last week didn’t use TLS 1.2.

Given this level of traffic and that most inbound email to my tenant comes from other Office 365 tenants and well-known mail servers which use TLS 1.2, I am happy to force TLS 1.2. I therefore ran the command:

Set-TransportConfig -AllowLegacyTLSClients $False

The Sting in the Tail

Now that I’ve removed TLS 1.0 and 1.1 connectivity for my tenant, I won’t be affected by what Microsoft charmingly call a “new submission error speedbump,” planned for introduction in September 2021. When the speedbump is in place, Exchange Online will begin rejecting a small (unspecified) percentage of attempts to make SMTP connections using TLS 1.0 or 1.1 and issue this error message.

421 4.7.66 TLS 1.0 and 1.1 are not supported. Please upgrade/update your client to support TLS 1.2. Visit https://aka.ms/smtp_auth_tls

This is a temporary error and clients can retry the connection. Given that Exchange Online will block only a small percentage of connections, it’s likely that the next attempt to connect will succeed. However, that small percentage of declined connections will increase over time to gradually make it more painful for clients using the older protocols to connect to Exchange Online. As Exchange Online declines more connections, clients will experience delays in transmitting email. In some cases, depending on the client’s error handling, email might not get through until someone updates the client to handle frequent retries (or even better, upgrade the client to TLS 1.2.

Eventually, Microsoft will pull the plug on TLS 1.0 and 1.1 for smtp.office365.com and it’s then up to the tenant to decide to continue with the old protocols or bite the bullet and transition to TLS 1.2. Should be a fun time ahead.

Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

Now Generally Available for Microsoft Defender for Office 365 Customers

The July 27 announcement of the General Availability of Safe Links for Teams is a welcome development. What it means is that if your tenant has Microsoft Defender for Office 365, you can update your Safe Links policy to include real-time checking of links posted to Teams chats and channel conversations.

Licensing Requirements

Licensing Microsoft Defender for Office 365 can be a little confusing. Two plans are available, both of which build on Exchange Online Protection (EOP):

• Office 365 E3 and below have Exchange Online Protection. These tenants can license Defender for Office 365 plans as standalone options.
• Microsoft 365 Business Premium includes EOP and Defender for Office 365 Plan 1.
• Office 365 E5/A5 and Microsoft 365 E5 includes EOP and Defender for Office 365 Plan 2.

Microsoft sometimes refers to the “security ladder from EOP to Microsoft Defender for Office 365” as a way of describing how the features in the Defender plans build on what you get in Exchange Online Protection (Figure 1).

In this case, you need at least Microsoft Defender for Office 365 Plan 1 to use Safe Links protection for Teams.

Configuring Defender for Teams

The Safe Links policy is managed through the Policies & rules section of the Microsoft 365 security center. To edit the policy, open Threat policies and select Safe Links. The important change is to set Select the action for unknown or potentially malicious URLs within Microsoft Teams to On (Figure 2).

At the same time, you should review the other Safe Links policy settings to make sure that they’re what you want. Three important settings used to detect and protect against malicious links in email also apply to links in Teams messages:

• Apply real-time URL scanning for suspicious links and links that point to files. In other words, before sending a user to a site, check that the link is not dangerous. If it is, display a warning.
• Do not track user clicks. This setting is normally off and isn’t needed unless you want to track user clicks against links.
• Do not allow users to click through to original URL. If a user clicks on a dangerous link, they see a warning page (Figure 3). You don’t want to allow people to click through the warning to open the dangerous page, so make sure that this setting is on.

You can also see in Figure 2 that I’ve opted to use organization branding on the warning page. The branding used here (and shown in Figure 3) is taken from the tenant’s browser theme.

Usually, Teams calls the default browser to open a web link and that’s when Defender steps in to display the warning page. If a malicious link is used in a channel tab (which means that someone has created a web site tab for that link), Teams opens the warning page in the tab and doesn’t call the browser. If Defender passes the link as safe, Teams opens the page as normal.

Nice Extension into Teams

It’s good that Microsoft has extended Safe Links protection into Teams. Although I suspect that most bad links will continue to arrive in user mailboxes (if not detected and placed in quarantine by Exchange Online Protection), it’s entirely possible that some users will share problematic links through Teams chats or channel conversations. If they do, and your tenant has Defender for Office 365 with a properly configured Safe Links policy, those links will be blocked. What’s not to like about that?

Learn about protecting Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant.

Stopping a Flood of Email to Mailboxes

Microsoft began the process of clamping down on high-volume mailboxes earlier this year. The process is still rolling out as Microsoft gradually imposes the limit (which was always documented but not enforced). Mailboxes which receive more than 3,600 messages in an hour are blocked from receiving further messages for an hour and senders receive a non-delivery notification with code 5.2.122. This limit applies to messages received from any source, including people in the same tenant, and is designed to stop Exchange Online mailboxes filling up because of problems with automated mailers, like those used by applications to notify people about the progress of jobs.

Clamping Down on Individual Senders

In message center notification MC272450 posted July 23, Microsoft says that they will introduce a further restriction in September 2021. Like the previous restriction, the reason specified is to block single-sender mail storms and deter DoS attacks. The big difference is that the focus moves from messages coming from all sources to messages coming from a specific external source. To do this, Exchange Online tracks sender-recipient pairs (SRPs). As messages arrive in a mailbox, Exchange Online notes the sender and builds a table of SRPs. If a single sender sends more than 33% of the overall threshold (1,200 of 3,600), Exchange Online stops accepting messages from that sender to the mailbox for an hour. The mailbox continues to receive messages from other senders.

The exception is that the limit does not apply to messages sent from an Exchange Online mailbox in the same tenant. The limit does apply to:

• Messages from Exchange on-premises mailboxes in the same tenant.
• Exchange Online messages from other Office 365 tenants.
• Messages from any other email system.

Blocked senders will receive non-delivery notifications with a 5.2.121 code. The mailbox owner will get a message to tell them that their mailbox has stopped receiving messages from the sender for an hour (the countdown starts once Exchange Online detects the problem). and administrators will be able to see the affected mailboxes in the Mailbox exceeding receiving limits report (aka Hot Recipients) in the Reports (Mail Flow) section of the Exchange admin center (Figure 1).

Microsoft suggests that Exchange administrators ask the mailbox owners why they receive so much email from the blocked sender.

Time to Review Email Generation by Applications

Microsoft says that this change will stop a malicious user blocking email flow to a mailbox. In other words, an attacker can’t try to stop someone receiving legitimate email by generating a flood of email to their mailbox. They also note that only a small percentage of mailboxes hut the SRP limit currently. My feeling is that the origins of most email likely to be blocked by the SRP limit come from applications generating frequent notifications and other updates. The tightening of the overall limit and the introduction of the new SRP limit is a good wake-up call for organizations to review the rate of email generation by applications and remove messages which are not strictly necessary.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

But It’s All Marketing Brown Smelly Stuff

I had a quiet chuckle when I read Microsoft’s assertion that the release of shared calendar improvements in Outlook for Windows is “arguably the biggest change to Outlook for Windows since its initial release in 1997.” This hyperbole exists only in the minds of Microsoft marketing and is absolutely untrue. It amuses me that sites like the Verge and ZDnet give credence to the claim.

What’s true is this: after nearly twenty-five years of sharing calendars, Microsoft is gradually getting control of the mess that allowing other people access to your calendar can be. The new model extends across OWA and Outlook for Mac (both there now) and is reaching Outlook for Windows slowly. That’s goodness, even if the Outlook mobile team is trying to forge their own path with delegate access (only for the Inbox for now). I’m sure that my MVP colleague, Ingo Geganwarth, who spends more time than anyone else I know battling with delegate issues, will be happy with the progress.

What Microsoft doesn’t say is that the changes only apply to Exchange Online. There’s no mention of Outlook for Windows perpetual versions connected to Exchange Server. That’s a pity, but it’s not unexpected.

Good Progress in Calendaring

There’s no doubt the Outlook calendaring team is doing some nice work, such as adding the new board view to the calendar in OWA. Work has also been done to take the OWA version of the Room Finder across to Outlook for Windows as part of Microsoft’s One Outlook initiative where common components are shared across clients. Some of my favorite engineering contacts at Microsoft work on Outlook calendaring, so I don’t wish to be unkind about their work.

But fixing something which should have been fixed a long time ago isn’t even close in the pantheon of major developments in Outlook for Windows. When I consider the most important and far-reaching changes since Outlook 97 debuted, I think of things like:

• Drizzle mode synchronization, introduced in Outlook 2003 along with some extra network smarts, gave Outlook the ability to synchronize a complete mailbox and to do so intelligently with high-priority threads used for outgoing messages and lower-priority threads synchronizing folders in the background.
• Autodiscover gave Outlook an auto-configuration capability by delivering a manifest of available services which clients could then connect to. Teams uses Autodiscover to learn how to find Exchange resources like user calendars.
• Outlook Anywhere allowed Outlook clients to connect to Exchange across the Internet without needing a VPN. Its successor, MAPI over HTTP, connects Outlook clients to Exchange Online. Without these protocols, Outlook for Windows wouldn’t be a viable Office 365 client.

I’m sure you can come up with your own candidates for Outlook stardom. The point is that many fundamental technical advances have happened in the past which are still in use and have proven their worth over long periods. I’m sure the change in shared calendar behaviour will improve matters, but the jury’s still out whether it is a change of import.

Oh well. Marketing is marketing. What do you think is the most important change made to Outlook since 1997?

Sixty Times Larger Than in 1996

Browsing the pages of my 1996 book on Microsoft Exchange Server 4.0, I discovered that the average size of an email 25 years ago was in the 2-4 KB range. This got me thinking about what the current average might be, so I checked my Inbox by running the Get-ExoMailboxFolderStatistics cmdlet to retrieve the total size of the folder and the number of items in it. The code I used is as follows:

$CheckName = Read-Host "What User Mailbox Shall I Check?"
If (Get-ExoMailbox -Identity $CheckName) {
   $Stats = $Null
   Write-Host "Checking Mailbox for" $CheckName...
   $Stats = Get-EXOMailboxFolderStatistics -Identity $CheckName -FolderScope Inbox | Select Name, ItemsInFolder, FolderSize ,@{Name="FolderSizeBytes"; expression={((($_.FolderSize -replace '^(.*\()(.*)(\sbytes\))$','$2').Replace(',','')) -as [int])}} 

    Write-Host ("Results for mailbox {0}: {1} Inbox items {2} folder size with an average message size of {3} KB" -f $CheckName, $Stats.ItemsInFolder, $Stats.FolderSize.Split("(")[0], [math]::round(($Stats.FolderSizeBytes/$Stats.ItemsInFolder)/1KB,2))}

The code looks complicated, but it’s not too bad. We fetch some of the properties returned by Get-ExoMailboxFolderStatistics and put them into a variable. One of the properties is calculated to return the total number of bytes in the folder as a integer variable. We then calculate the average size of a message and write out what we found.

In any case, the result is that the average size of messages in my Inbox is sixty times larger than they were in 1996. Other mailboxes will likely show different results (run the code against your Inbox to see what it reports) as it all depends on the volume of traffic and the type of messages you receive. However, I think everyone can agree that the size of messages sent and received today are larger than they were in the past.

Reasons for Swelling Messages

The reasons why today’s messages are much larger vary across organizations. However, I think four core reasons exist:

• More Headers: Today’s SMTP traffic include more message headers than ever before.
• Rich Editors: Old text-only messages are now jazzy HTML rich-text messages.
• Fat Attachments: Capable networks make users think nothing about sending a 25 MB PowerPoint presentation in email. They wouldn’t do this if connected on a dial-up telephone link.
• User Habits: We’re lazy and reply-all to messages which include all previous replies.

SMTP messages used to include just enough headers to get the email through. Now, a bunch of new headers exist, some of which are essential to authenticate that email comes from the right source and isn’t spam (DMARC, ARC, SPF, etc.). Other x-headers are added by servers like Exchange to track the progress of messages, include anti-spam reports, and measure latency. Fire up Outlook’s Message Header Analyzer add-in to examine the headers in a message to see what I mean.

Rich Format Email

Rich editors mean that text and formatting instructions must be sent where plain text was the norm. Embedded graphics drive up message sizes, including the autosignatures inserted by users and organizations. Complex autosignatures with corporate logos and social networking links add even more to message sizes, especially when organizations lose control and insist that every message goes out complete with graphic-intense marketing messages.

It’s lucky for everyone that servers are so fast and networks so capable that they can deal with the processing overhead required to transport messages in and out of Exchange Online and between Microsoft’s datacenters and email servers elsewhere across the internet. I’m not sure that Exchange’s original IMC (Internet Mail Connector) would have been up to the task.

The Size and Intelligence of Notification Email

Even relatively simple notification messages generated by applications can be huge. For instance, a brief review of notifications from different Microsoft 365 apps telling me that people are trying to contact me resulted in the following sizes:

• LinkedIn: 174 KB
• Teams: 265 KB,
• Yammer: 472 KB (Figure 1).

To be fair to Yammer, the latest generation of notification email are graphically rich and interactive to allow recipients to respond within the email client. The code necessary to enable this functionality increases the amount of HTML carried around in messages. It’s a price we must pay for intelligent messages.

Cloudy Attachments and Bad Habits

Microsoft’s efforts to convince users of the goodness of sending “cloudy attachments” (links to files in OneDrive for Business and SharePoint Online) are showing signs of progress, especially within Office 365. Consistent sharing links, the ability to co-author (now even when documents are protected with sensitivity labels), and easy access to files stored in other tenants mean that users send an increasing number of links where files were once attached. However, the default option for many is still to attach files (or rather, a copy of a file), and once that happens, the average size of message swells quickly.

People are creatures of habit, which is one reason why we continue to send traditional attachments. We also tend to take the path of least resistance, which is why we reply to messages without thinking about the long trail of previous replies sent along with our response. The outcome is that a message at the end of a thread might be 1 MB, roughly 10% of which is useful non-repetitive information.

Large Cloud Mailboxes Required

The world of email is very different to what it was when Exchange 4.0 appeared in 1996. I doubt anyone today could cope with the 20 MB mailbox quota often assigned to users in those days. Given the growing size of messages, it’s a good thing that Microsoft makes generous mailbox quotas available for Exchange Online users. Even so, if the trend of ever-swelling messages continues, we’ll all need 200 GB mailboxes soon.

The Office 365 for IT Pros eBook hasn’t covered developments in Exchange mailbox technology since 1996. Some of our authors remember back that far, but mostly we live in the modern world and track new developments as they happen inside Office 365.

Scheduling Done Right

We’ve come a long way since the early days of Schedule+. Much development has been done to refine and smoothen the way calendar meeting requests are handled across the range of Outlook clients and now Teams. However, I still receive more questions about calendars than any other aspect of Teams or Outlook. The requests vary from how to add a disclaimer to meeting requests, or removing items from calendars with PowerShell, to figuring out who receives invitations to Teams meetings. It’s a never-ending procession of queries.

Automatic Processing

A recent question covered the response received for a meeting request sent to a room mailbox. Typically, room mailboxes (which do not need Exchange Online licenses) are used to control bookings of public spaces like conference rooms. Background processes such as the Calendar Attendant review incoming requests against the configuration (policy) defined for the target mailbox and decide if a request is successful and the room can be reserved for the requested time. Users receive email to tell them if their calendar meeting request is successful, denied, or waiting approval by a delegate who controls booking requests.

Traditionally, people waited for the email to come back to say if they have a room for their meeting. OWA and Outlook try to stop users booking rooms which are already reserved. Outlook (Figure 1) uses a MailTip, while OWA takes a more forceful approach and demands confirmation before sending a meeting request (Figure 2).

Either way, the person creating the calendar meeting request can still go ahead and attempt to schedule the room. At that point, the resource booking assistant kicks in to decide if the request is acceptable. The easiest situation is when the requested time slot is available, and the policy assigned to the room mailbox allows automatic acceptance of requests. The Set-CalendarProcessing cmdlet supports a bunch of parameters to allow administrator to tune exactly how incoming meeting requests for a room mailbox are dealt with.

For now, let’s assume that the assistant resolves the policy and decides to accept or reject the request, or that it is tentatively accepted pending review by a delegate. The next step is to send the meeting organizer email to inform them what’s happening.

Sending Corporate Information in Meeting Responses

Which brings me to my point. It’s often overlooked that you can insert some informational text in meeting responses for calendar meeting requests. Look at Figure 3 to see a message about leaving the room clean and tidy after the meeting.

The text inserted in meeting responses comes from the calendar processing configuration for the mailbox. In this case, I ran the Set-CalendarProcessing cmdlet to set two values. The AddAdditionalResponse switch is $True to force Exchange Online to add the extra text while the AdditionalResponse property holds the text to insert. As shown here, if some basic HTML formatting commands are included, they are used.

Set-CalendarProcessing -Identity "Room 101" -AddAdditionalResponse $True -AdditionalResponse "Please remember to leave the room <b>clean and tidy</b> with all equipment <u>back in its storage</u>. Thank you for using the corporate room scheduling system!" 

It’s simple to apply the same text to all room mailboxes by running Get-ExoMailbox to find the mailboxes and then piping the set of room mailbox objects to Set-CalendarProcessing.

Get-ExoMailbox -RecipientTypeDetails RoomMailbox | Set-CalendarProcessing -AddAdditionalResponse $True -AdditionalResponse "Please remember to leave the room <b>clean and tidy</b> with all equipment <u>back in its storage</u>. Thank you for using the corporate room scheduling system!"

Creating Complex Text for Meeting Responses

I haven’t experimented to find the outer limits to discover how much text can be input, but it seems like it is around 1024 characters, meaning that it is feasible to create a nice message. For instance, I used this online editor to create the text of the message shown in Figure 4.

In this case, the PowerShell command used was:

Set-CalendarProcessing -Identity "Room 101" -AdditionalResponse '<h2>Welcome to the Corporate Room Scheduling System</h2><p>We have a few basic rules for you to follow.</p><ol>
<li>Please keep the room tidy and remove rubbish at the end of your meeting.</li><li>Please do not change the settings of the AV equipment.</li><li>Please clean the whiteboard before you leave.</li><li>Advise Corporate Meetings if you have any problems by sending email to: <a href="mailto:corporatemeetings@office365itpros.com">Corporate Meetings.</a></li></ol><p><strong>Room 101</strong> can hold up to <strong>12</strong> people. Please do not exceed this capacity.</p><p>If you need <strong>catering</strong>, please contact Trina at 147-1497.</p><p>Thanks for meeting with us!<img src="https://html5-editor.net/tinymce/plugins/emoticons/img/smiley-smile.gif" alt="smile" /></p><p></p>'

The HTML and text are enclosed in single quote marks because some of the HTML commands use double quotes. It wouldn’t take a lot of extra code to read basic text from a file and customize the text (for example, adding some details about the capacity, equipment, or other information) before updating each room mailbox.

Simple Update, Big Impact

Adding some extra text to responses to calendar meeting requests can have a big impact. It’s the kind of simple but useful change that people often don’t know about. Discovering the hidden corners of Microsoft 365 is delightful, at least to me…

We explore all sorts of dark corners of Office 365 apps as we build content for the Office 365 for IT Pros eBook. In this case, the corner proved to be full of sweetness and light!

Getting Email into Teams

I must have been sleeping in January 2021 and failed to notice that Microsoft posted in User Voice (now discontinued) that Teams supports drag and drop from Outlook. Several sites picked up the news, but Microsoft didn’t post a message center notification to make the information more broadly available.

In any case, drag and drop capability joins the array of methods available to bring email into Teams:

• Share to Teams uses an Outlook add-in to send a message to a Teams channel or chat (including the ability to create a new chat). Because Teams cannot read encrypted messages, email protected with Office 365 Message Encryption, sensitivity labels, or S/MIME are not sharable. Share to Teams works with Outlook for Windows (Microsoft 365 apps for Enterprise), Outlook for Mac, and OWA. It isn’t available in Outlook mobile.
• Reply with IM is an Outlook desktop option available when Teams is the registered chat application for Windows. The option creates a chat with people addressed in the email.
• Reply to Teams Missed Activity Mail gives users who receive missed activity notifications the ability to respond to conversations in Teams using Outlook actionable messages.
• Email-enabled channels have special email addresses to allow the delivery of messages through a connector to become channel conversations. Organizations can restrict who can send email to an email-enabled channel.
• Drag and Drop from Outlook desktop allows users to drag and drop a message (and any attachments) to a Teams channel conversation.

Dragging a Message to Teams

Outlook for Windows supports drag and drop of a message and any attachments from any folder to a Teams channel conversation. You can’t drag and drop a message to a personal or group chat and the feature isn’t available in OWA or Outlook for Mac.

To get an email to Teams, select it in Outlook and drag it to the compose box for a new topic or reply and drop it there (Figure 1).

To get the message into Teams, Outlook uploads a copy of the message into the channel folder in the SharePoint site belonging to the target team and creates a link to the email in the Teams message. The user can then add extra context for the message, just like they would for any other attachment shared in a channel before posting (Figure 2). Users can also drag and drop messages from Outlook to the Files channel tab. This action uploads the message to SharePoint without creating a message in the channel.

Notice that the file stored by Teams in SharePoint Online is a .msg file (Figure 3). This file is a complete message, including attachments.

To view the message, users use the message viewer through the Teams Files channel tab or SharePoint Online to view the content of the .msg file. As you can see in Figure 4, the viewer shows no trace of any attachment.

To access message attachments, users must download a copy of the .msg file. Outlook desktop can then open the .msg file to expose the full structure of the message, including any attachments.

Protected Email Unsupported

Although Outlook can upload messages protected with sensitivity labels (or S/MIME or any other protection mechanism) to Teams, users won’t be able to read the content unless they download the message and open it with Outlook. When this happens, Outlook checks if the user has the necessary rights to view the content and if so, decrypts and displays the message.

Another way of handling protected email is to copy the decrypted text from Outlook and paste it into a Teams message. If you want to include the message header to show recipients, forward the message to someone (but don’t send it) and copy the text inserted into the forwarded copy. Any attachments (which will also be protected) must be downloaded and posted to Teams separately. I use this method frequently when I want to post something from email to Teams.

Delayed but Welcome

Drag and drop is such a natural part of working with data that it’s surprising Microsoft supported this method to link Outlook to Teams so late in the evolution of the client. Now that it’s here (and you know about it), try the feature out and see what you think about dragging messages from Outlook to Teams.

Now Circulating to an Inbox Near You

The value of enabling the first-time safety tip and external tagging of email is evident in a new phishing attempt that’s now circulating. The attack purports to be email delivering a document relating to an invoice payment (Figure 1). The message is tagged as external and the first-time safety tip is obvious. The attacker uses a classic technique of attempting to lure the recipient into clicking a link to download a document. Naturally, this brings the user to a place they don’t want to visit and shouldn’t go.

The email comes from an Office 365 tenant (easystreetdotnet.onmicrosoft.com), which I assume has been either hijacked or set up by the attacker. Because it’s valid email and comes from an Office 365 tenant, the email passes anti-spam and anti-malware checks and therefore reaches user inboxes.

The View completed document link in the message brings users to b24-r98mpq.bitrix24.site (an unlikely site address for legitimate documents).

Report Phishing Messages

I used the Reporting Phishing add-in for Outlook to send a copy of the message to Microsoft for their security analysts to review and action. In the meantime, keep an eye out for similar messages which might arrive in your tenant and consider:

• Installing the external tagging and first-time safety tip features in Exchange Online.
• Deploying the Report Phishing add-in to users.

The Devil Finds Work for Idle Hands

I guess it is reasonable to expect that after more than 25 years of active development, the Exchange engineers might run short of new features to build, something that doesn’t seem to be a problem for their Teams counterparts.

Which brings me to today’s post announcing the new BccBlocked parameter added to the venerable Set-DistributionGroup cmdlet (the example in original post used -BlockBCC; trust me, that’s wrong). Apparently, the use of some distribution lists inside Microsoft forced engineers to conclude that a way was needed to reject messages addressed to a distribution list as a blind carbon-copy (BCC) recipient. The logic is that messages sent as BCCs to distribution lists bypass inbox rules created to stop these messages because the rules cannot detect BCC recipients as this information is not in message headers.

The feature is now available worldwide. It only works for Exchange Online distribution groups and isn’t available (yet) for Microsoft 365 groups.

Blocking BCC for a Distribution List

You could argue that it would have been better to enhance inbox rules to deal with BCC addresses, but developers being developers, they decided that it would be better to create an administrative block instead, which is why we now can crack open a PowerShell session, load the Exchange Online management module, and run something like:

Set-DistributionGroup -Identity "Board Reports" -BccBlocked $True

The default for distribution lists is not to block BCC, so to check the distribution lists with the BCC block, we run:

Get-DistributionGroup | ? {$_.BccBlocked -eq $True} | Ft DisplayName

DisplayName
-----------
Board Reports
The Company

Microsoft says that they plan to expose the BCC blocked option in admin centers. First in the new Exchange admin center later “this year” and probably the Microsoft 365 admin center once support is available for Microsoft 365 groups.

What Happens When a Distribution List is Blocked for BCC?

The Exchange transport system is responsible for processing all messages sent in Exchange. When a message comes in addressed to a blocked distribution list as a BCC recipient, the transport system drops the message and sends a non-delivery report (NDR) with code 5.7.138 to the sender (Figure 1).

Figure 2 shows the detail reported for a blocked BCC message by a message trace in the Exchange admin center:

The same information is available using PowerShell:

Get-MessageTrace -MessageId DB7PR04MB44105FC9811AEB90D9CA5BF18B629@DB7PR04MB4410.eurprd04.prod.outlook.com | fl

Message Trace ID  : 7b94a8cf-512d-423b-ec42-08d8efb44265
Message ID        : <DB7PR04MB44105FC9811AEB90D9CA5BF18B629@DB7PR04MB4410.eurprd04.prod.outlook.com>
Received          : 25/03/2021 17:34:36
Sender Address    : Tony.Redmond@xxxx.com
Recipient Address : boardreports@xxxx.com
From IP           : 51.171.212.129
To IP             :
Subject           : Super Important Email
Status            : Failed
Size              : 13851

Get-MessageTraceDetail -MessageTraceId 7b94a8cf-512d-423b-ec42-08d8efb44265  -RecipientAddress BoardReports@xxx.com

Date                   Event                Detail
----                   -----                ------
25/03/2021 17:34:36    Receive              Message received by: DB7PR04MB5001.eurprd04.prod.outlook.com using TLS1....
25/03/2021 17:34:36    Submit               The message was submitted.
25/03/2021 17:34:36    Fail                 Reason: [{LED=550 5.7.138 RESOLVER.GRP.BlockBcc; the group has been conf...

I’m unsure how much use that the new feature will get outside the unique scenario met in Microsoft, but it’s better to have the capability than to lack it.

Available for Activation Now

After a delay to allow for the deployment of the required cmdlets, tenants can now activate Exchange Online’s external email tagging feature to mark external email (MC243047 – Microsoft 365 roadmap item 70595). The tags appear in OWA, Outlook Mobile, Outlook for Mac, and should eventually show up in Outlook desktop. External email tagging is part of Microsoft’s strategy to make email secure by default along with other features like blocking automatic mail forwarding.

External email tagging means that messages received from any domain except those registered for the tenant are marked by Exchange as “external” when they pass through the transport service on their way to user mailboxes. Figure 1 shows External tags displayed for a set of messages in my Inbox with details obscured to protect the guilty. In addition to the tag, when a message is read, the user is offered the chance to block the sender. The external tag is not displayed for messages received from external senders and forwarded by a tenant user. Protected (encrypted) messages are not affected as the tag doesn’t affect message content.

Flagging external senders with a form of mail tip and offering to block them seems a tad robust. After all, email is all about communication and even if spammers are active, I expect a minimum of spam to get past Exchange Online Protection and Microsoft 365 Defender for Office 365 (aka Advanced Threat Protection). The implementation appears to make blocking senders the norm rather than the exception, which I don’t like.

Adding Well-known Functionality

Tagging adds a feature to Exchange Online that organizations have been building for years with transport (mail flow) rules (here’s an example). Obviously, Microsoft believes that highlighting external email is something which should be available out-of-the-box. I agree. It’s just curious that it’s taken the developers 25 years to get around to implementing the features. Then again, important stuff like enabling reactions to email (MC239090 – delayed on March 2 to “evaluate feedback” like “this is a waste of time”) has got in the way.

Activating External Email Tagging

External tagging is disabled by default. This is an unusual situation for a new feature as Microsoft invariably assumes that people want to use whatever new wheeze they have dreamed up and therefore enables new features. In this instance, you’ll have to run the Set-ExternalInOutlook cmdlet to get things moving.

Leaving aside the not-very-good cmdlet name (Set-ExternalEmailTagging would have been more obvious), the process is very simple:

• Connect to the Exchange Online Management endpoint (or use remote PowerShell if you must).
• Run Set-ExternalInOutlook to enable external tagging. You can decide if certain domains or individual email addresses are excluded from tagging. I’m not sure when I would use individual addresses, unless you wanted to be sure that email received from someone’s (like an executive’s) personal email address was not considered external. The more I think about that idea, the less I like it.

For my tenant, I ran:

Set-ExternalInOutlook -AllowList "quest.com", "microsoft.com" -Enabled $True

This command means that tagging is applied to any external email except the two domains defined in the allowed list. After a moment, I decided to add another domain. Doing it this way avoids overwriting the domains already excluded:

Set-ExternalInOutlook -AllowList  @{Add="Practical365.com"}

Note: Some tenants are reporting that they see failures when running Set-ExternalInOutlook to add just one domain to the allow list. While Microsoft debugs the problem, the quick workaround is to always add at least two domains to the list.

The Get-ExternalInOutlook cmdlet reports the tagging configuration:

Get-ExternalInOutlook

Identity   : s662313f-14fc-43a2-9a7a-d2e27f4f3478
Enabled    : True
AllowList  : {quest.com, microsoft.com, Practical365.com}

The identity reported is the GUID for the tenant. It’s the same as reported by Get-MgOrganization, which is my normal go-to cmdlet to find this information. You can also find the tenant identifier in the overview section of the Entra ID admin center.

After that, it’s a matter of waiting for Exchange Online to acknowledge the configuration update and enable tagging. Microsoft says that activation should happen within 24-48 hours. The exact waiting period depends on many factors, including service load, but in my case, Exchange Online started to tag messages within a few hours.

If you enable external tagging and want to see the tags show up, make sure that your account is enabled in the Microsoft 365 admin center for targeted release. Users on targeted release see new updates for several weeks before other users do.

Tagging Threads

Interestingly, OWA highlights a thread as external if any message in the thread comes from an external domain that’s not on the excluded list. For example, I have a bunch of messages from microsoft.com addresses which are excluded from tagging. But once someone from an external address (like dell.com, for instance), joins the conference, OWA applies the external tag.

Although tagging is supposed to show up in Outlook mobile, I haven’t seen it yet despite updating to the latest TestFlight build (4.2110.0). No doubt external tags will appear in time. I just have to be patient.

Update April 22: Glen Scales explains how to use the Microsoft Graph API and EWS to work with external tags in this blog post.

To learn lots more about Exchange Online and Office 365 in general, subscribe to the Office 365 for IT Pros eBook! We probe and test new features so you don’t have to do as much work to understand and deploy them in production.

Do Real User Mailboxes Receive a Message a Second?

What should we make of Microsoft’s decision to impose a hard limit on Exchange Online mailboxes receiving more than 3,600 messages per hour, as reported in message center notification MC239262 on February 13?

Simply this: in any large platform where resources are shared, some will try to take more resources than they should and it’s clear that some mailboxes are regularly exceeding thresholds. Microsoft says the number is very low, but once evidence of abuse appears, it becomes a candidate to be stamped out.

Microsoft has operated a soft limit (meaning that it wasn’t applied) for inbound message volume since Exchange Online commenced (other limits govern the ability to send outbound messages). The threshold of 3,600 messages per hour has been in place for at least four years. That’s one new message arriving in the inbox every second. Even the most productive user on the face of the planet cannot cope with such a torrent of inbound email, so the conclusion must be that mailboxes handling such amounts are used by automated processes rather than humans.

It’s possible that the automated processes are not trying to take advantage of Exchange Online. For instance, a process might generate email to inform recipients of its progress. Run in test conditions, the volume of email might be small and easily dealt with. When scaled up for production, the same code probably generates far more progress reports, and if several processes take the same approach to reporting and use the same target mailbox, it’s possible to imagine that the mailbox might receive a large volume of reports. But directing one new message per second over a sustained period to a single mailbox is too much. Mailboxes and their databases are not designed for that kind of sustained traffic.

Introducing Hard Limits

Microsoft says that they will impose a hard limit in April 2021. They will introduce the new limit gradually, starting with a higher limit and moving down to the published threshold. Think of this as a hard limit of 5,000/messages/hour being reduced weekly until the 3,600 figure is reached.

A new Mailboxes exceeding receiving limits report in the new version of the Exchange admin center (EAC) will help admins identify problems. The report lists mailboxes that have hit the threshold or are close to the threshold over the last 24 hours. The idea is that someone then calls up the mailbox owners to ask (politely) why they receive so much email. Microsoft says that admins should contact mailbox owners “to understand why they are receiving so many messages and inform them of ways to reduce mail volume and improve their experience.” In other words, “stop making my life difficult and change your code to reduce email volume.”

The Effect of Throttling

Once a mailbox hits the threshold, Exchange Online will throttle its ability to receive new email. In this context, throttling does not mean “slow down inbound traffic.” Instead, Exchange will refuse delivery of new email for an hour after the threshold is reached.

To make the mailbox owners aware that throttling is in force, Exchange sends an automated email to the affected mailboxes. Given the volume of new messages arriving in the mailbox, you’d wonder if the mailbox owner will ever see the notification of throttling. To offset the problem, Microsoft will make sure that the warning message appears at the top of the inbox.

Even with the warning message highlighted in the inbox, it is more likely that mailbox owners will more quickly react to sender complaints who receive non-delivery notifications (NDRs) saying that the mailbox can’t receive new messages because it has exceeded the threshold. Of course, if the senders are automated processes, they will probably ignore the NDRs.

EAC Highlights Problems

The EAC will highlight threshold violations in its Insights section with a notice saying that “one or more mailboxes have exceeded their receiving limits.” To avoid the need to access EAC to see what’s going on, Microsoft says that admins will be able to create an alert policy to send mail when a mailbox exceeds receiving limits. The ability to create alert policies doesn’t yet exist in EAC (Figure 1), but as the new version of the console is still under development, the functionality will hopefully show up before Microsoft beings to restrict high-volume mailboxes.

Hopefully, information about blocked mailboxes will also be posted as events in the Office 365 audit log. This will allow solutions like Microsoft Cloud App Security and third-party monitoring products to capture and signal problems with blocked mailboxes. Capturing events in the audit log also allows for at least a 90-day lookback (for E3 accounts – 365 for E5) should that need arise.

Need to learn more about how Office 365 and its apps work? Subscribe to the Office 365 for IT Pros eBook. We publish monthly updates to keep our subscribers updated about changes like the one described here.

Unexplained and Unannounced Change Affects Tenant Processing

The ability to send email to a Teams channel has existed since the earliest days of the product. If Email integration is turned on (the default) for Teams (in the Teams settings section under Org-wide settings in the Teams admin center), team members can retrieve an email address for a channel using the Get email address option (Figure 1). If the address doesn’t already exist, Teams creates one in the form Channel display name <identifier.domain@region.teams.ms>. The identifier is a unique 8-character value and the region is the datacenter region the tenant belongs to.

The email address is a tad strange, you can’t change it, and any team member (except guests) can remove and replace the address, but the mechanism works to get email into Teams. Any message sent to the address is picked up by a connector and posted as a new conversation in the target channel. Team members can then reply to the conversation as they wish (replies do not go back to the original sender).

All in all, sending email to a channel is a simple and effective way of taking messages which arrive at any mailbox and share information with Teams. Outlook’s Share to Teams option is a more elegant option if you have a supported client, but it doesn’t offer the flexibility of an email address.

Guest Account for a Teams Channel

I often create a guest account or mail contact using the email address for a Teams channel. This technique allows me to include the channel as a member of Microsoft 365 groups (guest account) or distribution lists (mail contact), and be visible in the GAL. Once available in the GAL (Figure 2), anyone in the tenant can send or forward messages to the channel as easily as addressing any other recipient. This is an example of the flexibility of the channel email address.

Teams Channel Email and SharePoint Online

When email arrives for a channel, Teams captures a copy in the SharePoint team site belonging to the team. Each channel has its own folder, and if messages arrive in the channel, they go into the Email Messages folder under the channel folder.

That is, until February 5 when Microsoft changed how delivery works. Instead of creating copies in the Email Messages folder, a new folder called EmailMessages_2_2021 appeared in the channel folder (Figure 3). New messages received since are in separate folders created for each month.

Breaking Flows

On the surface, there’s nothing bad here. Microsoft had some reason to change how SharePoint stores email delivered to Teams. It seems like a sensible idea to use separate month-based folders instead of stuffing everything into one big folder. There doesn’t seem to be a technical reason for the change as the documentation for SharePoint Online limits doesn’t mention anything that seems to be related, with the only mention that when a folder contains more than 100,000 items, you can’t break permissions inheritance.

But making an unannounced change without warning can have unexpected consequences for service users. In this case, users noted that Power Automate flows failed because messages went to the new folder instead of the expected folder. The workaround is to create yet another flow to trigger when .eml (message) files appear in the document library and create a copy where the original flow expects it to be. Although this works, it is clunky and shouldn’t be necessary. And what about the people who don’t realize yet that a change has happened?

Microsoft knows about the problem. However, there’s no word yet how they plan to address the issue. When we know, we’ll publish an update here.

Changes like this are the bread and butter of the Office 365 for IT Pros writing team. We see similar updates come along every month and process them as updates to book chapters. Once we get to the bottom of this development, we’ll update Chapter 12. Stay updated by subscribing to Office 365 for IT Pros – the only book about Office 365 tenant management republished monthly.

Build Filters Against Multiple Entra ID User Account Properties

A post in the Microsoft Technical Community looked for help building a dynamic distribution list based on multiple Entra ID properties. Our esteemed technical editor, Vasil Michev, stepped in to help and involved me. I pointed out that this topic is covered in the Groups chapter of the Office 365 for IT Pros eBook (easy to miss in 1,350 pages) but admitted that the question was interesting.

Dynamic distribution lists are an undervalued part of Exchange Online. The functionality has existed since Exchange 2003 introduced the query-based distribution group, or QDG. The current implementation arrived in Exchange 2007. In both cases, a query is resolved against the directory to identify the set of recipients for a message. The list is dynamic because the set of recipients will change based on the contents of the directory. Exchange Online calculates the list membership behind the scenes (the “modern” implementation), but the concept of membership depending on a filter run against the directory still holds.

Precanned and Custom Recipient Filters

The Exchange admin center (EAC) GUI is designed to make it easy for administrators to create the queries for dynamic distribution lists. It does this by limiting the set of properties available for queries, like department and city. The queries generated by the EAC are called precanned queries. after generation, Exchange stores the recipient filter as a property of the dynamic distribution list.

Custom queries can use a much wider set of properties. The downside is that you must build the recipient filters by hand and update dynamic distribution lists with PowerShell. That might seem hard, but it’s really not.

Excluding Some Mailboxes

In this instance, the need is to have a dynamic distribution list to address mailboxes owned by people with a specific job title but exclude any user accounts that Entra ID currently blocks for sign-in. Figure 1 shows the account of architect Ben James. The account is blocked.

When a user account is blocked, Exchange Online synchronizes the status and updates the ExchangeUserAccountControl mailbox property. To find the set of recipients who have architect in their job title and can still sign in, we can build a recipient filter which checks the Title and UserAccountControl properties (the version of the properrty name used by Get-Recipient). Because people might have prefixes to indicate the seniority of their architect status, we need to include some variants of the job title. Exchange Online only supports wildcards for filters at the end of a string (“architect*”) instead of the start (“*architect”), which would be more useful in this case.

Update: Unfortunately, the technique described here doesn’t work at present. I’m trying to figure out why this might be so. Microsoft has been active in DDL filters recently to make them more predictable, and this work might have had some side effects (23 August 2024).

Building and Testing a Recipient Filter with PowerShell

Here’s what a custom filter to check for a job title and account blocked status looks like:

$Filter = "((Title -eq 'Architect') -or (Title -eq 'Senior Architect') -or (Title -eq 'Principal Architect') -and (UserAccountControl -ne 'AccountDisabled'))"

To know if the filter works, we can use the Get-Recipient cmdlet. Get-Recipient accepts the filter defined in the $Filter variable and returns what it finds in the directory. This is exactly what will be returned as the set of recipients when the Exchange transport service resolves the query stored in the dynamic distribution list.

Get-Recipient -RecipientPreviewFilter $Filter | ft displayname, title

DisplayName                   Title
-----------                   -----
Ben James                     Architect
Eoin Redmond (Ireland)        Architect
James Joyce                   Principal Architect
Tony Redmond                  Principal Architect
Vasil Michev (Technical Guru) Senior Architect

It’s important to test a recipient filter before using it with a dynamic distribution list. If the query generated by the filter fails to resolve and return any recipients, any message sent to the list goes into a black hole. Exchange won’t generate a non-delivery notification because the address used for the message is valid (the list); the problem lies with what happens when the query is run against the directory.

Creating a Dynamic Distribution List with PowerShell

After you’re sure that the filter returns the correct set of recipients, you can create a dynamic distribution list using the filter. For example:

New-DynamicDistributionGroup -Name "Architects" -DisplayName "System and Engineering Architects" -Alias AllArchitects -PrimarySmtpAddress Architects@Office365itpros.com -RecipientFilter $Filter
Set-DynamicDistributionGroup -Identity AllArchitects -ManagedBy Tony.Redmond -MailTip "Distribution List for anyone with Architect in the job title"

The second command is to add an owner for the dynamic distribution list and to assign a mail tip for clients like Outlook to display when people address email to the list.

EAC Blocks Edits of Custom Recipient Filters

Any further adjustments to the recipient filter can only be made with PowerShell. If you look at a custom recipient filter with the Exchange admin center, it’s blocked for edit (Figure 2).

As for Ben James, when his user account is reenabled for sign-in, he’ll start to receive messages sent to the dynamic distribution list again, which is exactly what we want.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Dynamic Expansion of Recipient Lists

Exchange 2003 introduced query-based distribution groups (QDGs), a form of email distribution list which doesn’t have a fixed set of recipients but instead contains a query to be executed against a directory to resolve the recipients each time the list is used. Today, the same concept persists in Exchange Online dynamic distribution lists (DDLs) and Microsoft 365 dynamic groups. However, as detailed in Table 1, the two implementations for dynamic membership are based on very different foundations.

You can boil the differences down to the directory used to resolve membership, but that’s a very simplistic view. The bigger differences are the cost and how Microsoft 365 groups are used to manage membership for Teams, Yammer, and other apps.

Anatomy of a Dynamic Distribution List

A DDL is composed of:

• An Exchange Online object which is not synchronized to Azure AD. A DDL only exists in EXODS.
• A recipient filter used to resolve the set of recipients. The filter can resolve against Azure AD attributes (like City and Department), but only if they are synchronized to EXODS. Many other Exchange-specific attributes can be used in recipient filters.
• Other properties like a manager, MailTip, etc. used by email functionality.

A DDL cannot be used for security purposes. Its membership cannot contain a mixture of fixed and dynamic recipients, but membership can be made up of any mail-enabled recipient type including other distribution lists, mail contacts, public folders, and hybrid recipients.

Managing Dynamic Distribution Lists

DDLs are created and managed using the older Exchange admin center or PowerShell. The modern EAC does not yet include the functionality to create and manage DDLs. And because DDLs are not Azure AD objects, you can’t create or manage them through the Azure AD portal or the Microsoft 365 admin center.

Figure 1 shows the initial step in creating a new DDL. At the bottom of the screen you can see the start of creating the query for the DDL when we specify what types if mail-enabled recipients should be found.

Finding only recipients of a certain type is a valid query, but in most cases, you’ll want to refine the filter by adding some rules to check against filterable properties. In Figure 2, we’ve chosen to filter against two properties (Department and CustomAttribute1) and are entering one of the values we want to find in CustomAttribute1.

When saved, the rules are written out into the RecipientFilter property of the DDL. Exchange Online writes the recipient filter into the list after applying some post-processing to make sure that the filter finds the intended objects. Here’s the filter created for the DDL shown in Figures 1 and 2:

Get-DynamicDistributionGroup -Identity "Office 365 for IT Pros Writers" | Select -ExpandProperty RecipientFilter

((((((Department -eq 'Writers') -or (Department -eq 'Authors') -or (Department -eq 'Production'))) -and (CustomAttribute1 -eq 'Author’) -and (RecipientType -eq 'UserMailbox'))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'GuestMailUser')))

The filter looks complex, but the bulk is made up of exclusionary clauses to avoid messages being sent to system mailboxes.

Recipient Filters

Recipient filters (queries) are at the heart of DDLs. The queries are stated in OPATH format and two types are available:

• Precanned filters are created when you compose query rules for a DDL through the EAC. Precanned filters are restricted to queries against a small number of well-known object properties such as the department, city, and 15 customizable attributes. See this article for details for how to use precanned filters.
• Custom filters are created when you use PowerShell to define a recipient filter. Canned filters are more powerful and flexible than precanned filters because a wider of properties can be included in a query. Once you apply a custom filter to a DDL, you won’t be able to edit the filter through the EAC. This article explains how to build custom filters for use with a dynamic distribution list.

No matter how good your query is, it is useless if the properties of objects stored in EXODS are incomplete or inaccurate. Queries will run, but the transport service won’t find the correct set of addressees to receive messages.

You can test the effectiveness of a recipient filter by using it with the Get-Recipient cmdlet and checking the set of objects returned. For example:

Get-Recipient –RecipientPreviewFilter (Get-DynamicDistributionGroup –Identity "Office 365 for IT Pros Writers").RecipientFilter

Name		RecipientType
---- 		-------------
Jeff.Guillet    UserMailbox
James.Ryan      UserMailbox
Jane.Sixsmith   UserMailbox

Update: You can now use the Get-DynamicDistributionGroupMember cmdlet to see the membership of a dynamic distribution list.

Messages sent to dynamic distribution lists with queries that don’t find any recipients go into a void. Senders don’t receive any indication that the message reached no one, which is a good reason to validate that the recipient filter for a DDL finds some recipients.

Dynamic Distribution Lists Still Valuable

DDLs are simple, robust, and work. Everything depends on the recipient filter, but once you can query and find the right recipients, there’s very little else that can go wrong. DDLs are a good choice when you want to target communications at a changeable set of mail-enabled recipients and don’t want to spend a lot of time making sure that the list membership doesn’t go out of date. The big dependency is the directory. Make sure that EXODS (and by extension, Azure AD) is populated with accurate information and you’ll lay a great foundation for successful DDLs.

Learn more about dynamic distribution lists and dynamic Microsoft 365 Groups in the Office 365 for IT Pros eBook. We must be like a dynamic distribution list because we’re always updating our contents to stay accurate.

OWA Gets Remove External Access Feature

Office 365 notification MC216367 (updated August 27) announced that end users would be able to revoke messages protected by Office 365 Message Encryption (OME) if they are eligible for the advanced form of OME, licensed through Office 365 E5 or other licenses (like Microsoft 365 E5 compliance). OME allows users to encrypt or mark messages with Do Not Forward using OWA and Outlook desktop. Microsoft automatically enables OME for all Office 365 tenants with E3 or above licenses.

The new feature means that after you send a revocable message, you can use the Remove external access option to revoke access to the message (Figure 1). This feature is only available in OWA and only works for some external recipients (see below), but it’s still a nice option to have if you suddenly need to withdraw access to sensitive content that’s been distributed outside your tenant.

In addition to being able to revoke messages sent with the standard OME Encrypt-Only or Do Not Forward protection, the Remove external access feature also works for messages with an Office 365 sensitivity label, which can use rights management based encryption to secure access to content. Figure 2 shows a message protected by the Financial Data sensitivity label. Revoking access for external recipients works in the same way.

After the message is revoked, the OWA message header is changed to confirm that external access has been removed. At this point, any attempt by the recipient to open the content will be declined because “this message has been revoked by the sender.”

What Messages Can be Revoked

Revocation only works for external recipients. You can’t revoke a message delivered to recipients in your tenant. OME divides external recipients into two categories:

• Accounts in Office 365 domains and Outlook.com: You can’t revoke messages delivered to these recipients.
• Accounts in any other domain: Messages sent to these recipients can be revoked because the actual message is not delivered to their mailboxes. Instead, they receive a notification directing them to the OME portal. These notifications are called link-based messages. Recipients must authenticate with the OME portal by signing in or using a one-time passcode to access the protected content.

Revocation is possible for link-based messages because you can guarantee to block access at the OME portal. Revocation of messages delivered to other Office 365 domains or Outlook.com would require the ability to interfere with mail flow in those domains, and that’s not possible today.

Administrator Revocation

Prior to this development, protected messages could only be revoked by administrators using PowerShell or the Message encryption report in the compliance center. As the message encryption report is usually a few days behind real time and the need to retrieve sensitive information often makes revocation something that happens “now,” the best approach is to run a message trace in the new Exchange admin center (EAC) or the old Security and compliance center to find the message identifier and then revoke it with PowerShell.

Figure 3 shows the results of a message trace in the new EAC. After finding the message we want to revoke, we can check its properties to find the message identifier.

After saving the message identifier, we can use it with the Get-OMEMessageStatus cmdlet to check if it can be revoked (see below).

$msgId = "DB7PR04MB44108EE5BE4CD44B7452E20A8B050@DB7PR04MB4410.eurprd04.prod.outlook.com"
Get-OMEMessageStatus -MessageId $MsgId

ObjectState  : New
Container    : SystemMailbox{D0E409A0-AF9B-4720-92FE-AAC869B0D201}@office365itpros.onmicrosoft.com

Subject      : Project Quarterdeck
ReceivedTime : 01/01/0001 00:00:00
Revoked      : False
IsRevocable  : True

In this case, the IsRevocable flag is True, so we can go ahead and revoke using the Set-OMEMessageRevocation cmdlet:

Set-OMEMessageRevocation -Revoke $True -MessageId $MsgId
The encrypted email with subject "Project Quarterdeck" and Message ID "DB7PR04MB44108EE5BE4CD44B7452E20A8B050@DB7PR04MB4410.eurprd04.prod.outlook.com" was successfully revoked.

Running Get-OMEMessageStatus for the message will now show that the Revoked property has changed from False to True and the recipient will no longer have access to the content.

One irritation is that Get-OMEMessageStatus shows that these messages can be revoked and you can try to revoke them with Set-OMEMessageRevocation (which tells you that the revocation is successful), but recipients will still have access to the messages. I guess the cmdlet can’t tell the difference between messages sent by link and those which go direct

Detail like this leads to a couple of lines in the Office 365 for IT Pros eBook. Even a book spanning 615,000 words can’t cover everything in depth, which is why we have this web site. But that’s no reason to not subscribe to the book.

Send Email to Filtered Sets of Recipients

After explaining how to use a custom attribute to store users’ beverage of choice and surface that information in Office 365 apps through the Microsoft 365 profile card, the question came up if it is possible to create a dynamic distribution list using the same custom attribute. The answer is “absolutely!”

Dynamic distribution lists are a very powerful way of addressing specific sets of mail-enabled recipients. Table 1 compares their capabilities against those of dynamic Microsoft 365 groups.

Some on-premises Exchange organizations use thousands of dynamic distribution groups. Because of the presence of other methods to address sets of users like Microsoft 365 Groups and Teams in Office 365, dynamic distribution lists are not as heavily used. But as we’ll see, these lists are easily to create and use.

Filters Against the Directory

The core of both types of dynamic groups is the filter used to find objects in the source directory. The filters can be very complex when multiple attributes are involved, but in this case the filter needed to find users with a particular value in a custom attribute is straightforward. For example, to create a dynamic distribution list of mailboxes whose owners like beer, we can either use the Exchange admin center or run the New-DynamicDistributionGroup cmdlet:

New-DynamicDistributionGroup -Name DynamicBeer -DisplayName "Dynamic Beer Drinkers" -ConditionalCustomAttribute9 Beer -IncludedRecipients MailboxUsers -PrimarySmtpAddress Beer.Drinkers@office365itpros.com -Alias Beer.Drinkers

In this case, because we use CustomAttribute9 to hold the drink preference, we can use what’s called a “precanned” filter. In other words, Exchange knows that custom attributes are often used for filters, so the cmdlet supports an easy way to include these attributes in filters. The ConditionalCustomAttribute9 parameter is set to “Beer” and the IncludedRecipients parameter is set to MailboxUsers. Together, this creates a filter to find any user mailbox whose CustomAttribute9 is “Beer.”

If the attribute you want to use isn’t covered by a precanned filter, dynamic distribution lists can also use custom filters to find mail-enabled recipients. This is a little more complex because you must construct the filter instead of Exchange doing the job for you.

To complete the setup of the new dynamic distribution list, we use Set-DynamicDistributionGroup to define who is the list owner and create a mail tip to give an indication to users about the list’s purpose:

Set-DynamicDistributionGroup -Identity Beer.Drinkers -ManagedBy James.Joyce@Office365itpros.com -MailTip "Mailbox users who like beer"

Some judicious cut and pasting will quickly generate a set of dynamic distribution lists for people who like water, wine, cola, and so on.

Testing Recipient Filters

If you want to be sure that the filter created for a dynamic distribution list will locate the correct mailboxes, you can run the Get-Recipient cmdlet and input the recipient filter for the list. Here’s how:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity Beer.Drinkers).RecipientFilter | Select DisplayName

DisplayName
-----------
Kim Akers
Imran Khan
James Ryan

To have more mailboxes picked up by the filter, update their CustomAttribute9 with the value used by the filter. For example:

Set-Mailbox -Identity James.Joyce -CustomAttribute9 "Beer"

Using the List

Using the dynamic distribution list is as easy as using any distribution list. The notable difference from an end user perspective is that there’s no option to expand the list and reveal the individual members by adding them to the message header (Figure 1).

The list membership is evaluated each time a message addressed to the list passes through the Exchange transport service and messages for matching recipients are generated at that point.

We’re rather fond of dynamic distribution lists, so they are covered in the Office 365 for IT Pros eBook. It’s an Office 365 feature that hasn’t changed in years… but we still like it.

API in Preview Revealed at Ignite 2020 Conference

The advent of support for roaming signatures for Outlook desktop caused some to question if the case to use third-party email signature management products had weakened. As it turned out, Microsoft delayed the deployment and the latest information published in Office 365 notification MC215017 on September 22 says:

• We will begin rolling this out to Microsoft 365 Monthly Channel, Targeted, in late September (previously July). (This is Insiders Slow Channel which will soon be called Microsoft Beta.)
• We expect to roll this out to the Monthly Channel, Production, in late October (previously August).

Update: According to Microsoft 365 roadmap item 60371, the latest date for the general availability of roaming signatures is July 2022.

Not Easy to Manage Outlook Signatures

My experience of using PowerShell to create and update signatures for Outlook desktop convinced me of the complexity of the task. By comparison, the signatures used by OWA are much easier to manipulate. Messages generated by Outlook mobile and other email clients connected to Exchange Online are typically handled by routing the email through an Azure-based cloud service and then back to Exchange Online for onward delivery. In a nutshell, managing corporate email signatures is not easy, especially when multiple client types are involved.

A New Signature API for ISVs

Still, ISVs need to improve their software to convince potential customers that it’s best to use their products instead of relying on what Microsoft delivers. What might surprise some is that Microsoft helps ISVs, as evident in the Build Outlook Add-ins that integrate your solution seamlessly into your users’ Outlook experience session​ (yes, that’s a mouthful) from Ignite 2020.

The session features Szymon Szczesniak, the genial CEO of Code Two software (Figure 1), discussing his company’s experience of using a new Signature API to create web add-ins which work for Outlook desktop (Windows and Mac) and OWA (now), and Outlook mobile (in the future).

As you might expect, Code Two created a web add-in to add a corporate signature to a message before it is sent. This has been possible in the past, but only by creating something like a COM add-in that had to be installed on individual workstations or distributed to sets of workstations using Group Policy Objects. The COM add-in worked by updating Outlook settings with the signature, which Outlook then applied to new messages.

What’s Possible with Signature Web Add-ins

The Signature API and web add-ins are a dramatic step forward. Signatures inserted by add-ins based on the API can be dynamic, meaning that they can be intelligent enough to detect the type of message to insert an appropriate signature. For instance, a new message might get the full treatment with a corporate slogan inserted along with user details while a reply or forward might have a cutdown signature inserted or none. If the company publishes multiple types of signature available (for instance, signatures with different graphic layouts), users can select which they’d like to use.

Finally, because the processing is done on the client before email is sent, protection applied by sensitivity labels or Office 365 message encryption works properly and solve the issues highlighted in this article, at least for Outlook clients. Challenges remain for dealing with mail traffic generated by Outlook mobile (until it supports the web add-ins) and non-Microsoft email clients, which will still need to be processed en route.

Expect December Developments

Although Code Two Software get the kudos for publicizing the new Signature API, they won’t be the only ISV to exploit the API (LetsSignIt announced that they have also been working with Microsoft to develop an add-in). I expect a batch of new products and offerings to appear soon after Microsoft makes the API generally available, expected before the end of this year. Overall, the new API will make email signature management easier to deploy and manage, and that can’t be a bad thing.

Update March 22, 2021: Code Two has released their “modern web add-in” for Outlook and OWA. Like many software developments, it took a little longer to get the add-in from early development to full production.

Update May 25, 2021: Announced at the Build 2021 conference, Code Two Software’s modern signatures add-in for OWA and Outlook for Windows is now generally available. Not to be outdone, Exclaimer has support for an OWA add-in too (but not Outlook desktop yet). Expect all the major email signature vendors to follow suit in the near future.

We don’t cover much about ISV software in the Office 365 for IT Pros eBook. In this case, email signature management has been such a pain for so many organizations for so long that we’re delighted to see progress in the space.

Email Exfiltration Controls for Office 365 connectors

Updated: 18 June 2021

In May, I wrote two articles about how Office 365 tenants can restrict users autoforwarding email from their Exchange Online mailboxes. The first article covered OWA, the second more general restrictions. In the second article, I pointed out that Power Automate (aka Flow) cheerfully ignores any restrictions imposed by Exchange Online, thus giving those who want to transfer email outside the organization a handy way to accomplish their goal.

That was then and this is now. Microsoft has just introduced some additional capabilities to help tenants control “email exfiltration” through Office 365 connectors. The immediate use case is to stop Power Automate flows sending, forwarding, or replying to email. Exfiltration is an interesting word to choose, and one that will be unfamiliar even to native English speakers. One definition I found that seems to fit is that data exfiltration is any unauthorized movement of data. In this instance, we want to keep email inside Exchange Online so that it’s exposed to compliance and data governance tools, so the unauthorized movement of data is of messages to an external email address.

Exfiltration Headers

There’s nothing complicated in the new controls. Some well-understood and reliable mechanisms are deployed to detect and stop outbound email generated by Power Automate addressed to external recipients. What’s changed recently is that Power Automate now adds an SMTP x-header to messages to identify its traffic. For example, I created a flow to fire when a new item is added to a SharePoint list. The message sent has the following headers:

x-ms-mail-application: to identify that the message comes from Power Automate. For example, my flow generated the following header. The underlined identifier is important because it can be used to allow or block messages from specific flows.

Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow d356b212a66640dab94fd13546ca88d8; version 08586039113867675952) microsoft-flow/1.0

x-ms-mail-operation-type: to identify whether the message is a send, forward, or reply. In this instance, SharePoint Online creates a new message, so the action noted is Send. The value can also be Forward. Either will work.

To find this information, I sent the message to an Outlook.com address and examined it with the Message Header Analyzer after it was delivered (Figure 1).

Implementing an Email Exfiltration Block in a Transport Rule

Anyone who has ever created an Exchange transport (mail flow) rule knows that all outbound mail passes through the transport service, which examines and applies the conditions set in rules. In this instance, the rule is very simple. Figure 2 shows all that’s needed for a complete block of all email sent to external recipients via Power Automate flows.

The rule is: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

The rule conditions and action are: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

You can compose some nice text to explain the problem to the user which Exchange Online will insert into the reject message (Figure 3).

Microsoft’s article explains how to add conditional processing and exceptions. You might want to allow some flows to run because they are needed to send email to invoke an external process, or you might want to allow flows from specific senders or addressed to specific recipient addresses because you’re happy that the email is necessary and doesn’t compromise the organization’s data governance policy.

Good Flow Controls

The email exfiltration control is simple and effective. It’s just strange that it’s taken Microsoft four years since the introduction of Flow in April 2016 to figure out that controls are needed over email generated by Power Automate. In their defense, the data governance landscape was very different in April 2016 and Office 365 did not have the same kind of compliance feature set that’s available now.

Maybe Not Brain-Dead but Certainly Poor Thinking

Recently, the folks responsible for running the Microsoft Technical Community contacted me to say that someone was offended at a comment I made in a discussion about Office 365 backup. Apparently, the person didn’t like me saying (Figure 1):

“In this case, the backup product copies mail to PST files, which is just about the most brain-dead and stupid approach to backup of a cloud email solution known since the dawn of Office 365.”

The forum moderators removed the original note I replied to. It can be summarized as one of the almost Pavlovian responses from some working for ISVs who create backup software. As soon as a discussion starts in a forum about backup, they rush to talk about their product even when the product is wildly inappropriate.

In this case, the vendor representative advanced the case to use PSTs as a backup solution for Exchange Online mailboxes. I don’t regret calling this suggestion brain-dead and stupid because I honestly consider that anyone who thinks that backing up cloud-based mailboxes to personal files on workstations has lost their marbles.

Uses of PSTs

Despite all the flaws documented in PSTs over the years, these files continue to be used. Even Office 365 tolerates PSTs, but only for necessity when nothing else is available. PSTs can be used as an import source for mailboxes and to export the results of eDiscovery searches (typically for investigation and review by an external expert); aside from these uses, I can’t think of why I would even consider using a PST.

Using a PST for backup exports information from cloud mailboxes and creates potential compliance and retention issues for the company. The action could lead to loss of data to attackers, which is what happened to Sony in 2014. Users sometimes think that it’s a good idea to create their own personal mailbox archives in PSTs, but there’s really no reason to do this, especially with the large mailbox quotas available in Office 365 (the classic reason why people used PSTs was to remove old mail from their online mailbox).

Exchange Native Data Protection ensures that four copies of their mailbox exist in at least two Office 365 datacenters. An extra copy in a PST will only help if all those datacenters are offline. Even if this were to happen, the email in the PST might remain inaccessible if protected with sensitivity labels (which also make sure that people can’t take email with them to another employer).

No Room for Misleading Advocacy

To be fair to the ISVs who create PST-based backup solutions, a reasonable need existed for their products in the on-premises world at one time. Time and technology developments have passed them by and they’re struggling to maintain relevance in the cloud world. But that’s no reason to pollute discussion forums with wildly inappropriate advocacy for their products.

In saying this, I also note that some vendors of cloud backup products are guilty of the same tactics, especially those who represent backup for Exchange Online mailboxes as coverage for other parts of Office 365, notably Teams. Inaccurate and misleading assertions might lure the unwary into signing up for their products, but the reputation of the company and their software suffers overall.

No Perfect Office 365 Backup Solution

No perfect backup solution exists for Office 365. The interconnectivity of applications and lack of supported backup APIs for Office 365 workloads create a challenging environment for backup vendors. If you’re considering investing in a backup product, my advice is:

• Only consider cloud-based backup solutions.
• Understand what the standard features in Office 365 can do to identify where you need extra protection which can be provided by a backup product. Don’t accept what backup vendors say – test and verify their assertions yourself. I’m not saying that backup vendors deliberately misrepresent Office 365 functionality; some don’t seem to understand the technology as well as they should.
• Optional add-ons for Office 365 might be better solutions for some of the reasons often cited to justify backups. For instance, Privileged Access Management can mitigate the damage which a rogue administrator can inflict.
• Understand how backup products access information in Office 365 workloads to copy data to their repositories. Remember that the quantity of cloud data is often larger than is kept in on-premises deployments.
• Understand how the products deal with cloud-only applications like Teams, Yammer, and Planner and how they deal with protected (encrypted) items.
• Understand how restore operations work, including the restoration of complete Microsoft 365 Groups.

Equipped with answers to these questions, you’ll be able to make an informed choice if you need backups for your Office 365 tenant and if so, the best backup software to meet your needs.

And never ever consider using PSTs as a backup mechanism for Exchange Online mailboxes…

Escalating to Tenant Restrictions

In a previous post, I wrote about how Exchange Online Protection monitors the email traffic sent from mailboxes to detect potential problems like compromised accounts or bulk mailings. These mailboxes are blocked (restricted) to stop outbound messages. Administrators can lift the restrictions on the mailboxes to resume normal service, hopefully after discovering a root cause.

After blocking individual mailboxes, the next escalation occurs when Exchange Online Protection considers that a component of the tenant might be compromised, and a wider restriction is necessary. At this point, the “tenant restricted from sending unprovisioned email” alert fires. This is one of the standard alert policies installed in Office 365 tenants, defined as happening when “when most of the email traffic from your organization has been detected as suspicious and Microsoft has restricted your organization from sending email.” Figure 1 shows the settings of the alert policy as viewed through the Security and Compliance Center.

Alert Notification

When the alert fires – and every hour or so thereafter until the alert is cleared – Exchange emails the tenant administrators a notification (email is OK because it’s an internal message) to inform them about the restriction (Figure 2).

Lack of Clarity and Precision in Notification

It’s important that notifications to tenant administrators are concise and clear. When I received this notification, I was confused about its meaning. The biggest issues are:

• “Unprovisioned” and “unregistered” domains are both mentioned. Microsoft’s online documentation doesn’t define what these domains are. As it turns out, both refer to domains that are not registered as accepted domains for the tenant.
• The first line of the notification therefore means that Exchange Online Protection has detected that most of the traffic from the tenant is related to unaccepted domains. This could be perfectly normal, especially for tenants with a small number of users where most of their communication might be with external correspondents.
• The second line says that the suspicious traffic is usually related to a compromised connector. However, my tenant doesn’t have any connectors (apart from those created by Exchange Online). It’s easy to check the messaging configuration of a tenant and highlight areas to check in email, a step that would have made the notification more valuable.
• The third line says that the tenant has been restricted from sending email with unregistered domains. Going back to the point about accepted domains, surely this means that no email can be sent to any external domain. But that’s not what happened because I was able to send and receive email with domains such as Microsoft.com while the restriction was in force.
• The last line advises the administrators to check for compromised user accounts, new connectors, or open relays. It would be nice if Microsoft included a link to a checklist for administrators to consult, and even better if Microsoft tailored the checklist to take account of the tenant configuration.

The net outcome is that I knew that Exchange Online Protection was worried about some traffic from the tenant and had done something to restrict some functionality. However, the lack of clarity and precision in the text meant that I was unsure of what caused the problem and how it should be resolved.

Resolving the Block

The first step in resolving any problem with email restriction is to make sure that there’s no obvious sign of problems with accounts or connectors. Are any accounts generating more email traffic than normal and if so, why? Is the traffic external or internal? Do the account owners know about the traffic? Have any new connectors been created, and so on.

If modern authentication with MFA is used for all accounts, it’s much less likely that accounts will be compromised (this is why Microsoft is removing basic authentication for several Exchange connection protocols). If this is the case, you should use message traces to check who is generating email traffic and try to understand if a spike in traffic is causing problems. For my tenant, the problem seemed to be caused by sending email to some large distribution lists where most of the members are external mail contacts. Microsoft’s monitoring picked up the traffic as a possible indication of spam (even though the messages were perfectly valid) and imposed the block.

Tenant administrators can’t lift the block. You must contact Microsoft Support and ask them to remove the block. Before you do this, gather evidence to prove that you’ve done the due diligence to check the tenant for problems like open relays, compromised accounts, new connectors, and so on. Doing this will avoid the need for wasted time as the support professional tries to understand the full scope of the problem. I’ve criticized Microsoft Support in the past, but when contacted them about this issue, the problem was resolved quickly and without fuss.

Improving Through Experience

Blocks and restrictions are needed to ensure that no tenant can soak resources in a multi-tenant environment like Office 365. Exchange Online Protection usually does a good job of protecting Exchange mailboxes from spam and malware. Microsoft has deployed a lot of machine learning and artificial intelligence to pick up problems as they emerge. In this instance, the algorithms were a little too sensitive and the notification wasn’t nearly precise enough. Feedback has been given to Microsoft to allow them to tweak things as needed. Here’s hoping this happens soon!

Sorting out why things happen inside Office 365 tenants is our passion. Learn more by subscribing to the Office 365 for IT Pros eBook and get monthly updates about everything important that happens inside Office 365.

Exchange Online Isn’t for Bulk Email

Microsoft makes it quite clear that Exchange Online is not a platform for mass mailing. Limits exist to stop people who want to send bulk mail (spam) or whose mailboxes are taken over by malware. Essentially, even though Microsoft recently increased the maximum recipient limit for a message from 500 to 1,000, it doesn’t mean that you should switch mass mailings to Exchange Online from commercial mailing platforms like Mailchimp.

Most of the time, my mailbox never comes to the attention of Exchange Online Protection and the monitoring tools that look for evidence of misuse. I usually don’t send enough email to ever run into the limits. But occasionally, I need to send messages to reasonably large distribution lists (200 to 600 members). I was curious to discover at what point Exchange Online clamped down.

Sender Limits

The documented limit for accounts holding Office 365 E3 or E5 licenses is 10,000 recipients per day. A distribution list managed by the tenant (not a personal list) counts as a single recipient. Controlling mailboxes by measuring the number of messages they send is a crude control mechanism. Exchange Online Protection applies more intelligent algorithms to pick up unusual activity which might be a sign that something’s going on. The settings used by Microsoft to detect problematic senders are undocumented (as you’d expect), but you can force Exchange Online Protection to take an interest in your sending activity.

For instance, if someone who typically send 10-15 messages daily suddenly sends 200 messages over a short period or suddenly starts to send messages to large distribution lists, it might be that they’ve been told to get a message out about something like a new price list to customers. A one-off event isn’t enough to create suspicion, but other signs might exist to increase confidence that something’s wrong. An example is that because hyperlinks can lead the unwary into bad places, messages containing links are more suspect than those with plain text.

A single spike in traffic from a mailbox probably isn’t serious, but if the observed behavior of the mailbox over time deviates significantly from its expected norm, then the account might be compromised, and action is necessary. To ensure that a potentially-compromised account can’t be used to send spam or malware, Exchange Online Protection restricts (blocks) the mailbox. This means that the user is permitted to send messages to internal recipients but not to external recipients, including mail contacts and guest users registered in the tenant directory.

The Block Descends

I tested the theory by sending some messages containing hyperlinks to distribution lists over the course of a working day. Sure enough, after sending messages to circa 2,500 recipients spread across several distribution lists, Exchange Online Protection decided enough was enough and blocked my mailbox. When it imposes a block, Exchange Online generates NDRs (Figure 1) for every external message the user tries to send. The text of the message is:

“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 email. Contact your email admin for assistance. Remote Server returned ‘550 5.1.8 Access denied, bad outbound sender.”

In addition, tenant administrators receive a notification about the blocked user. A HygieneEvent Office 365 audit event is logged to record the blocking and an AlertEntityGenerated event logged for the alert which generates the notification to administrators. “User restricted from sending email” is one of the standard alert policies created by Office 365 to alert administrators about problems in the tenant.

Unblocking Accounts

To investigate and unblock restricted accounts, an administrator goes to the Restricted Users section of the Security and Compliance Center to check the current list of blocked users (Figure 2). In this case, an account (mine) is restricted because Exchange Online Protection observed a high percentage (20.75%) of suspicious messages over the last 24 hours.

total for outbound messages is noted as 36. The two figures don’t quite make sense; 747 divided by 36 is 20.75, which is the percentage of spam reported. Microsoft needs to do some work to clarify the reported data and make it more precise.

Unblocking in PowerShell

As expected, the underlying Get-BlockedSenderAddress cmdlet doesn’t help much either. The message trace identifier reported here doesn’t work with the Get-MessageTrace cmdlet.

Get-BlockedSenderAddress | Format-List SenderAddress, Reason

SenderAddress: TONY.REDMOND@OFFICE365ITPROS.COM
Reason: OutboundSpamLast24Hours=747;OutboundMailLast24Hours=36;OutboundSpamPercent=2075;Last Spam Message MessagetraceId:b2223b2d-469d-440c-b409-08d82a588f0e;AS:1135

If you recognize a blocked account and know that it shouldn’t be blocked, you can release the account using the Microsoft Purview Compliance portal or with PowerShell. Here’s how to do it with the Remove-BlockedSenderAddress cmdlet:

Remove-BlockedSenderAddress -SenderAddress Tony.Redmond@Office365itpros.com -Reason "No problem with this account"

I can’t find an audit event logged when an account is unblocked. An unblocked account can’t send messages immediately as mail servers which handle outbound messages must be updated about the block being released. Updating all servers can take up to an hour.

Blocking is Unusual

Dealing with blocked accounts should be an unusual incident. Mailboxes must exhibit some out-of-course behavior before Exchange Online Protection regards them as potentially compromised or a source of spam. And if a block descends, the question is if the account is compromised or it’s because of some unusual email activity on the part of its owner. And that’s where the administrator earns their pay keeping their tenant safe.

We try to discover where limits are in Office 365 and how the limits are implemented so that you don’t find the limits in production. Or at least, if you do, you know what to do next. All documented in the Office 365 for IT Pros eBook.

Exchange Online Drops Processing of Non-Travel and Parcel Delivery Events

Office 365 notification MC218910 published on July 20, 2020 announces that Exchange Online will stop processing some inbound email to extract information used to create calendar events.

Events from Email has been around for a few years. The idea is that Exchange can detect events in messages like car hire reservations or airline bookings and use the information in the message to create calendar events to remind the user when the event is due. Because of the need to register organizations who sent messages containing event information, the feature has been most useful in the U.S. and Canada. Coverage is spottier and more inconsistent elsewhere.

Only Travel and Parcel Events

According to Microsoft, starting in late July with worldwide deployment complete by mid-August, Exchange Online will ignore events for:

• Bills (for example, you need to pay your electricity provider).
• Dining reservations.
• Events reservations (for instance, you have tickets to attend a concert).
• Service reservations (some other service you booked for is due to happen).

However, Exchange will continue to process events linked to travel (airline bookings, car hire, and lodging) plus events for parcel delivery (like Amazon.com notifications).

High-Value Events Retained

I don’t think the development will affect many users. Microsoft is retaining the high-value events linked to travel. People find it very useful for Exchange to extract details like flight numbers and departure times and use them to create calendar events (the resulting events like that shown in Figure 1 are usually more accurate than those created by cut and pasting information from airline booking messages). The case for parcel notifications is less obvious except that we all seem to be doing more online shopping at present.

Given the number of establishments which generate email notifications (see this list for the recognized senders supported by Microsoft), it’s understandable that Microsoft might want to drop processing for the non-travel events, especially when you consider the many varied formats used. The difficulty of tracking and processing so many different types of notifications is probably what’s driven Microsoft to this decision, which will be regretted by some and ignored by most.

This kind of change infuriates authors. Blog posts need to be updated, book content scrapped, and generally it makes life a little more difficult. But that’s why Office 365 for IT Pros is updated monthly to make sure that our readers always have up-to-date information at their fingertips.

Covid-19 Changing the Game

We live in fast-changing times. The results of the Covid-19 pandemic are being felt in many ways. Many people are working from home, conferences are being rescheduled until next year or going virtual, and Microsoft is being forced to reschedule planned developments in Office 365. Some things, like increasing the membership limit for Teams to 10,000 are being accelerated. Others, like the plan to remove basic authentication for five Exchange Online connection protocols, are being pushed out.

Basic Authentication is Still Bad

Basic authentication is bad for Exchange Online because it is a vulnerability often used as an attack vector. I strongly supported the original plan to remove basic authentication for ActiveSync, PowerShell, Exchange Web Service, and especially POP3 and IMAP4 in October 2020.

All the signs from Microsoft were that the Exchange product group wanted to make this happen and would hold the line. But pandemics have a funny habit of changing things, and so the product group has been forced to postpone removing basic authentication for the famous five protocols until some time in the second half of 2021.

Second Half of 2021

The lack of a definite target date is because no one know when the world will resume normal working. No doubt Microsoft wants to set a date that’s sooner rather than later, but for now July 1, 2021 is a good target date for planning.

In the meantime, new Office 365 tenants won’t get the chance to develop a bad habit because Microsoft is disabling basic authentication for the five protocols by default in those tenants. And in October 2020, they’ll get some satisfaction by disabling the protocols in tenants with no recorded use of basic authentication (in other words, Microsoft’s telemetry only records connections using modern authentication in the tenant).

Updates Coming for Affected Protocols

Updated 30 April 2020:

Microsoft is rolling out support for OAuth 2.0 support for SMTP AUTH and IMAP4 to allow developers to upgrade clients that use these now ancient (but beloved in parts) protocols. Support for POP3 is also in the works.

OAuth support is especially important for SMTP AUTH connections (used by applications and appliances to send email via Exchange Online). Although I can see how programmers will update POP3 and IMAP4 email clients to keep them working with Exchange Online, I have a harder job imagining how device manufacturers will get to update all the multi-function devices that send email like job completion notifications, Which is why Microsoft is holding to the line that they don’t plan to disable SMTP AUTH (for now).

Remote PowerShell will also be updated, and anyone using PowerShell to work with Exchange Online today is advised to start using the Exchange Online Management module, which supports MFA and OAuth. More work is needed to allow PowerShell scripts to run in unattended mode. That’s expected to appear in a future update for the module quite soon.

The Podcast Blues

The funny thing is that I was sure in my own mind that this would not happen and said so quite passionately when Paul Robichaux and I recorded episode 18 of our Office 365 Exposed podcast last night. I’ll have to see if Paul can edit those words out as he tweaks the recording for release…

Tracking dates is hard, especially inside an environment like Office 365 changes all the time. Subscribe to the Office 365 for IT Pros eBook and let us do the heavy lifting of date checking.

News via Twitter Reveals New Editor

A February 26 tweet from the redoubtable Ross Smith IV reveals that Microsoft has given Outlook for iOS a new rich text editor.

Welcome as the news is, it came as surprise because Microsoft didn’t issue an Office 365 notification. The feature is listed as Microsoft 365 roadmap item 54805 “rich text options” with a “rolling out” status. There’s no word (and no roadmap item) to say if Outlook for Android will receive similar capabilities.

New Editor Brightens Outlook for iOS Messages

In any case, although you won’t be tempted to write the next great chapter of your book with Outlook’s text editor, this is a nice step forward that allows senders to highlight and emphasize important points in their messages.

When you compose a new message, the rich text editor is accessed by clicking the A/pencil icon in the menu bar just above the keyboard. You can then apply three styles to text (body, subhead, and title), create bulleted and numbered lists, add clickable web links, and make text italics, bold, underlined, or a combination (Figure 2).

Of course, a new text editor won’t do anything to improve the quality of your writing, but the text might look more attractive than the simple formatting used to date.

The screen shot was taken using Outlook for iOS 4.27.0 (available in TestFlight). No doubt the new editor will land on a device close to you sometime soon.

Baffled by the blizzard of changes in Office 365? Subscribe to the Office 365 for IT Pros eBook and let us track updates for you.

Using Delegate Permissions to Manage Mailboxes

Office 365 Notification MC203923 published on Valentine’s Day gives the welcome news that Outlook mobile clients are gearing up to be able to use the Exchange Online delegate permissions to manage another user’s mailbox. This work builds on the shared mailbox support delivered for Outlook mobile last August. The net is that Outlook Mobile Delegate Access for Exchange Online mailboxes is now available.

The associated Microsoft 365 roadmap items (53666 for iOS and 53667 for Android) are somewhat obscure in what they say: “Delegates can access and manage messages within an owner’s inbox folder.” This is what shared mailbox support is all about. Fortunately, the notification is more helpful when it tells us that: “Delegates who have been granted full access permissions to send email and respond to calendar invitations on the behalf of another person will soon be able to do so from Outlook for iOS and Android.” Delegate access is described in this Microsoft support article.

Deployment Done by mid-April

Microsoft says that they are deploying the feature now. The minimum supported versions are Outlook mobile 4.25.0 for iOS (available in Testflight) and Outlook mobile 4.1.31 for Android. As always with Outlook mobile features, it takes a little time to get the new software everywhere. Microsoft says that worldwide deployment should be done by mid-April.

Full Access Permissions Needed

Delegate access only works when the user and the delegate both have Exchange Online mailboxes. The delegate must be assigned full access permission for the target mailbox before Outlook mobile can add it as a delegate mailbox. Permission is granted by editing the mailbox with the Microsoft 365 Admin Center. Open the mailbox properties and select the manage mailbox permissions tab. Then add the user to whom you want to grant access. Figure 1 shows the assignment of Full Access permission, referred to by the Admin Center as “Read and manage permission.”

Alternatively, run the Add-MailboxPermission PowerShell cmdlet. This example gives James Ryan full access to the mailbox owned by Kim Akers. The automapping parameter is set to false to stop Outlook desktop including the mailbox in the set of resources automatically opened by the client.

# Add full access permission to mailbox but don't automap
Add-MailboxPermission -Identity Kim.Akers -AccessRights FullAccess -User James.Ryan@Office365itpros.com -AutoMapping $False

Full Access grants a delegate the ability to open the mailbox and interact with its content. It grants the delegate access to every folder, meaning that they can manage the calendar. The delegate can also read every message in the mailbox. Outlook mobile doesn’t use the set of granular folder-level permissions supported by Outlook desktop to grant delegate access to specific folders.

Permission to Send Email Needed Too

Full Access doesn’t allow a delegate to impersonate the mailbox owner when sending messages. A second permission is needed, and the delegate needs to be assigned either Send On Behalf or SendAs permission. These permissions can be added through EAC or by running the Add-MailboxRecipientPermission (SendAs) or Set-Mailbox (Send On Behalf) cmdlets. For example:

# Add permission for a user to send as another user
Add-MailboxRecipientPermission -Identity Kim.Akers -AccessRights SendAs -Trustee James.Ryan
Set-Mailbox -Identity Kim.Akers -GrantSendOnBehalfTo James.Ryan

It takes a few minutes to ensure that the new permissions are fully respected across Office 365.

Adding the Mailbox to Outlook Mobile

Open Outlook mobile and go to the Settings section. Select Add Email Account and then Add Shared Mailbox. Input the SMTP address of the mailbox you want to add. If your account has delegate permissions for the mailbox, Outlook mobile lists it in the set of mailbox resources accessible in the client (Figure 2).

You can also add a delegate mailbox from the list of mailboxes displayed by Outlook mobile (left-hand navigation) by selecting the mailbox add icon at the bottom of the list.

Processing Email

After adding the delegate mailbox, you should be able to see all the folders in the mailbox including the calendar. You can interact with any of the messages in the delegated mailbox as if you are the owner, meaning that you can delete messages, move them between folders, and so on.

To send a message, click the New message icon and compose the message ad normal. The name of the mailbox being used is displayed under the New Message label (Figure 3). Note that in this case my signature is included in messages created for the delegated mailbox.

If you’re using delegate mailboxes, you’ll want to create a separate signature for each mailbox. Do in Settings by selecting Signature and then enabling per-account signature. You can then enter a signature for each account.

Another way to send from a delegated mailbox is to compose a message and then select the mailbox to use from the drop-down list of accounts under the New Message label (Figure 4).

Delegate Access is Another Reason to Use Outlook Mobile

Adding functionality like delegate access to mailboxes underscores the advantage of using Outlook mobile with Exchange Online compared to clients based on the ActiveSync protocol. ActiveSync is a very successful protocol that helped Microsoft evangelize mobile connections to Exchange across a wide range of email clients, but it’s an aging protocol now and just doesn’t have the same functionality as the newer Microsoft sync technology. If you’re not using Outlook mobile now, maybe now’s the time to consider switching?

The Office 365 for IT Pros eBook covers clients in some detail, including how delegate access works. It’s another reason why you should be a subscriber.

Remind Meeting Attendees of Protocol and Expectations

Perhaps not for calendar meeting notification, but certainly for “normal messages,” adding a disclaimer (aka auto-signature) to Exchange Online messages is a well-trodden path. The process is straightforward: create a transport (mail flow) rule to add some disclaimer text and enable the rule. You can include HTML-formatted text and insert attributes about the sender into the disclaimer text such as their name, title, and telephone number.

The Exchange transport service will apply the text to every outbound record. This process works even with protected (encrypted) messages because the Exchange transport service is able to decrypt and re-encrypt messages. Just about the only complication is to include an exception condition in the rule to avoid applying the same disclaimer to the replies for an original message as that creates disclaimer upon disclaimer, which isn’t good.

All good, but what happens if you want to insert a special disclaimer into calendar notifications to remind internal users about meeting protocol, privacy, or etiquette (like “please tidy up the meeting room when you are finished”). Or to include a link to remind people about the etiquette for online Teams meetings, like staying muted until they’d like to speak or using meeting chat to ask questions.

Email X-Headers Identify Calendar Meeting Notifications

The solution is to use a transport rule that checks for the presence of an X-header added by Exchange to calendar meeting notifications. Some quick browsing of the headers of a meeting notification using the Outlook Message Header Analyzer add-in revealed the presence of a header called X-MS-Exchange-Calendar-Originator-id, which seemed like a good bet (Figure 1).

It didn’t take long to create a rule (Figure 2) to check if this header had a value (I used part of the distinguished name of the meeting originator) and apply a disclaimer. I also added an exception to make sure that the disclaimer wouldn’t be applied if the text already existed in the message.

X-MS-TrafficTypeDignostic might be an even better header to use. This header contains the name of the originating server and “MeetingMessage”, so you could check for that value.

Testing that the Disclaimer Works

Adding a rule is one thing. Seeing it work is another. Fortunately, the rule does work (Figure 3) and the disclaimer shows up in meeting notifications delivered to internal recipients, including those created in the Teams calendar app. This is because Teams uses the calendar in user mailboxes to generate meeting invitations, which flow through the Exchange transport service like any other message. It is at this point the mail flow rules kick in to insert the disclaimer.

External Recipients Can Receive a Different Disclaimer

Because the scope of the mail flow rule is limited to recipients inside the organization, external people never see the disclaimer. If you want external recipients to see a disclaimer in calendar meeting notifications, simply create a similar mail flow rule with the scope set to people outside the organization and change the disclaimer text as appropriate.

Test in Your Organization

I haven’t done extensive testing to verify that the disclaimer works in all circumstances which might exist in Office 365 tenants. In some situations, adding a disclaimer to a meeting notification can cause a receiving mail server to process calendar notifications as if they were normal email, which means that the recipient loses the ability to respond to the notification. The mail flow rule described here applies only to messages sent internally, which was the original message, so the messages with disclaimers never reach an external server. However, I have done similar work with disclaimers going to Outlook.com and Gmail.com recipients and know that calendar notifications with disclaimers work to these destinations.

After several months of the rule being in place, it seems to work reasonably well and certainly is a basis for further enhancement if this is needed by an organization.

It’s amazing what you can do with a little knowledge of how Exchange works…

Chapter 17 of the Office 365 for IT Pros eBook explains mail flow rules in great detail. It’s worth reading!

Quickly Find Attachments in Primary Mailbox

In the run-up to the Christmas holidays, you might have missed Office 365 notification MC198342 posted on 17 December to announce the advent of the OWA Files view. According to Microsoft 365 Roadmap item 59643 this is “a view of all the files sent and received as attachments in your inbox.” In reality, the Files view enables quick access to every sent or received attachment in every folder in your primary mailbox.

The feature is now rolling out to tenants and should be available throughout Office 365 by the end of March. You’ll know if it’s available when the Files icon shows up in OWA’s module switcher (Figure 1). Clicking the icon takes you to https://outlook.office.com/files/.

Microsoft hasn’t said if they will add this feature to OWA for Exchange on-premises. My feeling is that this is doubtful.

The Files View

The Files View presents attachments found in a mailbox in five columns, each of which is sortable. The default sort is by received date (newer to older), while Figure 2 shows attachments sorted by name (Z to A).

Newly received or sent attachments don’t show up immediately in the view.

If you select an attachment, OWA opens it and the message it belongs to in a viewer. You can hide the message if you want to concentrate on the attachment.

Types of Attachments

By default, all types of attachment are shown. OWA differentiates between Files (Office documents, PDFs, text, email, and other non-graphic types) and Photos (files in graphic formats like JPEG or PNG). When browsing photo attachments, choosing Tiles rather than a list can help locate the right attachment faster (Figure 3).

Filtering Attachments

You can choose to see all attachment types or switch between Files and Photos using the options in the left-hand navigation pane or the Filter drop-down (Figure 4), which allows you to select exactly what you want to see. The date range part of the filter is very useful when you want to find attachments sent in a specific period. You can combine a date range with filters for specific file types.

To refine the view further, you can input search terms into the search box. OWA will apply the search to the items in the view and display what it finds.

No Archived Attachments

OWA’s Files view only shows attachments stored in the primary mailbox. Attachments moved into archive mailboxes (not to be confused with the Archive folder in mailboxes) are not shown in the Files view. You’ll have to open the archive mailbox and use a search to find information stored there. This isn’t surprising because archive mailboxes are intended to hold information that is not needed very often.

The Substrate is the Key

Microsoft dipped their toes into a Files view for OWA with “group files” for Office 365 Groups in 2016. That feature is less functional than the generalized Files view now being introduced. In both cases, the features depend on the capture and storage of information by the Office 365 substrate. Hidden folders in user mailboxes (like GraphFilesAndWorkingSetSearchFolder) hold metadata and copies of attachments. OWA uses this data for fast access to information and to avoid the need to scan a mailbox looking for messages with attachments.

Poking around the folders in the “non interpersonal messaging” (aka Non-IPM subtree) part of an Exchange Online mailbox with a tool like MFCMAPI reveals that cloud mailboxes hold a lot more information than their on-premises counterparts. The overall size of these mailboxes is much larger than you’d expect. Features must be paid for with resources, and cloud storage is cheap (except for SharePoint Online).

OWA Files is an example of a new feature that may or may not make a difference to you. But it’s good to know about stuff like this, which is why we keep an eye on Office 365 developments for you and document the most important in the Office 365 for IT Pros eBook. Subscribe today to stay informed.

OWA or Mobile Outlook

I don’t know many Office 365 users who like accessing their email with OWA on a mobile device when Outlook mobile is available, but obviously some do. Perhaps they don’t like installing apps on their phone or use a non-standard mobile device that Outlook mobile doesn’t support, or they hark back to the days when OWA for Devices was the cornerstone of Microsoft’s mobile email strategy. In any case, folks in this category should note the news in Office 365 Notification MC202145 that the new OWA is becoming the only option for mobile browsers. This switchover happened for other browsers last July.

You can use the new OWA today with mobile browsers. What’s changing is that Microsoft is removing the toggle that allows users to switch between the new old and the older version (Figure 1). When this happens, users will only be able to access the new OWA. The changeover starts in February 2020 and should be complete by the beginning of March.

The change is a roadmap item (59334) and will relieve Microsoft from the need to maintain a separate code base for OWA for mobile browers.

Missing Features in New OWA

The list of not supported and won’t ever be supported features for the new OWA on mobile browsers is a lot more interesting than the loss of a toggle swatch. OWA is the fastest evolving of all the Exchange Online clients so there’s pressure to add new features and drop old features for the client in general. Mobile browsers introduce another decision point, which is the set of features available in the mainline versions of OWA to exclude because they are inappropriate in a mobile environment, won’t work, or can’t fit into the browser UI.

For example, in the list of unsupported features, there’s going to be no option to set message sensitivity and importance or assign retention policies. I assume that the way OWA handles sensitivity labels, especially when labels invoke encryption for messages, is one of the factors driving why sensitivity labels won’t be supported. Outlook mobile supports assigning sensitivity labels to new messages, but the processing is done on the server rather than in the client, which is what OWA does. Perhaps there’s no way to call the code to process encryption in a mobile browser context. Although I am surprised that OWA on mobile browsers won’t support retention labels, this is probably because most users don’t assign retention labels and leave it retention to organizational policies that execute in the background.

Other notable exclusions are that you can’t access Outlook add-ons in mobile browsers, or view shared folders or mailboxes, or shared calendars.

Use Outlook Mobile

The list of missing features underlines the argument to use Outlook Mobile (if possible). The iOS and Android variants both work well, are highly functional, and much faster than using OWA in a mobile browser. And with a 100+ million user base (as of May 2019), Outlook Mobile is the most popular choice for mobile email access for Office 365 users. Even if I can’t use some of Outlook Mobile’s party tricks (like Play My Emails), it’s still the best choice for most users.

Need to know more about Exchange Online email clients? Look no further than the Office 365 for IT Pros eBook, which covers all the major clients in depth.

Signs of Obvious Phishing in a Message

Another day, another phishing attempt. This one arrived in my inbox with all the signs to create heightened suspicion. Although offering the prospect of money, the message:

• Was from someone I didn’t know and a domain (omneshealthcare.co.uk) I didn’t recognize. Using a browser to access the domain reveals that the company is real with an insecure web (doesn’t use https), which is always a bad sign because it means that the domain is open to being compromised.
• Included a spelling error in the attachment name (“reciept”).
• Attachment proclaimed itself as a PDF but wasn’t. The PDF icon is smudged, and the attachment is a link to a file on a zoho.eu server (Figure 1).

In addition, examination of the results reported by the Message Header Analyzer add-in for Outlook revealed a DKIM failure (body hash did not verify). All in all, not a very authentic message.

Simple but Effective Attack

The attack is simple. Have users click the PDF attachment to find out how much money they’ve been paid to reveal. Display a file (Figure 2) with a big Click Here to Access File button (note the comforting assertion that Office 365 has secured the file).

When the user clicks the button, they go to a web site to gather their credentials (Figure 3). Note the name of the site. I’m sure usigaramoldova.ro is a well-known sign-in point to access Microsoft cloud services.

After the user has entered their credentials, the attacker stores the credentials away for later use. It’s a surprisingly effective method to convince people to reveal their username and password.

Reporting Spam to Microsoft

Despite using Office 365 Advanced Threat Protection, this phishing attempt got through to my mailbox. Focused Inbox even considered the message important enough to keep it in Focused instead of Other. All of which proves that some malware will penetrate defenses. My experience with Office 365 is that only a very small amount of spam gets this far and usually it’s because a message doesn’t exhibit known characteristics to mark it as a problem. It’s easy for a human to examine a message and pick up suspicious signs like bad spelling, formatting, and an unknown sender. It’s harder for machine learning to detect subtle signs like this (if every message was rejected because of a spelling mistake in an attachment name, how many would get through?). This underlines the need to coach users about how to recognize the signs of problematic messages that might be phishing attacks.

The best course of action if messages reach inboxes is to report them to Microsoft to allow investigators to examine the messages and understand how they passed message hygiene checks. Microsoft can then make whatever changes are necessary to their malware detection technology and we all benefit.

Learn more about mounting effective anti-malware defenses in Chapter 17 of the Office 365 for IT Pros eBook. So many policies, so many settings, all important!

New Configurable Mailbox Property for Maximum Recipients for a Message

As a cloud service, Office 365 uses preset limits (like custom recipient limits) to protect both Microsoft and its customers from abuse. Although most of the limits are set to reasonable values, in some cases organizations want to be able to modify them and complaints about “loss of control” after the switch to the cloud are not uncommon. Throttling policies in Exchange Online are one such example – the corresponding UI and PowerShell cmdlets have been removed from Exchange Online.

Custom recipient limits are a more specific example. This setting controls the maximum number of recipients for a single message sent from an Exchange Online mailbox. Ever since Office 365 launched, this limit has been 500 recipients, and could not be changed. Now, Microsoft is releasing a feature that allows organizations to customize this value. This was originally announced back at the Microsoft Ignite 2019 conference, and just recently the feature started rolling out through the different regions.

Any Value Between 1 and 1000

The feature does what it says, allowing you to configure custom values for the RecipientLimits property of a mailbox. You can set the value to anything between 1 and 1000. If you try to set it to a value outside of this range, an error is generated. So no, you cannot set it to 0, if you want to prevent the user from sending any message you have to use a mail flow rule. For additional information about the customizable recipient limits feature, you can refer to the feature description in Microsoft 365 Roadmap item 55025 (Figure 1).

Setting a Custom Recipients Limit on a Mailbox

Currently you can only change the recipient limits via PowerShell, but the corresponding UI bits are also rolling out and should be available at some point in the EAC. Here are some examples on how you can utilize this. First, if you want to change the recipient limit for a single mailbox, you can use the Set-Mailbox cmdlet:

Set-Mailbox user@domain.com -RecipientLimits 999

If you want to perform the change against a group of users, you can easily do so by using filters or importing the list from a CSV file. For example, here’s how to do it on all users in a specific department:

Get-User -RecipientTypeDetails UserMailbox -Filter {Department -eq "Marketing"} | Set-Mailbox -RecipientLimits 100

Or if you want to change it for all user mailboxes in the organization:

Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-Mailbox -RecipientLimits 10

Note: The new Get-ExoMailbox cmdlet is faster at finding large sets of mailboxes. To confirm the limit is changed, you can use the Get-Mailbox cmdlet to check the values on each mailbox.

It is important to understand that Set-Mailbox can only be used to change the limit for mailboxes that are already provisioned. If you want to make sure that a given limit applies to any newly created mailboxes, you can do so via the Set-MailboxPlan cmdlet. For example, to set the recipient limit to 100 on any newly provisioned Exchange Online Plan 1 mailboxes, you need to change the value on the corresponding “ExchangeOnline” plan. Similarly, you must change the “ExchangeOnlineEnterprise” plan for Exchange Online Plan 2 mailboxes, and so on.

Update Mailbox Plans for New Mailboxes

Set-MailboxPlan ExchangeOnline -RecipientLimits 50

To find the default recipient limits values for the different mailbox plans, use the following command:

Get-MailboxPlan | ft DisplayName, RecipientLimits

DisplayName              RecipientLimits
-----------              ---------------
ExchangeOnline           50
ExchangeOnlineEnterprise 500
ExchangeOnlineDeskless   500
ExchangeOnlineEssentials 500

Organization Recipient Limits in the Anti-Spam Policy

Recipient limits are also specified in the outbound anti-spam policy (Figure 1), managed through the Security and Compliance Center. The limits discussed above are limits applied to a single message. The limits in the anti-spam policy control the number of internal and external recipients a user can address in an hour or day (for both types).

The limits set in the outbound spam policy can’t exceed the sending limits for Exchange Online, which allow for a user to send to a maximum of 10,000 recipients per day.

There is lots of information about different aspects of Office 365 and Exchange Online management in the Office 365 for IT Pros eBook. Subscribe to learn and keep up to date with developments inside Office 365.

Using Tenant Domains for OME Email is Sensible

As a fan of Office 365 Message Encryption (OME), I was bemused by Office 365 notification MC196886 published on November 27. The notification covers some updates intended to improve the authenticity of OME messages. In other words, to make sure that messages generated by OME (for example, to send recipients a one-time code to enable them to decrypt a message) were delivered and not treated as spam or junk mail.

These updates are due to begin rolling out to tenants in January 2020 and be complete in February 2020. The updates fulfill Office 365 roadmap item 59001.

The OME Updates

The updates coming next month are:

1. OME will use a different layout for encrypted messages. No problem there. You can either accept Microsoft’s default layout or customize it.
2. OME will use the customer domain. See the explanation below.
3. Reduced odds that OME email will be identified as spam. This is associated with point 2.
4. Capture non-delivery receipt (NDR) email. NDR is normally referred to as a non-delivery notification, but the explanation that you should create a bounces@ mailbox to capture NDRs was a tad terse, so we go into it below.

Using Tenant Domains for OME Service Messages

After the updates are applied, service messages generated by OME will use the sender’s domain. Today, OME messages originate from addresses like microsoftoffice365@messaging.onmicrosoft.com (Figure 1).

In an era when it is easy for an attacker to spin up a new Office 365 tenant and use it to send phishing messages that look very similar to authentic messages, the potential existed for receiving email systems to consider OME service messages to be spam and redirect the messages to recipients’ junk email folder.

The change to use the sender domain means that receiving systems apply the same tests to OME messages as they do to other messages sent from the tenant. If sender domains are correctly configured for SPF, DMARC, and DKIM (including each domain having a valid DKIM signature), it is much more likely that OME messages are deemed to be authentic and delivered to inboxes.

OME Bounces Mailbox

When a recipient uses the OME portal to open a protected message, they can take whatever actions are assigned to them over the message. For instance, if a recipient opens a message protected with Encrypt-Only, they can reply to the message or forward it to someone else (Figure 2).

However, if they make a mistake and add a recipient that doesn’t exist or enter an incorrect email address, OME won’t be able to deliver the reply and the original recipient won’t know that the message failed because they won’t receive a non-delivery notification (NDR) as they would for normal messages. To get around the problem, tenants can create a bounces mailbox to receive NDRs for failures generated by recipient interaction with the OME portal. The intention is that someone with access to the mailbox can review NDRs and advise users what they should do next.

A bounces mailbox is any mailbox with the proxy address bounces@tenantdomain.com. A shared mailbox is a good choice for this task, and you should assign proxy addresses to the mailbox for all domains used by the tenant. For example, the bounces mailbox for the Office 365 for IT Pros tenant has the proxy addresses:

Bounces@office365itpros.com

Bounces@office365itpros.onmicrosoft.com

Interpreting Microsoft announcements about new Office 365 functionality is what we do to keep the Office 365 for IT Pros eBook updated. That’s why you should subscribe to keep yourself informed.

Growing Reach of Sensitivity Labels

Using Microsoft 365 Sensitivity Labels is becoming a popular method to mark important content and to protect that content with encryption (using the Azure Information Protection service). It’s likely that sensitivity labels will become even more popular after Microsoft releases their long-promised and much-awaited native support for the Office online apps and SharePoint Online (now in preview). OWA already has native support for sensitivity labels. Native support means that apps include the necessary code to protect content based on the labels published to the Office 365 tenant. Soon you’ll be able to assign labels to Office 365 Groups, Teams, and SharePoint Online sites, not to protect the content inside these containers but to control settings for the containers. Overall, there’s a lot happening with sensitivity labels.

Exchange Transport Rule Makes it Easy to Block Protected Messages

Assuming users assign sensitivity labels to important content, it might be a good idea to stop that content leaving the organization by email. Exchange Online passes all outbound messages through the transport service. As messages pass through the transport pipeline, the transport service checks each message to decide if it needs to process the transport (or mail flow) rules defined in the tenant. It’s possible to create a transport rule to look for protected messages and stop them being sent if they are of a certain sensitivity.

X-Headers and Sensitivity Label GUIDs

As messages pass through the Exchange Online transport pipeline, Exchange adds x-headers to record details of their processing. One of the x-headers added to outbound messages is called msip_labels. It records sensitivity label information such as the name and GUID of the label applied to a message.

The name of a sensitivity label is probably not unique, but its GUID is unique to the organization. This is an important point because we might want to block outbound messages stamped with the “Ultra Confidential” label belonging to our tenant while being perfectly happy to allow messages stamped “Ultra Confidential” by another Office 365 tenant to be sent. In this scenario, both labels have the same name but different GUIDs.

To block outbound messages stamped with a certain sensitivity label, the rule criteria are:

• Apply to outbound messages.
• Check the msip_labels x-header and if the GUID for the label is found, block the message with the action “Reject the message with the explanation.” The text for the explanation is up to you, but might be something like “You can’t send sensitive messages outside the organization.”

For example, let’s assume that you have a label with a GUID of ed4411cc-bec4-444a-b279-c404aaad79d6. The text that the transport rule should look for in the x-header is:

MSIP_Label_ ed4411cc-bec4-444a-b279-c404aaad79d6_Enabled=true

If found, we know that this message (or one of its attachments) is protected with the label, so the rule can go ahead and block the message. Figure 1 shows the rule criteria as entered in the Exchange Admin Center:

A single rule can block multiple sensitivity labels, each identified by their GUID. Remember that it can take between ten and thirty minutes before a change made to a transport rule becomes effective across Exchange Online. This delay is due to rule caching for performance and the need to distribute the rule update across multiple servers.

Finding the GUID for an Office 365 Sensitivity Label

Office 365 Sensitivity Labels are managed through the Security and Compliance Center. The information exposed for a label doesn’t include the GUID (Figure 2).

But we can find the necessary information with PowerShell. To do this, we need to connect to the Security and Compliance Center endpoint and run the Get-Label cmdlet.

# Retrieve GUID for the Intellectual Property Sensitivity Label.
(Get-Label -Identity "intellectual property").Guid

Guid
----
ed4411cc-bec4-444a-b279-c404aaad79d6

Need more information about transport rules or Office 365 Sensitivity Labels? The Office 365 for IT Pros eBook covers transport rules in the Mail Flow chapter (17) while Sensitivity Labels and the associated Azure Information Protection technology is covered in Chapter 24.

Do Not Disturb Feature Now Enabled for Office 365 and Outlook.com Accounts

Some news from Microsoft reveals that Outlook for iOS now supports the Do Not Disturb feature that its Android counterpart has had since July 2018. The delay in bringing the feature to iOS is curious and is perhaps associated with some difficulties manipulating the Apple notification service, something that Teams managed with its Quiet Hours feature in November. Microsoft says that Do Not Disturb can be set for Outlook for iOS by any Office 365 or Outlook.com account.

The idea is similar: to set times when you don’t want notifications for an app to arrive on your device. In the case of Outlook, a reasonable set of options are available to disable notifications indefinitely, for an hour, until the next day, for for some predefined periods like the work day or weekends (Figure 1).

Setting Do No Disturb for Outlook

Setting Do Not Disturb is straightforward. Go to the Home menu to view the set of accounts configured for Outlook. Now select which account for which you want to set Do Not Disturb. Or, if you want to set Do Not Disturb for all accounts, click the Home icon. Now select the alarm bell icon to define the notification block period. In Figure 2, you can see that three accounts are configured for Outlook and all the accounts are set to Do Not Disturb.

Click the alarm bell to change or disable the settings. For example, you might decide to silence some accounts and keep others active when you expect some high-priority messages to arrive.

Play My Emails and Time to Leave Both Need Cortana

Outlook mobile has been on a roll in terms of introducing new features recently. However, it’s not good that some of the more interesting features in Outlook are currently confined to the U.S. with no information available when they might become available elsewhere. Play My Emails, which allows Office 365 users to have their email read to them and to respond with voice commands, and Time to Leave, which prompts users when they need to leave their current location to be on time for a meeting, are both only available in the U.S. Or, as Microsoft says in the original announcement about Time to Leave in December 2017, markets where “Cortana is available.”

Microsoft made a big thing of the Play My Emails feature at the Ignite 2019 Conference. Customers were offered the chance to ride an exercise bike while processing their inbox, an activity that raised several thousand dollars for charity. A more normal example might be to process messages while driving into work, in countries where this kind of mobile usage is allowed. Duly impressed (with the technology, not the exercise), I asked the Outlook team why my account didn’t support the feature (Figure 3) only to discover that Play My Emails requires Cortana to be available in the Office 365 datacenter region hosting your mailbox. The three accounts listed here are an Office 365 account, an Outlook.com account, and a shared mailbox.

The same underlying problem appears to block the ability of non-U.S. Outlook accounts to be notified by Time to Leave, a service also powered by the elusive Cortana.

Configuring iOS to be in the U.S. or setting the location for your Office 365 account to be in the U.S. isn’t enough to trick Cortana that she can process your email or help you get to meetings on time. The availability of the features is dependent on where your mailbox runs. In my case, it’s the Western Europe datacenter region where the active copy of my mailbox might be in Dublin, Amsterdam, Vienna, or Helsinki, depending on how Exchange Online feels like on the day in question.

It’s great to see new technology coming through in mobile devices, but it’s sad when Microsoft’s vaunted campaign to make increased use of artificial intelligence and machine learning is incapable of supporting features outside the U.S. Much as it pains me to say this, there is a world outside Redmond…

For more coverage and information about Office 365 clients, read the chapter in the Office 365 for IT Pros eBook.

Improve the Readability of Teams Messages

From time to time, I check the settings in Teams policies to see if anything new has turned up or to pick up on something that I previously missed. Recently, I noticed the Immersive reader setting in the Teams Messaging policy (in PowerShell, it’s the AllowImmersiveReader property set with the Set-CsTeamsMessagingPolicy cmdlet). The description in the documentation says:

Allow immersive reader for viewing messages Turn this setting on to let users view messages in Microsoft Immersive Reader. Immersive Reader is a learning tool that provides a full screen reading experience to increase readability of text.

The Microsoft Immersive Reader is a free tool built into many Office programs to make it easier for people to read text. As you’d expect, the implementation differs across the apps. For instance, in Outlook desktop, the Read Aloud button reads the text of the message in the preview pane or when a message is opened. By comparison, the implementation in Teams and OWA is more “immersive” because the message opens in a full-screen window and the text is enlarged.

Using the Immersive Reader in Teams

You can read messages in personal or group chats or channel conversations with the Immersive Reader. Click the […] menu and select Immersive Reader (Figure 1).

Teams opens the message in full-screen mode. You can scroll through the text or have it read to you, with options to select a Male or Female voice and different speeds (Figure 2). I have not tried the reader in languages other than English, and the English reader doesn’t do so well if it meets non-English text. Perhaps people who use Teams in other languages can check and report back on their experience.

Using the Immersive Reader in OWA

OWA takes much the same kind of approach as used in Teams. Select a message, lick the […] menu, and choose Show in immersive reader (Figure 3). The same kind of controls and display seen in Teams are available when you open email with the immersive reader.

Most tenant administrators probably haven’t given much thought to message readability because there are many other things to worry about when managing Teams or Exchange Online. However, it’s nice to see technology like this available in the Office apps. A small but pleasant way to make Teams and email more accessible to all.

Although we don’t cover the Microsoft Immersive Reader in any depth in the Office 365 for IT Pros eBook, there’s lots more to discuss about Teams, Exchange Online, OWA, and other bits of Office 365. About 1,200 pages and counting…

Office Depends on Unified Labeling Client

Office 365 Message Center Notification MC193997 (24 October) brings the news that OWA will soon be able to automatically apply Office 365 sensitivity labels to outbound email (Office 365 roadmap item 56649). Automatic application is based on the detection of sensitive data types in content. This feature requires accounts to have Office 365 E5 licenses and is being deployed to Targeted Release tenants with roll-out due to complete by the end of 2019.

Outlook and the other Office desktop applications can apply sensitivity labels automatically if the Azure Information Protection client is installed on a PC. Microsoft is now upgrading Office applications to support the same functionality and OWA is the first application to receive the capability. Microsoft announced the preview for support for sensitivity labels in the Office Online apps and SharePoint Online at the Microsoft Ignite 2019 conference.

Auto-Labeling on Send

OWA applies automatic labeling when messages are sent and uses the content of the message body to decide if the test for the sensitive data is satisfied. The other Office applications perform automatic labeling when files are saved.

The sensitive data types used to detect content for auto-labeling are the same as used elsewhere in Office 365 (for instance, by data loss prevention policies) and the same concepts of defining the number of occurrences of the data type that must exist in a file or message together with the confidence level that the data type is what it seems to be are used to define when a match exists.

Defining Labels for Automatic Protection

Figure 1 shows the properties of a sensitivity label with auto-labeling enabled. In this case, the label will be applied to any document or file where a client detects the existence of a single credit card number. Typically, you combine this feature with content marking to apply a header or footer to warn users that sensitive data is present and encryption (if desired) to protect the information. The message displayed to the user is free-form text to communicate to users when their items are automatically labelled. In this case a suitable message might be “Automatic protection applied because this message contains a credit card number.”

Priority Dictates Which Label to Apply

It is possible that several sensitivity labels invoke automatic labeling and match against content in an item. When this happens, Office 365 applies the label with the highest priority as ordered in the sensitivity label policy published to the user. The first label in a policy has the lowest priority while the last has the highest priority (most sensitive).

Need to know more about Office 365 Sensitivity Labels? Look no further than Chapter 24 of the Office 365 for IT Pros eBook. It’s packed full of information on this topic.

Finishing Microsoft Ignite 2019 With Another Teams Session

One of the unique joys for all conference presenters is waiting for an audience to assemble. Will anyone turn up? Will only a few be waiting for me to start? Will people leave during the session? Will they like my material? I must admit to having some of these doubts at conferences where I have presented.

My last session at Microsoft Ignite 2019 was scheduled for Friday morning, the day after the attendee party at Universal Studios. The party ended at midnight and it takes time for people to get back to their hotels, so asking them to be at a 9:15am session on the last day of the conference is a stretch for some. And when I walked into the room about 30 minutes before the session started, rows of empty seats were waiting to be filled (Figure 1).

I wasn’t quite sure about the maximum capacity, but it was certainly in the high hundreds or early thousands. You can’t see past the front row once things start because of the very bright lights on the stage that are needed to record the video, so it wasn’t possible to know exactly how many turned up. Let’s leave it at enough to fill a large part of the room. All went well.

Will Teams Take Over from Email Recording and Deck Online

The recording for the session is available online at the Microsoft Ignite 2019 site. A link to a copy of the deck is below.

A write-up for the talk is available on the AvePoint web site.

It’s difficult to formulate a collaboration strategy for an organization without good information. If you need to know more about the strengths and weaknesses of Teams and email inside Office 365, read the Office 365 for IT Pros eBook.

New 1 TB limit for Exchange Online Bottomless Archives

Microsoft announced a “a truly bottomless archive” for Exchange Online in June 2015. At the time, Microsoft said that “the unlimited archive storage…” was available to “our Office 365 Enterprise E3 and E4 (now E5) plans.” The roll-out of the technology had some challenges, but stabilized at the end of 2016. I haven’t been aware of any great problems since and tenants now have some pretty large multi-terabyte archive mailboxes.

It turns out that unlimited isn’t unlimited after all. Microsoft recently updated the Exchange Online Archiving Service Description to say “The unlimited archiving feature in Office 365 (called auto-expanding archiving) provides up to 1 TB of storage in archive mailboxes in Exchange Online.” The same limit is documented in Exchange Online limits, which says “Each user initially receives 100 GB of storage in the archive mailbox. When auto-expanding archiving is turned on, additional storage is automatically added when the 100 GB storage capacity is reached. Office 365 provides up to 1 TB of additional storage in an archive mailbox.” The limit is enforced by restricting the number of auxiliary archives to 20. The bottom has well and truly been reached!

Users who already have archives that exceed the 1 TB threshold won’t lose data. However, they won’t be able to expand their archive by adding any more auxiliary mailboxes. At least, they won’t when Microsoft moves from a paper-based limitation to imposing a block in code.

Update August 1 2021: Microsoft’s current stance is that unlimited archiving is still supported with no mention of a 1 TB limit. However, they make the point that the growth rate of the archive should not exceed 1 GB/day to exclude activities such as migration from legacy on-premises archive solutions.

All Quiet on the Microsoft Front

Microsoft didn’t announce the change. A notification wasn’t posted in the Office 365 admin center, no press release was issued, and the information released for the Microsoft Ignite conference in Orlando this week is curiously mute on the point. The only conclusion is that Microsoft is embarrassed at having to retreat from a commitment made to customers in 2015 and emphasized multiple times since.

Why has this happened? I don’t know what circumstances convinced Microsoft to terminate unlimited archive storage. I suspect that it might be associated to the way that some migration tools use archive mailboxes as targets to import data from third-party systems like Enterprise Vault. Often there’s no problem as the migration moves information belonging to users from the legacy repository to their archive mailboxes, but issues do occur when the migration moves information for multiple users (for instance, data for ex-employees) to a single archive mailbox.

Migration to Archive Mailboxes

Microsoft makes their view clear about how people should use auto-expanding mailboxes: “Auto-expanding archive is only supported for mailboxes used for individual users (or shared mailboxes) with a growth rate that doesn’t exceed 1 GB per day. Using journaling, transport rules, or auto-forwarding rules to copy messages to an archive mailbox is not permitted. Microsoft reserves the right to deny unlimited archiving in instances where a user’s archive mailbox is used to store archive data for other users.”

In other words, they don’t want tenants to import more than 1 GB of day into an archive mailbox (most migration products will move more than this amount daily) and they don’t want tenants to set up archive mailboxes that act as repositories for legacy data (shared by multiple users). In a nutshell, Microsoft views auto-expanding archives as a personal user-centric feature. For these reasons, if you’re involved in a migration project to move data to Exchange Online, ask your migration vendor how they handle the provision and population of target mailboxes.

Exchange Online is a Business

Microsoft is sensitive to what they see as unexpected or unanticipated use of cloud resources. Office 365 is a business that now serves 200 million monthly active users. It’s a major driver for Microsoft’s cloud revenues. But it costs to install and manage the 200,000 Exchange Online servers and storage is a major part of the cost envelope.

Enterprise users are assigned generous 100 GB limits along with another 100 GB for recoverable items plus the archive. Although Microsoft uses cheap JBOD for most of its Exchange Online storage, when you think about the amount of storage needed to accommodate truly bottomless archives, you can understand why Microsoft might act if signs exist that storage is consumed in unusual ways. After all, they cut unlimited storage for OneDrive in 2015. At the time it was reported that some were using OneDrive to store massive movie collections consuming over 75 TB.

Failure to Communicate

A solid business case might exist to limit auto-expanding archives, but that’s not the point. The problem here is that Microsoft utterly failed to communicate that they no longer support bottomless archives and why the strategy needed to change.

One TB is a reasonable archive storage limit for most Office 365 tenants and shouldn’t cause enormous problems in practice, but architects and administrators must know details of technical limitations to incorporate into their plans. Sneaking in changes like this without notification will erode customer faith in the way Microsoft manages Office 365 and that’s not a good thing.

You sometimes need eyes in the back of your head to learn about everything that happens inside Office 365. That’s why we update the Office 365 for IT Pros eBook every month. Shouldn’t you be a subscriber?

ZAP and Quarantine

ZAP, or zero-hour auto-purge, is an Exchange Online Protection (EOP) feature that’s had some issues recently. To help, Microsoft is releasing improvements to support more granular control and better alignment with other hygiene controls. In a nutshell, apart from the current “malware ZAP” action to remove any and all attachments deemed unsafe, ZAP will now act upon messages identified as Spam or Phish and can quarantine the messages, if that option is enabled. And we are getting the option to disable phish or spam processing for ZAP, if needed.

Microsoft announced support for moving ZAP-ed messages to Quarantine as part of the Phish and spam Zero-hour Auto Purge move to Quarantine update in Microsoft 365 roadmap item 55432 (Figure 1):

Enabling ZAP for Spam and Phish

While the roadmap item doesn’t explicitly mention this, a quick glimpse at the documentation shows that we are also getting additional controls for toggling the spam and/or phish detection modes. Both new modes will be enabled by default and can be controlled via new parameters introduced for the Set-HostedContentFilterPolicy cmdlet: SpamZapEnabled and PhishZapEnabled.

The value for both these new parameters is currently inherited from the value of the ZapEnabled parameter, and this will remain the case until February 2020, when the ZapEnabled parameter will be deprecated. By default, both the SpamZapEnabled and the PhishZapEnabled parameters will be $true (enabled), if not explicitly changed. Coming soon, we will be able to toggle those two parameters to $false, thus disabling the processing of spam and phish messages by ZAP.

How ZAP Will Process Email

Going forward, ZAP will behave as follows. For any messages detected as malware, the current “remove attachment” action will remain in effect, while for messages identified as phish or spam, the corresponding action configured in the Content filter policy will be executed. If the action is set to Quarantine message, Delete message or Redirect message to email address, ZAP will move it to Quarantine. If the action is set to Move message to Junk email folder, the current behavior will apply, and messages will be moved to the Junk email folder. If the action is set to Add X-Header or Prepend subject line with text, or there is no action defined in the policy, then ZAP will not act upon the message. The same is true if the corresponding spam/phish processing has been toggled off by the controls listed above.

These improvements will also introduce another change in ZAP processing, based on the read status of the message. Malware messages will continue to be acted upon regardless of the read status. For messages identified as phish, the action will also be performed regardless of the read status. However, for messages marked as spam, the action will only be performed on messages marked as unread.

For more information about techniques to repel spam and malware, read the chapter about mail flow in the Office 365 for IT Pros eBook.

Bit by Bit, Office 365 Sensitivity Labels Reaching Applications

On September 24, I published an article about the support of Office 365 Sensitivity Labels in the Office ProPlus for Windows desktop apps. At the time, I noted that Microsoft still had work to do to add support for sensitivity labels to the Office online apps, including OWA. Microsoft had published Office 365 notification MC191074 to say that Office 365 tenants now with worldwide roll-out complete by the end of October. Well, OWA “manual” support for Office 365 Sensitivity Labels has turned up in my tenant to satisfy roadmap item 44921.

Manual Labeling

Manual support for Office 365 Sensitivity Labels means that OWA users must decide what messages to label and the labels to assign to messages. Automatic labeling is what happens today with Office 365 retention labels when conditions in a policy control what items labels are applied to by a background process. Similar facilities are likely for sensitivity labels in the future.

Apply Sensitivity Labels in the OWA New Message Window

Because OWA runs in online mode, it always uses the current set of sensitivity labels published for a user. This doesn’t mean that a new or updated label is available to OWA immediately a change is made. The Security and Compliance Center must publish the change to all Office 365 workloads and clients. It can therefore take some time before a change is available to OWA.

The Sensitivity button is available as an option in the OWA new message window. After a label is applied to a message, its name is shown in the banner above the message recipients. In Figure 1 we can see that the selected label invokes encryption because of the padlock icon beside the label name. A label that only applies marking or does nothing but act as a visual indicator uses a plain label icon.

OWA also displays these icons for labelled items in the read message window. Like Outlook, the protection applied to a message also applies to any of its attachments

Labeling Replies

Sensitivity labels can also be applied to replies to messages that aren’t previously labelled. In this case, the Sensitivity option to apply a label is in the […] menu of the reply message window (Figure 2).

When you assign a sensitivity label to a reply, it does not apply to the previous messages in the thread. However, Exchange automatically assigns the same label to future messages in the thread.

Encrypt-Only and Do Not Forward

The default Office 365 Message Encryption Encrypt-Only and Do Not Forward templates can also be used to protect messages with OWA. Click the […] menu and you’ll find Encrypt in the list of menu choices. Using these templates for protection does not assign a sensitivity label to the protected messages.

Still Work to Do

Now that OWA supports Office 365 Sensitivity Labels, it’s reasonable to expect that the other Office online apps will offer support soon. After that, eyes will turn to the SharePoint Online and OneDrive for Business browser interfaces to see how Microsoft will introduce sensitivity label support there.

For more information about Office 365 Sensitivity Labels and the underlying Azure Information Protection technology, read Chapter 24 of the Office 365 for IT Pros eBook.

Senders Left Without Notice When Send As Messages Fail

Updated: May 20, 2021

The Microsoft 365 Groups Send As and Send on Behalf feature allows group members to send email for group mailboxes in the same manner as used for personal mailboxes. The Send As permission allows someone to impersonate the group so that messages sent with this permission seem to come from the group. The Send on Behalf of permission allows someone to send as the group, but the message is stamped to show that the sender is not the group but rather its representative. It’s the equivalent of a p.p. (per procurationem) signature on a paper document. Interestingly, you don’t need to be a group member to be assigned Send As or Send on Behalf of permission for the group.

The Problem Report

The first indication of a problem came in a discussion in the Microsoft Technical Community where the question was posed why people who send as a Microsoft 365 group didn’t receive Non-delivery Reports (NDRs). As it happens, after a lot of engineering effort, the NDRs generated by Office 365 are more clearer in terms of telling the sender why their message failed to be delivered and what they must do to fix the problem. Clearly, no action can be taken if a NDR is never received and the original message has literally gone into a black hole.

Investigations proved that:

• Messages sent from a Microsoft 365 Group using the Send on Behalf of permission to a bad address resulted in a NDR being delivered to the sender.
• Messages sent to a bad address from a personal mailbox also resulted in an NDR (as expected, but good to check anyway).
• Messages sent from a Microsoft 365 Group using the Send As permission to a bad address resulted in no NDR being delivered to either the group or the sender.
• A message trace showed that an NDR was processed, but that the Microsoft Agent agent handling the NDR delivered the NDR to the Deletions sub-folder in the Recoverable Items folder of the group mailbox “because of an inbox role the recipient set up” (Figure 1).

Apart from a reference to a “group escalation agent,” the PowerShell version of the message trace didn’t turn up any more detail.

# Get message trace information for a message
 Get-MessageTraceDetail  -MessageTraceId 0941762f-0e0b-4165-d4e7-08d740d4322f -RecipientAddress exchangemvps@xxx.com | Format-List

Message Trace ID : 0941762f-0e0b-4165-d4e7-08d740d4322f
Message ID       : <bf8c2cba-748a-437d-b953-4c7e84b42d7a@am6pr04mb5255.eurprd04.prod.outlook.com>
Date             : 24 Sep 2019 09:47:22
Event            : Deliver
Action           :
Detail           : The message was successfully delivered to the folder:
                   DefaultFolderType:RecoverableItemsDeletions
Data             : <root>
<name="SourceContext" string="08D73FD41D42EEF6;2019-09-24T09:47:21.847Z;ClientSubmitTime:">
<name="MailboxServer" string="VI1PR04MB3214">
<name="DeliveryPriority" string="Normal">
<name="TotalLatency" integer="1"><mep name="ReturnPath" string="">
<name="ClientName" string="AM6PR04MB5255.eurprd04.prod.outlook.com">
<name="CustomData" blob="S:OriginalFromAddress=ExchangeMVPs@xxx.com">
<name="SequenceNumber" long="0">
<name="RecipientStatus" string="DefaultFolderType:RecoverableItemsDeletions-Group Escalation Agent">
<name="RecipientReference" string="">
</bf8c2cba-748a-437d-b953-4c7e84b42d7a@am6pr04mb5255.eurprd04.prod.outlook.com>

Rules in an Microsoft 365 Group?

There’s no easy way to create an inbox rule in a Microsoft 365 group mailbox so the explanation offered in the message trace is unlikely to be true. What’s more likely is that some condition causes the Exchange transport service to automatically route NDRs to Recoverable Items. It’s possible that an engineer thought that it would be best to suppress NDRs for messages sent as a Microsoft 365 Group, but it’s hard to understand the logic. In any case, the messages do end up in Deletions (perhaps thanks to that “group escalation agent”). That fact can be confirmed by running the Get-MailboxFolderStatistics cmdlet against the group mailbox:

# Check number of messages in the Deletions folder 
Get-MailboxFolderStatistics exchangegoms -FolderScope RecoverableItems | ?{$_.Name -eq "Deletions"}| Select Name, ItemsInFolder

Name      ItemsInFolder
----      -------------
Deletions             4

Questions, Always Questions

The big question is why Microsoft decided to route NDRs for messages sent as a Microsoft 365 Group to the Deletions folder in Recoverable Items. You might also ask why leaving the sender in perfect ignorance of their failed message was deemed to be a good idea? And then ask why the message trace report says that an inbox rule processed the NDR when it’s palpably the case that this didn’t happen. So many questions. Maybe we can get an answer at Ignite.

Need more information about Microsoft 365 Groups? We explain many of the mysteries in the Office 365 for IT Pros eBook. Uncloud your mind with the best and most comprehensive guide to Office 365 available anywhere.

Sometimes Called Exchange Fast Access

In September 2012, I attended the Microsoft Exchange Conference (MEC) in Orlando. Later, I wrote an article about Outlook’s hybrid mode, which Microsoft shipped in Outlook 2013. The idea was to improve performance for Outlook when the client works in cached mode by allowing Outlook the option to make network requests to fetch data instead of depending on data synchronized to the OST. The feature works well on fast networks because Outlook can connect and display data like new messages waiting in the Inbox faster than if the client had to wait for background synchronization to finish.

All subsequent versions of Outlook (desktop) support and use hybrid connections when the client is configured in cached mode. The feature was called “Exchange Fast Access,” but according to Microsoft documentation, it was deprecated in Outlook 2016. Perhaps it was only the name that was deprecated. Exchange Fast Access doesn’t really tell you what the feature does. In fact, it’s all about forcing Outlook to depend on the cached data in the OST., which is how Outlook worked when cached mode appeared in Outlook 2003.

Why Disable Outlook Hybrid Mode

I was reminded about my 2012 article during a discussion in the Microsoft Technical Community where a contributor named Bill Rupp said that his organization disables hybrid mode to force Outlook to use the OST when connected over high latency networks. They also disable hybrid mode for clients used by frequent travelers, who often connect using flaky Wi-Fi networks. The reason? Well, they feel that Outlook hangs too often when the client runs in hybrid mode and is allowed to switch between network and local data. I can see why this might be the case as an attempt to fetch network data across an unreliable link is always prone to cause problems.

Controlling Local Caching

Microsoft introduced the LocalCaching registry setting in Outlook 2013, saying: “Enable setting to turn off Exchange Fast Access. This forces user accounts to access data from the local cache.” In other words, if you set the LocalCaching to 1, you disable the (deprecated) Exchange Fast Access feature and force Outlook to use data cached in the OST. By default, this value probably doesn’t exist on your PC, so you must create it before setting the value to 1. Here’s what I configured for Outlook version 1907 (click to run build 11901.20176). Usually, the best idea is to run the RegEdit utility to make registry changes, which is what I do.

HKCU\software\policies\Microsoft\Office\16.0\Outlook\Hybrid
Value: LocalCaching 
DWORD: 1 (disable) 0 (enable)

After making the change and restarting Outlook, I noticed that Outlook’s startup behavior is slightly different even on fast networks where a distinct pause happens before new messages appear in the Inbox. I also noticed that Outlook reports some issues with search which means that search results are not as reliable as when hybrid mode is used. Apart from that, everything works as normal. Bill Rupp reports that the setting works for Outlook 2016 and 2019 (perpetual versions).

It might be that forcing Outlook to use locally cached data could be a solution for some of your users who operate in poor network conditions. Old solutions sometimes work well in modern conditions… even when Wi-Fi networks available now are so much better than they were in the past.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Tell External People that the Company’s on Holiday

The question arose about the best way to set auto-reply for a shared mailbox to inform external senders that the company is on holiday (public or otherwise). Some suggested using Flow for the job. I, of course, thought of PowerShell. I’m not against Flow: I simply think that PowerShell offers more control and flexibility, especially when multiple shared mailboxes are involved. For instance, you might want to set appropriate auto-reply messages up for all the shared mailboxes in an organization, especially if those mailboxes are used for customer interaction.

Auto-replies, or OOF (Out of Facility) notifications as they are known in the trade, go back to the dawn of email (before Exchange 4.0). Even Teams supports out of office notifications. For Exchange (on-premises and online), it’s easy to manage auto-replies with PowerShell using the Set-MailboxAutoReplyConfiguration cmdlet. The Get-MailboxAutoReplyConfiguration cmdlet reports the current auto-reply state of a mailbox. You can have separate auto-reply messages for internal (any mail-enabled object within the organization) and external senders (anyone else).

A New Auto-Reply for Shared Mailboxes

The example solution uses a quick and dirty script to find all shared mailboxes in the tenant and set two auto-replies on each mailbox. One (brief) for internal correspondents; the other (less terse and nicer) for external people. Two variables are declared to set the start and end time for the scheduled auto-reply. If you specify a time, remember that Exchange Online runs on UTC so any time you set is in UTC. In other words, you should convert your local time to UTC when you set up the auto-reply. Rather bizarrely, Get-MailboxAutoReplyConfiguration converts the UTC time to local (workstation) time when it reports an auto-reply configuration.

#These times are in UTC
 $HolidayStart = "04-Aug-2019 17:00"
 $HolidayEnd = "6-Aug-2019 09:00"
 $InternalMessage = "Expect delays in answering messages to this mailbox due to the holiday between <b>" + $HolidayStart + "</b> and <b>" + $HolidayEnd + "</b>"
 $ExternalMessage = "Thank you for your email. Your communication is important to us, but please be aware that some delay will occur in answering messages to this mailbox due to the public holiday between <b>" + $HolidayStart + "</b> and <b>" + $HolidayEnd + "</b>"
 [array]$Mbx = (Get-ExoMailbox -RecipientTypeDetails SharedMailbox | Select DisplayName, Alias, DistinguishedName)
    ForEach ($M in $Mbx) {
    # Set auto reply
    Write-Host "Setting auto-reply for shared mailbox:" $M.DisplayName
    Set-MailboxAutoReplyConfiguration -Identity $M.DistinguishedName -StartTime $HolidayStart -AutoReplyState "Scheduled" -EndTime $HolidayEnd -InternalMessage $InternalMessage –ExternalMessage  $ExternalMessage -ExternalAudience 'All' -CreateOOFEvent:$True }

The code above uses the Get-ExoMailbox cmdlet from the Exchange Online management module, which is what you should use in Exchange Online. However, the Get-Mailbox cmdlet will work, and it’s what you use for Exchange on-premises.

Figure 1 shows the result when an external person sends an email to a shared mailbox. You can be as creative as you like with the text when you set the auto-reply on the mailbox. Because Exchange stores the auto-reply message in HTML format, most basic HTML formatting commands work when you set auto-reply for a shared mailbox. I only use bolded text in this example, but you could also include something like a mailto: link to tell people who they should contact if someone is out of the office and unavailable.

Removing Auto-Replies

The scheduled auto-reply lapses when the end time arrives. If you want to remove the auto-replies from all shared mailboxes, run the command:

# We assume that all shared mailboxes are in $Mbx
 ForEach ($M in $Mbx) {
   Set-MailboxAutoReplyConfiguration -Identity $M.DistinguishedName  -AutoReplyState "Disabled" }

For more information about working with shared mailboxes, see the Exchange Online chapter in the Office 365 for IT Pros eBook. There’s over a thousand PowerShell examples in the book, including lots of examples of using PowerShell to work with the Microsoft Graph.

Problem EX186451 Fixed to Relieve Users Who Can’t Find Email

Yesterday the Exchange Online Focused Inbox had a slight meltdown and delivered all messages to the “Other” part of the Inbox folder. By “Other,” I mean the “Other” view because Outlook clients use two views to present email delivered to the single Inbox folder. Some users were confused, especially those using Outlook mobile, as they didn’t receive notifications for new and potentially important messages arriving into their Inbox.

Microsoft’s problem report says that the issue potentially affected everyone using the Focused Inbox feature. However, it’s not clear how widespread the issue was, but I did hear about it from multiple tenants. The distributed nature of Office 365 and the way that Exchange Online is installed in multiple forests makes it hard for a configuration problem to affect the entire service.

The decision to surface a message in the Focused or Other view is made by a mailbox assistant that processes inbound messages and evaluates them according to criteria built up by the user over time. The default is to put messages into the Other view, but you provide signals over time to instruct the assistant on the messages you think are important (or vice versa). The strongest signal you can give is when you move messages from the Focused to the Other view or back as this tells the assistant to do likewise with other messages. The assistant also looks for clues, like circulars and the like before deciding how to categorize a message. Admins can configure a transport rule to make sure that important email, like messages sent by the CEO for the edification of the whole company, are always placed into the Focused view.

The Outage

I wasn’t impressed at Microsoft’s problem report (Figure 1). Although it is a workaround, instructing users to disable Focused Inbox is liable to cause further confusion once the problem was resolved.

I guess the other question raised by the problem is (once again) how does Microsoft test changes before deployment into the production environment. The answer, in this case, is “poorly.” Software can fail, but configuration changes should be validated before they go anywhere near production.

Focused Inbox is covered in the Companion Volume of Office 365 for IT Pros. It’s a good example of a topic that is not of tremendous interest to most Office 365 admins until something bad happens…

Office 365 Admins and Users can Report Spam and Phishing

From time to time, reports come out to criticize the performance of Exchange Online Protection (EOP), mainly its inability to detect spam and phishing messages. Invariably, the report is authored by a vendor anxious to sell their mail hygiene service with promises that a much higher proportion of bad email will be caught if Office 365 tenants would sign up. It’s true that routing email through multiple cleansing services can have a benefit; what’s not so clear is if third parties do any better than Microsoft’s own Advanced Threat Protection (ATP), which serves the same purpose.

In any case, all the services that aim to block spam and malware depend on intelligence to understand the latest tactics taken by attackers to trick defenses and allow their email to get to user mailboxes. If you want to see EOP do a better job of blocking malware, you can help Microsoft by reporting messages that get through.

Two methods are available:

• The Report Message add-in for Outlook allows users to report messages as junk, phishing, or a false positive (not junk). Figure 1 shows how to use the Report Message add-in with the new OWA. The add-in works for Outlook desktop (Windows and Mac) as well and should be a basic part of the Outlook configuration for Office 365 clients.
• The Submissions section under Threat Management in the Security and Compliance Center allows admins to report messages. This is a relatively new feature described in this Microsoft post.

In both cases, reported messages are sent to Microsoft for analysis so that they can tweak EOP to do a better job.

Administrator Submissions for EOP Processing

Before administrators can submit a report to Microsoft through the Security and Compliance Center, they need some details about a bad message that only a user can give. Every message has a network message identifier that should be unique. An easy way to find the message identifier is to run the Outlook’s Message Header Analyzer add-in (also available as a GitHub project) and look for the X-MS-Exchange-Organization-Network-Message-Id property (Figure 2).

Another method is to use OWA’s Show Message Details option (Figure 3). The equivalent in Outlook desktop is to look at the message properties through the File menu.

In either case, I prefer to use the Message Header Analyzer because it’s easier to locate the message identifier. Once you have the message identifier, you can submit a new report. Go to the Threat Management section of the Security and Compliance Center, select Submissions, and then New submission. Fill in the information about the problem message (Figure 4) using the network identifier to find the message. You need to select one of the message recipients too. If you have a copy of the message (EML format), you can upload it too. Indicate if you think the message should have been blocked or passed, select what kind of problem you see in the message (spam, phishing, or malware), and submit the message for processing.

The Submissions dashboard (Figure 5) shows you a breakdown of user (via the Report message add-in) and admin submissions.

For admin submissions, the reported messages show when EOP has finished analyzing their content. Select a completed message to see what the verdict is. In the case of the message verdict shown in Figure 6, the user had complained that obvious spam had reached their Inbox. The clue to why this was so was in the policy type “Sender domain in safe list.” The user’s junk email settings accepted all email from outlook.com senders, so even though EOP had marked it as spam, the user’s preference had overridden the analysis. The learning from this is to educate users not to mark consumer email domains like outlook.com and gmail.com as safe because spammers often create throwaway accounts in these domains to use to send mail. It’s perfectly acceptable to mark individual known accounts from these domains as safe senders.

Of course, automated detection systems can only go so far. Some spam and malware will get through and it’s then up to user intelligence to recognize and suppress bad email. And hopefully, when they do see spam arriving in their inbox, they’ll know how to report the messages themselves or how to give admins the necessary information to make the report on their behalf.

There’s lots more to learn about Exchange Online Protection and Advanced Threat Management in the Office 365 for IT Pros eBook. Be informed and be secure!

The new OWA has been generally available since February 2019. Office 365 Notification MC184484 brings the news that Microsoft will start the process of making the new OWA (Outlook on the Web as Microsoft Marketing insists on calling the browser client; most normal people call it Outlook Web Access) the default from July 22. Apparently, removing the toggle switch to allow people to move back and forth between the old and new interfaces counts as an added feature, so it’s on the Office 365 Roadmap (Figure 1).

New OWA Still in Development

Since first introducing the new OWA, Microsoft has gradually rolled out new functionality like dark mode, a new Office 365 Groups management interface, and supporting categories as favorites. On July 3, Microsoft posted a list of what they consider to be highlights in the new OWA together with some things that are coming. One new feature that struck me is “expressions” or the ability to past graphics into email to clutter up mailboxes even more. I guess we need some more help to fill Exchange Online’s massive 100 GB mailboxes.

Before being too critical about features like expressions, you must always remember that OWA serves both business (Office 365) and consumer (Outlook.com) users and features that seem odd in a business context often make absolute sense for consumers. “Joyful animations” is an example of a consumer-centric feature that probably wouldn’t influence a CIO (but it might make them happy on their birthday).

Development continues to add new features and because there are still parts of the old OWA that don’t appear in the new, such as being able to see address lists and the ability for users to manage their own distribution lists [update: this feature was due to be available to targeted release tenants on July 3 but some provisioning issues stopped the code being delivered to all. The problem is now fixed.]

Another gap, but one likely to affect fewer users, is that the new OWA doesn’t load the add-in needed to process messages captured for review by Office 365 supervision policies. In this case, the easy (and better) answer is to process these items in the Security and Compliance Center.

Timing

In terms of when all this happens, Microsoft says: “We will start rolling out the new Outlook on the web as the default experience on July 22nd to Targeted Release customers, and following with non Targeted Release customers on August 3rd, the roll out will be completed for all customers by the end of September 2019.”

The one caveat is for Tasks, where people who use the older form of Tasks (aka “the classic Tasks experience“) will continue to see that for now. Those who moved to the new To-Do based Tasks interface will continue to use it (Figure 2). Apart from the UI, the giveaway is the URL https://to-do.office.com/?fromOwa=true. Apparently, a “later communication” will bring news about the toggle that moves users back and forth between the other OWA components and To-Do. Stay tuned for developments on this front.

Too many Office 365 changes giving you a headache? Take the strain away by subscribing to the Office 365 for IT Pros eBook and let us do the heavy lifting.

Outlook Mobile Shared Mailboxes in IOS and Android – Sharing is Caring!

August 29 note: The current versions of Outlook mobile include support for shared mailboxes. See this post for details or read on to learn how to add shared mailboxes to Outlook mobile.

Last week, we learned that Microsoft will soon roll out support for shared mailboxes in Outlook Mobile. Well, some people already have access to the feature through Apple’s Testflight for iOS program. Testflight allows developers to offer test versions of applications like Outlook mobile to people who don’t mind running beta software. The upside is that you see new features sooner. The downside is that the new features might not work or might change before the final version is released. With those caveats in mind, let’s explore how to add a shared mailbox to Outlook mobile using Testflight version 3.27.0.

Add Shared Mailboxes to Outlook Mobile

Before you can add a shared mailbox to Outlook mobile, you should meet these criteria:

• The shared mailbox must already exist on Exchange Online. Outlook mobile can only access existing shared mailboxes; it can’t create a new shared mailbox.
• Your primary mailbox must be in Exchange Online. Users in a hybrid organization whose mailbox is on-premises can’t add shared mailboxes to Outlook mobile.
• Your account has access to the shared mailbox. This means that an administrator assigns your account full access to the shared mailbox. In addition, if you want to send from Outlook Mobile as the shared mailbox, your account must hold SendAs permission for the mailbox.
• You must know the primary SMTP address of the shared mailbox. Why? Because you need to input the mailbox’s SMTP address when you add the shared mailbox.

With everything in place, go to the list of resources available to Outlook mobile and click the + icon and then choose Add Shared Mailbox (Figure 1).

Now input the primary SMTP address of the shared mailbox and click the Add Shared Mailbox button.

That’s all you need to do. Outlook Mobile adds the shared mailbox to its resource list and you can access the contents like any other mailbox.

One big benefit of native support in Outlook mobile for shared mailboxes is that it removes the need for people to use outdated protocols like IMAP4 to access shared mailboxes. From a Microsoft perspective, it gives customers another good reason to move to Outlook mobile and away from apps like the native iOS mail app that use the Exchange ActiveSync protocol to interact with mailboxes (ActiveSync doesn’t support shared mailboxes, which is why people end up using IMAP4).

Outlook Insiders and Testflight

If you want to test shared mailboxes with Outlook Mobile now, you can sign up for the Outlook Insiders program (limited slots are available). You’ll also need to download and install Testflight from the iOS app store. You can then download the test version of Outlook.

One side effect of using the test version is that Office 365 automatically provisions your tenant to use the Microsoft Sync Technology (if it didn’t, you wouldn’t be able to test new features). This process takes about 24 hours. When it’s done, you’ll be able to add shared mailboxes to your heart’s content, but only with iOS clients for now. According to a tweet from Outlook Mobile development last Friday, support for Android is coming “soon.”

Need more information about Office 365 clients, including Outlook Mobile? Read the Clients chapter in the Office 365 for IT Pros eBook!

Removes Need for IMAP4 Workaround

Office 365 notification MC181641 posted on June 5 includes the good news that Outlook mobile (iOS and Android) will soon support connections to Exchange Online shared mailboxes. This will remove the need for the IMAP4 connection currently used as a workaround to access shared mailboxes. Apart from the general kludginess of the IMAP4 workaround, if you log onto a shared mailbox with IMAP4., that mailbox should technically have an Office 365 license.

The development also addresses a huge feature gap that Microsoft has acknowledged to exist for years. This update relates to Office 365 Roadmap items 32571 (iOS) and 32572 (Android) and not the two listed in the announcement.

The announcement says: “You will be able read, write and send emails from the Exchange Online Shared Mailboxes in Outlook for iOS and Android. If you are part of the Office Insider program for iOS and using the Microsoft sync technology (MC165218), you will be able get an early preview of the capabilities via TestFlight this week. It is anticipated that we will start to roll out Shared Mailboxes in Outlook for iOS and Android (using Microsoft sync technology) for general availability in the next several weeks.”

In other words, expect to see shared mailbox support appear in July 2019. That is, if support for the Microsoft Sync Technology is deployed to your Office 365 tenant. To check, look at the settings for your account (Figure 1), or use the PowerShell script in this article.

Microsoft Sync Technology is the new connection protocol for Outlook mobile clients that Microsoft has deployed to Outlook.com and the Government Cloud (GCC) and is now rolling out to commercial tenants. Hopefully, the advent of shared mailbox support serves as a spur for Microsoft to complete the deployment of the new sync technology.

Updated Files, Calendar Events in Search, and Calendar Sync

Microsoft includes some other updates in MC181641. These are:

• Updated Files: The way Outlook mobile presents files will become more coherent with the rest of Office 365 and include a list of recently used files plus cloud sources (like OneDrive for Business or Google Drive). You’ll be able to add a link to share a file that complies with default tenant sharing permissions.
• Calendar Events in Search: When you search for someone or use a keyword, the results returned will include any matching events found in your calendar. This feature also depends on Microsoft Sync Technology.
• Calendar Sync: Outlook for Android now supports syncing calendar events from the native calendar app. This is a one-way sync and Microsoft says that the ability to sync from Outlook to local calendar apps is still in development.

Lots Happening in Mobile

Mobile apps tend to evolve quickly. Outlook mobile is no different. These changes, particularly shared mailbox support, will make many people very happy.

Need more information about Outlook clients? Or Office 365 clients in general? We have a complete chapter on the topic in the Office 365 for IT Pros eBook.

How Outlook 2003 Changed the World of Email Clients

Outlook 2003 introduced “drizzle-mode” synchronization. When Outlook is configured in cached Exchange mode, drizzle-mode synchronization uses a set of background threads to monitor changes in all non-system folders and download changes as they occur. The user doesn’t have to do anything to update the cached (offline) copy of their mailbox. Since the introduction of drizzle mode, Outlook users are accustomed to being able to keep a complete copy of their mailbox for offline access (or a subset of the mailbox as adjusted by the Outlook “slider”).

When Microsoft introduced Outlook 2003, they also included a bunch of network enhancements to make drizzle mode synchronization work smoothly, including high-priority threads to download new messages to the Inbox and upload outgoing messages as they were sent. At a time when abundant network resources exist, it’s hard to look back to a point when synchronization involved many slow dial-up connections and VPNs to emphasize just how good it was to have an efficient way to have a complete offline copy of a mailbox. Outlook 2003 revolutionized the way people worked and laid the foundation for Outlook to be the predominant client for Exchange. Cached Exchange mode rapidly became the de facto standard working model for Outlook and all was well in the world of email.

The Slight Problem of Shared Folders

Except, that is, for shared folders. Drizzle mode synchronization works extremely well for folders in primary mailboxes, but not in secondary mailboxes, such as shared mailboxes or when delegates had access to other peoples’ mailboxes. The classic use case is where an administrative assistant has access to other mailboxes to be able to process inbound messages. In some deployments, I have known assistants working with the mailboxes of over twenty people – and sometimes they weren’t very happy.

Things usually worked OK if Outlook had to cope with just a few shared folders, but problems lurking in the background soon became apparent as the number of folders increased. Items seemed to be missing and performance degraded rapidly. It wasn’t a good situation.

The Outlook and Exchange development teams have been aware of the issue for years, but their understanding of how to track changes in shared folders while respecting permissions to those folders (an issue that doesn’t occur for folders in the primary mailbox) led to a point where Outlook could support a maximum of 500 shared folders (a MAPI restriction: Outlook is still very much a MAPI client).

A New Approach

The good news is that Microsoft has come up with a new approach that will raise the limit from 500. As explained in a June 4 blog, instead of keeping individual shared folders open in memory (which is where the MAPI restriction comes from), Outlook will monitor a MAPI property for the folder that changes when something inside the folder changes (like a new message or the deletion of a message). Once Outlook sees that the property has changed, it can launch synchronization to make sure that the offline copy of the shared folder matches what’s on the server.

The reason why this approach is better is that Outlook doesn’t have to keep folders open to know when changes occur. Memory usage is lower and synchronization should be smoother. Microsoft says that they expect most customers to see the limit increase from 500 to 5,000 folders. They didn’t give any details about what they mean by “most customers” or how users can track how many shared folders Outlook can access.

Changes Available Now

Microsoft has already released these changes in Office ProPlus (click to run) for Office 365, saying: “These changes were released to our Monthly Channel (Targeted) customers  with the April 1904 release, to our Monthly Channel customers with 1905 (11629.20196) and later, and will be coming to our Semi-Annual channel customers on the regular SA schedule (September for Targeted and January for general release.) “

To check your version, go to File and then Office Account. As you can see in Figure 1, I currently run build 11620.20214, a later build than 11629.20196, so I have the updated code.

No New for Other Outlook Versions

Microsoft hasn’t said if they will update other versions of Outlook, including Outlook 2019, to take advantage of the new approach to synchronizing shared folders. For the moment, this change is restricted to Office ProPlus.

Need more information about Office 365 clients? Look no further than the Clients chapter in the Office 365 for IT Pros eBook.

Communicate by Email with Teams Channels

Teams supports the ability of users to send email to a channel by publishing special Teams channel email addresses. (The option to generate email addresses is controlled by the Email integration org-wide setting). The addresses used by Teams channels point to hidden mailboxes in a part of Microsoft 365 managed by Microsoft and invisible to the rest of the world, which accounts for the odd email addresses in the teams.ms domain. To retrieve an email address for a channel, use the Get email address option in the […] menu (Figure 1).

You can then paste the email address into a message to send it to the channel. Teams uses a connector to pick up the new message and bring it into the channel, and all is well. A fuller explanation of how Microsoft 365 and Teams process inbound messages and deliver them to the target channel is available here.

However, because the email addresses are a little weird, it’s unlikely that people will remember them. If you think that people will want to email a specific channel regularly, you might like to create an Exchange mail contact to make it easier for them.

Creating a Mail Contact for a Teams Channel

Mail contacts show up in the Exchange Global Address List (GAL), so once an contact exists, it’s easy for users to add them as a message recipient.

• Go to the Exchange Admin Center (EAC) and select Contacts under Recipients.
• Click Add [+] Mail Contact.
• Fill in the details for the new contact. Copy the email address for the channel into the external email address field. It’s a good idea to give the contact a display name that clearly indicates its purpose. In Figure 2, I’ve added a “(Teams)” suffix.

After saving the contact, the object is available in the GAL and can be used to address messages. Outlook clients will take a day or so to pick up the new mail contact in their copy of the Offline Address Book (OAB). However, before the contact appears in the OAB, Outlook users can always consult the GAL to find the new address (Figure 3).

Users Can Delete Teams Channel Email Addresses

The only problem is that users can remove the address for a Teams channel, which invalidates the mail contact. Teams is happy to generate a new email address for the channel if requested (it won’t reuse an address), so you’ll have to update the mail contact with the new address if this happens.

Using Teams Channel Email Addresses Elsewhere

Much the same technique works if you want to add a Teams channel email address as a member of a distribution list. It is, after all, a valid email address, and in most respects, can be used in the same way as any other email address.

For more information about Mail Contacts, read the Exchange Online chapter of the Office 365 for IT Pros eBook. Teams is covered in two chapters – one for the basics and architecture, and the other covers managing a Teams deployment. Together, the two chapters span over 150 pages of invaluable material…

Nasty Language Now Detected in Email and Teams

In March, I wrote about the update to Office 365 supervision policies to support monitoring of Teams communications in personal and channel conversations. Supervision policies are an Office 365 E5 feature and not every organization feels the need to check email and Teams to ensure compliance with company or industry regulations, but it’s an important part of data governance in some industries.

Recently, in another example of how Microsoft uses the cloud to bring machine learning and artificial intelligence into their products, supervision policies acquired the ability to use data models to check messages. The first data model is “Offensive Language,” which covers a wide range of conditions, including slurs, taunts, racism, homophobia, profanities, and taboo terms designed to help organizations implement anti-harassment and cyber-bulling in the workplace.

Adding the Offensive Language Data Model to a Supervision Policy

Adding the Offensive Language data model to a supervision policy is easy. When creating or editing a policy, you chose what communications to review, including the conditions to select messages. All you need to do is set the Use match data model condition checkbox (Figure 1).

Testing the Policy

After saving the policy, the next thing is to test its effectiveness. This is more easily done with email because Office 365 captures copies of messages for supervision immediately while it takes Teams up to 24 hours to do the same.

Messages selected for supervision are kept in special mailboxes and processed there by reviewers using OWA or the Supervision section of the Security and Compliance Center (Figure 2). Reviewers must decide if the messages picked up by a policy are compliant or non-compliant. Anyone who sends a message containing offensive language to other people needs some counseling. Ideally, the organization should have well-documented and clear procedures to report issues detected through supervision policies to line managers and HR for further action.

Blatant examples of grossly offensive language are picked up without a doubt (for instance, calling someone a f***ing idiot in email) as are messages containing specific keywords (like “homos”). Other messages get through that some might find offensive (you’ll have to do your own testing to find out), but might be caught in time as the learning model is refined to understand the kind of language used in the organization. At least, the great promise of artificial intelligence and machine learning is that administrators don’t have to keep on updating policies to take account of changing circumstances (new forms of insults, for instance). We shall see over time.

English Only

The current data model only handles English language terms. It will take time for Microsoft to build the models to handle offensive language in the many languages supported by Office 365, including regional variations used in the 240+ markets where Office 365 is sold. In the meantime, any local patois won’t be detected by policy, even if it is utterly offensive.

Along with a ton of other information about auditing, supervision policies are covered in Chapter 21 of the Office 365 for IT Pros eBook.

Outlook Can Schedule Meetings to End Early, But Will Users Respond?

Poor, badly-organized meetings suck the lifeblood out of an organization. You know the type I mean: attended by too many people, most of whom spend the entire meeting processing email or answering Teams conversations, no or unspecific agenda items, no drive to achieve consensus and decision, and so on. It doesn’t matter if these meetings are in-person or electronic, they’re still a horrible waste of time.

Which brings me to an option introduced in Outlook for Windows click-to-run build 1902 onward (I’m currently using build 1903 from the monthly channel (targeted) – you might have a different version). In Calendar settings, you can opt for meetings and appointments to end a few minutes earlier than the traditional 30- or 60-minute finish. The idea is that you can finish up one meeting and be in good time for your next appointment.

Office 365 for IT Pros author Brian Reid gets very excited about the feature in his blog and explains how to apply registry settings to enable the feature for everyone, or perhaps only the people you want to confuse.

You can also deploy the new calendar settings to clients via the Office administrative template files (ADMX/ADML) for Office 365 ProPlus.

Ståle’s LifeHacks

Apart from saying “awesome” a lot, Office 365 for IT Pros author Ståle Hansen, is very enthusiastic about LifeHacks, which is apparently a way to use OneNote to do most wondrous things to organize your life better. Perhaps ending meetings and appointments five or ten minutes earlier qualifies as a lifehack, but I rather think not.

The sad fact is that software might schedule meetings to occur at certain times and to last a set period, but humans often ignore the best intentions expressed in a meeting notice. People turn up late, barge in without excuse, disrupt the flow of the conversation with inane or inarticulate comments, and generally conspire (inadvertently) to run bad meetings. Outlook’s new option will give you the satisfaction of organizing your calendar better, but it will do nothing to make meetings go smoother.

If you’d like to see the Northern Lights, you can meet Ståle and myself (and lots of other good speakers) at the Experts Live event in Oslo, Norway on May 29. I’m going to hear Ståle say awesome some more while he’s going to tolerate me talking about Office 365 governance. It’ll be awesome. And if you can’t make the conference, read the Office 365 for IT Pros eBook from beginning to end. It’s only 550,000 words… especially Chapter 10, which covers Office 365 clients.

The blog posted by the Exchange development group yesterday to announce new tools to migrate from G Suite should really have been titled “migrate email from G Suite” because the solution only handles mail, calendar, and contacts. Or maybe the experience is intended to migrate the bits of G Suite that people really use and ignore Docs, Drive, and the other pieces. In any case, the Exchange guys are obviously very excited that the functionality is now rolling out and should appear in Office 365 tenants over the coming weeks.

The MRS Key to Migration

The advent of better migration tools is a good thing. Microsoft has built the migration on top of a well-known and robust foundation in the Mailbox Replication Service (MRS), which has been moving mailboxes between servers since Exchange 2010. Since its initial ability to move mailboxes from one version of Exchange to another, MRS has expanded its abilities to handle more scenarios and has moved literally millions of mailboxes from on-premises organizations to Office 365 tenants. Now it can move messages, contacts, and calendar items from Gmail to Exchange Online, treating each Gmail user as a migration request and bundling those requests into migration batches that MRS processes in the background.

There’s no great magic involved in connecting to G Suite. MRS uses the IMAP4 protocol to access and read information from Gmail mailboxes. Only 2 GB can be read from a mailbox daily. As Microsoft notes, this limit is enforced by Google (at least the limit is per mailbox). In any case, MRS will process mailboxes larger than 2 GB until they are completely moved over to Exchange Online using incremental synchronization before performing the final switchover. The process will just take a little longer (well, potentially days longer).

Limits

Some limits exist. The default for the largest item is 35 MB, but this can be increased to 150 MB by adjusting the transport configuration of Exchange Online in the target tenant. Note that the size of any message can be larger than expected because of the packaging used to preserve fidelity when messages pass between different servers. The 150 MB limit might, for instance, mean that a Gmail message of 135 MB (including all attachments) can be moved, but depending on the attachments and the format of the message, the limit might be smaller. Like for any other migration, it is a good idea to ask users due to be migrated to find large messages in their Gmail account and remove any that they don’t need to be moved.

Other limits exist in terms of the data that can be migrated. Essentially, users should be prepared to recreate rules and automatic replies and to review contacts after their mailbox is moved. Migration is all about moving mailbox data and not the settings for the Gmail account or other Google-related settings.

Cultural Changes for Users

Another cultural change facing migrated users is the change from Gmail labels to folders. The impact of this might be slight for people who only ever use the Inbox and Sent Items folders, but others who have created their own system of labels to mark and process email will need some coaching to transition to folders, understand the Focused Inbox,(which some people hate), and how Exchange Online archives messages (with retention policies or the Archive option), and other features such as OWA’s clean up mailbox.

If people have used Outlook to connect to Gmail, their transition to Outlook connected to Exchange Online should be smooth. However, their client might need to be updated to make sure that they use a supported version (and if their Office 365 plan includes it, the click to run version). The same is true for people who have used Outlook Mobile to connect to Gmail as Outlook Mobile (considered by some to be the best mobile client for Gmail). On the other hand, those transitioning from the traditional Gmail browser client to OWA will need some retraining to become comfortable with their new mailbox.

More G Suite Data to Migrate

There’s more than email to migrate when an organization moves from G Suite to Office 365. Microsoft suggests that you can move files from Team Drive to SharePoint Online, but there’s also many commercial migration products that should be considered before launching into a full-scale migration.

Going to G Suite?

If you want to go the opposite way and move from Office 365 to G Suite, Google launched the beta of G Suite Migrate in March 2019. In the early days of Office 365, it was quite common to hear about companies moving from on-premises Exchange to Gmail, but that doesn’t seem so common now.

Google’s tool supports migration from Exchange (on-premises and online), SharePoint, OneDrive for Business, and file shares, but misses out big parts of Office 365 like Teams and Planner. All of which proves that migration is a complex business and that any migration project deserves substantial up-front planning before a single byte is moved.

Administrators who move from G Suite to Office 365 need help too. Our advice is to buy a copy of the Office 365 for IT Pros eBook. The book contains far too much information to digest immediately, but it will be a source of comfort as they navigate their new home in the cloud.

Sometimes an old Dog has New Tricks

In an Office 365 world where the publicity seems to be perpetually absorbed by Teams, it’s nice when an old program suddenly turns up and does something different. Outlook, first released 22 years old, is the old dog, and background moves is its new trick.

Background moves means that when you move items between folders, Outlook doesn’t display a blocking modal screen to display progress of the moves (“moved 100 of 1000 items…”). Progress is interesting, but while the move happens, Outlook won’t let you do anything else. This might have been OK in 1997; it’s not acceptable for modern software in 2019.

Folder Filing is an Old Habit

To be honest, I don’t use Outlook often to move hundreds of items between folders. I might have in the past when it was more common for people to organize their mailboxes into a set of carefully-planned folders. Or when I needed to move items out of my primary mailbox to a PST because of a restrictive mailbox quota (my first Exchange mailbox quota in 1995 was 25 MB). Today I don’t bother much with folders and most email stays in the Inbox and Sent Items folders until it’s moved to my archive mailbox.

Outlook’s Asynchronous Background Moves

My lack of attention to folders meant that I didn’t notice Outlook’s new trick until one of my MVP colleagues pointed it out. Using Outlook ProPlus (build 11601.20144 – version 1904 or later), if you select a batch of messages and move them to another folder, Outlook performs a background move and lets you get on with other work while it completes the move. All you see is a progress bar at the bottom of the main Outlook window. This works for clients configured in both cached and online mode.

If multiple moves are in progress, you’ll see something like this:

The most valuable thing about this feature is that it makes it feasible to move large numbers of items from the primary to the archive mailbox. In the past, this was a real pain, especially when Outlook is configured in cached mode. Now – well, it just works.

The change is only available in Outlook ProPlus (click-to-run) and isn’t available in Outlook 2016 or Outlook 2019. This might change in the future.

Surprising But Welcome

It’s surprising that a vintage program like Outlook should gain such a fundamental improvement at this point in its lifecycle. After all, Microsoft dedicated enormous effort to making Outlook a better network client in the Outlook 2003 release, which introduced the ability to synchronize the entire mailbox and a batch of networking smarts using multiple threads. That all seems so long ago now, back when connecting to Exchange invariably involved some odd whistling noises over a telephone connection.

In any case, it’s nice that Outlook now finally addresses an issue that some people have complained about for a long time (not enough people, obviously).

For more information about Exchange Online clients, including Outlook, read Chapter 10 of the Office 365 for IT Pros eBook.

Little Things (Like MailTips) in Exchange Cause Irritation

Sometimes Office 365 drives me up the wall. It’s usually when little things don’t work like they should rather than problems with big pieces of functionality. The different ways that Exchange Online and clients handle MailTips is a current irritant.

Usually I don’t think too much about MailTips. They’ve been part of the product since Exchange 2010 and usually don’t cause any fuss or bother. Recently, Microsoft introduced a new tip in Outlook Mobile to warn users when they add a recipient to a message who’s outside the tenant. It’s a good idea that isn’t dependent on the transition to the new connection protocol for Outlook mobile, unlike many of the new mobile features Microsoft hopes to deliver in the future.

But curiously, Outlook for iOS shows different warnings depending on how the MailTips settings in Exchange Online’s organization configuration are set. On the left, we see the warning shown when the setting to disable MailTips is set, on the right, the different warning that appears when the setting is enabled.

The external recipient warning is the only one of the MailTips supported by Exchange Online displayed by Outlook Mobile.

Organization MailTips Configuration

The controls to turn MailTips on or off are in the organization configuration and can be set by running the Set-OrganizationConfig cmdlet. In this case, the settings of interest are:

• MailTipsAllTipsEnabled: Enable or disable Mail Tips. The default is True.
• MailTipsExternalRecipientsTipsEnabled: Enable or disable the tip that a message is going to an external addressee. The default is True.

Although I can’t think of any good reason to disable the warning for external recipients, it doesn’t seem right for Outlook Mobile to ignore a perfectly good setting. After all, if a setting can be set to False, then the clients that are supposed to respond to the setting should do so. The reason might lie in the fact that Outlook Mobile supports a setting to control the display of the external recipient tip in its application configuration policy. That is, if you use Intune.

Another setting (MailTipsLargeAudienceThreshold) allows an organization to set a threshold for a large recipient list (25 is the default) to warn someone when they’re about to send a message to a large group. The original idea was to warn people when they addressed messages to large distribution lists. And another (MailTipsMailboxSourcedTipsEnabled) controls whether warnings appear when people are out of the office or their mailbox quota is exceeded.

Outlook’s MailTips Settings

Possibly for historic reasons (because these settings go back to Outlook 2010), Outlook has its own controls for MailTips. Go to Options, Mail, and find the MailTips section. You can choose to never see MailTips or the selection of MailTips you want Outlook to display.

Neither OWA nor Outlook Mobile offer the same degree of control over the display of MailTips.

Differences in OWA

OWA doesn’t offer the same control over MailTips as Outlook does. Apart from this, the only issue I have with OWA is that the “new” version of OWA doesn’t display a warning if a message exceeds the 25 “large audience” threshold. Given that we’re in the middle of a transition between client versions, this is probably an oversight that Microsoft will address before they switch everyone to the new version.

Commonality Across Outlook Family

I’ve no doubt that some will be unaffected or won’t care about the variation in treatment of MailTips that exists across the Outlook clients. The fact that Outlook has its own set of controls doesn’t bother me, but I am irritated that the clients don’t all handle MailTips in the same way. It seems that Microsoft could do a better job of smoothing the differences across the different clients.

Note that it can take some time before changed settings in a tenant’s Exchange Online organization configuration become effective. OWA usually picks up changes first followed by Outlook and Outlook Mobile.

We try not to show irritation in the Office 365 for IT Pros eBook. That’s why we have this blog – to share some of the feelings that we otherwise hide.

Helping Exchange Protect Users from Bad Email

Given the amount of spam floating around today, it comes as no surprise that many organizations deploy an Exchange transport rule to mark inbound external email with a suitable warning. This is a straightforward rule to configure and it can help stop users being fooled by bad messages that get past the array of checks used by Exchange Online Protection to detect and suppress spam. Even the best anti-spam defense is sometimes fooled by a phishing attempt (at times, you wonder how some “amateur night at the races” phish attempts manage to get through).

Visual Marking to Help Users

The usual approach is to add two visual markings to external messages with the aim that these markings highlight the risk that could be present in external email. The first marking is a disclaimer placed at the top of the message body; the second is a prefix added to message subjects. In the rule below, we see that some HTML text is used for compose the disclaimer while a simple “#External:” prefix is used for the message subject.

Refining the Rule

Exchange applies the rule to any message sent from an external domain to a recipient within the organization. You can get pretty creative with the conditions that cause a rule to fire with the aim of only applying marking to messages that deserve to be treated with some caution. For instance, you could add a condition so that the rule would only fire if the message had an Spam Confidence Level (SCL) higher than 1. This means that any message that came through Exchange Online Protection’s spam checking with an SCL that says it definitely isn’t spam would not be marked. Exchange Online delivers messages with an SCL of 5 or higher to users’ Junk Email folders.

You could also look for a value in a message header and use it to decide if to apply marking. For instance, you might decide to mark all messages that don’t pass DMARC checking (look in the Authentication-Results header for dmarc=none or dmarc=fail).

The Message Header Analyzer tool is very useful when reviewing message headers to decide which to use and what value to look for. This is an add-in that you can load into Outlook (and OWA) to run against messages in your mailbox.

Adding Exceptions

As in the case of rules to add disclaimer text or auto-signatures to outbound messages, I usually add some exceptions to the rule. The first exception is to stop Exchange applying the rule to messages where the #External: prefix already exists in the subject. The logic here is that if someone is involved in a messaging thread, they’ve made the decision that it’s safe to do so and don’t need to be reminded for each reply.

The second exclusion is to not apply the marking for well-known domains. The exact list of these domains will differ from organization to organization but is likely to include important partners and trusted companies, like petri.com and microsoft.com as shown in the example. You could also add onmicrosoft.com to exclude Office 365 tenants that use their service domains for email. However, some spammers have used Office 365 tenants in the past, so this exclusion comes with some risk.

Using exceptions and refining the rule so that not all inbound email is marked has two effects. First, it means that marked messages have a meaning that they won’t have if every inbound message is marked. Second, it stops users complaining when perfectly legitimate business communications are marked. You wouldn’t paste a great big warning label across every parcel that comes into the company by post, so there’s no need to warn about every message coming into your tenant.

Composing HTML Marking

Most email is in HTML format today, so it makes sense to compose the marking in HTML. You might be fluent in HTML, but I am not, so I used the online HTML editor to compose the text and then cut and pasted the HTML into the EAC rule editor.

I also added a small (25 x 25 pixel) graphic to make the marking more visually interesting. All you need is a small graphic file located on a web site that can be reached by Exchange. The HTML I ended up with is:

<p><strong><span style="background-color: #ff6600;"> [WARNING]</span> </strong>This message comes from an external organization. Be careful of embedded links. <img src="https://i0.wp.com/office365itpros.com/wp-content/uploads/2019/03/stop.jpg" alt="Stop" /></p>

The Rule

The important parts of the rule (as returned by the Get-TransportRule cmdlet) are shown below:

FromScope                                     : NotInOrganization
SentToScope                                   : InOrganization 
HeaderContainsMessageHeader                   : Authentication-Results
HeaderContainsWords                           : {dmarc=fail, dmarc=none}
ExceptIfSubjectContainsWords                  : {#External:}
ExceptIfSenderDomainIs                        : {bwwmediagroup.com, audi.ie, revenue.ie, dell.com...}
ApplyHtmlDisclaimerLocation                   : Prepend
ApplyHtmlDisclaimerText                       : <p><strong><span style="background-color:#ff6600;">[WARNING]</span> </strong>This message comes from an external organization. Be careful of embedded links.<img src="https://i0.wp. com/office365itpros.com/wp-content/uploads/2019/03/stop.jpg" alt="Stop" /></p>
ApplyHtmlDisclaimerFallbackAction             : Wrap

The Visual Effect

The visual marking for the message body is shown below. Of course, the danger always exists that users will become used to the warning and ignore it over time, so it might be good to change the wording, color, or images used over time.

Remember to check that the marking shows up well on all email clients in use, including mobile devices. Also, any change to an Exchange Online transport rule takes some time to be effective within a tenant due to rule caching and the need to update multiple servers.

Markings Only Warn

The best and most obvious markings that a message might be suspect can and will be ignored by human beings. That sober recognition of what people are capable of might discourage you from adding marking rules, but that’s no reason not to go ahead and use this technique. After all, if it stops one person being phished, it’s worthwhile.

Need more help with Exchange transport rules? Look no further than Chapter 17 of the Office 365 for IT Pros eBook. It’s packed full of useful information about email processing and anti-malware techniques.

Outlook Mobile by Insiders

Microsoft is running a series of five seminars delivered by the Outlook Mobile team starting March 14. The aim of the seminars is to increase customer knowledge about how to exploit the functionality of Outlook Mobile and all manner of interesting tips and tricks are promised.

As always, those running seminars like this have their own purpose. Microsoft wants Exchange customers, especially those with Exchange Online mailboxes in Office 365, to use Outlook Mobile instead of the free email apps from companies like Apple and Samsung. These clients use ActiveSync to connect to Exchange.

Reasons to Use Outlook Mobile

I don’t disagree with this aim. If you use Office 365, you should use Outlook Mobile. The reasons are:

• Outlook Mobile uses a more modern connectivity architecture than ActiveSync-based clients do.
• ActiveSync is not under active development. Microsoft will deliver new functionality for mobile clients, including the much-anticipated access to shared mailboxes, in Outlook Mobile rather than in ActiveSync.
• Office 365 Groups are integrated into Outlook Mobile
• Even if Microsoft upgrades ActiveSync, there’s no guarantee that vendors like Apple will update their mail clients to take advantage of new features enabled in the ActiveSync protocol.
• When dealing with encrypted email, Outlook mobile is a more secure client than ActiveSync clients are because it is “enlightened.” This means that Outlook Mobile can process and display email protected by rights management inline (for example, email protected by the Encrypt-Only default template available in all Office 365 E3 and E5 tenants). ActiveSync clients are “unenlightened,” so the server must decrypt protected messages before the clients can read them. Downloading decrypted messages to a device removes much of the benefit of encryption.
• It’s easier to manage Outlook Mobile clients with Intune than non-Microsoft email clients. As Outlook Mobile and Intune progress, the gap is likely to grow.

Now I’ve made the case for Outlook Mobile, you might decide that no further discussion is necessary. But perhaps a better idea is to attend one or more of Microsoft’s seminars to gather extra information before making your mind up. Added knowledge is never bad.

For more information about mobile clients for Exchange Online, read Chapters 10 and 18 of the Office 365 for IT Pros eBook. InTune is also covered in Chapter 18.

Luring the Unwary into Clicking an Attachment

The growing popularity of cloud services makes it common to receive documents for eSignatures from services like DocuSign or Adobe Sign. Attackers note trends like this and try to exploit the tendency of humans to accept things on face value, which is the basis of this phishing attempt.

The attack is relatively crude as the signs that the message is false are pretty obvious. First, no respectable eSigning service would send messages from a public email service like bluewin.ch (run by SwissCom in Switzerland). Second, the email address to the left of the domain is obfuscated. (In this case, the address is microsoftexchange3297e09615bc6ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109e@bluewin.ch).

Seeing an address like this is suspicious because there’s no reason for a legitimate service to disguise their email address in customer communications. For example, DocuSign uses dse@docusign.net for its notifications). Further examination of the message header with the useful Message Header Analyzer (MHA) add-on for Outlook didn’t reveal anything to make me believe that the message was valid.

Examining the Link

The next thing is to look at its payload. The user is asked to click a link to see a PDF document. The reader is conned into believing that the link will take them to OneDrive (using a blurry graphic), but it really leads to digitaloceanspaces.com. There’s no need to go any further to prove that this message is a phishing attempt because no valid communication would signal that it comes from OneDrive and go to a developer site.

Reporting Phishing Messages

If you receive a message like this, you can report it to Microsoft with Outlook or OWA. Microsoft analyzes reported messages to understand the techniques used by attackers to bypass anti-malware checks such as Exchange Online Protection. The intelligence gathered is used to improve the checks.

Given the volume of spam and malware (53.49% of total email volume in September 2018), some phishing messages will always get through. Here are two other examples of recent phishing attempts: “Encrypted file from OneDrive” and “Retrieve pending messages for domain.”

Office 365 includes good out-of-the-box protection, but admins need to understand how to use Exchange Online Protection and users need some help to understand how to detect any bad stuff that arrives in their inboxes.

The array of anti-malware checks and tools available in Exchange Online Protection and Advanced Threat Protection for Office 365 are described in Chapter 17 of the Office 365 for IT Pros eBook. Because I read Chapter 17, I knew what to look for in the bad message.

New OWA: A Crisp, Clean Feeling

The updated version of OWA is now generally available, which means that it is now available in all Office 365 tenants. The new design is fresh and attractive and includes some nice new features, such as supporting Outlook categories in its favorite list, not to mention dark mode, the ability to schedule Teams meetings, and other new stuff.

On the other hand, some features from the older interface haven’t yet made it across to the new version. However, most of what’s not there could be regarded as nice to have rather than essential, and the new client is more than ready for use.

OWA’s Extra Tabs

While those who know how to use the old OWA won’t encounter much difficulty finding their way around the new, one behavioral change is already causing some comments. In the old OWA, when you switch from mail to calendar, the same tab is used within the browser. The new OWA launches a separate tab. Although this allows you to quickly move between calendar and email, you can end up with multiple tabs open for OWA.

The OWA Toggle

Because the new OWA is generally available, Microsoft has updated the UI of the old client to display a toggle switch to select the new OWA.
Toggling the switch on causes OWA to refresh and load the new interface. Toggling off reverts to the old UI.

As during the preview of the new OWA, administrators can control the display of the toggle switch with the OutlookBetaToggleEnabled setting in the OWA mailbox policy assigned to mailboxes. If True, OWA displays the toggle. If false, the toggle is invisible. If you look at the OWA mailbox policies in your tenant, you’ll find that Microsoft has enabled the toggle for all policies.

Controlling the New OWA Toggle

Some tenants will want to stop people using the new OWA in order to allow help desk and documentation to be prepared. This is easily done by switching the setting to False. For example, to do this for all policies, run the command:

Get-OWAMailboxPolicy | Set-OWAMailboxPolicy -OutlookBetaToggleEnabled $False

You might then assign a new OWA mailbox policy with the switch enabled to users that need to access the new UI for testing. Let’s assume that this policy is called OWAFullAccess. To set the switch in the policy and assign it to a mailbox, run the commands:

Set-OWAMailboxPolicy -Identity OWAFullAccess -OutlookBetaToggleEnabled $True
Set-CASMailbox -Identity Sanjay.Patel -OWAMailboxPolicy OWAFullAccess

Because Exchange Online caches client settings, it normally takes about 15 minutes before the assignment of an OWA policy to a mailbox or changing a setting in an OWA policy is effective.

If you disable the toggle to stop people enabling the new OWA, anyone who has already switched the toggle to on won’t be able to revert to the older interface because the toggle disappears. A small edge case to consider…

We cover OWA among the other Exchange clients in Chapter 10 of the Office 365 for IT Pros eBook.

Email Encryption is Good, but Only Under Tenant Control

In January 2019, Microsoft revealed a plan to create a transport (mail flow) rule in Office 365 tenants to encrypt email containing sensitive data. For many reasons, not least that it’s not a good idea to interfere with the business logic a tenant chooses to apply to outbound email, Microsoft pulled back on the idea. On January 25, after a period of mature reflection, Microsoft decided to publish details of how to create the transport rule and leave it to tenants to decide if they want to use it. Those instructions are now online. This post explores the commands included in Microsoft’s instructions.

PowerShell Commands to Create Rule

The instructions use two PowerShell commands. The first runs the Set-IRMConfiguration cmdlet to update the rights management configuration for Exchange Online in the tenant. The command sets the DecryptAttachmentForEncryptOnly switch to $True to give recipients of messages protected with the default Encrypt-Only template full rights over any attachments. The default value of this setting is $False, which means that attachments remain encrypted.

Unfortunately, the command published in the article is incorrect as it uses DecryptAttachmentsForEncryptOnly instead of
DecryptAttachmentForEncryptOnly.The correct command is:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Microsoft’s New Transport Rule

The next command runs the New-TransportRule cmdlet to create the transport rule. The rule applies the Encrypt-Only template to protect any messages that include the following Office 365 sensitive data types:

• ABA Routing Number.
• Credit Card Number.
• Drug Enforcement Agency (DEA) Number.
• U.S. or UK Passport Number.
• U.S. Bank Account Number.
• U.S. Individual Taxpayer Identification Number (ITIN).
• U.S. Social Security Number (SSN).

The Encrypt-Only template is used because it is available to every Office 365 commercial tenant and any Outlook.com user. Any other recipient can go to the Office 365 Message Encryption portal to decrypt the content.

Checking the Rule

The sensitive data types are very U.S.-centric and might need to be adjusted for your tenant to include data types that are more commonly used in your organization. I imagine that Microsoft chose the set for the rule because they are well-known and prove the potential value of the rule rather than deciding that these types make sense for every Office 365 tenant. Remember that you can create your own custom data type and use it if needed.

Unhappily, the PowerShell gods conspired against this command as well because it also has an error. The command as given by Microsoft is:

New-TransportRule -Name "Encrypt outbound sensitive emails (out of box rule)" -SentToScope  NotInOrganization  -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="Drug Enforcement Agency (DEA) Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -SenderNotificationType "NotifyOnly"

The problem is the last parameter where SenderNotificationType should be NotifySender. Change the command and replace the last parameter with NotifySender = “NotifyOnly” and PowerShell will happily create the new rule.

Adjusting for Your Office 365 Tenant

Before running New-TransportRule, remember to adjust the command to include the sensitive data types that you want to check for and any other changes deemed appropriate for your tenant. For instance, you might not want to encrypt email to every other domain and decide that protection should only be applied to specific domains.

If you don’t want to work with transport rules through PowerShell, you can run Microsoft’s command and then edit the transport rule through the Exchange Admin Center GUI. As you can see below, it is often easier to adjust settings through a GUI. In this case I limit the domains that receive protected email. If you choose to limit the rule to selected domains, you must also remove the notification to the sender as this setting conflicts with a domain list (for no apparent reason)

It is important to check that the new rule does not conflict with any other rule that already exists. For instance, you might discover that another rule does something else to messages sent to the selected domains and then exits rules processing, so messages will never be encrypted.

The old advice to never trust and always check code downloaded from the internet holds true, even when you download code written by Microsoft.

We cover rights management and email encryption in Chapter 24 of the Office 365 for IT Pros eBook while transport rules are described in all their glory in Chapter 17.

Encryption for Exchange Online Autosignatures

When I wrote about the effect of encryption on ISV autosignature products, I made the point that the Exchange transport service can apply autosignatures (disclaimer text) to outbound messages with a rule even if the messages are encrypted. This is because Exchange uses rights management super-user permissions to decrypt messages, apply the disclaimer, and then encrypt them again for final delivery.

Questions flowed in to know if it is easy to create a transport rule (aka mail flow rule) to apply an autosignature like those generated by the ISV products. The answer is that you can, but it takes some effort, especially if you want to use nicely formatted HTML text in the autosignature. The UI in the Exchange Admin Center to create and manage transport rules isn’t very accommodating when it comes to inserting complex formatted text. However, with persistence, it’s possible to create nicely formatted autosignatures (see the Exchange documentation for some examples, including how to insert a graphic file like a logo in an autosignature).

Apart from the difficulty of editing the text used in autosignatures applied by transport rules, the most common complaint is that rules stamp all messages, including replies, so you end up with multiple autosignatures in a mail thread. This is true, but it’s easy to build an exception into the rule so that the autosignature is applied once.

Once you’ve built a transport rule to apply an autosignature, you can combine it with other rules to protect messages sent to all or some destinations by applying a rights management template, including the special Encrypt-Only or Do Not Forward templates.

An Example of Encrypted Email

An example is always helpful. The screenshot below shows a protected message received by an Outlook.com user. The message has an autosignature applied by a transport rule. The text of the autosignature is inserted into the message content even though the message is protected. Some Azure Active Directory elements (like the first name, last name, phone number, etc.) are used in the autosignature. The phone number is blank, meaning that it hasn’t been populated for the user (more on this below).

The relevant extracts from the transport rule (using Get-TransportRule) are shown below.

ExceptIfSubjectOrBodyContainsWords            : {This message is the property of Redmond and Associates}
ApplyHtmlDisclaimerLocation                   : Append
ApplyHtmlDisclaimerFallbackAction             : Wrap
ApplyHtmlDisclaimerText                       :

Redmond and Associates

This message is the property of Redmond and Associates If you receive this message in error, please delete it immediately and inform us at +353 1 991 17463 about its delivery.
%%FirstName%% %%LastName%%
Phone: %%PhoneNumber%%
Email: %%Email%%

The exception in ExceptIfSubjectOrBodyContainsWords is important because it stops the autosignature being inserted into replies.

Why Use Third-Party Autosignature Products?

If it’s relatively straightforward to use a transport rule to insert autosignatures, including for protected email, why do people buy and use third-party autosignature products? The biggest reasons are flexibility and ease of use. The third-party products make it much easier to build and deploy attractive autosignatures to targeted sets of users (or the whole company) without having to grapple with the Exchange Admin Centre UI or PowerShell. Much as I like PowerShell, using it to edit HTML is not a rewarding experience.

Organizations that need to change autosignatures frequently (for instance, to advertise events) or deploy a range of different autosignatures to different groups within the company will find it easier to use specialized autosignature products. The downside, as I pointed out in the Petri.com article, is that server-side processing by these products cannot deal with protected messages. A client-side add-in must inject the autosignature into a message before encryption is applied by the client.

Directories

A word on directories… No centrally-managed autosignature will work unless the directory it’s based on holds accurate information. Make sure that your Azure Active Directory is updated with valid information for any of the attributes (like address or phone number) used by autosignatures.

For more information about transport rules, see Chapter 17 of the Office 365 for IT Pros eBook.

Capturing User Access to Exchange Messages

In an Office 365 update (MC171679 ) posted on January 4, Microsoft announced that a new “MailItemsAccessed” audit action will join the set of actions that can be captured in mailbox audit events. The new action will capture details of when a message in a mailbox is opened by the mailbox owner, delegate (someone with read access to the mailbox), or using administrative access. According to Microsoft, the data gathered gives
“comprehensive forensic coverage of mailbox accesses.” This is an important change for anyone who needs to investigate what happened if a mailbox is penetrated by an attacker or a delegate takes unauthorized action inside a mailbox.

Exchange will update the default mailbox audit configuration in February 2019 and begin to record mail accessed events. Initially, these events will be captured in the Exchange mailbox audit log and will not be ingested with the other Exchange mailbox audit events into the Office 365 audit log. To search for the new events, you’ll have to run the Search-MailboxAuditLog cmdlet.

Microsoft will eventually upgrade the ingestion process to bring the new audit data into the Office 365 audit log. There’s no word when this might happen.

More Comprehensive Capture of Audit Data by Exchange

As you might expect, the MailItemsAccessed action replaces the MessageBind action, which today records when a message is viewed by being opened by the user or in the preview pane. The new action captures a more comprehensive range of accesses to mailbox items, including items synchronized to mobile devices, so it gives more information to investigators who need to understand what happened inside a mailbox should an incident occur. However, for backwards compatibility, the MessageBind action is not being removed from mailbox audit configurations and can be left in place.

No Need to Update Default Configurations

If your tenant uses default Exchange mailbox audit configurations, you don’t need to do anything as Microsoft will update the audit settings for owner, delegate, and administrative access. However, if you manage customized audit settings for mailboxes, you need to run the Set-Mailbox cmdlet to update the audit configurations if you want to include the capture of MailItemsAccessed actions.

Note (January 23, 2019): Microsoft has completed the deprecation of the MessageBind audit action. You can no longer assign this action to the AuditDelegate or AuditAdmin settings for an Exchange Online mailbox.

For more information about Exchange Online mailbox auditing or the Office 365 audit log, read the comprehensive coverage in Chapter 21 of the Office 365 for IT Pros ebook.

A State of Constant Refresh

Part of what we do to keep the Office 365 for IT Pros eBook updated is to revisit text over time. Microsoft makes subtle changes in Office 365 all the time, and the possibility always exists that a change affects what we’ve written. And there’s always the opportunity to rewrite text to make it clearer or more concise, or simply to include new facts and insights that we have learned since, or to correct errors that crept into the text for one reason or another.

Refreshing Chapter 6

This week, I reviewed the section about sending email with PowerShell in Chapter 6. Apart from anything else, I want to upgrade the script to find obsolete Office 365 Groups and Teams to send email to prompt owners to do something if their group has fallen into disuse.

The Send-MailMessage cmdlet sends an email message using an SMTP connection to submit the message to a server. There are a ton of different posts available to read about sending email with PowerShell, but Microsoft has been rolling out some changes in SMTP client authenticated submission protocol recently, so it’s good to revisit the situation. One of those changes is very welcome in that Exchange Online now keeps copies of messages in the Sent Items folder of the sending mailbox, which removes the need to include the sender in the recipient list.

In an interesting article called “How to set up a multifunction device or application to send email using Office 365“, Microsoft describes three methods for sending email in Office 365:

• Client submission. This method is the traditional approach and uses an Exchange Online mailbox. Messages sent can be traced in the normal manner.
• Direct send via the tenant’s MX endpoint. This choice is best when you need appliances to send messages via Office 365, when you only need to send email (like notifications) within the tenant, and for bulk delivery. Messages sent this way cannot be traced because their progress is not logged.
• Connector relay. This method is best used when messages always originate from a fixed IP address.

For details about each method, see the article.

Client Submission Best for My Purposes

I tried the client submission and direct send before settling on client submission. Sending email via the MX endpoint is faster because you don’t need to authenticate and don’t use a mailbox. However, the lack of tracing is a big issue when dealing with email, and I also ran into some odd situations that I still quite don’t understand. For instance, messages seemed to be sent successfully, but they never turned up in the recipient’s mailbox. This happened intermittently and unpredictably, which is always bad.

Being Listed as a Spammer

Another issue to consider when sending email to the MX endpoint, especially you’re testing a script repeatedly, the danger exists that your activities seem awfully like what a spammer might do when viewing through the lens of the Office 365 anti-malware checks. I duly ran into this problem and was rewarded with:

Send-MailMessage : Mailbox unavailable. The server response was: 5.7.606 Access denied, banned sending IP [51.171.212.192]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655

The link brings you to a page containing instructions about how to delist a blocked address using the Office 365 Anti-spam IP delist portal. Basically, Office 365 saw the stream of messages generated over a short period from my IP address and concluded that I was up to no good.

The delisting process is straightforward. Head to the IP delist portal (see below) and:

• Insert the email address used as the SMTP from address to send messages with the Send-MailMessage cmdlet.
• Insert the IP address reported by PowerShell.
• Solve the Catcha puzzle and submit.

About 30 minutes later, you should be able to send email again from the IP address.

Submission Limits

If you choose to use the client submission method, another issue you might run into is that Exchange Online limits a user to sending 30 messages per minute. This limit is easily exceeded when you generate and send messages with PowerShell, so it is wise to build in a short 2 second delay after sending each message. Another limit that is less easily reached is that a mailbox can send messages to a maximum of 10,000 recipients per day.

In any case, I’ll return to this topic when I’m finished updating the scripts – and the section in Chapter 6.

We like PowerShell, so it’s liberally sprinkled throughout the chapters of Office 365 for IT Pros. Sometimes we make mistakes in our code, but that’s the joy of PowerShell – it’s easy (normally) to fix.

Encrypted or protected email is becoming more common inside Office 365 with the advent of the Encrypt-Only feature available in Outlook 2016 (Click to Run) and OWA.

You can include a mixture of internal and external recipients, including those who do not use Office 365, in the recipient list for a protected message and, subject to scoping defined for the template used to protect the message, will be able to open and access the content. You can also send protected messages to other Office 365 destinations, but as explained below, some restrictions apply.

Office 365 Groups

Protected messages (and attachments) sent to an Office 365 group can be read by any member of the group, including guest users, because they authenticate their access through membership of the group. 

Scoped Templates will Stop Access

The exception is when the template used to protect a message is scoped to assign permissions to specific recipients and a member of the Office 365 group is not included. In this case, the group member sees a conversation and who contributed to the conversation, but can’t see the content of the message (see below). if they click the banner telling them that a message can’t be displayed, they see the link to the Office 365 Message Encryption portal. However, this link won’t give them access because their account is not in the permissions list for the message.

Shared Mailboxes

Protected messages sent to a shared mailbox can be opened and read by those with access to the shared mailbox if they use OWA. However, the same people can’t read the messages if they use Outlook. The difference in behavior is explained by the way that OWA fetches use licenses. Microsoft has admitted that they need to make both clients work the same way.

Teams Channels

Protected messages sent to the email address of a Teams channel (for example, 95c133a3.office365itpros.com@emea.teams.ms) are rejected by Exchange Online because the transport service cannot re-encrypt the message for delivery to the phantom mailbox used to route messages to Teams. As shown below, the sender receives a 5.7.1.Delivery Service Notification (DSN). Exchange Online decrypts protected messages as they pass through the transport service to allow transport rules to process the content.

Yammer Groups

The same happens if you try to post a protected message to a Yammer group (with an address like office365QA+office365itpros@yammer.com). Again, Exchange Online can’t re-encrypt the message to deliver it to Yammer, so it issues a 5.7.1. DSN.

Learn all about rights management, templates, and email protection in Chapter 24 of the Office 365 for IT Pros eBook.

Managed Folder Assistant and and Exchange Online

The Managed Folder Assistant (MFA) is an important component in the application of data governance policies for Exchange Online mailboxes. Not only does MFA apply Exchange mailbox policies to mailboxes, it also applies Microsoft 365 retention policies and DLP policies. MFA treats Exchange retention tags and Microsoft 365 retention labels equally, and makes sure that users see a common set of tags for application to mailbox folders and items. Finally, MFA makes sure that Teams compliance records are cleaned up based on the settings in the Teams-only retention policies.

Microsoft 365 uses a different background assistant to process retention policies for non-Exchange workloads.

MFA Workcycle

Exchange Online uses a workcycle policy to run the Managed Folder Assistant. This means that a goal is set (once a week) for the system to process mailboxes. Exchange Online balances the demands of the workcycle policy and available system resources to make sure that MFA meets its workcycle goal. My experience is that MFA usually performs better than the stated goal and that you can expect to have mailboxes processed twice a week.

However, apart from noticing that some messages have been moved from a folder (perhaps to the Deleted Items folder or to an archive mailbox), there’s no obvious outward sign that the Managed Folder Assistant has processed a mailbox. Unless you examine the mailbox properties, which is where Exchange notes details of the processing done by the Managed Folder Assistant.

Here’s some PowerShell to create a set of user mailboxes and extract information about MFA processing for each mailbox. The XML properties extracted from the mailbox hold lots of information about the mailbox. All of the MFA-related properties are prefixed with “ELC” (Email Lifecycle Control or some similar meaning), and you can examine the properties to expose other information as you like. In this instance, I’ve grabbed the timestamp for the last time the Managed Folder Assistant processed the mailbox and the number of messages MFA removed from the mailbox. The output report is sorted by the last processed timestamp. You should see a variety of timestamps because Exchange Online does not process all mailboxes in a tenant at the same time.

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Sort-Object DisplayName
$MbxReport = [System.Collections.Generic.List[Object]]::new() 
ForEach ($M in $Mbx) {
   $LastProcessed = $Null
   Write-Host ("Processing {0}" -f $M.DisplayName)
   $Log = Export-MailboxDiagnosticLogs -Identity $M.ExternalDirectoryObjectId -ExtendedProperties
   $xml = [xml]($Log.MailboxLog)  
   $LastProcessed = ($xml.Properties.MailboxTable.Property | Where-Object {$_.Name -like "*ELCLastSuccessTimestamp*"}).Value   
   $ItemsDeleted  = $xml.Properties.MailboxTable.Property | Where-Object {$_.Name -like "*ElcLastRunDeletedFromRootItemCount*"}
   If ($LastProcessed -eq $Null) {
      $LastProcessed = "Not processed"}
   $ReportLine = [PSCustomObject]@{
      User          = $M.DisplayName
      LastProcessed = $LastProcessed
      ItemsDeleted  = $ItemsDeleted.Value}      
    $MbxReport.Add($ReportLine)
  }
$MbxReport | Sort-Object {$_.LastProcessed -as [datetime]} -Descending

If a mailbox reports a timestamp from a long time ago, it is probably because the mailbox has dipped under the 10 MB threshold and is therefore no longer a candidate for MFA processing.

No Processing for Small Mailboxes

MFA does not processes a mailbox if it holds less than 10 MB of content. The script shown above checks for these mailboxes and returns “Not processed” when the mailbox diagnostics cmdlet doesn’t return a successful timestamp. Usually, this means that a mailbox is too small for MFA to process. It could also be true that the mailbox was too small the last time MFA checked and subsequently grew past 10 MB and is waiting MFA to return and process the mailbox.

To check the size of a mailbox, run the Get-ExoMailboxStatistics cmdlet and examine the TotalItemSize property:

Get-ExoMailboxStatistics -Identity "imran khan" | Select-Object TotalItemSize

TotalItemSize
-------------
5.723 MB (6,001,249 bytes)


Hopefully this information helps you understand how often the Exchange Managed Folder Assistant processes Exchange Online mailboxes inside your Microsoft 365 tenant.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

An Insight Into Encryption

If you have deployed the new sensitivity labels into your Office 365 tenant or have trained people how to apply protection through rights management templates such as the default Encrypt-Only and Do Not Forward options available in OWA and Outlook, you might like to get some insight into how much email is being protected.

As announced at Ignite, the Security and Compliance Center includes a Message encryption report to show details of encrypted email processed in the last seven days. The report is in preview, so it doesn’t appear on any dashboard. However, if you’re an Office 365 tenant administrator, the report is revealed with this URL (Figure 1).

The report shows the date, sender, recipient, subject, and encryption details. The encryption template is either one of the default (like Encrypt only) or a custom template (one defined by the tenant).  The encryption method shows whether protection is applied by a user or automatically, such as by a transport rule.

Some Points to Improve

There’s no way to export this information, nor is it recorded in the Office 365 audit log. The information gathered also seems to ignore some encrypted messages, including email sent to Microsoft. No doubt these are the kind of glitches that will be sorted out before Microsoft moves the feature from preview to generally available.

For more information about email encryption in Office 365, read Chapter 24 of the Office 365 for IT Pros eBook.

Sometimes you’re told things that turn out to be incorrect, which is what happened when I originally wrote this post. I was asked why OWA displayed logos and turned to some contacts in Microsoft, one of whom told me that the answer was BIMI. As it turns out, that answer was wrong. I should have checked further, but didn’t. Now that I have found out the real answer, I document it here.

BIMI: Helping to Highlight Good Email

Brand Indicators for Message Identification (BIMI) is a standardized method for companies to publish their brand logos online so that the logos can be used in applications like email. The idea is that users will be more easily able to recognize messages from companies by seeing their logos when the logos are displayed in applications. A draft industry-wide standard  for BIMI is available.

BIMI Logos in DNS

The BIMI logo information is published in a DNS resource record. The record includes a link to the graphic file for an SVG-formatted logo. Email and other applications then retrieve the logo from DNS and load it alongside other message data such as Inbox lists and message windows.

It’s worth underlining that BIMI builds on and does not replace existing email authentication mechanisms such as SPF and DMARC. Reputable organizations should always publish SPF and DMARC records to allow receiving domains to authenticate inbound email. For more information about BIMI, head to the Brand Indicators site.

Microsoft’s Business Profile Program

Interesting as BIMI is, Microsoft does not participate in the BIMI initiative. Instead, they have their own approach called “brand cards,” which serve much the same purpose without using DNS. Instead, businesses sign up with the Microsoft Business Profile program, which is currently in beta.

When a company signed up, they give Microsoft a verified icon that is used by OWA in Office 365 and Outlook.com. As you can see below, the logos for Microsoft and Fitbit show up in OWA, which means that these organizations have business profiles, while Carrefour or Parking Tag do not. Outlook desktop and Outlook mobile do not yet support the display of brand cards. Because the program uses Bing, some brand cards are generated for well-known organizations.

The BIMI initiative could become an industry standard. Microsoft’s business profile program is definitely led by Microsoft. Whether the two will come together in the future is open for debate.

Nothing for an Office 365 Admin to do

You don’t have to do anything inside Office 365 before OWA displays brand logos as this is under the control of the email program and depends on whether a brand card exists for an organization. In fact, you can’t stop OWA displaying the logos.

SPF and DMARC are discussed at length in Chapter 17 of the Office 365 for IT Pros eBook along with lots of other great information about anti-malware techniques.

Outlook Mobile Connects with Microsoft Sync Technology or an Older Protocol

In my Petri.com article about the new architecture (aka, “Microsoft Sync Technology”) Microsoft is deploying to connect Outlook for iOS and Android devices to Exchange Online and Outlook.com, I mention a Microsoft FAQ on the topic. That FAQ includes some PowerShell code to help administrators know what protocol devices use to connect. The code is perfectly good, but being PowerShell, there are many ways to approach a problem and some to improve the solution. Here’s my attempt to do so.

The single-line command (always good) in the FAQ uses the Get-MobileDevice cmdlet to retrieve a list of devices that have connected to Exchange Online, extracts the devices running the iOS or Android client, and reports the protocol each device uses. All good, but the data would be more valuable if you knew who used the devices as well.

Mailboxes, Not Mobile Devices

My solution takes a user-centric approach to the question. The first step to know who is using Outlook for iOS or Android to connect to Exchange Online is to create a set of user mailboxes as they’re the only Exchange objects that can have mobile devices.

Next, we go through the list of mailboxes and use the Get-MobileDeviceStatistics cmdlet to examine details of mobile devices that have “partnerships” with each mailbox. We’re only interested in devices that report running Outlook for iOS or Android. If we find such a device, we grab the statistics like the O/S version running on the device and the date and time of the last successful synchronization. To know what architecture the device uses, we examine the ClientType property, which is “REST” if the device connects using the old architecture, or “Outlook” for the new.

[array]$Mbx = (Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select-Object Alias, DisplayName)
Write-Host "Processing" $Mbx.count "mailboxes"
$Report = @()
ForEach ($M in $Mbx) {
   Write-Host "Checking devices for" $M.DisplayName
   $Devices = (Get-MobileDeviceStatistics -Mailbox $M.Alias | ? {$_.DeviceModel -eq "Outlook for iOS and Android"})
   If ($Devices.Count -eq 0)
      { Write-Host $M.DisplayName "has no Outlook Mobile devices"}
   Else 
      { ForEach ($D in $Devices) {
        $ReportLine = [PSCustomObject]@{
           User     = $M.DisplayName
           Device   = $D.DeviceFriendlyName 
           OS       = $D.DeviceOS
           SyncType = $D.ClientType
           LastSync = $D.LastSuccessSync}
      $Report += $ReportLine }
  }
}

Examining Connection Details

To see what data our code generates, we examine the $Report variable.

$Report | Format-Table User, Device, SyncType, Lastsync, OS

User            Device          SyncType LastSync             OS
----            ------          -------- --------             --
Deirdre Smith   Outlook for iOS REST                          iOS 12.1
Deirdre Smith   Outlook for iOS REST     24 Aug 2018 17:30:53 iOS 11.4.1
Deirdre Smith   Outlook for iOS REST     4 Dec 2018 21:27:16  iOS 12.0
James Ryan      Outlook for iOS REST     10 Oct 2018 16:22:52 iOS 12.0
Tony Redmond    Outlook for iOS REST     1 Oct 2017 18:13:27  iOS 10.3.3
Tony Redmond    Outlook for iOS REST     4 Dec 2018 22:32:34  iOS 12.0

At the time of writing, clients in my tenant still use the REST protocol that’s soon to be replaced by the Outlook protocol. See the Petri.com article for details.

Of course, if we need to do some deeper analysis, we can output the information to a CSV file with another command. The CSV file can then be loaded into Excel or Power BI to slice and dice the data, generate graphs, and so on.

$Report | Export-CSV -NoTypeInformation c:\temp\OutlookMobileDevices

Easy!

For more information about Office 365 clients, read Chapter 10 of the Office 365 for IT Pros eBook, while Chapter 18 covers mobile devices.

Include a Teams Channel Email Address in a DL to Make it Easier for Users to Email

Updated: January 2022

Following yesterday’s post about the email addresses used by Microsoft 365 Groups and Teams, including Teams channel email addresses, the following question was asked:

“I have an existing email address from my distribution list.
I am using this address for a Microsoft flow “send an email to a SharePoint list”.
The emails send to this email address I also want to place in a teams channel.
1. Can I use my existing email address as an alias from a team channel or
2. can I forward my email sent to the existing email address to a teams channel?“

In other words, we have an existing distribution list that we want to add a Teams channel email address as a member so that anything sent to the list is copied to the channel, including the capture of the messages and attachments in SharePoint.

Simple Solution – an Exchange Mail Contact

The simple solution is to create a new mail contact in Exchange Online using the email address for the channel. Go to the Recipients section of the (new or old) Exchange Admin Center (EAC), then Contacts, and add a new Mail Contact with the email address of the channel entered in the external email address property (Figure 1).

If you plan to allow people to email the distribution list from outside your organization, make sure to configure the distribution list to allow it to accept messages from unauthenticated senders. You can do this by editing the distribution list properties through the EAC, or by running the Set-DistributionGroup cmdlet to set the list’s RequireSenderAuthenticationEnabled property to $False:

Set-DistributionGroup -Identity "Teams DL" -RequireSenderAuthenticationEnabled $False

Exchange Online fully supports the addition of mail contacts in its distribution lists, so it’s an easy step afterwards to update the distribution list with the new contact. You can do this through the EAC or with PowerShell. For example, here’s how to add the contact created above to a DL.

Add-DistributionGroupMember -Identity "My DL" -Member "Teams911"

Any message now sent to the distribution list will be copied to the Team channel. If you don’t want the mail contact to show up in the GAL and OAB, set it to be hidden.

Set-MailContact -Identity Teams911 -HiddenFromAddressListsEnabled $True

More Complicated with Guest Accounts

You can also create a Azure Active Directory guest account for a teams channel email address and when you have the account set up, you can add that account to a distribution list. Exchange Online treats guests as mail users, which are a valid recipient type for email and supported as distribution lists members.

However, Exchange won’t deliver copies of messages sent to the distribution group to a guest member. The reason is that guest accounts don’t appear in Exchange address lists, so Exchange can’t check the validity of the recipient. Messages sent to the distribution list are delivered to all other members, but the guest account is a black hole.

The workaround is to add the guest to a Microsoft 365 group. Guest accounts are automatically added to the subscribers list of a Microsoft 365 group because email is the way they participate in conversations. If you then add the Microsoft 365 group to a distribution list, routing works as expected because when Exchange checks the recipients, it validates the Microsoft 365 group and not the individual members. Messages sent to a distribution group that include a Microsoft 365 group with a guest member pointing to a team channel work, but it’s a complicated approach when compared to the simplicity of using a mail contact.

For more information about distribution lists and mail contacts, go to Chapter 7 of the Office 365 for IT Pros eBook. And when you’ve read all that material, go on to Chapter 11 to learn about Microsoft 365 Groups and Chapter 13 to learn about Teams.

There’s Email and There’s Email

I’ve seen some confusion over the email addresses used by Microsoft 365 Groups and Teams. This note gives a quick summary of the situation.

Email Addresses for a Microsoft 365 Group

Every Microsoft 365 group has at least one email address, but might have several, all of which can be used to route email to the group. We can retrieve the addresses from the group’s EmailAddresses property.

Get-UnifiedGroup -Identity "PL Test" | Select -ExpandProperty EmailAddresses
SPO:SPO_34be8c3b-3b4b-42e5-9e27-569045512c97@SPO_b662313f-14fc-43a2-9a7a-d2e27f4f3478
smtp:PLTest@office365itpros.onmicrosoft.com
SMTP:PLTest@office365itpros.com

The SMTP proxy addresses assigned to Microsoft 365 groups are used by Exchange Online to route email. Exchange Online creates the set of SMTP addresses during the creation of a new Microsoft 365 group. The set of addresses might be affected by the existence of an email address policy for groups. In all cases, one of the addresses must be a MOERA (Microsoft Online Email routing address), which comes from the tenant service domain (xxx.microsoft.com). Another of the addresses has the prefix highlighted, meaning that this address is the primary address of the type. For SMTP addresses, this means that the address is stamped on outbound messages sent by the group. The primary SMTP address for the group is also stored in the PrimarySMTPAddress property. For example:

Get-UnifiedGroup -Identity "PL Test" | Select PrimarySMTPAddress

PrimarySmtpAddress
------------------
PLTest@office365itpros.com

Sending to a Group

When you send email to a Microsoft 365 group, Exchange Online treats the group like a distribution list and delivers messages to any of the group members who subscribe for updates. A copy of the message is also delivered to the group mailbox, where it creates a new conversation in the group inbox. To find out which members receive updates sent to a group, run the command (there’s no UI to expose this list):

Get-UnifiedGrouplinks -Identity "PL Test" -LinkType Subscribers

Email for Teams Channels

If the Email Integration setting is enabled for Teams in a tenant, (Figure 1) you can generate email addresses for channels and use those addresses to send email to the channels. It’s important to underscore that the recipient is a channel and not the members of the team.

To generate an email address for a channel, select the channel and then take the Get Email Address choice in the […] menu. If an email address doesn’t already exist, a new one is generated (Figure 2). Any member of a team (except guests) can generate an email address for a channel.

The email address does not belong to any domain associated with the Microsoft 365 tenant. Instead, it’s in a part of Office 365 managed by Microsoft. The address is intended to be obscure to avoid casual spamming, so we end up with something like this:

General – Project Condor <95c133a3.office365itpros.com@emea.teams.ms>

If a channel is spammed, just remove the email address and generate a new one or include the spamming domain in the blacklist in the Email Integration section of Teams settings.

The email address for a Teams channel can be used much like any other email address. For instance, you can add it as a mail contact to the Exchange GAL or include it in the membership of a distribution list.

Sending to a Channel

When you send email to a channel, the message arrives in a special form of mailbox. A connector then picks up the new message and imports it into Teams, where it shows up in two places:

• A new conversation in the channel.
• A copy of the message (.eml file) and any attachments are stored in the SharePoint site belonging to the team. You’ll find these items in the Email Messages folder (Figure 3) under the folder for the channel. (Note: In February 2021, Microsoft changed how it stores copies of messages received by channels in SharePoint Online).

Because the messages and attachments are in SharePoint, they are indexed and available for compliance purposes.

Copies of messages sent to a channel are never delivered to team members. The email address is for a channel and does not act like a distribution list. If you want to send email to everyone in a team, use the email address assigned to the Microsoft 365 group used by the team. If the recipients subscribe to the group, they’ll get the message. If not, they won’t unless you use PowerShell to read the group membership and add each member as a recipient for the message.

For more information, read Office 365 for IT Pros to learn about much more about Microsoft 365 Groups and Teams. Obviously, we have a lot more to say about these and other associated topics than can be covered in a 600-word blog post.

S/MIME and the Unified Labeling Client

One of the interesting aspects of the latest release of the Azure Information Protection (AIP) client  (version 1.41.51.0) is its ability to use an existing S/MIME deployment instead of cloud-based rights management to sign and encrypt email.  The integration is only supported for the click-to-run version of Outlook 2016 for Windows.

The idea is that you can create a custom configuration for Outlook to call S/MIME instead of the normal rights management templates to encrypt an outbound message (read the online instructions). The custom configuration associates an S/MIME action (sign, encrypt, or both) with an AIP label. When the user applies the label to a message, the AIP client updates the message properties with the label metadata and applies whatever S/MIME action is defined.

The idea is not to replace rights management with S/MIME. Instead, it’s to help a small group of customers who have invested to deploy an S/MIME infrastructure. The custom AIP configuration does nothing to help customers manage S/MIME; it simply applies the S/MIME protection if it is available and functional.

Not for Most Office 365 Tenants

Although this feature proves the flexibility of the AIP client, I don’t think it is of much interest to the majority of Office 365 tenants. Here’s why:

• The solution only works for Outlook for Windows.
• Cloud-based rights management is built into and enabled for every Office 365 E3 and E5 tenant. You don’t have to do any work to encrypt messages with Outlook and OWA (or read those messages on any email client).
• The advent of Office 365 sensitivity labels, which will work for Office applications (Windows, Mac, and Online) in addition to email, makes rights management even more valuable. It’s not hard to see how Microsoft will extend coverage of sensitivity labels to other Office 365 data (like Teams conversations or channels) in the future.
• Rights management makes it easy to protect messages with transport rules.

So, a nice feature if you use S/MIME and have invested in that technology – but maybe it’s time for you to think about using something more modern and functional to protect more than just email?

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

Another Day, More Malware

Following yesterday’s phishing attempt, another suspicious message turned up in my inbox purporting to be a notification from Microsoft Office 365 that messages were waiting retrieval for my domain (Figure 1).

The Signs of Badness

There are many signs that give away the intent behind this message.

• Its from address is “‮‮563eciffO tfosorciM‬‬ <ms-Redmondassociates.outlooks.Redmondassociates365@tempecountyislandfiredistrict.org>.” No Microsoft communication would ever use such an address. The domain is owned by the Tempe fire service in Arizona (which doesn’t secure its web site very well either).
• The URL to “Recover Pending Messages” points to a very suspicious domain that doesn’t belong to Microsoft (or any other reputable service).
• The text of the message is poorly written and doesn’t match the quality of the communications I expect from Microsoft. I won’t go into this any further as it might help attackers to compose more plausible messages.

And so on…

Overall, this is a pretty amateurish phishing attack, but it’s one that could con an unwary Office 365 tenant administrator into clicking the link “to get email going again.”

What’s not so good is that this is the type of message I would expect Exchange Online Protection and Advanced Threat Protection to catch. There’s been a few examples of this kind of stuff getting through recently.

November 2019 Mail Non-Delivery Phishing

Figure 2 and 3 show a couple of Phishing messages that are circulating in November 2019 to try and convince recipients that some of their messages remain undelivered and can be recovered if only they’d “visit the portal” or “review” what’s happening.

When you see phishing attempts like this, please remember to report the messages to Microsoft. Doing so will help everyone in the long run.

The array of anti-malware checks and tools available in Exchange Online Protection and Advanced Threat Protection for Office 365 are described in Chapter 17 of the Office 365 for IT Pros eBook. Because I read Chapter 17, I knew what to look for in the bad message.

Yippee! An eFile Notification…

Yesterday evening, I traveled to Copenhagen to speak at the European SharePoint Conference. While on the modern (driverless) metro to the Bella Center, I received an odd email telling me that I’d received an “eFile Notification” from someone I didn’t know. Apparently (and very excitingly), an encrypted OneDrive document awaited my attention, if only I’d open the HTML attachment.

Problems with the Message

Any experienced Office 365 user will recognize a couple of problems with this message.

• A HTML attachment from someone you don’t know is always suspicious.
• Office 365 and Outlook.com both support the Encrypt-Only option (and Office 365 now has sensitivity labels) to protect email and attachments. There’s never any need to open a HTML attachment (and be infected) to get instructions.
• OneDrive sharing doesn’t work on the basis of sending people HTML instructions.
• Any message with grammatical or spelling error (like “you will be prompt to”) purporting to come from a company is also suspicious.

In any case, to confirm my suspicions, I looked up the domain that the message supposedly came from and found that keller-services.com is a heating contractor in Texas. Their web site doesn’t use HTTPS, which might be why it was hijacked. In any case, I don’t need heating services and I am not in Texas, so there’s no reason for accepting email from this domain.

Message Headers

The useful Message Header Analyzer (MHA) add-on for Outlook can confirm problems with messages. When I looked at the headers, I found that the real originator of the message was an Office 365 tenant called netorg533059.onmicrosoft.com (MXLookup reports that the email MX record for keller-services.com is managed by ProofPoint). A mismatch between the purported sending domain and the actual domain usually bad. The IP address reported in the header is offline or unreachable too.

I could go on, but decided to simply report the message to Microsoft as a possible (!!!) phishing attempt and let their Exchange Online Protection team work out why the message got through the array of anti-malware checks used to cleanse the inbound stream to Office 365.

But let’s be clear. Although the Office 365 anti-malware checks are very good, the competition between hackers and defenders is ongoing and will continue – and some suspicious email will always get through. Driving user awareness through education about the signs that a message might not be as nice as it seems to be is the backstop for anti-malware.

The array of anti-malware checks and tools available in Exchange Online Protection and Advanced Threat Protection for Office 365 are described in Chapter 17 of the Office 365 for IT Pros eBook. Because I read Chapter 17, I knew what to look for in the bad message.

Find Inactive Distribution Lists Using Message Trace Data

Updated 28 October 2023

Earlier this month, I was asked how to find inactive distribution lists in Exchange Online. We’re often asked questions about why such-and-such a topic isn’t covered in the Office 365 for IT Pros eBook all the time. Sometimes, our questioner is mistaken and the topic is covered (perhaps in a chapter that they don’t expect it to be) and sometimes we simply disagree and think that the topic doesn’t fit or isn’t worth covering. But sometimes we sit up and say “yeah, that should be in the book…” and promptly go to work.

I looked at the Groups chapter, which is where we cover distribution lists, and found that we had punted on the topic by recommending that people run a message trace to find whether anyone was sending messages to a list. That advice was correct, but we gave some practical example of how to approach the problem.

I took a look around the internet to see if anyone had come up with a good way to find inactive distribution lists and couldn’t come up with a good solution. Or at least, one that hadn’t been written years ago and perhaps needed some dusting off and recalibration against today’s Exchange Online. For example, many people assert that Exchange Online message traces can go back 30 days. They can’t. The limit used to be 7 days and it’s now 10. Commercial products like Quadrotech Nova offer good answers, but not everyone wants to pay for the power and sophistication of a full-blown reporting product.

In any case, the solution described below is imperfect and needs more work to be a production-quality answer, but it lays the foundation for someone else to work out the bells and whistles.

A Prototype Solution

Exchange Online does not include a way to find inactive distribution lists, so we must create a solution to find and report these DLs with PowerShell. The key points to remember are:

• A distribution list is active when people use it to address messages.
• Evidence of distribution list activity can be found in the message tracking logs by running a message trace to find events noting the expansion of distribution list memberships.
• Exchange Online keeps message tracking logs online for up to 10 days, after which the information is moved into Microsoft 365 data repositories and kept there for an extra 80 days. If you want to search back further than 10 days, Exchange Online can run historical searches in the background and return CSV files with the results. For the purpose of this exercise, online searches can only look back 10 days to find expansion events.

With these points in mind, we can write a script to collect expansion events from the message tracking logs for the last 10 days and store the results in a table. We can then check the distribution lists in the tenant against the table to discover if we find a match. If we do, we know that the distribution list was used in the last ten days. If not, it’s a candidate to be considered as an inactive DL. Apart from reporting each list as it is checked, the script also outputs the results to a CSV file. The code below is different to the current version, but it’s close enough to demonstrate the idea:

$EndDate = Get-Date
$StartDate = $EndDate.AddDays(-10)
$Messages = $Null
#Office 365 returns pages of message trace data, so we must keep on asking for pages until no more remain
$Page = 1 
Write-Host "Collecting message trace data for the last 10 days"
Do
{
   $PageOfMessages = (Get-MessageTrace -Status Expanded -PageSize 5000 -Page $Page -StartDate $StartDate -EndDate $EndDate | Select-Object Received, RecipientAddress)
   $Page++
   $Messages += $PageOfMessages
}
Until ($PageOfMessages -eq $Null)
# Build an array of email addresses found in the message trace data
$MessageTable = @{}
$Messagetable = ($Messages | Sort-Object RecipientAddress -Unique | Select-Object RecipientAddress, Received)
# Now get the DLs and check the email address of each against the table
[array]$DLs = Get-DistributionGroup -ResultSize Unlimited
Write-Host ("Processing {0} distribution lists..." -f $DLs.count)
$Results = ForEach ($DL in $DLs) {
   If ($MessageTable -Match $DL.PrimarySMTPAddress) {
     [pscustomobject]@{Name = $DL.DisplayName ; Active = "Yes"}
     Write-Host ("{0} is active" -f $DL.DisplayName) -Foregroundcolor Yellow }
   Else {
     [pscustomobject]@{Name = $DL.DisplayName ; Active = "No"}
     Write-Host ("{0} is inactive" -f $DL.DisplayName) -Foregroundcolor Red }
}
$Results | Export-CSV c:\Temp\ListofDLs.csv -NoTypeInformation

Given that message traces give us a limited ten-day window to find inactive distribution lists, this is not a practical technique for a production-quality solution. Nevertheless, the method gives us the basis to develop the technique further into something that might work. For instance, you could run a script every ten days and merge the results over a period of a few months to give a more precise view of inactive and active lists.

You can download the current version of the script from GitHub. The latest iteration updates the custom attribute 15 of any DL deemed to be active with the date and time of the last message sent to the DL.

For more information about distribution lists, see the Groups chapter in the Office 365 for IT Pros eBook. The Mail Flow chapter is the right place to go for information about how to run a message trace.

Protecting Sensitive Email

Let’s assume that you want to make sure that outbound email containing sensitive data is always encrypted using the (relatively new) Encrypt rights management template. Office 365 includes a wide range of default sensitive data types created for data loss prevention (DLP) policies. You can define your own sensitive data types if necessary.

You could, of course, rely on users to know when they need to apply the Encrypt template to messages (via OWA and Outlook, but not mobile clients), but it’s usually better to make the process automatic. You can do this with a transport rule or a DLP policy. Both can be created through a GUI (the Exchange Administration Center for a transport rule and the Security and Compliance Center for a DLP policy), but where’s the fun in that?

Using a Transport Rule for Encryption

Any sensitive data type known to the tenant can be used in a transport rule to identify messages for protection by including it in the MessageContainsDataClassifications parameter. Here’s a simple PowerShell example that looks for six different sensitive data types. If any are found in a message, Exchange Online applies the Encrypt template.

New-TransportRule -Name "Encrypt external email with PII content" -SentToScope NotInOrganization -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -Mode Enforce

Using a DLP Policy for Encryption

Alternatively, you can create a DLP policy that applies a template when messages are shared outside the organization. Two steps are needed to do this in PowerShell. The first creates a DLP policy; the second creates the rule to encrypt email with the same set of sensitive data types specified for the transport rule and attaches the rule to the policy.

New-DlpCompliancePolicy -Name "Encrypt external sensitive mail" -ExchangeLocation "All"

New-DlpComplianceRule -Name "Encrypt external email with PII content" -Policy "Encrypt external sensitive mail" -AccessScope NotInOrganization -EncryptRMSTemplate "Encrypt" -NotifyUser "LastModifier" -NotifyPolicyTipCustomText "This email contains sensitive PII information and will be encrypted when sent." -NotifyEmailCustomText "This email contains sensitive PII information and will be encrypted when sent." -ContentContainsSensitiveInformation @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"})

Choose How to Encrypt

As you can see, Office 365 offers several ways to apply encryption via policy to outbound email. It’s important that you choose either transport rules or DLP policies to protect sensitive data as it is easy to cause confusion if protection is applied for the same content using multiple methods.

We cover transport rules in Chapter 17 of the Office 365 for IT Pros eBook, DLP policies in Chapter 22, and rights management templates in Chapter 24.  You might say that we have this topic covered…

No Method Available in Office 365

Rather curiously, Office 365 has never included an out-of-the-box method to migrate a distribution list from an on-premises Exchange organization to Exchange Online. When an on-premises organization is synchronized with Exchange Online in a hybrid deployment, the suggested method is to remove the distribution list from on-premises and recreate it as a brand-new object in the cloud. For anything but simple lists with just a few members, this is a tiresome process, but it reflects the fact that transferring a distribution list to the cloud can be quite complex. Among the reasons why this is so include:

• The owner(s) of the distribution list might not have their account(s) in the cloud. An on-premises user cannot manage a cloud-based distribution list.
• Objects for mail-enabled members of the distribution list might not exist in the cloud. For example, a mail contact in the on-premises environment might not be synchronized to the cloud.
• The distribution list might hold other distribution lists.
• The proxy addresses for the on-premises distribution list must be transferred to the new list.
• Some properties of distribution lists refer to other directory objects that must exist in the target environment before they can be used. For example, the property controlling the ability of users to send email on behalf of the list.

Scripting a Solution

It is possible to write a PowerShell script to concurrently connect to Exchange on-premises and Exchange Online and perform the processing to transfer a distribution list. The script must:

• Check that all the prerequisites are satisfied for the transfer to go ahead. For example, are all the members of the list known in the cloud.
• Create the target distribution list in Exchange Online.
• Read information about the source distribution list from Exchange on-premises and update the properties of the target distribution list.
• Assign a new proxy address to the source distribution list and transfer it to the target distribution list.
• Update the membership of the target distribution list with the membership of the source list.
• Hide the source distribution list from address lists so that the only list that is visible to users is the target. Eventually, if the transfer worked and no problems are found, the old list is removed.

Tim McMichael of Microsoft has shared an example of a migration script for distribution lists in GitHub (the documentation is here). Even though Tim’s a very nice guy and ultra-competent, as with any script, you should test it carefully and adapt where necessary to meet the needs of your deployment.

Migrating Dynamic Distribution Lists

Things aren’t quite so straightforward for dynamic distribution lists. These objects are supported by both Exchange Server and Exchange Online and both work by querying a directory to find recipients for a message. The big difference is the directory used. Exchange Server uses Active Directory while Exchange Online uses Azure Active Directory. In light of this fact, the easiest option is not to synchronize on-premises dynamic distribution lists to Azure AD and recreate new equivalent dynamic distribution lists in Exchange Online.

We cover distribution lists and how to manage these workhorses of Exchange in Chapter 7 of the Office 365 for IT Pros eBook.

Talking about Email and Teams

On October 17, I had the opportunity to speak at the Modern Workplace Conference at the Microsoft conference center in Paris. My topic was a discussion about whether Teams can replace email. I’m pretty definite that Teams can’t, but it certainly can replace some of the email traffic that circulates within Office 365 tenants today. The percentage of traffic that moves to Teams will be higher in some organizations than others, as it all depends on culture, training, and the flows of communication. For instance, a company that has a high percentage of its traffic going to external parties won’t see that traffic drop through Teams.

As always, it’s best to try and extract most value from all the technologies at your disposal. That means good preparation, intelligent choices of tools, user education, and ongoing management. Given that these factors are in place, I think Teams and email can live together well and complement each other in most organizations. But if Teams is launched within a company with poor preparation and no user training, it’s unlikely to be successful. At least, not as successful as it can be.

A Sketch Note

I am indebted to Luise Freese for coming to the session in Paris to generate a “sketch note” from my comments.

And the Presentation

For those wanting my slides, here’s a copy of the deck Can Teams Replace Email for your downloading pleasure.

Editor’s note: the deck is updated to reflect the content presented at the European Collaboration Summit in Wiesbaden, Germany on May 28, 2019.

For more information about Teams, head to Chapter 13 of the Office 365 for IT Pros eBook, where you’ll find 80+ pages of practical and insightful information to help plan your deployment.

A New Default for Room Mailbox Automatic Processing

Today, Microsoft published Office 365 Message Center update MC151582 to tell tenants that from November 15, 2018, new room mailboxes will be created with their AutoProcessing property set to AutoAccept. Previously, the default value for the property was AutoUpdate.

The documentation for the Set-CalendarProcessing cmdlet explains the values as:

• AutoUpdate: Only the Calendar Attendant processes meeting requests and responses. Meeting requests are tentative in the calendar until they’re approved by a delegate. Meeting organizers receive only decisions from delegates.
• AutoAccept: Both the Calendar Attendant and resource booking attendant are enabled on the mailbox. This means that the Calendar Attendant updates the calendar, and then the resource booking assistant accepts the meeting based upon the policies. Eligible meeting organizers receive the decision directly without human intervention (free = accept; busy = decline). [New Default]

A Little PowerShell Error

The Message Center update includes some PowerShell to help tenant administrators check the value assigned to existing room mailboxes. Unfortunately, there’s an error in the code as it omits a call to the Get-CalendarProcessing cmdlet. To see the values, you need to run this PowerShell code:

Get-Mailbox -RecipientTypeDetails @("Equipment","RoomMailbox") -ResultSize unlimited | Get-CalendarProcessing

Identity                  AutomateProcessing
--------                  ------------------
Room 104                  AutoUpdate
Room 101                  AutoAccept
Room 102                  AutoAccept
Room 103                  AutoAccept
Las Vegas Conference Room AutoAccept
San Francisco Room        AutoAccept
Nikon Room                AutoAccept
VCR Recorder              AutoUpdate

Updating Existing Room Mailboxes

If you want to update existing rooms to the new default, run this PowerShell code:

Get-Mailbox -RecipientTypeDetails @("Equipment","RoomMailbox") -ResultSize unlimited | Get-CalendarProcessing | Where-Object {$_.AutomateProcessing -eq "AutoUpdate"} | Set-CalendarProcessing -AutomateProcessing AutoAccept

And as the update says, make sure that any scripts you use to create new room mailboxes specify whatever value you want for this property. Room mailboxes created from the Microsoft 365 admin center have AutomateProcessing set to AutoUpdate.

The Office 365 for IT Pros eBook covers this kind of information in Chapter 5, which is where we get to grips with Exchange Online mailboxes.

Questions, Questions, Questions

Following the announcements about Exchange 2019 at Ignite, people are processing what they heard and seeking clarifications about some details. One of those questions is whether a free hybrid license will be available for Exchange 2019. The answer is no. You can certainly assign a license to an Exchange 2019 server and have it host the hybrid configuration wizard, but the free license is only available for earlier versions.

Volume Licensing for Exchange 2019

Microsoft made recent changes to the licensing of hybrid servers, but the hybrid license for Exchange 2019 is linked to the decision to only license Exchange 2019 through volume licensing. In other words, the only place you’ll be able to download Exchange 2019 software is from Microsoft’s volume licensing site. This includes future cumulative updates for Exchange 2019.

This change in direction is linked to Microsoft’s focus on Exchange 2019 as the mail server for large enterprises who don’t want to move to the cloud. Concentrating on volume licensing is certainly a way to serve large enterprises, but it might be less convenient for smaller organizations. Microsoft has been made aware of this concern and is considering how best to resolve the issue.

For more information about hybrid connectivity, read the Companion Volume for the Office 365 for IT Pros eBook. We bundle the Companion Volume with the main book if you buy the PDF/EPUB version, and it’s available separately for Kindle.

Bright, Shiny, and New

Today’s Petri.com article covers the new user interface for Outlook Web App (OWA). As with any software that’s under active development, there are some glitches and missing features, but overall the new design looks solid.

In some ways, this is to be expected because Microsoft tried out the new UI framework when it launched the new interface for Outlook.com. As you probably know, Outlook.com and Exchange Online share the same infrastructure, so in one sense it is relatively easy for Microsoft to transfer the work to the commercial platform. However, even though many features are common to both platforms, the functionality of OWA differs from Outlook.com, so considerable effort is needed to make sure that all features support the new framework.

Open Source Components

Some observers have claimed that the new interface is based on React.js. It’s absolutely true that the new OWA uses React.js, but it’s equally true that many other open source components are used too.

The new OWA is in targeted release for now. As it matures and functionality is complete, it will move into general availability. Once that happens, probably close to the end of 2018 or early 2019, you’ll have about 60 days to make the transition from the old UI. The extended period is intended to allow tenants to prepare help desk, documentation, and anything else needed to support users.

Chapter 10 is where we talk about clients in the Office 365 for IT Pros eBook. Then again, clients pop up all through the book, so there’s plenty to read.

A Recommendation, Not a Restriction

On September 25, I posted an article on Petri.com about the details Microsoft released at Ignite about Exchange 2019, due for release soon. In the text, I said: “The minimum memory recommendation for Exchange 2019 is 128 GB, up from a wildly unrealistic 8 GB previously.” This statement promptly created a stir and many questions flowed into the Exchange product group to ask if 128 GB was really needed to run the new server.

Well, if you read the statement again, you see that the word “recommendation” is prominent. You will still be able to run Exchange 2019 on servers equipped with less memory, but the strong recommendation is that you should give Exchange enough memory to cache as much data as possible. Caching data results in better all-round server performance with faster mailbox access and searches, but the amount of memory used depends on the load you put on the server.

Different Memory Needs

Clearly, a server handling one hundred mailboxes does not need 128 GB and you only need to equip the server with enough memory to handle the anticipated load. That amount might be 32 GB or 64 GB or 128 GB. It all depends on the load, and Microsoft will continue to provide support to customers who deploy Exchange 2019 on servers equipped with less than 128 GB. However, if you have less than the recommended minimum and you run into performance issues, I think it fair to say that you will not find a sympathetic shoulder to cry on if you call support.

The important idea that the Exchange product team wants to get across to customers is that modern software consumes a lot of memory. Users want high performance, they consume more data than ever before, and servers offer more functionality. All of these aspects must be paid for in CPU, I/O, and memory, so do yourselves a favor and make sure that your brand-new Windows 2019 Server Core box that you prepare for Exchange 2019 comes with enough memory to keep email flowing.

Tools to help people model server configurations for Exchange 2019 are not yet available, but you can expect this gap to be filled in the near future as server vendors begin to measure Exchange 2019 performance on their hardware. Of particular interest is how server vendors will deal with the metacache, the SSD-based fast cache that holds up to 10% of database content (see more information here).

And the Link to Office 365?

Why does a blog about Office 365 care about Exchange 2019? Well, Microsoft runs 175,000 mailbox servers inside Exchange Online, and while those boxes run different software to what on-premises customers do, they follow the guideline of having enough memory to do their work. The Exchange Online servers have been running the metacache for about a year now to allow Microsoft to understand how best to tune its operation before releasing the feature to on-premises customers in Exchange 2019. Habits proven in the cloud are worth noting for on-premises deployment…

Auditing Deletions

Updated: March 2021

Ever since Microsoft introduced the current mailbox auditing mechanism in Exchange 2010 (an earlier version in Exchange 2007 took a different approach), it has been used to answer the question of “who deleted that message,” an issue that usually crops up when a delegate removes items from someone else’s mailbox or a shared mailbox and won’t admit their action.

Ingestion and Normalization

Microsoft enables mailbox auditing for all Exchange Online mailboxes for accounts with Office 365 E3 and E5 licenses. Audit records are not generated for accounts with other licenses. The audit records flow through a normalization process before the records are ingested into the Office 365 audit log. Normalization makes sure that the Exchange records have the same format as records from other workloads.

Searching for Email Deletions

You can look for delete operations through the audit log search in the Compliance Center, but it’s usually more convenient (and faster) to use PowerShell and run the Search-UnifiedAuditLog cmdlet.

Here’s an example that searches for hard and soft delete operations and extracts information from the JSON payload which holds the details of the action performed. In this case, we want to find who deleted a message. The results are piped to the Out-GridView cmdlet to view on screen.

$StartDate = (Get-Date).AddDays(-90); $EndDate = (Get-Date) 
[array]$Records = (Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Operations "HardDelete", "SoftDelete" -ResultSize 5000) 
If (!($Records)) { Write-Host "No deletion records found."; break } 
Else { 
 Write-Host "Processing" $Records.Count "audit records..." 
 $Report = [System.Collections.Generic.List[Object]]::new() # Create output file  
 ForEach ($Rec in $Records) { 
    $AuditData = ConvertFrom-Json $Rec.Auditdata 
    If ($AuditData.ResultStatus -eq "PartiallySucceeded") {
        $EMailSubjects = "*** Not deleted by" + $AuditData.ClientInfoString + " ***" }
    Else {
        $EmailSubjects = $AuditData.AffectedItems.Subject -join ", " }
    $ReportLine = [PSCustomObject] @{ 
      TimeStamp          = Get-Date($AuditData.CreationTime) -format g 
      User               = $AuditData.UserId 
      Action             = $AuditData.Operation 
      Status             = $AuditData.ResultStatus 
      Mailbox            = $AuditData.MailboxOwnerUPN 
      "Message Subjects" = $EmailSubjects
      Folder             = $AuditData.Folder.Path.Split("\")[1] 
      Client             = $AuditData.ClientInfoString } 
    $Report.Add($ReportLine) }
  } 
$Report | Sort Mailbox | Select Timestamp, Action, User, Mailbox, "Message Subjects", Folder | Out-GridView

The formatted records are placed in the $Report list. You can slice and dice the records to meet your needs, or export the data to a CSV file and then format it with Excel or Power BI. For example:

$Report | Export-CSV -NoTypeInformation -Path c:\temp\ExchangeMailboxDeletes.csv


If you need to extract the records for a particular user or shared mailbox, apply a filter to the $Report list. For instance, to find just the records for a shared mailbox with a specific primary SMTP address, use a command like this to find the records for a target mailbox and pipe them to the Out-GridView cmdlet.

$Report | ?{$_.Mailbox -eq "BookBuild@office365itpros.com"} | Out-GridView

Figure 1 shows the result.

Another variant on the theme is posted in this article. The script used here is available in the Office 365 for IT Pros GitHub repository.

For more information about the Office 365 audit log and how to configure Exchange mailbox auditing, read Chapter 21 of Office 365 for IT Pros. If you want to read more about reporting from the mailbox audit log rather than the Office 365 audit log, it’s in Chapter 3 of the companion volume.

Updated 15 September 2021

Note: Formal support from Microsoft for the Search-Mailbox cmdlet ceased on July 1, 2020. See this post for more information. As of September 15, 2021, the cmdlet is still available.

In a previous post about the Search-Mailbox cmdlet, I discussed how the cmdlet is restricted to only processing Exchange user and shared mailboxes. Some questions came in about how easy is it to delete items from mailboxes with Search-Mailbox. The answer is that it’s terrifically easy.

Blowing Messages Away

For example, this command searches all user mailboxes to find messages with “Spam Email” in the message subject and deletes any matching items. The deleted items are irrecoverable.

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Search-Mailbox -SearchQuery {Subject: "Spam Email" Received:1-Apr-2018..1-Jul-2024} -DeleteContent

A much more comprehensive parameter-driven example is described in this article. The script used in the article can search based on message subject, body text, author, and date range, which is a more realistic example of the kind of thing that administrators need to do.

It’s easy to see how mistakes could be made and many items removed from user mailboxes in the twink of an eye. Well, Search-Mailbox doesn’t run so quickly, so maybe several twinks of the eye.

The Same Problem a Long Time Ago

Having a function that can wreak havoc on mailbox contents is not unique to Exchange. In the past, when I worked on Digital Equipment Corporation’s ALL-IN-1 Office system in the early 1990s, we had a problem with an internal system in Turin, Italy, when the administrator ran a script to do mailbox maintenance. He thought that any mail older than a year would be removed, but a mistake in syntax meant that every single message in every single mailbox was removed. No one realized until Monday morning when howls of pain erupted after people discovered what had happened to their mailboxes.

In those days, we could restore mailboxes (and the databases used to connect messages together) from large 1600 bpi magnetic tapes like those shown above. Today, if you run Search-Mailbox and use the DeleteContent switch to remove items from Exchange Online, you won’t have any type of backup to fall back on – unless you buy a third-party cloud backup service.

Be careful!

Read more about Search-Mailbox in Chapter 6 of Office 365 for IT Pros.

A New Way to Block Forwarding of Important Meeting Requests

Microsoft has started to roll out a new feature in Exchange Online, OWA, and Outlook 2016 (click to run) to stop people forwarding meetings when meeting organizers don’t want them to do so. You know the scenario: someone sets up an interesting meeting with a well-chosen list of attendees to figure out how to solve a problem and next thing you know, 50 people turn up to meet in an overcrowded room because some of the invited attendees decided to pass on the meeting notification to their colleagues.

By default, meetings can be forwarded, but now organizers have a new option in Outlook 2016 and OWA (see below) to disable forwarding of their meetings.

When an attendee opens the meeting request, the client disables the forward option.

Of course, an attendee could create their own meeting request and cut and paste the meeting details into that request and send it to whomever they like, but that’s probably too much work. This fix cuts out casual forwarding, and that’s what it is intended to do.

Supported Clients

The new feature is now available in OWA, Outlook 2016 (click to run version 1808 – I see it in client build 10730.20102). Microsoft says that it is coming to Outlook for Mac soon. It is not available in Outlook 2016 MSI clients. Only users with Exchange Online mailboxes can blocking the forwarding of meetings.

Many Unsupported Clients

Obviously, there’s lots of unsupported clients in use today. An unsupported client doesn’t have the user interface to disable meeting forwarding or to stop someone forwarding a meeting that the organizer has blocked. It therefore follows that people who receive blocked meetings might try to forward them.

To make the block more effective, Microsoft has included a check in the code that submits messages to the Exchange transport service to validate that someone has the right to forward a meeting request. To have that right, the submitter must be the meeting organizer or a delegate of the meeting organizer. Users assigned editor access to the organizer’s calendar can also forward meetings, but only if they are granted that right under the new calendar sharing model. Those with editor rights granted under the old model can’t forward meetings.

If the submitter has the right to forward a meeting, transport accepts and processes the message. If they don’t, transport politely declines the message and issues a non-delivery notification.

This block is built into Exchange 2016 (latest cumulative update), Exchange 2019, and Exchange Online, so anyone with a mailbox connected to one of those servers respects blocks set on meeting forwarding. If someone using an older Exchange server or a non-Exchange server receives a meeting request, they can anything they want with it because the block isn’t available.

The formal Microsoft support article is available online. We cover calendar sharing in Chapter 6 of Office 365 for IT Pros. And if you’re at Microsoft Ignite, check out session BRK3146 to discover all the new stuff that’s happening in Outlook calendaring.

Using Solid State Disks with Exchange

One of the more interesting sessions for Exchange aficionados to attend at the Ignite 2018 event is BRK3130 – Email Search in a Flash. It’s a 45-minute session at 4:30pm on Wednesday, September 26 that explains how Microsoft uses solid state disks to speed access to hot data, specifically the search indexes (the “big funnel” initiative) that now exist inside Exchange Online and Exchange 2019 mailboxes.

The reason why this topic is interesting is that it marks the first time that Microsoft has embraced SSD technology for Exchange. Although this might seem that Microsoft is reversing course away from their decade-long campaign to concentrate on cheap JBOD disks for mailbox storage, this session will explain how Exchange 2019 and Exchange Online bring SSD and JBOD together to make the Information Store even faster. Obviously, this is an important point for Exchange administrators to understand as mailboxes swell larger and larger (and the search indexes become larger as a consequence). Remember, it’s not just email that Exchange stores in mailboxes these days.

I can’t say too much more because of the constraints of the NDA I’ve signed with Microsoft. If you’re not at Ignite, you can catch the session via live streaming (all Ignite sessions are live streamed this year) or as a recording later.

There’s tons more information about Exchange Online, mailboxes, and all that stuff in Office 365 for IT Pros, including the companion volume that you get with the main book.

Stop Password Sharing Now

A ZDNet report described a number of bad security habits in small to medium companies, among which was the headline statistic that 22% of business leaders share their email passwords with co-workers or assistants.

Much of the success of Office 365 is fueled by small to medium businesses, who find it much easier to use cloud services than to deploy their own Exchange and SharePoint servers (a point underlined by attacks on on-premises Exchange servers) . I hope that 22% of business leaders who use Office 365 don’t share their passwords. It’s old-school thinking that doesn’t reflect the reality of today. Sharing passwords is bad practice and it is utterly unnecessary.

Knowing someone’s account password gives you access to much more than their email. You can then log onto Teams and read the conversations in the private teams that person belongs to, or open protected SharePoint documents, or read whatever’s in their OneDrive for Business account, or take part as that person in Yammer conversations. As people move more data into cloud services, knowing personal passwords becomes the key to access all that data rather than just a mailbox.

The sad thing is that no need exists for anyone to ever share the password to their account. Mailbox delegation, shared mailboxes, Microsoft 365 Groups, and Teams all provide other ways for senior people to collaborate effectively and securely with their assistants.

No matter what size your company is, it’s time to stop the awful habit of password sharing now. Make sure that none of your users share passwords, and if you find that some do, be kind but firm and help them understand why what they are doing is so dreadfully wrong.

Better Sharing Options Exist

If people argue back and say that sharing passwords is the only way they can collaborate with their assistants, take the opportunity to prove that they are dead wrong. Clinging to techniques that worked in the 1980s is not a recipe for good IT security or successful collaboration. Point out that a variety of methods exist in Office 365 to allow better and more secure sharing:

• Delegate access to folders in their mailbox, including the inbox and calendar, to allow assistants process email on their behalf. Delegation is very straightforward and doesn’t need the delegator to share passwords.
• Have their email sent to a shared mailbox where it is processed by their team. Any important email can be sent to a separate private mailbox used by the executive for their most personal and sensitive communications. The private mailbox is hidden from the GAL and only available to certain senders. You can define a list of approved senders (use a distribution list for maximum flexibility) for the mailbox or use moderation to control what email gets through. Using a mix of shared/private mailboxes for executive communications is often used to protect executives in large corporations, but as shared mailboxes are free in Office 365, there’s no reason why the same technique can’t be used in smaller companies.
• If they prefer, they could use an Microsoft 365 group instead of a shared mailbox. Microsoft 365 Groups are included in many Office 365 subscriptions and the email that arrives in the group can be responded to by assistants. The benefit of using a group is that it comes along with a SharePoint team site, so it’s easy to handle shared documents. The group can also be used with Planner. Again, the executive can have a private mailbox for their most sensitive and secure email.
• If the executive wants to have a secure place to discuss matters with their assistants, they could also consider using a team instead of a group and take discussions out of email. The executive could send messages needing action to different channels in the team (like a “Priority” channel or channels named after projects, or a private channel shared only between the executive and their assistant). The downside of using Teams is that you cannot send email from a team (or on behalf of a user from a team), so outbound communication will still have to be processed by email.
• Sensitivity labels with information protection can stop unauthorized access to confidential documents and email even if they are leaked or shared inappropriately.

Microsoft 365 Groups and Teams both support shared calendars, so supporting the executive’s calendar is not a problem. Outlook for iOS and Android support access to shared mailboxes and Microsoft 365 Groups, and Teams has its own mobile client, so there’s no problem getting to information when on the road.

Deploy MFA Now

Using basic authentication to connect to Exchange Online exposes mailboxes to attack, including business email compromise attacks. And accounts that are only protected by passwords, especially those shared with other people, are more likely to be pwned. Every account used by senior personnel and those used by administrators should be protected by MFA and you should check the MFA status of accounts periodically.

After you use MFA to protect an account, knowing passwords is not enough for others to access the account. They need to have access to the second authentication method, like a mobile phone. Although it’s conceivable that executives might give their mobile phone to their assistants to allow access to their email, implementing MFA in a tenant is an excellent way to begin eradicating password sharing.

Break Old Habits

Executives have different modes of working and the transition from email-based, password-sharing access to mailboxes will be difficult for some (and their assistants). It is sensible to sit down with the assistants to understand the ebb and flow of information and how the executive processes work to come up with the right solution for them. The good thing is that Office 365 offers different highly functional options. The challenge is to pick the right one for the person to help them break the horrible and dangerous habit of password sharing.

The Office 365 for IT Pros eBook goes into great detail about all these topics. Isn’t it worth your while having access to the best and most up-to-date information about Office 365?

Update: On September 6, Microsoft included a note in their “Helping customers shift to a modern desktop announcement” to say that they are extending Office 2016 support to October 2023. They say:

“We are modifying the Office 365 services system requirements related to service connectivity. In February, we announced that starting October 13, 2020, customers will need Office 365 ProPlus or Office 2019 clients in mainstream support to connect to Office 365 services. To give you more time to transition fully to the cloud, we are now modifying that policy and will continue to support Office 2016 connections with the Office 365 services through October 2023.”

I guess pressure from users helped Microsoft make the right decision…

Confusion Reigns

Microsoft statement that “Effective October 13th, 2020, Office 365 will only allow Office client connectivity from subscription clients (Office 365 ProPlus) or Office perpetual clients within mainstream support to connect to Office 365 services” in a post covering system connectivity for Office 365 is causing some concern and confusion in the user community. The same statement is made in System requirements for Office (365).

The problem is the word “allow” as it implies that Microsoft will deploy a block within Office 365 to prevent older clients from connecting to services like Exchange Online. As it happens, Office 2016 exits mainstream support on the same day, which then implies that the perpetual-use version of Outlook 2016 would be blocked.

Please Use Office ProPlus

Microsoft is certainly very keen that customers use up-to-date clients when they connect to Office 365. Their view is straightforward: online services are designed to be used with the latest clients and can’t be guaranteed to work as well with older clients. New features won’t surface in the older clients and the older clients don’t support newer protocols. We see this too in the recent announcement sent to Office 365 customers to inform them that a new UI is coming for Outlook for Windows (Office 365 roadmap 26542), but only the click to run version. The new UI features:

• A simplified ribbon: Users will have the option to collapse the ribbon into a single row of most commonly used commands. The ribbon will also be customizable where users can pin and remove commands from the ribbon based on their preferences and expand the ribbon back to the multi-layered, classic ribbon at any time. -Additional user experience updates to the folder pane, message list, message, and calendar read/compose screens. The updates include typographical, alignment and use of text color to simplify the experience, making it easier to use and more efficient for customers.

All in all, Microsoft would very much like Office 365 tenants to use the click to run version of Office, or Office 365 ProPlus.

The Message to Partners

Partners who attended Microsoft’s Inspire conference in Las Vegas in July 2018 received the message that ProPlus or Office 2019 is needed to connect to Office 365 after October 2020. The slide shown below has appeared in several LinkedIn posts that I have seen, accompanied in one case by a note that the Microsoft speaker spent about ten seconds reviewing the change.

Customers Have Older Software

In many cases, Office 365 customers have many older clients deployed and might not see the logic of paying Microsoft more money for a higher-priced Office 365 plan that includes the Office clients when they have a perfectly good version of Office 2013 or Office 2016 installed on their desktops. If these customers don’t use the new features exposed in the click to run version (like the Encrypt Only feature in Outlook 2016), then why update?

This is a dance that’s been going on for years. Microsoft brings out a new version of Office roughly every three years and promptly tries to convince customers to upgrade. Some do, some don’t. More update quicker these days because of the click to run version, but there’s still people clinging on to their favorite old version of Office.

Support Rules

In any case, the word “allow” actually means “support,” or so we hear from sources within Microsoft. In other words, you’ll still be able to connect an older Office client to Office 365 after October 13, 2020, but if you run into problems you shouldn’t expect any sympathy or support from Microsoft.

There’s no word yet when Microsoft will change the wording of their statement. I expect them to because of the obvious confusion it has caused, but we shall have to wait and see.

This is the kind of stuff that we follow assiduously in Office 365 for IT Pros. Read all about Office 365 clients in Chapter 10. We’ll keep that chapter updated as this topic evolves.