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

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 Phish 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 2024?

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.

Deploying Technology to 100-plus Million Users

After the note about the launch of shared mailbox and dark mode support for Outlook mobile appeared, several people commented that they had the latest client but couldn’t access the shared mailbox feature. This prompted me to have a conversation with Microsoft to find out how they deploy new features to what is now a very large (100+ million as of May 2019) installed base.

Outlook Mobile has both consumer and commercial (Office 365) users. Some features, like dark mode, are available to both sets while others, like shared mailboxes, are only available to commercial customers. The deployment mechanism needs to take account of these factors.

Random Selection During Roll-Out

When Microsoft releases a new Outlook mobile feature, they select a random percentage of the worldwide installed base as the initial roll-out target. For features like dark mode intended for use by any Outlook mobile user, the random selection is formed of individual commercial and consumer users. Commercial-targeted features like shared mailboxes begin deployment to a random selection of Office 365 tenants. If the selection is user-based, selected users can access the new feature immediately while others in the same tenant must wait until the roll-out reaches them. If the select is tenant-based, everyone in the selected tenants can access the new feature once the tenant is enabled.

Eventually the roll-out reaches 100% and everyone who has the latest version of the Outlook mobile app (iOS or Android) can access the new feature. The exact timing from start to finish of a roll-out varies across features and depends on factors such as bug reports or problems detected in the telemetry Microsoft gathers from Outlook clients.

No Control for Office 365 Tenants

Office 365 tenant administrators can’t influence the selection of their tenant or users within their tenant to receive new Outlook mobile features early. There’s no equivalent of the Targeted Release capability that exists for Office 365 features. There’s also no way for a tenant administrator to know who in the tenant might have been randomly selected to receive early access to a new feature. One way of looking at this is to say that random selection is fair to everyone; another is to say that Microsoft should give tenants some control over how new client technology is deployed to their users. On balance, it seems to me that Microsoft should provide some way to control deployment of commercial features, perhaps as a setting available through the Office 365 Admin Center.

There’s also no way to disable one or more Outlook Mobile features on a selective user-by-user basis. This might be useful for commercial features where some tenants don’t want people to use certain capabilities (like shared mailboxes) on mobile devices.

Testflight Makes a Difference

Those who sign up for the Outlook Insiders program and use the Testflight version of Outlook for iOS are not restricted by the random selection process and can use new features as Microsoft deploys them to Testflight. This can lead to an interesting situation where a tenant account can access a new feature through Testflight while another account in the same tenant can’t when using the production version of Outlook for iOS.

Need to know more about Outlook Mobile and other Office 365 clients? The Office 365 for IT Pros eBook covers this topic in some detail!

Shared Mailboxes for All, Dark Mode for Some

After much anticipation, shared mailbox support is now generally available for Outlook mobile. You need three things in place to be able to add shared mailboxes:

• A suitable version: Outlook for iOS version 3.37 or later or Outlook for Android 3.0.134 or later.
• Back-end support for the Microsoft synchronization technology (see this article to see how to check if Outlook is using the new sync).
• Your account is enabled for the feature. My contacts at Microsoft say that the roll-out of shared mailboxes is now past 50% of all Office 365 tenants after some pauses to fix bugs.

With the prerequisites in place, you can add shared mailboxes as easily as adding any other mailbox. According to the Office 365 Roadmap, support for delegate access to mailboxes in Outlook Mobile is coming too (Q1 CY2020).

Outlook Mobile Goes Dark

In other news, Office 365 notification MC189044 (August 28) announces that dark mode is starting to roll out for Outlook Mobile. Version 4.1 of Outlook for iOS is now available to Outlook Insiders who can download beta versions through the Testflight app. Support for dark mode (Figure 1) brings Outlook mobile up to speed with its desktop and browser counterparts. Even after using the new software for just a few days, I like dark mode much more on mobile than I do on other platforms. It just seems more natural to use a darkened mobile app.

To throw some light into what Microsoft is doing (no pun intended), Jon Friedman, head of Office design, posted an article to explain the design principles in dark mode. This article tells us that Outlook will be able to manage dark mode automatically based on user preferences when iOS 13 and Android Q are available.

[Update September 9: A tweet by Michael Palermiti, head of product for Outlook, says that dark mode is now 100% deployed]

Enabling Dark Mode

