Summarize Attachment Feature is an Example of New Features Needed to Maintain Customer Interest

Introducing a new technology is hard. The great expectations created at the initial launch soon meets the hard reality of deployment and things don’t get better until the technology has had time to bake. This is as true for Microsoft 365 Copilot as for any other major technology. I see people questioning whether the $30/user/month really delivers any benefits, with real concern over whether people use any of the purported time saved through Copilot interventions doing anything more valuable than drinking more coffee.

News that the U.S. Better Business Bureau forced Microsoft to change some of the claims it makes about how Microsoft 365 Copilot affects user productivity doesn’t help the case for AI-based assistance. And lukewarm or mildly enthusiastic (but independent) reports about Copilot usage in organizations, like the recent UK Government report based on a 3-month trial for 20,000 employees don’t bolster the case much either.

All Microsoft can do is continue to push out updates and new AI-based features to keep customer interest while Copilot matures to become more useful in day-to-day activities. The result is a flood of new Copilot-related features, not all of which seem valuable except in specific cases. I don’t know whether AI-informed People Skills will become popular (some HR professionals that I know like People Skills a lot). Those in the Power Platform world (now with 56 million monthly active users according to data made available at Microsoft’s FY25 Q3 results) see lots of changes to make Copilot agents more productive. I do like the ability to upload documents to agents for the agents to reason over.

Summarizing Attachments

All of which brings me to the update described in message center notification MC1073094 (13 May 2025, Microsoft 365 Roadmap item 475249). It’s an example of a recent Copilot enhancement to help users process “classic” email attachments faster. Even though cloudy attachments are preferable in many respects, many people still send files instead of links.

Copilot has been able to summarize cloudy attachments for email for quite a while. Now, when a message with one or more classic file attachments arrives, users with a Microsoft 365 license see a new summarize option for Office and PDF attachments. The feature is available in the New Outlook for Windows, OWA, Outlook mobile, and Outlook for Mac, but not for Outlook classic. Microsoft is rolling out the update now with estimated completion by late August 2025.

Figure 1 shows the general idea. A Word file is attached to a message. Clicking the summarize option from the drop-down menu beside the attachment causes Copilot to create and display the summary for the file inside the Summary by Copilot panel (or card). If a message has multiple file attachments, the summarize option must be invoked separately.

Copilot cannot process encrypted attachments (using sensitivity labels or another encryption mechanism).

No Archived Messages

My archive mailbox is full of attachments from long-forgotten projects, including files related to some legal cases that I was involved with. I was curious to see what sense Copilot might extract from some of the PDFs and Word documents from those cases. Oddly, Outlook won’t summarize any of the attachments for messages stored in an archive mailbox. To generate a summary for these files, you must open download and open Office files in a desktop or web app and use the Copilot options available in the app.

Thinking about why this might be so, I guess the logic is that attachments for archived messages probably aren’t of very high interest, and if someone goes to the trouble of finding an archived message, they have a purpose for doing so and won’t mind opening attachments to view content. On the other hand, I could be overthinking things and Microsoft simply designed the feature to work only with messages from the primary mailbox.

The Value of Small Changes

Over my many years of work, I cannot say how many emails I have received with file attachments. Being able to see a quick summary of an attachment is a good example of how AI can be effective. The feature works well because the AI has just one file to process, so it’s unlikely that hallucinations or other issues will occur. You might disagree with points made in the summary, but having the summary is a timesaver and a great starting point for understanding whether a file contains anything important.

Another example of a small but interesting change is the ability to create a meeting from an Outlook email thread (MC1090693, 9 June 2025, Microsoft 365 roadmap item 494154). The idea is that Copilot scans an email thread to determine the topic for a meeting and its participants and creates a meeting invitation ready to go. This kind of thing doesn’t need AI because existing Graph APIs can do the work, but Copilot integrates the work into a new Schedule with Copilot option (only for email threads with sufficient data to base a meeting upon). According the roadmap item, this feature is for the mobile clients, but I bet it will be available in the new Outlook and OWA too.

In the overall scheme of Copilot, delivering Outlook features to make small tasks easier is not important. However, changes that reduce friction for users are important and collectively a bunch of changes like this might just be enough to convince an organization that they really can’t live without Copilot.

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.

Force Two-Click Confirmation to View Email Protected by Sensitivity Labels

Recently I noticed that OWA behaved differently when previewing email protected by sensitivity labels. Because it’s an online client, OWA has always been able to seamlessly retrieve the authorization to open and display protected messages from the rights management service. Now a message said that organization policies mandate clicking “View message” to access the email content (Figure 1).

It’s no big deal to comply with the demand for the extra click, but what organizational policies are at work here?

The New Setting for Two-Click Confirmation

The answer lies in the Exchange Online organization configuration, specifically the TwoClickMailPreviewEnabled setting. In my tenant, the setting is True, meaning that it’s enabled and forcing OWA to demand the extra click.

But here’s the thing. According to message center notification MC1041456 (26 March 2025, Microsoft 365 roadmap item 483883), the two-click requirement to view protected messages rolled out to general availability in early April 2025 and should be now be complete worldwide. The notification mentions encrypted emails. I have no idea if the feature extends to messages protected with S/MIME or another type of encryption other than Purview sensitivity labels. I hadn’t seen the behavior in OWA before because I’ve been using the new Outlook for Windows. According to MC1041456, the setting should affect that client too, but it doesn’t. The new Outlook ignores the TwoClickMailPreviewEnabled setting and opens protected messages without as much as a brief pause (Figure 2). Perhaps the client is awaiting an update to respect the setting.

The TwoClickMailPreviewEnabled setting doesn’t affect Outlook classic. That client uses a different mechanism to fetch authorization to open protected messages (to allow Outlook to work offline).

Configuring Two-Click Confirmation

A mismatch between documented setting and client behavior isn’t the only thing that’s odd about the information contained in MC1041456. First, the text refers to the setting being in the Microsoft Azure directory. It’s not. The setting is in the Exchange organization configuration. I’m not saying that the setting doesn’t exist somewhere in Entra ID (which I assume the text refers to), but the instructions given to maintain the setting use Exchange Online cmdlets.

MC1041456 asserts “By default, the two-click setting is off.” I checked by running the Get-OrganizationConfig cmdlet and found that the setting is true (enabled):

Get-OrganizationConfig | fl two*

TwoClickMailPreviewEnabled : True

Obviously, somewhere along the line between the message center notification appearing and now the setting had been changed, probably by me.  To reset the setting and remove the requirement for double clicks, I ran:

Set-OrganizationConfig -TwoClickMailPreviewEnabled $false

(MC1041456 refers to Boolean values. You can use $false or 0 to update the setting).

Prompts to use OneDrive

When checking out two-click confirmation, I noticed that both OWA and the new Outlook nag users to use OneDrive to share files rather than uploading copies of files as attachments (Figure 3). This is the effect of MC1053121 (last updated 15 May 2025) to have the Office apps prompt users to make more use of OneDrive. The update is now generally available. I don’t like this kind of nagging and recommend that organizations take the time to review the information in MC1053121 and consider if you want to block the nagging.

Two-Click Confirmation Can be Valuable

Microsoft doesn’t give any clues why they think it is a good idea to “require user confirmation before allowing access to encrypted emails.” My assumption is that the reason has to do with privacy. No one wants to have a confidential message pop up on screen when a chance exists that the information could be read by someone else.

However, in other situations where people have grown used to reading confidential messages without hindrance, they might find two-click confirmation a tiresome restriction on their workflow. The bad thing about the feature is that it’s either on or off for an entire tenant without any ability to grant exclusions.

Forcing the double click confirmation allows the recipient to wait until they’re sure that no one can look over their shoulder or otherwise see the content before going ahead. The volume of notifications that flood into tenants mean that features like this can go by without being noted by administrators. If administrators don’t know about a feature, it can’t be used. And that’s a bad thing.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Make Sure that Users Can’t Download Copies of Attachments to Unmanaged Devices

A recent encounter with David Los in Microsoft’s HQ in Redmond reminded me of a relatively unknown feature of OWA mailbox policies that might be of interest as the new Outlook for Windows progresses. In October 2018, David wrote about how to combine a setting in a OWA mailbox policy with an Entra ID conditional access policy to block the download of attachments on untrusted (unmanaged) devices. It’s a similar idea to the SharePoint Online’s block download access policy.

Fast forward seven years and OWA mailbox policies control many aspects of how the new Outlook for Windows work, so let’s see if the setting works as well for it as it does for OWA.

Updating the Conditional Access Setting for an OWA Mailbox Policy

The magic starts with the ConditionalAccessPolicy setting in a OWA mailbox policy. The values of the setting can be:

• Off (default): Exchange Online doesn’t attempt to apply a CA policy.
• ReadOnly: Users can’t download attachments to make local copies (which means that they cannot use the Office apps to edit files). They can view attachments in the browser.
• ReadOnlyPlusAttachmentsBlocked: User cannot view attachments at all.

To set the block in the OWA mailbox policy, sign into the Exchange Online management PowerShell module with an account holding the Exchange administrator role and run the Set-OWAMailboxPolicy cmdlet to update an OWA mailbox policy. I don’t recommend that you update the default policy unless you want the block to apply to all users. Choose a different policy (or create a new policy by running the New-OWAMailboxPolicy cmdlet instead).

After updating the policy, run the Get-OWAMailboxPolicy cmdlet to check that the setting is in place for the chosen OWA mailbox policy. Note that the ConditionalAccessFeatures property for the policy reports the set of restrictions for OWA to enforce.

Set-OWAMailboxPolicy -Identity NoOfflineAccess -ConditionalAccessPolicy ReadOnly
Get-OWAMailboxPolicy -Identity NoOfflineAccess | Format-List ConditionalAccess*

ConditionalAccessPolicy   : ReadOnly
ConditionalAccessFeatures : {Offline, AttachmentDirectFileAccessOnPrivateComputersEnabled, AttachmentDirectFileAccessOnPublicComputersEnabled, AttachmentPrintWithoutDownload}

When the ConditionalAccessPolicy setting is ReadOnlyPlusAttachmentsBlocked, the AttachmentWacViewingOnPrivateComputersEnabled and AttachmentWacViewingOnPublicComputersEnabled are added to the set of restrictions.

Use the Set-CASMailbox cmdlet to apply the OWA mailbox policy to a mailbox. It normally takes about 15 minutes for an updated policy to be effective. In the meantime, run Get-CASMailbox to check which mailboxes come within the scope of the policy, just in case some other mailboxes are affected.

Set-CasMailbox -Identity "Marty.King" -OwaMailboxPolicy 'NoOfflineAccess'
Get-CasMailbox -RecipientTypeDetails UserMailbox | Where-Object {$_.OWAMailboxPolicy -eq 'NoOfflineAccess'} | Format-Table DisplayName, OWAMailboxPolicy

Create a Conditional Access Policy to Block OWA Downloads

Figure 1 illustrates the details of the conditional access policy to enforce the blocks specified in the OWA mailbox policy. The session control for the CA policy says: “use app enforced restrictions,” which is the set of restrictions defined in the OWA mailbox policy. The only role conditional access has here is to notify the selected app(s) that they should apply restrictions because the device used for the connection is unmanaged.

The app is Office 365 Exchange Online, the enterprise app used by Exchange Online for many purposes, including OWA (its role in managing hybrid rich coexistence is being replaced by a dedicated tenant app soon).

Testing the Block Download Policy with OWA

To test the policies, I ran OWA on an iPad (an unmanaged device). A banner on messages with attachments informed me that the block on download and printing existed (Figure 2). Microsoft refers to this as the “limited access experience.”

A side-effect of imposing the CA policy is that the light version of OWA is blocked, probably because the light version is so simple that it doesn’t include the necessary smarts to handle the CA policy.

Testing with the New Outlook for Windows

Experience so far of managing the new Outlook is that settings from OWA mailbox policies apply to the Monarch client. Testing confirms that this is also true for conditional access restrictions. Installing and running the new Outlook for Windows on a Windows PC shows that the client picks up the same restriction as applied to OWA (Figure 3).

It’s nice that the restrictions imposed by the OWA mailbox policy work, but it would be nicer if the documentation reflected the fact. I’m sure Microsoft will get around to updating its web pages. In the meantime, to learn more about blocking access to downloads, here’s a Practical365.com article to read.

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

Tweaks to Copilot for Outlook Make the Functionality More Accessible

On Tuesday, I reported that I thought the new Facilitator agent in Teams chat is a good example of AI performing a task well. It’s evidence of how the initial rush of deploying AI everywhere to anything that could have a Copilot label applied is moderating into better implementations.

Message center notification MC892651 (last updated 18 March 2025, Microsoft 365 roadmap item 397092) could be regarded as being in the same category. In this case, the UI for Copilot interactions in the Outlook has what Microsoft terms as “major design improvements” for the new Outlook on Windows and Mac desktops, OWA, and Outlook mobile clients. Outlook classic remains unaltered.

Perhaps because it involves major improvements or a wide range of clients, the deployment of the update has been delayed. Microsoft originally intended to have full deployment done by late February 2025. That date is now late April 2025. When this happens, it normally means that Microsoft had to halt the deployment to fix some problems.

No New Functionality in Revamped UI

According to Microsoft, the revamped UI doesn’t include any new functionality. I never saw the ‘rewrite like a poem’ option before (which might have improved some of my email enormously), so the fact that the new layout and navigation makes this option accessible (Figure 1) is proof that the overhaul works.

Of course, things work differently on mobile devices, but the changes seem to make things better there too (Figure 2).

By comparison, the Copilot options in Outlook classic are a tad austere (Figure 3), just like the options were like in the other clients before the change. The changes made in the other clients proves once again that good design is important when it comes to making technology accessible to users.

UI Great, Text Awful

I like the UI changes and think they improve how Copilot for Outlook works. However, the changes do nothing to improve the quality of the written text generated by Copilot, which remains bland and overly effusive to my taste. I guess that’s my personal approach to email shining through because I favor brief to-the-point messages over lengthy missives.

The late Mark Hurd (CEO of HP at the time) once advised me to always put the most important information in a message into the first paragraph so that recipients could quickly review items in their inbox without needing to read long messages on mobile devices (Blackberries and iPAQs then). Technology has moved on, but the advice is still true, especially as so many different forms of mobile devices are now in use. Maybe Copilot for Outlook needs a rewrite in one brief paragraph option.

More Change to Come

Although it sometimes seems much longer, we’re still only two years into the Copilot era. We’ll see more changes like this as Microsoft refines and enhances how Copilot is integrated into apps. Now that they’ve given Outlook a nice new UI, perhaps they’ll do the same for Excel and PowerPoint to make it easier to use Copilot in those apps. Or maybe that’s just me moaning because I’m not as proficient as I should be with those apps.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Report Message and Report Phishing Deemed Unsafe by Microsoft

Message center notification MC1030003 (12 March 2025) brings news that the built-in Report button (Figure 1) is available for all Outlook clients (from these versions on). The older Report Message and Report Phishing add-ins are now in maintenance mode. Although they continue to work, Microsoft recommends that the add-ins should be removed before the time comes when Microsoft retires and finally removes the now-obsolete add-ins.

Microsoft cites many benefits for the new Report button, including support for reporting email delivered to shared mailboxes, better localization, and the ability to report messages from different places, like the preview window. My favorite is that users can’t report their own messages as junk because Outlook disables the Report button for messages sent by the mailbox owner. For now, this feature only seems to work in OWA and the new Outlook and sometimes it doesn’t work, but it’s certainly a good thing.

If users don’t see the Report button, it could be that the user reported settings in the Microsoft Defender portal need to be adjusted. These settings control whether users can submit messages suspected to be junk email or phishing attempts to Microsoft for analysis.

Some organizations don’t permit people to report email because they don’t want Microsoft personnel to be able to read the reported messages. That’s certainly a valid perspective, but phishing techniques evolve on an ongoing basis and a reported message could disclose a new technique that allows Exchange Online Protection to detect and block dangerous content. Overall, I think it’s best to allow users to report bad email.

Unsafe Add-ins

Rather alarmingly, the FAQ for the built-in Report button says that “there are security issues with the add-in which makes them unsafe for the organization” without saying or even hinting what those issues might be. The FAQ also says that the add-ins “can’t architecturally support functionality that customers keep asking for.” Again, no further information is given to back up the claim. It’s more likely that the problem is that these add-ins are COM-based. Microsoft is dumping this technology as it moves forward with the new Outlook for Windows.

Checking the Report Add-ins

Unless good reason exists not to use built-in client functionality, it’s best to use it rather than add-ins. Given the profusion of integrated apps that could appear in tenants due to Copilot agents, administrators are likely to be busy managing those apps. Getting rid of a few obsolete add-ins won’t ease the agent burden, but it’s step in the right direction.

Taking my own advice to heart, I checked in the Integrated apps section of the Microsoft 365 admin center to see if the Report Message and Report Phishing add-ins were still in use. As you can see from Figure 2, just one active user was detected.

The download option creates a CSV file that gives some details about the app and when it was used, but it doesn’t point to who is using the app. The app properties might be configured to allow access to the add-in to specific users or groups, and that could give a clue to who might be using it. But you’re out of luck if the app is configured for tenant-wide access.

Removing an Add-in

It’s always best to let users know that a change in coming. Microsoft says that people prefer the single Report button. In any case, changing from the add-in to the built-in report button shouldn’t prove too difficult for anyone, so I went ahead and removed the add-in from the set of Integrated apps (Figure 3).

It takes some time for a change like this to make its way to clients. Microsoft documentation says that it can take up to 24 hours before a newly deployed app appears in a client. The same applies to app deletions. My experience is that it can take longer before all clients receive updates. However, removed add-ins should disappear in a couple of days.

I’m glad to report that the removal of the old Report Phishing add-in from my tenant went according to plan. No squawking from annoyed users has happened so far. Maybe they haven’t noticed the change yet.

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.

Client-Side Limitation or Licensing Limitation?

Microsoft launched the new message recall feature for Exchange Online in October 2022 and shipped the code in early 2023. I duly wrote about the feature and noted the restriction for email protected by sensitivity labels. The EHLO blog describing message recall says:

Does recall work for encrypted email?

Message Recall within Classic Outlook is not available for messages encrypted with OME or using MIP labels. When attempting to recall these messages, the recall option will be greyed out in Classic Outlook and unavailable. This is a client-side limitation and is by design. To recall these messages, access your mailbox using OWA or the New Outlook for Windows, and recall your message from there.

Microsoft subsequently revamped the new message recall in August 2024. Nothing more was said about sensitivity labels. All we know is that a client-side limitation stops Outlook classic being able to recall protected messages while OWA and the new Outlook can both recall protected messages with ease (Figure 1).

Having the Right License is Always Important

Roll forward to message center notification MC882266 (last updated 23 October 2024, Microsoft 365 roadmap item 413431) where we discover that a component called Microsoft Purview Information Protection Advanced Message Encryption lies at the heart of the matter. According to the notification, user accounts must have a Microsoft 365 E5 or Office 365 E5 license to be able to recall encrypted email from their Sent Items folder. The same limitations that the mailbox must be in Exchange Online and that recall is only possible for messages sent to recipients within the same organization exist.

Notice that there’s no mention of client-side limitations. When such limitations are mentioned, it implies that some software problem exists within a client that prevents the client from being able to do something. Outlook classic is perfectly capable of working with sensitivity labels that encrypt messages.

In fact, Outlook classic is the most capable client in terms of working with encrypted messages because it can operate offline, including the ability to issue message recall requests for unprotected email by selecting a message and using the option in the File menu (Figure 2). The recall option isn’t available if the selected message has a sensitivity label with encryption.

Recall requests are kept in the Outbox folder until a network connection is available. Synchronization then occurs to send the recall request to Exchange Online for processing.

The ability of Outlook classic to work offline almost as well as when online is where the real issue might lie. OWA and the new Outlook are both designed to work online and that’s how they usually work. It’s therefore easy for the clients to check the licensing status of the signed in user, specifically to check that the account holds the Azure Information Protection Premium P2 service plan that’s included in the Microsoft 365 E5 and Office 365 E5 products. Outlook classic would need additional code to check user licensing when online so that it could work offline, much like the client stores rights management use licenses to allow it to work with protected messages when offline.

It can be argued that the limitation exists both in the client (can’t check a license unless Outlook classic is online) and licensing (can’t recall protected messages unless the right license is available), so the somewhat torturous text MC882266 is accurate without being clear.

Message Recall in Outlook Mobile

Meanwhile, message center notification MC1025213 (7 March 2025, Microsoft 365 roadmap item 471444) announces that Outlook for iOS and Android can recall messages. The option is available from the […] menu after selecting a message (Figure 3).  Outlook mobile clients cannot recall protected messages.

In Case of Protected Recall, Look for OWA

I’m not sure how many people will want to recall encrypted messages. If you find yourself in this situation, it’s easy to fire up OWA or the New Outlook and issue the recall request. Of course, the added time required to remember to use a different client and perform the message recall might mean that the recipient has read the text, but that’s a risk you must take.

Keep up to date with developments like the new Outlook 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 ECS to Send Outlook Newsletters to Thousands of External Recipients

After writing about the new Outlook Newsletters app last week, I was asked if any workaround existed to allow newsletters to be sent to external recipients. If you only need to send a newsletter to a few external recipients, the easy answer is to create an Exchange Online mail contact for each recipient. Assuming that a distribution list is used to distribute a newsletter, the mail contacts can be added to the distribution list membership and so receive their copy when the Exchange transport service expands the membership to dispatch the newsletter to its final destinations.

This approach works for any external SMTP address, defined as an SMTP address that doesn’t belong to one of the accepted domains registered for the tenant. I often use the technique to capture copies of messages sent to distribution lists as posts in a Teams channel. Figure 1 shows an example of such a mail contact. Note that the contact is hidden from address books to prevent its discovery by users who browse the GAL.

Scaling Up to Cope with External Recipients

However, adding individual mail contacts for external recipients is not a method that’s easy to scale up. You can automate the process with PowerShell by using the New-MailContact cmdlet to create mail contacts and the Add-DistributionGroupMember cmdlet to add mail contacts to a distribution list, but that’s probably too much trouble for the delivered value.

Besides, using distribution lists to send messages to large numbers of external recipients will run foul of the new tenant external recipient rate limit (delayed for implementation until 1 May 2025), not to mention the individual mailbox external recipient rate limit that’s due for implementation in October 2025. A better solution is required.

Sending an Outlook Newsletter with Azure Email Communication Services

Azure Email Communication Services (ECS) is a pay-as-you-go service based on Exchange Online that’s expressly intended to process external email sent at high volumes, like newsletters directed at customers. The problem is that Outlook Newsletters use “regular” Exchange Online and have no connection to ECS, so we need a way to bridge the gap.

My solution, imperfect and manual as it is, goes like this:

• Create and send an Outlook newsletter as normal.
• Open the copy of the newsletter in the Sent Items folder of the author’s mailbox (or the copy received by any recipient).
• Copy the HTML body and paste it into a Word document. Make sure to select the keep source formatting option to remain the layout. The result should look something like the document shown in Figure 2.

Save the Word document as a web page (HTML file). The output HTML file should contain all the formatting instructions and pictures for the newsletter.

If you look at the script referenced in the article about ECS, you’ll see that the setup necessary to send a message through ECS using PowerShell is very similar to sending a message with the Microsoft Graph PowerShell SDK. Essentially, you create and populate a message structure before submitting it to ECS to be sent. Part of the message structure is the message body, which can be formatted as HTML.

When I worked with ECS last year, I discovered that ECS was very sensitive to the HTML in a message structure and refused to process HTML generated from Word. That issue seems to have gone away because I was able to load the HTML for the Outlook newsletter into a string variable like this:

[string]$HtmlContent = Get-Content Newsletter.htm

Next, I amended the script code to change the message subject and use the HTML content loaded in from the newsletter and used the code to send newsletters to several hundred email addresses as a test. Here’s the code that does the work.

[int]$i = 0
Write-Host "Processing messages... "
ForEach ($Recipient in $RecipientList.Email) {
    # Construct the TO addresses for the message
    [array]$ToRecipientAddress = Get-MessageRecipients -ListOfAddresses $Recipient
    $i++
    Write-Host ("Sending email to {0} ({1}/{2})" -f $Recipient, $i, $RecipientList.count)

    # Build a hash table containing the settings for the message
    $Email = @{
         # The sender's email address
        senderAddress = $senderAddress
        # Create a unique identifier for this message
        headers = @{
            id = ("{0}-{1}" -f (Get-Date -format s), $ToRecipientAddress.address)
        }
       
        # The content of the email, including the subject and HTML body
        content = @{
            subject   = "Office 365 for IT February 2025 Articles"
            html      = $HtmlContent
        }
        # The recipients of the email
        recipients = @{
            to = $ToRecipientAddress
            bcc = @(
               @{
                   address     = "o365itprosrenewals@office365itpros.com"
                   displayname = "Office 365 for IT Pros Support"
                }
            )
        }
        # The reply-to addresses for the email - doesn't have to be the same as the sender address
        ReplyTo = @(
            @{
                address     = "o365itprosrenewals@office365itpros.com"
                displayName = "Office 365 for IT Pros Support"
            }
        )
        userEngagementTrackingDisabled = $false
    }

    # Convert the email settings structure to JSON
    $EmailSettings = $Email | ConvertTo-Json -Depth 10
    $MailStatus = $null
    # Define the URI to post to when sending a message with ECS. 
    # The same URI is used for all messages. The body of the message dictates who receives the email
    $Uri = ("https://{0}/emails:send?api-version=2023-03-31" -f $CommunicationEndpoint)
    # Submit the message to the Email Communication service
    try {
        $MailStatus = Invoke-RestMethod -Uri $uri -Method Post -Headers $headers -Body $EmailSettings -UseBasicParsing
    }
      catch {
        Write-Host ("Failed to send email to {0}" -f $Recipient)
     }
   }
   Start-Sleep -Seconds 2
   $Recipient = $null
}

Combine Different Components to Solve a Problem

The results aren’t perfect. Some email clients complain that the messages contain trackers (used by Outlook Newsletters to track the number of recipients that open newsletters. Some clients can’t display the inline graphics (Outlook classic does the best job). Tweaking of the HTML before it is processed by ECS might fix these problems. It’s worth noting that we’re dealing with preview software sending messages through an unsupported route, so some difficulties are to be expected.

Even though this is a use that Microsoft doesn’t support, it seems possible to use Outlook Newsletters for what it’s good at (creating nice-looking newsletters) and send the output to as many external recipients as you want through ECS. Given the imminent limitation for external recipient traffic being imposed by Exchange Online, using ECS might just be a solution for those who depend on being able to send high volumes of email to customers. ECS is harder to set up than simply sending messages from Outlook, and its traffic costs money, but ECS does get the job done.

After Microsoft ships Outlook Newsletters, they might support the use of ECS. It seems like a sensible next step!

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Outlook Users Never Realized the Desperate Need for Colored Folder Icons

The announcement in message center notification MC993229 (31 January, 2025), Microsoft 365 roadmap item 472921) that the new Outlook (or as it’s referred to in the announcement, “the new Microsoft Outlook for Windows desktop” and OWA are allowing users to personalize folder icon colors is in the category of “why” features. Apparently, the idea is to make it easier for people “to visually differentiate and personalize folders.” The feature is available in targeted release tenants and will be generally available worldwide during March 2025.

I don’t want to pour cold water on innovation, but the thought did go through my mind that the Outlook classic desktop client has survived and prospered since 1997 without different colored folder icons. The same is true for OWA, introduced around the same time, and seemingly unaffected by monocolor folder icons.

Using Outlook Colored Folder Icons

But now we have colored folder icons and the world is a better place. At least, it might be if you’re not color blind (like me) and have difficulties differentiating between nuanced shades. In the spirit of adventure, I resolved to bring a dash of color into my email life and set out to update some folders.

The first thing to note is that you can leave Outlook alone and it will use automatic colors. In other words, Outlook chooses how to present the folder icon. I’m not quite sure what color is used, but it’s functional and never caused me a moment’s worry until now, mostly because I never thought about choosing a new color for folder icons.

In Figure 1, the Archive folder is selected, and its folder icon is colored silver, one of the options in the folder icon palette. Some of the other folders have new colors too. Whether this makes those folders more recognizable or visually differentiated is in the eyes of the beholder.

To reveal the option to choose a new color for a folder icon, click the […] folder menu alongside its name. To produce the screen shot shown in Figure 1, I selected the folder menu for the Sent Items folder. As you can see, Sent Items still uses the automatic default chosen by Outlook. To update the folder icon color, choose one of the available selection like cranberry, light teal, or lime (note to self, who would have thought that I would ever write about applying lime as a color to any Outlook component?).

In any case, it all works, and you can spend a few minutes colorizing your folder icons.

Filers versus Pilers

I don’t know what impetus pushed the Outlook team to introduce colored folder icons at this point in the product’s development. It seems like many users eschew the use of folders apart from the default set because they depend on search to find items of interest when necessary. Piling items into a small set of folders is a habit encouraged by reliable search, something that took Outlook a long time to acquire.

I’m a filer in that I use folders to organize information. I’m not as diligent about filing as I once was in the days when search worked intermittently. Smaller mailbox quotas meant that it was sometimes necessary to clear out lots of items to make space for new email. Large mailbox quotas and retention processing have largely taken care of the need to delete items from mailboxes manually. I guess we need to fill the time once spent removing unwanted debris from mailboxes with other activities, like choosing colors for folder icons.

But Seriously

Some will criticize the Outlook developers for spending valuable engineering time implementing features like folder icon colors. If Microsoft is really serious about convincing the curmudgeons who use Outlook classic to move to the new client before support ceases for Outlook classic in 2029, shouldn’t they be solving the major pain points that stop people switching? Of course, Microsoft should deliver solutions like solid PST support (due imminently according to MC966639), but assigning a bunch of extra engineers to work on the pain points might not create solutions any faster. Which is why the engineers need to be kept occupied by pushing forward the frontiers of information technology with colored folder icons.

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.

Outlook Newsletters App for Outlook and OWA

Message center notifications MC1009916 (19 February 2025, Microsoft 365 roadmap item 328282) describes the new Outlook Newsletters solution, designed to create and send high-quality internal newsletters. The app is rolling out now in preview to targeted tenants. Standard tenants are likely to see Outlook Newsletters before the end of March 2025. General availability is scheduled for August 2025.

Outlook Newsletters is an app constructed from components drawn from the Microsoft 365 software toolbox like SharePoint Embedded, Microsoft Designer, Outlook reactions, comments, and so on. It’s a good example of how to combine available components with new code to create new apps.

Enabling Outlook Newsletters

Outlook Newsletters is an opt-in solution, meaning that it must be enabled before it appears in the menu bar for the new Outlook for Windows or OWA. Enablement is through settings in the OWA mailbox policies applied to mailboxes. Three policy settings are available (the administrator documentation is sparse and likely to be overhauled before general release):

• OutlookNewslettersAccessLevel: defines the access level a mailbox has to Outlook Newsletters. To create and send newsletters, this setting must be ReadWrite. Users with ReadOnly access can open the Newsletters app but can’t create or send newsletters. The default is no value, which equates to NoAccess.
• OutlookNewslettersReactions: Set to DefaultOn to make it the default that newsletters allow recipients to react in the same way as they react to normal Outlook email. Reactions can only be posted by internal recipients.
• OutlookNewslettersShowMore: Set to DefaultOn to make it the default for newsletters to display other newsletters at the bottom of a message. The idea is that recipients might find newsletters to subscribe to.

For example, this command allows any mailbox with the scope of the OWAFullAccess policy to have read write access to the Newsletters app with the other features enabled by default.

Set-OwaMailboxPolicy -Identity OWAFullAccess -OutlookNewslettersReactions DefaultOn -OutlookNewslettersAccessLevel ReadWrite -OutlookNewslettersShowMore DefaultOn

After updating the mailbox policy, it will take between 15 and 30 minutes before the Newsletters app becomes available to users in the Outlook menu bar. Alternatively, users can open the app using the direct link.

Quick Tour of Outlook Newsletters

The user documentation for Outlook Newsletters is available online and doesn’t need to be repeated here. Instead, I’ll describe how I created and sent a newsletter in just a few minutes.

After opening the app, you can choose to create a newsletter or group page. A group page is recommended when a newsletter has multiple contributors and multiple newsletters will be created with common branding, so that’s what I created (Figure 1). I added a heading and some common settings shared by all the newsletters associated with the group page.

Next, create a newsletter by selecting one of the out-of-the-box templates or a blank template. I used the basic template, which seemed like a good starting point to create a newsletter to circulate details of blog posts published over the last month.

Creating the content of a newsletter is a matter of editing the elements contained in sections. A template contains prepopulated sections to make the task easier, but you can add or remove elements as you like to create the desired effect. In my case, I extracted snippets and links for blog posts and combined them with images to highlight each article. Suitable images can be uploaded or generated using Microsoft Designer.

Draft newsletters and comments are stored in SharePoint Embedded containers and are visible through the SharePoint admin center (Figure 3) and PowerShell. Unhappily, an application name isn’t registered for the containers used by Outlook Newsletters. No doubt this is a detail that Microsoft will clean up before GA. Because of the dependency on SharePoint Embedded, those who create newsletters need a SharePoint Online license.

When the newsletter is complete, it’s ready for sending. This process involves creating a HTML format body part and combining it with message properties like the message title and recipients (Figure 4) before sending the message from the author’s mailbox, much like you’d do with Graph APIs.

Only known recipients can receive newsletters. A known recipient is an emailable object known to Exchange Online, including distribution lists, Microsoft 365 groups, individual mailboxes, mail user objects for guest accounts, and mail contacts.

You can enter an SMTP address, but Outlook drops these addresses if they don’t match with a known recipient when it sends the message. The golden rule is that to send a newsletter to an external address, the address must belong to a known recipient. This isn’t a big deal because it’s easy to create a mail contact for an external recipient, even for something like the email address for a team channel.

When sent, copies of the newsletter are normal messages in recipient mailboxes. After it is sent, the newsletter remains available for editing in the Newsletters app. If you make some changes and send another version, everyone in the recipient list receives a new copy.

Lots to Like

There’s lots to like about the Outlook newsletters app. The output generated looks well, basic analytics are included, newsletters support subscribe and unsubscribe options, messages can be sent from one mailbox with replies going back to a different mailbox, and so on. It’s definitely an app that people who send internal communications can find value.

Although it’s possible to send newsletters externally, restrictions like the new tenant-wide external recipient limit in Exchange Online constrain sending high volume communications, even if you add all the external email address as mail contacts. Used properly for internal communications, Outlook newsletters have the potential to be very successful.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Outlook Classic. OWA, and the New Outlook All Get the Org Explorer

Now that we’ve all recovered from the news about the retirement of Viva Goals, a possibly more important change in the world of Viva is the removal of the requirement for a Viva Suite license for access to the Org Explorer feature in Outlook (Figure 1). Microsoft introduced the need for potential Org Explorer users to have a Viva Suite license in February 2023 after originally saying that a Microsoft 365 E3 or E5 license was sufficient.

According to MC939925 (last updated 5 December 2024), rollout of Org Explorer to Outlook users will start in mid-January 2025 and complete by mid-April 2025. The Org Explorer is available for Outlook classic, OWA, and the new Outlook for Windows. Microsoft 365 roadmap item 421191 says that the feature is available to all Microsoft 365 commercial customers, which implies that anyone with a paid-for Microsoft 365 license can use the Org Explorer.

The Need for Directory Sanity

I never understood why Microsoft decided that it was a good idea to license the Org Explorer as a premium Viva feature. The explorer reveals the same kind of information that’s shown by the Microsoft 365 user profile card (without the ability to add custom properties to what’s displayed about users).

It seems like the folks who put together the Viva licensing strategy cast around to find features they could include to justify premium pricing and decided that the Org Explorer was a good fit. It’s yet another of the Microsoft 365 licensing oddities, like demanding an E5 license to add a default retention or sensitivity label to SharePoint document libraries. I had a Viva Suite license at one point, which is how I tested access to the Org Explorer, but after losing that license, I never noticed that the Org Explorer was no longer available in Outlook, which summarized the value I received from the feature.

Even though I might not have discovered much value in the Org Explorer, I think it’s fair to say that those working in large enterprises, especially when offices are distributed and/or multinational, might consider the Explorer to be a useful tool. Like user profile cards, the usefulness of something like the Explorer is highly dependent on the accuracy of the information stored in Entra ID. For instance, if reporting relationships (managers and direct reports) are not maintained in Entra ID, it’s impossible for a tool like the Org Explorer to build a coherent view of the organizational structure.

Some organizations prefer to store reporting relationships in HR databases and don’t synchronize this information with Entra ID. In such a situation, the view of the organization constructed by the Org Explorer is unlikely to be helpful or accurate.

Outlook’s Toggle into the Future

Speaking of Outlook classic, in MC949965 (December 6, 2024), Microsoft says that in April 2026, they will “toggle” enterprise users of Outlook classic to use the new Outlook for Windows. Fortunately, users will be able to recognize Microsoft’s mistake and immediately switch back if they choose. Conditions that will prevent automatic toggling include:

• Tenants hide the switching toggle. Hiding the toggle is the easiest way to stop Microsoft automatically moving Outlook classic clients to the new Outlook.
• Tenants choose an admin-driven migration.
• Outlook accesses on-premises mailboxes.

Microsoft wants to give users the opportunity to try the new Outlook, something that might be better appreciated if the client worked better than it does now. New features like pinning and snoozing messages might be appreciated by some, but I suspect that many in the Outlook community don’t care too much about these things.

Still, who knows what might transpire between now and fifteen months’ time? All the lingering issues that stop people switching now might be solved and everyone will be happy to adopt the new client before Microsoft support for the classic client ceases in 2029.

Change Keeps on Happening

Product retirements, licensing changes, and client upgrades are just part and parcel of Microsoft 365 life. It’s hard to keep track of everything that happens. Even we have a hard time, and we’ve been tracking the ins and outs of change across Office 365 and Microsoft 365 since 2014.

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.

Code Replacement Deadline for Exchange Legacy Tokens Approaching

In May 2024, I wrote about the upcoming change for the authentication method used by Outlook add-ins to embrace a technology called Nested App Authentication (NAA), which is used by ISVs and other developers to obtain access tokens to interact with Exchange through the Outlook REST API or Exchange Web Services (EWS).

Microsoft originally wanted to disable legacy Exchange tokens in October 2024. As tends to be the nature of these projects, customers needed some extra time. However, we’re now on the glidepath to complete disablement for legacy Exchange tokens across Microsoft 365 and Microsoft plans to turn off Exchange legacy tokens for all tenants in February 2025. The exact timing for when a client ceases to support legacy Exchange tokens depends on the Office channel in use (see the timeline for the different Office channels).

What Happens in February 2025

After February 2025, tenants can reenable Exchange legacy tenants using PowerShell. This action grants access until June 2025. At that point, Microsoft will disable Exchange legacy tokens again and tenants will only be able to reenable tokens through an appeal process. If granted, the tenants can use legacy Exchange tokens until Microsoft finally removes the functionality from Microsoft 365 in October 2025. That seems like a long time away, but given the effort required to find and deploy replacement add-ins to Outlook classic clients, tenants need to be in control of the process before the first phase of token disablement happens.

Although Microsoft is going through its normal process of publishing documentation, issuing message center notifications, and so on, one wonders if the message about removing support for Exchange legacy tokens is getting through. This is important because this change will eventually cause Outlook or OWA add-ins to stop working for many Outlook users if action is not taken.

Knowing What Add-Ins Are in Use

Microsoft has collated information about the Outlook add-ins known to be in use inside Microsoft 365. That information is available in a downloadable Excel worksheet (Figure 1). Additional reporting is expected in early 2025.

The first thing to do is to download and analyze the worksheet to identify what add-ins are in use within the tenant and who developed the add-in. At this stage, you must run several cmdlets (see instructions here) to discover the add-ins deployed in your tenant.

Often the author will be an ISV like SAP who understands the problem and has already created a replacement add-in based on NAA, the new way for add-ins to authenticate and receive access tokens from Entra ID. Some other add-ins might be authored by in-house developers, in which case the responsibility for updating the add-in code lies with the tenant. Microsoft’s documentation highlights some API calls that developers need to pay special attention to because they indicate the use of legacy Exchange tokens.

Some add-ins might have been developed by a company that’s now out of business. In these cases, the add-in will cease working once Microsoft disables legacy Exchange tokens and there’s no path forward except to find (or develop) a replacement add-in.

It Would Have Been Better to Start Earlier

Change is never easy, especially when it involves code that’s installed and run in a client like Outlook classic that’s been around for a very long time. There’s no easy workaround either when the problem involves a fundamental change in authentication and access that must be addressed in a code update.

Given the timeline, the important thing is to start the assessment process as quickly as possible. Identifying the set of add-ins in active use is critical, as is knowing where the necessary code updates will come from. After that it’s a mere matter of deploying the updates to individual workstations, which is always the easiest part of projects.

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.

The New Outlook Masters the Art of Offline Access

Microsoft added the initial support for offline working to the new Outlook for Windows in June 2024. Now they’ve announced (MC907098, 8 October 2024) that the client can start up when not connected to the internet. Truly this announcement deserves a roll of drums because it comes just 27 years or so after the Outlook classic client figured out how to start up without a network connection.

To be fair to the new Outlook, we live in an ultra-connected world and clients do expect to have connections to cloud services like Exchange Online. That wasn’t the case in 1997. The nature of early Wi-Fi networks and spotty dial-up phone connections often meant that Outlook 97 had no option but to work offline. Isn’t progress wonderful?

Microsoft 365 roadmap item 414516 refers to the feature as “offline app boot” and explains that offline access was previously only supported when Outlook was online and then went offline. My guess is that the Outlook developers hadn’t built the code to handle the detection of a lack of network and an elegant switchover to the local cache, which is what seems to have been added in the MC907098 update.

Details of what functionality is available when the new Outlook works offline are in this support article. General availability is expected in early October 2024 with full worldwide deployment complete by late November 2024. The update hasn’t reached me yet (version 1.2024.1002.100) as I still see the error in Figure 1 when I start the client without a network connection.

Control Over Offline Access

The ability for the new Outlook client to work offline is enabled by default. The Offline section of Outlook settings (Figure 2) allow users to decide if the client should be able to work offline.

Exchange administrators can block offline access by updating the OfflineEnabledWin parameter in the OWA mailbox policy assigned to user mailboxes. For example, this command blocks offline access with the new Outlook for every mailbox assigned the NoOfflineAccess OWA mailbox policy:

Set-OWAMailboxPolicy -Identity "NoOfflineAccess” -OfflineEnabledWin $false

To block offline access for everyone, run:

Get-OWAMailboxPolicy | Set-OWAMailboxPolicy -OfflineEnabledWin $false

Where does the New Outlook Cache Offline Data

Outlook classic spawned a cottage industry of ISVs specializing in creating products to do all sorts of things to the OST (offline storage) and PST (personal storage) files used by Outlook classic to enable that client to work offline. I receive frequent requests to endorse OST/PST products, none of which I accept.

The new Outlook doesn’t currently support PSTs. This feature is “coming.” The client doesn’t use OST files to create slave replicas of online mailbox folders. Microsoft hasn’t published any documentation to say where the local cache used by the new Outlook is, but some judicious poking around on a PC reveals that the likely storage location is in %LocalAppData%\Microsoft\Olk\EBWebView\Default\Cache\Cache_data.

WebView is an important component for the new Outlook (and OWA), so the location makes sense. Monitoring what happens in the folder, we see:

• A set of four “data” files (data_0, data_1, data_2, and data_3). I believe that these files form the offline cache read by the new Outlook. The number of data files probably depends on the number of mailboxes (primary and shared) configured for the new Outlook. In Figure 3, data_3 is much larger than the other files. If my theory holds true, this is the cache for my primary mailbox.
• A set of log files (like f_000094) that grow over time as the user works with Outlook. I believe that these files capture transactions such as new messages arriving, item deletions, and message sends. As part of client startup, a new log is created. When the client shuts down, any uncommitted transactions are written from the log into the data files.
• An “index” file. This likely keeps track of the transactions captured in logs that have been committed to the data files.

There’s nothing particularly strange here. The same kind of arrangement is used by many database systems, including the Exchange JET Blue database engine.

If you delete all the files in the Cache_data folder and restart the client, Outlook creates a complete fresh set of files and populates them. You can’t delete the data or index files when Outlook is active because they are locked by the client. However, you can remove the log files and Outlook will continue to create new logs without interruption.

The above is my interpretation of what’s happening based on observation. I have no idea if it is 100% correct.

The Long March Continues

Anytime I write about the new Outlook, I have to remind myself that we’re in the middle of a long march to the point where the new Outlook can take over from Outlook classic. Microsoft has committed to supporting Outlook classic until at least 2029. At the current pace, they might need all that time.

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.

Moving Deleted Items and Other New Outlook Functionality

As everyone knows by now, the new Outlook for Windows is generally available. Normally, this means that a product is feature complete and ready for deployment. Alas. The situation is more complicated because the new Outlook is still well away from a stage where enterprise customers might consider the client to be the finished article. It’s certainly better than the old Windows Mail and Calendar clients, but there’s a reason why Microsoft will support Outlook (classic) until at least 2029.

To Microsoft’s credit, they continue to add features to Outlook, like the update described in message center notification MC896715 (Microsoft 365 roadmap item 413716) telling us that in November 2024 users can drag an item to the calendar icon in the navigation bar to cause Outlook to create a new event. The downside of Microsoft pushing forward with adding features to the new Outlook is that it removes engineering resources from working on stuff that enterprises value, like support for PSTs. I’m sure that creating calendar events from email (which happens today for messages like airline bookings) will be good, but closing the feature gap with Outlook (classic) appears to be much more important.

Controlling Moving Deleted Items from Shared Mailboxes with Outlook Classic

Which brings me to the topic of deleting items from shared mailboxes. Quite why Outlook (classic) insists on moving deleted items from shared mailboxes to the Deleted Items folder in the user’s primary mailbox is beyond me, but that’s the client’s default behavior. The approach might be justifiable if only a single person accessed the shared mailbox, in which case you’d always know where the deleted items are, but the whole point of shared mailboxes is that they’re a resource accessible by multiple people. Scattering deleted items across many different mailboxes just doesn’t seem logical.

Thankfully, a registry setting exists to force Outlook (classic) to keep deleted items in the Deleted Items folder of the shared mailbox. Or rather, in the Deleted Items folder of any mailbox where delegated access allows the deletion of items. The DelegateWastebasketStyle DWORD can be:

• Not present: Move delete items to the Deleted Items folder in the user’s mailbox
• 4: Move deleted items to the Deleted Items in the shared mailbox.
• 8: As for “not present.”

In most cases, setting the value to 4 is what’s needed. You can update the registry manually (Figure 1) or via group policy. The article cited above contains some caveats that you should be aware of, but in general, 4 works well and is what I use for all the shared mailboxes that I access daily.

No Setting to Control Moving Deleted Items in the New Outlook

The New Outlook is very like OWA and eschews the system registry for application settings. Instead, Outlook settings are stored in hidden items in user mailboxes. This is the right approach because it means that settings are transportable across workstations. In other words, when someone gets a new PC, they don’t need to spend hours configuring Outlook to work the way it did on the old PC. It also means that OWA and the new Outlook share settings, which makes moving to the new Outlook very easy for people who now use OWA.

Good as transportable settings are, it means that the engineers building the new Outlook must track down every registry setting that can be applied to Outlook (classic) and recreate the setting (if required) for the new Outlook. And today, the new Outlook has no equivalent setting to control where messages deleted from shared mailboxes end up. It’s an example of work that needs to be done at some time in the future before Microsoft can retire Outlook (classic).

Debugging the New Outlook

All software is imperfect in some way. Finding glitches in the transition of a client that’s been in use since 1997 is easy, especially during a platform change. Organizations won’t discover if the new Outlook fits their requirements unless people use the client for real work. It’s easy to switch back to the classic client if you find something doesn’t work as expected. And if you do, be sure to let Microsoft know.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Removing Duplicate Contacts From Outlook’s View

When Microsoft published message center notification MC835643 (last updated 12 September 2024), I was a little confused (a more normal state for me than you might imagine) and wondered how well the new contact duplication feature would work. Now that the feature has reached my tenant, it’s pretty obvious what happens. Let me explain.

The Problem with Personal Contacts

First, a comment about personal contacts: they’re easy to mess up over years of acquiring business cards from people or details scrawled on convenient pieces of paper, or just by making a mistake when importing contacts from an external source (like this example). Microsoft’s suggested resolution for a mess of duplicates by exporting, pruning, and importing is viable but painful, which is why so many third-party products exist to maintain Outlook contacts.

Outlook (classic) does its best to stop duplicate contacts by highlighting potential problems when a user attempts to add a new contact (Figure 1). I can’t say when Outlook (classic) started to do this. All I know is that I have accrued some duplicate contacts over the years.

The other problem with personal contacts is that their accuracy degrades over time as the people the contacts describe move jobs, locations, or otherwise change. There’s not a lot you can do about this issue short of maintaining a hawk-like eye over LinkedIn updates to detect changes in peoples’ circumstances to allow you to update your contacts. The summary is that lots of user mailboxes include duplicate contacts.

Hiding Duplicate Contacts

The new Outlook for Windows and OWA aim to reduce the visibility of duplicate contacts by detecting and hiding contacts “that are exact duplicates or proper subsets of other contacts. This means that if you have multiple entries for the same person, Outlook will consolidate them, keeping only the most complete contact visible.” Hiding potential duplicates leaves them in the Contacts folder of your mailbox and visible through other clients like Outlook (classic) and Outlook mobile.

There’s no administrative control over the feature to enable or disable it on a per-user or tenant-wide level. It’s now how the new Outlook and OWA clients work.

To detect duplicate contacts, Outlook looks for clues. Finding contacts that are perfect replicas of each other is the easiest way to detect duplicates. After that, looking for the same details such as email address, work phone, and so on build a case to hide contacts as duplicates by satisfying the requirement that contacts are a proper subset of the others.

Explaining a mathematical concept to end users who want to know why duplicate contacts disappear from view can be challenging. I can’t track down support documentation that might explain what happens in plain English.

When everything works, duplicates contacts disappear from view. Figure 2 shows that only one of the two contacts for Larry Hawkes is shown.

After the initial flush of success, some questions arise. How did Outlook decide to show one contact and not the other? Is it based on completeness of contact properties, or the last time the contact was modified (on the basis that the latest contact information is likely the most accurate).

Then I added another contact for Larry Hawkes (with the same email address and roughly the same contact properties). After refreshing Outlook, the three contacts were visible (Figure 3).

Perhaps the thought was that while people are likely to have duplicates, having three contacts that refer to the same person is outside the boundaries of what Outlook can resolve. If so, Microsoft should document this.

Here’s the contact information visible with PowerShell:

Get-MgUserContact -UserId $User.Id -Filter "Companyname eq 'Contoso'" | Format-Table displayname, companyname, emailaddresses, businessphones

DisplayName  CompanyName EmailAddresses             BusinessPhones
-----------  ----------- --------------             --------------
Larry Hawkes Contoso     {Larry.Hawkes@contoso.com} {+1 (206) 177 1931}
Larry Hawkes Contoso     {Larry.Hawkes@contoso.com} {+1 (206) 177 1931}
Larry Hawkes Contoso     {Larry.Hawkes@contoso.com} {+1 (206) 177 1931}

I expect three contacts with the same email address, display name, company name, and work phone number to be called as duplicates, and I think most other people would too.

The problem might be to do with timing, Perhaps once Outlook resolves duplicates, it doesn’t go back and check again for a set period. The client certainly doesn’t perform a check on startup because I tried that several times. Microsoft hasn’t said if Outlook uses a schedule to decide when to check for duplicates or if a user can request a check (for instance, after importing some contacts from an external source).

Update: I can’t confirm this as 100% accurate, but a Microsoft source said that Outlook checks every 15 days.

Improvement Needed

Don’t get me wrong. I like the idea of hiding duplicate contacts. It’s a good thing to do. It’s just that it would be better if Microsoft delivered better documentation and some controls for administrators and users to dictate how the feature works instead of assuming that everyone will be happy with the code as delivered.

Make sure that you’re not surprised about changes that appear inside Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Choice Remains Between Outlook Mobile and Exchange ActiveSync Clients

One of the most common questions I am asked concerns mobile email clients. Should Microsoft 365 tenants deploy and use Outlook Mobile or select a client based on the Exchange ActiveSync (EAS) API created by companies like Apple and Samsung instead? I’ve written about this topic before but it’s worth summarizing the current state of the art, so here goes.

OWA for Devices

Ten years ago, Microsoft jettisoned its focus on OWA as the premium client for mobile email connectivity. Trumpeted with some vigor at the 2014 Microsoft Exchange Conference in Austin, OWA for Devices, as the client was known, leveraged the engineering investment to create a high-quality browser-based client. Essentially, OWA for Devices was a wrapper around the full client to allow it to run using the native browser found in all mobile devices.

The OWA for Devices plan allowed Microsoft to bring a wide range of features to mobile devices that couldn’t be built on top of the EAS protocol. It’s worth remembering that Microsoft created EAS to compete with IMAP4 and POP3, so the feature set enabled through the EAS API is limited to basic email and calendaring.

The Acompli Effect

Technical difficulties, poor performance, and the feeling that Microsoft was trying to squeeze a heavyweight client designed for PC browsers into a mobile pot were the fault lines in the OWA for Devices strategy. If you can’t build technology, plan B is often to buy technology, and that led to the Acompli acquisition in late 2014.

Acompli’s signature feature was the focused inbox, or the ability to filter the most important messages into a separate Inbox (actually just a filtered view of Inbox contents). No mobile API supported the processing required to understand what messages were most important to a mailbox’s owner and filter those messages as new mail arrived in the mailbox. Acompli built the necessary infrastructure to copy mailbox contents from Exchange to build an online cache located in Amazon Web Services (AWS) to enable advanced email processing. The Acompli client connected to the processed cache and presented the filtered Inbox view to the user.

Acompli became Outlook Mobile for iOS and Android. The focused inbox became a feature loved or hated by hundreds of millions of users, and Microsoft replaced AWS with equivalent storage and processing based on Azure. Outlook Mobile still fetches cached mailbox content from Azure (now with a customizable synchronization period).

The new Outlook for Windows client exploits the same mechanism to deliver advanced functionality to users who connect to email servers via POP3 and IMAP4. These now-antique connection protocols don’t support many features used by modern email clients, so if the interim processing wasn’t done, the new Outlook for Windows would be restricted to a basic feature set. This simple but salient fact is ignored by those who protest when they discover that Microsoft synchronizes mailbox content to Azure for processing.

Outlook Mobile Continues to Lead

Coming back to the original question, I continue to recommend that organizations focus their mobile email client strategy on Outlook Mobile whenever possible. It’s a solid client for both iOS and Android that easily outpaces EAS-based clients in areas like email features and information protection. The client feature set continues to evolve, with the latest initiative being a new contact editor (MC746321, last updated 5 July 2024, Microsoft 365 roadmap item 384869). Apart from more reliable synchronization of contacts with Exchange Online, the new contact editor (Figure 1) supports enforcement of Intune policies such as preventing copy and pasting data in the editor. Outlook Mobile is better integrated into Intune device management too. In summary, from a corporate IT perspective, Outlook Mobile ticks many boxes. Its advantage over EAS clients in this area is unlikely to diminish.

But life isn’t always simple and corporate IT doesn’t always get to implement their choice. The era of BYOD means that an incredible number of devices connect to Microsoft 365, and it can be hard to move people from a native email client. Old habits die hard. However, I see an increased uptake in Outlook Mobile usage, possibly because features like sensitivity labels have rolled out in more tenants. My view is anecdotal and based on a limited set of data, but it seems like that’s the way things are going ten years after Microsoft choose Acompli as their new mobile email client.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Set a Delay for Microsoft Content Services to Evaluate Email Content

I was asked about a Microsoft Technical Community post from July 2023 titled Oversharing Pop-up in Outlook– Customize experience via GPO settings. Some folks couldn’t get the pop-up windows to work with the newly branded Outlook (classic), so I decided to take a look.

Outlook DLP Policy Tips and Pop-Up Windows

When a tenant has configured Data Loss Prevention (DLP) policies to prevent sharing of sensitive data, Outlook and OWA evaluate message content and display policy tips if configured in DLP rules. Figure 1 shows how Outlook displays a policy tip after detecting some credit card information in a message.

Outlook sends email content to Microsoft content services for processing by DLP policies. If a violation is found and a policy tip is configured, Outlook displays the policy tip. It’s possible to use a sensitivity label to block access to content services for Microsoft Office apps. Although the intended use case for assigning such a label to an email is to stop Copilot for Microsoft 365 processing message content, the label also stops DLP policy tips. Blocking a visual indicator isn’t optimal, but a backstop exists in that the transport service can block messages when it processes the checks defined in DLP policies.

The Problem Being Solved with Outlook DLP Policy Tips

The problem that the pop-up messages attempt to solve is that it’s possible to insert sensitive data into a message and send it before Outlook has the time to send the content to Microsoft content services, which means that the user never sees the policy tip. The solution that I tested involved configuring the specify wait time to evaluate sensitivity content setting in a Cloud Policy configuration in the Microsoft 365 apps admin center (Figure 2).

Enabling the setting and specifying a period (in seconds) instructs Outlook (classic) to pause for the specified period before sending a message. Allowing 15 seconds or so should be enough for Outlook to transmit the email to Microsoft content services and receive a response. During this process, users see a message to tell them that the organization requires email to have a sensitive content check before transmission (Figure 3).

Depending on the DLP rule conditions, a violation discovered by the content check causes Outlook to display the policy tip with or without the message being blocked. If allowed by the DLP rule, the sender can override the block and continue to send the email. Figure 4 shows a DLP rule configured with a policy tip and the ability for a sender to override the block.

When content services detect a policy violation, Outlook displays the policy tip and the dialog to allow the user to override the policy (Figure 5).

DLP captures DLPRuleUndo audit records when users override a policy when sharing sensitive documents from SharePoint Online and OneDrive for Business. Exceptions cited by email senders are included in the audit data payload for the records. The same records are not captured when people override a DLP block with Outlook. I have flagged this issue to Microsoft and await their response.

Outlook DLP Policy Tips Good if You Can Handle the Sending Delay

Outlook pop-ups for sensitive data checks close a gap that might stop someone from sending a message containing sensitive content only to have DLP reject the message when it goes through the Exchange transport service. Closing any gap is goodness, as is the additional education people see when they see that messages are checked. The downside is that users might dislike the delay all outgoing messages experience to allow content services to process their content, plus the lack of audit records. If you can live with these issues, then pop-up warnings for Outlook might be a policy to experiment with a small target group before making it live for everyone.

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.

Many Mailbox Settings Missing from Outlook Settings API

One of the curious things about the Graph APIs is the incomplete Outlook settings API. It’s a well-known fact that Microsoft has not done a good job of supporting Exchange management operations through the Graph API. Perhaps understandably because of its long-term history with Exchange, PowerShell is the current focal point for Exchange Management automation

Perhaps the Outlook settings API is the starting point for what will become a full-fledged implementation to manage all aspects of mailbox settings. Given the scheduled retirement of Exchange Web Services (EWS) from October 2026. If so, an API covering all aspects of mailbox configuration would be a welcome development. PowerShell is great, but a Graph API is more flexible because of its support. With that thought in mind, let’s review what the current API can do.

Different Clients, Different Settings

Outlook classic (Win32) and OWA (or the new Outlook for Windows) use different client settings. Some crossover exists, such as roaming signatures, but the different history for the clients means that settings are divided into those stored in the system registry (Outlook classic) and those held in user mailboxes (OWA).

Exchange Online supports cmdlets like Get-MailboxCalendarConfiguration to manage mailbox settings, but the Outlook settings API only deals with a limited subset of the settings exposed through the OWA client (Figure 1).

Properties Returned by the Outlook Settings API

The properties returned by the Outlook Settings API are:

• Auto-replies (automaticRepliesSetting).
• Date format (dateFormat).
• Delegate message delivery options (delegateMeetingMessageDeliveryOptions).
• Locale (localeInfo).
• Time format (timeFormat).
• Time zone (timezone).
• Working hours (workingHours)
• User purpose or mailbox type (userPurpose).

The Get-MgUserMailboxSettings cmdlet returns all the properties supported by the Outlook Settings API. Here’s how to fetch the settings for the currently signed-in user:

Connect-MgGraph -Scopes MailboxSettings.ReadWrite
$User = Get-MgUser -UserId (Get-MgContext).Account
[Array]$Settings = Get-MgUserMailboxSetting -UserId $User.Id

$Settings | Format-Table

ArchiveFolder                         : AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNAAuAAAAAAB_7ILpFNx8TrktaK8VYWerAQA3tTkMTDKYRI6zB9VW59QNAABnZQYBAAA=
AutomaticRepliesSetting               : Microsoft.Graph.PowerShell.Models.MicrosoftGraphAutomaticRepliesSetting
DateFormat                            : d MMM yyyy
DelegateMeetingMessageDeliveryOptions : sendToDelegateAndPrincipal
Language                              : Microsoft.Graph.PowerShell.Models.MicrosoftGraphLocaleInfo
TimeFormat                            : HH:mm
TimeZone                              : GMT Standard Time
UserPurpose                           : user
WorkingHours                          : Microsoft.Graph.PowerShell.Models.MicrosoftGraphWorkingHours

To reveal full details of a setting shown with a Graph object type rather than a value, pipe the property to the Format-List cmdlet:

$Settings.Language | Format-List

DisplayName          : English (Ireland)
Locale               : en-IE
AdditionalProperties : {}

As a practical example of using the API, here’s how to configure auto-replies. The example configures a simple HTML auto-reply message for both external and internal senders to be sent during a scheduled period extending from now to 30 days in the future. Details of the different values available to configure the autoreply settings are available online. This code uses some simple hash tables to hold the parameters (for those who care, I find this technique easier and less probe to error than composing a request body in JSON, especially when nesting values).

to error than composing a request body in JSON).
[array]$Settings = Get-MgUserMailboxSetting -UserId $User.Id
$Timezone = $Settings.TimeZone

$Start = Get-Date (Get-Date).AddHours(-2)-format s
$End = Get-Date (Get-Date).AddDays(+30) -format s

$StartDateTime = @{}
$StartDateTime.Add("dateTime", $Start)
$StartDateTime.Add("timezone", $TimeZone)

$EndDateTime = @{}
$EndDateTime.Add("dateTime", $End)
$EndDateTime.Add("timezone", $TimeZone)

$Parameters = @{}
$Parameters.Add("Status", "scheduled")
$Parameters.Add("externalAudience","all")
$Parameters.Add("internalreplymessage",$HtmlMessage)
$Parameters.Add("externalreplymessage",$HtmlMessage)
$Parameters.Add("scheduledEndDateTime",$EndDateTime)
$Parameters.Add("scheduledStartDateTime",$StartDateTime)

$AutoRepliesSetting = @{}
$AutoRepliesSetting.Add("automaticRepliesSetting", $Parameters)
Update-MgUserMailboxSetting -UserId $User.id -BodyParameter $AutoRepliesSetting

The effect of the update to mailbox settings is shown in Figure 2.

OWA and Outlook classic share most auto-reply settings. Three settings specific to OWA are shown under the scheduled period, like “block my calendar for this period.” These settings are not available in Outlook classic and unsupported by the Outlook settings API. Auto-reply settings can be set using the Exchange Online Set-MailboxAutoReplyConfiguration cmdlet, as in this example of configuring auto-replies for shared mailboxes to respond to incoming customer queries over a holiday period.

The Archive Folder

I’m not quite sure why the settings include the mailbox folder identifier for the Archive folder. The Archive folder is one of Outlook’s default mailbox folders and has nothing to do with the online archive. The folder identifier might be present to tell Outlook the target folder when executing the move to archive action.

In any case, an API exists to translate folder identifiers between different formats. The value is stored as a “RestID,” which is the default used by the Graph. Here’s how to translate the identifier to the MAPI format, which is what you’d see when browsing mailbox contents with the MFCMAPI utility.

[array]$SourceIds = $Settings.ArchiveFolder
$Body = @{}
$Body.Add("sourceIdType", "RestId")
$Body.Add("inputIds", $SourceIds)
$Body.Add("targetIdType", "entryid")

$R = Invoke-MgTranslateUserExchangeId -UserId Rene.Artois@office365itpros.com -BodyParameter $Body
Write-Host ("REST format identifier is {0}" -f $R.SourceId)
Write-Host ("MAPI format identifier is {0}" -f $R.TargetId)
REST format identifier is AAMkAGU2MDhlMDhjLTdlZGMtNDMwNC05M2Y4LTIyNzNiYzI5N2VlNwAuAAAAAAC8kIa3heviTIMxxfhY7u2KAQB7Y5w0HV7-Rou7AD9UAhLGAAAAAAE9AAA=
MAPI format identifier is AAAAALyQhreF6-JMgzHF-Fju7YoBAHtjnDQdXv9Gi7sAP1QCEsYAAAAAAT0AAA2

To see more of the gory details about item and folder identifier formats, see Vasil’s blog.

Good in Parts

The Outlook settings API is like a curate’s egg: good in parts. It seems like something Microsoft started on some time ago (look at the 2016 dates used in the update examples) and then forgot. If so, that’s a pity. It would be nice to have full Graph coverage of all Microsoft 365 workload. We’re still waiting and looks like we’ll have to wait for a while yet.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

Microsoft Clears the Deck to Permit the New Outlook for Windows to Move to GA

Message center notification MC803006 (last updated 20 June 2024) is an indication that Microsoft is getting close to announcing the General Availability (GA) for the new Outlook for Windows (aka the “Monarch” client). In March, Microsoft indicated that they were approaching GA. This step takes them a tad closer.

MC803006 says that Microsoft will formally rename the Outlook (Win32) app to be Outlook (classic) from July 2024 “to differentiate it from the new Outlook for Windows.” The change is active in Office version 2407 or later.

The classic moniker has been in use for months. The difference is that Microsoft is changing the app name, icons, and listing in the Start menu. Normal users who haven’t been aware of Microsoft’s determination to deliver a new Outlook for Windows will see the name change, and this could prompt questions.

Outlook (Classic) Still Retains Support Until 2029

Microsoft emphasizes that the name change does not affect the status of Outlook (classic) or their previous commitment to support the product until at least 2029. They also point out that they’ve started to use the new naming convention in support documentation.

I’m sure that those who pay attention to naming conventions will distinguish the importance of the change. Regular users will probably still be confused how a slightly better OWA that still isn’t nearly as functional as Outlook (classic) is now the lead Outlook for Windows. However, users can safely ignore naming games because the reason for the change is to allow Microsoft to proceed make the new Outlook for Windows generally available for customers who want to use the client (Figure 1).

Anyone who uses OWA, for instance, will find the new Outlook for Windows to be a better client, especially when Microsoft delivers some of the promised features needed to close the gap with Outlook (classic), like offline mode and support for PST files. Microsoft has an adoption site to document its reasons why organizations should embrace the new Outlook for Windows. Like most similar sites, it includes a mixture of valuable information mixed in with propaganda.

Offline Capabilities for the New Outlook for Windows

According to MC798674 (4 June 2024), support for what Microsoft terms “the first set of offline capabilities” for the new Outlook for Windows is coming in late June 2024 when mail, calendar events, and contacts will be saved on local devices and available for offline working. Users will be able to create, send, and save emails and perform management actions like moving or deleting items. Offline access is not available as of today, but there’s still some time left in June.

Teams 2.1 Loses Its New Label

Meanwhile, MC803890 (21 June 2024) reminds tenant administrators about another forthcoming app rename. This time the new Teams (2.1) client loses its “new” label because the Teams classic client reaches the end of support on July 1, 2024. It’s one way of showing that Teams 2.1 is now the only game in town, unless you’re a VDI or government cloud customer as the Teams classic client continues in support for these environments.

Reaching the end of support doesn’t mean that the Teams classic client stops working. However, anyone running the client will be nagged through dismissible in-app messages to remind them that their software is unsupported.

Starting on October 23, 2024, the Teams classic app will cease working on Windows 7/8 and MacOS Sierra (10.12) desktops. Users of these platforms will have to use the Teams browser client. Starting on July 1, 2025, the Teams classic client reaches the end of the road for everyone and will be formally consigned to the great byte wastebasket for obsolete software products.

Lots of change to deal with!

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Confused Communication Masks a Simple Message About Retirement of Legacy Outlook Clients

Microsoft’s ability to communicate a clear and concise message about software retirements was demonstrated once again by the publication of message center notification MC801980 on June 14, 2024. Titled “Legacy Outlook clients retirement plan,” the post stated:

“Starting in mid-July, for organizations that use vanity domains and their users are on the following version of clients they will experience functionality diminishing:

• Outlook for iOS versions prior to 4.2411.
• Outlook for Android versions before 4.2342.
• Outlook for Mac versions older than 16.73.
• Windows Mail and Calendar applications.”

Copilot for Word required several attempts to rewrite the introduction into comprehensible English. In a nutshell, Microsoft is encouraging people using legacy Outlook clients to upgrade to a more modern version. The suggested versions are:

• Windows Mail and Calendar: the new Outlook for Windows (aka Monarch). Microsoft says that millions of consumer users have already made this switch. Support for these apps terminates at the end of 2024.
• Outlook for Mac: The current version is 16.86.
• Outlook for Android and Outlook for iOS; Build V4.2422.0 is the latest.

MC801980 announces the retirement of OWA light. The news about retirements of legacy Outlook clients caused some fuss and bother. In reality, the announcement is directed more at consumer users than Microsoft 365 organizations, but there is some detail to note.

Upgrade to a Modern Browser Now (Please)

From mid-August 2024, Microsoft will insist that people using OWA or Outlook.com use a recent version of their favorite browser. Internet Explorer is listed, but that doesn’t concern Microsoft 365 users because support for IE terminated on August 17, 2021. Most Microsoft 365 users will have a recent version of a browser on their workstation, so the advice to upgrade from Chrome or Edge version 79 (I’m running Edge version 125.0.2535.92 on my PC) indicates that there must be many Outlook.com users with old software.

The Demise of OWA Light

Microsoft announced some of the news (like the retirement of OWA light) in a technical community post on June 11, 2024. OWA light goes back to the earliest days of browser support for Exchange Server and is still available in Exchange Online (Figure 1). At one time, OWA light was important for low-end devices, but the need has declined over the years and its loss shouldn’t be of huge concern.

Some people use OWA light for accessibility reasons. Microsoft says that the latest version of OWA contains accessibility options, so the need to support a separate client no longer exists. For Exchange Online, Microsoft will remove the IsOptimizedForAccessibility parameter for the Set-CASMailbox cmdlet. Once a tenant is refreshed with the change (from mid-August to late October), mailboxes configured to use OWA Light will see an error page. Losing OWA Light might turn out to be the biggest impact on Microsoft 365 tenants signaled in MC801980.

In the technical community post, Microsoft also announced the termination of basic authentication support for Outlook consumer accounts on September 16, 2024. Taking the two communications together, a consistent message emerges that Microsoft wants its consumer base to move to modern software if users want to connect to its cloud services. It’s exactly what happened in the enterprise space, so this development is no surprise. Modern clients all support modern authentication, so that’s a good reason to upgrade.

Retirements of Legacy Outlook Clients Begin in mid-July 2024

Overall, there’s really nothing more in MC801980 than a call for people to replace old software with newer software. There’s no reason to panic and no need for people to upgrade their Outlook classic clients. The new Outlook for Windows has still not reached general availability. Even when it does, Microsoft says that Outlook classic will remain supported until 2029.

Microsoft will begin the retirement process for the older clients in mid-July 2024 and expect to complete the roll-out by late September 2024. No guarantee can be made about when a block will descend on consumer users or a specific Microsoft 365 tenant, so the call to action is clear: check your software and upgrade as necessary blocks start to descend in mid-July.

Stay updated with developments like client requirements across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Copilot Audit Records Now Include Resources Used in Responses

In April 2024, I wrote about the appearance of audit events to capture details when Microsoft 365 applications call Copilot to process a user request (prompt). These events have an operation type of CopilotInteraction.

Since then, Microsoft announced progress in capturing records when people use Copilot in the Stream player to query video transcripts (MC720180, last updated 22 May 2024). It’s like MC720180 (also updated on 22 May 2024), which describes using Copilot to interact with meetings. In both cases, the important point is that the audit events generated for Copilot interactions capture details of resources accessed by Copilot when responding to user prompts (previously the AccessedResources property in the AuditData payload was empty).

Linked to the Change in Transcript Storage Location

Because Copilot depends on meeting transcripts to answer queries, meeting interactions are only possible when meetings are recorded with a transcript. As discussed last week, Teams is standardizing on OneDrive for Business storage for the MP4 files generated for meeting recordings and transcripts. Like many situations in Microsoft 365, developments reported in one message center notification are linked to what’s described in another, seemingly unconnected, update.

The change should be effective in most places now as Microsoft aims to complete worldwide deployment in early June 2024.

Updated Script to Handle Copilot Audit Records

To test the effectiveness of the change, I updated the script I wrote for the previous article (downloadable from GitHub) to support audit records generated by the Stream player and to pay more attention to the data recorded in the associated resources property. Figure 1 shows the output of the script as viewed through the Out-GridView cmdlet.

Please check out the updated script and let me know if it’s helpful or could be improved.

Copilot in Outlook Classic

Speaking of Copilot, for a long time Microsoft communicated the message that Copilot experiences would only be available in the new Outlook client (aka Monarch). This was no more than a thinly-disguised ploy to drive adoption for Monarch, which still isn’t close to ready for consumption by corporate users.

In any case, message center notification MC794816 (21 May 2025, Microsoft 365 roadmap item 388753) reports the availability of the Copilot for Microsoft 365 chat experience for Outlook classic (Win32). This feature joins “Summarize,” the Copilot option that extracts the major points from an email thread (my second favorite Copilot feature after meeting summarization), and the option to have Copilot draft or revise message drafts. Microsoft will roll out Copilot for Microsoft 365 chat to Outlook classic in the current channel in June 2024.

Before anyone gets too excited, let me say that Copilot for Microsoft 365 chat in Outlook is the same application as accessed as a web application and in Teams. The only difference is that Copilot has an icon in the Outlook application bar and runs in the Outlook window (Figure 2). In other words, if you’re used to Copilot chat elsewhere, you’ll find no difficulty using it in Outlook, providing you have the necessary Copilot for Microsoft 365 license.

As you can see from Figure 2, chats generated in other instances of the client are available in Outlook.

Change, Change, and More Change

Change is ongoing within Microsoft 365. Some changes are dependent on other changes, such as Copilot audit records capturing associated resources for the Stream player. Others are the delivery of incremental functionality within an application. The trick is to keep an eye on what’s happening and to recognize what kind of change each message center notification represents. That’s sometimes hard to do based on the way Microsoft describes a change. Oh well, into every life a little rain must fall…

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Microsoft Retiring Legacy Exchange Authentication Methods from October 2024: Are Tenants Ready?

Outlook integrated add-ins are a popular mechanism to extend client functionality to allow access to external data sources. No one knows exactly how many add-ins have been created or how many are in active use within Microsoft 365 tenants, but what we do know is that some tenants will get an unpleasant shock in October 2024 when Microsoft turns off legacy Exchange user identity tokens and callback tokens for Exchange Online tenants. Microsoft says that these legacy methods “no longer provide sufficient support for organizations’ response to threats against email data.”

Both are authentication methods originating from on-premises environments. Microsoft wants to remove as many legacy authentication methods as it can from Microsoft 365. This is part of Microsoft’s Secure Future Initiative, launched by Brad Smith in November 2023. Since then Microsoft has experienced the Midnight Blizzard attack and upped the ante in terms of withdrawing legacy authentication whenever possible, like the withdrawal of Application Impersonation for Exchange Web Services (EWS) announced in March 2024.

The replacement is a technology called Nested App Authentication (NAA), announced in preview on April 9, 2024 (Microsoft also posted to the Technical Community, but it was easy to miss). According to Microsoft, “NAA provides simpler authentication and top tier identity protection through APIs designed specifically for add-ins in Office hosts.”

The Impact on Outlook Add-in Developers

Microsoft’s developer blog makes it seem simple to adopt NAA, listing five steps:

• Register an Entra ID application for use with the add-in. The application will hold consent for the Graph permissions needed by the add-in.
• Update redirect URIs to support trusted brokers.
• Update the add-in’s MSAL.js configuration to allow native bridging.
• Add a fall-back authentication method.
• Test the add-in.

However, the simplicity of Microsoft’s approach understates the work they expect developers of Outlook add-ins will do:

• Review their Outlook integrated add-ins to identify where legacy authentication is used.
• Switch from Exchange user identity tokens and callback tokens to use NAA. The big advantage delivered by NAA is that it’s integrated with Entra ID and supports its advanced set of authentication capabilities.
• Use Graph APIs to access Exchange Online data instead of EWS and the Outlook REST API. Microsoft has already announced that they will block access for EWS to Exchange Online from October 2026.
• Test with multiple versions of Outlook. Microsoft is due to support the classic Outlook client until 2029.
• Contact customers who use the older versions of the add-ins.
• Deliver production-quality code to customers.

Even with help from something like GitHub Copilot, there’s a significant amount of work here. NAA is only just in preview, so a limited amount of practical experience exists of its use with add-ins. Perhaps Microsoft will reveal more information at the Build Conference next week.

Equipped with knowledge or not, the work must be done before Microsoft turns off the legacy authentication methods at a so far indeterminate date sometime in October 2024. The change only affects Exchange Online. Outlook add-ins can continue to use the legacy authentication methods to connect to Exchange on-premises servers. Of course, this creates a further complication for developers who create add-ins used hybrid environments because their code must be able to handle connections to on-premises and cloud servers.

Reviewing Personal Use of Outlook Add-ins

I don’t use many Outlook add-ins myself, and those that I do are produced by Microsoft (Figure 1). I assume that Microsoft will take care of these add-ins in due course.

A quick scan around the internet reveals the presence of many Outlook add-ins created by third parties (here’s an example). I’m not quite as sanguine that all the third party add-ins will have quite the same smooth upgrade. If you’re a tenant administrator, it’s a good idea to ask people what add-ins they use and start to build a list of add-ins in active use.

A Better Future

Everyone wants better security, and we currently suffer from the effects of using technology developed for use in on-premises environments in the more challenging world of cloud systems. Over the long terms, there’s no doubt that technologies like NAA and the Graph are the right way to go will help close holes that attackers could potentially exploit.

The big problem is lack of time. October 2024 will come very quickly and if tenants don’t know that they need to update Outlook add-ins, they’re going to get a hell of a shock when Microsoft disables the legacy authentication methods and add-ins cannot connect to Exchange Online. I’m not sure that every developer reads Microsoft’s developer blog diligently, so it’s entirely possible that some add-ins won’t receive the attention they need before the big turn-off. Allied to the inability to audit the use of Outlook add-ins within a tenant and all the components of a big mess are coming together. I hope that I’m wrong.

Learn about using 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 important and how best to protect your tenant.

Follow Response Advances the State of the Calendar Art

It’s genuinely difficult to find innovation in calendaring. After so many years of so many people working on developing features to make user and shared calendars as productive as possible, it’s seldom that a new capability appears that makes people sit up and take notice. I think that the Follow option (MC786325, 26 April 2024, Microsoft 365 roadmap item 154557) is in that category, especially for those with heavily-scheduled calendars. The option rolled out to targeted release tenants in late April 2024. General availability is expected to start in mid-June 2024 and complete by the end of July 2024.

The Follow option is available when responding to meeting requests in OWA, the Monarch client, and Teams. The option is not currently available in Outlook classic (Windows or Mac) or Outlook mobile. If meeting organizers use Outlook classic, they see Follow responses as tentative. This problem will disappear after Microsoft upgrades Outlook classic to support Follow responses, as I hope they do soon.

Essentially, instead of accepting or declining a meeting, a meeting participant can indicate that they are interested in the meeting content and want to stay informed, even if they can’t attend in person or online.

Meeting Artefacts Core Underpinning for Follow Responses

Follow is a feature made possible by the preservation of meeting artefacts such as chat, transcribe, meeting recap, and shared files. It’s great that these elements capture what happened during a meeting and are available afterward for review, but until now the items have only been available to meeting participants. If you decline a meeting, you become a non-participant and have zero access.

You can’t respond to every calendar meeting request with Follow. It wouldn’t make sense to Follow a one-to-one meeting because you’re telling the other person that they can go ahead with the meeting but you’re not going to be there. In short, a meeting’s got to have enough participants to happen even if you’re absent.

Two big things happen if you respond to a meeting request with Follow (Figure 1). First, the meeting remains on your calendar. However, your availability is unaffected because a followed meeting does not block out time, meaning that it’s possible to accept another (more important) meeting. Second, you retain access to meeting artefacts.

Meeting Organizers Responsibilities

Obviously, if a meeting organizer receives some Follow responses (Figure 2), it’s a big hint for them to make sure that the meeting is recorded and transcribed. The text shown in the meeting response is part of the meeting body, so it appears in all versions of Outlook, even when a meeting organizer uses Outlook classic and sees a Follow response as tentative.

To remind the organizer what they should do to facilitate those following the meeting, Teams prompts the meeting organizer when they join the meeting to take action to record the proceedings (Figure 3).

I often use Copilot for Microsoft 365 to generate a summary of the key points and action items that I then edit to add emphasis (and correct some of Copilot’s little flaws) before circulating the information via email. Sure, this isn’t the same as making the data available through Teams, but some appreciate getting the quick summary via email.

A Real Improvement

Adding an onsite status for a meeting is another example of where Microsoft is developing the calendar app. It’s a worthy change, but it’s not of the same import as the Follow response. This feature is something to bring to the attention of people who make heavy use of their calendars.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Removing the Share to Teams Outlook Add-in

I’ve never had more than a passing relationship with Microsoft 365 integrated apps (Figure 1). The most I have done is deploy some Outlook add-ins to Exchange Online mailboxes like the Message Header Analyzer.

All of which meant that I probably wasn’t the best person to ask how to remove the Share to Teams Outlook add-in for selected mailboxes. The Share to Teams add-in allows an Outlook user to post a message from Outlook to a one-to-one or group chat or to create a new conversation in a team channel (Figure 2).

Essentially, the add-on signs into Teams for the user and posts the message using a Graph API request. The add-on only works for the user’s home tenant. You can’t use it to post as a guest member to a host tenant. I quite like the add-in but admit that I don’t use it very often. At this point, Share to Teams seems like something that Microsoft had to develop to help people move from email-centric work habits to the chat-based nature of Teams.

Whether Share to Teams helped very much is an open question, but its existence was probably enough to reassure people that it is possible to send information to and from between Outlook and Teams, which has an equivalent Share to Outlook feature to transmit messages in the opposite direction.

Exchange Online App Management Cmdlets

Some research revealed that PowerShell offers a viable solution. The Exchange Online management module contains cmdlets to create, list, remove, and disable apps. For instance, the Get-App cmdlet reveals details of the installed apps for a mailbox:

Get-App -Mailbox lotte.vetler | Format-Table AppId, DisplayName, ProviderName

AppId                                DisplayName             ProviderName
-----                                -----------             ------------
131a8b55-bd40-4fec-b2e6-d68bf5929976 Translator              Microsoft
afde34e6-58a4-4122-8a52-ef402180a878 Polls                   Microsoft Corporation
545d8236-721a-468f-85d8-254eca7cb0da Share to Teams          Microsoft
6b47614e-0125-454b-9f76-bd5aef85ac7b Send to OneNote         Microsoft Corporation
fe93bfe1-7947-460a-a5e0-7a5906b51360 Viva Insights           Microsoft
62916641-fc48-44ae-a2a3-163811f1c945 Message Header Analyzer Stephen Griffin
6046742c-3aee-485e-a4ac-92ab7199db2e Report Message          Microsoft Corporation
c61bb978-adb2-4344-abe9-d599aa75704f EmailTranslator V1.1    Avishkaram
f60b8ac7-c3e3-4e42-8dad-e4e1fea59ff7 Action Items            Microsoft
7a774f0c-7a6f-11e0-85ad-07fb4824019b Bing Maps               Microsoft
a216ceed-7791-4635-a752-5a4ac0a5eb93 My Templates            Microsoft
bc13b9d0-5ba2-446a-956b-c583bdc94d5e Suggested Meetings      Microsoft
d39dee0e-fdc3-4015-af8d-94d4d49294b3 Unsubscribe             Microsoft

The AppId identifier is important because it’s the required value to pass to tell the cmdlet which app to manage.

Scripting Disabling an App

The first task is to identify the set of mailboxes to process. I don’t know why the desire existed to remove the Share to Teams add-in. Perhaps it’s because a division within the company has decided that their users should not use the add-in. Maybe some senior manager took a dislike to the add-in. Or maybe it’s the result of a decision to separate Outlook and Teams communications. For whatever reason, it’s still important to find mailboxes to process. You can do this with the Get-ExoMailbox cmdlet.

Once the targets are identified, it’s a matter of looping through the mailboxes to use the Disable-App cmdlet to turn off the add-in for each mailbox. This code fetches a set of mailboxes based on a value in a custom attribute and checks each to extract the set of enabled apps. If that set includes the Share to Teams app, the Disable-App cmdlet turns Share to Teams off.

$TargetAppId = "545d8236-721a-468f-85d8-254eca7cb0da"  # Id for the Share to Teams app
$TargetAppName = "Share to Teams"
[int]$RemovedApps = 0
[array]$Mbx = Get-ExoMailbox -Filter {CustomAttribute9 -eq 'NoApp'} -RecipientTypeDetails UserMailbox
ForEach ($M in $Mbx) {
    Write-Host ("Checking mailbox {0} for the {1} app" -f $M.displayName, $TargetAppName)
    [array]$InstalledApps = Get-App -Mailbox $M.Alias | `
         Where-Object {$_.Enabled -eq $true} | Select-Object -ExpandProperty AppId
    If ($InstalledApps -contains $TargetAppId) {
        Write-Host ("Disabling app for {0}" -f $M.displayName) -ForegroundColor Yellow
        Disable-App -Identity $TargetAppId -Mailbox $M.Alias -Confirm:$False 
        $RemovedApps++
    } Else {
        Write-Host ("App {0} not installed for {1}" -f $TargetAppName, $M.displayName)
    }
}
Write-Host ("Removed {0} instances of the {1} app from {2} scanned mailboxes" -f $RemovedApps, $TargetAppName, $Mbx.count)

Disabling Outlook Add-ins Isn’t Immediate

It usually takes several hours before Outlook picks up the newly disabled status for the add-in. The app data is cached within the service and refreshed periodically. That refresh must happen before clients can detect the change. There’s nothing you can do to accelerate the process, so consume some of your favorite beverage and chill out.

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.

Aspects of Monarch Client Security and Privacy Highlighted, Especially Data Held in Azure

An April 4 posting on the respected security blog hosted by Bruce Schneier hyped the claim by Proton that the new Monarch client (aka the new Outlook for Windows) is “Microsoft’s new data collection service.” It’s repeats some of the overhyped shock and horror story that appeared in Germany in November 2023.

In this instance, it seems like a great deal of uninformed commentary intended to convince people to ditch Monarch and use another email client. That’s absolutely a choice that people are entitled to make, but it would be nice if they did so in a state of knowledge instead of reacting to classic FUD. The problem is all about perception and not really anything to do with security.

Understanding Monarch

Let’s recite some important points about the Monarch situation:

• The current version of the Monarch client replaced the Windows 11 Mail and Calendar apps for consumer users. The best thing about the old apps is that they were free for personal use. Apart from that, the apps weren’t great (and that’s being kind).
• Corporate users are in the opt-in stage of the Monarch development cycle that extends out to at least 2029 before Microsoft will replace the classic Outlook for Windows client. Some major functionality gaps remain for Microsoft to fill before corporate users are likely to want to even consider moving to what’s been called “a slightly prettier version of OWA.”
• Microsoft has acknowledged that their initial plans to replace classic Outlook with Monarch won’t fly. For instance, they removed the restriction that limited Outlook support for Copilot for Microsoft 365 to Monarch.
• Many consumer users have mailboxes on servers that they access using the POP3 and IMAP4 protocols. These are old mailbox access protocols (SMTP is needed to send messages) that don’t support many of the features of modern email clients, like the focused inbox or delayed send. Holding the message data in Azure also makes search much faster because the remote server doesn’t have to be contacted. In addition, if users take advantage of client-side features like flagging email for follow-up or categorizing messages, the data is stored in Azure and isn’t affected if the user workstation ever encounters a problem that requires a reinstallation of Windows.
• To make advanced features available to consumer users, Microsoft extracts messages from their host IMAP4 or POP3 servers and processes the messages in ‘phantom mailboxes’ stored in Azure. The Monarch client accesses the processed messages from the Azure mailboxes rather than the host servers.
• This kind of processing to add feature support is not new. The original Acompli client introduced the concept for their service in 2012. At that time, processing happened on Amazon Web Services. After Microsoft bought Acompli in late 2014 and renamed the client to be Outlook Mobile, they moved message processing to Azure. Outlook Mobile works like this today. In 2019, Microsoft said that over 100 million people used Outlook Mobile for iOS and Android. That number is likely much higher today.
• User passwords are needed to fetch email from host servers and process the messages on Azure. It would be possible to cache credentials for a single session, but then users would likely complain that they’re asked to enter passwords too often.

The situation is therefore that Microsoft synchronizes data from mail servers to Azure to process email so that it can make features available to Monarch using a technique that’s been used by hundreds of millions of users since 2012. Microsoft has not communicated how Monarch works with independent email servers in a clear and concise manner, and that’s probably the root cause of much of the criticism.

Letting Consumers Know What’s Happening

Proton is rightly concerned with privacy and highlighted the fact that Monarch displays a screen to inform users that Microsoft and its 801 partners process data for a variety of reasons, including the personation and measurement of ads. Email services have costs and the companies providing these services attempt to recover those costs in different ways. The golden rule is that if you don’t want to see ads, pay for your email service (client and server).

In this instance, because Microsoft partners with other companies to display ads in the Monarch client, they are forced by consumer protection legislation like the European Union’s Digital Services Act to inform end users that these arrangements are in place. Ads have appeared in the free version of the consumer version of OWA connected to Outlook.com (served by the same infrastructure that supports Exchange Online) for years. Outlook.com even includes an advertising preference settings panel to allow users to see details of the partners Microsoft works with (Figure 1). There’s nothing new about Microsoft email clients displaying ads. What’s different is Microsoft being forced to highlight the number of ad partners they work with.

I think consumers understand that they must pay in some way for the service they receive and while the ads are irritating and often unwelcome, they’re a fact of life associated with access to many services. It’s not as if we’re all innocent victims waiting to be gobbled up by the pernicious tactics of a malevolent Microsoft.

Getting Back to Monarch Client Security

If you use the Monarch client with a free personal account, you will see ads. If you use the Monarch client, it will use your credentials to synchronize with your server to process your email and make it suitable for consumption by the client. Does this mean that your personal security is compromised? I doubt it. Microsoft is rather good at managing credentials. Office 365 has more than 400 million paid seats and account compromise there is usually the result of password spray attacks, the root cause of which is often poor tenant administration (not enforcing MFA) or poor password choice by individual users.

Entra ID handles accounts and credentials for more than Office 365 (at least 610 million accounts) and there’s no evidence that Microsoft manages these accounts in anything but a reasonable manner.

At The End of the Day, It’s Consumer Choice

I am not an apologist for Microsoft. I don’t like seeing ads in any technology (but have tolerated it in many services over the years) and think that Microsoft is sometimes too eager to monetize its installed base. For instance, I hate the way that Microsoft thinks it can encourage Microsoft 365 accounts to attend certain technology conferences, and that’s in a paid-for service. I also find the insertion of paid-for messages in the inbox of Outlook.com users distasteful and an overreach. Direct injection of spam into an inbox (Figure 2) is never acceptable. Spending some more effort to block the obvious malware that arrives in inboxes instead of how to make users unhappy with planted ads would be a good thing for Microsoft to do.

It’s bad to have ads in Monarch, but would those who complain loudly now wish to pay for an ad-free client? If they do, then there’s plenty of services that are willing to take their money, including paid-for versions of Proton Mail (a free version is available). Or IMAP4 and POP3 users could move to a free client, like the ever-reliable Thunderbird. You pay your money and make your choice.

The New Outlook for Windows Won’t Replace Outlook Classic for Another Five Years

A March 7 Technical Community post laid out Microsoft’s plan to bring the new Outlook for Windows client (aka, Outlook Monarch, Figure 1) from its current state to general availability for commercial customers and eventually to replace the Outlook Classic (Win32) client.

The bottom line is that there’s lots of twists and turns to play out before the replacement of Outlook classic. Microsoft says that they will “continue to honor published support timelines for existing version of classic Outlook for Windows until at least 2029.” Whether Microsoft means January 2029 or December 2029 is immaterial at this point. The exact timeframe will be determined based on development progress between now and then.

Monarch Used by Consumer Clients

Monarch is already in use by consumer users where it replaces the old Windows Mail and Calendar clients. Although Monarch is a superior client, its introduction has been marked by a great deal of adverse comments about the way Microsoft uploads email data to its servers (here’s one example).

The problem is that Outlook supports connects to servers via obsolete email protocols like IMAP4 and POP3 but wants to deliver advanced features that aren’t available in the old protocols. The solution is to synchronize email from the servers to Microsoft’s cloud environment to process the email data to support functionality like the focused inbox. Outlook mobile uses the same mechanism, but Monarch’s usage seems to be considered different. It’s odd, but there you are.

Bringing the New Outlook for Windows to Commercial Customers

Commercial customers are different. They tend to send and receive higher volumes of email and use different features than consumers do. For instance, consumers don’t use the Teams Meeting add-in to schedule online meetings, nor do they protect email with sensitivity labels or keep messages in archive mailboxes, including expandable archives. And customer organizations and ISVs have created a bunch of add-ins for Outlook over the years, many of which are still in active use.

In their article, Microsoft points to the transition of Outlook for Mac users to the new version of that client and say that they plan to take the same approach with the new Outlook for Windows. The only problem is that the user base for Outlook Classic is much larger and more diverse in terms of add-ons than Outlook for Mac is. The complexities involved in moving users off Outlook Classic might just be more difficult than implied by Microsoft’s confident stance.

In any case, Microsoft’s plan unfolds over three phases (Figure 2):

• Opt-in. We’re currently in this phase. General availability for the new Outlook will happen during the phase.
• Opt-out. The new Outlook client becomes the default and users must opt-out to continue using Outlook Classic.
• Cutover. New deployments will only use the new Outlook and the ability to switch back to Outlook Classic disappears. Eventually, Microsoft will cease support for Outlook Classic and might block connections at this point.

Monarch Still Lacks Features

During the development process, Microsoft has added many features to satisfy customers such as support for personal email accounts. However, some major pieces of functionality that are important to corporate customers are still missing, the most notable being the lack of support for PST files and the ability to work offline (a true strength of Outlook Classic since the introduce of drizzle-mode synchronization in Outlook 2003).

Without these features, Monarch resembles a slightly prettier and better client than the standard OWA for Exchange Online. And if people have chosen to use Outlook Classic instead of OWA, they’re not going to be tempted to use the new client until it supports all the features that they’ve come to depend on in Outlook Classic. Further difficulties arise in the need to convert COM or VSTO-based add-ins, which aren’t supported by the new client, to the new add-in model.

The Need for Balance

It’s good that Microsoft has laid out the availability timeline for Outlook over the next five years. It’s in Microsoft’s interests to get to the new Outlook (reduced engineering expenses and less complexity in the Outlook client family) but they can’t make customers (or rather, too many customers) unhappy through the transition. Achieving their goal will force Microsoft to walk a tightrope. Let’s hope that they don’t inconvenience too many people along the way. I think Outlook Classic will make it past 2029. The only question is “how long?”

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Outlook Win32 Copilot Support Coming. Teams Gets a Better Integration

After removing the major barriers blocking adoption of Microsoft 365 Copilot last month, Microsoft has quietly dropped its insistence that Copilot would only support the Outlook Monarch client. The latest version of the Microsoft 365 Copilot requirements documentation (2 February 2024) says that Copilot works with the new Outlook client on Windows and Mac (Outlook mobile is also supported) and then notes that “Microsoft Copilot for Microsoft 365 will be supported on classic Outlook for Windows (Win32 desktop app) in the future.”

A link to the Microsoft 365 roadmap lists three items relating to the introduction of Copilot functionality in the classic Outlook client together with dates when the rollout is supposed to start:

• Coaching by Copilot (190927) –February 2024
• Draft by Copilot (190937) – March 2024. Figure 1 shows the draft created by Copilot in OWA.
• Summarize by Copilot (180900) –November 2023

According to the items, Microsoft added 190927 and 190937 on 6 December 2023, and 180900 on December 10, 2023. Don’t pay too much attention to the purported rollout dates until you see a Microsoft 365 message center announcement describing when the new functionality will be available in the preview and other Office channel. Even then, announced dates are often optimistic and end up being delayed. I’m pretty sure that Outlook Win32 support will only extend to the subscription version of Outlook packaged in Microsoft 365 enterprise apps, but we’ll see when Microsoft shares more details.

No Formal Announcement for Outlook Win32 Copilot Support

Speaking of details, I can’t find a formal Microsoft announcement about the change in direction. Ever since the original Copilot for Microsoft 365 announcement in March 2023, Microsoft held to the line that Monarch was the only supported Outlook desktop client. As I noted in August, this position applied despite the fact that Microsoft’s One Outlook program includes the ability for Outlook desktop to use code developed for Monarch/OWA. The only logical conclusion is that Microsoft hoped to use Copilot to drive customers to embrace Monarch.

The sad fact is that Monarch is still not fit for purpose in the eyes of many Outlook users. The lack of offline access and PST support are just two issues that must be addressed before Monarch has a chance to replace the classic client.

Although they’re rolling Monarch out as a replacement for the standard Windows mail and calendar client, Microsoft knows that the software lacks many features needed for success in commercial environments. All the missing functionality is on a list for development, but the fact remains that it’s very hard to force people to change to a client that doesn’t do what they need, and this became a blocking factor for Copilot adoption.

Given that making it easy for customers to use Copilot is much more important for Microsoft than achieving an earlier switchover to Monarch is, the choice for senior management must have been simple, and that’s probably why the restriction is gone. Customers will applaud the new reality.

New Copilot Experience in Teams

Meanwhile, on February 12, Microsoft announced a new Copilot experience in Teams. Like the rest of Teams, the experience is in the form of an app that administrators can control through setup policies. According to Microsoft, the major changes are better prompts, access to Copilot Lab to see prompts that you might use, and a list of your Copilot chat history.

The app delivers a chat experience, so it should come as no surprise that Teams can store and reveal previous interactions with Copilot. The chat messages are captured for compliance purposes, just like personal and group chats, and can be retrieved by content searches for eDiscovery.

Just to be sure that Copilot support for Outlook Win32 is a reality, I asked Copilot in Teams (Figure 2) about Outlook Win32 Copilot support. After thinking for a bit, Copilot duly responded to confirm support and noted two references, one being the requirements documentation, the other a document stored in a SharePoint Online site. Website content is only available to Copilot if enabled for the tenant and the user chooses to enable it for searches.

More Change Coming

I suspect that the Copilot for Microsoft 365 journey will have other ups and downs as customers identify and Microsoft removes barriers to adoption, problems, bugs, and other issues. Like the initial development of Teams in the 2017-2020 period (albeit accelerated in some part by the Covid pandemic), I expect lots of change. Stay tuned.

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.

Conditional Access MFA Gives Outlook Desktop a Problem with Protected Email

I think most Microsoft 365 tenant administrators would agree that multifactor authentication (MFA) is a good thing. MFA stops bad guys compromising accounts even if they have the password. Microsoft’s recent little bother with Midnight Blizzard could have been cut off had the account whose password was uncovered by a password spray attack been protected with MFA.

Sensitivity labels are also good in terms of their ability to protect sensitive Office documents and PDF files with encryption. The usage rights assigned in sensitivity labels stop people who don’t have access from being able to decrypt and view the content of protected files.

Two good things create a warm feeling of snug protection, or so it might seem. That is, until conditional access policies get in the way. Specifically, conditional access policies that insist on MFA for all cloud apps without exclusions. This seems like a very good kind of policy because it enforces MFA before users can connect to OWA, the new Outlook “Monarch” client, SharePoint Online, Teams, and so on. However, “all cloud apps” means all cloud apps, including the Microsoft Rights Management Services app. This is a multi-tenant app that exists in tenants that use Microsoft Information Protection, the basis of the encryption applied by sensitivity labels to protect files.

Get-MgServicePrincipal -filter "displayname eq 'Microsoft Rights Management Services'" | Format-Table DisplayName, AppId, SignInAudience

DisplayName                          AppId                                SignInAudience
-----------                          -----                                --------------
Microsoft Rights Management Services 00000012-0000-0000-c000-000000000000 AzureADMultipleOrgs

Let’s assume that you deploy a conditional access policy to enforce MFA for all cloud apps. With this configuration in place, users generate and send some protected email by applying sensitivity labels with encryption. Some messages go to external recipients, but that’s OK because the usage rights defined in the labels allow the external recipients to access the content.

The Problem with MFA for All Cloud Apps

All works wonderfully if the external recipients use OWA, Monarch, or Outlook Mobile to read the messages. Decryption for these clients is managed by Exchange Online, which obtains the necessary use licenses to allow the clients to access the content. However, Outlook desktop (Win32) uses a different scheme and must obtain use licenses from Microsoft Rights Management Services running on the originating (your) tenant. This is when you see the dialog telling you that Outlook is configuring the computer for Information Rights Management (Figure 1).

But the conditional access policy in the sending tenant insists on MFA for all cloud apps and there’s no way for Outlook to satisfy an MFA challenge in your tenant. Deprived of the use license, Outlook falls back to displaying the RPMSG wrapper for the message (Figure 2).

Clicking the read the message link brings the user to the Office 365 Message Encryption portal, where they can read the message. This proves that the usage rights given to the user allow access. The problem lies with not being able to obtain the use license due to the MFA challenge.

Excluding Microsoft Rights Management Services

The simple solution is to exclude the Microsoft Rights Management Services app from all conditional access policies that enforce MFA for user connections. This is easily done by editing policies through the Entra admin center (Figure 4).

PowerShell makes it easy to scan and update conditional access policies in the tenant. A similar approach to the one to add breakglass accounts to conditional access policies can be used to add an exclusion to policies.

The script (available from GitHub) performs these steps.

• Connects to the Microsoft Graph PowerShell SDK.
• Runs the Get-MgIdentityConditionalAccessPolicy cmdlet to find the set of enabled conditional access policies.
• Checks each policy to see if an exclusion for the Microsoft Rights Management Services app is present.
• If no exclusion is present, the script checks if the policy uses MFA (with or without authentication strength) as a control.
• If the policy applies MFA, the script checks if a forced password change is set (this eliminates the possibility of adding an app exclusion) and that the policy doesn’t use an authentication context. Both prevent the addition of an excluded app to the policy.

Once it’s sure that an exclusion is possible, the script adds the exclusion. Figure 5 shows the script in action.

It’s an Ecosystem Thing

It’s unfortunate when a clash occurs between two important parts of the Microsoft 365 ecosystem. It’s a reminder to us all about the importance of taking a holistic view of functionality instead of focusing on a single workload. Some will think that this problem is something that Microsoft testing should have found. That’s a fair perspective, and Microsoft’s documentation does cover some potential issues with conditional access and encrypted documents, but it’s unlikely that the testing regime considers how sensitivity labels work with Outlook desktop for external recipients when MFA is involved.

Any debate must be tempered by the realization that the clash appeared due to the increased usage of multifactor authentication (due to incessant campaigning by Microsoft) allied to increased use of sensitivity labels to protect information. Both are good trends.

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.

Preserve Declined Meetings in Calendars to Retain Meeting Notices

Announced in message center notification MC684218 (26 October 2023, Microsoft 365 roadmap item 154056), the ability to enable the preservation of details for declined meetings is now available in the OWA and Outlook Monarch (the “New Outlook”) clients (Figure 1).

The setting is also controllable through the Set-MailboxCalendarConfiguration cmdlet. This command enables saving of declined events for a mailbox:

Set-MailboxCalendarConfiguration -Identity Kim.Akers -PreserveDeclinedMeetings:$true

There’s no organization-wide control to preserve declined meetings. Because it’s an individual choice to keep declined meetings in a calendar, the setting must be enabled for individual mailboxes. However, to enable the setting for all user mailboxes, it’s easy to do this with PowerShell:

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
ForEach ($M in $Mbx) {
   Set-MailboxCalendarConfiguration -Identity $M.UserPrincipalName -PreserveDeclinedMeetings:$true
}

Enabling any calendar setting for a mailbox isn’t fast but it should be a one-time operation. On the other hand, the setting must be enabled for new mailboxes as they are created.

Why It’s a Good Idea to Preserve Declined Meetings

Ever since the first version of Outlook appeared in 1997, when people decline an incoming meeting, Outlook removes all details of the meeting to keep the calendar clear and not block time that might be needed for another event. This scheme works well but it means that once someone declines an inbound meeting, they have no further knowledge about the meeting even if they have no intention of attending the event. They can forward the meeting invitation to someone else (if meeting settings permit forwarding), review any attachments included with the invitation or access content created during a meeting such as the meeting chat or meeting recap (if it’s a Teams meeting). Alternatively, they can decide to attend the meeting if their schedule clears up.

Preserving declined meetings means that Outlook enters details of an event in an invitee’s calendar but does not block the event time in the user’s free/busy data. This means that the Outlook scheduling assistant regards the slot as available and can be used for other meetings.

As a Microsoft MVP, I receive many meetings organized by Microsoft engineering group to discuss new product details. Some of these events are interesting, but only if I can find time to attend. Having the calendar retain the event details allows me to go back to attend an event when I can.

No Declined Meetings for Outlook Desktop

Outlook desktop doesn’t obey the settings used by OWA and Monarch. Its settings are often implemented in values held in the system registry. Even if its implementation has caused some difficulties, roaming signatures are a good example of how Microsoft is moving Outlook desktop from its PC-centric heritage to cloud settings.

With this in mind, it shouldn’t be a surprise to learn that meetings declined using Outlook desktop are not preserved. Meetings declined using the Outlook for Mac and Outlook mobile clients are preserved, even if their UI doesn’t include the ability to control the setting.

Declined meetings kept in the calendar are the same as any other calendar events (Figure 2). The sole difference is that the event doesn’t occupy a slot in the user’s free/busy data. Because the meetings are calendar events, they show up as normal in all clients and any other application that uses calendar data.

If the user changes their response and accepts the meeting, Outlook updates the calendar event and reserves the time in the user’s free/busy data.

A Change in Habit

Microsoft doesn’t make changes like this without some form of feedback that points out why a new approach is necessary. I don’t know if the input came from customers or from inside Microsoft, but I suspect that the driving factor is the increasing amount of information shared with meeting invitations and added to events during Teams calls. Being able to go direct to the event makes it a lot easier for meeting participants to access the information, even if they choose to decline the invitation to attend.

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.

Outlook Voice Dictation Supported by Monarch and OWA

Announced in message center notification MC679312 (4 October, 2023, Microsoft 365 roadmap item 171199), the ability to dictate the body text for Outlook messages is now rolling out to all tenants with the intention that Microsoft will complete the deployment in early December 2023.

The title of MC679312 is “Dictation Support Coming to the new Outlook,” which implies that this feature is only for the Monarch client, but message text dictation works for OWA too.

Setting up for Outlook Voice Dictation

The basic idea is that you can turn on a PC microphone when composing a new email and speak instead of writing the message body. Outlook connects to the Microsoft Azure speech-to-text service (hence the need for a “reliable internet connection” to translate words captured by the microphone into text. Transcribing audio to text is well-known within Microsoft 365. It’s the basis for meeting transcription in Teams and video transcripts in Stream.

To begin, make sure that the PC microphone is enabled before creating a new message. When positioned in the message body (voice dictation doesn’t work for the message subject or to select recipients), select the Dictate (blue microphone icon) option and the language you plan to speak in. As Figure 1 shows, Outlook supports a limited set of languages for now with another set in preview. Microsoft Azure speech-to-text can handle “more than 100 languages and variants,” so it’s likely that the set of available languages will expand over time to deal with all languages supported by Outlook.

I was impressed to find Gaeilge (Irish Gaelic) in the list of preview languages (the list of preview languages is much longer than shown in Figure 1).

Switching languages is easy and it’s possible to compose a message in multiple languages, assuming that you have sufficient fluency in the target languages to create passible text. My efforts in Irish were OK but my French accent proved an obstacle that dictation (or the back-end voice processing service) had difficulty with. In any case, it was fun testing out languages.

Composing Messages with Outlook Voice Dictation

After settling on your preferred language, dictation can start. I found that a slight delay occurred between selecting the Dictation option and a beep indicating that the microphone was ready to accept input. Perhaps this is due to the need to connect to the Azure transcription service.

Once connected, composing message text is a matter of speaking normally. Microsoft says that voice dictation is “a quick and easy way to draft emails, send replies, and capture the tone you’re going for.” I’m not sure that dictation is any faster than typing, especially with the help of intelligent editors, but that applies to people with good typing skills. Those who struggle to compose message text might well find it easier to speak and edit the output before sending the message.

Figure 2 shows a message that I composed with voice dictation. You can see that dictation captured double instances of words twice (easily fixed). The output text is very usable if you don’t mumble or say “Uh” too often.

Creating Better Text Output

Microsoft says that Azure transcription has “automatic formatting and punctuation.” Perhaps Outlook doesn’t use this functionality because the text I generated seemed like a real stream of consciousness devoid of punctuation. To have any punctuation, you need to remember to use commands like:

• Full stop.
• Comma.
• New line.
• New paragraph.

I haven’t yet worked out how to insert a quotation or to bold, or underline text. On the other hand, I discovered that the profanity filter works when I swore at my inability to master dictation.

Outlook voice dictation doesn’t seem to use the Azure speech-to-text disfluency removal feature. This cleans up “stutter, duplicate words, and … filler words like uhm or uh” to produce text that reads better.

Dictation only works when the compose message window is active. If you move focus to another application, like switching to a document to check a fact, the connection to Azure drops and dictation stops. The connection also drops if you pause and don’t speak for more than ten seconds (approximately). I can understand why voice dictation works like this. It would be wasteful to persist a connection while waiting for the user to return and produce some more pearls of wisdom. However, it’s something to remember as no one likes to speak into a message without generating text.

Fixing Dictated Text is a Copilot Thing

Being able to rewrite and improve text is one of the benefits advanced for generative AI. I asked Bing Chat Enterprise (BCE, soon to be plain “Copilot”) to add the missing punctation from text generated from speech and then make the text more concise (you could equally use ChatGPT or Bing Chat to do the job). The output was very good and it’s easier to do this than rewriting the raw text. Interacting with BCE required me to copy text to BCE, run the prompt, and paste the amended text (Figure 3) back into the Outlook message.

Using an external generative AI is slightly clunky, but it works and is a lot cheaper than paying $30/month for the fully-integrated Microsoft 365 Copilot. Admittedly, Microsoft 365 Copilot offers many more features and functions and no one would ever buy it simply to improve text. Or would they?

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.

Disallow Outlook Reactions with Clients or Mail Flow Rules

Introduced in October 2022 as a method to allow people to respond to email with an emoji instead of a traditional reply message, I think it’s fair to say that customer opinion about Outlook reactions is divided. Some think that being able to send back a heart or thumbs-up is a fantastic and simple way to respond to email. Others dismiss the idea as a valueless frippery.

In a September 2023 blog post, Microsoft describes how organizations can control the sending of reactions and new client options to allow users block reactions for individual messages. The assertion that “millions of reactions are used every day” seems impressive but needs to be viewed in the context of 400 million Office 365 users and the 9.2 billion emails handled by Exchange Online daily (figure from MEC 2022 presentation). The blog says that Microsoft realizes that granular control over reactions, especially for email where it might not be appropriate to respond with an emoji, is important.

How the Disallow Reactions Option Works

All of which brings us to the functionality described in message center notification MC670444 (last updated 19 September, 2023) and Microsoft 365 roadmap item 117433. Essentially, the controls boil down to two technical changes.

First, the OWA and New Outlook (Monarch) clients have a new message option that senders can apply to disallow reactions for individual messages. Microsoft says that support for Outlook desktop and the Outlook mobile clients will “follow at a later date.” Figure 1 shows the option to disallow reactions in the OWA new message creation window.

When a client disallows reactions, it stamps the message with the x-ms-reactions header set to “disallow.” Clients that receive a message stamped with x-ms-reactions set to “disallow” remove the ability of the recipient to respond with an emoji. Figure 2 shows the presence of the x-ms-reactions header with disallow set. The existence of the header forces OWA to disable the option to reaction to the message.

Second, the Exchange Online transport service implements a check for the x-ms-reactions message header as email flows through the transport pipeline. If a user responds to a message with an emoji using a client that doesn’t support disallowed reactions (like Outlook desktop), the transport service stops the response being updated for the original message. To implement organization-wide blocks, tenants can deploy mail flow rules to apply the header to specific messages.

Mail Flow Rules to Disable Reactions

The Exchange Online transport service applies mail flow rules to each message as it passes through the transport pipeline. One of the actions available for mail flow rules is to modify message properties by setting a message header. Figure 3 shows an example of a mail flow rule to set the x-ms-reactions header for all messages sent between people within the organization with the exception of messages with “Congratulations” or “Announcements” in the message body or subject.

A variation on the rule is to disallow reactions for any messages sent by selected people. For instance, all email sent by senior executives, or everyone working in a country where emoji responses are deemed unacceptable by local custom.

The net effect of disallowing reactions through mail flow rules is that the only messages that people can respond to with emojis are those that match exceptions granted in the rules. Figure 4 shows a message that matches the exception included in the rule illustrated in Figure 3. You can see that OWA UI reveals the option to allow the recipient to respond with an emoji.

Administrative Controls Often Lag Behind New Features

Some will wonder why it took Microsoft a year to introduce controls for Outlook reactions. It’s always better when new features come along with administrative controls but it seems like the rush to introduce new functionality in cloud systems means that the surrounding administrative framework is lacking. That’s a pity, but at least the necessary controls are now available.

Learn about using 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 important and how best to protect your tenant.

Storm in a Teacup as the New Outlook Appears

There’s a lot of fuss and bother about the new Outlook client (aka Monarch) caused by an article in a German website that begins with the assertion that “The new free Outlook … sends secret credentials to Microsoft.” Quelle surprise! It goes on to say “But beware: If you try the new Outlook, you risk transferring your IMAP and SMTP access data to mail accounts as well as all mails to Microsoft servers.” The author concludes that synchronization (which is what happens) of email and credentials “allows Microsoft to read the mails.”

I fear that the article falls firmly into the category of hysterical clickbait. However, its assertions will cause worry and concern for people who don’t fancy the idea of transferring information to the cloud where the cloud provider might possibly access their data. This hasn’t worried the hundreds of millions of people who use Gmail or the 400 million users of Office 365, but I can understand the concerns expressed by others.

Sending Plain Text Credentials

The author is very upset that Microsoft stores IMAP4 and SMTP credentials for user accounts (I’m pretty sure that this happens for POP3 too). Outlook sends these plain-text credentials over a TLS connection. I guess Microsoft could enforce some form of modern authentication with Monarch, but that requires the mail servers it connects with to support modern authentication, and that’s not going to happen for most IMAP4 and POP3 connections. So credentials must be plain text to allow Outlook to connect to the servers that host user accounts (Outlook does use OAuth2 to connect to Google accounts, and uses that access to synchronize data from those accounts).

Synchronization of User Data in Azure

The author is also upset that Microsoft synchronizes user email data to Azure. This is the same mechanism as Outlook mobile has used since Microsoft moved from the AWS-based infrastructure used by the original Acompli client (bought by Microsoft in 2014) to Azure in 2018. Data is held in special forms of mailboxes that cannot be accessed by normal email clients and it’s stored like this to make functions like search and the focused inbox work.

If Outlook did not synchronize email, contacts, and calendar items to Azure, the client would be limited to whatever features are supported by IMAP4, an obsolete email access protocol that only persists because the standards community has not developed a replacement. Moving copies of items to Azure allows background processes to make the data more like the information retrieved from a full-blown Exchange Online server. If you want, massaging the data makes it possible for Outlook to work with the data as if it came from Exchange.

The New Outlook is a Better Client

The mail client is part of Windows and has changed dramatically as Windows evolved. Few would want to go back to Outlook Express at this point. The latest change benefits users because they get more feature and a better client. Microsoft also gains through reduced engineering expenses by eliminating a client from its mix of mail clients. Comparing the old Windows mail client to Outlook is like comparing the default mail client on a smartphone to Outlook mobile. Both will do the basics of sending and receiving email, but Outlook mobile does much more besides.

It’s reasonable to be concerned about the storage of email data but people do have a choice. To get the additional functionality (see the list of features enabled by synchronization), they can use the new Outlook. On the other hand, if they fear that Microsoft might compromise their information (an infinitesimal and highly unlikely occurrence) they can use another client. This is called user choice.

Other Clients Available

The simple solution for those unhappy about the way the new Outlook works is to seek an alternative. Fortunately, many other free email clients are available, such as the well-respected Thunderbird IMAP4 client. The latest versions of the Thunderbird client support OAuth2 connections, including to Exchange Online, proving that not all IMAP4 connections depend on plain-text credentials.

The combination of server and client create a secure connection. Perhaps people should worry more if the server hosting their mailbox still uses basic authentication and clients send plain-text credentials to the server. In this situation, accounts are more likely to be compromised by attack techniques such as password sprays. I’d be a lot more worried about compromise of accounts on servers that use basic authentication than attackers gaining access to email data stored in Azure.

To me, this is a storm in a teacup. Once people think through how and why Microsoft synchronizes email data to make the new Outlook work better, I think they’ll be OK with the mechanism used. I’ve never worried about the processing of email data for mobile Outlook and I doubt that it’ll cause me any concern for Monarch.

Microsoft Gives Tenants More Time to Prepare for Roaming Signatures

Announced in MC684213 (26 October 2023), Microsoft is helping customers who struggle with the introduction of roaming signatures for Outlook by allowing them to postpone the implementation in tenants. This is a good idea, but it’s sad that Microsoft has taken so long to sort out what seems to be a reasonably straightforward feature. First promised in summer 2020 (when I noted that signature management is complex), Microsoft’s development of the feature ran into problems and eventually in July 2022, they announced that roaming signatures wouldn’t be available until October 2022. A year later, we’re still struggling to deal with roaming signatures across the Outlook client family.

The background is that OWA stores its signature information as mailbox settings. This implementation makes it easy for administrators to check if mailboxes have signatures configured and if not, make the necessary changes. By comparison, Outlook desktop (for Windows) traditionally stores its signature information in Outlook profiles in the system registry. The implementation goes back to the earliest days of Outlook desktop, now over 25 years old, and is much more difficult to deal with in terms of configuring standard signatures.

The Solution for Roaming Signatures

Microsoft’s solution stores signature information for Outlook clients in a hidden mailbox folder (visible using the MFCMAPI utility). This is a good approach because it means that the same signature information is available to any Outlook client that connects to the mailbox.

However, roaming signatures cause problems for OWA because the Set-MailboxMessageConfiguration cmdlet used to configure the mailbox settings for OWA signatures doesn’t work when a tenant uses roaming signatures. In essence, when roaming signatures are active within a tenant, OWA ignores the settings configured with Set-MailboxMessageConfiguration. That’s unacceptable when customers invest a lot of work to develop PowerShell scripts to manage signatures for users. Naturally, these customers were very unhappy when they discovered that Microsoft introduced a new problem for OWA by addressing the roaming signatures issue for Outlook desktop.

The problem has been known for well over a year at this point and it’s unknown why Microsoft has been so slow to respond. Perhaps it’s an instance of when the solution for a problem has always seemed to be close at hand without ever being attainable.

New Organization Setting to Postpone Roaming Signatures

The latest initiative is that Microsoft has implemented an Exchange Online configuration setting called PostponeRoamingSignaturesUntilLater. If set to True (or 1), Exchange Online disables roaming signatures for OWA and the Monarch client. This means that PowerShell scripts developed to manage OWA signatures with the Set-MailboxMessageConfiguration continue to work.

Set-OrganizationConfig -PostponeRoamingSignaturesUntilLater $true

This setting only affects OWA and Monarch. It has no effect on Outlook desktop clients.

Many tenants can already update this setting in their tenant. Microsoft will complete deployment to all tenants by mid-November 2023. By default, the setting is False, meaning that Outlook desktop clients can use roaming signatures.

Note the PostponeRoamingSignaturesUntilLater name chosen for the setting. This is a postponement. Microsoft plans to make roaming signatures the norm for Exchange Online in the future, once they’ve sorted out the problems that currently make it difficult for OWA to deal with the data stored in the hidden mailbox.

The change gives tenant administrators control over a mess that Microsoft caused. It’s good because previously administrators had to file a support request to have Microsoft disable roaming signatures through some backend process. However, the need for such a

Microsoft says that the only way to disable roaming signatures for Outlook desktop, remains to apply a registry setting.

ISVs and Roaming Signatures

Many third-party signature management solutions are available for Exchange Online. When Microsoft updates how Outlook clients fetch signature data, the change impacts the ISV products. Microsoft says that they are now working to deliver API support for roaming signatures so that ISV products can manage signatures in the mailbox location.

Given the length of time Microsoft has been working on the roaming signatures problem, it’s curious that the API is not already available. But then again, Microsoft’s history of helping ISVs working in this space has been patchy with many issues in the past. I thought things had turned the corner in 2020, but that improvement doesn’t appear to have persisted.

A Hard Computing Problem

I know things are complex anytime you try and work with Outlook desktop. That’s probably one of the reasons why Microsoft is gung-ho to prepare the current client with Monarch. It takes too long to innovate, too long to change the UI, too long to do anything. Even so, it’s hard to understand why developing a new mechanism for roaming signatures can have taken quite so long. I guess it’s one of those hard computing problems!

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.

Changing Outlook for the Better

It’s amazing (or surprising) when developers find new GUI tweaks to add to a 26-year old software program. Two recent changes to Outlook seem worthy of note, even if one appears in the Outlook Monarch client rather than the classic desktop client, which isn’t quite 26 years old.

The first covers “Find Related,” described in message center notification MC649940 (Microsoft 365 roadmap item 141712). The notification was last updated on 28 July, but the promised update is now available for Outlook desktop classic (I used version 2309, build 16827.20056, but don’t know the exact build when Find Related first appeared) and Outlook for Mac. The feature will come to OWA and Monarch at some point in the future.

Find Related for Conversations or Users

Search has had a checkered history in Outlook. It wasn’t very good for years, but has steadily improved recently. Find related is a quick way to search a mailbox for related emails directly from an item in the message list. To use Find related, select an item in the list and use the right-click button to reveal the actions menu (Figure 1).

The options are to find:

• Messages in this conversation: Find items in the same thread as the selected item (Figure 1). The search used is the same as if the user types ‘[Conversation]:=”Title of message“’ into the search box. For example: [Conversation]:=”TEC PowerPoint Slides are due!”  The search looks for an exact match against message subjects, so “TEC PowerPoint” won’t work. However, casing doesn’t matter and the search finds messages with subjects like “RE: TEC PowerPoint Slides are due!”
• Messages from sender: Find all items from the sender of the selected message. Outlook looks for messages based on the display name of the message sender. It’s like typing from:”user display name” in the search box. For example, from:”Kim Akers.”

Monarch’s Reminders Window

There’s not much more to say about Find Related, so let’s move to message center notification MC638133 (last updated 12 August 2023, Microsoft 365 roadmap item 144731), which describes a new reminders window implemented in the current build of the Monarch (preview) client.

Microsoft says that the reminders window is a “new notification style.” It’s a pop-out window, which isn’t very new at all, except when used to communicate meeting, event, and task reminders. The window lists reminders for upcoming events with the option to snooze reminders, dismiss reminders, or join Teams meetings (Figure 3).

I hate to say this, but the new notification style trumpeted by Microsoft seems no more than a web implementation of the Outlook classic reminders window. It’s certainly useful to have reminders listed in a separate window, but it’s not like this is breakthrough thinking that sets a new frontier for information technology. Maybe it’s just functionality introduced in Monarch to match what’s in the Outlook classic client in preparation for an eventual switchover. That won’t be possible until feature parity is achieved. Monarch is still a tad away from that as current builds lack support for important features like offline access and PSTs.

MC638133 says that the default value for setting to control the reminders window is Off unless their settings from a “previous Outlook client that they toggled in from” is set otherwise. I assume that this is the Outlook desktop “Show Reminders” setting. In any case, you can check the notifications section of Monarch settings to see if the reminder popup is selected (Figure 4).

Feature Rich Outlook

In one respect, the problem with Outlook is that it is too feature rich. Even after using the client since Outlook 97, I continually find (or rediscover) functionality. Maybe that’s just my failing memory. But I like the Find Related search and will probably remember it. At least, I think I will.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Stop People Using Graphic Reactions to Email

Preannounced in message center notification MC670444 (updated 6 September 2023, Microsoft 365 roadmap 117433), with further details provided in a post in the Microsoft Technical community on September 15, Microsoft is giving organizations a way to disable Outlook reactions. The server-side block is rolling out now and should be complete worldwide by the end of September.

Outlook reactions allow users to respond to messages with a graphic reaction using Outlook classic, the Monarch client, OWA (Figure 1), or Outlook mobile. The idea is that recipients can respond to message by selecting a reaction rather than typing out a reply. The mechanism is common in messaging systems like WhatsApp, Facebook, and Teams. Some people love using reactions, others think it’s an abomination on the face of email.

The Wish to Disable Reactions

Soon after Microsoft enabled Outlook reactions, tenant administrators looked for a way to disable the feature with appeals like this post in the Microsoft Technical community. Microsoft’s blog post says that soon Outlook users will be able to choose to “Disallow reactions” for new email. This option must be chosen when composing an email. Once the message is sent, its properties cannot be updated to disallow reactions. Microsoft says that OWA will get the ability to disallow reactions (Monarch should get the feature at the same time) followed by Outlook classic and the other Outlook clients.

The ability to disable reactions depends on being able to add and recognize the SMTP x-ms-reactions: disallow message header for an email. When the Exchange transport service sees this header on a message, it knows that it should block reactions. Likewise, when an Outlook client sees the header, it knows that it should disable the ability of the recipient to respond with a reaction. Of course, it will take time for all Outlook clients to block the ability of a user to react to a message. However, if a block exists and an older client allows someone to respond with a reaction, Exchange Online will suppress the reaction and won’t allow the sender to see the response.

Because an SMTP message header controls the ability of clients to respond with reactions, it’s possible to  construct mail flow rules to block reactions completely for outbound messages to external organizations or to selected domains. Figure 2 shows a mail flow rule to disable Outlook reactions for email delivered to external recipients.

eDiscovery and Outlook Reactions

Whether or not someone responds to a message with a reaction is an interesting clue for eDiscovery investigators. For instance, if you send me a message saying “Let’s commit fraud” and I respond with a thumbs-up reaction, it could be construed that I agree with the proposal to commit fraud.

Unfortunately, you can’t run an eDiscovery search for reactions. Instead, investigators must check the properties of message found by searches to verify the presence of any reactions. Examining message properties with the MFCMAPI program, an investigator can see if any reactions exist for a message. Figure 3 shows the reaction data in the MAPIReactionsBlob property.

Microsoft notes that the way the MAPIReactionsBlob property stores reaction information is “not memory efficient” and that the same data is available in the ReactionsSummary property. I’m sure that they’re right, but the data in the ReactionsSummary property is encoded and less accessible than the information in MAPIReactionsBlob. This situation might change as Microsoft renames the ReactionsSummary property to OwnerReactionHistory.

Disabling is a Tenant Choice

Microsoft often comes up with ideas to enhance Outlook and other clients that work well for some tenants and not for others. With around 400 million paid seats, Office 365 is a broad church, which means that new features that change client UIs are best when they come with the ability to disable the feature. It’s taken a while to disable Outlook reactions, but at least it’s now possible.

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.

Really Just Sending SharePoint News in an Email

Whover wrote MC671563 (29 Aug 2023) titled “SharePoint News in Outlook” needs some help composing headlines. Microsoft 365 roadmap item 124803 has nothing whatsoever to do with Outlook. Reading the headline, I anticipated something like a new OWA control (available also in the Monarch client, and for Outlook desktop via OPX) that allowed users to browse news items posted to their favorite SharePoint Online sites.

Instead, it’s simply a way to send news items from SharePoint Online via email to allow recipients to read the news using whatever email client they like. Although sending news via email is functional, it’s a bit of a damp squib when you consider that people have exchanged news via email since the dawn of messaging. Something more adventurous would have been nice.

Rollout to targeted release tenants has already happened. Standard release tenants will start to see the new feature in mid-September with full deployment due by late September 2023.

New Emailable News Templates

Essentially what’s happened is that SharePoint Online has six new templates to compose news items that are both posted to their host SharePoint site and emailed (Figure 1).

The templates intended for both posting and email support a limited set of web parts. With that exception, creating a new item is as before (Figure 2).

SharePoint News in Outlook Messages

After the content is ready, click Post and send. SharePoint posts the item to the site and displays a screen to allow the user to add the email addresses to receive the post (Figure 3).

The message that arrives in a user inbox gives the recipient the option to read the information in their favorite email client or in SharePoint (Figure 4). The link to SharePoint Online only works if the recipient can access the host site.

The mechanism used by SharePoint Online is rather like the Teams Share to Outlook feature and shouldn’t cause anyone to kill too many brain cells to master the feature. Some points worth noting are:

• To make sure that the information stays within the tenant, SharePoint Online doesn’t allow external addresses to receive the post. All addresses added to the message must belong to the tenant. The set of valid addresses includes user accounts, Microsoft 365 groups, and distribution lists.
• The feature connects to the mailbox of the author of the news item and creates and sends the message from there (you can do the same thing using Graph APIs or the Graph SDK). A copy of the outbound message is in the Sent Items folder. Using this mechanism ensures that the message travels through the Exchange Online transport pipeline. Exchange Online can then apply any transport rules or DLP policies that match the message. The full path of the message is available through message trace, including any transport events that happen such as the application of transport rules.

One exception exists to the rule that limits transmission to internal recipients. If you operate in a Microsoft 365 multi-tenant organization (MTO), user accounts from other tenants in the MTO synchronize to your tenant as member accounts. SharePoint Online allows news items to be emailed to MTO synchronized accounts from other tenants. It might be that the SharePoint developers decided to support MTO accounts because they are deemed trustworthy because they come from a tenant that has a cross-tenant synchronization arrangement with your tenant. Or they simply didn’t realize that MTO accounts exist. I fear that the latter is the true reason.

Analytics for SharePoint News in Outlook

Page analytics are available for each news item. Microsoft says that the analytics reflect total page reads sourced from SharePoint Online and Outlook (email). News sent by email can be reported in terms of page views but SharePoint can’t capture how long people spend reading news items received by email.

A Feature Seeking a Problem

As I played with sending SharePoint news items via email, the question crossed my mind about what demand exists for such functionality. It’s easy to copy and paste interesting news snippets into regular email if you want to. No analytics are available, but again you wonder if this is important. Perhaps organizations exist that place great importance on SharePoint news items and insist on the ability to email the latest information. If so, I haven’t met them.

Microsoft’s blog on the topic isn’t particularly illuminating until you read the comments from real people who know more about SharePoint news than I do. Those comments are worth reviewing before you decide to dedicate any effort to deploying this feature.

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

Outlook Monarch Controls for the New Outlook for Windows

Updated 8 November 2023

With the disclosure that Microsoft 365 Copilot will only work with the Outlook Monarch client, organizations interested in Copilot deployments might need to reassess their plans for the “new Outlook for Windows,” currently available in preview.

Because Monarch is under active development, the set of features that it supports changes all the time. An assessment of the client software available last September isn’t a good basis for deciding how ready Monarch is today (this support page includes a non-exhaustive list of key Outlook features). Apart from adding features for Microsoft 365 users, work is also ongoing to make sure that Monarch can support email accounts for other mail servers.

In a related development, Message center notification MC590123 (updated 20 June) and a support article laid out Microsoft’s plan to use Monarch as the default email and calendar client for Windows 11. The kicker here is the statement that “After this change is implemented at the end of 2024, Users with a Microsoft 365 or Office 365 subscription with access to the Microsoft 365 desktop apps can use the new Outlook for Windows.” With their normal enthusiasm for new software, Microsoft will take every opportunity to make Monarch available to end users. Some would say that they will stuff Monarch down peoples’ throats, but that’s going a tad far for me.

Controls to Block or Allow Access to Outlook Monarch

With Microsoft accelerating its plans for Monarch, administrator thoughts invariably turn to the set of controls available to enable or disable the new client. Microsoft documentation covers this topic (and there’s some interesting information in the FAQ), but here are the essentials together with some PowerShell that you might find useful.

Monarch is based on OWA, so it should come as no surprise that it functions like OWA. For example, a setting is available to disable the client at the access level (what used to be the Client Access Server in on-premises servers). This command blocks access to Monarch for the Terry Hegarty mailbox (account):

Set-CASMailbox -Identity Terry.Hegarty -OneWinNativeOutlookEnabled $False

Note: Outlook checks the value of both the OWAEnabled and OneWinNativeOutlookEnabled settings for the mailbox to decide if the new Outlook can be used (both must be true). In a change announced in MC922623 (31 October 2024), Microsoft removed the check for OWAEnabled and will only check OneWinNativeOutlookEnabled after the update rolls out in January 2025.

To disable or enable a set of mailboxes, use either the Get-ExoMailbox (to search against mailbox attributes) or Get-User (to search against Azure AD account attributes) cmdlets and pipe the results to Set-CASMailbox:

Get-User -Filter {Department -eq "IT"} -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-CasMailbox -OneWinNativeOutlookEnabled $False

To report the set of mailboxes enabled for Monarch, we can do something like this (unfortunately, Get-CASMailbox doesn’t support server-side filtering against OneWinNativeOutlookEnabled):

Get-CasMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Where-Object {$_.OneWinNativeOutlookEnabled -eq $True} | Format-Table DisplayName, OneWinNativeOutlookEnabled

An OWA mailbox policy setting is available to block users from adding third-party email accounts (like Gmail) to Monarch. This command updates an OWA mailbox policy to disable personal accounts. The policy is effective with Monarch builds post 30 June. To block personal accounts, the Outlook profile must be first configured with an enterprise account with an Exchange Online mailbox. If not, blocks placed by Exchange Online OWA policies are ineffective.

Set-OwaMailboxPolicy -Identity OWAMailboxPolicy-Default -PersonalAccountsEnabled $False 

And to report the set of mailboxes to which the OWA mailbox policy applies, run:

Get-CASMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Where-Object {$_.OWAMailboxPolicy -eq "OwaMailboxPolicy-Default"}

Turning Off the “Try the New Outlook” Toggle

Recent Outlook for Windows builds include a toggle to allow users to switch to Monarch (Figure 1). If you’re not going to allow people use Monarch, it’s a good idea to remove the tempting toggle.

To hide the toggle, add a new DWORD value in the system registry called HideNewOutlookToggle at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General and set it to 1 (Figure 2). The next time Outlook restarts, the toggle is gone.

The change can also be made in a GPO using ADMX build 16.0.5401.1000 or later. The setting is “Hide the “Try the new Outlook” toggle in Outlook,” which sets HideNewOutlookToggle at HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\General to either 0 or 1, depending on if the toggle is on or off. Publishing the change via a GPO might take a little time before the client responds and disables the toggle.

Removing Monarch

Because the Monarch client is fully supported for personal accounts, users might receive it as a preinstalled app on a new device or they might download the client from the Windows Store. To remove the app from a Windows image so that Windows does not install the app for new user accounts, you can remove the Outlook Monarch app package by running the Remove-AppxProvisionedPackage cmdlet. According to instructions given in MC676298 (22 September 2023), the command to remove the Monarch package is:

Remove-AppxProvisionedPackage -Path c:\offline -PackageName OutlookforWindows

To remove a previously-installed app, run the Remove-AppxPackage cmdlet.

Reporting Outlook Client Usage

Currently the Email Apps report in the usage reports section of the Microsoft 365 admin center doesn’t separate Monarch out from OWA when it identifies the different Microsoft clients that connect to Exchange Online (Figure 3). Hopefully, Microsoft can update the report to highlight people who use Monarch.

Monarch’s Coming. Are You Ready?

It seems like Microsoft has been on the journey to deliver the new Outlook for Windows forever. But let’s face it, replacing a client that’s been in use since 1997 is difficult to say the least. Code developed over decades can’t be replaced without huge engineering effort, especially when the desired outcome is a common Outlook code base that will work on multiple platforms and support faster innovation.

OWA introduces new functionality much faster than the legacy Outlook for Windows does. That’s not the fault of the older Outlook client. It is handicapped by decades of building features one step at a time. The new Outlook for Windows will eventually be a good replacement. The question is just when that time will be. In the meantime, some Outlook Monarch controls are a good thing to have.

Monarch’s Path to Replace Outlook for Windows is Rocky at Times

On June 20, 2023, Microsoft updated message center notification MC590123 covering the “Future of the Mail and Calendar apps in Windows with Outlook.” This note caused a lot of fuss and bother, but essentially it all boils down to one thing. At the end of 2024, Microsoft will discard the old Mail and Calendar apps in Windows 11 and replace them with the Outlook Monarch (“One Outlook”) client. This makes perfect sense because it replaces two so-so marginal apps with a core app that Microsoft is pouring development resources into with the intention of replacing the current Outlook for Windows app.

The idea behind Monarch is that Microsoft will have a single Outlook app that can run on multiple platforms. By design, Monarch should be able to connect to any email server, including Exchange Online and Exchange Server, Outlook.com, Gmail, and IMAP4/POP3 servers. At this point in its development, Monarch still some way from that point. The support article summarizes the situation as:

“New Outlook for Windows supports Exchange-backed Microsoft 365 work or school accounts, Outlook.com accounts, and Gmail. Currently, the new Outlook for Windows does not support other account types like Yahoo!, iCloud, or other account types connecting through POP/IMAP protocols. New Outlook for Windows also does not currently support On-Premises, Hybrid, or Sovereign Exchange deployments.”

Some might be surprised at the last sentence where Microsoft reports that Monarch can’t currently connect to Exchange Server on-premises or hybrid or sovereign Exchange deployments. The last term means, I think, that Monarch doesn’t currently support the non-commercial Office 365 clouds like Office 365 China or GCC. This is probably because of the additional code and testing required to sign off deployment of software in these environments.

Bringing Monarch to Exchange On-Premises

As to Exchange Server, some recent changes in modern authentication for Exchange Server based on AD FS probably mean that some extra work is needed before Monarch can connect to Exchange 2019. Monarch is based on OWA, but not the version of OWA that runs on Exchange 2019, which is the only version supporting modern authentication. As to hybrid environments, Monarch needs to cope with hybrid modern authentication.

I guess Microsoft views the need to support all the variations at play with Exchange Server to be of lesser importance than achieving other goals, like giving Monarch the ability to work offline. Anyway, it’s not like there’s a flood of user requests coming from the on-premises world tpo replace the current Outlook for Windows.

Connecting Monarch to Gmail

Coming back to the point in hand, I’ve been using Monarch ever since it first became available. This week I decided to connect it to my Gmail account and was surprised at how easy the process was. Start off by going to Outlook Options and choose Accounts. You can then add a new account to the set by typing in the email address (Figure 1).

Next, Monarch informs you that you need to sign into Gmail. This step is necessary to validate that you own the Gmail account and can authorize Monarch to connect to the account. Monarch invokes a new browser tab and announces that you must go there to complete the OAuth 2.0 sign in to the Google account.

After successfully signing in, Monarch (or rather, Microsoft apps & services) requests consent for it to have the permissions needed to access email in your Gmail account (Figure 2). Quite why Monarch needs to know my exact date of birth is a mystery, but it’s one of the request permissions.

After receiving authorization, Monarch accesses the Gmail account using the Gmail API to display messages in its UI. Interaction with Gmail is like accessing messages in Exchange Online. The obvious difference is the reduced set of options that Monarch supports for Gmail compared to Exchange Online, probably due to API limitations. However, I was happy to discover that I could search and find some old Gmail messages, such as those relating to an Exchange 2010 Maestro training seminar that Paul Robichaux, Brian Desmond, and I delivered in 2011 (Figure 3).

The days of two-day in-person intense hands-on training are probably gone, but I enjoyed the Exchange 2010 Maestro events very much indeed.

Slow and Steady Progress

Microsoft is making steady progress with the Monarch client. Development is probably too slow for some, but the fact is that the current Outlook for Windows client supports so much functionality that replacing it was always going to be a massive task. Replacing the Mail and Calendar apps in Windows 11 is just a sideshow, albeit one that will deliver much better functionality for some long-maligned clients.

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.

Oversharing Popups  for Outlook Help Users Avoid DLP Problems

Originally due for deployment in March 2023, Microsoft is rolling out the ability for Outlook clients to detect and highlight messages using “oversharing popups” if the messages have specific sensitivity labels. The change is covered by message center MC523046 (last updated 9 June 2023) and Microsoft 365 roadmap item 100157. It’s also associated with Microsoft 365 roadmap item 100255, which covers the general effort to provide customers with replacement technology for the features available in the Azure Information Protection unified labeling client (due to retire in April 2024).

Azure Information Protection (AIP) labels were the predecessor of Microsoft 365 sensitivity labels. Users had to install a separate add-in to use labels (now the unified labeling client). As part of the process to retire the unified labeling client, Microsoft has incorporated information protection technology in the Microsoft 365 apps. The UI exposed by the AIP is gradually being replaced in native Microsoft 365 features. The arrival of the sensitivity bar in Microsoft 365 apps is an example of the process in action.

Implementing Oversharing Popups in Microsoft 365 DLP Policies

In this case, instead of relying on the unified labeling client to detect potential “oversharing” problems when users compose email, it’s now possible to include checks in Data Loss Prevention (DLP) policies. The effect is to cause Outlook to use a policy tip to highlight that a message contains sensitive content that shouldn’t be shared outside the organization as users work with message content. DLP detects the oversharing condition in either the message or an attachment and the user is forced to take action before they can send the message.

DLP policies have always been able to detect and block oversharing of email. What’s different here is that DLP checks happen during message composition instead of the user sending the message and receiving a non-delivery notification because a DLP policy detects a violation and blocks the message. Of course, oversharing of email protected by a sensitivity label might not matter all that much if the rights granted in the sensitivity label don’t allow the external recipient to read the content. The value of the policy tip is that by proactively highlighting the issue, the user can take action to avoid problems detected by DLP. For instance, they could choose a different label for the message (and justify the downgrade).

Microsoft documents an example DLP policy to explain how the oversharing policy tip work. They document the steps for creating a policy with both the Microsoft Purview compliance portal and PowerShell. Despite my affiliation for PowerShell, I wouldn’t do anything with DLP rules through PowerShell because of the relative complexity of rule construction.

Testing DLP Oversharing Popups

After creating a DLP policy with a rule to check for the presence of sensitivity labels on email addressed to non-internal domains (Figure 1), wait about an hour to allow the policy information to replicate.

You’ll know that the rule works if you see a policy tip when composing a message to an external recipient and the message or any attachment has one of the sensitivity labels specified in the rule. Figure 2 shows a message assigned the Public sensitivity label, which isn’t covered by the rule. However, the attachment has the Confidential sensitivity label (you can’t see this, so you’ll have to trust me), so DLP detects a violation and displays the policy tip to say that the recipient isn’t authorized to receive this information.

Attempts to send the message fail and Outlook displays a pop-up to tell the user why (Figure 3). OWA displays a similar prompt. In both cases, the user must take action before they can send the message.

It’s possible that a user will send a message with one of the sensitivity labels defined in the policy from Outlook mobile. It’s also possible that a user will send a message before the DLP code in Outlook or OWA detects a problem. In these instances, the Exchange transport service imposes the general block on sharing messages with the specified sensitivity labels and rejects the message.

The Power of Policy Tips

Allowing users to correct potential errors when they compose email is a good idea. Apart from anything else, it helps reinforce the idea that email can contain confidential and sensitive information that shouldn’t go outside the organization. I’s much more powerful when users see policy tips that help amend behavior than simply having their email rejected for some inexplainable (to them) reason.

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.

Making Plans to Introduce Sensitivity Labels for Meetings

I previously wrote about how sensitivity labels protect meetings created in Outlook and OWA and the way that labels can apply settings to Teams meetings, if meeting organizers have Teams Premium licenses. In that article, I said that introducing sensitivity labels for meetings requires up-front planning. This article discusses some of the topics that such a planning exercise might cover.

Label Scoping

Scoping defines to what objects applications can apply labels. In the past, the split was simple: information protection (encryption) for files and emails or container management for groups, sites, and teams. The introduction of meetings and a recent update to introduce separate scopes for emails and files (MC514980, updated 3 Mar 2023, Microsoft 365 roadmap item 99939) means that things are a tad more complex now (Figure 1).

Looking at the options to define the scope for a sensitivity label, you can select the following for items:

• Emails: Labels are only available to Outlook clients.
• Files: Labels are available in Word, PowerPoint, and Excel (Online, subscription, and mobile). These labels are also assignable to PDFs by the Adobe Acrobat paid-for products (or by export from Office) and to files stored outside Office 365 by the AIP extension for Windows Explorer.
• Meetings: Labels are available for meetings created in Outlook and OWA and the Teams desktop and browser clients. Because meetings include elements of email (meeting notifications and responses) and files (attachments), if you select this option, you must also enable the label for Emails and Files.

In the past, I have recommended having separate sets of sensitivity labels for information protection and container management. I think this approach leads to easier management because labels serve one purpose. The question now is should we have separate labels for meetings?

It’s a harder question to answer because meetings require files and emails. If Microsoft had created a scope for meetings that implicitly includes files and emails but didn’t display these labels for users to apply to email and documents, then I’d say yes. Because they didn’t, any label created for meetings is also available for email and documents, so we need a different approach to guide users.

Label Naming

The obvious answer is the display name assigned to sensitivity labels for meetings. By including “Meeting” in some form in the display name of labels created to protect meetings, hopefully people will use the labels for their intended purpose and not to label documents and emails.

To start, we might create a limited set of sensitivity labels for meetings:

• Public (no protection – label is for visual marking only).
• Internal meeting (protection limits editor access to tenant members).
• External meeting (protection limits access to anyone who can authenticate against Azure AD).

As time goes by and experience develops, the need might emerge for other labels. For example, if the finance and legal departments work with external advisors, the organization might decide to create sensitivity labels for their meetings with a label policy to publish the labels to users in those departments. The protection in these labels could assign co-editor permission to people in the domains owned by the external advisors to allow them to edit documents shared in meetings.

You can create display names for sensitivity labels with a maximum of 64 characters (excluding % \ & < > | ? : and ;), so plenty of room exists for innovative naming schemes. Just remember some basic facts about labeling:

• Applications have limited space to display label names (especially mobile apps).
• If you create a wide range of sensitivity labels for different scopes, users might have difficulty deciding upon the most appropriate label to apply to items.

Figure 2 shows the effect of scoping and naming, Only four sensitivity labels in the tenant are scoped for meetings. Each has a name that is clear in its purpose (the Very Secret label is a little tongue in cheek; Confidential would be a better name). A checkmark appears beside the Internal meeting label, meaning that it is the selected label. When a label is automatically selected for new meetings, it’s because it is the default label for meetings selected in the sensitivity label policy published to this account.

Keep It Simple

Keeping it simple is key. Use scoping to make sure that applications make appropriate sensitivity labels to users. Give the labels clear and understandable names. If necessary, translate the display names of labels for use in multinational organizations. Follow those two simple rules with the sensitivity labels used for meetings and users should be happy.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Project Moca to Outlook Board to Fast Deprecation

MC554157 (May 12) announces the retirement of the board view in the Outlook calendar. Well, the OWA calendar because the board view never existed in the Outlook desktop calendar, unless you count the Monarch client as an Outlook desktop client.

The origins of the board view come from Project Moca. In 2020, Moca seemed like a nice way for people to organize different pieces of information drawn from different sources on a board, kind of like pinning bits of paper to a pinboard. After going through a preview phase while Microsoft figured out where Moca might fit inside Microsoft 365, eventually Moca turned up as a new board view for the OWA calendar in mid-2021.

Low Usage for Boards

Getting on for two years later, Microsoft’s famous telemetry must show that the usage of boards remains staggeringly low. At least, that’s what I anticipate the data indicates because I have never been asked a single question about this aspect of OWA, and that’s despite writing several articles on the topic. I have several boards (Figure 1), but I haven’t used them in months. The fact is that the board view seems to have been in a sad state of disrepair for quite a while. No new features appeared and no-one in Microsoft seemed interested in curing the obvious quirks that sometimes emerged when moving items around a board. Software that stays static is always in trouble unless it’s a COBOL program running tax software from the 1970s.

Many Ways to Take Notes

Another truth is that there are just too many ways to take notes available in Microsoft 365. Some like the simplicity and mobile access of To Do; others like OneNote. And now Microsoft is preaching the wonders of the Loop app. Over the long term, I could see a consolidation in the OneNote/Loop space with the newer application winning because of its better synchronization capabilities and its roots in SharePoint Online. But we shall see.

The End of Boards

In any case, the guillotine descends on boards on June 26, 2023, or roughly six weeks from the announcement and just before the end of Microsoft’s FY23 fiscal year. By Microsoft standards, retiring an Outlook feature in six weeks is very fast and is further testimony to its low usage. Boards are no public folders, something that Microsoft has been trying to dump since 1987 or thereabouts.

Microsoft’s advice to users is confusing. On the one hand, they say that there’s nothing that users need to do. Boards will simply disappear on the designated date. The items linked to boards remain in place and can be accessed from their original location. For instance, when you create a note on a board, Outlook stores the underlying item in the Notes folder of your mailbox. Outlook Notes is another application that hasn’t received much tender loving care from Microsoft in the recent past, but at least the data is there and can be copied and pasted into a more up-to-date and functional digital notebook.

On the other, Microsoft recommends going to the Privacy and Data section of Outlook (OWA) options to export board data (Figure 3). I shouldn’t bother. In a decision surely taken by a developer without supervision, OWA outputs the board information in JSON format to a file called boards.json. I wonder what target the developer had in mind when they contemplated how to export the board data?

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Outlook and Teams Meetings Both Benefit from Added Protection

Published in message center update MC513052 (last updated 27 April 2023, Microsoft 365 roadmap item 98924) and finally rolling out over May, Outlook (Mac, Windows, and OWA) can assign sensitivity labels for meetings. That is, if you have Office 365 E5 licenses.

Last October, I speculated that Microsoft’s claim of protection and recaps for Outlook and Teams meetings would be deliver very different functionality. Now we see that protecting meetings is a multi-part story composed of:

• Defining and publishing sensitivity labels configured with the meeting protection setting.
• Defining and publishing sensitivity labels configured with Teams online meeting settings. Meeting organizers require Teams Premium licenses to use sensitivity labels with Teams online meeting settings.
• Defining and publishing Teams meeting templates describing different forms of meetings (internal, external, highly secure) to help users choose the right configuration for their meetings. Microsoft describes a concept of three tiers of protection for Teams meetings.

This article covers the basics of creating and using sensitivity labels with Outlook meetings.

Using Outlook to Assign Sensitivity Labels for Meetings

Sensitivity labels have always been able to protect “normal” email, including attachments. Meeting requests and responses are a different form of emails because they include metadata about a meeting (date and time, location, and attendees) that a recipient can use to create an event in their calendar. Given that people often include a great deal of confidential information in meeting requests, I don’t know why Microsoft did not extend protection to calendar messages until now.

When you apply a sensitivity label with encryption to a meeting, the body (text containing details of the event) and any attachments inherit the rights management protection defined in the label. Other information like the meeting title and participant list is not encrypted. This is like normal messages where encryption protects only the content and attachments of messages.

Figure 1 shows how to assign a sensitivity label to a meeting with OWA. Only the set of sensitivity labels configured to protect meetings appear in the drop-down list for users to select from. You can configure a default sensitivity label to apply to all meetings through the sensitivity label policy that publishes labels to users.

A protected meeting operates like any other protected email. Outlook wraps the contents of the message and its attachments in a protected rpmsg message. If the receiving client is “enlightened” (it knows how to process protected messages), it can decrypt the message and display it inline. If not, the user receives a link to access the content through the Office 365 Message Encryption (OME) portal. Note that clients can only open protected messages if the recipient has the right to view the content. The rights are set in sensitivity label properties and will stop people who don’t have the right to view content opening the messages. For instance, the “Internal meeting” label might restrict access to users within the tenant. If someone outside the tenant is a meeting participant, they cannot open the message.

Points to Ponder

While working with protected meetings, I noticed a couple of points worth highlighting:

• You can insert a Loop component in a meeting request created in OWA. Recipients can edit the content of the Loop component even if the sensitivity label blocks edit access. This is because Loop doesn’t support sensitivity labels yet. Current builds of Outlook desktop (subscription) doesn’t support adding Loop components to meeting requests.
• If you assign a restrictive sensitivity label to a meeting, you might stop meeting participants being able to edit attachments. This might be what you want to do, but it’s a change in behavior that users need to understand.
• Sensitivity labels determine rights based on email addresses. If someone forwards a protected meeting invitation to someone else, they might not be able to access the content if the rights specified in the label doesn’t have an entry that matches their email address (or domain). One advantage gained is that if people forward meeting invitations without permission outside the organization, the external recipients won’t have access to the meeting content.

Sensitivity Labels for Meetings in Outlook Mobile

Outlook Mobile can open protected messages (decryption occurs on the server) and can process inbound events to include them in the calendar. However, the meeting body is not decrypted (Figure 2), which means that the user knows they have a meeting to attend but can’t see the text explaining what the meeting is about unless they open the meeting with Outlook desktop or OWA. However, the deeplink for the Teams meeting remains usable because it is not encrypted.

In addition, Outlook mobile cannot send protected meetings because the client doesn’t include the encryption technology needed to apply protection.

Don’t Rush to Deploy Sensitivity Labels for Meetings

Introducing protected meetings isn’t something to do on a whim. Like any information protection project, some consideration is needed, especially if sensitivity labels are already deployed. That topic deserves a separate article, which I’ll get to in due course.

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.

Outlook Sensitivity Labels Processed in Different Ways

An observant reader noticed that Outlook clients encrypt messages using sensitivity labels in different ways. If you look at Figure 1, you see three messages sent to the same person using Outlook Mobile, OWA (or Monarch), and Outlook for Windows. The Ultra Confidential sensitivity label protects all messages with encryption, but only the copy sent from Outlook for Windows is protected in the sender’s mailbox. The other copies sent from Outlook Mobile and OWA are protected when they arrive in the recipient mailbox.

The obvious question is why this situation happens. Shouldn’t all Outlook clients produce the same result? Alas, this is not the case. As explained in Microsoft documentation, “When a sensitivity label is configured with encryption, the encryption process depends on the client platform.” In effect, Outlook desktop is the only client that contains the code necessary to encrypt an outbound message.

Other Outlook clients rely on passing messages through the Exchange Online transport service. The transport service has super-user capabilities and can apply the necessary protection. When transport detects that a message has a sensitivity label with encryption that isn’t yet protected, it does the necessary work to protect the message by placing the message and its attachments in a rpmsg “wrapper” before sending the message on to the next hop in its journey.

Client Processing for Protected Messages

The rpmsg wrapper is how Outlook sensitivity labels impose rights management for protected messages. The receiving client must unpack the message from the wrapper and respect the rights assigned to the recipient by the publishing license that’s included in the wrapper. The receiving client sends the publishing license to the information protection service to obtain a use license that allows the client to open the message.

Clients perform the processing to allow users to read protected messages without being prompted for credentials. If the client can’t obtain a use license, it displays information from the rpmsg to direct the user to the Office 365 Message Encryption (OME) Portal. If the user can prove their rights to open the message by signing into the OME portal with an account included in the recipient list, they can view the message contents online.

The reason why two out of the three messages are unencrypted in the Sent Items folder is that these are the messages that clients didn’t protect. Outlook desktop protected the other message before it submitted the item to transport. In

all cases, the sender can be confident that the message was fully protected when it left the transport service for onward routing.

Clients and the MIP SDK

Microsoft could incorporate the code (using the Microsoft Information Protection SDK) to protect messages in OWA and Outlook mobile. However, this approach doesn’t seem to make sense. Apart from the extra complexity introduced into the client code base, OWA can only be used online. Outlook mobile clients could protect files, but they usually work in a connected mode (either Wi-Fi or a cellular network). Outlook desktop has always been able to work offline, so its developers incorporated the code to process protected inbound and outbound messages when working offline.

Growing Use of Outlook Sensitivity Labels

The number of messages protected by Outlook sensitivity labels is steadily increasing. I do not have firm data to back this assertion, just anecdotal evidence from customer interactions. Microsoft continues to pour engineering effort into making sensitivity labels more accessible and useful, so I expect the trend to continue. And when your tenant starts to use sensitivity labels to protect email, you’ll know why some Outlook clients protect messages in a different manner to others.

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

Introducing Authenticator Lite

Without too much fuss, Microsoft introduced the preview of a new “surface” (way) for users to complete multi-factor authentication (MFA) challenges. The new method is a companion app for the Microsoft Authenticator app and is covered by Microsoft 365 roadmap item 122289 and is slated for roll-out in May 2023.

Azure AD already covers a variety of methods to satisfy MFA challenges. The methods are categorized from weak to strong in terms of their ability to resist attacks and conditional access policies can insist that a connection uses a certain strength of MFA response before it is accepted. “Authenticator lite” is rated as strong as the Authenticator app because it’s basically code taken from Authenticator and built into other Microsoft apps. In addition, Authenticator lite only supports push notifications with number matching and one-time codes, which are less likely to provoke MFA fatigue than the traditional “click here to approve” response.

Outlook Mobile Leads the Way

Outlook mobile (iOS 4.2309.0, Android 4.2308.0, or higher versions) is the first Microsoft 365 app to pick up the Authenticator Lite code. Some might ask why Microsoft choose Outlook as the test case. I think it’s because Outlook is likely the most heavily used mobile client. The last time Microsoft gave a number for Outlook mobile (April 2019), they reported that Outlook for iOS and Android had more than 100 million users. At that time, Office 365 reached 180 million monthly active users. Now Office 365 is up around 400 million monthly active users. Assuming Outlook mobile has kept pace, it has around 220 million monthly active users.

Building MFA responses into the most popular mobile client is a great way of making MFA easier for organizations to deploy. Microsoft wants customers to deploy MFA. They also want customers to use strong MFA responses and move away from methods like SMS text-based responses. The recent introduction of the Azure AD system-preferred authentication policy to force Azure AD to select the strongest available authentication method for a user when it issues a challenge is a pointer to the future. Who needs to resort to an SMS response when you can respond to a number challenge within Outlook? It makes absolute sense.

Update the Azure AD Authentication Methods Policy

If you’re interested in trying Authenticator Lite with Outlook mobile, the steps to make everything happen are covered in a Microsoft article. In summary:

First, use a Graph API PATCH request to update the Azure AD Authentication Methods Policy to update the companionAppAllowedState setting from disabled (the default) to enabled. The easiest way to do this is with the Graph Explorer (make sure to sign in with an administrator account because you’ll need to consent to the Policy.ReadWrite.AuthenticationMethod permission to update the policy. The relevant lines for the policy in my tenant look like those shown in Figure 1. The state is enabled and the policy is targeted at a group of users with an identifier of “all_users.” This is a special identifier that instructs Azure AD to apply the policy setting to all tenant users. If you want to limit the policy to a specific set of users, create a security group with those users as members and update the authentication methods policy with the group identifier.

The updated policy might take a little time to become effective and people can respond to MFA challenges from Outlook. Only accounts enabled to use the Authenticator app (with the mode set to Push or Any) to respond to MFA challenges can use Authenticator Lite within Outlook, and responses are limited to number matching or one-time codes. It’s important to realize that if the Microsoft Authenticator app is present on a device, Outlook won’t attempt to use Authenticator Lite and instead refers all authentication challenges to the full Authenticator app.

It’s also important to realize that the code incorporated into Outlook supports fewer options than the full Authenticator app. For instance, it doesn’t support Self-Service Password Reset (SSPR). The Authenticator app is a more appropriate option for users who need functionality like handling MFA responses for other cloud services like Twitter and GitHub.

MFA Responses for the Masses

I like any action that reduces the friction of MFA deployment and operation for both organizations and users. Authenticator Lite falls into this category. Although I won’t use the new capability because I need the power of the full Authenticator app, I think that Authenticator Lite will meet the needs of most Microsoft 365 users when it comes to responding to MFA challenges.

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.

Intelligent Technology Depends on Machine Learning Access to User Data

Some years ago, I wrote about how Outlook uses machine learning to predict words to insert in messages. This was an early example of machine learning in Outlook. Text prediction is common practice today and we almost expect applications to include machine learning to help us compose notes, documents, and responses. Given the introduction of ChatGPT and Bing’s AI Bot, some worry about the prospect of increasing amounts of machine-generated text and its effect on human creativeness. It’s definitely a story to follow.

Over the last few years, Microsoft has steadily increased the use of “intelligent technology” in Outlook. Currently, the range of features covers features like birthday detection to text predictions to suggested replies, controlled through OWA settings (Figure 1). Regretfully, the Set-MailboxMessageConfiguration cmdlet doesn’t currently support updating these settings for a mailbox.

The combination of Microsoft Research and product engineering groups has driven the introduction of intelligent technology in OWA. For example, Outlook’s suggested replies feature is underpinned by the Azure Machine Learning Service.

Outlook Desktop Lags in Intelligence

Outlook desktop clients receive the intelligent technology features after OWA. This lag has always existed, but at least we can respond to email with an emoji. Oddly, there’s been a few recent reports of Outlook for Windows failing to display the “show text predictions while typing” setting in its options (here’s an example). I don’t see the setting on one PC and do on another, both of which run the same build of Outlook click to run. I even updated the system registry at HKCU\SOFTWARE\Microsoft\Office\16.0\Common\MailSettings to set the InlineTextPrediction DWORD value to 1 to enable text predictions with no effect.

Microsoft Processing of User Data

One thing that people get worried about is the notion that Microsoft “reads” their email to create suggested replies and to build models for text predictions. It’s true that Microsoft processes email to create the suggestions and predictions used by Outlook, but the important thing is that the data used by the learning models constructed to help machine learning understand how individual users work with text remain in user mailboxes. Microsoft doesn’t gather information from the 380-odd million active Office 365 users to improve its detection algorithms. The general foundation for the models come from public data (and I imagine, messages circulating within Microsoft), but the tweaks to make those models personal remain private to the user.

In its user documentation for suggested replies, Microsoft says that “Suggested replies are generated by a computer algorithm and use natural language processing and machine learning technologies to provide response options.” It also says that “Outlook uses a machine learning model to continually improve the accuracy of the suggestions. This model runs on the same servers as your mailbox within your organization. No message content is transmitted or stored outside of your organization.”

These statements don’t mean that the machine learning code runs on 300K Exchange Online mailbox servers. Instead, Microsoft uses a concept called Privacy Preserving Machine Learning (PPML) to transfer data to specialized AI computers in the Microsoft cloud. After processing, Microsoft erases the source information from the AI computers and background agents update mailboxes with user-specific results. It is this information that Outlook consumes locally when dealing with messages.

Email is worldwide, but the structures and syntax used by different languages means that Microsoft’s machine learning processes is limited to certain languages. For instance, at the time of writing, suggested replies are available in only 22 languages.

I’ve heard (but can cite no public evidence) that AI processing occurs on a tenant basis to allow some consolidation of generic results at the tenant level. For instance, if many users in a tenant use “OK” as a standard response, it’s likely that machine learning will consider “OK” as a prime candidate to be a suggested response for everyone in that tenant. The consolidated generic data remains in the tenant.

Viva Insights Processes User Email Too

In addition to the way Microsoft processes user email to understand text patterns, Viva Insights looks through email to detect commitments made by users. Its MyAnalytics predecessor started to scan emails for commitments in 2018. When users open the Viva Insights add-in or use the Viva Insights app in Teams, they see recommendations and insights derived from the contents of the calendar and inbox folders from their mailbox.

Among the information Viva Insights highlights are messages that might contain commitments that the user needs to follow up. Viva Insights displays details of the messages it has found and prompts the users to either note the potential task as complete or add it as a personal To Do task (Figure 2).

Viva Insights also finds messages where the user asks recipients to do something and prompts them to either follow up or mark the task as done.

There’s lots of deep research into finding commitments in email and highlighting those commitments to users. But again, the important thing is that the data used by Viva Insights remains in user mailboxes and is under the control of users.

Worrying About the Data Used by Machine Learning in Outlook

Those with responsibility for compliance and privacy in an organization are usually the people most worried about the processing of user data. With the growth of machine learning and AI-powered “experiences” and the resultant need for access to user data to learn from, this is a good concern to have. In the case of Microsoft 365, many “connected experiences” exist where people consume a cloud service without realizing where data comes from or is consumed.

Personally, I’m not concerned about how machine learning processes my email as the outcome is useful (when it works), but I realize that others have different feelings. It’s a topic for every organization to work through and figure out how happy they are to have Microsoft process their data to create new features.

To finish off, Figure 3 shows how Bing chat answered my question about how Outlook uses machine learning…

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.

Time to Consider How to Handle Outlook Add-Ins for New Clients

A recent Practical365.com article about user submissions of suspicious email caused me to think. Not about the proposal because it’s obvious that allowing people to report suspicious messages that Exchange Online delivers to their inboxes is a good idea.

After all, if someone receives an email that looks like malware, smells like phishing, and has a faint hint of spam, it’s probably not a good thing. And if it gets to a mailbox, it’s a failure of Exchange Online Protection (EOP) or whatever email cleansing service the message passed through en route. Reporting this kind of message to their administrator or Microsoft for further analysis is right and proper. Everyone benefits when Microsoft receives copies of messages that get past the EOP tests.

Customizable Notification Messages

The article explains how Exchange Online now allows organizations to customize the messages displayed when people report bad email. It’s a nice feature that allows organizations to reassure people that something happens when they take the time to report a problem. No one likes their efforts to disappear into a black hole. Figure 1 is an example of a customized message sent to people in my tenant when an administrator reviews a reported message. The format of the message contains corporate branding to reassure the recipient about its source.

The End of COM Add-ins

But the goodness of being able to create customized notification messages for reporting bad email is not what caused me to think. My attention was drawn to the assertion that the Report Message/Report Phishing add-ins will stop working at some point in the future. These add-ins allow users to report messages as junk mail or phishing and have been around for a while. Their long-term replacement is a built-in Report message button that can report messages as either phishing or junk. In other words, a consolidation of add-ins.

At this point, you might wonder why I focus on such an arcane subject. Does it matter if Microsoft decides to replace some Outlook add-ins? Of course, it doesn’t, except when it’s a pointer to a change that might affect customer organizations and ISVs. The older Outlook (for Windows) add-in model is COM-based. Many such examples of these add-ins exist, whether built by ISVs or in-house.

Monarch and OWA Don’t Use COM

But Microsoft is heading to a common Outlook base, aka “One Outlook” or Project Monarch, with the aim of delivering a unified client on as many platforms as possible. The Monarch client is based on OWA and cannot use COM add-ins. Instead, the new Outlook add-in model uses JavaScript or HTML. Monarch is currently in preview with Office Insiders and, like OWA, receives frequent updates. We don’t know when Monarch will transition to become the next version of Outlook for Windows. Given the current state of play, this probably won’t happen in 2023. But it could certainly happen in 2024 or 2025.

This brings me to the point of this note: Microsoft is updating its Outlook add-ins to move away from COM. Is the same happening for the add-ins created by ISVs or in-house development? With its knowledge of where the Outlook puck is going, Microsoft has first-mover advantage here, but the fact that it’s making the change should signal a warning to tenant administrators and architects that it’s time to understand what COM-based add-ins are in use and the plans to evolve them to work with the new Outlook, or even with today’s OWA client.

ISVs know what’s happening and will have plans to evolve their products. I wonder if the same attention is paid for in-house code. Given the longevity of the current Outlook for Windows architecture, it’s possible that some add-ins are in situ that no one wearing an administrator hat knows much about. It would be a shame if an obscure but necessary add-in surfaced to disrupt future deployment plans, so do yourself a favor and check now.

Keep up to date with developments like Project Monarch 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.

Driving Usage for the Bookings with Me App

The January 12 announcement that bookable time is coming to Outlook (OWA) is no more than a Microsoft attempt to drive usage of the Bookings with Me app. There’s nothing wrong with that tactic, even if it might make some people think that the announcement brings news of a brand new feature.

Microsoft also refers to bookable time as “Bookings in Outlook” and asserts that the apps helps to reduce “the back and forth in scheduling while helping you [to] maintain control of your calendar.” Bookable time in Outlook is available to users with the following licenses:

• Office 365: A3, A5, E1, E3, E5, F1, F3 
• Microsoft 365: A3, A5, E1, E3, E5, F1, F3, Business Basic, Business Standard, Business Premium 

The Magic of Controlled Scheduling

This magic happens through uses creating a personal bookings page where they publish slots where they are available to meet people who care to make a booking through the page. The control Microsoft mentions comes about by the user establishing a schedule of available time slots when the user will accept 1:1 meetings (Figure 1).

Microsoft’s documentation for Bookings with Me explains the various settings.

It’s important to emphasize that bookings are regular Outlook meetings that show up in a user calendar alongside other events. There’s absolutely nothing different between a meeting scheduled in the normal way and one created using Bookings with Me. The intelligence in the Bookings with Me app is entirely in the user interface to define available slots and the processing that publishes those slots and allows people to make bookings. Users can edit the settings of their booking pages by going to the Booking app.

Not everyone will want to or be interested in Bookings with Me. Within a company, it’s a facility that people like HR consultants might use to allow employees to easily set up meetings to seek advice, Externally, people need an Azure AD account (school or work account) to book an appointment using Bookings with Me. The calendar owner remains in full control at all time and can reschedule or cancel appointments made with them at any time. Those who request meetings can also cancel or reschedule appointments (with the calendar owner’s assent).

Publishing and Using a Booking Page

When the schedule is ready, the user can publish (share) their availability for meetings. If the user hasn’t published a booking schedule before, the app generates a URL that the user can share with people who might want an appointment (Figure 2). For instance, they could include the URL in their email signature or publish it in their Teams status.

Clicking the link displays the user’s personalized booking page and exposes the available time slots based on the schedule established by the user (Figure 3).

Bookings and Bookings with Me

Some are confused between Bookings with Me and Microsoft Bookings. The differences are straightforward:

• Bookings with me is for personal use and deals with 1:1 meetings only. It is an Outlook feature that can schedule Teams online meetings. All events are in the user’s calendar.
• Microsoft Bookings is a separate application with its own (scheduling) mailboxes intended for use by a group or other entity.

Whether the advent of bookable time in OWA will convince more people to create Bookings with Me pages to allow others to schedule meetings with them remains to be seen. If you need a feature like this, it’s nice to have Bookings with Me. If not, it’s very safe to ignore bookable time.

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 happens, why it happens, and what new features and capabilities mean for your tenant.

Email Signatures Shared between Outlook and OWA But Not a Panacea for Signature Management

A reader pointed me to Microsoft’s Email Signature Gallery and asked if these signatures could be used with Outlook and OWA. The answer is yes, and there’s documentation to show how, which is always nice.

The gallery of email signatures is in a Word document (Figure 1), which can be downloaded or edited online. Editing is important as you need to update one of the sample signatures to use it.

After making the appropriate changes, you can cut and paste the signature into OWA or Outlook desktop (Figure 2) and the wonders of roaming signatures will make it available in both clients. Basically, all you need to do is replace the photo, update the values for title, phone numbers, organization, and address, and add links for your web site and Twitter handle. The email signatures gallery sounds like a very useful tool, but some downsides exist.

According to message center notification MC450845 (October 27, 2022), rollout of roaming signatures should now be complete. Microsoft also refers to the feature as “cloud signatures.” Both mean the same thing. The signature information is in user mailboxes and clients download signature information from the mailbox to apply signatures to messages.

Set-MailboxMessageConfiguration Remains Broken

The first issue is that Microsoft hasn’t addressed the issue with roaming signatures that broke the Set-MailboxMessageConfiguration cmdlet by removing HTML support for signatures in OWA. Microsoft removed the warning from the documentation that roaming signatures causes the problem, which was nice of them. The problem means that if you’ve taken the time to develop nicely-formatted signatures for OWA, any scripts that apply OWA signatures to mailboxes won’t work.

You can’t make an omelette without breaking eggs and Microsoft would say that you can’t introduce roaming signatures and give users a choice of signatures to use without breaking something. At least, I think they’d say this because they broke something.

It’s reasonable to assume that an update would be necessary for the Set-MailboxMessageConfiguration cmdlet after the introduction of roaming signatures. The update needs to:

• Support the storage of signature information in the user’s mailbox.
• Support reading and setting of multiple signatures per mailbox.
• Support selecting a default signature for new messages and replies from the available set.

It would be nice if Microsoft fixed the cmdlet problem so that those who’ve invested time and energy to develop PowerShell scripts to manage email signatures can continue to benefit from their work.

Roaming Signature Data in User Mailboxes

Up to now, the cmdlet could retrieve signature information from its settings. Now it must read data from the ApplicationDateRoot\49499048-0129-47f5-b95e-f9d315b861a folder in the non-IPM part of the mailbox. The MFCMAPI utility reveals that each signature has its own sub-folder (Figure 3) along with other information stored in ApplicationDateRoot\49499048-0129-47f5-b95e-f9d315b861.

The folder for a signature has a contents table storing some message items. The message items hold the signature data (Figure 4) in HTML format, including graphic elements like icons.

It’s obvious that the implementation of roaming signatures is very different in many ways to the simplicity of the earlier approach taken by OWA, which only supports a single HTML signature.

Roaming Signatures Work for OWA

In any case, signatures updated in Outlook desktop become available to OWA (and vice versa) after a period for the clients to learn about updates and refresh caches. Figure 5 shows the signature from the email signatures gallery that I pasted into Outlook as it appears in an OWA message.

Current State of Play

The current state of play is therefore that clients that support roaming signatures (OWA, the Monarch client, and the latest Outlook click to run builds) share signatures stored in user mailboxes. No matter what client someone updates a signature in or the source of the signature (from the gallery, from another user, or generated by the user), the clients will all pick up and use that signature.

Does this mean that ISV signature management products like Code Two’s Email Signatures for Office 365 are out of business? Not at all. Roaming signatures fix a problem in that a common signature is now available within the Outlook client family. It’s not a universal panacea for email signature management and does nothing about making sure that people use suitable corporate signatures throughout the organization, including with non-Outlook clients. If you’re interested in central management of email signatures across multiple clients, there’s still a ton of value to be gained from investing in the right tools.

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 happens, why it happens, and what new features and capabilities mean for your tenant.

Being Able to Work with Folders and Rules Make Outlook Groups More Useful

In August 2022, Microsoft announced that support for group owners and members to create and use folders and inbox rules in Outlook groups was coming. As is often the case, the rollout of the new functionality stalled a little, but is now reaching tenants (MC422161). The feature only works with OWA and Outlook Monarch and there’s no news when, if ever, it will appear in Outlook desktop or Outlook mobile. Nevertheless, giving Outlook groups some new functionality is welcome as not much has happened in this area for a while. The last major update was the addition of Send As and Send on Behalf of support in 2019.

New Support for Folders and Rules

The new capability allows group owners and members (if allowed) to:

• Create new folders in the group mailbox used by an Outlook group. Although you can then list and access the new folders, you can’t access any of the default folders in the mailbox except Inbox and Deleted Items (and calendar, but only through the calendar view). For years, people have asked for access to the Junk Email folder in group mailboxes to allow them to rescue messages that end up there.
• Move and copy items between folders. Oddly, OWA doesn’t support drag and drop of items between group mailbox folders.
• Create rules to process messages delivered to the group mailbox’s inbox.

Group owners can always create and delete folders and rules. Group members need permission before they can use these functions.

What’s odd about this implementation is that OWA has allowed access to group folders for years if you add a group mailbox to its set of resources as a shared folder. For instance, Figure 1 shows the folders in a group mailbox when accessed as a shared folder. You can see default folders like Archive and Junk Email. The “Happiness” folder, created using the new functionality, is also visible.

Figure 2 shows what you see using the new feature. The Happiness folder is present, but there’s no trace of the Drafts, Archive, Sent Items, or Junk Email folders. I realize that Microsoft didn’t set out to make all folders in a group mailbox available, but it would be nice to know why not, especially when it’s possible to leverage code that already exists (albeit for group owners only).

Curiously, you can only drag and drop a message from another folder to the inbox of a group mailbox. The other folders are there but OWA won’t move items to them. Instead, you move the item to the inbox and then move it from there to the desired folder.

Another oddity is that if you add a group as a favorite, OWA only displays the Inbox when you access the mailbox. This is likely by design because an OWA favorite is a folder rather than a complete mailbox, but it’s something that might confuse users.

Organization-Wide Settings

Several organization-level and group-level settings are available to control the new functionality. A tenant administrator can use the Set-OrganizationConfig cmdlet to update these settings:

• IsGroupFoldersAndRulesEnabled: Defines if the new functionality is turned on or off. The default is False, meaning that OWA does not exposes the support for folders and rules in Outlook groups. Run the Set-OrganizationConfig cmdlet to update the setting to True to enable the new features.
• IsGroupMemberAllowedToEditContent: Controls if group owners see a permissions toggle in group settings to control the ability of group members to move, copy, and delete messages and create and manage rules. The default is True, meaning that the toggle is available. If set to False, group owners don’t see the toggle and group members cannot move, copy, and delete items.
• BlockMoveMessagesForGroupFolders: Controls if the move option is available to group members. If True, they can move items to other folders. If False, they cannot. The reason why you might prevent group members moving items is to keep all received messages in the Inbox where they can be accessed by people using Outlook desktop and mobile clients.

Group owners can always delete, move, and copy items.

Group-Level Setting

After making sure that the organization IsGroupMemberAllowedToEditContent setting is True, we can move to group-level control. In my tenant, the permissions toggle (Figure 3) to allow group members to move, delete, and copy items is off for all groups, meaning that a group owner must go and switch the toggle before group members can edit content. It can take up to 20 minutes before the change becomes effective. This is probably due to caching and the need to publish the new settings to OWA.

Rules

Except that fewer actions are available, creating a new rule to process inbound email for the group works exactly like personal inbox rules in OWA. Go to group settings and select the Rules option. OWA displays the screen shown in Figure 4 to allow the input of:

• A rule name.
• Rule conditions.
• Rule actions. In Figure 4, you can see that the Move action is unavailable. This is because the BlockMoveMessagesForGroupFolders organizational setting is True.

One point to remember is that rules only apply to the copy of an inbound message delivered to the group mailbox. Group members that subscribe to the inbox to receive copies of messages sent to the group still receive those copies.

Progress But More to Do

There’s not much more to say about folder and rule support in Outlook groups. It’s progress because it enables more ways to work with email in Outlook groups. However, the nagging feeling is that most Microsoft 365 Groups created today are used with Teams. Quite how many Outlook groups are used to process real work is unknown, but presumably there’s enough for Microsoft to continue adding new features.

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.

Users Can React with an Emoji Instead of Sending an Email Reply

Updated 6-Jan-2024

We like to keep a close eye on changes Microsoft makes within Office 365 to make sure that the Office 365 for IT Pros eBook contains the most essential information for tenant administrators. Sometimes, Microsoft publishes details of a change that’s mildly interesting but doesn’t meet the threshold for inclusion in the book. Such is the case for Microsoft 365 notification MC445423 (13 October), announcing the introduction of reactions for Outlook.

Reactions in Outlook work the same way as reactions in Teams do. Microsoft says that reactions allow users to show their “appreciation and empathy with one click or tap.” In other words, instead of sending a reply by email to say that you appreciate the content of a message, you use a reaction.

Update: See this article for instructions how to block Outlook reactions using a mail flow rule.

All Outlook Clients Covered

The feature is scheduled to appear in all versions of Outlook with the following Microsoft 365 roadmap ids:

• 69095 Outlook for iOS.
• 69097 Outlook for Android
• 70615 OWA (including the Outlook Monarch client).
• 93321 Outlook for Mac
• 98101 Outlook for Windows (desktop)

Microsoft says that roll-out for all clients except Windows starts in mid-October and will complete by the end of the month. Outlook for Windows is always a little behind (or a lot behind) when UI updates are necessary to support new features. For instance, external tagging for email arrived in Outlook for Windows a year after the other clients. In this case, Microsoft expects to roll-out the feature at around the same time and complete it worldwide by the end of December. We’ll see. It’s important that all Outlook clients support the feature.

It’s important that all Outlook clients support reactions. If a gap exists, senders and recipients won’t see or be able to add reactions. Of course, many clients that connect to Exchange Online won’t support reactions, including older Outlook clients, POP3 and IMAP4 clients, and Exchange ActiveSync clients like the Apple iOS mail client. Without UI and code updates to recognize, display, and interact with reactions, these clients will be a reaction-free zone.

Sending Reactions

To send a reaction, look for the icon (a face) in the set of actions displayed for a received message. Hover over the icon and you’ll see the set of available reactions (Figure 1). Six are available for now (thumbs up, heart, celebrate, laugh, surprise, and sad), which is the same set that Teams originally supported before it upgraded its UI to allow users to select a reaction from 800+ emojis.

Six different shades of thumbs-up are available to cater for different skin tones. This is the same set of “inclusive” emojis Microsoft launched for Yammer in February 2021. Like Yammer, Outlook remembers which skin tone you prefer and uses it as the default in the future.

A short time after reacting to a message, the reaction appears in the copy of the message in the mailbox of the sender and other recipients. You can remove and replace a reaction to increase or decrease the level of empathy felt towards a message content. Again, after a short time, the updated reaction appears for the other message copies.

Notifications

Email senders receive notifications as recipients add reactions to messages (Figure 2).

Microsoft says that senders of messages who receive reactions will receive a digest email. So far, no trace of a digest email for reactions has appeared.

Cross-Tenant Outlook Reactions

According to Microsoft, reactions only work for messages received from someone inside the same tenant. However, I have tested this feature across different tenants, and it seems to work, perhaps if the two tenants are in the same Office 365 data center region. Figure 3 shows a message in a tenant that’s received reactions from users in two other tenants.

Outlook.com and Exchange Online share the same infrastructure, but reactions don’t work across the commercial-consumer boundary. I didn’t test reactions for messages from other email systems, including on-premises Exchange Server. Given that the display of reactions depends on the availability of suitable UI and code to understand reactions, it didn’t seem to make much sense to pursue this question.

Outlook Reactions in MAPI Message Properties

An inspection of message properties with the MFCMAPI editor reveals that several properties are used to track reactions. Figure 4 shows the ReactionsSummary property for a message, where you can see that the message received reactions from two recipients. Other properties track the count of reactions and a user’s history of adding reactions to a message.

The Teams Oreo Emojis

Speaking of things that won’t turn up in the Office 365 for IT Pros eBook, the October 18 announcement that Microsoft had teamed up with Nabisco (the maker of Oreo Thins) to create a 15-minute break as part of National Cookie week left us cold. A fair case is arguable that too many emojis are already available in Teams. Adding two more to represent an Oreo biscuit and a smile with an Oreo biscuit (Figure 5) hardly seems like a good use of Teams development effort.

In any case, type (oreo) or (oreoyum) if you must.

Will Outlook Reactions Succeed?

I’m a bad person to judge if reactions in Outlook will be successful. I never used the original Likes feature (announced in September 2015), which is a similar concept and uses a similar mechanism to track Likes received by messages. Perhaps expanding the set of available reactions will help people appreciate the feature.

What’s probably more important is that Teams has laid the foundation for people to understand when to use reactions to respond to messages. We’ve been using thumbs up, hearts, and laughs to respond to chats and channel; conversations for years. Although reacting is the same as in Teams, a large percentage of email traffic is for business communications where a simple reaction is neither appropriate or sufficient. Email is a very different way of communicating to Teams.

I don’t know if reactions can transition to Outlook in a way that makes sense and adds value, especially when the feature only works for some messages handled by clients connected to Exchange Online. Time will tell.

Make sure that you’re not surprised about important changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

But What the Two Products Will Deliver is Very Different

Among the features listed by Microsoft at the launch of the Teams Premium product at Ignite 2022 are sensitivity label support for Teams meetings and intelligent meeting recap. Sounds good, but then the Outlook team revealed that they will ship sensitivity support for Outlook meetings and a meeting recap feature among the set of new capabilities planned to be available to targeted release customers before the end of 2022.

The Teams Premium product is currently slated to cost $10 user/month, yet Outlook appears to be about to deliver the same functionality at zero cost. Does that make sense? Actually, it does, but in a weird kind of way.

Teams and the Exchange Calendar

Teams depends on Exchange for its calendar. The Teams calendar app is built on top of the Exchange calendar, which handles the scheduling of meetings. Teams uses a deeplink to connect the scheduled events in the Exchange calendar to the online space used to host meetings. As far as Exchange is concerned, it delivers a scheduling capability for meetings and nothing more. What happens to extend that basic functionality is entirely under the control of the app that creates the extension. This is how Teams handles features like meeting roles, the lobby, and so on.

Outlook, Teams, Meetings, and Sensitivity Labels

Outlook will “provide the capability to apply sensitivity labels to meeting invites and protect them too. ” In other words, Outlook will allow organizers to apply a sensitivity label to a meeting and the protection assigned by the label will apply to meeting artifacts, like attachments.

The Teams description focuses more on the automatic application of sensitivity labels (an Office 365 E5 feature) “to apply relevant meeting options automatically.” Apart from the automatic application of labels, the assignment of meeting options is a capability like the way that containers (Teams, Groups, and Sites) inherit settings like privacy and guest user access from sensitivity labels.

It therefore appears that Outlook will extend the existing method of protecting messages with sensitivity labels to cover meeting invitations. Teams Premium will inherit settings from sensitivity labels to make sure that critical meetings and all the artifacts associated with the meeting are properly protected.

Meeting Recaps

Outlook’s definition of meeting recap is that “users have new discoverability and productivity features to easily find and access information about a meeting including files, transcript, and the recording directly from the calendar event in Outlook.” The screen shot for Outlook meeting recap posted by Microsoft shows how users can click a View meeting recap link in meeting properties to see the meeting transcript and other information. It’s a nice way to catch up with what happens during a meeting.

Teams Premium applies Artificial Intelligence to derive more value from the same meeting data. Microsoft says that “intelligent recap uses AI to suggest action items and owners” and “After the meeting, intelligent recap will create smarter recordings with automatically generated chapters and insights such as when your name was mentioned, when a screen was shared, or when you left a meeting early.” This is a more proactive and expansive use of information gathered during a meeting.

Of course, whether users will like Teams suggesting action items and owners automatically is quite another matter. And adding automatically generated chapters (markers) to the video recordings of Teams meetings is only useful if someone actually goes back to review the recording. As we know from the data Microsoft shared when they introduced the auto-expiration feature for Teams meeting recordings, relatively few people consult a meeting recording after it is stored and available to participants.

Confusing Naming

It would be nice if Microsoft product groups didn’t use the same terms for very different features. The bottom line is that the public information revealed by Microsoft to date indicates that Outlook will deliver support for sensitivity labels for meeting items and a basic meeting recap. Teams Premium uses more from Microsoft’s bag of AI tricks to introduce intelligence into understanding what meeting data means and how it could be better used. Of course, all of this could change before the software is generally available, so final judgment must be reserved until we see the Outlook and Teams Premium implementations in real-life scenarios.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Outlook Sweep Works in Monarch Client Too

I’m not quite sure why Microsoft made a big thing about highlighting the support for sweep rules in the latest build of the Monarch (One Outlook) client. Unless it was a subtle way to emphasize that when Monarch replaces the current Outlook for Windows client, users will gain access to features like Sweep that Outlook for Windows doesn’t support. If so, the message was too subtle and it went right over my head at the time.

Sweep Options

OWA and Monarch are the only clients that support Sweep today. The idea is that you use Sweep to clean up your mailbox by “sweeping” unwanted items into somewhere like the Deleted Items folder. The options are straightforward (Figure 1). After selecting a message from someone that you want to “sweep” (the sender) you can:

1. Move all messages from the sender in the source folder to the destination folder (the default is Deleted Items, but you can choose any mailbox folder). OWA processes this request immediately and doesn’t create either an inbox or sweep rule.
2. Move all messages from the sender in the source folder to the destination folder. OWA moves any matching messages immediately and creates an inbox rule to move future messages.
3. Keep the latest message from the sender and move the rest from the source folder to the destination folder. This action creates a sweep rule.
4. Move matching messages older than 10 days from the source folder to the destination folder. This action also creates a sweep rule.

Because Exchange Online processes both inbox and sweep rules on the server, it doesn’t matter that other clients don’t support the Sweep feature.

Comparing Inbox and Sweep Rules

When I started looking at the Sweep feature, I wondered why the developers opted to use a mixture of inbox and sweep rules. The probable answer is that it saved time to reuse existing functionality (inbox rules) to handle the situation where a user wants to remove all items from a sender in a folder plus any future matching items that arrive into the mailbox (inbox).

The inbox rule generated for this option is simple. Here’s an example

Get-InboxRule -Mailbox James.Ryan | fl

Description                           : If the message:
                                       the message was received from 'Petri IT Knowledgebase'
                                        Take the following actions:
                                         delete the message
                                         and stop processing more rules on this message

Enabled                               : True
Identity                              : cad05ccf-a359-4ac7-89e0-1e33bf37579e\8434222137593561089
Name                                  : Messages from Petri IT Knowledgebase

While inbox rules process items as Exchange delivers them to the Inbox folder, Sweep rules can apply to any folder except Sent Items. That’s because the items in Sent Items come from the mailbox owner and it doesn’t make sense to clean up their own messages. It’s also not supported to create a sweep rule from an item in search results.

Sweep rules apply on a scheduled basis. In other words, a background Exchange assistant runs to execute the rules. Like all Exchange background assistants, the exact time when the process runs to sweep items out of a folder depends on its defined workcycle and the service load, so you can’t predict when item sweeping occurs.

Outlook Sweep Rules and PowerShell

An Exchange administrator can create sweep rules for mailboxes with PowerShell. A mailbox owner can use PowerShell to create rules for their own mailbox, but this hardly ever happens.

The New-SweepRule cmdlet creates a new sweep rule. This example moves items from the designated sender from the Inbox after seven days:

New-SweepRule -Enabled:$true -ExceptIfFlagged:$True -ExceptIfPinned:$True -KeepForDays 7 -Mailbox james.ryan@office365itpros.com -Name "Clean up Petri Seminars" -Provider Exchange16 -Sender Partners@petri.com

According to Microsoft documentation, the ExceptIfPinned and ExceptIfFlagged parameters are supposed to create exceptions for messages pinned to the top of the folder or flagged for some reason. Although I’ve included them in the command, New-SweepRule ignored the settings. Running Set-SweepRule to update the rule didn’t work either:

Set-SweepRule -Identity cad05ccf-a359-4ac7-89e0-1e33bf37579e\UIvh1A6dr0Cci8pYuUNHWA== -ExceptIfFlagged:$True -ExceptIfPinned:$True

Again according to the documentation, destination and source folders are identified using the normal Exchange notation of mailbox identity:\folder name (for instance, TonyR:\Archive). Both New-SweepRule and Set-SweepRule refused to accept any but deault folder destinations. These symptoms might be associated with the upgrade of older cmdlets to the V3 of the Exchange Online management module.

To complete this discussion, to remove a sweep rule, run the Remove-SweepRule cmdlet.

Remove-SweepRule -Identity cad05ccf-a359-4ac7-89e0-1e33bf37579e\YCfJ7ktCd0KNQuPqhtMAsg== -Confirm:$False

Outlook Sweep Removes Junk

The Sweep feature is an excellent way to remove service messages like Teams missed message notifications, newsletter updates, and other non-essential items from mailboxes. Of course, you could ignore any clean-up and depend on search to find messages when required, but it’s nice to get rid of some of the clutter that drops into mailboxes on an all too frequent basis these days.

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.

Better Late than Never for the Windows Desktop Client

The preview for External tagging for Exchange Online messages first appeared in March 2021 with general availability in October 2021. Microsoft 365 roadmap item 70595 covered OWA, Outlook Mobile, and Outlook for Mac. For no apparent reason, Outlook for Windows was conspicuously missing, perhaps because Microsoft anticipated faster progress with the Outlook Monarch client.

A year after the other clients received external tagging, builds of Outlook for Windows support the feature. I’ve been using it with beta channel releases (Version 2210, build 15726.20000 and later). External tagging works as expected with Outlook for Windows, but a potential reason for its delay is apparent at first sight.

Fitting External Tagging into Outlook for Windows

Compared to the other Outlook clients, Outlook for Windows is a antique beast of a program. Although Microsoft has tweaked Outlook’s design over the years, the same basic layout persists. Anyone who used Outlook 97 twenty-five years ago would recognize the latest click-to-run build. Sure, the menu is nicer, and Outlook boasts a reading pane to make it easier to triage a busy inbox, but the structure of mailbox resources, folders, and messages remains.

Preserving the essence of Outlook’s interface creates continuity for users. Change has happened over the years, but nothing to totally rebuild the interface in the same way that the Monarch project is progressing. The upshot is that Outlook’s interface is full of items and options, and the views used to display lists of messages are quite tight. The result is that the new external tag must fit into a confined space, and it looks like it (Figure 1).

I realize I am not a professional designer and that my reaction is very much that of an amateur, but the external tag adds more clutter to an already crowded Outlook screen. In any case, the UI is what it is.

As you’d expect, external tagging works exactly the same way as in other Outlook clients. Any email received from an external domain that isn’t marked for exclusion for tagging is tagged as external (see my previous article for details about how to exclude a domain). Most of the email I receive is from external domains, and even after excluding domains that I correspond with extensively, I see many tagged messages.

Raising User Awareness

To be fair, that’s the point. The idea of external tagging is to highlight these messages to users with the hope that people will pay extra attention to any links and other content. Organizations have used transport rules to stamp inbound email with similar labels for years and highlighting email does help. However, like any visual clue, user fatigue grows over time and the tags are probably less effective once they become part of the Outlook landscape.

External tagging also helps to avoid recipients falling into the trap of business email compromise (BEC). Many BEC attacks happen due to compromised accounts, but the removal of basic authentication from email connectivity protocols should reduce compromise through attacks like password sprays, meaning that attackers need to employ new tactics.

One is when email appears to come from an internal domain but really comes from a domain with a very similar name that’s set up by attackers with the aim of duping recipients. Humans might be fooled when an attacker swaps 1 for an l in a domain name, but a computer won’t be. Unfortunately, there’s no guarantee that people won’t ignore the external tag on an email that apparently comes from an internal sender.

External Tagging for Some, Not All

Adding external tagging to Outlook for Windows rounds out the Office 365 story. At least, if you use the click-to-run version. Perpetual versions like Outlook 2019 don’t include the necessary interface and Exchange Server doesn’t implement the feature for on-premises users. The classic approach of using transport rules to label external mail work in these scenarios. If you prefer to keep these methods, disable external tagging for Outlook by running the Set-ExternalInOutlook cmdlet:

Set-ExternalInOutlook -Enabled $False

Microsoft has probably done as good a job as possible to implement external tagging given the constraints of Outlook for Windows. External tagging works, it’s a valuable feature, and it will keep some out of trouble. That is, if you notice and respect the tags.

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 happens, why it happens, and what new features and capabilities mean for your tenant.

This One Outlook Build is Worthwhile

Updated 13 March 2023

In May 2022, a leaked build of Microsoft’s new One Outlook (“Monarch”) client emerged. A week or so later, Microsoft made an official beta available to members of the Office Insiders Beta Channel. At the time, I called Monarch a slightly prettier version of the OWA client available for Exchange Online, albeit one that missed important functionality.

A refreshed Monarch client is now available to all Office Insiders. Based on working with the new Monarch for a couple of days (and years of Outlook), it’s still a slightly prettier client. The big difference is that the new build is usable for real-life day-to-day work, especially if your preference is to use OWA rather than desktop Outlook.

Update: According to message center notification MC526128 (11 March 2023), users of the Current Channel for Microsoft 365 apps for enterprise will be able to try out the new client in early April, while those who use the Monthly Enterprise Channel will see it in May.

New Features Highlighted by Microsoft

This isn’t because of the features touted by Microsoft. I use Monarch with a Microsoft 365 account, not a Microsoft consumer account (OWA is more than sufficient to deal with my consumer email). The current build is still limited to a single account, but Microsoft says that support for multiple accounts is coming. I don’t use Quick Steps because my triage of email is simple: read and keep or delete immediately. And while I like the way that calendar gives the current day more space in calendar views, I couldn’t adjust the column width as promised. Every attempt resulted in Monarch trying to create a new event. Maybe it’s just me.

I did like the ability to customize the ribbon bar (Figure 1), if only because I could get rid of the button to move items to the dead-end street called the Archive folder. I’m not sure I think of the ribbon as having a sleeker look and feel, but beauty is in the eye of the beholder.

Keeping Features

As you might expect, features that appeared in the previous build are still there. This includes support for Loop components, which didn’t appear in OWA and Monarch for some time after Microsoft issued the original beta. The same oddities appear with the Loop implementation, including adding the sender as a Cc recipient for messages and setting the sharing link for the Loop component to be read-only (Figure 2) if that’s what’s defined for files and folders in the organization sharing policy.

Sending out read-only sharing links makes little sense when email is used as a vehicle for collaboration, and it’s surely possible for Microsoft to come up with a way to allow organizations to implement a different sharing link policy for loop components used in OWA, Outlook for Windows, and Teams chat.

Microsoft’s blog post refers to the “new Outlook calendar board view.” This has been available in OWA since July 2021 after they decided that Outlook Spaces (the Moca project) wouldn’t move forward.

The post also refers to Sweep as a way to “to keep your Outlook inbox tidy.” This is another feature that appeared in OWA and then submerged to have more work done to improve its functionality before reappearing. I rather like Sweep because it’s an easy way to get rid of a lot of messages at one time. Select a sample message (in Figure 3 it’s a missed message notification from Teams) and with one click, the client moves all matching messages to a nominated target folder (Deleted Items is the default).

If you choose to use options other than an immediate move (like keep the latest but move everything else), Exchange Online creates a “sweep rule.” The rules are available in the Mail section of Outlook settings. They can also be seen by running the Get-SweepRule PowerShell cmdlet. Background processes run the sweep rules defined in mailboxes periodically, so don’t expect messages governed by these rules to disappear immediately after delivery.

More Coming

Although OWA users will find it easy to switch to Monarch, offline access remains the big blocking factor for those who might consider switching from Outlook desktop clients. Offline access is on the list of features Microsoft plans to release in the coming months. Even in an always connected world, network outages do happen… and having that offline data to work with can be awfully important.

Keep up to date with developments like the development of One Outlook and the Monarch client 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.

Now in Preview and Coming Soon

In July, Fluid components made their appearance in OWA. Now they’re available in Outlook for Windows (Microsoft 365 apps for enterprise). According to Microsoft 365 notification MC360766 (updated September 21, 2022), Microsoft now expects general availability for Loop components in Outlook (OWA and Outlook for Windows) in November 2022. There’s no word about availability of Loop in Outlook for Mac and they won’t be available in the Outlook perpetual versions like Outlook 2019. Loop is very much a cloud application.

To check things out, I used build 2209 (current channel preview) and discovered that things worked very much like OWA (no surprise there!). Figure 1 shows the Loop components displayed in Outlook’s create message window.

Like OWA, Outlook for Windows adds the sender as a CC recipient when a message contains a loop component. Apart from ensuring that the sender receives a copy of their own message, this doesn’t seem to make any sense. The copy of the message held in the Sent Items folder contains the loop component, and any change necessary to the component can be made through that message. As a matter of practice, I remove the CC recipient from any messages with Loop components that I send. So far, the world (or Outlook) hasn’t come to a crashing halt.

Loop Sharing Permissions

When you create a Loop component in Outlook, its physical manifestation is as a fluid file stored in the Attachments folder in your OneDrive for Business account. This is the file that users edit whose contents synchronize to keep everyone who has the component open see changes almost immediately. Of course, people can’t make changes unless they have the permission to do so.

I was bothered when I discovered that OWA sets the default sharing permission for Loop components to read-only. Outlook does the same thing and there’s no good reason for this either. The very reason why you might use a Loop component is to create a shareable canvas to collaborate with the recipients of a message. Setting the sharing permission to read-only reduces the value of components to be no better than static text pasted in from Word or Excel or created from scratch in Outlook.

Being forced to update the sharing link is an unnecessary step, but it’s relatively straightforward. Click the link to the fluid file to reveal the link settings and change the link to allow edit access as necessary. For instance, it makes sense to allow message recipients to edit a Loop component received in email (Figure 2). At least, it makes sense to me.

Multiple Loop Components in Outlook Messages

Like OWA, multiple Loop components can exist in a single message, mixed with normal text. For instance, you could have some introductory text followed by a checklist component, some further text, and then a table component. Each component has its own fluid file stored in OneDrive for Business. This is different to Teams chat where a Loop component must be the only thing in a message.

You can copy a Loop component from Outlook or OWA and paste it into another app (only Teams chat for now) and the component is editable in its new location. Changes made in Teams show up in Outlook and vice versa. This shouldn’t be surprising because you’re essentially copying the link to the component and pasting it into a different app, but it’s nice that it works so smoothly.

Loop Components in Outlook Mobile

One thing I hadn’t tried before was editing a loop component from Outlook mobile (iOS). When I clicked on the component, Outlook called the Office app and opened the loop component to allow me make changes, which then synchronized back to Outlook desktop. Although Outlook mobile doesn’t yet support full integration with loop components, it’s good that a solution exists to access and edit components on a mobile device.

Loop Forward

Microsoft is making steady (but slow) progress to make Loop components available in Microsoft 365 apps. Email poses different challenges to Teams in that email is a more outward-facing collaborative application with a large proportion of messages usually sent outside the organization. Even though Teams supports external access for chats, most of its traffic is inward-facing.

Currently, you can’t send a message with Loop components to external recipients. At least, Outlook protests when you add an external recipient. You can make Loop components accessible to external recipients, but the experience of accessing the components is not seamless, and that’s why Outlook warns against adding external recipients to messages containing Loop components. Obviously, this is something that needs to change to make Loop more amenable to email. Maybe that’s coming. We wait developments with bated breath.

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 happens, why it happens, and what new features and capabilities mean for your tenant.

The Wonders of AutoMapping

Automapping is the process by which Exchange “tags” a mailbox after a user receives full access permission to the mailbox. Outlook automapping happens when the client learns about the new access. The mechanism goes back to Exchange 2010 SP1. In some old Exchange server documentation, Microsoft explains automapping as follows:

“Exchange populates the msExchDelegateListLink attribute in Active Directory to locate mailboxes for which the user has Full Access permission, and then provides this information to the Autodiscover service. Autodiscover then populates the AlternateMailbox attribute with the information necessary for Outlook to open the full access mailboxes.”

Details are essentially the same for Exchange Online. Outlook uses the information received from Autodiscover to add the mailbox to its resource list. Resources include the user’s primary mailbox, their archive mailbox (if enabled), public folders, group mailboxes, and shared and other user mailboxes to which they have access. When Outlook starts, it opens all its resources.

Outlook automapping means that the client automatically opens mailboxes without user intervention. Fifteen minutes or so after gaining access to a mailbox, Outlook reacts to the tag and the mailbox appears in its resource list.

Mostly, Outlook automapping is a very valuable and worthwhile feature, which is why it’s the default when granting mailbox access through the Microsoft 365 admin center, Exchange admin center (EAC), or PowerShell. Figure 1 shows how to add full access permission through the Microsoft 365 admin center (left) and EAC (right). It would be nice if Microsoft rationalized the words used to describe the action.

In all cases, full access only grants permission to manage all folders in a mailbox. Users need to receive a separate permission to send as the mailbox or send on behalf of the mailbox.

Outlook mobile has its own delegate permission model while OWA opens other mailboxes as shared folders. It’s also possible to assign folder-level permissions to selected folders instead of the entire mailbox.

Synchronization Concerns

Outlook synchronizes the contents of automapped mailboxes into the OST for the user’s primary mailbox. Because of more generous quotas, Exchange Online mailboxes tend to be larger than on-premises mailboxes, so the OST files for cloud mailboxes are also larger. The size of the OST depends on the offline synchronization period set for Outlook (from one week to all). Obviously, if the user decides to synchronize their entire mailbox, the OST is larger than if they synchronize for the last year.

When Outlook 2003 introduced “drizzle-mode synchronization” and other network smarts (like an express thread to synchronize outgoing messages), the hard disks available for PCS were not as large or fast as those available today. In those days, Outlook started to experience performance problems after an OST file approached 8-10 GB in size.

The advent of solid-state drives, especially in laptops, has mostly cured this problem and users generally don’t meet performance issues due to the OST. That is, unless Outlook synchronizes multiple mailboxes into the primary OST. Depending on the mailbox sizes, the OST can grow to 50 GB or more. Solid state drives deliver great I/O performance, but even the fastest drive has its limits.

An efficient OST is important to Outlook. Having content for all mailboxes in local storage allows Outlook to switch between mailboxes and folders very quickly without the need to contact the server.

Mailbox Access Without Outlook Automapping

If users need access to multiple large mailboxes, it might be a better idea to grant them access without using Outlook automapping. To do this, you must:

• Grant full access to the mailbox using the PowerShell Add-MailboxPermission cmdlet. For example:

Add-MailboxPermission -AccessRights FullAccess -User Kim.Akers@office365itpros.com -Owner Customer.Services@Office365itpros.com -Automapping $False

• Manually add the mailbox to Outlook’s profile so that Outlook knows it must open the mailbox. Mailboxes added in this way do not synchronize to the primary OST. Instead, Outlook uses a separate OST for each mailbox.

As explained in Microsoft’s documentation, if a mailbox is automapped and you want to manually add it, you must remove the full access permission and then add it again without automapping.

Using separate OSTs means that each file is smaller and should perform better. The downside of manually adding a mailbox to the Outlook profile is that this action is PC-specific. If you move to a new PC, you must add the mailbox to the Outlook profile on that PC. By comparison, because Autodiscover provides Outlook with information about automapped mailboxes, Outlook learns about these mailboxes automatically no matter what PC it runs on.

OSTs and NSTs

After manually adding a mailbox to Outlook, you should have the following files in the Microsoft\Outlook folder of %LocalAppData%:

• An OST (offline slave table) file for the primary mailbox. This file stores the offline (slave) copies of items from the server copy of the user’s mailbox. Outlook names the OST file after the account’s user principal name (UPN), so it will be something like Kim.Akers@office365itpros.com.ost.
• An NST (network slave table) file for the primary mailbox. Amongst other data, this file stored offline content (messages and calendar items) for Outlook groups the user belongs to. Outlook groups are Microsoft 365 groups that use email conversations for collaboration. Outlook names the NST using the mailbox’s primary SMTP address, which could differ from the UPN.
• An OST for each mailbox added manually to Outlook.
• An NST for each mailbox added manually to Outlook.

The size of each file reflects the amount of data in the relevant mailboxes and Outlook’s offline synchronization setting. Windows Explorer doesn’t differentiate between OST and NST files and calls them all Outlook Data Files (Figure 2). To see the file type, you must examine file properties.

The information described above is what I see with Outlook for Windows click-to-run (Microsoft 365 apps for enterprise version 2208). The details might vary for different versions, but the concept remains valid.

Making Things Better

There’s no doubt that Microsoft could smoothen how automapping works. They could:

• Alter the portals GUI to allow administrators to choose whether to use automapping when assigning mailbox permissions.
• Add an option to allow an administrator to turn automapping off without forcing removal and reinstatement of the permission (this would probably happen behind the scenes, but a one-click option would be better).

I’m sure Microsoft would argue that the current scheme works well in most cases and that the number of people who don’t want Outlook automapping for mailboxes is minimal. If that’s the case, then the current manual process is acceptable, once you understand how automapping works, its effect on the OST file, and the alternative.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

An Attempt to Make Scheduling Meetings Easier

According to message center notification MC375740 (updated Jun 21, 2022, Microsoft 365 roadmap item 93239), the deployment of Outlook’s Booking with Me feature is rolling out to targeted release tenants. The deployment to standard release tenants will start soon and be complete in mid-August. Any user with an Exchange Online license has access to Bookings with Me unless the organization disables the feature for the entire tenant or individual users.

Despite its association with Outlook, Booking with Me is a separate app that uses Exchange Web Services (EWS) API calls to interact with user calendars. The idea behind the app is to allow internal and external people to request time in the calendars of other users through their Booking with Me page. The app is separate to the Microsoft Bookings app, with the basic differentiation between the target audiences: personal (manage meetings in my mailbox) and group (manage appointments for a group of people, usually for a business purpose).

Using Booking for Me

If your account isn’t blocked, a Create bookings page link appears in your OWA calendar (Figure 1). A similar link is not available in Outlook for Windows or Mac. After creating a bookings page, the link changes to Edit bookings page.

Clicking the link brings up a draft bookings page for you to populate with meeting type. A meeting type defines the characteristics of a meeting you’re willing to accept, including:

• Public or private: Anyone with the link to your bookings page can select from the defined public meeting types to create a meeting in your calendar. Only those with the link to a specific private meeting event can create those events. You might have a private meeting type that can be scheduled immediately at any time by selected co-workers and a public meeting type for everyone else.
• When it can happen: By default, you use the working hours defined for your calendar, but you can amend the available hours. For instance, you might decide to reserve slots between 10 AM and 11 AM each morning for meetings.
• How long a meeting will be: The default is 30 minutes. It can be as short as 10 minutes
• Where the meeting will be: The default is to create online Teams meetings., but you can define a location such as your office or a conference room.
• Create buffer times before and after meetings so that you don’t end up with back-to-back events. The buffer time is defined in minutes.
• How long in advance someone can schedule a meeting. The default is one hour, meaning that someone can look for a time slot in your calendar an hour ahead of the current time. As many people like to review meetings to decide if they will accept them or reschedule as necessary, a longer lead time might be better.

Figure 2 shows how to populate the settings for a new meeting type.

Each meeting type has a separate link used to make bookings. You don’t have to define all the meeting types immediately as you can add more over time. Just one is needed to create your booking page, which can take ten or so minutes for the service to set up.

Sharing Meeting Types

When the bookings page is ready, you can share its link with other people. The Share option generates a link like Book time with Sean Landy, which expands to a link to the BookWithMe service running on Outlook.com:

https://outlook.office.com/bookwithme/user/7b111e2fc69a4d309725c9bb579256ba@office365itpros.com?anonymous&ep=pcard

The important point to understand is that anyone with a meeting link (public or private) can book a meeting with you, even if they don’t have a Microsoft account.

You can share the link to your bookings page by copying it to include in a document, email, or Teams message, or add it to your email autosignature. OWA greyed out the option to add the booking link automatically in the edit email signature dialog. This was probably because I defined two public meeting types and OWA couldn’t choose which of the links to the meeting types to insert. The problem is easily solved by pasting the link to the bookings page into your email signature.

Booking Meetings

To book a meeting, use the link to someone’s bookings page or the link to a private meeting time that’s been shared with you. Booking with Me displays the page. You can then select the meeting type from the set displayed on the page and then choose a meeting time (Figure 3).

When someone schedules a meeting through Booking with me, both the requester and the person who hosts the meeting (the meeting owner) receive email confirmation. The meeting owner receives email to tell them that someone set up a meeting through their bookings page. The requester receives a regular meeting invitation. If the meeting is online, the invitation includes any custom Teams meeting information defined by the organization. To make this happen, the Bookings service impersonates the meeting owner and creates a meeting in their calendar with the person who requests the meeting. The calendar event is like any other event and can be updated or cancelled as necessary. This includes changes made by the requestor, who can use a link in the meeting invitation to access meeting details to reschedule or cancel the event.

Likely to be a Popular Tool

Booking with me is a good example of how many can deploy its software toolkit to combine different elements drawn from across Microsoft 365 to create a new solution that people can use without installing any additional software. Users might need a little help to understand how to create good meeting types, but once people get the hang of it, I think Booking with me will be popular. Let’s face it: few people enjoy organizing meetings, and if Booking with me helps to reduce the pain a little, it will deliver value.

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 happens, why it happens, and what new features and capabilities mean for your tenant.

Scripts Stop Working without Warning

In 2020, I wrote about how to create and apply corporate email signatures for use by OWA. Recently, things started go wrong and some people reported that the code didn’t work any longer. The issue is linked to the work Microsoft is doing to deliver Outlook roaming signatures, a much-anticipated feature that’s currently delayed until October 2022. The good news is that some progress is visible. The bad is that the development has caused problems for tenants that could have been avoided.

The Broken Set-MailboxMessageConfiguration Cmdlet

I’m all for Outlook roaming signatures. It’s a nice feature that should have existed across the entire Outlook family long before now. One of the consequences of the move is that Microsoft deployed code to allow OWA (and the Monarch client) to support multiple signatures (Figure 1) instead of the previous situation where OWA supported just the one. The code is available in all tenants, except those who have asked for it to be removed (see below).

Outlook desktop has long supported multiple signatures, so getting the functionality in OWA is goodness. However, the change means that the SignatureHTML parameter of the Set-MailboxMessageConfiguration cmdlet now includes a warning that:

This parameter doesn’t work if the Outlook roaming signatures feature is enabled in your organization. Currently, the only way to make this parameter work again is to open a support ticket and ask to have Outlook roaming signatures disabled in your organization.

In other words, the scripts developed to create nicely-formatted HTML signatures for OWA won’t work. Existing signatures remain in place and will work, but the cmdlet might fail if you try to update a signature. Note the word “might.” The strange thing is that sometimes the cmdlet fails and sometimes it works. For instance, I just ran these commands to set and check a HTML signature for a mailbox, and everything worked:

Set-MailboxMessageConfiguration -Identity $M.UserPrincipalName -SignatureHTML $SignatureHTML -AutoAddSignature $True -AutoAddSignatureOnReply $False

Get-MailboxMessageConfiguration -id Terry.Hegarty | Format-List SignatureHTML


SignatureHtml             : <html>
                            <body>
                            <b>Terry Hegarty </b>Valued Employee<br>
                            <b>Office 365 for IT Pros</b> Terenure, Dublin, D18A42Z2 Ireland<br>
                            / Email: <a href="mailto:&quot;Terry.Hegarty@office365itpros.com&quot;">Terry.Hegarty@off
                            ice365itpros.com</a><br>
                            <br>
                            </body>

But I know that many other people have difficulties making the cmdlet work, so the behavior is inconsistent and unpredictable, which is just the kind of unhappy behavior no one likes in code.

The only bright spot on the horizon is that the beta channel builds of Outlook for Windows share the same signature information with OWA and the Monarch client (Figure 2). Outlook for Windows now reads the signature information from a hidden folder in user mailboxes instead of the system registry. The folder for signature information is ApplicationDateRoot\49499048-0129-47f5-b95e-f9d315b861a6, with a separate sub-folder used for each signature. An item inside the folder holds the signature text. It seems like roaming signatures are getting closer, even if their development has caused some upheaval.

Only One Fix (or Patience Required)

As those involved in tenant management know, living with change is a constant inside Microsoft 365. In this case, change is happening (slowly) to enable a good outcome (Outlook roaming signatures), but Microsoft overlooked the need to upgrade the Set-MailboxMessageConfiguration cmdlet (or an equivalent Graph API) to allow organizations to continue managing signatures for mailboxes. That’s more than regrettable, especially when it happened with a total lack of communication to tell customers what’s happening.

If you run into the problem, Microsoft suggests that you open a case with Microsoft Support to ask them to arrange for the roaming/multiple signatures feature to be removed from the tenant. This process is likely to take a few days to complete. The alternative is to ignore the issue and wait until Microsoft delivers Outlook roaming signatures as promised in October. That update might, or might not, happen on schedule. But that’s the way of the cloud…

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

First Step Along the Path in Loopifying Email

Nine months after Loop components first appeared in Teams chat, the same components are available to include in OWA messages (message center notification MC360766, Microsoft 365 roadmap item 93234). The general availability date of June 2022 on the roadmap item is a tad optimistic as tenants configured for targeted release are only just seeing Loop components show up in OWA now. I have not seen Loop components show up in Outlook for Windows, bit according to Microsoft, general availability for Loop components in both OWA and Outlook for Windows is expected in July. That goal seems like quite a stretch.

The concept behind Loop components remains the same as in Teams chat. The author of a message inserts a component and edits its content. The physical instantiation of the component is a fluid file stored in the Attachments folder in the author’s OneDrive for Business account.

When they access a loop component, message recipients use a web sockets connection to receive changes made by others in almost real-time together with indicators to show where people are actively editing the content and where changes are made. A link in the message points to the file stored in OneDrive for Business and the app displays the content of the file in an inline editable frame.

Implementing Loop for OWA

If you have used Loop components in Teams chat, there’s not a lot to explain about the implementation in OWA. However, I did note a few points of interest:

• When you add a Loop component to a message, OWA adds your email address as a CC recipient. I don’t know why Microsoft does this as all the action does is deliver an unnecessary (and possibly unwanted) copy of the message to your Inbox. Some will like this approach because receiving a copy of the message in their Inbox reminds them that they’ve shared an editable component with others, but I think it’s a poor implementation. If you need to update a Loop component in a message you send, find the copy of the message in the Sent Items folder, and edit the component there. Alternatively, open and update the fluid file stored in OneDrive for Business.
• Despite Microsoft positioning Loop components as a new way to collaborate, OWA sets the Loop components in emails to allow read-only access to recipients in the same organization. This is dictated by the Files and Folders Links setting in the SharePoint admin center. That setting is focused on document sharing rather than editable components, and I think a separate setting is probably needed for Loop sharing links. Message authors can change the access to allow recipients to update components they receive in email, but it seems like an unnecessary step.
• You can include multiple Loop components in a single email and mix them with normal text. For instance, you could have a paragraph component as an introduction to a message followed by a task list. Each component has its own fluid file stored in OneDrive for Business. This is different to Teams chat where a Loop component must be the only thing in a message. OWA has always been able to deal with multi-part messages, so this isn’t too surprising.
• You can copy a Loop component from OWA and paste it into another app (only Teams chat for now) and the component is editable in its new location. Changes made in Teams show up in OWA and vice versa. This shouldn’t be surprising because you’re essentially copying the link to the component and pasting it into a different app, but it’s nice that it works so smoothly.

Figure 1 shows a Loop component in a message in the Sent Items folder that was pasted into a Teams chat and updated there.

For Now, Loop is Focused on Internal Collaboration

Generally, the Loop implementation in OWA does what you expect and is very usable. The big downside for now is that Loop components in OWA messages only work with people inside the same organization. The technical challenges of controlling access to recipients in other Microsoft 365 tenants (including hybrid deployments) and non-Microsoft email servers must be understood and addressed before you’ll see seamless interaction using Loop components for people inside and outside your tenant.

You can add non-tenant addressees to a message containing a Loop component, but when you send the message, OWA detects that the links in the message won’t work and signals the error (Figure 2).

If you go ahead and send anyway, external people will receive messages containing links to Loop components that they won’t be able to open. Sometimes, you might see the kind of message shown in Figure 3, which comes from an Exchange Online system mailbox in the tenant to notify a message sender that some problems occurring in granting access to Loop components in an email.

Given that we’re in the early days of emailed Loop components, I’m sure that the issue seen in Figure 3 is a glitch that Microsoft will soon iron out.

The Need for Client Updates Will Slow Adoption of Loop Components

Unlike Teams, the Outlook clients don’t share a common code base. This is what the One Outlook project aims to achieve, but for now the set of email clients in use ranges from those usually up to date (OWA) to those that often aren’t up to date (Outlook desktop). Even within the same organization, if a recipient uses an email client that’s not “Loop enlightened,” they’ll see a link to the fluid file instead of the fully-rendered content. People can use the link to open and interact with the Loop components, but that’s hardly the intended inline editing experience that Microsoft wants to deliver.

The list of email clients that can’t handle Loop components includes Outlook mobile, any other mobile client (like the Apple mail app), and older Outlook desktop clients. Even after Microsoft updates Outlook desktop, experience proves that it will take a long time before every Outlook client used in an organization can interact with Loop components. Perhaps Microsoft hopes that the existence of Loop components will convince customers to use recent versions of Outlook. If that is the hope, it might be a long shot.

Finally, before rushing to use Loop components, remember that some compliance issues remain unsolved. This is evidence that Loop components are still an unproven and immature collaboration technology, which might remain the case for several years to come.

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 happens, why it happens, and what new features and capabilities like Loop components mean for your tenant.

Cleaning Up a Mess

Delegates are users granted access rights to another user’s mailbox or to a shared mailbox. Often, delegates receive full access permission to a mailbox to allow them to process inbound and outbound emails. The classic example is of an executive assistant supporting a senior manager. The assistant is the delegate with full authority over the manager’s mailbox and might even be able to send emails on their behalf or as the manager.

Delegate access is a well-known area of functionality for Exchange and Outlook. Despite different implementations in the various Outlook clients (here’s how it works for the mobile clients), things usually work without a hitch until some complexity arises. Dealing with emails encrypted using Microsoft Purview Information Protection (MIP) sensitivity labels is an example of that kind of complexity.

The good news is that Microsoft is enabling some control to how Outlook clients allow delegates to access and work with MIP-protected messages and their attachments. Differences exist between Outlook for Windows and the other Outlook clients interact with encrypted items and the controls Microsoft is now rolling out apply only to:

• Outlook Web App.
• Outlook for Mac.
• Outlook Mobile for iOS and Android.
• Mail App for Windows.

In their June 6 post, Microsoft acknowledges that “some inconsistencies” exist across the set of Outlook clients. Here’s what’s happening.

New PowerShell Cmdlets

The control is in the form of a set of three new PowerShell cmdlets in the Exchange Online management module. These are:

• Set-MailboxIRMAccess: Block a specified delegate from accessing encrypted messages in a user or shared mailbox.
• Get-MailboxIRMAccess: Check if a block exists for a specified delegate in a user or shared mailbox.
• Remove-MailboxIRMAccess: Remove a block from a user.

Full Access and Different Outlook Clients

Delegate access to encrypted messages depends on the type of mailbox and how the delegate receives full access permission:

• Outlook for Windows clients do not support delegate access to encrypted messages sent to user mailboxes. Delegates can only read encrypted messages if the sender includes the delegate as a TO or CC recipient. In this scenario, the delegate’s ability to read the message depends on the rights granted to them as a recipient. If the rights assigned to recipients include one applicable to the delegate, they can read the content. If not, they cannot.
• Outlook for Windows clients support delegate access to encrypted messages sent to shared mailboxes if the delegate has full access and auto-mapping is specified when the delegate receives permission to the mailbox. Auto-mapping forces Outlook for Windows to open the shared mailbox as part of the resources available to the delegate. It is the default used by Exchange Online and is assigned when granting full access to a delegate for a mailbox using the Microsoft 365 admin center or Exchange admin center.
• The other Outlook clients support delegated access to encrypted messages in both user and shared mailboxes if the delegate has full access to the mailbox.

Microsoft documents some restrictions that apply to delegate access for encrypted messages.

Blocking Access

To prevent delegates with full access to a user or shared mailbox from being able to view encrypted messages using clients other than Outlook for Windows, you can block their access by running the Set-MailboxIRMAccess cmdlet. For example, this command blocks the ability of Kim Akers to read any encrypted messages delivered to the Customer Services mailbox:

Set-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com -AccessLevel Block

To make sure that a block is in place, use the Get-MailboxIRMAccess cmdlet.

Get-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com

Identity                       User                           AccessLevel
--------                       ----                           -----------
Customer Services              Kim.Akers@office365itpros.com  Block

The time required to implement the block depends from client to client. OWA imposes the block within a few minutes, while other clients might take longer. It all depends when a client checks with the server to learn that a block is in place. When a block applies, delegates see that they don’t have the necessary permissions when they attempt to access encrypted messages (Figure 1).

A block placed on delegate access remains in place until an administrator removes it and only affects the ability of a delegate to read encrypted messages using clients that support the block. For instance, the block will stop a delegate reading encrypted messages in a shared mailbox using OWA or Outlook for iOS, but they can switch to Outlook for Windows to see the message content. In addition, blocking access does not hide message subjects, which can contain sensitive information, nor does it prevent a delegate from deleting or moving encrypted messages. The block exists for reading, and only works for clients that support the block.

To remove the block and restore the ability to read encrypted messages to a delegate, run the Remove-MailboxIRMAccess cmdlet:

Remove-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com

Good Block for Confidential Information

Microsoft is addressing a real customer need with these controls. There’s no point in protecting confidential messages with sensitivity labels if an unintended recipient (a delegate) can read the content. It would be nice if all the Outlook clients worked the same way. However, that’s probably too much to hope for until the One Outlook project delivers a common client across all platforms. Given the speed that Project Monarch is moving at, that might take some time yet.

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 important and how best to protect your tenant.

Org Explorer Brings Data from Multiple Microsoft 365 Sources

Updated 28 February 2023

About 18 months ago, I wrote about the importance of maintaining user account attributes in Entra ID. At the time, my focus was on Teams, because the application exposes where someone fits in the organizational structure when viewing their details. If you use Exchange Online dynamic distribution lists, the queries used to resolve list membership also depend on accurate directory data.

Organizational information is also available in the Office 365 profile card (which now shows local time information for users to make meetings easier to arrange). And now, organizational views are coming to Outlook desktop clients.

Introducing Outlook’s Org Explorer

Announced in message center post MC315746 (last updated January 21, 2022) and in preview since February (see Microsoft 365 roadmap item 84785), a new Org Explorer tab is available in Outlook’s navigation bar in Insider builds. Microsoft originally disclosed the feature in July 2021. At that time, Microsoft said that the Org Explorer is available to users with an Microsoft 365 E3 or E5 or Microsoft 365 Business license.

Update: According to message center notification MC492902 (updated 7 February 2023), the Outlook Org Explorer is only available to users with the “Microsoft Viva Suite” or “Microsoft Viva Suite with Glint” licenses. It’s odd that Microsoft would change the license requirements in mid-course, but they can do so at any time before a feature becomes generally available, which is the case here.

Oddly enough, given that OWA usually picks up new features first, the Outlook Org Explorer isn’t yet available in OWA, or the preview build of the One Outlook (“Monarch”) client.

Choosing Org Explorer opens what feels like a web page. The content shown on the page combines organizational information, personal information (like their address), presence information, and people insights derived from the Microsoft Graph from user activity (Figure 1). The user picker at the top right-hand conner can only search for user accounts within the tenant. In this instance, the person is an individual contributor without any direct reports. However, their manager appears at the top of the screen.

The Outlook Org Explorer tells you how many people report to the person in focus. You can expand the raw count to see the full set. Navigation down through the organization works well but navigating back up a level or two doesn’t work as well, even when attempting to move from a user with a direct manager.

Exchange Online must cache the information displayed by the Org Explorer. Changes made to reporting relationships didn’t appear for several hours after the update. Caching data is reasonable because the Org Explorer shows a lot of information extracted from different sources. I’m sure a background process collects the data periodically to make it available to Outlook.

Roaming Signatures Coming Closer

Also for Outlook,. Microsoft has been working on roaming signatures for Outlook desktop clients for several years, Message Center post MC305463 (15 December 2021) announced a delay for Roaming Signatures, and Microsoft later said that the new target date is July 2022. The good news is that the latest Insider builds and the One Outlook preview both include a way to insert Outlook Web Signatures into a message (Figure 2).

Outlook web signatures are no more than the signature defined for OWA (which can also be set for a mailbox using PowerShell). The good news is that the method works, which means that you can insert OWA signatures into Outlook very easily.

The latest version of OWA (and the One Outlook preview) allow users to define multiple web signatures. In the past, OWA had just one signature, but that seems to be in the past. In addition to being able to define multiple signatures (and insert any of the signatures into a message), users can choose default signatures for new messages and replies.

This flurry of change in OWA and Outlook points to OWA mailbox-based signatures being the way forward. No doubt Microsoft will reveal all in July. It will be nice to only have to define signatures in one place and have all Outlook clients use those signatures.

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.

View Teams and Outlook Messages in Search Results

Microsoft Search and the results it delivers to users are in a state of constant flux. This is usually a good thing because it means that Microsoft is upgrading search capabilities to help users find information more effectively. Sometimes, things get out of step, and you can see extra results in one place that don’t appear in another. A little consideration usually comes up with a reason why this is so.

Take the example of the Messages vertical that Microsoft has added to Office.com. When you search from Office.com, the results include Teams and Outlook messages (Figure 1). In search parlance, the set of results exposed by the messages tab is referred as a “search vertical.” You can add custom search verticals to SharePoint search, but not to Office.com.

The Teams messages come from both chats and channel conversations. Selecting a Teams or Outlook message uses a deeplink to bring you to the source loaded in the Teams client or OWA.

Microsoft Search trims the search results so that users only see information from resources they have permission to access.

Why Messages from Deleted Teams Appear in Search Results

Sometimes search results resurrect messages from deleted groups. Take the second message listed in Figure 1, which comes from a conversation in the Project Athena group (a team). Selecting this message does nothing because it doesn’t have a deeplink to bring it to the source conversation.

Some investigation found that the team doesn’t exist anymore. I deleted the team since the conversation happened in 2018. However, the messages persist because the team came within the scope of a hold imposed by a retention policy. Microsoft Search relies on the compliance records the Microsoft 365 substrate captures for Teams chats and channel conversations, and these records remain in mailboxes until the retention period for the policy lapses. Therefore, the conversation remains available for search to find while the deeplink pointing to the source conversation is unavailable.

Microsoft Search in Bing

The interesting thing is that the ability to return messages in search results isn’t available in SharePoint search. You might expect this to happen because it’s a search for Microsoft 365 data. However, it’s a search of SharePoint resources, so the results only cover the information available to SharePoint Online and OneDrive for Business. Personally, I think Search should deliver the same results in SharePoint Search as it does in Office.com, even if SharePoint Online doesn’t manage the items found. The lines between applications continue to blur and it seems strange to have artificial barriers where they’re not needed.

Where messages do turn up is in search results from Bing.com if you configure Microsoft search in Bing through the Search & Intelligence section of Org settings in the Microsoft 365 admin center. In effect, when you do this, you connect Microsoft 365 content to Bing to expose “work” results alongside results for internet sources. Accessing the work tab exposes results from different Microsoft 365 sources, including messages (Figure 2).

This capability has been available for at least six months. At least, we updated the coverage about Microsoft Search in the Office 365 for IT Pros eBook about six months ago to report its availability!

Loop Components in Search Results

While looking at the various results now available through Microsoft Search, I noticed that Loop components show up. I probably missed this in the past but felt that it’s worth noting that even though Loop components pose some eDiscovery challenges, the information in the components is fully indexed and discoverable as evident in the first two search results shown in Figure 3.

There’s nothing surprising here because the Loop components in Teams chats (and soon in OWA messages) exist as files in OneDrive for Business.

Nice to See Messages in Search

Given the amount of data people now store in the cloud, effective search facilities are increasingly important. Adding the new search vertical for messages to Office.com is very useful. It’s just a pity that the same capabilities aren’t available elsewhere.

And Microsoft Issues Block to Stop People Using Leaked Client

Update: Microsoft has now released a public preview of the Monarch client. You can download the preview if you are a member of the Office Insiders program. See this post for details. The preview version is not very different to the leaked software.

A leaked build of Microsoft’s “One Outlook” client emerged last week. It wasn’t very exciting because it’s what Microsoft described during sessions at the Ignite conference in September 2020. “Project Monarch” is making progress, but it’s not the kind of fundamental breakthrough redevelopment of Microsoft’s venerable email client that some anticipated.

What leaked is a version of the Outlook Web App (OWA) client currently available to Exchange Online users. The client is complete with links in the navigation bar to invoke Yammer and Bookings, and icons to start a Teams chat or fast access to To Do tasks (Figure 1).

Support for shared mailboxes, Microsoft 365 Groups, sensitivity labels, and calendar board views is included, as is full support for Microsoft Editor, tab completion of phrases (with some interesting hiccups), and so on. I was even able to open a public folder. One thing that’s missing is Loop components, which Microsoft plans (MC370366) for both OWA and Outlook for Windows this month.

The Project Monarch client is packaged as a Progressive Web App (PWA) with limited offline capabilities (some calendar and email information is available, but not item contents). You can sign into the client with an Azure AD account, but not a consumer Microsoft Services account.

Prettier OWA

In a nutshell, this Project Monarch build is a slightly prettier version of OWA. When it’s feature-complete, it’s easy to see how Microsoft will slip this client in to replace:

• OWA in Exchange Online (Office 365).
• OWA in Outlook.com.
• The basic Mail app in Windows 11.

Of course, each version of the client will have different capabilities, but they’ll all use the same basic framework, and that’s the important point.

Core Technologies

Three core technologies form the One Outlook framework (see this Ignite 2020 video):

• OPX – OWA Powered Experiences (Figure 2): a method to allow other clients to consume features developed for OWA. A good example is how Outlook for Windows uses the OWA Room Finder. OPX depends on the WebView2 component, developed by the Edge team. WebView2 is also key to the Teams 2.0 client architecture.
• Microsoft Sync Technology: the synchronization protocol currently used by the Outlook mobile (iOS and Android) and the Outlook for Mac clients to interact with Exchange Online. The word is that Outlook for Windows will eventually move away from MAPI over HTTP to use this protocol.
• Augmentation Loop: a way to coordinate the services and data consumed by Outlook clients. Instead of Outlook building separate interfaces to plug new services into clients, they plug into the augmentation loop.

Synchronize My Mailbox

Offline working is the big gap that Microsoft must plug before replacing the Outlook desktop client is possible. For the last twenty years, Outlook has been able to synchronize a user’s entire mailbox using network smarts like drizzle-mode synchronization and priority threads. A replacement for Outlook desktop must be capable of sophisticated offline working, meaning that the client needs to be able to do more than basic send and receive of email. There’s no evidence of progress toward this goal in the leaked PWA.

Blocking the Leak

In response to the leak, Microsoft released MC376710 late on May 6 to say that “some users can access an unsupported early test version of the new Outlook for Windows.” The announcement appealed for customers to wait until Microsoft releases an official beta, promising more news about the beta “in the coming weeks.”

Microsoft also gave instructions about how to block mailboxes from synchronizing with the new Outlook. To do this, connect to Exchange Online with PowerShell and run the Set-CasMailbox cmdlet to block access, just like you’d block a mailbox from accessing a protocol like IMAP4 or Exchange ActiveSync.

Set-CasMailbox -Identity Kim.Akers -OneWinNativeOutlookEnabled $False

When the block is in place, the new client fails to connect to the user mailbox and issues the error shown in Figure 3.

Microsoft suggests that organizations use the block to prevent people from using the new client until the official beta is ready. In other words, they’d like you to run some code like this:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-CasMailbox -OneWinNativeOutlookEnabled $False

And when Microsoft releases the official beta, you can reverse the block with:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-CasMailbox -OneWinNativeOutlookEnabled $True

The Slow Pace of Development

After all the excitement dies down, we’re left with the conclusion that Project Monarch is moving ahead, albeit slowly. We see the tip of the iceberg in the leaked client. Underneath, I’m sure that Microsoft is working through a bunch of software engineering challenges to create the foundation for a single base that can support multiple variations of Outlook clients. We await the news of the official beta as promised by Microsoft.

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 happens, why it happens, and what new features and capabilities mean for your tenant.

Just in Time for Outlook

Updated: March 22, 2023

Microsoft Loop components have been available in Teams chat since November 2021. I haven’t heard about widespread usage, but that might be because people need time to adjust their collaboration habits. Access to Loop components in other applications is also a gating factor, but availability in OWA and Outlook for Windows (current channel preview) should help to address this concern. According to MC360766 (April 18, Microsoft 365 roadmap item 93234), Microsoft will roll out this feature to tenants configured for targeted release in early May.

Update: It took a little longer than predicted, but Loop components are now available in OWA.

So far, there’s no sign of Loop components in Outlook desktop, but I’m sure the components will arrive in my email any day now to deliver the same kind of functionality as available in Teams chat (Figure 1). In a nutshell, if an email contains a loop component, it exists as a file in the sender’s OneDrive for Business account that is shared with the email’s recipients. We’ll report more when the software is available.

IsLoopEnabled

This brings me to MC371268 (May 2), where Microsoft announces that “in response to customer feedback,” they’re retiring the existing settings to control the availability of Loop components and introducing a new control called IsLoopEnabled.

The control is part of the SharePoint Online tenant configuration and is set using the Set-SPOTenant cmdlet. You’ll need to upgrade the SharePoint Online management module to version 16.0.22413.12000 or later. Microsoft posted this version in the PowerShell Gallery five days ago. You can install or update the module from the PowerShell gallery or download an MSI file from Microsoft.

The replaced control is IsFluidEnabled, which enables the Fluid Framework within a tenant. Microsoft plans to retire the IsFluidEnabled setting on November 25, 2022. Going forward, the relevant settings in the SharePoint Online configuration are:

• IsLoopEnabled: Controls if Teams can use Loop components. The default is True (Enabled).
• IsCollabMeetingNotesFluidEnabled: Controls if fluid components are available in OneNote collaborate meeting notes.

Update: Following the availability of the preview version of the Loop app, the control for the Loop app, Outlook, Whiteboard, and the Office Online apps is via settings in the Cloud policy.

eDiscovery and Compliance Issues

Although eDiscovery searches can find Loop component files stored in OneDrive for Business, Microsoft acknowledges “limited eDiscovery workflow support.” With the additional of Loop support in Outlook, this aspect might become more problematic. For example, today, the preview feature for search results can render the full content of emails. This isn’t possible when an email contains a loop component because the preview window needs a software upgrade to fetch the content from OneDrive and display it inline within a message.

Another issue is with exports of search results. Today, Microsoft Purview can export emails (and the compliance records captured for Teams chats) found by searches as individual message files or in PST files. Microsoft says that the export format is “not consumable by existing tools,” and that they’re working on “an offline consumable export format.” Taken together, these statements make me think that the exported emails contain references (links) to OneDrive files that aren’t accessible to investigators working offline or independent experts who review eDiscovery results without access to the source tenant.

Making the content of search results available offline probably involves replacing the embedded link in messages containing Loop components with a static version of the content extracted from OneDrive.

This topic deserves a more comprehensive test, which I will get to once Outlook support for Loop components is available. In the meantime, organizations that don’t want to run into potential eDiscovery problems should strongly consider disabling Loop components for both Teams and Outlook by setting the IsLoopEnabled control to False.

Set-SPOTenant -IsLoopEnabled $False

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Recipient Moderation Works for All Mail-Enabled Objects

A discussion about moderated distribution lists was a throwback to the past. You hardly hear much about recipient moderation these days, but it was a big thing when Microsoft added it to Exchange 2010. Moderation works for both on-premises and cloud recipients, and it works in hybrid deployments too (there’s a good write-up about troubleshooting moderation on the EHLO blog).

Moderation works for all kinds of mail-enabled objects: mailboxes, dynamic and normal distribution lists, mail users and contacts, public folders, and Microsoft 365 groups. It’s a good feature to use to protect sensitive recipients from receiving emails from all and sundry.

A typical deployment scenario is to moderate messages sent to senior executives by forcing a review by an executive assistant before Exchange can deliver the messages to the target mailboxes. Moderation supports bypassing, meaning that you can define sets of users or distribution lists whose messages are not subject to checks. When an email comes from bypass senders, Exchange delivers it directly.

Moderation in Action

When moderation happens, an arbitration mailbox sends details of the email to the designated reviewers (moderators), who can approve or reject the message (Figure 1).

The response goes back to the arbitration mailbox, which releases the message for final delivery if the response is positive. If the response is negative, the arbitration mailbox returns the email to the original sender with a note to tell them that a moderator rejected its delivery. If a moderator doesn’t process the message within two days, it’s returned to the original sender to tell them that moderation didn’t happen.

Moderators have full access to messages awaiting approval, even if sensitivity labels encrypt message content and they wouldn’t normally have the right to read it. Because it needs to be able to check messages as they pass through the transport pipeline, the Exchange transport service has super-user access to all encrypted content. The transport service can decrypt the protected message when it sends the copy for approval, which is how the moderator can review the email.

You can even have a situation where a moderator reads a message, approves it for delivery, and the final recipient can’t read the email because the sensitivity label doesn’t grant them the right to access it. This underlines the point that senders should always know what rights a sensitivity label applied to email grants to recipients.

The Problem with Outlook

Coming back to the problem under discussion, the query was about why OWA can expand the membership of a moderated distribution list and Outlook for Windows cannot. On the surface, there’s no good reason why this should be so. Unlike a dynamic distribution list whose membership depends on directory attributes, the membership of a moderated distribution list is static and known. Even the Outlook address book agrees and is perfectly willing to display a list’s members (Figure 2).

When a user asks OWA to expand the membership of a moderated distribution list, it’s happy to do so (Figure 3).

But Outlook refuses point-blank, even if the plus sign appears to show that the client supports the expansion of a distribution list (Figure 4). Normally, if you click the plus sign, Outlook warns that if you expand the list, Outlook replaces the distribution list with the individual addresses of its members. Once this happens, you can’t collapse the individual members back to the list. I don’t know what Outlook means by a moderated public group either (as noted in the comments, this turns out to be a Microsoft 365 group…)

For the record, Outlook mobile avoids the issue by not offering the option to expand the membership for any distribution list.

One Outlook

Inconsistencies like this in client families madden users. In this case, it’s probably a small issue that affects very few users and an obvious and viable workaround exists, all of which means that Microsoft is unlikely to fix whatever is causing Outlook to fail to deal with moderated distribution lists. Maybe the fabled Project Monarch (aka “One Outlook”) app, apparently due to enter public preview soon, will address the inconsistency. But I wouldn’t hold your breath!

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.

A Complex Software Engineering Problem

First announced in May 2020, Microsoft’s efforts to deliver Outlook roaming signatures in the click-to-run version of Outlook desktop (part of Microsoft 365 apps for enterprise) have stalled several times since. The latest information in Microsoft 365 roadmap item 60371 points to preview in September 2022 and general availability in October 2022. Given Microsoft’s record with this feature so far, few would bet that they will achieve this date.

As I explained in my original May 2020 post, the current implementation of Outlook signatures in the desktop client makes them more difficult to manipulate than the OWA equivalent, which require a simple update using the Set-MailboxMessageConfiguration cmdlet.

You’d hope that Microsoft has come up with a simpler and more elegant implementation for Outlook roaming signatures, but that’s no reason why it is taking Microsoft so long to deliver a solution to a problem that many other companies have solved, especially with their access to internal structures of Exchange Online and Outlook. According to Microsoft 365 message center notification MC305463 (December 15, now unavailable in the message center), the delay is due to the need for “further stabilization.”

Cynics might note that Microsoft finishes its FY22 fiscal year on June 30, and engineering management will be keen to ship features before that milestone. We may yet see at least a public preview of Outlook roaming signatures soon.

Signature Settings in Mailboxes

The roadmap item promises that Outlook will store signature information in the cloud, likely meaning that Outlook will retrieve signatures from a hidden folder in the Non-IPM section of Exchange Online mailboxes. Users who choose not to store signatures in the cloud will continue using the system registry to store signatures. Outlook 2016 and Outlook 2019 perpetual license clients will also use the system registry.

There’s no indication that Microsoft will bring roaming signatures to Exchange on-premises servers. Then again, Microsoft has gone dumb about the future of Exchange Server recently, with no news about when the successor to Exchange 2019 will appear.

The ISV Approach

Although customers are exasperated at the lack of Microsoft’s progress in delivering roaming signatures, I’m sure that ISVs like Code Two Software, Exclaimer, and Crossware are happy to have had two extra years to hone their signature management software to compete with Outlook roaming signatures. In 2020, Microsoft said that third-party add-ins will have to disable the Outlook feature to continue to work. They also committed to deliver an API to allow add-ins to work with roaming signatures. No details of the API are yet available, but given Microsoft’s focus on the Graph, it’s likely it will be a Graph API. Whether the API appears at the same time as roaming signatures or afterwards is another question.

On another front, signature management ISVs are leveraging the Outlook Signatures add-in API to integrate their products with Outlook desktop. First announced at Ignite 2020 and subsequently followed by a set of product releases from ISVs, the Outlook API is different to the one promised by the developers of roaming signatures and leverages the Outlook add-in model developed by the Office extensibility team. It’s a classic example of two solutions for the same problem coming from different Microsoft development groups.

I don’t think that Microsoft’s implementation of roaming signatures will materially affect ISV signature management products. After many years of development, these products are very sophisticated and tailored to meet the needs of enterprises who want common signatures used by all employees. Those who want an out of the box solution can have it today without waiting for roaming signatures by implementing signatures through transport rules. This approach works, it’s free, but it’s crude in comparison to what’s available in ISV products.

Confusing Outlook Signatures

As things stand, multiple different signature mechanisms exist for Outlook clients (OWA, Outlook for Windows, Outlook for Mac, Outlook mobile). This situation is due to the historical differences in client architectures and is confusing and cumbersome. Perhaps roaming signatures will be the first step on the road to a common signature used across all clients. Delivering such a capability might justify some of the two-year delay, but don’t hold your breath.

Make sure that you’re not surprised about changes which appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Privacy and Protection Might Not be Enough

MVP Ingo Gegenwarth’s post about Outlook and private items is a good example of the problems which arise when user assumptions running into software limitations. The assumption is that if you mark an item as private, only you can see its contents. The limitation is that it depends on clients containing code to respect private items. Some do, and some don’t, much to the chagrin of users when they find out.

Delegate Access to Protected Email

Similar confusion exists around protected email which arrives in a user mailbox and is read by a delegate. Email protected by a sensitivity label uses rights management to know what a user can do with the content. If they don’t have the right to view the encrypted content, the mail client shouldn’t open the message. But if someone has delegate access to a user or shared mailbox, they might be able to read protected messages. It all depends on the client used and the rights assigned in the sensitivity label.

For instance, here’s an example where a protected message arrives in a mailbox. The delegate (full mailbox access) can read the protected message with OWA (left), but not with Outlook desktop (right). They can also read the message with Outlook mobile if they add their delegate account there.

Change Coming for Some Outlook Clients

In their FAQ for protected email, Microsoft says:

“Is delegated access supported with opening encrypted messages? Even if a delegate has full access to another user’s mailbox?

Delegated access of encrypted mail is supported in Outlook on the web, Outlook for Mac, Outlook for iOS, and Outlook for Android. Outlook for Windows does not support delegated access.”

A change described in Microsoft 365 roadmap item 88888 appears as if it will help. The item says:

“Outlook will provide consistent access control on protected emails for delegates and shared mailbox members. For delegates or shared mailbox members, when they have full access of the owner’s mailbox but are not allowed to read encrypted email, Outlook will have a new setting to block the owner’s protected email access which covers ad-hoc encrypted email as well as email with protected MIP sensitivity labels.”

According to the roadmap, we will see this change in April 2022. However, it only applies to OWA, Mac, iOS, and Android. Outlook for Windows remains an outlier. And that’s the problem because Outlook for Windows is often the client of choice for administrative assistants who process email on behalf of others.

Protecting Confidentiality

Is there anything that can be done in the situation where the organization uses sensitivity labels to protect confidential email and documents and want to be sure that delegates cannot access this material? Well, you could remove OWA and Outlook Mobile access from delegate accounts to force them to use Outlook desktop, but that’s probably not realistic.

Instead, an old technique from on-premises Exchange might be useful. For executives who need the assurance that delegates cannot access protected email, you could create two accounts with mailboxes. Let’s take the example of the CEO. They would have:

• A primary mailbox accessed by the delegate to manage inbound email and the calendar. The mailbox appears in the GAL and is accessible to anyone in the organization (or maybe not, as the case demands).
• A hidden mailbox which only the owner can access. This mailbox is not listed in the GAL and is limited so that only certain people can send email to it. This mailbox is used for protected or other confidential email, so the rights assigned in sensitivity labels grant access to the hidden mailbox instead of the primary mailbox.

A certain amount of configuration to make sure that the two accounts work as planned. However, if protected email is sent to the hidden mailbox and only the owner of that mailbox accesses the email, there’s no chance that the delegate can see confidential material.

Yes, this is a pain. Delegate access to protected email should work better with Outlook for Windows. Let’s hope that Microsoft moves on this point soon. Perhaps it’ll be an example of their One Outlook strategy of bringing OWA features to Outlook desktop.

Search in Outlook Has Never Been Great

On January 11, MC313286 brought the news that Outlook searches might return no result if messages are stored in PST and OST files. I’ve zero sympathy for those who store email in PST files, but the loss of search in OST files handicaps offline operation for those of us who keep email in Exchange Online mailboxes. I realize that some persist in using POP3 and IMAP4 to access mailboxes (hopefully, the loss of basic authentication in October 2022 will stop this), but it’s time to move on use more modern messaging protocols.

In any case, the problem affects people who upgrade PCs to Windows 11 because the upgrade removes the search index. Over time, Windows rebuilds the search index, and all is well. At least, it’s as well as Outlook searches ever are. Over the years, my expectation that Outlook delivers reliable search results has never been high, so my level of disappointment is never severe. To be fair, searches performed by latest version of Outlook desktop (click to run) are better than before, but force of habit makes me depend on OWA when I need to search for something.

New Search Capabilities Include Outlook and Teams

Behind the scenes, Microsoft Search powers the search facilities in Outlook and OWA. Microsoft Search indexes and can search the Microsoft 365 substrate, meaning that it can find documents, email, tasks, and the compliance items for Teams, Planner, and Yammer. Recently, Microsoft upgraded the search UI in Office.com and SharePoint Online to add a “Conversations” tab to search results. This tab reveals Teams and Exchange Online messages (Figure 1) while other tabs deal with news, people, sites, files, and so on. The change is documented in MC299210 (last updated December 8) and Microsoft 365 roadmap item 68779.

If you select an item, a deeplink takes you to the original message in the underlying workload. For example, if you find a Teams message you want to see, the deeplink offers to open the Teams browser client but will open the item in the desktop client if that client is available. Outlook items open in OWA.

According to the roadmap item, the new search became generally available in January 2022. It should therefore be available in all tenants now.

Microsoft 365 Search in Bing Now Covers Outlook

The roadmap item refers to Bing.com too, which covers the scenario when Microsoft 365 results are integrated with results from Bing searches. It’s long been possible to see Teams and Yammer messages in Bing results. Now Outlook messages are included (Figure 2). As in other features powered by Microsoft Search, filters make sure that the person performing the search only sees the information they can access. This means that a search covers the user’s own mailbox but won’t reveal items in shared mailboxes or other user mailboxes they have delegate access to.

The presentation of Outlook content differs in Bing. In the past, Bing had a Conversations tab covering Teams messages and Yammer. Now, Teams and Outlook show up under Messages and Yammer is moved out to its own tab. I’ve heard speculation that this is because Yammer messages are slower to index. Curiously, the search results available in neither SharePoint Online nor Office.com include Yammer content, so perhaps Microsoft is doing some work to integrate Yammer better.

Integrated View is Best

The obvious advantage of using Office.com or SharePoint Online for searching is access to integrated results. OWA delivers good results for Outlook messages. However, given that we live in a world where communications aren’t restricted to email, the integrated search across SharePoint, OneDrive, Teams, and Outlook is very attractive. It’s now my favorite way to look for Microsoft 365 content.

Make sure that you’re not surprised about changes which appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

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.

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.

Previous Moca Boards Still Available

The July 20 announcement (MC271629) to move Project Moca boards to the OWA calendar board view was not a surprise. Given the dates on Microsoft 365 roadmap item 80213, it seems like Microsoft made the decision in May, soon after rolling out the calendar board view to OWA, which at the time we pointed out seemed like a Moca board (or space, for Moca was also referred to as “Outlook spaces”) tailored for the calendar.

Moca’s Lack of Identity

It’s a sensible call, I don’t think Moca got much traction with customers after Microsoft introduced it as a preview feature in October 2020. A separate component within OWA must have its own identity to stand alongside mail, calendar, people, and tasks. Moca delivered boards onto which people could post a collection of different bits of data, but that’s hardly the same as a fully developed OWA component. I used Moca for a couple of months and then gave up, not least because no mobile client exposed Moca boards (I found a workaround using the To Do mobile client, but it was never satisfactory).

In any case, all the Moca boards created using the preview are now safe and sound and available through the calendar (Figure 1). Everything seems intact, even if some objects appeared to have moved on the board (this could be just me).

The Project Moca icon is still present in OWA’s left-hand navigation rail and opens the Moca page, but I bet this will disappear soon.

Outlook Desktop

For now, only OWA supports the board view. The thought going through my mind is whether Microsoft will use the OCX/WebView2 technology to bring the board view to Outlook desktop as part of their One Outlook initiative, just like they recently did for the Room Finder. It would be logical if they did this to bring boards to Outlook, especially now that the WebView2 runtime component is included with Microsoft 365 apps for enterprise updates. Time will tell.

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.

A Banner Notification Difficult to Ignore?

I’m unsure what to make of the news in MC264090 (updated July 1) telling us that Outlook (and OWA) users on Windows 10 will soon see a clickable recommendation to install the Outlook in Edge extension (currently in preview). The recommendation will appear in “any Windows browser” (if using OWA) or in Outlook desktop (presumably Outlook click to run rather than Outlook perpetual). The recommendation is dismissible but annoying and can appear a maximum of three times “in each app” before it is “suppressed permanently.” Those who use both OWA and Outlook can therefore see the banner six times, which is something to look forward to.

If you succumb and install the extension, an Outlook icon appears in the Edge menu bar (Figure 1). It has access to the site because the user grants consent to access their mailbox.

Bringing the Power of Outlook to an Edge Icon

According to Microsoft 365 roadmap item 82036, “The Microsoft Outlook browser extension brings you the power of mail, calendar, contacts, and tasks using an icon in Microsoft Edge. Quickly access your Outlook work account or your Outlook.com or Hotmail account without switching to another tab or app. The extension will be available in the Chrome Store soon as well.”

Apart from anything else, the roadmap item tells us that the Outlook extension will also be available for Chrome users, presumably again on Windows 10 (and likely Windows 11, since that appears to be Windows 10 with a new skin).

The reason why I am conflicted is that I don’t see the point in the extension. If I want to use OWA (and I do), I open a tab in the browser for OWA and keep that tab open. I can then do whatever I want with email, tasks, contacts, and the calendar. It’s like using the “peeks” available in Outlook desktop to get an insight into data. Being able to overlay the calendar when processing email (Figure 2) is mildly interesting and enough to convince me to keep the extension, but it’s not something I use heavily.

Apart from the calendar, the extension can peek into your mailbox, tasks (including any To Do list), and contacts. Within the mailbox, you can select any folder, but you cannot select another mailbox, including your archive mailbox. The extension allows you to select different calendars to view. However, this part doesn’t work so well in the preview and was inclined to freeze. You can also access a limited selection of OWA settings. For instance, you can set an auto-reply message. And if you want access to the full functionality of a section of OWA, the extension can open into a tab. Just about the only thing which is missing is Project Moca.

Blocking the Clickable Recommendations

Although the Outlook extension doesn’t float my boat, I can see how it will work for others. The real question for tenant administrators is if they want to block the display of the recommendation banner by using the Office Cloud Policy Service (OCPS) to set “Recommend the Microsoft Outlook Extension” policy to ‘Disabled’ (Figure 3). OCPS settings affect both OWA and Outlook for Windows.

According to MC264090, a future update to Group Policy templates will support the block too in Outlook by setting the RecommendOutlookExtension system registry (DWORD) value at HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\outlook\options to 0 (disabled).

Good for Some

Targeted release is due in July and tenants need to act before July 30, 2021, if they don’t want users to see the clickable banners. Before deciding, try the extension yourself to see if you think people will find value in its use. If not, go ahead and block. If you do, let people see the banners and install the extension if they wish.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

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?

That is, if Meeting Attendees Cooperate…

Research commissioned by Microsoft says that your brain needs breaks when working over sustained periods and points to back-to-back video meetings as a problem. The article goes on to point to new calendar settings in Outlook (Windows and OWA for now, the other platforms are coming) to help users to shorten Outlook meetings to create breaks when they schedule events. The idea is that these breaks give users the opportunity to decompress a little before plunging into the maelstrom of their next meeting. It’s a nice idea, but one that can only work if everyone attending meetings cooperates to begin and end meetings on time, which is something that human beings fail to do.

Making Outlook Shorten Meetings

Outlook has been able to suggest shortened meeting durations for two years (here’s an article by MVP Brian Reid from 2019), with the idea being that people could gain some time back in their day by scheduling 30-minute meetings for 25 minutes and hour-long gatherings for 50 minutes (or whatever you choose). What’s different now is:

• An organization-wide default setting is available to complement the client-side settings. The change is described in message center notification MC251866 published on 21 April and Microsoft 365 roadmap item 72215.
• People can choose to shorten meetings at the start or end of a period by starting late or ending early.
• The organization defaults or user-selected settings apply to the full range of Outlook clients for Microsoft 365 (after Microsoft upgrades the software). Perpetual clients like Outlook 2019 don’t respect the settings.

For instance, I used version 2104 of Outlook for Windows (the option should be in version 2102 or later of Microsoft 365 apps for enterprise) to choose my preferred options (Figure 1).

On the basis that people always turn up late to my meetings, I choose to create a time barrier to my next meeting by ending early. The corporate culture in your organization might be different, but I hazard a guess that most meetings can focus on finishing by a defined meeting end time where they might struggle to begin on time. Of course, the period allotted to a meeting and the actual time consumed by the meeting can be two very different values. The behavior of people in a meeting might be affected by a shortened time, but when business or personal needs dictate, people will continue until they achieve the purpose of the meeting.

The periods available to shorten meetings of less than one hour are 5, 8, and 10 minutes, while for meetings of one hour or longer they are 5, 10, and 15 minutes. As we’ll see, more granularity is available when setting organization defaults with PowerShell. Figure 2 shows how to configure the event shortening settings in OWA. It’s interesting that Outlook desktop refers to meetings and appointments while OWA refers to generic “events.”

Shortening a Meeting

My calendar settings call for a default meeting duration of 30 minutes. After selecting my event shortening options, new meetings start off with a 25-minute duration set (Figure 3). If the default meeting duration is an hour or longer, Outlook shortens it by 10 minutes.

The new setting does not affect any meeting already in the calendar. And of course, because the owner has full control over an event, I can select other durations for the meeting as I like. The shortening feature is an advisory guide rather than a mandatory restriction.

When scheduling a meeting with OWA, users might see a MailTip saying: “Your organization shortens events by default.” This only applies when the user has not configured event shortening and an organization policy is active (see below). Microsoft says that the same MailTip will be visible in other Outlook clients in the future.

Shortening Teams Meetings

Given the multitude of Teams meetings occurring today, effective event shortening must apply to these events. Neither Teams calendar app nor the Teams channel calendar app respect organization-wide or personal event shortening settings at present. Events created by Outlook synchronize with the Teams calendar app, so Teams meetings created through Outlook will pick up the shortened times. According to Microsoft, an update is coming for the Teams calendar app to respect the shortening settings.

Configuring Shortening Events Settings with PowerShell

While users can decide on their personal event shortening settings and set these values through Outlook or OWA, organizations might want to apply default settings. This is done by updating the Exchange Online organization configuration with PowerShell. It’s critical to understand that once a user selects their own settings, the organization defaults do not apply to them.

Three organization-wide settings are available to control event shortening:

• ShortenEventScopeDefault: Sets whether event shortening is in effect (0 or none) or applies to ending meetings early (1 or EndEarly) or starting later (2 or StartLate). This parameter must be set to 1 or 2 before you can amend the periods.
• DefaultMinutesToReduceShortEventsBy: The number of minutes to shorten events by if they are scheduled for one hour or less. The default is five.
• DefaultMinutesToReduceLongEventsBy: The number of minutes to shorten events by if they are scheduled for over one hour. The default is 10.

To turn on event shortening for the organization using my preferred end early option, run:

Set-OrganizationConfig -ShortenEventScopeDefault EndEarly

Using Get-OrganizationConfig to examine the settings afterwards shows the current configuration:

Get-OrganizationConfig | fl defaultmin*, short*

DefaultMinutesToReduceShortEventsBy : 5
DefaultMinutesToReduceLongEventsBy  : 10
ShortenEventScopeDefault            : EndEarly

Like any organization-wide setting, some time is necessary to allow clients and servers to pick up new values (it can take up to 24 hours for the setting to reach all the mailbox servers used by a tenant). For now, there’s no way for administrators to use PowerShell to update settings for individual mailboxes as Microsoft hasn’t upgraded the Set-MailboxCalendarConfiguration cmdlet.

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.

Edge WebView2 Enables Reusable OWA Features

Last October, I wrote about Microsoft’s One Outlook vision, essentially a plan to rationalize the many forms of Outlook around a more rational approach to development. The Edge WebView2 control is a big part of the plan because it enables Outlook desktop to consume web-based features developed for OWA. That’s why Microsoft now distributes the WebView2 control with Microsoft 365 apps for enterprise (desktop Office click to run).

Room Finder Now Used in Outlook Desktop

In the article, I mentioned OWA’s revamped room finder (to locate a conference room for an in-person meeting – something we all hope will resume soon) as an example of the functionality which would turn up in Outlook desktop. With version 2103 (the current channel preview), Outlook desktop now uses OWA’s room finder. Figure 1 shows the room finder in OWA while Figure 2 shows it in Outlook desktop.

As you can see, it’s the same component, and sometimes when Outlook first loads the component, you see the OWA sign-in screen.

Looks Like a Win-Win Approach

The advantages of this approach to Microsoft are obvious: they can write a component once, deploy it in OWA to shake down any bugs, and then reuse the component in Outlook desktop. Apart from saving engineering effort to create code for multiple clients, it reduces the cost of ongoing sustaining engineering.

It’s good for customers too. Apart from experiencing the same feature behavior across the Outlook family, new features should appear faster. The Outlook desktop user interface as always been much slower to evolve than its web counterpart, largely because of the legacy of almost twenty-five years of development. With the new model, Outlook desktop can refresh its capabilities more rapidly. Of course, the proof will be seen as Outlook evolves, but at least the process is now moving.

Use Share to Teams to post a Conversation from Outlook to Teams

Message center notification MC238648 published on February 9 said that Microsoft would update the Share to Teams feature. The update dutifully appeared on schedule during the last week of March. This feature is covered by Microsoft 365 roadmap items 71265, 70598, and 68909 because it is available in Outlook for Windows (Microsoft 365 apps for enterprise – March monthly channel), OWA, and Outlook for Mac (preview). The feature is not yet available for Outlook mobile.

The idea behind Share to Teams is simple. People receive a lot of email that they would like to discuss with colleagues. They could conduct the discussion in email with the known downsides of interminable series of to-and-fro replies, not all of which might be circulated to the same people. Taking the discussion to Teams keeps focus and makes sure that everyone sees the discussion developing and can contribute as needed.

Share to Teams Target Destinations

Launched in 2020, Share to Teams uses the same email connector infrastructure used to support the ability to send email to a channel. This is a connector which uses cloud-only mailboxes to accept inbound email addressed to channels and deliver them to Teams. In the case of Share to Teams, the addressee can be:

• A person (the message is delivered to a personal chat). The sender must be able to send a message to the person (information barrier policies can block people communicating via chat).
• A group chat: If you share a message from Outlook to multiple users, Teams delivers the message to the group chat involving those users (if one exists) or otherwise creates a new group chat.
• Any channel that the sender can access, including private channels. You cannot share to multiple channels at one time.

In all cases, messages can be sent with attachments.

Figure 1 shows a typical example. In this instance, we’re sharing a message from Outlook to a Teams channel.

Figure 2 shows what the shared message looks like in Teams. As you can see, it looks like any other base note for a conversation. Replies can be posted as normal. The only jarring note is that Teams does not highlight the subject of the conversation to make the topic stand out better in a list of topics.

You must be signed into your home tenant to be able to post messages to Teams. If you’re signed in as a guest to another tenant, Teams will tell you that you need to switch before it can post.

Capturing Message Copies in SharePoint Online and OneDrive for Business

Apart from messages delivered to target destinations, like email sent to channels, a copy of the shared message (including attachments) is captured in the Email Messages folder in the channel folder in the document library of the SharePoint Online team site. This is the way that the email connector used to behave until February 2021. Now, messages sent to a channel go into a folder named for the month, like EmailMessages_4_2021 for messages sent in April 2021. The change in target folder annoyed many people because it broke some Flows, and inconsistency like this drives people up the wall across Teams is maddening.

Copies of messages shared with individuals or group chats are in the Microsoft Teams Chat Files folder of the sender’s OneDrive for Business account.

No Protected Email

You can’t select the Share to Teams option for messages protected with sensitivity labels, the standard Outlook Encrypt-Only or Do Not Forward options, or S/MIME. This is because the connector cannot remove the encryption which protects these messages.

What’s Changed

When you share an Outlook message to Teams, the add-in checks for the presence of the Teams desktop client. If it’s available, the add-in uses single sign-on (SSO) to launch a new window in the Teams client to compose the message details for sharing. This is the major difference between the old method and the new. Creating a window in an already connected Teams client is faster and creates less overhead than the alternative, which is for Outlook to do the work to connect to Teams and send the message.

Admin Control

Microsoft says that Share to Teams is controllable “by selectively enabling or disabling this add-in for individual users via PowerShell Cmdlet. Admin documentation will be published soon.” Although Microsoft is promising that a cmdlet will be available, I’m not sure if many tenants will want to disable Share to Teams. It’s not a function that I used often, but I am grateful that it’s there when I need it. I suspect most other organizations will be in the same category.

This refresh won’t make much difference to users. It’s a improvement in software engineering that will bypass most, but that’s not a reason to ignore the development and update a paragraph in the Office 365 for IT Pros eBook. It’s what we do.

Relax. It’s an Outlook Component

Microsoft published message center notification MC242585 (Microsoft 365 roadmap item 70699) on March 3 to bring the news that devices running the Microsoft 365 apps for enterprise (aka Office click to run) will get the Edge WebView2 runtime along with version 2101 (or later). I’m running version 2102 (Current channel -preview) and never noticed the arrival of WebView2. Those in the current channel not using the preview should see the change in April, unless your Office 365 tenant is hosted in a sovereign cloud or GCC (including High and DoD) where this action won’t happen.

Only Windows PCs are affected and only those which have Microsoft 365 apps for enterprise. Other devices can get the runtime by installing the Edge browser. Edge is a nice browser, even if its sleeping tabs sometimes cause disruption for SharePoint, and I have nearly broken my Chrome habit to use Edge exclusively.

Getting back to the point, installing the WebView2 runtime is like installing the Visual C++ 2008 redistributable, a much beloved inclusion in Windows updates. It’s a non-event.

No Cunning Plan

People became upset when they read the announcement and wondered if this was another cunning plan from Microsoft to force everyone to use Edge. It’s not. Edge isn’t installed and your choice of default browser remains intact. Instead, it’s using the Office distribution channel as a convenient way to make sure that the WebView2 component is available on PCs.

WebView2 is a critical part of OWA Powered Experiences (OPX). In a nutshell, Microsoft wants to be able to write software once and use it in multiple Outlook clients. New features like the Room Finder and Meeting Insights built for OWA use WebView2 as a rending engine, and the presence of the WebView2 runtime allows Outlook desktop to use the features without any changes (Figure 1). If WebView2 isn’t available, the features can’t work. Microsoft benefits by writing a feature once for multiple clients. Users benefit because clients behave the same way and features arrive faster.

Administrative Control for Edge WebView2

There’s no reason that I can think of not to allow Edge WebView2 runtime to be installed, but you can block it through the Customization section of the Apps Admin Center. Go to Device Configuration, then Modern Apps settings, and disable the automatic installation (Figure 2).

For more information, read Microsoft’s instructions.

Delegate Access to Calendars is Popular Exchange Feature

Delegate access to a mailbox is a popular feature supported by Outlook desktop, OWA, and Outlook Mobile. In some cases, you only want to allow access to a specific folder rather than the complete mailbox. Calendar access is often granted to delegates to allow other people to deal with someone’s schedule. It’s easy for users to assign delegate access to their calendar. For instance, in OWA, go to the calendar, click the […] beside the calendar you want to share, select Sharing and permissions, and then add the new delegate. In Figure 1, we’ve elected to give the delegate the ability to view private calendar events too.

Once applied, the delegate will be able to open the delegator’s calendar and Exchange will send calendar invitations and responses to the delegate for their attention.

Behind the Scenes

Delegate access usually works without a hitch, but when things go wrong administrators will probably need to resort to PowerShell to understand what’s happening. The first thing is to establish what kind of access someone has to a problematic calendar. The Get-MailboxFolderPermission cmdlet shows the permissions set on a folder. In this case, we pass the user principal name of the account we want to check and “:\Calendar” to indicate the folder name.

Get-MailboxFolderPermission -Identity Jane.Sixsmith@office365itpros.com:\Calendar

FolderName           User                 AccessRights          SharingPermissionFlags
-------------           ----                 ------------       ----------------------
Calendar             Default              {AvailabilityOnly}
Calendar             Anonymous            {None}
Calendar             Ken Bowers           {Editor}              Delegate, CanViewPrivateItems

Common Delegate Access Issue

According to Microsoft, the most common error met with delegate access happens when a user cannot add a new delegate or remove an existing delegate from their mailbox. The root cause is usually a corrupted hidden item in the mailbox which stores the delegate information. Microsoft publishes a comprehensive support article outlining the steps to take to recreate the hidden item. The steps work, but assume that:

• You have a working knowledge of the MFCMAPI utility or the Exchange Web Services editor. I prefer using MFCMAPI and consider it an extremely useful program for any administrator, but I acknowledge that the interface is “interesting” and non-intuitive. In other words, it’s easy to make mistakes.
• You can run these utilities on a Windows workstation to access the problem mailbox.

Because of the multi-step recipe to fix the problem and the need to use an unfamiliar program, some people never manage to get to the end and resolve the issue. This is a classic example of where software can help.

Automating the Rebuild with a New Cmdlet Parameter

Microsoft has released a new switch parameter for the Remove-MailboxFolderPermission cmdlet called ResetDelegateUserCollection. When you run the cmdlet with the parameter, Exchange Online essentially does all the work outlined in the support article to replace the potentially corrupted mailbox items. For example:

Remove-MailboxFolderPermission -Identity Jane.Sixsmith@office365itpros.com:\Calendar -ResetDelegateUserCollection

Confirm
Are you sure you want to perform this action?
Using ResetDelegateUserCollection changes existing calendar Delegate permissions. You will need to re-assign the
Delegate flag to these recipients using Set-MailboxFolderPermission -SharingPermissionFlags Delegate. It is suggested
that this ResetDelegateUserCollection option is only used when you believe there is corruption that is preventing
managing calendar permissions.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): Y
WARNING: Resetting DelegateUserCollection...
WARNING: DelegateUserCollection is reset.

Note the warning. If we run Get-MailboxFolderPermission again, we’ll see that the sharing permission flags which make someone into a delegate are gone.

Get-MailboxFolderPermission -Identity Jane.Sixsmith@office365itpros.com:\Calendar

FolderName           User                 AccessRights             SharingPermissionFlags
----------           ----                 ------------             ----------------------
Calendar             Default              {AvailabilityOnly}
Calendar             Anonymous            {None}
Calendar             Ken Bowers           {Editor}

To complete the fix, we need to add delegate permissions again. You could ask the user to do this by updating the permissions assigned to their calendar, but it’s easier and more polite for the administrator who’s just reset the delegate information to do the job for the user by running the Set-MailboxFolderPermission cmdlet. If you don’t do reset permissions, delegates will have editor permission for the calendar folder, but they won’t be able to process calendar invitations on behalf of the mailbox owner. Here’s how to reset the permissions for Ken Bowers:

Set-MailboxFolderPermission -Identity Jane.Sixsmith@office365itpros.com:\Calendar -User Ken.Bowers@office365itpros.com -SharingPermissionFlags Delegate, CanViewPrivateItems -AccessRights Editor

After the cmdlet completes, you can run Get-MailboxFolderPermission again to verify that the delegate sharing permission flag is present once again (and optionally the flag allowing the delegate to view private items too).

Of course, it’s fine if you’d prefer to follow the MFCMAPI recipe to fix the delegate issue, but it’s a lot easier and faster to run a couple of lines of PowerShell!

Cmdlet Availability

The upgraded version of Remove-MailboxFolderPermission is rolling out now. If your RBAC configuration is higher than 15.20.3722, the cmdlet should be available in your tenant. To check, run the Get-OrganizationConfig cmdlet to check the value of RBACConfigurationVersion:

Get-OrganizationConfig | Select RBACConfigurationVersion

RBACConfigurationVersion
------------------------
0.1 (15.20.3763.11)

This is just the kind of detailed how-to information we love reading about. It might only end up as a line or two in the Office 365 for IT Pros eBook, but that’s no reason not to share the knowledge with you.

Closing the Gap Between Outlook and Teams

Microsoft has been gradually closing the gap between Outlook and Teams over the last year or so. The headline work is probably the Share to Teams and Share to Outlook features, but lots of smaller changes have rolled out to make it easier for Outlook users to access Teams. Most recently, a change was made to have Outlook create Teams meetings by default.

Office 365 notification MC233463 (January 9) covers the addition of a Meet Now button for Teams in the Outlook for Windows (Microsoft 365 apps for enterprise version). The roadmap item is 68838 and deployment to commercial and GCC tenants due to start in late January with completion in mid-February.

Code for the Meet Now button is included in the Teams meeting add-in. In addition, you’ll need to run a recent version of Outlook (I am using version 2012 build 13530.20316) before the Meet Now button shows up in Outlook’s calendar tab (Figure 1).

What Happens When You Meet Now from Outlook

When you click the Outlook Meet Now button, Teams attempts to launch a new private meeting. This works well if you’re signed into Teams in your home tenant (in other words, Outlook and Teams are connected to the same tenant). The meeting starts and you can invite people to join and do everything that normally happens during a private meeting.

Things aren’t quite so good if you’ve moved away from your home tenant to sign into Teams as a guest in another tenant. Now things depend on settings in the default Teams meeting policy for that tenant, which dictates what guest users can do. First, guests must be allowed to create impromptu private meetings. In Figure 2 the setting is disabled, and guests can’t use Meet Now.

Guest Accounts and Meet Now

Even when guests can use Meet Now, they might run into another issue. It’s common that organizations set meeting policies to restrict the people who can join a meeting without going through the lobby. In Figure 2, the policy is set so that only meeting organizers can join a meeting direct. If the meeting policy doesn’t allow guests to join a meeting without going through the lobby, any attempt by a guest to use Meet Now will result in the frustrating situation where the meeting starts but the guest can’t join because they are in the lobby. No one else has been invited to the meeting, so no one can join to release the guest from the lobby. The meeting therefore enters a black hole and doesn’t come out.

The point can certainly be argued that guest accounts shouldn’t be using a tenant for Meet Now meetings. If they want to meet with someone in the target tenant, the guest can go back to their home tenant and create the meeting there. This is true, but a more elegant implementation could have communicated the problem better to guests.

Teams Meeting Policy Settings to Control Meet Now

Reverting to tenant users, two settings in the Teams meeting policy assigned to an account dictates if the user can use the Meet Now feature of the Teams meeting add-in. First, they must be allowed to use the add-in (else it won’t be loaded by Outlook). Second, they must be allowed to use Meet Now to launch private meetings. For instance, users assigned the meeting policy shown in Figure 2 won’t see the Meet Now button.

If you’re using the Teams PowerShell module to check or set policy settings, the settings are AllowOutlookAddIn and AllowPrivateMeetNow. Both must be True. Note that if you disable the Allow Meet Now in private meeting setting, users won’t be able to use the Meet Now option in the Teams calendar app.

Lots of changes happen in Teams as the platform expands to deal with user demands and requirements of organizations. Keep up to date with what’s happening by subscribing to the Office 365 for IT Pros eBook. We do the heavy lifting so that our subscribers always have the best information.

Critical Piece to Connect Outlook to Teams

The article about how to make Teams meetings the default for Outlook for Windows prompted some questions about the Teams Meeting add-in. This is the component which connects to Teams to create the online space used to host a meeting and populate the meeting properties with the values necessary to let Outlook know that the meeting is online. Read this post for more details about using the add-on.

Finding the Version of the Teams Meeting Add-In

The questions that arose included:

• Where is the add-on stored?
• How do you know what version of the add-in is on a PC?

The easy answer to both questions is found by examining the Add-ins section of Outlook options and looking for the entry for Microsoft Teams Add-in for Microsoft Office (Figure 1).

Here we discover that the DLL used to load the add-in is AppData\Local\Microsoft\TeamsMeetingAddin\1.0.20339.4\x86\Microsoft.Teams.AddinLoader.dll. We now know the location and the version number of the add-in. A separate folder stores the files for the X64 version.

Teams updates the add-in when it refreshes the Teams client on Windows PCs.

The Teams Meeting Add-In and LoadBehavior

Another important influence on the Teams Meeting add-in is the registry setting which controls its load behavior. The LoadBehavior DWORD value under the TeamsAddIn.FastConnect key should be 3 for normal operation (Figure 2). According to Microsoft documentation, 3 means that the relevant application (Outlook) should load the add-in at start up, which is what we want.

Sometimes, for whatever reason, the value goes missing in action and needs to be recreated to allow Outlook to load the Teams meeting add-in. Don’t set the value to anything else unless instructed by Microsoft support.

The registry file to populate the value is:

Windows Registry Editor Version 5.00
[HKEY_CURRENT_USER\Software\Microsoft\Office\outlook\addins\TeamsAddin.FastConnect]
“Description”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“FriendlyName”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“LoadBehavior”=dword:00000003

Unwanted Add-Ins

Not many people probably check the add-ins loaded by Outlook (unless problems occur). The other add-ins listed in Figure 1 are:

• SharePoint Server Colleague Import: Used by the old Colleague feature implemented in SharePoint 2010. Not needed anymore.
• Exchange: If you’re using Teams, you’re using Exchange. Leave this add-in alone.
• Outlook Social Connector 2016: Used by Outlook’s People Pane (another old feature). Microsoft says that it’s not used in Outlook for Office 365, so why the add-in is loaded is unknown.
• OneNote notes about Outlook items: Used to send Outlook data to OneNote. This function must be enabled in the Advanced section of Outlook options.

In my case, the add-ins are published and installed automatically by Microsoft. Depending on how Outlook is configured in your organization, you might have other add-ins loaded, including some created by ISVs.

To disable the unwanted add-ins, select COM Add-ins in the Manage drop-down at the bottom of the Add-in options screen and click Go. Uncheck the add-ins you don’t use (Figure 3).

Another day, another snippet of Office 365 information to share with the world. We can’t fit this kind of information in the Office 365 for IT Pros eBook because its 1,250 pages are already packed with juicy insight into how applications really work, but it’s nice to share.

Making Teams Meetings the Default for Outlook

Microsoft is taking steps to encourage Outlook users to make Teams online meetings the norm. It’s possible for organizations to enforce a policy to make Teams meetings the default for Outlook mobile, Outlook for Mac, and OWA clients and an update to Outlook for Windows will force the same behavior for individual clients.

Teams Ignores Outlook Attachments

It’s good that Microsoft is upgrading Outlook to make it work better with Teams work. That is, until you want to attach files to invitations for Teams meetings sent from Outlook. Despite being a feature supported by Outlook for as long as I can remember, the functionality is not supported by Teams. The lack is noted in Teams User Voice and many other complaints in other sites. So far, the Teams development group hasn’t commented.

Figure 1 illustrates the problem. We’ve created a Teams meeting in OWA and dragged an XLS attachment to add it to the meeting. This is a natural action for Outlook users that’s replicated millions of times weekly (if not daily).

When the meeting invitation is sent, it is delivered to recipient mailboxes and added to their calendars. The meeting details are synchronized from the mailboxes to the Teams calendar app, which displays them in Teams (Figure 2). We can see that the text included in the invitation is present, but the spreadsheet attachment is missing. In fact, the attachment is in the calendar folder in the mailbox and can be accessed using an Outlook client, but it’s ignored by Teams.

Teams Prefers Cloudy Files

On the surface, it seems odd that Microsoft allows such a feature gap to exist. However, the Teams architecture is very different to Outlook, and that’s where the root of the issue might be.

Exchange has always supported message attachments. For years, including attachments in email was the only reliable way to transmit files between people. Microsoft started on the path to convert Office 365 users away from traditional attachments to “cloudy attachments” soon after the introduction of Office 365 Groups (now Microsoft 365 Groups). The almost-guaranteed availability of SharePoint Online and OneDrive for Business make it more feasible to ask people to store documents in the cloud and add links to attachments in email instead of physical attachments. Over time, Microsoft has improved link management across Office 365 to a point where links are consistent across all the major apps.

SharePoint Online is now used by over 200 million Office 365 users and a lot of that growth is due to the popularity of Teams. Every team has its own SharePoint team site, and every user has OneDrive for Business. Teams uses SharePoint and OneDrive to store and share files, meaning that there’s no need to accommodate attachments on local drives, which is where many attachments added to email originate.

Adding Files to Teams Meetings

The net result is that two ways are available to include files in Teams meetings:

• The meeting organizer can generate links to files and include them in the meeting invitation. They can also update meeting details afterwards to include links to other files. The meeting organizer must set sharing permissions to allow participants to access the shared files.
• After the meeting is created, any tenant user can upload files to the Files section of the Teams meeting workspace. Invitees outside the organization can’t share files in this way. However, they can share links to documents through chat after the meeting starts (they’ll have to make sure that the links grant access to meeting participants).

If the information contained in an attachment isn’t very long, you can also cut and paste it into the body of the invitation. This is acceptable for text but less satisfactory for other types of documents.

To share files, participants access the meeting through the Teams calendar app and upload the files to the workspace (Figure 3). The shared files become part of the meeting chat.

The files are uploaded to the Microsoft Teams Chat Files folder in the sharer’s OneDrive for Business account and shared with meeting participants. Note that if other people are added as meeting participants after a file is shared, the owner of the file must update the direct access sharing settings to include the new participant (Figure 4). If they don’t, they won’t be able to access the file.

After a file is uploaded, it can’t be removed from the meeting chat using the Teams calendar app. If someone makes a mistake, they can either move the file from the Microsoft Teams Chat Files folder, remove it from their OneDrive for Business account, or change the permissions on the file. The file is still listed in the meeting, but participants won’t be able to access it (Figure 5).

A Gap Microsoft Should Close

Although it’s understandable that Teams would like to use cloudy attachments everywhere, Microsoft should close the functionality gap which now exists when Outlook users include attachments in Teams meeting invitations. It wouldn’t take much code to extract attachments from invitations and create copies in OneDrive for Business.

Using technology to transform attached files into cloudy attachments seems like a reasonable step to remove some user frustration and connect Outlook and Teams together more seamlessly. We wait to see what Microsoft will do.

Looking for more information about why Teams works the way that it does? Subscribe to the Office 365 for IT Pros eBook to take advantage of the years of experience our writers have in understanding and interpreting what Microsoft does (or doesn’t do).

Just Like the Other Outlook Clients

In mid-2020, Microsoft introduced new configuration settings to make Teams online meetings the default when scheduled by OWA, Outlook for Mac, and Outlook mobile clients. Office 365 notification MC230567 (updated January 20) brings the news that Outlook for Windows gains a similar feature. According to Microsoft roadmap item 66021, the feature will be available in January 2021. It depends on updates to the Teams meeting add-in for Outlook and Outlook click-to-run (current channel). As I write, I see the change in Microsoft 365 Apps for Enterprise build 13530.20218.

Updating the Organization Configuration

OWA and Outlook mobile use an Exchange Online organizational setting (which can be overridden for individual mailboxes) to know if they should schedule online meetings. If the organizational setting is configured, Outlook for Windows will respect that setting and make meetings online by default. To configure the organizational setting, run the Set-OrganizationConfig cmdlet from the Exchange Online management module as follows:

Set-OrganizationConfig -OnlineMeetingsByDefaultEnabled $True

All Outlook clients now use the same organization setting to control when they create Teams online meetings. The default for a tenant is $False, meaning that the decision is then up to the user.

Even if OnlineMeetingsByDefaultEnabled is updated to $True, Outlook users can remove the online components from individual meetings by selecting the Don’t Host Online option from meeting settings (Figure 1).

Outlook for Windows also includes a setting in the Calendar section of its options to control if the client should create Teams meetings as the default (Figure 2). This option is effective only if OnlineMeetingsByDefaultEnabled is set to $False.

Users who choose not to enable online meetings by default can still schedule online events by selecting the Teams meeting add-in when creating a new meeting.

Teams Online Meetings

When Outlook creates a Teams meeting, it sets up a Teams online space for the event and adds the necessary properties to the meeting (Figure 3).

A welcome change in the Teams meeting add-on is that Outlook for Windows no longer calls a web page when a meeting organizer wants to set or change the options for a Teams online meeting (Figure 4).

No Support for Third-Party Online Meetings

Unlike Outlook mobile, you can’t configure third-party add-ins for online meetings to have Outlook for Windows use services like WebEx, Zoom, or BlueJeans instead of Teams. To setup new Outlook events for meetings hosted on these platforms, you need to paste the meeting details into the Outlook meeting before sending the event notification to participants.

This is a great example of a change that warranted a four-word update in the Office 365 for IT Pros eBook. It’s not that the topic isn’t interesting; it’s just that we have so much more to talk about when it comes to running an Office 365 tenant.

Recognizing an Online Meeting

A Year or so ago, I wrote about how Outlook recognized online meetings created in Skype for Business Online and Teams. In a nutshell, the Teams meeting add-in for Outlook populates a set of MAPI properties like OnlineMeetingConfLink in the calendar event to allow the user to join the online meeting. The Teams calendar app also populates these properties and Outlook and the calendar app use these properties to recognize the event as an online event and associate the link with the Join button shown in meeting reminders and other places in the client UI.

To allow meeting participants to navigate to the online workspace, several properties of the calendar event such as OnlineMeetingConfLink store joining information. For a Teams online meeting, OnlineMeetingConfLink holds a deeplink to the online workspace which hosts the meeting resources like the chat, whiteboard, notes, and participant list. Once created, the online space is available for any participant to join, even if the starting time for the meeting is a long time in the future. This facility exists to allow people to prepopulate a meeting with resources, like notes or shared files, before it begins. Likewise, a meeting persists after its formal end time to allow participants to access its resources after the meeting finishes.

Clicking the Join button (or the Join Microsoft Teams Meeting link in the body of the meeting item) starts the process of joining the meeting, which might involve navigating through a web page to choose how to join and waiting in a lobby to be admitted.

Recurring Meetings Have the Same Workspace

Recurring meetings are created in a series to occur at the same time at set intervals, such as every week or every month. Figure 1 shows the Teams calendar app scheduling a recurring meeting to occur monthly. From an Outlook perspective, each meeting is a separate event in a series of meetings.

Teams uses the same online workspace for all the meetings in the series. You can see this by examining the deeplink added to the events (Figure 2). They are all the same.

The value of this approach is that all the meetings in the series share the same resources. A chat started in one meeting is carried on to the next; the notes from previous meetings are available in future meetings, and so on. For example, Figure 3 shows a sequence of chats generated after joining multiple events in a recurring meeting. There is nothing to distinguish the messages sent in one meeting from those sent in another; they are all merged into a single stream.

The same is true for other assets like meeting notes (Figure 4). In this case, a separate section is used for each meeting to identify the notes taken for individual events.

The Downside of the Common Workspace

Sharing a common workspace for all instances of a recurring meeting makes sense to some but not all users. Unless it’s explained how Teams leverages the shared workspace for all meetings in a series, it’s common to find that people expect that each instance in a series should be treated as a standalone event with its own resources. This isn’t the case and won’t be the case unless the Teams development group reverses course, which then means that if you consider that it’s best to separate each event, you need to create individual meetings. New access rules for meetings being rolled out in December 2020 will help, but individual meetings are the best way to go if you want to have sure control over meeting resources.

Scheduling individual meetings forces Teams to create a different workspace for each meeting and the assets generated for the meeting will be associated with that workspace. The downside of this approach is that it’s obviously much easier to create a single recurring meeting to occur monthly than to create twelve individual meetings.

Need to understand more about how Teams really works? Subscribe to the Office 365 for IT Pros eBook to gain insight that’s updated monthly.

Introducing the Teams Button

Today’s topic is an unannounced update that’s just turned up in Outlook for Windows version 2011 (click to run build 13426.20184). At least, I’ve just noticed the change, which adds a Teams button to the Groups menu bar displayed when a team-enabled Microsoft 365 group (aka an Office 365 group or even Outlook group) is accessed (Figure 1). The button is hidden when you open a Microsoft 365 group that doesn’t have an associated team.

Clicking the Teams button opens the Teams client positioned in the General channel of the team. It can’t open any other channel.

I’m uncertain what value is delivered by the Teams button. If you use Outlook to open Microsoft 365 Groups, you’re likely using it to have email-based conversations instead of Teams chat-based conversations. It seems unreasonable to assume that you would want to switch between the two modalities in the same group. After all, Microsoft doesn’t support the Share to Teams functionality for group conversations that’s available for regular email. Apart from a manual cut and paste, the only way to get a group conversation from Outlook (or OWA) to Teams is to forward the message to the email address of a team channel.

Moving Easily Between Outlook and Teams

It could be argued that adding the Teams button is simply a case of Microsoft making it easier for customers to move between Outlook and Teams. It could be the case that the team has integrated apps that aren’t available to Outlook, like Planner, some SharePoint pages, and a couple of third-party apps. In that respect, it makes sense to have an easy way to jump from Outlook to Teams.

It seems more likely that the Teams button is Microsoft’s subtle way to convince people to move their conversations from Outlook to Teams. There’s logic underpinning that transition because Teams is a better place to hold many conversations, especially those involving multiple back-and-forth responses.

On the other hand, if email-based conversations are your thing and your group involves many external people (guests and non-guests), an Outlook-based group is a good way to get work done. Microsoft recently updated Outlook for Windows to make the unread count work like regular folders, so work is still being done to improve and smoothen Outlook groups. And that’s the way it should be. Although Teams has 115 million daily active users, a lot of email is still sent inside and out of Office 365.

We cover both Teams and Outlook Groups in the Office 365 for IT Pros eBook. And we use both to get real work done.

A Rather Useful Add-in

The Teams Meeting add-in for Outlook is installed automatically when Outlook starts if:

• The user account is licensed to use Teams in the same Office 365 tenant.
• Outlook is configured to use modern authentication. Exchange Online enables modern authentication by default for Office 365 tenants. It might be off (but shouldn’t be) for tenants created before August 1, 2017.
• The Teams meeting policy assigned to the account allows the user to create personal meetings. All meetings created through Outlook are personal (rather than channel meetings, Meet Now meetings, or Live events). The Teams meeting policy for the account must also permit Outlook to load the Teams Meeting add-in.

If an account meets these criteria and Outlook desktop does not load the add-in automatically, the usual solution is to sign out of both Teams and Outlook, then restart Teams and connect to the home tenant. Finally, restart Outlook. The add-in should now detect the correct Teams configuration and load properly.

Meetings Created by Outlook

Teams personal meetings can be created by Outlook desktop (Windows and Mac), Outlook mobile, and OWA. Like a previous add-in for Skype for Business Online, its function is to allow users to create online meetings without having to use the calendar app in the Teams client. When Outlook creates a Teams meeting, the add-in creates the Teams thread for the meeting and populates the properties of the meeting to identify it as an online event, including the connection URL needed by participants to attend the meeting.

Administrators can configure a policy to create online meetings as the default for OWA, Outlook for Mac, and Outlook Mobile. Users of Outlook for Windows can configure client settings to make Teams online meetings the default.

Add-In Files and Registry Setting

Teams updates the Meeting add-in when it updates the desktop client. You can find information about where the add-in files are installed on Windows and how the add-in is launched in this post.

Updating Meeting Options

Until recently, the Teams Meeting add-in was only used to create new online events. The latest version of Outlook in the Current Channel (Preview) supports the ability to alter the settings for an event after it is scheduled (Figure 1). As I write, I am running build 2010 13328.20292 of the Microsoft 365 apps for enterprise, but the feature worked in the last released build too. The same capability doesn’t seem to be available in OWA or Outlook Mobile (yet). I haven’t tested Outlook for Mac.

To set meeting options, select a Teams meeting from the calendar and open it. You should see a Meetings Options choice in the menu bar (the icon might differ from that shown in Figure 1). Outlook opens the Teams meeting options dialog to update settings like who can bypass the lobby and join a meeting without being explicitly allowed in or if participants can unmute themselves during a call. The same web page is used as when meeting options are set from the Teams calendar app.

Behind the scenes, Outlook uses a URL like that shown below to open the meeting options page:

https://teams.microsoft.com/meetingOptions?language=en-us&tenantId=b762313f-14fc-43a2-9a7a-d2e27f4f3478&organizerId=efe4cd58-1bb8-4899-94de-795f656b4a18&threadId=19_meeting_NTQwZjY3ZjItNGQ4ZC00NWU5LTk2ODYtMDA5YWQ1N2FhMjJm@thread.v2&messageId=0&correlationId=webclient:6c86e496-88ac-4088-b430-575895275a09

The URL includes:

• Display language (en-us = U.S. English).
• GUID to identify the Office 365 tenant (tenanted).
• GUID to identify the Azure AD account of the meeting organizer (organizerid).
• Thread identifier for the online event.

The URL for the meeting is among the properties stored by Outlook for the calendar event.

A Logical Change

Updating the Teams Meeting add-in for Outlook to support changing meeting options is a good change. Even though Teams is the Office 365 app getting most focus from Microsoft today, many people prefer to use Outlook as their fulcrum for work (and personal activity). And while they might use Teams for online meetings, it doesn’t make sense to disrupt their workflow and force them to open the Teams calendar app just to update a meeting setting.

There’s tons of useful and insightful information like this in the Office 365 for IT Pros eBook. Best of all, we update the information when Microsoft changes something. That way our subscribers always have the latest insight at their fingertips

For Both Teams and Skype for Business Online Meetings

In May, Microsoft published Office 365 notification (MC213856) to say that OWA and Outlook Mobile would soon make online meetings the norm. This is now the case.

The calendar settings for OWA include whether an online meeting should be created for all meetings (Figure 1). By default, the setting is controlled by the OnlineMeetingsByDefaultEnabled setting in the Exchange Online organization configuration, which can be examined using the Get-OrganizationConfig cmdlet. Here we see that the setting is true, meaning that all meetings created by OWA are online:

Get-OrganizationConfig | Select OnlineMeetingsByDefaultEnabled

OnlineMeetingsByDefaultEnabled
------------------------------
                          True

Mailbox-Level Control

You can also control the setting on a mailbox basis by updating its calendar configuration with the Set-MailboxCalendarConfiguration cmdlet. The mailbox-level setting takes precedence over the organization setting. For example, this command disables online meetings by default for a mailbox:

Set-MailboxCalendarConfiguration -Identity James.Joyce –OnlineMeetingsByDefaultEnabled $False

OWA uses the Teams configuration to figure out if Teams or Skype for Business Online is the current provider of online meetings to the tenant. The provider is noted in the calendar configuration of each mailbox. We can check which provider is used by running code like this to report the provider and if online meetings are enabled. Fetching calendar configuration can take some time to complete for more than a few mailboxes:

$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize 50
$Mbx | Get-MailboxCalendarConfiguration |Select Identity, DefaultOnlineMeetingProvider, OnlineMeetingsByDefaultEnabled

Identity       DefaultOnlineMeetingProvider OnlineMeetingsByDefaultEnabled
--------       ---------------------------- ------------------------------
Andy.Ruth      TeamsForBusiness
Ben Owens      TeamsForBusiness
Ben.James      TeamsForBusiness
Brian Weakliam TeamsForBusiness
Imran Khan     TeamsForBusiness
James.Joyce    TeamsForBusiness             False
Kim Akers      TeamsForBusiness             True

Different Approach Used by Outlook Desktop

Outlook desktop takes a different approach to OWA. Outlook doesn’t use the calendar configuration settings stored in user mailboxes; its settings are in user profiles stored in the system registry. Currently, Outlook doesn’t have a setting to control whether all meetings should be online and instead loads an add-in to allow users to decide if a meeting should include Teams or Skype for Business Online.

When you create an online meeting, Outlook populates several properties for the meeting item stored in the mailbox containing links and other information about the online space for the meeting. The link allows users to join the online meeting at the appointed time. Apart from the link and the list of meeting attendees, Outlook has no connection to the online event, so items such as the meeting chat, participant list, and so on must be accessed through the online provider.

Microsoft 365 Roadmap item 58132 promises that Outlook for iOS will allow third-party online meeting providers like Zoom and WebEx to be the preferred provider. Microsoft was supposed to deliver the capability in August 2020, but there’s no sign of it still.

Who knows when you might need a nugget of information like this? We don’t know, so we find and document interesting bits of insight in the Office 365 for IT Pros eBook. Subscribe today to stay abreast of what happens inside Office 365.

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.

Wow! Where Did All Those Unread Items Come From?

Last Tuesday, I checked for updates for the Microsoft 365 apps for enterprise (Office click to run) and duly downloaded the available update to upgrade to version 2009 (build 13231.20200). Nothing strange happened and the upgrade proceeded without any issues. I was a happy camper.

That is, until I noticed that the unread count for my Outlook Groups suddenly displayed much higher numbers (Figure 1). Usually these groups have a very low number of unread items, especially those marked as favorites because I check them at least once daily.

The History of Groups

The reason why this happens is clouded in history. When Microsoft introduced Office 365 Groups (now Microsoft 365 Groups) in November 2014, they were characterized as a new way for email-centric collaboration. Teams didn’t exist at that point and although Microsoft’s marketing muscle was pushing Yammer (bought in June 2012) as the future for collaboration and a replacement for email (that strategy really worked out), the bulk of interpersonal electronic collaboration occurred over email.

In the on-premises world, many Exchange organizations combined distribution lists with public folders to give people an archive for discussions. Groups introduced a group mailbox to host discussions and a shared calendar and came with a SharePoint Online team site for document storage, including a shared group OneNote notebook. Given that the bulk of work that had been migrated to Office 365 at that point was email, Groups looked pretty good. In April 2017, Groups (now called Groups in Outlook) had 10 million active users, or roughly 10% of the Office 365 user count at the time. The latest figure for Office 365 is 258 paid seats (April 2020). It’s unlikely that Outlook Groups have kept pace and now has 25 million active users, but it’s possible.

The collaboration landscape within Office 365 changed upon the general availability of Teams in March 2017. Since then, Teams has taken the lead and Groups have concentrated on a new mission of delivering a membership and access service to applications like Teams. Usage of Outlook Groups as a fulcrum for email-based collaboration is much less important to Microsoft now, but Groups are still actively used in this way in many Office 365 tenants.

Choosing a Simpler Unread Count Model for Groups

When Groups were added to Outlook in 2015, the developers decided not to use the standard item read/unread model as used in other mailbox folders like the Inbox. This model depends on the unread status of items and operates on a per-user basis. In other words, in a shared resource like a group inbox or public folder, each user has a separate unread count generated by the number of items they have not read in the folder.

Instead, the group developers chose a “more simple triage model for the groups conversations list, where all the conversations would be marked as seen as you moved away from the group.” Apparently, the decision was based on user feedback that many groups contain conversations unimportant to some members, so you couldn’t expect them to read everything. As implemented in Outlook, the group seen/unseen model allowed users to scan a group for new items and then set the unread count to zero once the user moves from the group. The new item count for a group then becomes the number of items delivered to the group since the last access by the user.

By comparison, new messages delivered to an inbox are personal and the mailbox owner is expected to deal with them. The new item count for the inbox is therefore very important for the mailbox owner and is adjusted up and down as the unread status for messages change (you can mark a read item as unread).

OWA and Outlook Mobile Use Normal Unread Counts

At the time, the developers accepted that the difference in how folders reported unread counts caused user confusion and said that they were working on implementing an item read/unread model for Groups. That model was implemented by OWA in early 2019 and is in use today (Figure 2).

For whatever reason (prioritization, lack of resources, more pressing features, etc.), Outlook desktop is a long way behind OWA in moving to the item read/unread model. The latest builds of Outlook have switched to the item read/unread model, which is the reason why the unread counts for my groups suddenly exploded from their normal low levels. Outlook Mobile has also used item unread counts since early 2019.

Resetting the Unread Count for an Outlook Group

Another piece of good news is that the Outlook developers have included a Mark All as Read option to reset the unread count for a group. Select the group you want to reset, right-click, and select the option. Processing to reset the unread status for items occurs in a background thread, so it doesn’t stop you working while the unread count is reset. Depending on the number of unread items in the group, the option can take a little while to complete.

Unhappily, Outlook’s Mark All as Read option might not be able to update the status for all unread items. At least, it didn’t for me. My solution was to open the group with OWA and use its version of Mark All as Read, which worked flawlessly.

The good news is that as you open unread items in in a group using one client, the read status for the item and unread count for the group is updated and shown correctly across all Outlook clients.

Hindsight Always Best

The benefit of hindsight tells us that the decision of the Groups developers to go with the simpler read/unread model for their Outlook implementation was flawed. The change made in the other clients in 2019 is now showing up in Outlook desktop. A little preparation and user communication should be enough to get everyone over the shock of seeing elevated unread counts for their groups.

This one-time change will probably warrant a line or two in the Office 365 for IT Pros eBook. It’s an example of a small change that’s important for some users for a period. Once the change is done, it’s done. But change persists inside Office 365, which is why we keep updating the book.

Easy Switch Away from Apple’s Mail App

In June, we reported that Apple would allow Outlook to be the default mail app for iOS14. This prospect proved popular for the many Outlook for IOS users who have no interest in using Apple’s Mail App. Because of the limitations of the Exchange ActiveSync protocol, Outlook for iOS is more functional when connected to Exchange Online than the Mail app is. The only place where the Mail app has an advantage is its ability to connect to accounts in Office 365 tenants across multiple datacenter regions, something that Outlook can’t do.

Now that iOS14 is generally available, it was time to download and apply the update and then check that Outlook can indeed take the place of Apple’s Mail app. The good news is that switching Outlook in is simple. Use the Select Default Email App link in Outlook settings (or go direct) to go to iOS settings, Now select Outlook and scroll down to the Default Mail App setting (Figure 1).

Mail means that the Apple Mail app is currently selected. Click the link to view the set of available options. You’ll need a recent version of Outlook for it to show up here. I used version 4.56.0 from the Testflight program, but any version from 4.55.1 will work. Select Outlook to make it the default mail app for iOS (Figure 2).

Rebooting iOS14 will reset the choice of apps back to the Apple apps. I experimented by rebooting iOS a couple of times and each time iOS made the Mail app the default. The problem is fixed in iOS 14.0.1, published on September 24.

Glitches like this are certainly something to be expected with a new version of an operating system and is one reason why people recommend waiting before upgrading. Microsoft is also aware of two other bugs:

1. Mailto: links in Safari will be opened in Apple’s Mail app instead of the chosen default app (Outlook in this case).
2. If you have a profile configured with the Mail app, certain compose sheet actions trigger Apple’s Mail app instead of the chosen default app. For example, apps that use MFMailComposeViewController.

Bugs like this might not affect you, especially if you choose to replace Safari with Microsoft Edge as the default browser.

Pin Outlook to the Home Screen

Another useful thing to do is to include Outlook and other apps which you commonly use into the set of four pinned apps at the bottom of the home screen. Apparently this is possible in iOS13 too, but I guess I missed that news. The set of default apps includes Mail, so if you’ve replaced it with Outlook, there’s no reason to keep it pinned. Click and hold on the Outlook icon until the Edit Home screen option appears. Then drag and drop it into the pinned set to replace Mail. As you can see in Figure 3, I also replaced the Music app with Teams.

Another way of doing the same job is to search for the app, press on the icon, and select Add to Home Screen.

Even though it takes some muscle memory adjustment to look for Outlook in the pinned set, I can’t tell you how useful it is to be able to access Outlook at one click no matter where you are in iOS.

Outlook No Longer Supports iOS12

Now that Apple has released iOS14, Microsoft’s support policy means that Outlook on iOS12 is no longer a supported platform: these devices will no longer receive Outlook updates and will eventually cease to connect to the service. You should look for devices running Outlook on iOS12 and ask their users to upgrade. Fortunately, a little PowerShell (see this article) will quickly identify the iOS12 devices by checking their connection status. After that, it’s a matter of communication and persuasion to get those devices up to the necessary level. Maybe they’ll upgrade to iOS14 to take advantage of Outlook’s new potential status as the default mail app.

Sometimes we share things that make our working lives better that never end up in the Office 365 for IT Pros eBook, but it’s good to know how things work, which is why we write about them.

A Reminder About the Demise of Office 2013

Microsoft originally published Office 365 notification MC190854 in September 2019 to advise tenants that support will end for Office 2013 client connections to Office 365 applications on October 13, 2020. They’ve just republished the notification as MC218020 to remind everyone that the date is approaching and it’s time to act. The original end-of-support announcement was in April 2017, so no one should be surprised at this point. But some will be.

Microsoft has softened their line a little since 2017. Then they said that “it will be required to have Office 365 ProPlus (now Microsoft 365 apps for enterprise) or Office perpetual in mainstream support to connect to Office 365 services.” Now they say that they’ll will not take “any active measures to block older Office clients, such as Office 2013 and Office 2010, from connecting to Office 365 services.” The bite is in the comment that “legacy clients…may experience performance and reliability issues.”

We Told You Things Will Break

In other words, after October 13, 2020, you can continue using Outlook 2013 to connect to Exchange Online, but you’re on your own and shouldn’t be surprised if some feature stops working or the client connects intermittently or not at all. In addition, the deprecation of basic authentication for many connection protocols for Exchange Online means that all clients must use modern authentication. Finally, without security updates for older clients, a higher risk exists that an attack will succeed through a weakness fixed in a current version.

Microsoft’s update says, “Support for Office 2016 and Office 2019 connections to Office 365 cloud services will continue until October 2023.”  This is the end of mainstream support for Office 2019 and it’s curious that they use the same date for both versions. Perhaps this is to emphasize to Office 365 tenants that the days of perpetual licensing for the Office desktop applications are ending. Microsoft wants customers to transition to Microsoft 365 apps for enterprise, which use the click to run technology to upload clients.

Click to Run Glitches

Click to run normally works very well, but examples do exist when things go wrong, such as the botched update of July 14 which stopped Outlook connecting to Exchange Online and caused some tenants to rollback to a previous build by running the OfficeC2RClient program (see note below). The update to version 2007 was fine on my PC, probably because I had waited to apply it and was covered by the patch Microsoft issued. Overall, my experience is that the way Microsoft rolls out click to run updates is easy for users to deal with (if they’re told what to do when an update is offered as in Figure 1).

Choice Between Click to Run and Browser Apps

Faced with the decision what to do about outdated Office software, it’s hard not to recommend using the Microsoft 365 apps for enterprise, even if it costs more to upgrade users to Office 365 E3 licenses (the plan which includes these apps). On the other hand, a strong case exists that given the way people work today, it’s time to move away from desktop apps and use browser and mobile apps instead. OWA is now a fine client that’s more than an adequate replacement for Outlook desktop unless you absolutely need some Outlook-specific functionality that OWA can’t deliver.

Just in case you need this information, to revert to a previous version of Office Click to Run, open a command (CMD) window, change to the directory where the program is located, and run the program, stating which version you want to use:

cd %programfiles%\common files\microsoft shared\clicktorun
officec2rclient.exe /update user updatetoversion=16.0.12827.20470

Another Way for Tenant Administrators to Know When Incidents HappenI

MC211619 was one of the Office 365 notifications that passed me by without making much of an impression. Announced on June 16, it’s about a new right-hand notification panel in Outlook for Windows (click to run, aka Microsoft 365 enterprise apps). The panel appears when an incident happens that affects tenant users and the idea is that administrators get a heads-up before users start to complain that something isn’t working. The update is associated with Microsoft 365 roadmap item 58085.

One reason why I didn’t pay much attention to this change is that relatively few incidents have recently happened that affect my tenant. I guess I’ve been luck. Although incidents occur all the time inside Office 365, the sheer scale of the service and the way that tenants receive service from a network of datacenters mean that some tenants never notice problems while others experience issues.

The Outlook Notifications Panel Opens

Last night, Outlook (version 2006, build 13001.20384) opened the notification panel for the first time to display details of a problem with OneDrive. As you can see in Figure 1, notifications also include when problems are resolved. As it happens, the two incidents are related (navigation in the browser clients for SharePoint Online and OneDrive for Business). Clicking the See more link under a notification opens the Service health section of the Microsoft 365 admin center to display details of the problem.

I’m not sure how quickly Outlook removes notifications. The service health dashboard shows both problems as resolved at 9:37pm UTC on July 14 while the notifications remain visible some 36 hours later.

Outlook Help Includes Admin Notifications

The notification panel is designed to open automatically, which is what I saw. You can check for incidents at any time by going to Outlook’s help section (Figure 2).

Disabling Incident Notifications

If you don’t want to see incident notifications, you can disable their display in Outlook Options. Go to Advanced and scroll to the bottom to reveal the checkbox to disable incident notifications intended for administrators (Figure 3).

Outlook Build 2009 or later also includes the option to turn off notifications (Figure 4).

Microsoft doesn’t define what users Outlook considers to be an administrator. It seems like the panel is available to any account holding a role which allows them to access service health data, such as global administrators and global readers. This would make sense as these roles can access details of advisories and incidents in the Microsoft 365 admin center. I don’t believe that it works for accounts holding other roles like SharePoint administrator or Teams administrator.

Service Notifications by Email

You can configure service health dashboard preferences in the Microsoft 365 admin center to have incident notification sent by email to up to two users. Oddly, I didn’t receive notifications for the incidents flagged by Outlook, even though I’d chosen to receive emails for incidents and advisories related to SharePoint Online and OneDrive for Business. As I assume both Outlook and the admin center use the same service communications API to know when new incidents occur, it’s hard to explain why this happened. Maybe it’s just another small disconnect in the cloud.

Uncertain Need for the Feature

I’m unconvinced that a need existed for Outlook to surface incident reports to administrators. There’s already many ways to find out when problems exist, including the email mentioned above, using a third-party monitoring product, or building your own solution using the API. Besides, users let you know faster than any probe when things aren’t working, and your favorite social media feed will highlight problems when they are widespread across Office 365.

Overall, it seems like Outlook could focus on other areas of functionality like the top items in Outlook user voice instead of admin notifications, but hey, what would I know…

Need more information about how to run an Office 365 tenant? We have a few ideas in the Office 365 for IT Pros eBook…

New Version of IOS to Allow Users to Choose Default Mail App and Browser

Apple’s annual worldwide developer conference (WWDC) normally generates a lot of press coverage for new iOS features. Buried among the announcement of features due to be included in iOS 14 is:

Set default email and browser apps

Set a default web browser and email app that launch when you click a link or want to compose a new mail message.

In other words, instead of being forced to use the iOS mail app, you’ll be able to swap in Outlook for iOS and use it as the default mail app. This is excellent news for legions of users who have chosen Outlook mobile because it is easily the best iOS email client for Exchange Online. I’m sure the Google people will be pleased to use the Gmail app for iOS, unless they use Outlook for iOS to connect to Gmail.

In its defence, the iOS mail client supports modern authentication, which is good because Microsoft will soon eliminate basic auth connections to Exchange Online mailboxes using ActiveSync, and it’s better at dealing with multiple accounts in different tenants. Aside from those points, there’s no good reason to use a client that’s handicapped by its dependency on the limited functionality available through the venerable Exchange ActiveSync protocol. Features like delegate access to mailboxes, support for shared mailboxes, adding sensitivity labels to messages, and making Teams meetings the norm are in Outlook mobile but not in ActiveSync clients.

Number of Outlook Mobile Users

Microsoft hasn’t revealed the number of Outlook mobile users since it said that it was “more than 100 million users” in April 2019. At that time, Office 365 had 180 million monthly active users; a year later, the latest figure was 258 million (albeit paid seats, which are not the same). Given that, the number for Outlook users is likely around 120 million.

The split between Android and iOS is harder to call, but even if it’s 50-50, that’s still 60 million users who’ll be happy to use Outlook as the default mail app in iOS 14.

Choosing Edge

The same announcement covers the replacement of Safari as the default browser. I might try Edge if only to synchronize across devices, but the notion of swapping browsers isn’t as compelling as swapping email clients.

Read more about the features coming in iOS14.

Cloud Settings Roam from PC to PC

Following our coverage of roaming signatures for Outlook for Windows last month, Microsoft made the formal announcements that the feature is coming in Office 365 notification MC215017 on June 2. A separate notification (MC214927 – roadmap item 63037) dealt with the storage of its client settings in Exchange Online mailboxes belong to Office 365 accounts.

The two announcements are separated because of the need to accommodate third-party add-ins which deal with Outlook signatures. This means that if necessary, Outlook can use cloud storage for its settings without including signatures (if add-ins are used).

Store Client Settings in Mailboxes

The two announcements are linked in that this is part of a Microsoft project (long overdue in the eyes of some) to make it easier for Office 365 users to move between computers without the need to reconfigure Outlook for Windows. Roaming Outlook profiles aren’t new and OWA has stored its settings in mailboxes for a long time, so Outlook for Windows is a little late to this party.

Cloud storage or settings appeared last month and will gradually make its way through the various channels used to distribute updates for Microsoft 365 apps for enterprise (aka click to run, aka Office ProPlus. Figure 1 shows the setting to control cloud settings in Outlook version 2005 (build 12827.20268) updated from the current channel (preview) last Tuesday.

Outlook Settings Stored in Mailboxes

According to Microsoft, when cloud storage is used (it’s now the default), Outlook stores the settings from the following sections found in Outlook options:

Ribbon customizations and add-ins are not stored in the mailbox and I don’t think views are either. The language setting for Outlook is not stored because this usually depends on the language configured for Windows.

Slow and Steady

Office 365 is now nine years old and Office click-to-run first appeared in the 2013 generation of products. It’s taken Outlook for Windows a long time to take advantage of cloud storage for its settings, possibly because this issue has never been a high priority for the development group. Given the focus on mobile apps, it’s curious that Microsoft would move to deliver the feature for PCs now, but late is better than never.

In any case, it’s good that both roaming signatures and other cloud settings are now safely stored in mailboxes.

The Office 365 for IT Pros eBook includes a chapter about handling client updates. It’s work that we suspect few really like, but it needs to be done.

Signature Management is Complex (and Delayed)

Updated December 16, 2021: According to Message center notification MC305463 (December 15), roaming signatures for Outlook for Windows have “been delayed while we work on further stabilization.” In other words, some bugs are present that Microsoft must squash before shipping the feature. Microsoft doesn’t give a new date when they expect this work to be done.

According to the roadmap item, the current roll-out date is predicted to be October 2022.

Companies often want to impose corporate branding and a common style to the email signatures applied by email clients to outbound messages. Managing signatures and making sure that the right signature is applied can be complicated, which is why so many companies like CodeTwo Software, Crossware, and Exclaimer develop and sell email signature management software.

The difficulties of dealing with Outlook for Windows signatures is described in a post explaining how to build and apply a HTML signature with PowerShell. Updating the system registry is often complicated and Outlook doesn’t make it easy. By comparison, updating the signatures used by OWA with PowerShell is more straightforward.

Roaming Signatures for Outlook Click to Run

One of the reasons why Outlook signatures cause management challenges is the need to update signatures on individual PCs. Microsoft is making things easier by introducing roaming signatures for Outlook. In other words, you can create a signature on a PC and that signature will be available on any PC you sign into. For now, the feature won’t work for Outlook for Mac and OWA will continue to use its own signatures, but you couldn’t rule out a plan that would see the same roaming signatures being used across all Outlook clients.

To make this arrangement work, the signature information is stored in Exchange Online user mailboxes and retrieved by the click-to-run version of Outlook (part of the Microsoft 365 enterprise desktop apps). In other words, the feature isn’t available on-premises because Exchange Server doesn’t store signatures in its mailboxes. Outlook 2016 and Outlook 2019 will continue to use the system registry to store signature settings (the RTF files containing the signatures are in the file system).

Signatures that aren’t associated with an Office 365 account won’t roam because they can’t be matched with an Exchange Online mailbox. These signatures, which might belong to people who use Outlook with non-Exchange servers, remain in place and available.

Synchronizing Signatures to Exchange Online

According to Microsoft 365 roadmap item 60371, Microsoft expects that roaming signatures will be available in June 2020. If all goes well, the June 2020 update for Outlook (monthly channel) will be the first version to support roaming signatures. After you install the update, Outlook will read existing signature information from the system registry and write it into the mailbox. The current setup of signature information in the system registry and signature files on disk remains to support offline working. Outlook on other PCs will pick up the updated signature the next time the user signs in.

Microsoft says that third-party add-ins will have to disable roaming signatures to continue to work. In the future, Microsoft expects to deliver an API to allow add-ins to work with roaming signatures.

Outlook doesn’t block users from updating signatures through its Options (Figure 2). Subsequent changes to the signature made in Outlook will be synchronized with Exchange Online. Each time Outlook starts, the client checks if the signature in the mailbox is newer than its copy and downloads the information if needed.

Disabling Roaming Signatures

It’s possible that an organization doesn’t want Outlook to use roaming signatures. In this scenario, you can disable the feature on individual workstations by updating this DWORD value in the registry:

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Setup\DisableRoamingSignaturesTemporaryToggle

Set the value to 1 to disable roaming signatures. If the value doesn’t exist or is set to 0, Outlook uses roaming signatures. Microsoft views the registry value as a holding measure until they do the work to allow third-party add-ins to interact more gracefully with roaming signatures. When that API is delivered, you can expect Microsoft to deprecate this setting.

ISV Reaction to Roaming Outlook Signatures

As expected, ISVs specializing in email signature software are wary about Microsoft’s announcement. If you’re interested in seeing how ISVs have reacted and the positioning of the features available in their products, you can read this assessment by CodeTwo Software. The case being advanced is what you’d expect: roaming signatures are only one part of a big piece of work needed to manage corporate signatures.

Welcome Change

Roaming signatures is a welcome update that people have wanted for a very long time. I doubt that the advent of the feature will affect the ISV market for email signature management products because the process of making sure that the right signature is used by the right person is more complicated than copying signatures between PCs. Corporate branding matters!

Need more information about using PowerShell to manage client settings? Look no further than the Office 365 for IT Pros eBook. We have a ton of information to offer on this topic.

Personal and Channel Meetings

Updated 8 September 2023

Microsoft refreshed the Teams Calendar app last year and introduced a new scheduling experience in early 2020. Both were good steps forward to giving Teams users the tools to manage Teams meetings effectively. At least, if you know what you’re scheduling and who can join a meeting, and who should receive the Teams meeting invitations.

Two kinds of scheduled Teams meetings exist and each behaves differently when generating meeting notifications.

• An online Outlook meeting (personal meeting).
• A Teams channel meeting.

Let’s discuss the differences between the two types.

Update May 15 2020: In Office 365 Notification MC213330, Microsoft announced that the attendee picker used by the Teams calendar app now includes Exchange Online distribution groups and Microsoft 365 Groups. In other words, you can add these recipients to meetings scheduled in Teams in the same way as you can in Outlook.

Personal Online Meetings

An personal (or private) Teams meeting is created by an individual user in Outlook or in the Teams meeting app. The person who creates the meeting is the organizer and the meeting is created in the calendar in their mailbox. Online meetings created in Outlook use an add-on (like the Teams Meeting add-in) to associate the meeting with a Teams online meeting space and populate several properties of the meeting with details of how participants connect to the online platform when the event happens.

Figure 1 shows how a Teams meeting is created in Outlook. You can see the link to the online meeting that’s inserted by the New Teams Meeting add-on in the body of the notification sent to meeting attendees.

Remember that Outlook only loads the add-on when you’re signed into your home Teams tenant when Outlook starts. If you’re signed in as a guest to another tenant, Outlook won’t load the add-in because it can’t create meetings in that tenant.

Teams Meeting Invitations for an Outlook Meeting

Notifications for an online Outlook meeting go from the organizer’s mailbox to the email addresses of the participants added to the meeting. Usually, these are the only people who join a meeting. Of course, if someone forwards the meeting notification to another person, that person can attend too.

When you create a meeting the Teams calendar app and don’t specify the name of a channel to meet in, it’s the same as creating an online meeting in Outlook. Only the people specified as attendees receive notifications. Teams creates the meeting in the organizer’s mailbox and sends the notifications to attendees from there. It doesn’t matter whether you create an online meeting in Outlook or Teams: the outcome is identical.

In other words, online meetings in Outlook or Teams which are not associated with a channel are personal and no-one except the organizer and the attendees know about the meeting.

Teams Meeting Invitations for Channel Meetings

Teams channel meetings are scheduled using the Teams calendar app or the channel calendar app. When a meeting is scheduled in a channel, it’s no longer a personal meeting. Instead, the meeting “belongs” to the team hosting the channel and the meeting is created in the calendar in the group mailbox for the team and the team is the organizer. In effect, you’re not creating a meeting for nominated individuals to attend. Instead, you’re creating a location (the channel) and time for a meeting to occur and allowing any team member to attend.

Figure 2 shows the creation of a channel meeting. Note that two attendees are explicitly added to the meeting. We’ll come back to this later.

Differences in The Creation of Teams Meeting Invitations

The big difference between personal and channel meetings is who receives invitations for the meeting. A meeting created in the channel doesn’t have anyone to notify because the channel is not a person, nor does it have a mailbox or calendar. The meeting takes place in the channel at the appointed time. When the meeting is on, any team member can join it if they want. Figure 3 shows the visual signal for a channel where a meeting is happening. Team members who want to join open the channel and select Join.

There’s nothing to stop team members creating appointments in their calendar to remind them when an important channel meeting is due. In fact, it’s a good idea to do so. As explained in this post, it’s possible to change the settings of the group to make sure that some or all of the team members receive meeting invitations. This isn’t something that a regular team owner will do as it requires some knowledge of PowerShell, but it’s easy enough for an administrator to do.

You can’t change the channel a meeting is created in after the meeting is sent. If you need to change location, the organizer must remove the original meeting and recreate it in the right channel.

Meet Now

Meet Now meetings are impromptu gatherings in a channel. These are channel meetings without being scheduled in the team calendar. No notifications are sent for Meet Now meetings.

People Who Receive Notifications for Teams Channel Meetings

Remember from Figure 2 that two attendees are explicitly added as participants to the channel meeting? These are the only people who receive email notifications about the meeting. The notifications are like any other meeting notification and allow the recipient to decide if they will attend the meeting. If they accept the invitation to attend, the meeting is added to their calendar.

If distribution lists are added as meeting attendees (Figure 4), their membership is expanded to find the individual members and notifications are sent to those recipients to allow them to join the meeting. Remember that the membership of a distribution list can include other distribution lists, mail users, mail contacts, and even public folders. In other words, you might end up sending an invitation to many unexpected recipients.

Microsoft 365 Groups only support mailboxes and guests as members, but some restrictions apply. First, the group must be visible in the Exchange Online GAL; second, members must receive calendar (event) updates from the group. (this post goes into the settings to allow members to receive calendar updates in more details). Yammer can use Microsoft 365 Groups to manage the membership of Yammer communities, and the members of those groups might not use email and never see the invitation.

The two golden rules are:

• If you want to be sure that someone knows about a channel meeting, add them as a meeting participant. If you don’t, they still might attend the meeting, but only if they notice that the meeting is on in the channel when it’s in progress.
• Make sure you know who’s included in a Microsoft 365 group or distribution list before you add these objects to meeting invitations.

It is possible to enable all team members to receive invitations for channel meetings. If you do this, be aware that a) Microsoft might change how things work in the future and b) while some people like receiving invitations to channel meetings, others consider these invitations to be a waste of time.

Update: See this article for more information about the generation of meeting invitations for Teams channel meetings and why sometimes everyone in a team receives an invitation. Also for details fo a technique to schedule meetings in shared and private channels.

Teams Meeting Invitations and Microsoft 365 Group Settings

We’ve covered the basics of who receives Teams meeting invitations for personal and channel meetings here. Because Teams is built on top of Microsoft 365 Groups, some group settings affect notifications. For example, you can add someone to the subscriber list for a group and they’ll receive notifications for channel meetings because the meeting “belongs” to the team/group.

Although these group settings exist, it’s best to leave well alone and not change them. Teams hides the groups it uses from Exchange clients to stop people updating notification settings and make sure that things operate as planned. It’s not good to have too many moving parts in play when trying to figure out how things work.

Detail is important. That’s why we take the time to understand how things really work inside Office 365. You can learn from what we do by subscribing to the Office 365 for IT Pros eBook. Thousands already do. Shouldn’t you?

Delegate Access and Mailbox Permissions Bring Us to Folder Permissions

Two recent posts about Outlook Mobile supporting delegate access to Exchange Online mailboxes and reporting mailbox permissions bring us to the topic of folder permissions. Outlook Mobile uses full access permission to access delegate mailboxes and the report captures this information. But Exchange Online has supported folder-level permissions for many years (here’s a 2006 blog based on Exchange 2003 SP2) and it’s common to find these permissions in use, especially with Outlook desktop.

Outlook Delegate Access

Folder-level permissions have been core to Outlook’s ability to satisfy the traditional manager-assistant work model where the assistant takes care of the manager’s inbox and calendar. This capability is still supported and documented today for Outlook ProPlus and Outlook 2019.

The option to assign delegate access to mailbox folders in Outlook ProPlus is in the backstage area (Figure 1). Alternatively, you can search for “delegates” and Outlook will find it for you.

Setting Outlook Delegate Permissions

Figure 2 shows delegates (left – none are listed because I’m in the process of assigning one) and folder permissions (right). In this case, I’ve selected a user to act as a delegate and chosen the permissions I wanted to assign. When ready, click OK to save the delegated permissions.

When someone assigns folder permissions to a delegate, Exchange Online creates and sends an automatic notification to the delegate to inform them that they can now open the folders (Figure 3).

The support article emphasizes that you should grant Folder visible permission on the root folder of the your mailbox to delegates. This is especially important if the delegate wants to access the delegated folders as shared folders in OWA. In Outlook, delegates should add the mailbox to their profile.

Steps to Script a Folder-Level Access Report

Just like it’s good advice to run a periodic check of mailbox permissions, it’s good to validate that everyone who is assigned permission over folders outside their own mailbox still need that permission. Exchange Online doesn’t come with a report to tell us what folder permissions are in place, so we need to do this with PowerShell.

The Get-MailboxPermission cmdlet fetches permissions for a mailbox. Its counterpart, Get-MailboxFolderPermission, does the same for a folder. Conceptually, the steps to create a report are straightforward:

• Find a set of mailboxes to check.
• Find the folders in each mailbox to check. Exchange Online mailboxes often hold hundreds of folders. We only need to check folders that are commonly delegated, like the Inbox, Sent Items, and Calendar.
• Fetch the permissions for each folder and extract delegated assignments to users who aren’t the mailbox owner.
• Report any delegated access to the selected folders.

You could use the Get-Mailbox, Get-MailboxFolderStatistics, and Get-MailboxFolderPermission cmdlets to create the report. To be a little different, I used the new REST cmdlets because an equivalent is available for each of the three cmdlets listed above (Get-ExoMailbox, Get-ExoMailboxFolderStatistics, and Get-ExoMailboxFolderPermission).

Differences in REST Cmdlets

Using the REST cmdlets means that things run faster, especially when you’re dealing with hundreds or thousands of mailboxes. This is important, especially when the cmdlets are all quite demanding in terms of system resources.

It’s also true that the Exchange Online Management module (which holds these cmdlets) is easier to use with modern authentication, which helps the transition away from basic authentication. Remote PowerShell will no longer support basic auth connections after October 13, 2020.

The downside is that sometimes the REST cmdlets return data in different formats to their Remote PowerShell counterparts. For example, after retrieving permissions for a folder with Get-MailboxFolderPermission, you might want to fetch the name of the delegated user. If the variable $Permission holds the retrieved permission, the name of the user is available as $Permission.User.DisplayName, but it’s $Permission.User with Get-ExoMailboxPermission. It’s the detail that counts when you move from one set of cmdlets to another!

CSV Output

You can grab a copy of the script from GitHub. Its output is a CSV file (Figure 4) that might reveal some interesting delegations. For instance, I found an entry for a user (Michael Harty) that no longer exists in my tenant.

Outlook Mobile to Support Folder-Level Permissions

Microsoft says that Outlook Mobile will support folder-level permissions in the future to remove the need to grant complete access to everything in a delegate mailbox. This is a good step forward that will be welcome by those who don’t really want to expose everything they have just to let someone else manage part of their email.

Using PowerShell like this proves that it’s a great skill for any Office 365 administrator to have. You can find out a lot more about using PowerShell to manage Office 365 in the Office 365 for IT Pros eBook. Join our happy band of subscribers today!

How to Roll Your Own Outlook Signature with PowerShell

After finishing my article about Microsoft developing cloud signatures for Outlook, I decided to look at what’s involved with updating an Outlook signature with PowerShell. As it turns out, there’s quite a few methods suggested in various blogs and articles, mostly on the theme of how to use information from Active Directory into signatures (here’s an example).

Most of the scripts I met were old and suffered from one problem or another, like failing to support Office ProPlus (click to run) or not using Azure Active Directory. So I decided to explore the topic by putting together my own version.

Outlook and the System Registry

As noted in my other article, Outlook for Windows stores information about its settings in the system registry. The first issue was to find out from the registry which Azure Active Directory account is used with Outlook. My solution is to fetch the accounts information and parse out the user principal name. I then use the user principal name to fetch account properties from Azure Active Directory:

$UserAccount = Get-ItemProperty -Path HKCU:\Software\Microsoft\Office\Outlook\Settings -Name Accounts | Select -ExpandProperty Accounts
$UserId = (ConvertFrom-Json $UserAccount).UserUpn[0]
# Retrieve the properties of the user from Azure Active Directory
$UserProperties = Get-AzureADUser -ObjectId $UserId

Outlook Profiles

Outlook can have multiple profiles on a PC. Each profile has its own settings, including signatures. The default profile name is Outlook, and it’s the one that you’ll probably encounter most often (based on a limited test). But you can have more profiles and then must get into the business of figuring out how to update which profile with which signature. Given I was doing this on a wet Sunday afternoon, I decided to cheat by:

• Fetching the profile information from the registry.
• If only one was found, set things up to update the signature information for that profile.
• If more than one profile exists, update the common settings for Outlook. This means that users can’t update signatures themselves, but it was an OK workaround given limited time.

# Find Outlook Profiles in registry
$CommonSettings = $False
$Profiles = (Get-ChildItem HKCU:\Software\Microsoft\Office\16.0\Outlook\Profiles).PSChildName
# This script can only deal with a single (default profile); more code needed to handle multiple profiles
If ($Profiles -eq $Null -or $Profiles.Count -ne 1) {
   Write-Host "Warning - Applying signature to all Outlook profiles" 
   $OutlookProfilePath = "HKCU:\Software\Microsoft\\Office\16.0\Common\MailSettings"
   $CommonSettings = $True}
Else { # Path to default profile is elsewhere in the registry
   $OutLookProfilePath = "HKCU:\Software\Microsoft\Office\16.0\Outlook\Profiles\" + $Profiles.Trim() + "\9375CFF0413111d3B88A00104B2A6676\00000001" }

Sometimes the path to the user profile in the registry ends with 00000002 (the first might point to the Outlook address book), so your code should be prepared to handle this situation.

Generating the Signature File

Now that I know where in the registry to update, we can proceed to generate the signature file. This is usually an RTF file written to %appdata%\Microsoft\Signatures (English language PCs). A HTML file is also acceptable. Many scripts call Word as a COM object to create or update a signature file. I looked at using the impressive PSWriteWord module (available in the PowerShell gallery) to do the job with code like this:

Import-Module PSWriteWord
$WordDocument = New-WordDocument $FilePath

Set-WordTextFontFamily
$Line = $Null
Add-WordText -WordDocument $WordDocument -Text $Line
$Line = $UserProperties.DisplayName 
Add-WordText -WordDocument $WordDocument -Text $Line -Bold $True -FontSize 12 -FontFamily "Segoe UI"
$Line = $UserProperties.Title
Add-WordText -WordDocument $WordDocument -Text $Line -FontSize 12 -FontFamily "Segoe UI"
$Line = "Email: " +$UserProperties.WindowsEmailAddress
Add-WordText -WordDocument $WordDocument -Text $Line -FontSize 10 -FontFamily "Segoe UI"
$Line = "Telephone: " + $UserProperties.Phone + " Mobile: " + $UserProperties.MobilePhone
Add-WordText -WordDocument $WordDocument -Text $Line -FontSize 10 -FontFamily "Segoe UI"
$Line = $UserProperties.StreetAddress
Add-WordText -WordDocument $WordDocument -Text $Line -FontSize 10 -FontFamily "Segoe UI"
$Line = $UserProperties.StateOrProvince
Add-WordText -WordDocument $WordDocument -Text $Line -FontSize 10 -FontFamily "Segoe UI"
$Line = $UserProperties.PostalCode
Add-WordText -WordDocument $WordDocument -Text $Line -FontSize 10 -FontFamily "Segoe UI"

### Save document
Save-WordDocument $WordDocument -Language 'en-US' 

It’s easy to generate a Word DOCX file. You still must convert the signature file to RTF, which can be done using a Word COM instance, but I ran into some problems when calling Word, apparently due to failure to load a DLL.

$WordDocument = $WordApplication.Documents.Open($FilePath)                           
You cannot call a method on a null-valued expression.
At line:1 char:1
+ $WordDocument = $WordApplication.Documents.Open($FilePath)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : InvokeMethodOnNull

HTML Works for Me

Not wanting to reinstall Office, I went back to my old backstop of creating formatted HTML text. To get a head start, I used the free email signature generator tool from Code Two Software to get some ideas of what should be in the signature and what the necessary HTML would look like. The code to build the HTML and write out the signature file is:

# Construct a signature file in HTML format using the information fetched from Azure Active Directory
$CompanyLogo      = "https://i1.wp.com/office365itpros.com/wp-content/uploads/2020/02/2020EditionVerySmall.jpg"
$HeadingLine      = "<title>Signature</title><br>"
$ImageLine        = ""
$PersonLine       = "'
$EndLine          = "<table style="`&quot;FONT-SIZE:" 8pt;="" color:="" gray;="" font-family:="" `'segoe="" ui`'="" `"=""> <tbody><tr><td><img src="&quot; + $CompanyLogo + &quot;" border="0"></td><td padding="0"><b>" + $UserProperties.DisplayName + " </b> " + $JobTitle + "<br>"
$CompanyLine      = "<b>" + $CompanyName + "</b> " + $StreetAddress + ", " + $City + ", " + $PostalCode + "<br>" + $UserProperties.TelephoneNumber + "/" + $UserProperties.Mobile + " Email: " + $UserProperties.Mail + "<br><br>"
# Facebook and Twitter icons
$IconsLine        = '</td></tr><tr><td style="font-size: 10pt; font-family: Arial, sans-serif; padding-bottom: 0px; padding-top: 5px; padding-left: 10px; vertical-align: bottom;" valign="bottom"><span><a href="https://www.facebook.com/Office365itpros/" target="_blank" rel="noopener noreferrer"><img border="0" width="23" alt="facebook icon" style="border:0; height:23px; width:23px" src="https://i0.wp.com/office365itpros.com/wp-content/uploads/2020/02/Facebook.png"></a> </span><span><a href="https://twitter.com/12Knocksinna" target="_blank" rel="noopener noreferrer"><img border="0" width="23" alt="twitter icon" style="border:0; height:23px; width:23px" src="https://i1.wp.com/office365itpros.com/wp-content/uploads/2020/02/Twitter.png"></a></span></td></tr></tbody></table><br><br>"

# Put everything together and output the HTML file
$SignatureHTML = $HeadingLine + $ImageLine + $PersonLine + $CompanyLine + $Iconsline + $EndLine | Out-File $HtmlPath

Updating the Registry

The final step is to update the registry with details of the new signature file. Here’s how I updated the settings (these settings mean that Outlook inserts the signature in new messages and replies/forwards):

# Update the registry settings where Outlook picks up its signature information
If (Test-Path $TargetForSignatures) {
   Get-Item -Path $OutlookProfilePath | New-Itemproperty -Name "New Signature" -value $SignatureName -Propertytype string -Force 
   Get-Item -Path $OutlookProfilePath | New-Itemproperty -Name "Reply-Forward Signature" -value $SignatureName -Propertytype string -Force }

The Final Signature

The resulting signature is pretty nice (Figure 1), and I am happy with it, even if the code to generate the signature is a bit kludgy. For this to work in production, you’d have to make sure that the script called the Connect-AzureAD cmdlet to connect to Azure Active Directory and add a pile of error checking and other essential pieces. It’s also important to underscore the importance of an accurate directory in this exercise. If your directory isn’t populated with up-to-date information about people, any signature which depends on that information won’t be successful. If you’re uncertain about the accuracy of your directory, maybe a visit to Hyperfish might be a good idea.

If you want to make the script better, you can grab a copy from GitHub. Make sure you let us know what you did to improve things by writing a comment to this post.

My wet afternoon’s coding taught me that the ISVs who build auto-signature products for Office 365 have a lot to cope with. And that Microsoft’s work to put Outlook signatures in the cloud can only be a good thing.

Making sure that users have the right signature is a mixture of client and mailbox management. The Office 365 for IT Pros eBook covers both topics in-depth and at length. You should subscribe!

Old Reply with IM Feature Works with Teams

The new Share to Teams and Share to Outlook features announced (still not generally available) by Microsoft have attracted a lot of attention, but Outlook’s Reply with IM feature seems to fly under the radar with little awareness (and no Microsoft documentation). Let’s try and redress the balance.

The idea is simple. You receive an email and instead of having endless rounds of to-and-fro replies, you take the conversation to an instant messaging platform that’s more suitable for an interactive debate. Reply with IM has been around since Outlook 2010. In those days, the IM connection was to Office Communications Server, duly replaced by Lync and then Skype for Business. Inside Office 365, depending on your configuration, Outlook ProPlus or OWA will connect to Skype for Business Online or Teams.

Reply with IM from Outlook

I used Office ProPlus Version 2002 to test Reply with IM. I doubt this feature will work with Outlook 2016 or 2019, and it seems like it didn’t work so well with earlier versions of Office ProPlus.

The Reply with IM option is found in the […] menu of Outlook’s read message window (Figure 1) or in the Respond section of the Outlook menu bar. Reply with IM launches a conversation with the sender while Reply All with IM includes all the recipients in the conversation.

Prerequisites

To use the feature with Teams, a user must be:

• Configured in TeamsOnly mode. The value of the registry key HKCU\Software\IM Providers\DefaultIMApp should be “Teams.” This value is set when you choose to register Teams as the chat app for Office in Teams settings (Figure 2).
• Signed into the Teams tenant where the users you want to chat with are homed. In other words, if you want to chat with someone in your home tenant, make sure that you sign in there.

Some Gotchas with Conversation Transfer

There are some details to remember when using Reply with IM:

• If an existing chat with the recipients exists, Teams will use that. Otherwise it creates a draft chat.
• Teams doesn’t take the message subject and use it to name the chat, even when a new chat is created. In fact, apart from the recipients, nothing is copied from the message into the chat, so you’ll have to cut and paste information from the message body into the chat to provide a context for the conversation.
• Federated chat (external access) isn’t supported by Reply with IM. If you use Reply All with IM and a guest user is among the message recipients, they are dropped from the conversation.
• If one of the message recipients is blocked for chats by Teams, you won’t be able to send messages to the chat.
• If you are signed in as a guest to a Teams tenant where an external recipient is homed, Reply with IM can launch a conversation with that person.
• Rather bizarrely, if a shared mailbox is in message recipients, Teams includes the shared mailbox in the chat (you can clean things up by removing the shared mailbox from the chat).
• If the message recipients contain a group, Teams drops the group when it starts the chat.

It seems like the Outlook developers might do a little work to smoothen the rough edges that Reply with IM sometimes exhibits when used with Teams, but that being said, this is a useful little-known feature that deserves more attention from users too.

It’s the detail that makes technology interesting. In this case, a feature that’s been around for a long time has a new lease of life because it bridges a gap between Teams and Outlook. Learn more in the Office 365 for IT Pros eBook, where there’s enough detail for anyone’s taste.

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.

MAPI Properties to Point to Intelligent Communications Services

Has it ever crossed your mind what differences exist between a regular meeting event scheduled in an Outlook calendar and a Teams meeting? I must admit to not caring too much about this topic until a senior Microsoft engineer said that the difference lies in the properties of the meeting event created by Outlook. Normal meetings have a set of properties such as the meeting time, time zone, and attendees. Online meetings have these properties too, but also have a set of Intelligent Communications Services properties that tell Outlook how to connect users to the online meeting.

Although the assertion was entirely logical (of course Outlook needs to know how to connect to an online meeting), my curiosity was piqued and I looked a little further.

Scheduling an Online Meeting with Outlook

The key to scheduling a teams meeting with Outlook is the Teams meeting add-in that the client automatically loads based on the user’s online configuration. If they use Skype for Business Online, Outlook loads the Skype for Business Online add-in; if it’s Teams, Outlook loads that add-in. Apart from adding a button to the calendar menu bar, the add-in serves one major purpose: when the user creates an online meeting, the add-in creates a meeting slot with the online meeting service and inserts the details of the meeting as a URI in the meeting body (Figure 1).

When the time of the Teams meeting rolls around, the user clicks the URI. The target online service responds by opening a web page to allow the user join the meeting. The services differ in how they handle the link. For instance, if the Teams desktop client is logged into the home tenant of the user who created the meeting, the meeting starts in the desktop client. On the other hand, if the user is logged in as a guest to another tenant, Teams offers the option of joining with the with the desktop client or by opening the browser client. The flow is slightly different in the mobile clients, but essentially the key is the URI because it contains the necessary information for the application to connect to the meeting. An example of a URI created for a Teams meeting scheduled through Outlook is:

https://teams.microsoft.com/l/meetup-join/19%3ameeting_MDY3ZjY0MjAtNTNmZS00NWVkLTk0Y2EtNzhjNTI5MmM5ZGUz%40thread.v2/0?context=%7b%22Tid%22%3a%22b662313f-14fc-43a2-9a7a-d2e27f4f3478%22%2c%22Oid%22%3a%22eff4cd58-1bb8-4899-94de-795f656b4a18%22%7d

As you’d expect, the same kind of URI is inserted into meetings created using the Teams calendar app.

Users can fetch the link to send to other people from the meeting properties through the Teams calendar app by selecting a meeting (Figure 2) or using right click to view meeting details (Figure 3).

Outlook Meeting Properties

Outlook stores the information identifying an event as an online Teams meeting as MAPI properties for an item in the Calendar folder of the mailboxes of meeting participants. You can see the properties with a utility like MFCMAPI, which reveals items like OnlineMeetingConfLink (Figure 4). This property contains the name of the meeting organizer among other information. According to Microsoft’s documentation, this is a Globally Routable User Agent URI (GRUU), or a SIP URI that can be used by a user agent (client) to connect to an online meeting. Because the description comes from the Microsoft Exchange ActiveSync protocol documentation, it’s probably a link designed for use by mobile clients that synchronize the calendar folder to a device.

Another interesting property is SkypeTeamsMeetingURI (Figure 5). This is the link that meeting participants use to join an online meeting. As the name suggests, the same property can be used by either Skype for Business Online or by Teams.

Other properties exist for online meetings that I don’t describe here. But the important point is that the difference between a regular meeting event created in an Outlook calendar and one that involves an online meeting are a set of properties holding information to allow clients to connect to the online service. Whether that quite counts as a connection to Intelligent Communication Services is another matter.

You might not need to know this kind of esoteric information right now, but there’s no doubt that filling in knowledge gaps around Office 365 apps makes it easier for people to understand how to work with the technology. Which is a great reason to subscribe to the Office 365 for IT Pros eBook and learn about stuff that might not be documented or explained elsewhere.