To set dark mode in Outlook for iOS, go to preferences and select the option (Figure 2). You need to restart Outlook to make dark mode effective (I had to restart iOS, but I believe this is usually unnecessary).

When Your Client Can Go Dark

According to the Office 365 Roadmap, the planned release for dark mode is September 2019 for both iOS and Android. In the run-up to general availability, apparently Microsoft has enabled dark mode for a select group of non-Testflight users who run the most recently released client software. Roughly 10% of users are in this category, so if your device has version 4.0 of the iOS client or version 3.0.137 of the Android client, you might be able to select dark mode now. Have a look!

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

Filtered Email Views for Your Most Important Contacts

Over the years, Microsoft has made many attempts to help people access Inbox contents more intelligently, mostly by applying views to isolate and highlight important messages. The Clutter feature appeared in 2014 only to be replaced by the Focused Inbox in 2016. Now we have Outlook People Favorites.

Favorites have been around for years. Folder favorites give fast access to the most important parts of a user’s mailbox while favorite categories allow users to find messages tagged in particular categories. Outlook does this by creating a view within the mailbox to find all messages in the selected category. People favorites are like categories in that when you add someone (an email address) as a favorite, Outlook creates a view to find all messages from that person. It’s as simple as that.

Creating and Managing People Favorites

People favorites are designed to give quick and simple access to messages from those who are important to you, like your direct manager or critical customers. To mark someone as a people favorite, use OWA to select a message where they are a recipient or sender and click their email address to expose their people card. In Figure 1, I’ve selected David Los, who works on OWA (seems appropriate). To make David one of my people favorites, I clicked the star beside his name in the people card.

You can manage the set of people favorites through OWA’s People section. People and Groups are managed together (Figure 2). Favorite categories are managed through OWA options. To remove someone from the set of people favorites, deselect the star opposite their name.

Behind the scenes, Exchange Online creates a folder in the non-IPM section of the mailbox to hold pointers to items relating to the favorite. The folder is stored under the FavoritePersonas root. We can see details of the folders by running these PowerShell commands:

$Folders = Get-ExoMailboxFolderStatistics -id mailboxi-id -FolderScope nonipm -IncludeOldestAndNewestItems | Select Name, Itemsinfolder, NewestItemReceivedDate, FolderPath
$Folders | ?{$_.FolderPath -Like "*FavoritePersonas*"}|  sort  {$_.NewestItemReceivedDate -as [datetime]} -desc | Format-Table ItemsInFolder, Name

ItemsInFolder Name                                                   NewestItemReceivedDate
------------- ----                                                   ----------------------
          209 James Redmond_b4b30d32-ba9a-4d9b-ad76-7bdb3b6b6c51     09/12/2019 15:20
          222 Thomas Bowers_6701c170-5c66-4ded-ac00-5e083d2ab648     03/12/2019 14:33
           37 Mary-Jo Smith_589ac9ce-da38-45e2-b2b4-24950fb1c270     05/12/2019 09:55
           59 Brad Jones_9607102f-465a-48d9-846b-a3dd7cb9cdb8        01/11/2019 11:00
           40 David Los_078e789e-fa0a-4e98-bb83-ca81ff9a54ca         07/11/2019 23:15
            0 Steven Phillips_9a81d5c0-055e-400e-a0cb-9b43e21c93e7

The items in the persona folders are not updated in real-time. Instead, a background mailbox assistant processes the mailbox to find matching items and creates items for display when the favorite is accessed. The items in the favorite folder might therefore be a little behind. The folder listed above with zero items is just added and hasn’t yet been processed by the assistant.

Using People Favorites

People favorites show up in the set of resources available to OWA users, just like favorite folders and categories. In Figure 3, you can see that my favorites include some categories, groups, and people. Because Exchange Online generates views for favorites, we see unread counts for groups and people where unread messages exist in the mailbox. Selecting a people favorite displays the messages from that person inside the mailbox.

Mobile People Favorites

OWA boasts the most complete implementation but the favorites also appear in Outlook mobile. Figure 4 shows how people favorites appear in Outlook for iOS. You can also create new people favorites in Outlook mobile, but although the favorite is created I have found that Exchange Online sometimes doesn’t generate the view, so when you select the favorite created in Outlook mobile, you see no messages.

Outlook mobile clients don’t use the hidden mailbox folders to reveal items for about people favorites. Instead, these clients search the mailbox and synchronize items on an on-demand basis, an implementation which is more in line with the synchronization model used to update folders for other Outlook mobile resources.

No People Favorites for Outlook Desktop

Outlook desktop doesn’t support people favorites. This isn’t surprising. The Outlook desktop UI is notoriously difficult to change, which is why features that need UI updates invariably appear in OWA and Outlook mobile first.

Need help to keep track of changes in Office 365? It can be really hard to track small but important changes in client user interfaces, which is why Office 365 for IT Pros can help. We’ve been tracking changes like this for six years and are pretty good at it by now.

Click-to-Run Version of Outlook Supports Office Black Theme

Office 365 notification MC187963 (roadmap item 49924) brings us news that the click-to-run version of Outlook desktop (aka Outlook for Office 365) joins the rest of the Office suite in supporting the “Black Theme,” which is how you get Office displayed in dark mode. The notification says: “We’ll be rolling this out to Monthly Channel (Targeted) customers in the coming days. The rollout is expected to be complete and available to all Monthly Channel customers with Version 1908. “

Support for black/dark mode was added to OWA in January 2019 and appeared in Office 2016 in 2018. It just takes longer to make UI changes in Outlook.

Selecting Black Mode

The latest updates installed version 1908 (build 11929.20114) on my PC, so I opened Outlook options to select the Black theme (Figure 1). You can also go to the backstage area (where information about your Office 365 account and updates are displayed) and select the theme there.

Using dark mode on screens has become popular for apps recently. White text on a dark background was the default in the old days of character-cell video terminals and black on white only became prevalent after the introduction of Windows and other GUIs in the 1990s, all of which goes to prove how trends can return in the IT industry.

The case for dark mode is supposedly that it is easier on the eye, but some articles debate this assertion. In any case, choosing to go dark is a personal preference. And after twenty or so odd years of using Outlook in “white mode,” I’m still uncertain if I like the darkened version of Outlook (Figure 2). Right now, my personal preference is the Office Colorful theme.

Turning the Lights On to Read

Some people like to distinguish or highlight the contents of the message pane. Outlook offers the option to switch the message pane between dark (moon) and light (sun). In Figure 3 you can see how the text appears when the message pane is in light mode and the remainder of Outlook uses the dark background.

This switch is for individual messages. Once you’ve established a preference for dark/light reading, you can check the “Never change the message background color” setting in Outlook Options to force the client to use the same color for all messages.

Remember that selecting an Office theme applies the same theme to all the Office apps. You can’t use the Black theme with Outlook and another theme with Word, PowerPoint, and Excel.

Need more information about managing Office 365 clients? Try reading the sage and wise commentary in the Office 365 for IT Pros eBook. You never know what you might discover!

Sometimes Called Exchange Fast Access

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

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

Why Disable Outlook Hybrid Mode

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

Controlling Local Caching

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

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

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

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

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

Office 365 Admins and Users can Report Spam and Phishing

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

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

Two methods are available:

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

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

Administrator Submissions for EOP Processing

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

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

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

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

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

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

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

How Outlook 2003 Changed the World of Email Clients

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

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

The Slight Problem of Shared Folders

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

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

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

A New Approach

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

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

Changes Available Now

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

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

No New for Other Outlook Versions

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

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

Connecting Internet Client Protocols to Exchange Online

Most people I know who use Office 365 for email use a mixture of Outlook clients (desktop, browser, or mobile). These clients use Microsoft and internet protocols to connect to Exchange Online (MAPI over HTTP, Exchange Web Services, Outlook mobile synchronization), and Microsoft takes care to make sure that clients and server connect together smoothly.

Some prefer not to use a Microsoft client and prefer software based on internet standards, or choose to look for a non-Outlook client because their Office 365 license doesn’t include Office, or they prefer the simplicity of a client that purely concentrates on email. Often, this means looking for a client based on IMAP4 or POP3 for mail access and SMTP to send messages. The basic difference is that IMAP4 stores messages on a server while POP3 downloads them to the client and removes them from the server. POP3 is the older protocol and is now pretty antiquated. IMAP4 also dates back to the early days of the Internet but has been upgraded many times since, so it’s the more preferable protocol if you go down this road.

Exchange Online supports both the IMAP4 and POP3 protocols and the connection settings for Office 365 are available online. Some clients are able to configure settings automatically, while others take a little more effort to make sure that the right ports and encryption are used.

A wide range of IMAP4 and POP3 clients are available, including Thunderbird by Mozilla, which has been around for a long time and supports Windows, Mac, and Linux, and the eM client (for Windows and Mac), my current favorite (Figure 1). Although the protocols might limit some of the functionality available to clients (there’s no trace of the Focused Inbox, for instance), a client like eM is still feature-rich and more than meets the needs of someone who just wants to process some email.

Configuring IMAP4 Access

By default, the mailboxes for new Office 365 accounts are not enabled for IMAP4 or POP3 access. Before an account can connect, an administrator must enable access by editing the mailbox properties through the Exchange Administration Center (Figure 2) or by running the Set-CASMailbox cmdlet. The reason why this cmdlet is used instead of Set-Mailbox is that Exchange moved control of protocol-related settings to a separate cmdlet when the Client Access Server role was introduced in Exchange 2007. That server role is integrated in the main server in modern versions, but the separation between protocol and other mailbox settings still exists.

For example, this command enabled the Kim Akers mailbox for IMAP4:

Set-CASMailbox -Identity Kim.Akers -IMAPEnabled $True

When the account is enabled for IMAP4, Exchange sets some default values for the properties that control IMAP4 access, which we can see with the Get-CASMailbox cmdlet:

Get-CASMailbox -Identity Kim.Akers | Format-Table IMAP*

ImapEnabled                             : True
ImapUseProtocolDefaults                 : True
ImapMessagesRetrievalMimeFormat         : BestBodyFormat  
ImapEnableExactRFC822Size               : False
ImapSuppressReadReceipt                 : False
ImapForceICalForCalendarRetrievalOption : False

Handling Calendars

In most cases, these settings don’t need adjustment. However, if you have clients that can handle iCalendar format meeting notifications, you might want to set the ImapForceICalForCalendarRetrievalOption to $True so that clients receive meeting notifications in iCAL format instead of a link that forces them to open OWA to process the request. OWA settings include an option to allow a user to opt for iCalendar (Figure 3 – the options only appear if the mailbox is enabled for POP3 or IMAP4).

Some reports in the past say that when this option is taken OWA sets ImapForceICalForCalendarRetrievalOption correctly, it doesn’t updateImapUseProtocolDefaults to $False, which is needed to make the option work correctly. Checking this over the last day or so shows that everything happens as expected.

PowerShell to Set IMAP4 Options

But if you want to be sure that your IMAP4 or POP3 settings are correct, we can handle the situation through PowerShell. One approach is to look for any mailbox enabled for IMAP4 and set the iCalendar option correctly on the basis that most IMAP4 clients use iCAL today. Here’s a quick and dirty script to do the job.

$Mbx = (Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox)
ForEach ($M in $MBX) {
     If ((Get-CASMailbox -Identity $M.Alias).ImapEnabled -eq $True) {
       Write-Host "Processing" $M.DisplayName
       Set-CASMailbox -Identity $M.Alias -ImapUseProtocolDefaults $False -ImapForceICalForCalendarRetrievalOption $True
       Start-Sleep -m 200 }
}

The code fetches a list of user mailboxes and then steps through each to find IMAP4-enabled mailboxes before setting the right values for the control properties. The same approach can be taken to adjust the properties controlling POP3 access.

It’s a good idea to check how many accounts are enabled for these older protocols and limit access to the accounts that really need to use IMAP4 or POP3 and to make sure that mailbox properties are set as expected when the protocols are enabled. It’s the kind of good housekeeping that an admin should do, if only time was available.

For more information about Exchange Online clients and how to configure settings for POP3 and IMAP4, see Chapter 10 of the Office 365 for IT Pros eBook.

Feature Supported in Both Outlook for iOS and Android

Being able to schedule Teams (and Skype for Business) meetings has always been a popular feature in Outlook desktop and OWA. The feature is now supported in the latest builds of Outlook for iOS and Android and turned up in my client this week when I installed build 3.21.0. The feature was originally announced in Message Center update MC173895 on 20 February, and the roll-out was due to start at the beginning of April, so it’s a little delayed.

Outlook mobile and Teams are both on a roll recently. According to data released with Microsoft’s Q3 FY19 earnings, Outlook mobile is used by more than 100 million people. A reasonable proportion of that set are likely found in the more than 500,000 organizations using Teams. Bringing the two apps closer together adds a lot of value, especially in a mobile-first world.

Skype for Business Online Co-Existence Setting is Important

MC175147 issued on March 2 describes how the Skype for Business Online co-existence setting for the tenant affects if Outlook mobile offers the ability to schedule Teams or Skype for Business Online meetings. if the co-existence mode is set to be “Teams Only” or “Skype for Business” with Teams Collaboration and Meetings, you’ll see the option to schedule Teams meetings.

No Tenant Dependency

Unlike Outlook desktop, the Teams client on your mobile doesn’t have to be connected to your home tenant to be able to create a meeting. Outlook mobile can happily create a meeting in your home tenant while the Teams client is connected to a guest account in another Office 365 tenant.

Exploiting the New Outlook Synchronization Technology

Being able to schedule Teams meetings is not dependent on the new Outlook connection/synchronization architecture. My client still connects to Office 365 using the older REST-based synchronization (my Outlook.com account uses the new technology). Given that Outlook.com and Exchange Online share the same infrastructure, it might seem odd that business accounts persist with the older synchronization when a consumer account benefits from the change, especially when some features (like one-click join of Teams meetings from Outlook mobile described in MC175147) depend on clients using the new technology.

Ross Smith IV of Microsoft explained the situation on 12 March in a response posted in the Microsoft Technical Community saying ” For Outlook mobile, major feature deployment operates with a staggered rollout where we begin with consumer accounts (if applicable) and then deploy to commercial accounts like Office 365. Our primary focus for commercial accounts was moving Government Community Cloud. Now that’s complete, we’ll be focusing on the remaining Office 365 tenants.”

You can discover what synchronization is used by Outlook by looking at the properties of an account. If you see “Microsoft Sync Technology” (as circled in Figure 2), you know that Outlook connects using the new architecture.

Like everything else inside Office 365, it’s likely that the deployment of the new Outlook connection architecture varies from datacenter region to region and even from country to country. I’ll look forward to seeing the new synchronization

We cover Outlook mobile among other Office 365 clients in Chapter 10 of the Office 365 for IT Pros eBook.

Introducing a Camera to Outlook Mobile for iOS

According to Microsoft’s Q3 FY19 results, Outlook Mobile is now used by over 100 million users. The iOS app gets even better with Version 3.21.0 with the integration of Microsoft’s Office Lens technology to give users the chance to take and include photos in messages. This is Office 365 roadmap feature 34352.

It’s not just a case of including camera capture capability. Office Lens, which began life as a Microsoft Research project, is turning up in multiple Microsoft iOS apps. Outlook, OneNote, and soon (or so we hear), Teams. The big selling point for Office Lens is its ability to sharpen and clarify captures of documents and whiteboards.The standalone app can then save the resulting capture in a PDF, PowerPoint, Word, OneNote, or an image file.

Using Office Lens to Capture Photos

The new capability shows up as a new camera icon in Outlook’s create message screen (Figure 1).

Clicking the icon brings you to Office Lens to capture the image you want to include in the message. Once you’re finishing capturing and editing the photo and exit Office Lens, the image is copied automatically into the message (Figure 2). It’s all very easy and natural.

This is a super-useful feature that I’m sure will be very popular with Outlook mobile users. I don’t have an Android phone to test and I couldn’t find a similar feature listed on the Office 365 roadmap (Office Lens is available for Android), so maybe there’s some added complexity that needs to be solved before the same feature appears in Outlook for Android.

Clients are covered in Chapter 10 of the Office 365 for IT Pros eBook. We like the Office Lens technology, but we don’t get down to that level of detail in the book, which is why it’s here.

Teams and Deep Links

Unless you’re a programmer, you might not be aware of deep links and how Teams uses these special form of URLs to navigate to find information. Deep links are used extensively within the client. For example, if you use the Get link to team option, you’ll get a URL like:

https://teams.microsoft.com/l/team/19%3a3380a323d4114b3193cd0ae15ef116b1%40thread.skype/conversations?groupId=e141d2a4-a14c-4865-928e-31f13397d9de&tenantId=a662313f-14fc-43a2-9a7a-d2e27f4f3478

The link means nothing to humans, but Teams finds it terrifically interesting as it can use the information to navigate to the team.

Deep Link for a Chat

In any case, a deep link can also be used to automate operations, like starting a personal chat with one or more Teams users within your tenant. In this case, the deep link is much simpler. The link below starts a chat with Brian Weakliam, or, if the user has already chatted with Brian, continues that chat:

https://teams.microsoft.com/l/chat/0/0?users=Brian.Weakliam@Office365itpros.com&topicname=Chat

Creating an Email Signature with a Chat Link

This leads us to the idea of putting a chat link in your email signature. Both OWA and Outlook support the creation of HTML format signatures so there’s no problem to insert the link (Figure 1). If you have problems, compose the signature in Word or another editor and paste the results into Outlook or OWA (and yes, it would be nice if the two clients used the same signatures).

The new signature complete with chat link is inserted in outbound messages. Recipients can click the link (Figure 2) to start a chat using either the Teams browser or desktop (if available) client. The link only works when the sender and recipient are in the same Office 365 tenant.

This is the kind of small detail that amuses us when we find it. Learn more amusing and interesting details about Teams in Chapter 13 of the Office 365 for IT Pros eBook!

Office 365 Powering Ahead

As is usual in Microsoft’s April quarterly report (for Q3 FY19), they gave a new number for Office 365 users. In the earnings call, CEO Satya Nadella said that “Office 365 commercial now has 180 million users.” This marked an uptick in the monthly gain to around 4.16 million users since the last number (155 million) was reported in November 2018.

I had expected the number to be in the region of 175 million and it’s interesting to see an increase in users gained each month because eight years after its launch, Office 365 is well past the point when easy migrations happen. The uptick might be driven by large organizations moving to the cloud after they have digested what Microsoft is doing (or not doing) with on-premises servers and noted the relative lack of new functionality appearing in Exchange 2019, SharePoint 2019, and Skype for Business 2019 when compared to their cloud counterparts.

Microsoft also said that Office 365 commercial seats grew 27% year-over-year (Figure 1). This confused me a little because the April 2018 number for Office 365 was 135 million and 27% growth would put the new number around 171 million. However, like many numbers presented in Microsoft earnings briefings, we don’t quite know how they are measured, so we must accept the new figure to be 180 million.

Strong Growth for Enterprise Mobility and Security,(EM+S)

Another figure that attracted my attention was the assertion that “Our EMS install base reached 100 million.” The reason why this is important is that it indicates that a large proportion of the Office 365 base also buys EM+S; it also implies that an even larger proportion of the enterprise Office 365 base buys EM+S. I’m sure some customers buy EM+S without Office 365 but I’m unsure why they would do so. The growing EM+S base also indicates that Microsoft is having some success in moving customers over to Microsoft 365 plans. Microsoft CEO Amy Hood noted that “Office 365 commercial seats grew 27% and benefited from the strong performance of our Microsoft 365 academic offers.”

Success for Outlook Mobile Too

Satya Nadella also said that “the Outlook apps on iOS and Android surpassed more than 100 million users for the first time this quarter.” From one perspective, Outlook reaching this milestone shouldn’t be surprising because:

• Outlook mobile can be used by both cloud and on-premises Exchange. Although the Exchange Online base is obviously growing in line with Office 365, there’s still a lot of Exchange on-premises in use.
• Outlook mobile is acknowledged as a great client for other mail servers, like Gmail.
• Mobility is hugely important for users.

But if you think about things a little deeper, what the data might be telling us is that an increasing percentage of Office 365 users are moving away from the mail apps built into iOS and Android to use Outlook instead. This is sensible because Outlook is a far more feature-rich client. The connectivity architecture used by Outlook mobile enables features like the Focused Inbox (hated by some), encrypted email, and smart calendaring. Native mail apps use the now-outdated ActiveSync or IMAP4 protocols and will never have access to this functionality.

We keep an eye on Office 365 numbers because we like to know what’s happening with the suite and the surrounding ecosystem. It’s an evolving world. See Chapter 1 of the Office 365 for IT Pros eBook for more information about the commercial success of Office 365. Outlook Mobile is covered in Chapter 10, and EM+S in Chapter 18.

Outlook Can Schedule Meetings to End Early, But Will Users Respond?

Poor, badly-organized meetings suck the lifeblood out of an organization. You know the type I mean: attended by too many people, most of whom spend the entire meeting processing email or answering Teams conversations, no or unspecific agenda items, no drive to achieve consensus and decision, and so on. It doesn’t matter if these meetings are in-person or electronic, they’re still a horrible waste of time.

Which brings me to an option introduced in Outlook for Windows click-to-run build 1902 onward (I’m currently using build 1903 from the monthly channel (targeted) – you might have a different version). In Calendar settings, you can opt for meetings and appointments to end a few minutes earlier than the traditional 30- or 60-minute finish. The idea is that you can finish up one meeting and be in good time for your next appointment.

Office 365 for IT Pros author Brian Reid gets very excited about the feature in his blog and explains how to apply registry settings to enable the feature for everyone, or perhaps only the people you want to confuse.

You can also deploy the new calendar settings to clients via the Office administrative template files (ADMX/ADML) for Office 365 ProPlus.

Ståle’s LifeHacks

Apart from saying “awesome” a lot, Office 365 for IT Pros author Ståle Hansen, is very enthusiastic about LifeHacks, which is apparently a way to use OneNote to do most wondrous things to organize your life better. Perhaps ending meetings and appointments five or ten minutes earlier qualifies as a lifehack, but I rather think not.

The sad fact is that software might schedule meetings to occur at certain times and to last a set period, but humans often ignore the best intentions expressed in a meeting notice. People turn up late, barge in without excuse, disrupt the flow of the conversation with inane or inarticulate comments, and generally conspire (inadvertently) to run bad meetings. Outlook’s new option will give you the satisfaction of organizing your calendar better, but it will do nothing to make meetings go smoother.

If you’d like to see the Northern Lights, you can meet Ståle and myself (and lots of other good speakers) at the Experts Live event in Oslo, Norway on May 29. I’m going to hear Ståle say awesome some more while he’s going to tolerate me talking about Office 365 governance. It’ll be awesome. And if you can’t make the conference, read the Office 365 for IT Pros eBook from beginning to end. It’s only 550,000 words… especially Chapter 10, which covers Office 365 clients.

Sometimes an old Dog has New Tricks

In an Office 365 world where the publicity seems to be perpetually absorbed by Teams, it’s nice when an old program suddenly turns up and does something different. Outlook, first released 22 years old, is the old dog, and background moves is its new trick.

Background moves means that when you move items between folders, Outlook doesn’t display a blocking modal screen to display progress of the moves (“moved 100 of 1000 items…”). Progress is interesting, but while the move happens, Outlook won’t let you do anything else. This might have been OK in 1997; it’s not acceptable for modern software in 2019.

Folder Filing is an Old Habit

To be honest, I don’t use Outlook often to move hundreds of items between folders. I might have in the past when it was more common for people to organize their mailboxes into a set of carefully-planned folders. Or when I needed to move items out of my primary mailbox to a PST because of a restrictive mailbox quota (my first Exchange mailbox quota in 1995 was 25 MB). Today I don’t bother much with folders and most email stays in the Inbox and Sent Items folders until it’s moved to my archive mailbox.

Outlook’s Asynchronous Background Moves

My lack of attention to folders meant that I didn’t notice Outlook’s new trick until one of my MVP colleagues pointed it out. Using Outlook ProPlus (build 11601.20144 – version 1904 or later), if you select a batch of messages and move them to another folder, Outlook performs a background move and lets you get on with other work while it completes the move. All you see is a progress bar at the bottom of the main Outlook window. This works for clients configured in both cached and online mode.

If multiple moves are in progress, you’ll see something like this:

The most valuable thing about this feature is that it makes it feasible to move large numbers of items from the primary to the archive mailbox. In the past, this was a real pain, especially when Outlook is configured in cached mode. Now – well, it just works.

The change is only available in Outlook ProPlus (click-to-run) and isn’t available in Outlook 2016 or Outlook 2019. This might change in the future.

Surprising But Welcome

It’s surprising that a vintage program like Outlook should gain such a fundamental improvement at this point in its lifecycle. After all, Microsoft dedicated enormous effort to making Outlook a better network client in the Outlook 2003 release, which introduced the ability to synchronize the entire mailbox and a batch of networking smarts using multiple threads. That all seems so long ago now, back when connecting to Exchange invariably involved some odd whistling noises over a telephone connection.

In any case, it’s nice that Outlook now finally addresses an issue that some people have complained about for a long time (not enough people, obviously).

For more information about Exchange Online clients, including Outlook, read Chapter 10 of the Office 365 for IT Pros eBook.