Old Message Tracing Components Will be Deprecated in September 2025

The June 3 announcement that the new Exchange Online Message Trace facility is generally available creates some work for Microsoft 365 tenant administrators who use message trace in scripts. The roll-out of the update will happen between mid-June and July 2025. Tenants that participated in the public preview and have V3.7 or later of the Exchange Online management module can already use the new Get-MessageTraceV2 and Get-MessageTraceDetailV2 cmdlets.

In the announcement, Microsoft says that they will deprecate the old message tracing UI from the Exchange admin center and the old Get-MessageTrace and Get-MessageTraceDetail cmdlets beginning September 1, 2025. Microsoft will also deprecate the background reporting web service that responds to requests for online message trace data at the same time. The deployment is limited to commercial tenants and doesn’t currently affect sovereign clouds because of the need to certify code upgrades for those environments.

Time Slipping Away to Upgrade Code

Microsoft will take care of updating the Exchange admin center. Customers and ISVs that depend on the old implementation of message tracing must complete their upgrade by the end of August 2025 before the deprecation cycle begins. If you don’t, the risk is that code will stop working without notice.

Twelve weeks seems like a reasonable amount of time to find and update code. However, we’re heading into a peak vacation period when availability of developers becomes more problematic, so now’s the time to get going.

Checking What’s Needed to Upgrade Scripts

To check out what’s needed, I upgrade two scripts. The first script reports email sent to external recipients by members of a distribution list. The second reports the numbers of outbound and inbound messages sent from domains (Figure 1). The updated scripts are both available in the Office 365 IT Pros GitHub repository (see links in the articles).

Updating the first script was easy. All I needed to do was swap out calls to the Get-MessageTrace cmdlet and replace them with Get-MessageTrace2.

The second script was harder because it used paging to fetch pages containing 1,000 message tracing records. Microsoft’s public preview announcement said that they removed support for pagination. The new mechanism behaves awfully like pagination in that you need to fetch message tracing events in batches of up to 5,000 records until all available data is retrieved. Unlike the pagination used by Graph-based APIs, next link URLs are not used to indicate the point the next set of events start. Instead, fetching based on a mixture of dates and email addresses.

An example is worth many words, so if you’re confused about how to fetch message tracing data, have a look at the script for the second example.

Extended Range of Historical Data Available

According to the public preview announcement, Microsoft plans to deliver the ability to query up to 90 days of historical message tracing data. Initially, Microsoft plans to have 30 days of historical message tracing data available online. However, a single query is limited to ten days, so fetching the message tracing data for 30 days requires three separate queries, each covering a 10-day period. If you fetch data for more than 10 days, Exchange responds with the error message:

Error fetching message trace data: ||The interval between StartDate and EndDate can’t be longer than 10 days.

Not a Difficult Transition

Moving to the new message tracing facility isn’t hard. It shouldn’t take too long to upgrade scripts as the changes are straightforward (and having an example helps). Time is likely to be the problem. Too many competing demands for PowerShell coding, too little time to get everything done.

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.

Use the Import-Export Graph API to Copy Data from Mailboxes Without a Trace

A recent LinkedIn post by a security practitioner set some alarm bells ringing when it disclosed that the Graph Mailbox Import-Export APIs processed mailbox content without creating audit events to track activity. Given that a) any operation that can exfiltrate mailbox data could be a highly prized tool for attackers and b) the extensive auditing capabilities built into Microsoft 365, this oversight is more than surprising.

What’s poignant about the situation is that Microsoft released the Mailbox Import-Export Graph APIs as part of their campaign to eliminate Exchange Web Services (EWS). EWS is deemed to be insecure and was used to exfiltrate mailbox data from many sensitive executive mailboxes in the Midnight Blizzard attack on Microsoft’s own tenant in March 2024.

Since then, Microsoft has been on a campaign to eradicate EWS from Microsoft 365 as quickly as practicable. The deadline for all apps to stop using EWS is October 2026, and Microsoft plans to eliminate EWS from first-party apps by October 2025, with recent moves to lay the path for Exchange Online and Teams to stop using EWS to share free-busy information and other data.

To be fair to Microsoft, the Mailbox Import-Export Graph API is in preview and beta software usually has a few holes to fill before it can become generally available. On the other hand, Microsoft launched the API in January 2025 and you’d imagine that someone in the development team would have noticed by now. The good news is that Microsoft has acknowledged the issue. I don’t imagine that it will take them long to begin generating audit events for import and export activities.

For an independent take on using the Mailbox Import-Export Graph API, I recommend reading the articles published by MVP Glen Scales.

Testing Auditing of Permanent Removals

Another step in the EWS removal process came with the launch of APIs to permanently remove mailbox items (including calendar items, contacts, and events). Given the issue reported above, I wanted to check if Exchange Online generated audit events for the permanent removal APIs. It’s not inconceivable that an attacker would seek to remove some items from a mailbox, and so much the better if they can do it without detection.

I processed some permanent deletions for mailbox objects and then ran an audit search for hard deletions (which is what these events are).

[array]$Records = Search-UnifiedAuditLog -StartDate '29-May-2025 10:00' -EndDate (Get-Date) -Formatted -SessionCommand ReturnLargeSet -ResultSize 5000 -Operations 'HardDelete'

Audit events for the permanent deletions duly turned up.

Permanent Removals of Calendar Events

I then processed a permanent deletion of a calendar event by finding some events in my own calendar, selecting one, and deleting it:

[array]$Events = Get-MgUserCalendarView -UserId $userId -Startdatetime "2025-01-01T19:00:00-08:00" -Enddatetime "2025-02-20T19:00:00-08:00"
$Event = $Events[1]
$Uri = $("https://graph.microsoft.com/v1.0/users/{0}/Events/{1}/permanentdelete" -f $UserId, $Event.Id)
Invoke-MgGraphRequest -Uri $Uri -Method Post

Again, Exchange Online captured a hard delete audit event for the deletion (Figure 1)

Deleting different types of mailbox items permanently generates audit events. I expected this to be the case because these are not new APIs. Instead, Microsoft extended existing APIs to support permanent deletion, and the extension picked up the existing auditing mechanism.

Auditing is Critical

Some might consider the inclusion of auditing to be a small point when an API is in beta. It’s an arguable point, but the counter is that attackers don’t care if an API that can do a job for them is a beta or production API. All they worry about is the outcome, which could be a bunch of data noiselessly moved out of a tenant.

Of course, the tenant must be compromised beforehand, but evidence exists of cases where attackers penetrated a tenant and waited months before seizing an opportunity to do damage. A beta API that doesn’t generate audit records sounds like just the kind of tool attackers might like to use.

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

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

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

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

The New Setting for Two-Click Confirmation

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

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

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

Configuring Two-Click Confirmation

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

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

Get-OrganizationConfig | fl two*

TwoClickMailPreviewEnabled : True

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

Set-OrganizationConfig -TwoClickMailPreviewEnabled $false

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

Prompts to use OneDrive

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

Two-Click Confirmation Can be Valuable

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

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

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

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

Maybe a Microsoft 365 Retention Policy is Better than an eDiscovery Hold

Last month, I wrote about how to replace Exchange Online litigation holds, which only preserve mailbox content, with holds applied by Purview eDiscovery cases. The advantage gained by this exercise is that eDiscovery holds can also secure the OneDrive for Business accounts owned by specific users, including those who leave the company.

My idea works, but it’s unnatural. eDiscovery cases are designed to secure information required by eDiscovery investigations, not to preserve information for indeterminate periods. Retention policies are the designated Microsoft 365 mechanism to retain information. Still, I enjoyed probing how to use eDiscovery case holds, and the good news is that much of the code written to prove the principle can be repurposed for retention policies.

Using a Retention Policy

A Microsoft 365 retention policy can cover many different types of data. In terms of mailbox data, a Microsoft 365 retention policy isn’t as granular as Exchange (“legacy”) retention tags, nor does a Microsoft 365 retention policy support the move to archive action to move items from a primary mailbox into its associated archive mailbox. For these reasons, Microsoft hasn’t deprecated Exchange retention policies and tags.

The question of granularity doesn’t arise with litigation holds because a litigation hold retains everything in the primary and archive mailbox. We can therefore replace litigation holds with a retention policy to hold everything indefinitely, and that policy will place a hold on everything in the mailboxes and OneDrive accounts that are added as locations to the policy.

Dealing with the 1,000-Location Limit

The only real limitation that exists is the maximum number of locations supported for Exchange mailboxes and OneDrive accounts. A retention policy that uses static locations can add up to 1,000 locations for each type. It’s unlikely that a tenant will have more than 1,000 mailboxes on litigation hold, but if this is the case, the choice is to either split the locations across multiple retention policies or use an adaptive scope to identify the mailboxes. A retention policy based on an adaptive scope isn’t subject to the 1,000-location limit.

The easiest way to mark mailboxes to be found by an adaptive scope is to set a value in one of the fifteen custom properties available for mailboxes. Each of the mailboxes (accounts) covered by an adaptive scope requires an Office 365 E5, Microsoft 365 E5, or Microsoft E5 Compliance license.

Creating the Retention Policy and Rule

A retention policy consists of two parts. The policy defines the set of target locations, like Exchange mailboxes, OneDrive accounts, SharePoint Online “classic” sites, and Microsoft 365 groups. Figure 1 shows the target locations for a “standard” retention policy. Specific retention policies can be created for Teams channel messages, Teams chat and Copilot interactions, and Viva Engage (Yammer) community messages.

The policy rule defines the retention settings, or what the policy does to the items found in the target locations. In this instance, the rule is very simple because the idea is to mimic what a litigation hold often does, which is to apply an unlimited hold. Litigation holds do accommodate a limited duration hold, and it would be possible to recreate this kind of hold with a retention policy, but here we’re just proving the principle, so it’s enough to show how to create the retention policy and a rule to hold continue indefinitely. Here’s the code:

Write-Host "Creating Microsoft 365 retention policy to replace litigation holds..." -ForegroundColor Yellow
$NewPolicy = New-RetentionCompliancePolicy -Name "Litigation Hold Retention Policy" -ExchangeLocation $MailboxesToHold -OneDriveLocation $OneDriveToHold  `
    	-Comment ("Retention policy to replace litigation holds created by Switch-LitigationHoldsforRetentionPolicies.PS1 script on {0}" -f (Get-Date).ToString("dd-MMM-yyyy")) `
If ($NewPolicy) {
    Write-Host ("Retention policy {0} created" -f $NewPolicy.Name) -ForegroundColor Green
    $NewPolicyRule = New-RetentionComplianceRule -Name LitigationHoldRule -Policy "Litigation Hold Retention Policy" -RetentionDuration unlimited `
        -Comment "Created by Switch-LitigationHoldsforRetentionPolicies.PS1 script" 
    If ($NewPolicyRule) {
        Write-Host ("Retention rule {0} created" -f $NewPolicyRule.Name) -ForegroundColor Green
    } Else {
        Write-Host "Failed to create retention rule" -ForegroundColor Red
        Break
    }
} Else {
    Write-Host "Failed to create retention policy" -ForegroundColor Red
    Break
}

If you want to create a more complicated retention rule, it’s probably best to do so via the Purview compliance portal GUI. You can download the script I used from GitHub.

After applying a retention policy, it can take a few days before the policy becomes fully effective. I’d wait a week and then remove the litigation holds from the mailboxes.

Dump Litigation Holds Now

I don’t hesitate to recommend phasing litigation holds out in favor of retention policies. At this point, litigation holds are a dead-end street that Microsoft is putting little or no effort into. By comparison, Microsoft 365 retention policies are more functional and under active development, which makes them a better long-term bet for meeting the retention needs of Microsoft 365 tenants.

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.

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

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

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

Updating the Conditional Access Setting for an OWA Mailbox Policy

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

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

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

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

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

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

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

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

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

Create a Conditional Access Policy to Block OWA Downloads

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

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

Testing the Block Download Policy with OWA

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

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

Testing with the New Outlook for Windows

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

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

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

Finding Exchange Mailbox Audit Data Isn’t So Easy Anymore

From an engineering perspective, Microsoft’s decision to decommission the Search-MailboxAuditLog and New-MailboxAuditLogSearch cmdlets makes a ton of sense. Microsoft 365 apps consume shared services, and the unified audit service ingests the data used by these Exchange Online cmdlets. Why incur the engineering and support expense to keep the old on-premises cmdlets going?

Microsoft posted the news on January 14, 2025, and stopped writing audit log data to mailboxes on March 1, 2025. The cmdlets will disappear at the end of 2025. You might have missed this information because Microsoft posted to the security blog instead of the Exchange EHLO blog, where all the other Exchange-related news appears. Perhaps this is because audit data is related to Microsoft Purview and the topic therefore is in the security space. However, losing cmdlets that might be used in Exchange-related administrative processes is a big deal deserving better awareness.

In 2016, Exchange mailbox audit data was one of the first sources of audit events for the unified audit log. Ever since, mailbox audit data has flowed into the unified audit log and can be found by audit log searches, so what’s the problem?

Searching the Unified Audit Log for Exchange Mailbox Audit Data

Searches of the unified audit log can be performed synchronously using the Search-UnifiedAuditLog cmdlet or asynchronously through the Audit section of the Purview compliance portal or by submitting a job through the Graph AuditLogQuery API. Audit log searches can find mailbox data among the many other forms of workload data ingested on an ongoing basis, and searches can go back 180 days (audit standard) or 365 days (audit premium). It all sounds good.

But people build processes around PowerShell cmdlets, and when a cmdlet disappears, those processes must be redeveloped. In this instance, any script that uses the deprecated cmdlets must be altered, probably to use the Search-UnifiedAuditLog cmdlet. And let’s face it, even its biggest fans (and I’m probably in that category) wouldn’t consider Search-UnifiedAuditLog to be an easy cmdlet to use, and Microsoft has tinkered with the way the cmdlet functions over the years. Thankfully, they’ve retreated from the idea of making high completeness (very slow) searches the norm.

The parameters for audit log searches can be complex to construct, duplicate audit records can be retrieved, and there’s always the need to unpack the JSON structure contained in the AuditData property to find out what actually happened for the auditable event.

Those accustomed to interacting with the AuditData property know that every workload decides what information to include in audit events and how that data is formatted. Extracting properties from AuditData usually isn’t hard, but it’s tiresome to see how many variations Microsoft engineers can come up with when inserting data into audit events.

Apart from the issue of interpreting audit events, there’s also the simple fact that it’s easier to extract audit data for the actions of a single user from their mailbox. Finding the relevant information about mailbox events from the unified audit log is more complicated.

Find Exchange Mailbox Audit Data for a Single Mailbox

The easiest way to find audit records for a specific mailbox with the Search-UnifiedAuditLog cmdlet is to pass the user principal name for the mailbox owner (or, to search multiple mailboxes, a set of user principal names) in the UserIds parameter. Here’s an example that finds the audit records for a mailbox and reduces the set to those belonging to Exchange actions:

$RecordType = "ExchangeAdmin","ExchangeItem","ExchangeItemAggregated","ExchangeItemGroup","ExchangeSearch"
[array]$Records = Search-UnifiedAuditLog -Userids ‘kim.akers@office365itpros.com' -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

Searching based on user principal names finds audit records for actions performed by that user. If you want to find audit records for actions performed by a mailbox delegate, use a free text search for the object identifier of the mailbox owner’s account. The free text search finds references to the mailbox owner in the AuditData property and includes those records in the set returned. Here’s an example of using an account identifier in a free text search. It’s important that the identifier is cast as a string as otherwise the search will fail because it will attempt to use a GUID where the cmdlet expects a string:

[array]$Records = Search-UnifiedAuditLog -Freetext ((Get-ExoMailbox -Identity Tony.Redmond).ExternalDirectoryObjectId -as [string]) -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

The Bottom Line

You might not have been aware of the change to the old cmdlets. They still work (for now), but mailbox audit data generated since March 1, 2025, cannot be retrieved using the cmdlets. In any case, it’s a good idea to check scripts to find any instances where the old cmdlets are used. The bad news is that those scripts must be redeveloped. Good luck!

Permanent Deletion for Message and Other Types of Items from User Mailboxes

On April 1, 2025, Microsoft announced the availability of APIs to permanently delete mailbox items. This news might well have passed you by because the post appeared in the developer blog rather than anything a Microsoft 365 tenant administrator might see.

The APIs are intended to fill in some gaps in Graph API coverage for mailbox items compared to Exchange Web Services (EWS). It’s part of the campaign to remove EWS from Exchange Online by October 2026. An example of where permanent removal of mailbox items is needed is when migrating mailboxes from one tenant to another. After a successful move, the migration utility might clean up by removing items from the source mailbox.

In any case, APIs are now available to permanently delete mail message, mail folder, event, calendar, contact, and contact folder objects.

What Permanent Removal Means

In this context, permanent removal means that no client interface exists to allow the user to recover the message. For example, users can’t use Outlook’s Recover Deleted Items facility to retrieve the deleted items and administrators can’t use the Get-RecoverableItems cmdlet to do likewise (or appear in a report of recoverable items).

The reason why this is so is that when Outlook deletes items in the Deleted Items folder, the items move to the Deletions folder within Recoverable Items. When the API deletes an item, the item moves to the Purges folder. If the item is not subject to a hold, the Managed Folder Assistant will remove it the next item the mailbox is processed. If it is subject to a hold, the item remains in the Purges folder until the hold lapses.

Permanent Removal with the Microsoft Graph API

Two pieces of information are needed to permanently remove a message item using the Graph API: the object identifier for the account that owns the mailbox and the message identifier. Let’s assume that you have a variable containing details of a message:

$Message | Format-List Subject, CreatedDateTime, Id

Subject         : Thank You for Subscribing
CreatedDateTime : 06/05/2022 06:47:28
Id              : AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNABGAAAAAAB_7ILpFNx8TrktaK8VYWerBwDcIrNcmtpBSZUJ1fXZjZ5iAB_wAYDdAAA3tTkMTDKYRI6zB9VW59QNAAQnaACXAAA=

To delete the item, construct a URI pointing to the message and post the request to the messages endpoint. This example shows where the variables for the user identifier and message identifier are in the URI:

$Uri = ("https://graph.microsoft.com/v1.0/users/{0}/messages/{1}/permanentDelete" -f $UserId, $Message.Id)

$Uri
https://graph.microsoft.com/v1.0/users/eff4cd58-1bb8-4899-94de-795f656b4a18/messages/AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNABGAAAAAAB_7ILpFNx8TrktaK8VYWerBwDcIrNcmtpBSZUJ1fXZjZ5iAB_wAYDdAAA3tTkMTDKYRI6zB9VW59QNAAQnaACXAAA=/permanentDelete

Invoke-MgGraphRequest -Uri $Uri -Method Post

The Graph API doesn’t ask for confirmation before proceeding to remove the item and it doesn’t provide a status to show that the deletion was successful. The only indication that something happened is found by using the Get-MailboxFolderStatistics cmdlet to see if the items in the Purges folder increase:

Get-MailboxFolderStatistics -FolderScope RecoverableItems -Identity Tony.Redmond | Format-Table Name, ItemsInFolder

Name                                    ItemsInFolder
----                                    -------------
Recoverable Items                                   0
Deletions                                        2135
DiscoveryHolds                                   2543
Purges                                             16
SubstrateHolds                                     12
Versions                                           79

Alternatively, use the MFCMAPI utility to examine the items in the Purges folder. Figure 1 shows that the “Thank you for subscribing” message is in the Purges folder.

Permanent Removal with the Microsoft Graph PowerShell SDK

The Remove-MgUserMessagePermanent cmdlet does the same job as the Graph API request:

Remove-MgUserMessagePermanent -UserId $UserId -MessageId $Message.Id

Once again, there’s no status or confirmation required for the deletion to proceed. The other Microsoft Graph PowerShell SDK cmdlets to permanently remove objects are:

• Remove-MgUserMailFolderPermanent: Remove mail folder
• Remove-MgUserCalendarPermanent: Remove calendar.
• Remove-MgUserEventPermanent: Remove calendar event.
• Remove-MgUserContactPermanent: Remove contact.
• Remove-MgUserContactFolderPermanent: Remove contact folder.

All the cmdlets work in the same way. Deletion is immediate and permanent.

Adding new automation capabilities by extending APIs is always welcome. I just need to find a suitable use case for the new cmdlets.

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

Moving Exchange Online Away from Unauthenticated Connections with Reject Send

If your tenant still has devices that send email to Exchange Online, you should pay attention to the April 28 announcement about more control over the Direct Send feature. This step is part of the overall campaign to improve the security of Exchange Online that’s included initiatives like removing support for Exchange Web Services (EWS) and only accepting inbound mail from supported versions of Exchange Server in hybrid configurations.

Direct Send is a method for devices or applications to unauthenticated send email to Exchange Online recipients using an external mail server using an accepted domain for a Microsoft 365 tenant. No mailbox is required, so Direct Send is a relatively painless way to set up an email connection to internal recipients (Exchange Online rejects messages sent to external recipients).

Authenticated Connections Preferred

Because authenticated connections are used, Microsoft would prefer customers to use client SMTP submission (SMTP AUTH) or SMTP relay instead of Direct Send. The announcement says that Reject Send is a new option to disable Direct Send by default. If they don’t need to use Direct Send, tenants should use Reject Send to block Direct Send because it’s a method that could be exploited by spammers.

SMTP AUTH is next on the list for upgrade as it will lose the ability to connect with Basic authentication in September 2025. Devices and apps that use basic auth today, for instance to send email using the PowerShell Send-MailMessage cmdlet, must be upgraded to use OAuth connections or they will lose the ability to send messages via Exchange Online. Authenticating SMTP connections via OAuth is not a matter of changing out cmdlets, so if a tenant hasn’t started that work to make sure that apps and devices continue working after the September deadline, they’re behind the curve and need to accelerate.

The Reject Send Feature

Direct Send email is anonymous (messages don’t come in via a connector). In the past, this didn’t matter so much because the messages came from devices or apps controlled by you and submitted using a domain owned by the organization. Reject Send works by updating the Exchange organization configuration to instruct the transport service to reject any unauthenticated messages submitted by Direct Send.

Reject Send is currently an opt-in feature, so the RejectDirectSend setting in the organization configuration is set to false. To enable Reject Send, connect to Exchange Online PowerShell as an administrator and run the Set-OrganizationConfig cmdlet:

Set-OrganizationConfig -RejectDirectSend $True

Exchange Online organizational settings need time to percolate to all the mailbox servers used by a tenant, so it could take up to 30 minutes before the update is effective across a tenant. Once the block is effective, messages submitted via Direct Send will then a 550 5.7.68 error. Of course, unless someone is checking devices for errors in mail transmission or notices that expected messages don’t arrive, those errors might remain undetected.

Microsoft says that they plan to enable Reject Send by default for new tenants. The logic here is impeccable. If you’ve never used the feature, don’t get the habit. Reject Send is a preview feature to allow customers to test. An issue with forwarding and Sender Rewriting Scheme (SRS) is documented in the announcement, and Microsoft does not provide a date for general availability.

Before Reject Send can reach general availability, Microsoft must deliver the promised “optics” (a report) to give administrators insight into the level of Direct Send traffic within a tenant. Assuming that the report turns up soon and unless big problems are uncovered during the preview, I’d expect Reject Send to be fully available by the end of 2025.

Connectors Required

It’s possible that some existing mail will be affected by enabling Reject Send. If so, that email must be authenticated by routing across a partner mail flow connector.

SMTP AUTH is the Immediate Priority

There’s not much else to say about Reject Send. If you have a test tenant that mimics the operational environment (complete with apps and devices), you should enable Reject Send and see what happens. You could do the same for the production tenant, but only when prepared to track problems with devices and apps. A better idea might be to wait for the promised report to understand the level of Direct Send traffic within the organization.

Given the looming deadline for SMTP AUTH to lose support for basic authentication, this is likely to remain the immediate priority for upgrade. September isn’t that far away, especially when the prime vacation period is in the middle.

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.

Use the Exchange Web Services Usage Report to Track Down the Apps Still Using EWS

On April 22, I wrote about the steps Microsoft is taking to prepare for the removal of Exchange Web Services (EWS) from Exchange Online through the introduction of a dedicated app for hybrid interoperability. Essentially, the new app will take over as the fulcrum for fetching data such as free/busy information from on-premises mailboxes, first using EWS before moving to Graph API requests later this year.

This is an example of Microsoft preparing first-party apps before retiring EWS. Third-party apps running in tenants might also still use EWS. It’s important to check if such apps exist so that contact can made with the app vendor to ascertain their plans for EWS retirement. To help with the process, the reports section of the Microsoft 365 admin center has an EWS usage report (Figure 1).

Validating Apps Listed in the EWS Usage Report

The report details the application identifier, SOAP action (API call) and volume, and the last activity date. Application identifiers make a lot of sense to Microsoft 365 (and more specifically, Entra ID), but they’re hard for humans to understand. Fortunately, it’s easy to resolve the application identifiers for many Microsoft apps by consulting the Verify first-party Microsoft apps in (Entra ID) sign-in reports page. A quick check against the apps reported for my tenant found the following apps:

• Office 365 Exchange Online (00000002-0000-0ff1-ce00-000000000000).
• Office 365 SharePoint Online (00000003-0000-0ff1-ce00-000000000000)
• Teams (1fec8e78-bce4-4aaf-ab1b-5451cc387264).
• Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c)
• Microsoft Outlook (5d661950-3475-41cd-a2c3-d671a3162bc1)
• Teams Web Chat (5e3ce6c0-2b1f-4285-8d4b-75ee78787346).

None of these are surprising. EWS has long been used for calendar lookups, and Teams uses EWS in its middle tier to communicate with Exchange. The apps listed here probably use EWS to fetch information about the current calendar status for users to display that status in their profile data.

Checking for Other Apps

Two explanations exist if you find an application identifier that isn’t in Microsoft’s list of first-party applications. The app is either owned by Microsoft but didn’t make it onto the list for some reason. The more likely reason is that it’s a third-party or custom-developed app that uses EWS.

You can resolve the application identifier by searching the set of enterprise applications in the Entra admin center or with PowerShell. Figure 2 shows an extract of the set of enterprise apps with Teams in the name. You can’t search by application identifier or even sort the set of apps by application identifier, so finding the right app can be tiresome.

Instead of grappling with the Entra admin center UI, it’s usually faster to search for an enterprise application with PowerShell. In this case, I create an interactive Microsoft Graph PowerShell SDK session with the Application.Read.All scope (permission) and use the Get-MgServicePrincipal cmdlet to look for the application with a specific identifier. Once you know the name, you can find other details by examining the app’s properties through PowerShell or the Entra admin center.

Connect-MgGraph -Scopes Application.Read.All
Get-MgServicePrincipal -Filter "Appid eq '5d661950-3475-41cd-a2c3-d671a3162bc1'" | Select-Object DisplayName, AppId

DisplayName       AppId
-----------       -----
Microsoft Outlook 5d661950-3475-41cd-a2c3-d671a3162bc1

Time Ebbing Away

Microsoft plans to retire EWS from Exchange Online on 1 October 2026. That seems like a long time away, but it’s not if you have to track down the developers of EWS apps built for your organization internally or externally. Unlike other deadlines, Microsoft won’t extend the retirement date for EWS because the API is considered insecure and a prime method for attackers to exfiltrate data from a compromised tenant.

Perhaps your EWS usage report will only contain references to Microsoft first-party apps. If so, you’re all set. If not, it’s time to get moving and either retire or upgrade apps.

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.

Moving from Single-Workload Holds to Microsoft 365 Holds

Many tenants use litigation holds (also known as legal holds) to retain the complete content of Exchange Online mailboxes. The feature has been available since Exchange 2010 and can hold mailbox items (including associated archive mailboxes) indefinitely or for a specified period. The good thing about litigation holds, which is probably why people use them, is that it’s very easy to put one or more mailboxes on hold using PowerShell or the Exchange admin center (Figure 1).

The PowerShell equivalent to set litigation hold on a mailbox is:

Set-Mailbox -Identity Brian.Weakliam -LitigationHoldEnabled $True -LitigationHoldOwner "Tony.Redmond@office365itpros.com" -LitigationHoldDate "21-Apr-2025 16:00" -LitigationHoldDuration Unlimited -RetentionURL "https://office365itpros.com/AllAboutLitigationHold.Html"

While this command lists the set of mailboxes with litigation hold enabled:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -Properties LitigationHoldEnabled, LitigationHoldDate, LitigationHoldDuration, LitigationHoldOwner -Filter {LitigationHoldEnabled -eq $True} -ResultSize Unlimited | Format-Table DisplayName, LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

Inactive mailboxes can also be on litigation hold (and the hold might be the reason why Exchange Online retains these mailboxes):

Get-ExoMailbox -InactiveMailbox -Properties LitigationHoldEnabled, LitigationHoldDate, LitigationHoldDuration, LitigationHoldOwner -Filter {LitigationHoldEnabled -eq $True} -ResultSize Unlimited | Format-Table DisplayName, LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

To release the litigation hold for a mailbox, set its LitigationHoldEnabled property to $false.

Set-Mailbox -Identity Kim.Akers -LitigationHoldEnabled $False

Or for an inactive mailbox:

Set-Mailbox -InactiveMailbox Dylan.Webb -LitigationHoldEnabled $False

This action clears the other litigation properties. Enabling or removing a litigation hold from a mailbox is usually effective within a few minutes but can take several hours.

The Bad Thing about Litigation Holds

Litigation Holds are easy to apply and manage and are available for all Exchange Online mailboxes. But their big downside is that litigation holds only cover mailbox items. That was an acceptable state when the need to preserve personal information for an employee only extended to email. Today, Microsoft 365 apps store so much information in a user’s OneDrive account that it is imperative to preserve this data when someone leaves.

Within Microsoft 365 today there are many other ways to communicate, including Teams, OneDrive for Business, Microsoft 365 Groups, and Viva Engage. Along with mailboxes, those locations are all covered by Microsoft 365 retention policies, which are the modern alternative to litigation hold.

However, I’m not going to cover retention policies here. Instead, I’m going to throw out a different idea, which is to use an in-place hold imposed by a standard eDiscovery case (available with Office 365 E3 and above or Microsoft E5 compliance licenses). Perhaps the recent GUI overhaul for Purview eDiscovery prompted me to investigate this solution.

Holds are only one part of eDiscovery cases, which also include searches, review sets, and exports covering multiple data sources. In the scenario where an organization wants to keep personal information for employees for a period (perhaps after employees leave), an eDiscovery case might replace litigation holds and deliver the additional benefit of holding OneDrive for Business accounts.

Creating an eDiscovery Case with PowerShell

The eDiscovery case we need is simple. It consists of:

• The case (created with New-ComplianceCase). A container for the case elements, like holds and searches,
• A case hold policy (created with New-CaseHoldPolicy) defines the set of locations (mailboxes and OneDrive for Business accounts) that the hold will apply to.
• A case hold rule associated with the case hold policy (created with New-CaseHoldRule). The rule specifies the KQL query used by the hold. In this case, to create a hold that applies to everything in the mailboxes and OneDrive for Business accounts, the KQL query is empty.

Before running any of these cmdlets, you must connect to Exchange Online and the compliance endpoint, and the account used must have the eDiscovery manager role.

An example script is worth hundreds of words. You can download my example from GitHub.

Delegated Permissions and OneDrive for Business

The script is intended for use with delegated permissions. It would be possible to use app-only mode, but I wanted to illustrate an important an important aspect of dealing with OneDrive for Business accounts.

The Sites.Read.All permission allows the signed-in user to read details of all SharePoint Online sites – but not OneDrive for Business accounts, even if the account is a SharePoint administrator. This is a little strange because the SharePoint administrative interfaces allow access to OneDrive.

The full URL for a OneDrive account is needed to add it to an eDiscovery case hold policy (or a retention policy). This is a value like:

https://office365itpros-my.sharepoint.com/personal/brian_weakliam_office365itpros_com

Even with the Sites.Read.All delegatedpermission, you can’t use the Get-MgUserDrive or Get-MgUserDefaultDrive cmdlets to get the OneDrive URL (you can with the application permission). I therefore use a little trick of retrieving the OneDrive usage report data for the last 90 days and extracting the user principal name and site identifier from the data. The script can use the site identifier with the Get-MgSite cmdlet to find the OneDrive URL. It’s a little complicated, but the code works. It would be nice if the usage report data included the site URL. However, a longstanding problem that Microsoft seems incapable of solving means that the site URL is missing from SharePoint Online and OneDrive usage reports.

Easier Solutions Exist

It would be easier to use the Microsoft Graph PowerShell SDK in app-only mode and have full access to the OneDrive account information, but this is an example of how it’s often possible to get at Microsoft 365 data when it seems to be blocked. It would also be easier to move mailboxes (and their OneDrive accounts) from litigation hold to a retention policy instead of an eDiscovery case, but where’s the fun in always taking the easy route?

If you’re still using litigation holds, the question is why? In 2010, litigation holds were the best we could do in terms of preserving mailbox content. In 2025, we can do better, and there’s many ways to satisfy the need to preserve data, including OneDrive.

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.

OWA Access to Online Archives Ceases on 12 May 2025

The April 17 announcement about the retirement of OWA support for cloud archives in Exchange Server dismayed some people. I received several messages to ask why Microsoft will withdraw support for OWA access to cloud archives from May 12, 2025. Some asked if this was yet another example of Microsoft releasing bad news on the cusp of a holiday weekend. Others asked why Microsoft only gave customers 25 days’ notice. And a few asked if this was the first step to retire Exchange Server (despite the imminent arrival of Exchange Server SE).

A Matter of Money

I wasn’t surprised at the news because it fits in with the current environment around Exchange Server. First, we migration to the cloud is all but finished for organizations that want to use Exchange Online. Even in hybrid organizations most mailboxes are in the cloud with a relatively small percentage still on-premises.

Organizations that wish to stay on-premises and use Exchange Server SE do so for their own reasons. Security over email is one of the primary motivations for staying on-premises, so these organizations probably generate relatively little demand for online archives (archive mailboxes hosted by Exchange Online). Coupled with a reducing set of on-premises mailboxes in hybrid environments, the overall demand for online archives cannot be high.

If Microsoft isn’t generating revenue by selling Microsoft 365 licenses to on-premises organizations to access online archives, they’ll want to reduce engineering and support costs. One way to do that is to reduce the number of clients that can access online archives when the primary mailbox is on-premises, and that’s what’s happening here.

Outlook Classic Continues

Microsoft points out that access to online archives will continue via Outlook classic. They don’t specify what version of Outlook classic is necessary, but we can assume that anyone who accesses an online archive today with Outlook classic can continue to do so after May 12, 2025.

It’s unsurprising that Microsoft chose to retire OWA access. There’s no indication that the new Outlook for Windows (aka OWA on steroids) will support Exchange Server in the future. The New Outlook is very tied to Exchange Online and moving that client to Exchange Server seems like work that Microsoft wouldn’t want to do. Simplifying the version of OWA available to Exchange Server makes that client easier to support and cheaper to maintain.

But if the new Outlook isn’t going to support Exchange Server when Outlook classic support terminates sometime in 2029, that creates the question of what clients will be available to Exchange Server customers after that time. I don’t think a simplified version of OWA will be enough for on-premises users. Unlike the new Outlook, OWA doesn’t support offline access, PSTs, and so on. Microsoft will have to do something to address the client issue for on-premises customers. It would be no surprise if Outlook classic (a version of the perpetual client, not subscription) continued after 2029. It’s a while away before we’re likely to hear about client plans for Exchange Server SE in 2029, but Outlook classic seems like a good bet (“Outlook 2030” perhaps?).

Change Happens

Change is a constant factor in the cloud and trade-offs happen between the introduction of new functionality (some is coming for Exchange Server SE) and the retirement of older underused features. Microsoft says that tenants affected by the change have received message center notification MC1053644 to let them know what’s going on. If you haven’t received the notification and think that your tenant is affected, you should contact exchonpremfeedback[AT]microsoft.com.

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.

Change to Dedicated Exchange Hybrid App Paves Way to Graph APIs

I don’t know why Microsoft publishes important information at the start of a holiday weekend when the distraction level is high, but that’s just what they did when making a critical announcement for organizations running hybrid Exchange. As it turns out, the announcement is linked to the April 2025 Exchange Server hotfix update (HU), but I think releasing both pieces of news would have been fine once everyone was back at work after the Easter break.

The announcement outlines how Exchange hybrid configurations are dropping Exchange Web Services (EWS) in a two-phase process beginning with the release of the April 2025 HU. It’s part of the strategy to retire EWS from Exchange Online in October 2026.

Preserving Rich Coexistence

In a hybrid organization, Exchange Online uses EWS for “rich coexistence.” In other words, Exchange Online issues EWS commands to fetch free/busy data, mail tips, and user profile pictures for on-premises mailboxes. The EWS requests to fetch data are made by a first-party Microsoft enterprise app called Office 365 Exchange Online, which is present in every tenant that uses Exchange Online. Requests from Teams to fetch similar data for on-premises mailboxes also flow through the Office 365 Exchange Online app.

Microsoft’s announcement says that the Office 365 Exchange Online app is created by the Hybrid Configuration Wizard (HCW). HCW certainly updates the app’s service principal, but the app itself isn’t tied to HCW. For example, one use of the app is to hold Exchange Online permissions that can be assigned to other service principals, such as when an Azure Automation account needs to run Exchange Online PowerShell cmdlets.

Microsoft wants to remove EWS. However, instead of using another first party enterprise app that’s controlled and managed by Microsoft, tenants are required to create an Entra ID registered app. Like any other Entra ID app, the app (with a display name of ExchangeServerApp-{organization identifier) can hold the Graph permissions needed to access mailbox and other data. Or rather, the app’s service principal can hold the permissions. Microsoft calls this app the “dedicated Exchange hybrid app.”

When first presented with the idea that tenants had to create individual apps, my response was that it should surely be easier for all to have a dedicated first party app where Microsoft manages the app and its permissions. In their text, Microsoft justifies their decision as follows:

Consider the upcoming shift from EWS to Graph API calls: adjustments to the application will be necessary (for example, updating API permissions). A dedicated customer application allows customers to choose when they want to transition from EWS API permissions to Graph API permissions.

The reason why a tenant-specific registered app is used is therefore to allow individual customers to choose when they move from EWS to Graph API. This is valid and I can see how the flexibility to move at the time of a customer’s choosing is useful. It seems like Microsoft is saing that a centrally-managed enterprise app can’t be used because of the requirement to switch permissions from EWS to Graph. However, there’s nothing to stop an enterprise app holding both EWS and Graph permissions for a period after which the EWS permission is removed. That ship has sailed and the registered app is the way forward.

Step One: Switch Apps

The first step in the process requires tenants to apply the April 2025 HU. After updating servers, tenants can run the ConfigureExchangeHybridApplication.ps1 script to switch their configuration from the current setup to the dedicated Exchange hybrid app. The script is run once per organization. After switching, EWS is still used, but it’s routed through the dedicated Exchange hybrid app rather than the Office 365 Exchange Online app.

Microsoft says that they plan to release an updated version of the HCW in the second quarter of 2025 (soon). If a tenant runs the updated HCW, it will switch the apps.

Step Two: Switch to Graph

The second step depends on availability of Graph API support for coexistence with Exchange Server. When the software is available, tenants must apply server updates to enable servers to respond to Graph API requests. Being able to handle Graph requests for mailbox data is not the same as the wider and deeper Graph access available within Microsoft 365.

After upgrading servers, tenants can run the script again to switch the dedicated Exchange hybrid app from EWS permissions (which essentially allow unfettered access to mailboxes) to a set of more granular Graph permissions that limit the app to more precise and restricted access. The elimination of the broad access to mailboxes enjoyed by EWS is one of the primary driving factors behind the desire to retire EWS from Exchange Online. This phase must be completed by 1 October 2026 (Figure 1). If not, rich co-existence will stop working.

Take Your Time

Before doing anything, I suggest you read the announcement, hot fix information, and installation notes for the script. Reviewing the PowerShell code in the script will also help you to understand what it does in different modes.

After applying the April 2025 hotfixes, the next decision is when to switch to the dedicated app. I don’t see any reason why not to switch immediately. The bigger decision is when to switch the app to using Graph permissions rather than EWS. This is likely something that you’ll want to do during a scheduled server maintenance period towards the end of 2025, after making sure that everything works well in a test organization of course.

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.

No Out-of-the-box Answer for Transfer Meeting Ownership

A problem that’s often faced when tidying up the affairs of ex-employees is what to do about the meetings they organize. Sometimes, no issue arises because the ex-employee doesn’t organize meetings or they have just a few meetings that can be easily canceled. In other instances, the departing individual is the organizer of a many meetings, including recurring meetings, and the meetings have artifacts like Loop-based meeting notes, attendance reports, and so on.

The core issue is that no way exists to transfer the ownership of meetings from one user to another. If this facility existed, it would be easy for someone like an ex-employee’s manager to take over responsibility for future and past meetings. To avoid the problem happening with important company events, some organizations use designated shared mailboxes to schedule and manage these events. It doesn’t matter when someone leaves the organization because the meeting organizer always remains.

The One Calendar

Outlook and Teams share the same calendar. Teams allows meetings to have co-organizers. This feature helps keep scheduled meetings running and preserves past events, but no transfer of ownership occurs. The Outlook equivalent is a delegate with full control over a calendar, but delegation is not ownership.

On the surface, it seems like the software engineering involved in transferring meeting ownership is just a matter of moving calendar events from the old organizer’s calendar to the new organizer’s calendar. However, that simple move hides a lot of complexity when issues like delegation and recurring events are considered. Transferring meeting ownership without affecting access to meeting resources is likely a good chunk of work, which is probably why it hasn’t happened.

A New Take on the Classic Answer to the Transfer Meeting Ownership Question

The classic answer is to cancel all future meetings owned by the ex-employee and have another person reschedule the meetings. You can automate meeting cancellation by running the Remove-CalendarEvents cmdlet, which can cancel events for up to 1,825 days in advance. Meeting participants receive cancellation notifications as normal. It’s an effective way of cleaning up events owned by an ex-employee, provided their mailbox is still online.

And while the mailbox remains online, it’s a good idea to create a report detailing meetings that might need to be rescheduled. The data is easily fetched with the Graph list calendar view API, which fetches the set of calendar events for a mailbox for a specified period.

The Office 365 for IT Pros GitHub repository contains many scripts covering different parts of Microsoft 36. It’s my scripting toolbox when I need some code to solve a problem. In this case, I used code from the room mailboxes statistics report. The original version uses Graph requests. To simplify matters, I modified the code to use Microsoft Graph PowerShell SDK cmdlets. The basic flow is:

• Run the Connect-MgGraph cmdlet to connect an interactive session to the Graph with the Calendars.ReadBasic and User.ReadBasic.All scopes. The script available from GitHub uses delegated permissions with the signed-in account. If you want a script that can read any mailbox, use an app to hold the permissions and authenticate with a certificate so that you can run in app-only mode (see an example here).
• Run the Get-MgUserCalendarView cmdlet to fetch data for the last 180 days (an arbitrary value that can be set to whatever number of days you want).
• Find the set of meetings organized by the user from the data returned in the calendar view.
• Report details of the meeting and generate an Excel worksheet or CSV file as output (depending on if the ImportExcel module is available).

Figure 1 shows selected details for some reported events through the Out-GridView cmdlet.

You can download the complete script from GitHub. The script as written doesn’t report details like meeting body (notes) or attachments. It’s possible to fetch and reuse this data (the script will need the Calendars.Read rather than the Calendars.ReadBasic.All scope to access the meeting body and attachments).

Reschedule to Transfer Meeting Ownership

The remaining work is to review the set of meetings found in the ex-employee’s calendar and decide which meetings need to be rescheduled and who should be the new owner. The rescheduling process is probably going to be manual, but it would be possible to read in event details from the output XLSX or CSV file using the New-MgUserCalendarEvent cmdlet. It’s not worth doing the work if only a few meetings are involved but it might be if a large volume of meetings need to be rescheduled. I’ll leave that work to the reader.

One final point: cleaning up future meetings and possibly rescheduling meetings are points that should be part of a departing employee checklist. It’s best to be proactive.

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.

EX1015484 Issue Causes Duplicate Exchange Online Mail User Objects Linked to Entra ID Guest Accounts

I am indebted to MVP Joe Stocker for sharing information about incident EX1015484 (duration from February 20 7:38AM PST to February 27 5AM PST). The problem as reported by Microsoft (Figure 1) is that when administrators create new Entra ID guest accounts, duplicate objects appear in Exchange Online that prevent email delivery to the guest accounts.

Creating Mail User Objects

Entra ID and Exchange Online use a dual-write mechanism to update objects. Guest accounts originate when external users are added to Teams or Microsoft 365 groups, or when an administrator invites an external user to join the tenant from the Entra admin center.

When Entra ID creates a new guest user account, Exchange Online creates a mail user object. The existence of the mail user object allows guest users to be included in distribution lists. The mail user object has an email address, so email can be sent to the object, and the transport system is able to route messages to the guest account. Exchange Online removes a mail user object automatically following the removal of the guest user account from Entra ID. If the deleted Entra ID account is restored, the mail user object reappears.

Duplicated SMTP Addresses

In the case of EX1015484, it seems like Microsoft shipped a feature update with a bug that created mail user objects with duplicate SMTP email addresses. The Exchange transport system insists that email-enabled objects have unique email addresses because that’s the basis for routing messages to their final destinations.

Apparently, tenants need to contact Microsoft support to remove the duplicate objects. You can’t just remove duplicate mail user objects because of the dual-write mechanism. Entra ID is the directory of record, so any attempts to run Remove-MailUser to delete an object linked to a guest account will fail:

Remove-MailUser -Identity a9f35d52-572e-4438-a129-08d8c00ae88b

Confirm
Are you sure you want to perform this action?
Removing the mail enabled user Identity:"a9f35d52-572e-4438-a129-08d8c00ae88b" will delete the mail enabled user and
the associated Windows Live ID "elifon_contoso.com#EXT#office365itpros.onmicrosoft.com".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
Remove-MailUser: ||An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online.
However, it failed. Detailed error message:  Resource 'a9f35d52-572e-4438-a129-08d8c00ae88b' does not exist or one of its queried reference-property objects are not present. DualWrite (Graph) RequestId:
61220f4c-90ea-4fa5-bf1f-c07b5d10c26d The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.

Removing the guest accounts from Entra ID and restoring them after a few minutes might well work. I can’t say because the problem didn’t affect any tenant that I have access to.

In any case, Joe posted some PowerShell to find mail-enabled objects with duplicate SMTP addresses:

Connect-ExchangeOnline; Get-Recipient -ResultSize unlimited | Select-Object -ExpandProperty EmailAddresses | Where-Object {$_ -like "smtp:*"} | Group-Object -Property {$_.ToString().ToLower()} | Where-Object {$_.Count -gt 1} | Select-Object @{Name="SMTPAddress";Expression={$_.Name.Substring(5)}}, Count | Sort-Object -Property Count -Descending

The code is faster when a filter is applied to select mail user objects. Here’s my version (updated for Exchange Online Management PowerShell module V3.7.2; if you run V3.7.1, filter against MailUser objects)

Connect-ExchangeOnline; 
Get-ExoRecipient -RecipientTypeDetails GuestMailUser -ResultSize unlimited | Select-Object -ExpandProperty EmailAddresses | Where-Object {$_ -like "smtp:*"} | Group-Object -Property {$_.ToString().ToLower()} | Where-Object {$_.Count -gt 1} | Select-Object @{Name="SMTPAddress";Expression={$_.Name.Substring(5)}}, Count | Sort-Object -Property Count -Descending

I tested the amended code by removing the check for addresses with a count greater than 1, so I am pretty sure that it works. Feel free to improve the code!

Problems Happen

It’s regrettable that EX1015484 happens, but that’s the nature of software. The issue has been resolved, and you will no longer encounter mail user objects with duplicate SMTP addresses in your tenant. It’s worth running the code shown above just in case that the problem hit your tenant and left some bad objects behind.  

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.

The Microsoft 365 Admin Center Makes It Easy to Remove Domains

I’ve been cleaning up the set of accepted domains configured for my Microsoft 365 tenant. After we launched the Office 365 for IT Pros eBook, I acquired several domains like Office365ExchangeBook.com that seemed to be relevant to the book. Years later and the office365itpros.com domain persists with a large legacy of published articles and scripts. No real advantage has been gained from the other domains, so the decision was taken to drop the unwanted domains and remove them from Microsoft 365.

Removing a domain is easier than adding a domain. Go to the Domains section (under Settings), select the unwanted domain, and select Remove domain from the menu. This method works for vanity domains (the type that you pay domain registrars to own) but not for fallback or service domains used for MOERA addresses.

When you use the Microsoft 365 admin center to remove a domain, the portal thoughtfully shows the mail-enabled objects that will be affected by the removal (Figure 1). You can then remove any proxy addresses assigned to the highlighted objects that use the domains.

The Problem of PowerShell

But sometimes you might remove a domain with the Remove-AcceptedDomain cmdlet and so lose the benefit of the checks performed by the Microsoft 365 admin center. This is fair enough because if you make changes to a tenant configuration through PowerShell, you should understand the consequences of the action. I wish I did…

If you forget to adjust email addresses for objects affected by the domain removal, you’ll see errors like this when attempting to update an address:

Set-UnifiedGroup -Identity c38ef1e1-1957-4e5f-bcde-1eae7bb234f3 -PrimarySmtpAddress 'Soccer.Fans@office365itpros.com'
Set-UnifiedGroup: ||You can't use the domain Office365ExchangeBook.com because it's not an accepted domain for your organization.

Quite reasonably, the cmdlet complains that it can’t update the primary SMTP address for the Microsoft 365 group because it’s detected an invalid entry in the set of proxy addresses. To correct the issue, we need to find all the mail-enabled objects that has primary or proxy addresses that use the removed domain and remove or replace the offending addresses.

The PowerShell Solution

You can download the script I used from the Office 365 for IT Pros GitHub repository. Essentially, the script breaks down into three parts. First, the script retrieves the current set of accepted domains and identifies the default domain:

[array]$Domains = Get-AcceptedDomain 
$PrimaryDomain = $Domains | Where-Object { $_.Default -eq $true } | Select-Object -ExpandProperty DomainName
[array]$Domains = $Domains | Select-Object -ExpandProperty DomainName

Second, the script checks mailboxes, Microsoft 365 groups, distribution groups, and dynamic distribution groups to find instances where proxy addresses don’t belong to an accepted domain. The details of the affected objects are recorded in a list. Here’s how the script deals with mailboxes:

Write-Host "Checking mailboxes..."
[array]$Mailboxes = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, RoomMailbox, EquipmentMailbox, discoveryMailbox

ForEach ($Mailbox in $Mailboxes) {
    $ExternalAddresses = $Mailbox.EmailAddresses | Where-Object { $_ -like "SMTP:*" -and ($_.Split(':')[1].Split('@')[1] -notin $Domains) }
    If ($ExternalAddresses) {
        $ReportLine = [PSCustomObject][Ordered]@{
            DisplayName             = $Mailbox.DisplayName
            PrimarySmtpAddress      = $Mailbox.PrimarySmtpAddress
            EmailAddresses          = $ExternalAddresses -join ", "
            Type                    = "mailbox"
            Identity                = $Mailbox.Alias
        }
        $Report.Add($ReportLine)
    }
}

Finally, each of the objects found by checking proxy addresses against accepted domains is processed to remove any bad proxy addresses and assign new primary SMTP addresses where necessary.

Not Perfect Code

I don’t pretend that this script is perfect code. All I can say is that it did the job for me and cleaned up primary and proxy addresses for my tenant and might therefore be useful to others in the same situation. What this experience goes to prove is that sometimes executing clean-up operations is better done through the GUI where you can take advantage of the work done by engineers to anticipate what needs to be done after adjustments are made to a tenant.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Client-Side Limitation or Licensing Limitation?

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

Does recall work for encrypted email?

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

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

Having the Right License is Always Important

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

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

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

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

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

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

Message Recall in Outlook Mobile

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

In Case of Protected Recall, Look for OWA

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

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

New 3,000 Threshold for Dynamic Distribution Groups in April 2025

Fresh from its decision to impose a tenant-wide external recipient run rate (now delayed until May 2025), Microsoft announced another restriction for Exchange Online on March 5, 2025 by limiting the number of dynamic distribution groups (DDGs) in a tenant to 3000 (message center notification MC1024399). Once the limit is reached, no further dynamic distribution groups can be created until some have been removed. Microsoft plans to introduce the restriction in early April 2025.

To discover how many dynamic distribution groups are in a tenant, run this PowerShell command:

(Get-DynamicDistributionGroup).count

A Surprising Move

It’s a surprising move. Dynamic distribution groups require service resources to resolve recipient filters to individual recipients when messages pass through the transport pipeline. Microsoft announced “modern” DDGs in December 2021 (rolled out in mid-2022) to save resources and reduce the time required to process list expansion by calculating list membership on a scheduled basis in the background rather than on-demand.

Dynamic distribution groups support both precanned and custom recipient filters, and expansion of some complex custom filters is likely quite demanding. Recently, Microsoft fixed a bug in wildcard support in DDGs that affected custom filter resolution for many customers. No hint was given then or earlier that tenants might be using too many DDGs. I suspect that very few tenants surpass the new 3,000 limit.

Entra ID supports a much higher 15,000 limit shared between dynamic Microsoft 365 groups and dynamic administrative units. Both the dynamic Entra ID object types require Entra P1 licenses whereas dynamic distribution groups are covered in the standard Exchange Online license. Dynamic distribution groups are not Entra ID objects and do not synchronize from Exchange Online to Entra ID. Nevertheless, it seems odd that Exchange Online should choose a much lower limit than pertains for dynamic Microsoft 365 groups. Conspiracy theorists will no doubt conclude that the new limit is yet another not-so-subtle hint from Microsoft that they’d prefer if customers use Microsoft 365 groups instead of distribution groups.

The actual answer might be that this is a simple check to stop people abusing dynamic distribution lists. Many components that consume service resources are limited in one way or another. This could just be another example of Microsoft introducing a threshold to impose an upper limit on the resources DDGs can consume.

Checking for Inactive Dynamic Distribution Groups

If your tenant is near the new limit, you might want to check for inactive Dynamic distribution groups. The easiest way to do this is using the report available in the Reports section of the Exchange admin center (Figure 1). As you can see, all 27 of the DDGs in my tenant are unused, probably because so much of my recent work has focused on Microsoft 365 Groups and Teams.

The report supports filtering for 7, 30, and 90 days and a custom start date (within the last 80 days). The information shown in the report comes from message tracing data (which goes back a maximum of 90 days). If you want more control over the reported data, you can use the technique explained in this article to run historical message trace reports and analyze that data with PowerShell (the article explains how to do this for normal distribution groups, be sure to change the reference to the Get-DistributionGroup cmdlet to Get-DynamicDistributionGroup).

Time to Trim Dynamic Distribution Groups

I don’t have knowledge about any abuse that might have driven Microsoft to clamp down on dynamic distribution groups, Given that it is very easy to build a recipient filter that addresses everyone in the tenant, it’s understandable that abuse could occur in the form of a significant increase in email volume generated when such a DDG is used. In the past, this might have caused an email storm, but Microsoft built checks for email storms into Exchange Online several years ago.

In any case, the limit will come into effect in early April 2025. Before then, it’s time to check the set of dynamic distribution groups with the aim of trimming unused DDGs. And if you can’t get the number of DDGs under the limit, consider converting them to dynamic Microsoft 365 groups.

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.

Now Possible to Include iOS Build Numbers in ActiveSync Device Access Rules to Allow Access for Devices Running Specific Builds

I last looked at Exchange Online Mobile Device management in June 2023, when I wrote about reporting devices that synchronize with Exchange mailboxes using ActiveSync. At the time, I said that not many changes had recently occurred in Exchange Mobile Device Management. After all, Microsoft wants customers to use Intune, and Exchange Mobile Device Management is very much the runt in the Microsoft device management litter.

Which brings me to message center notification MC916298 (23 October 2024) and now fully available in tenants worldwide. It’s the first change in ActiveSync Device Access rules that I can remember since Microsoft updated rules to support Outlook for iOS and Android after its Acompli acquisition in late 2014. The best articles about how to configure device access rules still date from that period. Exchange ActiveSync is not an area of high change.

Query Strings and iOS Build Numbers (or Build Strings)

The change is that Apple iOS build information is now supported in the query string used to check the O/S version on mobile devices attempting to connect to Exchange Online mailboxes. MC916298 says “build number,” but Apple uses alphabetic identifiers like 22D72 (Figure 1).

Leaving semantics aside, the point is that organizations can create ActiveSync device access rules based on the information reported by iOS devices. For example, this code creates an access rule that allows IOS devices running iOS 18.3.1 22D72:

New-ActiveSyncDeviceAccessRule -AccessLevel Allow -Characteristic DeviceOS -QueryString "iOS 18.3.1 22D72"

To block iOS devices with a specific build, change the access level to Block.

I guess that the new capability exists to allow tenants to insist that iOS devices use a specific build for whatever reason that they might have. It’s just another level of granularity to detect devices.

Testing a Block Using iOS Build Numbers

The documentation for the New-ActiveSyncDeviceAccessRule cmdlet hasn’t been updated recently (it features examples blocking iOS devices running 6.1.1), so don’t expect much additional information from that source. However, I can guarantee that the access rule shown above works. I know this because I removed all the other access rules from my tenant and created one that was slightly different to the one shown above (IOS 18.4.1 rather than iOS 18.3.1). After a pause of about 15 minutes for the rule changes to replicate and become effective, the access rule blocked any attempt by Outlook for iOS to synchronize with mailboxes (Figure 2).

Users of non-compliant iOS devices also received email to tell them that their devices couldn’t connect and was blocked from synchronizing with Exchange Online (Figure 3). Interestingly, the blocked devices have never shown up in the quarantined device list in the Exchange admin center.

After being shouted at by several users who were unhappy that their email wouldn’t synchronize, I deleted the incorrect access rule and replaced it with the proper version. Within 15 minutes, email flowed again and all was well.

Time to Check Device Access Rules

Apart from playing with IOS build numbers, the exercise in testing device access rules was useful because it forced me to clean out the old and obsolete device access rules that had accumulated in my tenant. There was a time when these rules were critical. Given the dominance of Outlook for iOS and Android, I suspect that many tenants have just one rule (to allow access to those clients. Defining more sophisticated access rules are only needed to control clients that use the Exchange ActiveSync protocol for everything, like the native Apple mail app. Oh well, on to the next thing.

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.

Microsoft Clamps Down on EWSEnabled Tenant Setting to Enable Exchange Web Services

Exchange Web Services (EWS) is scheduled for retirement on October 1, 2026. Although October 2026 is still 19 months away, retiring an API that was heavily used at one time requires time and patience to expunge every trace of the API. Microsoft has already removed EWS from clients like Outlook for Mac and is working through the steps to remove EWS from its other applications.

Independent software developers have received clear directions that they should replace EWS with the Microsoft Graph. The acknowledged gaps in functionality that currently exist in the Microsoft Graph are being closed, with the latest example being the introduction of the Exchange mailbox import-export API (see MVP Glen Scales’ commentary on the new API).

Now Microsoft is preparing for the final removal by clamping down on the organization setting which controls whether EWS is enabled or disabled within a tenant. In a February 20, 2025 post, Microsoft says that the organization-level EWSEnabled flag will play a more significant role than it has done in the past. The change is being made to make it easier for Microsoft to disable EWS across Microsoft 365.

Enabling EWS for a Mailbox

In the past, it was sufficient for administrators to set the EWSEnabled flag for a mailbox to $true to allow the mailbox to use EWS in apps and clients. This condition existed because the mailbox setting has precedence over the setting in the Exchange Online organization configuration and, by default, the organization setting is null.

Get-OrganizationConfig | Select-Object EWSEnabled

EwsConfig
---------

The only time administrators set the organization-level EWSEnabled setting is if they wanted to block EWS throughout the tenant. Usually, this need didn’t arise because it was sufficient to set EWSEnabled to $true on the mailboxes that needed access to EWS. For instance, because EWSEnabled is $true for the James Ryan mailbox, that mailbox can use EWS even though the organization setting is null.

Get-CasMailbox -Identity James.Ryan | Select-Object EWSEnabled

EwsEnabled
----------
      True

The Big Change

What’s changing is that Exchange Online will only permit a mailbox to use EWS if both the organization and mailbox settings are $true. The old situation where the default null value at the organization level is sufficient to allow access is no longer in force. Tenants that want to use EWS to the bitter end must now explicitly enable EWS in the Exchange Online organization configuration:

Set-OrganizationConfig -EWSEnabled $true

You can see where Microsoft is going. By forcing the relatively small number of tenants to explicitly allow EWS by updating the organization configuration, Microsoft is preparing for the big turn-off when they will update the organization configuration to set EWSEnabled to $False and block any further changes to the setting. It’s an elegant and effective way of making sure that the turnoff happens on October 1, 2026.

Problems might arise for tenants that have the organization configuration set to $false already and still have a small number of mailboxes enabled for EWS. The precedence enjoyed by the mailbox setting allows these mailboxes to access EWS, but once Microsoft removes the precedence, those mailboxes will lose the ability to use EWS.

The solution is to update the organizational setting back to $true. It might seem counterintuitive to allow EWS for the tenant, but the existing access setting for mailboxes will then kick in and only those mailboxes enabled for EWS can continue making EWS API requests.

Check Mailboxes Enabled for EWS

Given that we’re on the final glidepath to the retirement of EWS, it’s a good idea to validate that the set of mailboxes enabled for EWS declines over time. That way you’ll know if the dependency on EWS within the organization is reducing and understand why some mailboxes continue to need EWS. To help, I put together an Azure automation runbook that looks for EWS-enabled mailboxes and emails the details using Exchange High Volume Email (HVE). The email (Figure 1) serves as a nagging reminder for tenant administrators to minimize the set of mailboxes enabled for EWS. Using Azure Automation means that it’s easy to schedule the job to run weekly (or whatever period makes sense) as the clock ticks down to October 1, 2026.

You can download the code from the Office 365 for IT Pros GitHub repository. See this article for more details about running Exchange Online PowerShell in Azure Automation, and this article about using HVE in Azure Automation.

I chose HVE rather than using the Send-MgUserMail cmdlet from the Microsoft Graph PowerShell SDK because there’s an odd bug that stops the latest version of Exchange Online PowerShell module working in version 7.2 runbooks. My Graph setup is based on PowerShell 7, so mixing and matching Exchange Online and the Graph SDK doesn’t work as smoothly as it should for now. Microsoft is aware of the issue. I believe it will be fixed in the next release.

You don’t need to use Azure Automation as a standard script will do the job too. It just seems to make sense to me to have Azure Automation run the job without human intervention. After all, I might forget to check…

Exchange Online PowerShell Assumes Administrators Run Its Cmdlets

My last primer article in the Azure Automation series covered how to send email using the Exchange Online High-Volume Email (HVE) facility. HVE is still in preview (Microsoft is targeting September 2025 for general availability) but it still does a nice job of sending email from scheduled automation jobs.

This article discusses how to create and execute Azure Automation Exchange runbooks using PowerShell cmdlets from the Exchange Online management module. Unlike HVE, which doesn’t require any Exchange cmdlets, Automation accounts that use the Exchange module in their jobs need some special configuration. This is because the Exchange module assumes that anyone running its cmdlets is an Exchange administrator. There’s no concept of least privilege implemented in the module: once a process loads the module, it can act like a human administrator.

Loading Exchange Online PowerShell into an Automation Account

At least, an app can be all-powerful for Exchange if it meets three conditions. First, it can load the Exchange Online management module. For Azure automation accounts, this means that module is loaded as a resource into the account (Figure 1).

At the time of writing, Exchange Online PowerShell only supports PowerShell V5.1 for automation runbooks, so be sure to install that version of the module. Due to module dependencies, you must install the PackageManagement and PowerShellGet modules (loaded jn that order) before installing the Exchange Online module.

Assigning Exchange Online Permissions and Roles for the Automation Account

Second, the service principal for the app must be assigned the Exchange administrator RBAC role. For Azure Automation, this means the service principal for the automation account. The assignment can be done through the Entra admin center (Figure 2) or with PowerShell. Make sure that you select the correct automation account from the set of enterprise applications listed in the picker.

Third, the app must be assigned the Exchange.ManageAsApp permission. This is not a Microsoft Graph permission. It is an Office 365 Exchange Online permission designed to allow apps to act as administrators. The assignment can only be made through PowerShell. Here’s how to do the job with the Microsoft Graph PowerShell SDK:

$ExoApp = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
$TargetSP = Get-MgServicePrincipal -filter "displayname eq 'M365Automation'"
$Role = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$AppRoleAssignment = @{}
$AppRoleAssignment.Add("PrincipalId",$TargetSP.Id)
$AppRoleAssignment.Add("ResourceId",$ExoApp.Id)
$AppRoleAssignment.Add("AppRoleId",$Role.Id)

$RoleAssignment = New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $TargetSP.Id -BodyParameter $AppRoleAssignment
If ($RoleAssignment.AppRoleId) {
  Write-Host ("{0} permission granted to {1}" -f $Role.Value, $TargetSP.DisplayName)
}

Creating a Runbook to use Exchange Online Cmdlets

With the three prerequisites in place, you can create a runbook. To test that everything works as expected, create a V5.1 PowerShell runbook with the following code (replace the organization name with your tenant):

Connect-ExchangeOnline -ManagedIdentity -Organization Office365itpros.com
(Get-OrganizationConfig).DisplayName

Save the runbook and use the test pane to execute it. The output should be the display name for your organization. If that’s all you see, you can go ahead and build out the runbook with code to do more useful work.

As a demonstration, I took the script to report missing properties for user mailboxes and copied it into the runbook. The only changes that I made were:

• Remove the code that checks for an active connection to Exchange Online at the start of the script and replace it with the Connect-ExchangeOnline -ManagedIdentity command.
• Remove the Clear-Host cmdlet (Azure Automation doesn’t have a host to clear).
• Replace the Write-Host cmdlet with Write-Output (Azure Automation outputs everything together (a stream) at the end of a job).
• Remove the code to output the results as an CSV file at the end of the script.

Figure 3 shows the output of the runbook in the test pane. Everything works and we know that there are some mailboxes with missing properties that should be addressed.

Azure Automation can create an output file on the headless server where the runbook executes, but the question is then how to copy the file to somewhere more accessible later. The easy answer is to use HVE to send the file as an email attachment or to include the data in the body of a message. Something more complicated, like creating a file in a SharePoint Online site, will require more effort.

Not So Difficult

Running Exchange Online scripts in Azure Automation isn’t difficult once the initial setup for the automation account is in place. Some tweaking of the script code is probably necessary, but it’s not difficult to make the changes and will become second nature after a while. If you need to run jobs that process large numbers of Exchange objects (like mailboxes), Azure Automation is an excellent platform choice.

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

Use HVE with Azure Automation Runbooks to Send Email

The last article in the series about using Azure Automation with Microsoft 365 showed how to send email with the Send-MgUserMail cmdlet. The cmdlet can create and send messages from a designated user or shared mailbox to any valid SMTP recipient. As explained in the article, the approach works well for communicating details of background processing, such as reviewing audit records for suspicious activity, especially when run as a scheduled job. Computer systems are better than humans at remembering when they have work to do.

HVE and ECS Email Options

An issue raised in the Office 365 for IT Pros GitHub repository about a script I wrote for an article about the Exchange Online High Volume Email (HVE) feature prompted me to think about using HVE in an Azure Automation runbook.

HVE processes email often created by line of business applications or messages intended for high-volume circulation, such as corporate updates or marketing communications. The focus for HVE is internal email. Although HVE can send mail externally, Microsoft restricts external recipients to 2,000 daily per HVE account. The Azure Email Communication Service is a better solution for external email.

The HVE Scenario and Credentials

Let’s put together a scenario to test how to use HVE with Azure Automation. I decided to check a fact published on a website and act depending on the website content. As you might know, we publish monthly updates for the Office 365 for IT Pros eBook. The date of the most recent update and its release both appear on the book’s page (Figure 1).

The runbook uses the Invoke-WebRequest cmdlet to fetch the webpage content. It then parses the page to find the latest published release date. For test purposes, the runbook compares the publication date against a hardcoded date and sends email to a distribution list if it detects a new publication date. In a production environment, the date of the last known update could be stored and updated in a repository like a SharePoint Online list.

HVE supports basic and OAuth authentication. Microsoft plans to remove support for basic authentication for the SMTP AUTH protocol in September 2025. HVE uses a different SMTP endpoint and its traffic is limited to clients that can connect using a HVE account, so it’s unaffected by the deprecation in September. For now, you can pass the username and password for a HVE account to authenticate. When Microsoft removes this capability, the code will need to be updated to fetch an access token to use to authenticate.

I use an Azure Key Vault in the Azure account used for Azure Automation to store the HVE account credentials. Storing information in Key Vault eliminates any need for hardcoded credentials, which is always good.

Outline of the Script to use HVE with Azure Automation

The good news is that an automation account doesn’t need any additional resources to be loaded or consent for any special permissions before it can send email via HVE. The cmdlets necessary to interact with Azure Key Vault are in the AZ modules that Azure Automation automatically maintains for automation accounts (you don’t need to install or update these modules in the same way as you need to manage Microsoft 365 modules). The same is true for the Import-WebRequest and Send-MailMessage cmdlets. Send-MailMessage is now an old cmdlet that Microsoft would like to deprecate, but it works to send HVE messages.

The script goes through these steps.

• Uses a managed identity to connect to Azure.
• Fetches the user credentials for the HVE account from Azure Key Vault and builds a credentials object.
• Retrieves the content of the target web page and checks it to find the last update for the book.
• If an update is found, constructs a message and sends it to the distribution group via HVE (Figure 2).

You can download the complete runbook (script) from the Office 365 for IT Pros GitHub repository.

It was surprisingly easy to put together this proof of concept and demonstrate how to use HVE with Azure Automation. It’s a good example of how a scheduled background process can check if something has changed and take action when necessary. The hardest part was figuring out how to extra the publication date from the website. Once that was done, the code came together quickly because I was able to “borrow” bits from scripts written for previous articles.

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

Code Replacement Deadline for Exchange Legacy Tokens Approaching

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

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

What Happens in February 2025

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

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

Knowing What Add-Ins Are in Use

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

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

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

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

It Would Have Been Better to Start Earlier

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

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

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

Many Ways Exist in Microsoft 365 to Find Inactive Mailboxes

On Tuesday, I posted a link to an old (2018) article explaining how to use message trace data to identify inactive distribution lists. Almost by return, I received a request to ask if it’s possible to use the same technique to find inactive mailboxes. The answer is yes, but before we go any further along that path, we should recognize that other methods exist to detect underused mailboxes, such as analyzing mailbox statistics and Entra ID sign in records or even looking through historical message trace searches to analyze message traffic for the last 90 days.

Looking past email, the Graph usage reports API reveals a ton of data about user activity that can be combined to reveal an in-depth view of how active accounts are across multiple workloads. You could also investigate activity by extracting audit log data for accounts and build a very granular view of exactly what people do in Microsoft 365 over a period. In other words, many ways exist to find inactive mailboxes using different data available to tenant administrators.

Changing the Script to Find Inactive Mailboxes

Not being a great fan of recreating wheels, I took the script written to detect inactive distribution lists and made the necessary changes. You can download the script from GitHub. The major changes are in two areas:

First, the script creates an array of user mailboxes rather than distribution lists. If you want to check activity for shared mailboxes, modify the script to include shared mailboxes in the receipt type details parameter for Get-ExoMailbox:

[array]$Mbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails 'UserMailbox', 'SharedMailbox' | Sort-Object DisplayName

Second, the script extracts message trace Delivered events rather than Expanded events. Expanded events are good for distribution lists because they happen when Exchange Online resolves the distribution list membership to create bifurcated copies of messages for delivery to individual recipients. Delivered events occur when Exchange Online successfully delivers a message. The script extracts details of the sender for these events on the basis that an active mailbox sends messages (which is what Figure 1 shows the script reporting). Inactive mailboxes might receive a ton of messages, but unless they send a message, they’re not really active.

Generating Report Files

The script checks for the availability of the ImportExcel module. If found, the output file generated by the script is an Excel worksheet. Otherwise, the script creates a CSV file. The ImportExcel module is very easy to use and the worksheets it creates are nicer to work with in Excel than the CSV equivalent.

The code is straightforward. The Get-Module cmdlet checks for the module. If found, the output file name in the Downloads folder for the current user is generated. It’s easier to use the Downloads folder instead of checking for an arbitrary folder like “c:\temp\” and creating the folder if not available.

# Generate report
If (Get-Module ImportExcel -ListAvailable) {
    $ExcelGenerated = $True
    Import-Module ImportExcel -ErrorAction SilentlyContinue
    $OutputXLSXFile = ((New-Object -ComObject Shell.Application).Namespace('shell:Downloads').Self.Path) + "\InactiveMailUsers.xlsx"
    $Report | Export-Excel -Path $OutputXLSXFile -WorksheetName "Inactive Mail Users Report" -Title ("Inactive Mail Users Report{0}" -f (Get-Date -format 'dd-MMM-yyyy')) -TitleBold -TableName "InactiveMailUsers" 
} Else {
    $OutputCSVFile = ((New-Object -ComObject Shell.Application).Namespace('shell:Downloads').Self.Path) + "\InactiveMailUsers.csv"
    $Report | Export-Csv -Path $OutputCSVFile -NoTypeInformation -Encoding Utf8
  }
  
  If ($ExcelGenerated) {
    Write-Host ("An Excel report is available in {0}" -f $OutputXLSXFile)
  } Else {
    Write-Host ("A CSV report is available in {0}" -f $OutputCSVFile)

More to Do to Improve the Script

I’m sure that people will find ways to improve the script. For instance, you might decide to include details of the account that owns each mailbox, like their country or department. The beauty of PowerShell is that it’s easily changed. Go for it!

subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

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.

Exchange Online Security Updates Focus on EWS, Public Folders, Mail Transport, and More

On November 18, as interest in the Microsoft community turned to the marketing fest at the Ignite conference in Chicago, Microsoft released an interesting technical community post covering security updates for Exchange Online. Given the fundamental role that email plays within Microsoft 365, this is a topic that every tenant needs to pay attention to.

Many of the items listed are restatements of previous news, like the February 2025 deprecation of the App Impersonation RBAC role (I covered this point as a footnote in yesterday’s article). Basically, this is a role that allows Exchange Web Services (EWS) apps to access mailboxes. Microsoft wants to remove the role because it can be a vector to potential mailbox compromise. The problem is that tenants might be unaware that the role is used by an app or script. Microsoft has a PowerShell script to locate accounts that hold the role. It’s worth running the script, just in case.

It’s worth noting that equivalent Graph permissions are available to access content in user mailboxes. Microsoft answer is that tenants should use RBAC for Applications to restrict app access to the set of mailboxes that need to be processed. I agree.

Microsoft restated the plan to remove EWS from Exchange Online in October 2026, noting that the change will break any app based on EWS. Originally, Microsoft originally planned to implement an exception to allow their own EWS-based apps to continue running, but now they say that they’ll phase out EWS well before October 2026.

Gaps in Graph Coverage for EWS Functionality

More interestingly, Microsoft points to known gaps where Microsoft Graph APIs are not capable of taking over from EWS today. They say that they are working to support access to archive mailboxes, but don’t have a delivery date. I imagine that the Exchange admin center will need this API to perform tasks like enabling archives, reporting archive mailbox size, and so on.

Microsoft also noted that they will soon release Graph support for Application settings for Exchange client applications to cover user configuration and folder associated information (FAI). User configurations and FAIs are stored in mailboxes and used to hold settings needed by applications. I imagine that this work involved an extension of the current Graph support for mail items.

The big news in the announcement is that Microsoft says that they cannot deliver Graph support for “several admin features that are available to developers via EWS,” such as setting folder permissions or managing delegates for user mailboxes. Once EWS is deprecated, developers who implement these features in their apps will have to find a different way, perhaps by calling PowerShell using Azure functions.

The rate of progress towards Graph API support for Exchange Online has disappointed in the recent past. If Microsoft want a successful transition from EWS, they need to do better in terms of coverage.

The Final Demise of Public Folders

In terms of the “cockroaches of Exchange”, Microsoft says that they will no longer provide APIs to programmatically manage public folders after the removal of EWS in October 2026. I assume Microsoft thinks it’s simply not worthwhile to recreate public APIs for public folders because of low usage. Public folders were hot technology when Exchange 4.0 appeared in 1996 and have been on a downhill slope ever since. Despite suitable efforts to eradicate public folders over many years, use persists in a small number of Exchange Online tenants. Microsoft will continue to provide access via “supported” Outlook clients and for bulk import/export.

I presume that the new Outlook for Windows will support public folders. An option is available to add one or more public folders to Outlook favorites but the button to actually add the folder is missing. Maybe Copilot for Outlook didn’t like it. No doubt the button will show up before Microsoft removes for support for Outlook classic sometime after 2029.

I’m not sure if tenants will take the news as a broad hint that they should get off public folders (they should). It’s just sad that the tools to analyze the data in public folders and move what needs to be kept to a more modern alternative are so weak.

Exchange Online Security Updates in Mail Transport

Rounding out the post, Microsoft covers a bunch of recent improvements around DNSSEC and DANE. The news is that Mandatory Outbound SMTP DANE is coming in May 2025 with per-tenant and per-domain settings. Microsoft didn’t cover other efforts to increase the security of the Exchange Online email service, like the introduction of the external recipient rate limit (due on January 1, 2025, except for GCC, GCC-High, and DOD tenants as shared in an update to MC787382) or the continuing effort to force hybrid tenants to upgrade on-premises servers to a supported version before email can flow across a connector to Exchange Online.

Finally, Microsoft notes that they recently added OAuth support to the preview of the High Volume Email feature (HVE). This summer, I spent some time working with HVE and ECS, the Azure Email Communication service. Both can do a job for tenants that needs to send bulk email, with HVE a better option for internal-focused email and ECS more suitable for outbound communications. You can read more, including sample PowerShell to send email via HVE and ECS, on Practical365.com.

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.

A Truly Horrible Name for What’s a Pretty Good Way to Stop User Mailboxes Being Removed in Error

On November 5, the Exchange development group announced the new delicensing resiliency feature. Unfortunately, the blog post for the announcement went out at the same time that the Microsoft Technical Community was in the middle of a major upgrade (it was offline for most of the day), so you might not have seen the news.

Delicensing resiliency is a horrible name for a feature. What it means is that large Exchange Online tenants (with more than 10,000 paid seats) can enable an extra layer of protection for unlicensed mailboxes. Most users are licensed for Exchange Online through a service plan included in a product SKU like Office 365 E3 (Figure 1) or Microsoft 365 Business Premium. An Exchange Online license can be bought separately, but that’s usually only done to enable features like an archive for shared mailboxes.

When a product license containing the Exchange Online service plan is removed from an Entra ID user account, Exchange Online notices that the user’s mailbox is no longer licensed and starts a 30-day countdown clock. Because it is no longer licensed, the user loses access to the mailbox. However, if an administrator assigns an Exchange Online license or service plan to the account, the mailbox reverts to a licensed state and normal service is resumed. If not, Exchange Online proceeds to permanently remove the mailbox and data is no longer recoverable.

One way that organizations guard against inadvertent removal of mailboxes is to make the mailbox into an inactive mailbox by applying a retention hold to the mailbox before removing licenses (or complete account deletion). This mechanism works and supports both mailbox recovery and restore, but the affected users lose access to their mailbox because it’s in an unlicensed state.

Group Licensing Errors

What seems to have happened in the past is that some tenants have made mistakes with group-based licensing. This mechanism allows a group to hold licenses that Entra ID assigns automatically to users when they join the group. Conversely, when someone leaves the group, Entra ID removes the license held by the group.

Exchange Online has supported license stacking since January 2023. License stacking means that a user account can be assigned several licenses of the same type. For instance, they can hold Office 365 E5 and Microsoft 365 E5 licenses, both of which come with an Exchange Online Plan 2 service plan. If one license is removed, the second license remains in place and the user’s mailbox is unaffected. License stacking facilitates license swapping or switching, which happens when a tenant upgrades its licenses and needs to assign new licenses to users while removing old licenses.

It’s possible that some license swaps went wrong in the past due to errors made in group-based assignments. Perhaps users were removed from the group that controlled assignments of the old license without being added to the group that controlled assignments for the new license. It’s easy to see how such a thing could occur. The upshot is that accounts removed from the original group enter an unlicensed state for Exchange Online and lose access to their mailboxes, which is not a great situation to be in as it disrupts internal and external communications and can cause users not to receive email.

The Extra 30-Day Grace Period

Microsoft’s solution is to introduce an additional 30-day grace period during which unlicensed mailboxes remain fully functional. The extra time is intended to allow administrators to realize that a problem has occurred and take appropriate action, which might be something as simple as adding the affected users to a group.

After the 30-day grace period lapses, the normal mailbox removal process clicks into gear and the user loses access to their mailbox. Eventually, the 30-day removal retention period expires, and Exchange Online removes the mailbox permanently.

Tools to Help with Delicensing Resiliency

To back up the extra grace period, Microsoft is providing several tools, including:

• A new Get-PendingDelicenseUser cmdlet to check for mailboxes due to be delicensed.
• A new Licenses removed recently tab in the Billing section of the Microsoft 365 admin center to list mailboxes in the grace period (with an option to expedite delicensing for a mailbox, meaning that it goes straight into the normal 30-day removal cycle).
• Service Health advisories for admins when “delicensing activity” occurs (presumably only when the delicensing resiliency feature is enabled and only covering Exchange Online licenses)
• Email notifications to users whose Exchange Online license has been removed telling them to contact their administrator if the removal was in error.

Overall, it seems like a pretty good plan. Of course, I followed the instructions in the documentation to see what happened if I enabled the feature and failed utterly:

Set-OrganizationConfig -DelayedDelicensingEnabled:$true

Set-OrganizationConfig: |Microsoft.Exchange.Management.Tasks.DelayedDelicensedUserException|Your tenant does not qualify for the Exchange Online Delicensing Resiliency feature, which is only available to tenants with more than 10,000 paid licenses.

Oh well. Most mailboxes removed in my tenant are as a result of my actions. I guess I don’t need to worry so much about this kind of thing. But if I was running a tenant with more than 10,000 paid Exchange seats, this is absolutely a feature to enable.

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.

EAC Upgrade Distribution List Feature is Terrible

I met Tim McMichael at the recent TEC 2024 event in Dallas. Tim works for Microsoft as a senior escalation engineer. He’s the kind of person whom you don’t want to meet during a support incident because if you do, it means that you have a very sick Exchange environment. In any case, Tim also maintains an excellent utility for migrating on-premises distribution list to Exchange Online. The utility has been around for a while (I last mentioned it in 2018), which is testament to Microsoft’s (the engineering group) disinterest in this topic.

All of which brings me to MC510333 (last updated 27 April 2023), which describes the facility in the Exchange Admin Center to upgrade a distribution list to a Microsoft 365 group. I ignored this update for a long time, mostly because the feature took forever to arrive but also because it’s terrible. The feature never worked any of the times I’ve tried to use it. The documentation is also poor.

Testing the Upgrade Distribution List Feature

The upgrade distribution list feature works as follows:

An administrator initiates the upgrade by selecting the distribution list in the EAC and taking the Send upgrade request option (Figure 1).

The Send upgrade request action invokes a dialog (Figure 2) to send the upgrade request to the distribution list owners. Only one owner must be selected and EAC uses the signed-in user’s credentials to create and send the message from their mailbox. You can’t edit the message text, which seems like a missed opportunity to allow tenants to add their own information to the message.

The upgrade request duly arrives in the inbox of the selected recipients. The message content seems to be an adaptive card (Figure 3). Pressing the upgrade button starts a background process to upgrade the selected distribution list to a Microsoft 365 group. Microsoft says that this process should take no longer than 10 minutes.

In my experience, either nothing happens – even after hours of patient waiting – or an error is immediately detected and the adaptive card reports an upgrade process failure (Figure 4).

I’ve only ever attempted to upgrade distribution lists that meet the criteria (membership composed solely of user accounts and cloud-based). All of the distribution lists I tried to upgrade were in the set reported as eligible for upgrade by the Get-EligibleDistributionGroupForMigration cmdlet.

I also tried to upgrade distribution lists with the Upgrade-DistributionGroup cmdlet. Despite successfully submitting a distribution list to be upgraded, nothing happened and the same feeling of dealing with black box occurred. I suspect that Exchange Online invokes the cmdlet when a distribution list owner presses the Upgrade button in the adaptive card as described above.

Upgrade-DistributionGroup -DlIdentities Conference.Organizers@office365itpros.com

dlIdentity                      : Conference.Organizers@office365itpros.com
ErrorReason                     :
ExternalDirectoryObjectId       : 58ad00b8-4800-48b9-b698-52467635ccf4
SuccessfullySubmittedForUpgrade : True
Identity                        :
IsValid                         : True
ObjectState                     : Changed

I never managed to convert a distribution list. Maybe the problem lies in the fact that my tenant is part of a multi-tenant organization (MTO). Perhaps having several fallback domains might affect the ability of the conversion process to work. But who knows? The lack of feedback and error messages makes any attempt to diagnose an exercise in guesswork.

Overall, the upgrade group type feature is the most frustrating part of EAC. It’s not helped by the paucity of documentation to describe what to do next (apart from contacting your administrator for assistance) when problems happen. The only page available cites reasons for upgrade failure like distribution lists with more than 100 owners or no owner. The page doesn’t cover problems upgrading a distribution list with one owner and three members, all of whom are user accounts in a cloud-only tenant.

Stay with Distribution Lists

Leaving the problems of the feature to one side, I do not recommend that organizations “upgrade” distribution lists to Microsoft 365 groups unless a solid technical and business reason dictates that the resources provisioned for a Microsoft 365 group are required. In many cases, the SharePoint Online site created for a distribution list when it’s upgraded to be a Microsoft 365 group is never used. The empty site takes some 60 MB of valuable SharePoint storage quota and clutters up the tenant.

Distribution lists that are used for email communication are more powerful in this respect than Microsoft 365 groups because they can include members other than user accounts, such as other distribution lists, mail users, mail contacts, public folders, and even Microsoft 365 groups. Ignore Microsoft’s silly recommendation that Microsoft 365 groups offer more collaboration tools (which are useless unless the tools are needed) and keep on using distribution lists the way they’ve always been used by email servers.

No One Uses the Upgrade Distribution List Feature

The current feature replaced a previous version that also had problems before Microsoft withdrew it from Exchange Online. I don’t know why upgrading a distribution list is such an intractable problem. Maybe Microsoft should ask Tim McMichael to fix the problems. At least he knows how to migrate stuff.

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.

Amend a PowerShell Script to Import Contacts from a CSV File

Being a creature of habit, my practice is to write about shorter topics here and keep long-form articles that address complex topics for Practical365.com. Those topics often include discussion about using PowerShell to automate operations and involve a script that I publish in the Office365ITPros GitHub repository. The idea in writing scripts is to illustrate the principles of the topic under discussion, not to deliver a complete solution. I expect people to take the code and change it to meet their needs.

All of which brings me to an article where I cover how to read data from a list in a SharePoint Online site and use the information to create personal contacts in user mailboxes. I like the idea because I think a list is a good way to maintain information. Others obviously disagree, because soon after publication, I received a note saying that keeping stuff in a list is too complex (from the scripting perspective) and could they have a version that reads the input from a CSV file?

The Joy of Publishing PowerShell Scripts

Authors who write about PowerShell and include code snippets or complete scripts in their text often find that people reach out to ask for changes to be made. It’s as if you’re an online script generation service. For instance, after writing about how to create a licensing report for Microsoft 365 accounts, I received multiple requests for enhancements. Most of the ideas were very good and I was happy to incorporate the changes, which is why the script is now at version 1.94.

In some respects, generative AI has taken over as the go-to place to get advice about writing PowerShell. In any case, because generative AI depends on knowledge captured in its LLM from previous scripts, articles, and blog posts, it has a nasty habit of getting things wrong. Copilot seems prone to creating cmdlets that don’t exist and recommending their use to solve a problem. However, people do like the fact that it’s often easier to ask AI about a script than to track down an author.

Getting back to the original point, when an author receives a request to change code that they’ve published, they can ignore the email, tweet, or whatever platform was used to reach out to them or respond. If you want an author to help, you can prepare the ground by attempting to make the change yourself and explaining exactly why you think the change will be valuable. The desired outcome is more likely if you demonstrate that you’ve tried to understand and amend the code, and that good logic underpins the request.

Script Change to Import Contacts from a CSV File

In this instance, lines 20-46 of the script are where the input data is fetched from the SharePoint Online list. If you want to use a CSV file instead, you can throw away those lines and add something like this:

$ImportFile = 'c:\temp\Contacts.csv'
[array]$Itemdata = Import-Csv $ImportFile

These lines import data from a CSV file to the array used to populate contacts in user mailboxes. If the input CSV has the correct columns, then that’s all you need to do. The script will run and add the contacts to the target mailboxes.

Figure 1 shows an example of a CSV file in Excel. The column names are those expected by the script. If you don’t include the column headings or use different names, the script won’t know how to map properties from the CSV file to the contact records and it won’t be possible to import contacts.

A Quick Change to Switch Source of Import Contacts from SharePoint Site to a CSV File

Making the change took me about five minutes, three of which were to fix a bug where the hash table used by the script to detect if a contact already exists didn’t handle duplicate contacts with the same name. I’d created the duplicates to test how well the new Outlook suppresses duplicate contacts and forgot to remove them. It just shows how developing PowerShell scripts can be an iterative process.

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. The Office 365 book package now includes the Automating Microsoft 365 with PowerShell eBook.

Modernized Get-Mailbox Cmdlet Versus REST Get-ExoMailbox Cmdlet

In November 2019, Microsoft introduced a set of REST-based cmdlets designed to improve the performance and stability of the most frequently used PowerShell actions conducted against Exchange Online. The new set didn’t use Remote PowerShell and incorporated functionality like pagination (like Graph API requests). Given its usage in many scenarios, the Get-ExoMailbox cmdlet is possibly the poster child for the REST cmdlets. Many tests were run, usually successfully, to validate its performance advantages over the older Get-Mailbox cmdlet.

Get-Mailbox Still in Active Use

Five years on, I still see people use Get-Mailbox in their scripts. I was recently quizzed about the enduring nature of the older cmdlet. It’s a good question. Despite my advice, many chose to leave Get-Mailbox untouched in their scripts on the basis that if something isn’t broken it shouldn’t be touched. Get-ExoMailbox behaves differently, especially in how it fetches mailbox properties. In a nutshell, Get-ExoMailbox fetches just fifteen of the hundreds of available mailbox properties, so if you want a property like InPlaceHolds or ArchiveStatus, you must request them:

[array]$Mbx = Get-ExoMailbox -Properties Office, InPlaceHolds, ArchiveStatus

It’s all too easy to forget to request a property. I can appreciate that perspective because I’ve fallen into the unrequested property hole myself.

Another reason why people stick with Get-Mailbox is that Microsoft has modernized the older cmdlets to remove dependencies like basic authentication and remote PowerShell. I’ve heard the feeling expressed that if Microsoft puts time and effort into upgrading a cmdlet, it must be a good sign that the cmdlet can safely be used. And yes, Get-Mailbox is very safe to use.

The question then is when to use Get-Mailbox and when to opt for its turbo-charged version? I propose a simple guideline:

• When you’re working interactively with less than five mailboxes, use Get-Mailbox. The cmdlet will fetch all available mailbox properties, but that’s OK because relatively few objects are involved. In addition, requests don’t need to page to find more data and the chances of time outs or other known problems are small when fetching a small number of mailboxes.
• Anytime else, use Get-ExoMailbox. That means all scripts and Azure Automation runbooks should use Get-ExoMailbox. Scripts should include the best possible code and that means using the best possible cmdlets. The issue with requesting the correct set of properties shouldn’t occur because the testing of the script will highlight any problems in this area.

The same rule of thumb applies to the other REST cmdlets like Get-ExoMailboxStatistics, Get-ExoMailboxFolderStatistics, and so on. I have a lingering suspicion that Microsoft will dedicate more tender loving care to the REST cmdlets than their older counterparts. It’s probably not true, but stranger things have happened.

The Importance of Server-Side Filtering When Fetching Mailboxes

While I’m at it, let me advance another golden rule for use with either Get-Mailbox or Get-ExoMailbox: never use a client-side filter when a server-side filter is available. The reason is that a server-side filter is always faster than applying a client-side filter after retrieving all possible matching data over the network.

I review many articles and it’s surprising when a code example is submitted that abuses the server-side principle. For example, this server-side filtered command:

[array]$MBx = Get-ExoMailbox -filter {Office -eq 'New York'} -Properties Office

is much faster than:

[array]$Mbx = Get-ExoMailbox -Properties Office -ResultSize 1000 | Where-Object {$_.Office -eq 'New York'}

The exact performance advantage depends on the number of objects that are retrieved, but I have never seen a case when a client-side filter wins. Use the Measure-Command cmdlet to measure the speed advantage by running commands against mailboxes. This article has more information about using filters with Get-ExoMailbox.

A PowerShell Principle

The principle of using server-side filters extends anywhere PowerShell fetches data from a server, including using Microsoft Graph PowerShell SDK cmdlets. If you see the Where-Object cmdlet being used to extract a set of objects from a larger set, ask if the larger set could have been reduced with a server-side filter. In many cases, it can, and if a server-side filter can be applied, your scripts will run faster, no matter if you use Get-Mailbox or Get-ExoMailbox (but use the latter).

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.

A Different Way to Report Items Stored in Recoverable Items

Yesterday’s article about reporting items stored in the Recoverable Items structure in mailboxes provoked some questions. Some were surprised that it is possible for administrators to get this level of detail about retained items from user mailboxes, but the items are the same kind that users process, so the APIs work as well for the items held in Recoverable Items as they do for folders like the inbox, sent items, and so on. On a serious note, RBAC for applications is the best way to curtail application access to sensitive mailboxes, including whatever they hold in Recoverable Items.

One of my MVP colleagues pointed out that a lot of the information I discussed could be retrieved using the Get-RecoverableItems cmdlet. That’s true, if you are only interested in certain item properties and certain folders. Using the Graph APIs supports full access to item properties in all folders, and that’s where the major advantage lies.

Let me explain what I mean. Microsoft built the Get-RecoverableItems cmdlet to allow administrators to recover items on behalf of users. The recovered items go back into the parent folder from where they were deleted. The intention behind the cmdlet is that it is used in tandem with the Restore-RecoverableItems cmdlet. In other words, the items found by Get-RecoverableItems can be restored by Restore-RecoverableItems.

Creating a Script Based on Get-RecoverableItems

Getting back to the point in hand, the observation made was that you could use Get-RecoverableItems to retrieve item information for reporting purposes, just like I did with the Graph. However, the available data is different. This might or might not be a problem.

To illustrate the issue, I created a version of the script using Get-RecoverableItems. You can download the script from GitHub. The script:

• Connects to Exchange Online. You must use an account that holds the Exchange mailbox import-export role as this is required to run the Get-RecoverableItems cmdlet.
• Finds user mailboxes.
• Runs Get-RecoverableItems for each mailbox to find items in the Deletions folder in Recoverable Items for the last year. By default, Get-RecoverableItems fetches items from Deleted Items, Deletions, and Purges. The Graph-based version of the script only processes Recoverable Items folders including Versions and SubstrateHolds that aren’t exposed to Get-RecoverableItems.
• Create a report of the results (Figure 1) and export the results to a CSV file.

Different Data Reported

Looking at the data shown in Figure 1, some of the item properties are common with those available via the Graph SDK (mailbox name and item subject). The last modified time is in U.S. format, so the script reformats the date. The last parent property is the folder that the item was deleted from, and the item class is the MAPI type. Looking at the items returned from my mailbox, I see the following types (IPM.Note is a regular message).

$Items | Group-Object ItemClass -NoElement | Sort-Object Count | Format-Table Name, Count

Name                                 Count
----                                 -----
IPM.Schedule.Meeting.Resp.Tent           1
IPM.Task                                 1
IPM.Note.Rules.OofTemplate.Microsoft     3
IPM.Note.SMIME.MultipartSigned           4
IPM.Schedule.Meeting.Canceled            9
IPM.Post.Rss                            27
IPM.Schedule.Meeting.Resp.Pos           27
REPORT.IPM.Note.NDR                     89
IPM.Schedule.Meeting.Request            92
IPM.Appointment                        180
IPM.Note                              4305

The properties for a full item returned by Get-RecoverableItems looks like this:

LastParentPath       : Calendar\Planner-Microsoft 365 Message Center
LastParentFolderID   : 37B5390C4C3298448EB307D556E7D40D000392D3F3B3
OriginalFolderExists : True
Identity             : Tony.Redmond@office365itopros.com
MailboxIdentity      : a662313f-14fc-43a2-9a7a-d2e27f4f3478\0370f354-2752-4437-878d-cf0e5310a8d4
ItemClass            : IPM.Appointment
Subject              : [Microsoft 365 for the web] (Updated) Loop components in Microsoft OneNote [MC777847]
PolicyTag            : 59c7aa03-6579-4008-b484-e8ed327c3b69
EntryID              : 000000007EEC82E914DC7C4EB92D68AF156167AB07005EF42BB02DCD9F4CAED6E3A2F5480A7D000000DA5215000037B5390C4C3298448EB307D556E7D40D00078B11E96B0000
SourceFolder         : Recoverable Items\Deletions
LastModifiedTime     : 08/16/2024 21:15:03
IsValid              : True
ObjectState          : New

The properties for an item returned by the Graph looks like this. Many of the properties are blank because I did not fetch the information.

Attachments                   :
BccRecipients                 :
Body                          : Microsoft.Graph.PowerShell.Models.MicrosoftGraphItemBody
BodyPreview                   :
Categories                    :
CcRecipients                  :
ChangeKey                     :
ConversationId                :
ConversationIndex             :
CreatedDateTime               : 12/09/2024 16:53:39
Extensions                    :
Flag                          : Microsoft.Graph.PowerShell.Models.MicrosoftGraphFollowupFlag
From                          : Microsoft.Graph.PowerShell.Models.MicrosoftGraphRecipient
HasAttachments                :
Id                            : AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNABGAAAAAAB_7ILpFNx8TrktaK8VYWerBwBe9CuwLc2fTK7W46L1SAp9AAAA2lIaAAA3tTkMTDKYRI6zB9VW59QNAAechaYpAAA=
Importance                    :
InferenceClassification       :
InternetMessageHeaders        :
InternetMessageId             :
IsDeliveryReceiptRequested    :
IsDraft                       :
IsRead                        :
IsReadReceiptRequested        :
LastModifiedDateTime          :
MultiValueExtendedProperties  :
ParentFolderId                :
ReceivedDateTime              :
ReplyTo                       :
Sender                        : Microsoft.Graph.PowerShell.Models.MicrosoftGraphRecipient
SentDateTime                  :
SingleValueExtendedProperties : {Long 0xe08}
Subject                       : Undeliverable: Size limit for HVE
ToRecipients                  :
UniqueBody                    : Microsoft.Graph.PowerShell.Models.MicrosoftGraphItemBody
WebLink                       :
AdditionalProperties          : {[@odata.etag, W/"FwAAABYAAAA3tTkMTDKYRI6zB9VW59QNAAeYsZ/A"]}

It’s obvious that the two sets of properties are very different. Because the Graph provides data to clients, the Graph set includes the item body and a body preview together with a bunch of flags for the item status, like isRead or isDraft. The set includes a single value extended property for the item size. By comparison, the set retrieved by Get-RecoverableItems are designed to help a user or administrator decide which items to restore and no more.

The Bottom Line

Two methods are available to tenant administrators who need to know about the items held in the Recoverable Items structure. The Graph API can reveal more information about individual items, especially the actual content of an item, but the Get-RecoverableItems cmdlet is a viable candidate to use if you only need to know bare details like the sender, date, and subject. Isn’t it nice to have choice!

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.

Ability to Restore Deleted Groups Depends on Graph APIs

Yesterday, I covered a gap that exists between the Purview development group and the Exchange Online development group when it comes to applying scoped roles to audit log searches. Today, a blog post by ex-MVP Tony Murray-Smith reminds me about another functionality gap that exists in the area of groups. The problem described occurred when a user deleted a security group by mistake only to discover that the Entra admin center doesn’t support a method to restore deleted groups of this type.

In fact, Microsoft 365 groups are the only type of group that Entra supports for restoration via its admin center. There’s no way to restore a deleted distribution list, dynamic distribution list, security group, or mail-enabled security group. Apart from dynamic distribution lists, these objects are recognized by Entra ID and accessible through the Groups API. However, the only group objects supported by the List Deleted Items and Restore Deleted Items (directory objects) APIs remain Microsoft 365 groups. And if a Graph API isn’t available to support restoration, the administrative portals cannot create functionality from thin air.

This situation has persisted since the introduction of cmdlets to restore deleted Microsoft 365 groups in 2017 followed by a GUI option in the Exchange admin center, Microsoft 365 admin center, and Entra admin center. Microsoft subsequently removed the option to restore deleted groups from the new EAC, so the current GUI-based options to restore deleted Microsoft 365 groups are in the Entra admin center and Microsoft 365 admin center. And if you want to use PowerShell, there’s the Restore-MgDirectoryDeletedItem cmdlet.

The Gap Between the Exchange DS and Entra ID

The question is why Entra ID only supports the restoration of Microsoft 365 groups. I think the answer lies in two parts. First, the desire within Microsoft to make its brand-new cloud-only Office 365 groups (now Microsoft 365 groups) the “best group for everything” following their launch at the Ignite conference in May 2015.

The infrastructure to fully support Microsoft 365 groups took time to develop, and building the capability to reconnect all the different resources that a group might use made the process more complicated for Microsoft 365 groups. Being able to restore SharePoint Online, Teams, the group mailbox, and so on was a big undertaking that Microsoft quickly discovered needed to be tackled after the launch of Office 365 groups, especially after some early customers discovered that they couldn’t be restored. The functionality duly arrived in 2017. The campaign to make Microsoft 365 groups do everything is far less intense now than it was some years ago, but its legacy is evident sometimes.

The EXODS Objects

The second issue is heritage. Distribution lists and mail-enabled security groups originated in Exchange Server. Exchange Online still has its own directory (EXODS) to store details for mail-enabled objects. Synchronization and dual-write update operations keep Entra ID and EXODS aligned so that updates performed in one directory synchronize immediately to the other. The Graph APIs support distribution lists and security groups, including mail-enabled security groups, but Entra ID and the Graph APIs ignore dynamic distribution lists and can’t update settings for distribution lists and mail-enabled security groups because these objects are homed within Exchange Online.

Good reasons exist for why the differentiation exists. Dynamic distribution lists require Exchange Online to resolve their membership because the membership supports objects like mail-enabled public folders that don’t exist in Entra ID. Dynamic distribution lists also support nested lists. Regular distribution lists and their mail-enabled security group variants have many settings that aren’t supported in Entra ID, like message approval.

As far as I can remember, it has never been possible to restore deleted distribution lists (and some of the online answers are very misleading, like this example). Once an administrator removes a distribution list, it’s gone. The only thing that can be done is to recreate the distribution list from scratch. That might be possible if someone knows the membership and the list settings, but that might not be the case.

Some Work Necessary in This Area

Microsoft should do some work to make it possible to restore all forms of deleted groups. That work will need contributions from teams responsible for Entra ID, the Graph API, and Exchange Online. Mistakes do happen and administrators remove important distribution lists or mail-enabled security groups when they shouldn’t. Being told that it’s necessary to recreate an object from scratch is a royal pain, and it’s something that shouldn’t still be a problem in 2024. Customers assume that if they can restore one type of deleted group, they should be able to restore any type of deleted group.

Then again, other pains exist around distribution list management, like the Microsoft’s failure to produce a utility to move distribution lists from on-premises servers to the cloud. Tim McMichael’s DLConversionV2 solution is the best available. He’ll be discussing distribution list management at TEC 2024 in Dallas in October. Maybe I should ask Tim about restoring groups that aren’t Microsoft 365 groups.

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.

Identify Problematic Shared Mailboxes using Sign-in Logs

Exchange Online shared mailboxes have Entra ID accounts. The accounts have passwords and people can sign-into the account and start a mail client that’s connected to the shared mailbox to process email. Is this a problem? Absolutely!

Shared mailboxes don’t require Exchange Online or any other licenses unless the mailboxes have an archive, need more than 50 GB quota, use litigation hold, or are subject to Purview retention policies. As stated in the Microsoft service description:

“To access a shared mailbox, a user must have an Exchange Online license, but the shared mailbox doesn’t require a separate license.”

No Need Exists to Sign Into Shared Mailboxes

Shared mailboxes are intended for joint access by multiple users whose connections are controlled by permissions managed by Exchange Online. Full Access permission allows a user full control over all mailbox folders and items while Send As or Send on Behalf Of allows them to send email from the mailbox. No need exists to sign into the Entra ID accounts for shared mailboxes, and if you sign into an unlicensed shared mailbox, you violate Microsoft licensing terms.

One reason I have heard advanced to justify signing into a shared mailbox is after someone leaves the organization and their mailbox is converted to a shared mailbox. If the mailbox includes some information that’s important to the organization, another user might need to sign into the mailbox to retrieve the data. I don’t buy this logic. Granting Full Access permission to the mailbox is sufficient to review the items stored there. I prefer to use inactive mailboxes to preserve ex-employee content instead. It’s just a cleaner solution.

Microsoft documentation says:

“A shared mailbox is a type of user mailbox that doesn’t have its own username and password. As a result, users can’t log into them directly.”

This is factually incorrect. Every shared mailbox has an ExternalDirectoryObjectId property that points to its Entra ID account. This PowerShell snippet uses the property to report the user principal names for the accounts:

$Mbx = Get-ExoMailbox -RecipientTypeDetails SharedMailbox -ResultSize Unlimited | Sort-Object DisplayName
ForEach ($M in $Mbx) {
    $User = Get-MgUser -UserId $M.ExternalDirectoryObjectId
    Write-Output ("Mailbox {0} has Entra ID account {1}" -f $M.DisplayName, $User.UserPrincipalName)
}
Mailbox Admin-RA-Shared has Entra ID account admin-ra-shared@office365itpros.com
Mailbox Azure Management Account has Entra ID account Azure.Management.Account@office365itpros.com

Changing the password and enabling the accounts to allow users to sign into the accounts is easy. If you don’t want to use PowerShell, you can select the account in the Microsoft 365 admin center and perform the actions there (Figure 1).

Checking for Illegal Shared Mailboxes

Life isn’t perfect and people make mistakes. It’s possible that a tenant has some shared mailboxes that fall in a technically illegal state because people sign into the mailbox instead of connecting using mailbox permissions. To detect these situations, we can use the Get-MgAuditLogSignIn cmdlet to check if any sign-in records exist for the mailbox accounts. The account running the script must have an Entra ID P1 license to access the audit log records.

To illustrate the point, I wrote a script (downloadable from GitHub) to find shared mailboxes and check if they’ve been signed into. If so, a further check establishes if the mailbox’s account is licensed with Exchange Online Plan 1 or Plan 2. The output is shown in Figure 2.

Fortunately, the two mailboxes with detected sign-in records both have Exchange Online Plan 2 licenses, so they’re in compliance.

Other Checks

Microsoft doesn’t check shared mailboxes where other license requirements arise, like those with archive mailboxes or those on litigation hold. If you want to scan for those conditions, the necessary code is covered in this article. It wouldn’t take much to combine the two scripts to have one script that checks everything. I’ll leave that as an exercise for the reader.

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.

HVE and ECS Compete for Different Customers of Microsoft Cloud Email Services

I need to apologize to some of the subscribers to the Office 365 for IT Pros eBook. Over the last few weeks, I’ve been using you as the targets for emails sent using Exchange Online High-Volume Email (HVE) and the Azure Email Communication Service (ECS).

Both solutions focus on sending large quantities of email. HVE is more internal-focused but can handle external messages. HVE is part of Exchange Online and intended to help customers move off on-premises servers to handle traffic generated by multi-functional devices and applications. ECS is a standalone offering that can handle large volumes of external email such as newsletters, subject to thresholds set by Microsoft. According to Microsoft, ECS is very popular and handles large amounts of messages daily.

HVE is in preview and is free to use today. When it’s generally available, HVE will likely cost for some traffic. ECS is already a pay-as-you-go service that must be funded by an Azure subscription.

Seeking Test Email Targets for Microsoft Cloud Email Services

When setting out to test the effectiveness of emailing solutions, you need large numbers of target recipients. Little is to be learned by sending a couple of messages to a few internal recipients. To run a better trial, I decided to use HVE and ECS to send reminder messages to subscribers of the 2024 edition of the Office 365 for IT Pros eBook to ask if they wanted to take advantage of an offer to extend their subscription. Sending email to ask people to buy something or take out a subscription seemed like a pretty good scenario to test the useability of HVE and ECS.

Comparing HVE and ECS

Overall, HVE is easier to use. Less setup is required, and the PowerShell used to generate and submit messages is based on the old (deprecated) Send-MailMessage cmdlet. No shortage of articles can be found on the internet to tell you how to use Send-MailMessage. Because of the need to provide an email service for apps and devices, HVE uses a restricted form of basic authentication with the SMTP AUTH protocol. Support for modern authentication is coming, but using basic authentication for internal messages will make the switchover to HVE much easier.

HVE reporting (Figure 1) is basic. More comprehensive reporting is built into ECS. In both cases, feedback from sent messages is minimal, so figuring out what happened to messages is tough. ECS can tell you the number of messages it failed to send but HVE is silent on this point. However, HVE is in preview and Microsoft says that they will deliver better reporting when the solution is generally available.

The ECS setup is more complicated if you’re unaccustomed to dealing with Azure resources and billing. ECS uses an Entra ID app for authentication and to prove that an app (like a PowerShell script) has the right to submit messages to the service. Creating and submitting messages to ECS is similar to using Graph-based cmdlets like Send-MgUserMail. Some differences exist because a different API is used, but the basics of building a hash table of message parts and converting it to JSON before sending won’t be unfamiliar.

Throttling and thresholds were the biggest issue I encountered with both ECS and HVE. It took a little while to find where limits applied in practice and to investigate ways around them. Microsoft has a documented process for applying for higher limits for ECS but my ability to navigate the process failed and I never managed to achieve a higher threshold. Microsoft is careful with HVE while it is in preview and some limitations (like the 2,000 external recipients per tenant daily) are hardcoded and won’t change until the software reaches general availability.

Testing of both Microsoft Cloud Email Services Proves Valuable

As always, the opportunity to conduct realistic tests over a sustained period proved invaluable in gaining an understanding about how HVE and ECS work. In my case, sending thousands of reminder messages to Office 365 for IT Pros subscribers certainly taught me a lot. You can read more about my experiences in articles covering HVE and ECS in-depth. Other articles about HVE and ECS are available on the internet, but most are content to send just a few test messages and then declare success. That’s no way to exercise a high volume email system.

If you’re interested in one of these services, my advice is to spin up both and test using a sample of messages that your organization needs to send. Exchange Online tenants will, I think, select HVE, but I can see why ECS has its attractions especially if the focus is on sending large quantities of email to external recipients. Beauty is in the eye of the mail sender.

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.

User Privacy a Major Concern When People Access Ex-Employee Mailboxes

The mailboxes of ex-employees can hold valuable information that an organization needs to retain for either business or compliance reasons. Two options are available:

• Convert the mailbox into a shared mailbox. This option is available in the Exchange admin center (EAC).
• Use a retention hold to make the mailbox an inactive mailbox after deleting the user account.

Each method offers different advantages and disadvantages. I discussed this topic a couple of years ago. At the time, I concluded that a shared mailbox might be the better default option. Now I am not so sure for the reasons explained below.

The Shared Mailbox Option

Converting a mailbox into a shared mailbox is a popular option. The user account which owns the mailbox must be licensed before EAC reveals the option, so it’s an action that must happen before removing the user account. If the shared mailbox holds more than 50 GB of content or has an archive mailbox, it must be assigned an Exchange Online license. Plan 1 covers the archive mailbox while Plan 2 extends the mailbox quota from 50 GB to 100 GB.

Conversion only changes the mailbox type. Everything else remains the same, including the account user principal name and password. Ideally, these properties should be updated to reflect the new mailbox status. In addition, you should remove any unrequired licenses from the account and disable it to prevent people from signing into the account.

People can still access the shared mailbox even when its account is disabled if they are granted Exchange Online permissions to open the mailbox. Easy access to a shared mailbox that once belonged to an ex-employee is a major advantage, but as we’ll discuss later, this is a double-edged sword.

The Inactive Mailbox Option

Following the deletion of an Entra ID account, Exchange Online checks for the presence of any retention holds on the mailbox. A hold on mailbox content could originate from an eDiscovery case, a retention policy, or retention labels. In all cases, the presence of the hold means that the mailbox cannot be removed until the retention period set for the hold lapses. Several holds could exist on the mailbox, and when this happens, Exchange Online must retain the mailbox until the last hold expires, at which time Exchange Online permanently removes the mailbox. Inactive mailboxes do not require any form of license.

To retain the mailbox, Exchange Online makes it inactive. An inactive mailbox is a form of soft-deleted mailbox. Unlike a shared mailbox, an inactive mailbox is invisible for normal operations. If the need exists to access the mailbox online, it can be recovered (create a new mailbox) or restored (merge into an existing mailbox). Alternatively, if only some content is required from an inactive mailbox, compliance administrators can run a content search against the mailbox to find and export the content.

An advantage of using inactive mailboxes over shared mailboxes is that Microsoft 365 performs the remaining steps in the account clean-up procedure such as removing the user’s OneDrive account (preventing future problems with managing unlicensed OneDrive accounts). Also, when an account is deleted, it is removed from membership of distribution groups, teams, security groups, and Microsoft 365 groups. Shared mailboxes keep their memberships.

The Privacy Issue

In an era when personal privacy is more important than ever before, converting the mailbox belonging to an ex-employee to a shared mailbox creates some concerns. For instance, people often store non-business information in email, so how do you handle personally identifiable information (PII) found in the mailbox? Information like bank account numbers, passport numbers, and so on could be present. Once access is granted to the mailbox to allow other employees to harvest business information that data becomes available to anyone with access to the mailbox.

In places like the European Union and California, ex-employees are entitled to ask for information relating to them to be extracted from systems like Microsoft 365 and provided to them in a portable form. Responding to GDPR Data Subject Requests for information held in Microsoft 365 can take a lot of time and effort. Microsoft Priva is a solution to help respond to and manage data subject requests. Nice as it is to have software available to manage data subject requests, it’s a lot better to avoid heightening the risk that ex-employees will make data subject requests, which they might do if they know that their mailbox is open for access by other people.

Because of the risk of inadvertent disclosure of PII, I prefer not to transform user mailboxes into shared mailboxes. It is a more prudent approach to retain the mailboxes of ex-employees as inactive mailboxes for a limited period (say six months). If necessary, content can be extracted from inactive mailboxes by compliance administrators. This process can be tightly controlled to ensure that an obvious and well-documented business need exists to extract the data.

Think About Using Shared Mailboxes

Old habits die hard. I think the default tendency to use shared mailboxes is an old habit inherited from on-premises servers where inactive mailboxes don’t exist. Often what works for on-premises organizations is not the most efficient method in the cloud.

It might still be the case that converting a user mailbox into a shared mailbox is the right action for your organization. But before you make that decision, take the time to consider how you deal with ex-employee mailboxes and make sure that the organization is protected from the consequences of inadvertent disclosure of PII.

PS. A similar PII issue can surface in the OneDrive for Business accounts of deleted users. See this article for details.

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.

Focus on Improving Email Security Continues with Inbound DANE with DNSSEC

To their credit, over the past few years, Microsoft has steadily increased the security of Exchange Online email services. Some of the measures taken, such as restricting the versions of on-premises servers that can send messages to Exchange Online via an inbound connector, didn’t get good press when announced or when the restriction came into effect. I haven’t heard much about the issue recently and guess that those running hybrid organizations have bought into the need to keep their on-premises Exchange servers updated.

Other initiatives to enhance the security of email, like support for MTA-STS and DANE with DNSSEC for outbound email, were less controversial. Some tenant administrators probably didn’t pay much attention to these advances because they use default settings for email security and are happy to let Microsoft manage those defaults. But making sure that SMTP-based email transmission is as secure as possible is a major concern for many large organizations (and some small tenants too).

The Licensing Conundrum for Inbound DANE with DNSSEC

Which brings us to June 3, 2024, and Microsoft’s announcement of the preview of DANE with DNSSEC support for inbound email. On the surface, there was nothing remarkable about the announcement. Microsoft has been open about their intention to implement DANE with DNSSEC for Exchange Online since April 2020 and adding support for inbound email complements the existing support for outbound mail. Then people noticed that support for the new capability (when generally available) required tenants to have Microsoft 365 E5 licenses. This came as a complete surprise and led to widespread criticism.

Requiring Microsoft 365 E5 licenses might have kept bookkeepers happy, but it wasn’t the right thing to do. Inbound support for DANE with DNSSEC adds to fundamental email security. It’s not like upgrading from Exchange Online Protection to Microsoft Defender for Office 365 to gain some extra features to help an organization deal with inbound spam.

The good news is that the Microsoft 365 messaging team took the criticism on board and withdrew the preview software. After taking six weeks or so to contemplate their next steps, on July 17, Microsoft announced that the public preview for inbound support for DANE with DNSSEC doesn’t require any high-end licenses (message center notification MC711018, Microsoft 365 roadmap item 63213). The updated documentation for the feature contains no mention about licensing requirements, so plain old Exchange Online does just fine.

The Implementation Timeline

The preview is now available. Some tenants might need to wait until July 19 before the Enable-DnssecForVerifiedDomain cmdlet becomes available. You will need to install V3.5.1 of the Exchange Online management module to see the cmdlet. Here’s a handy script to update Microsoft 365 PowerShell modules.

The remaining timeline goes like this:

• August 2024: An Inbound DANE with DNSSEC and MTA-STS report is available in the Exchange admin center.
• October 2024: General Availability of Inbound DANE with DNSSEC.
• By the end of 2024: Microsoft begins to deploy inbound DANE with DNSSEC for all Outlook domains. These are the Microsoft consumer email services like Hotmail.com, Outlook.com, and their country-level domains. Microsoft says that they have already updated several domains.
• Newly created Microsoft 365 tenants will have DNS records created for them in the DNSSEC-enabled messaging infrastructure under the *.mx.microsoft root. See this article for more information about the changes planned for DNS records.
• February 2025: Mandatory Outbound DANE with DNSSEC set per-tenant/per-remote domain.

Towards a More Secure Messaging World

It’s easy to see how DANE with DNSSEC will become the norm for all Exchange Online domains in the future. The transition should be smooth for most, but any tenant that uses a third-party email hygiene system or connector needs to check that all elements of their mail transport infrastructure can accommodate inbound DANE with DNSSEC.

Microsoft nearly made a big mistake by insisting on high-end licenses for a fundamental piece of messaging security. They made the right call by retreating from that position. Let’s hope that the trend continues to improve and enhance the messaging security for Exchange Online.

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.

Set Calendar Permission to Allow Organization Users to See Limited Details

In September 2021, I wrote about how to set the calendar permission for mailboxes to allow users within the organization to view event titles and locations. In the article, I discuss how to use the Set-MailboxFolderPermission cmdlet to update the access rights assigned to the “default user” from availability only to limited details. The permission assigned to the default user is the one used if a more specific permission is unavailable. By allowing more access to a user calendar for the default user, it means that anyone in the organization can see more information from that user’s calendar. In OWA and the new Outlook for Windows (Monarch) client, the sharing permission is called “can view titles and locations” (Figure 1).

Can view titles and locations means that users who check someone else’s calendar to see event subjects and locations. The default shows only that slots in a calendar are blocked or free.

Calendar Permissions and the Graph

Time passes on and today an alternative solution is available in the form of the Graph calendar permission resource and its methods, plus the associated Microsoft Graph PowerShell SDK cmdlets like Get-MgUserCalendarPermission and Update- MgUserCalendarPermission.

The Get-MailboxFolderPermission and Set-MailboxFolderPermission cmdlets have never been quick, so the question is whether the Graph-based cmdlets are faster at checking and setting calendar permissions.

Testing Performance

I decided to test by writing two scripts. Both scripts fetch user and room mailboxes which use the limited availability permission and update the mailboxes to allow access to limited details.

Both scripts use the Get-ExoMailbox cmdlet to fetch mailbox details. There isn’t a good Graph-based method to fetch mailbox-enabled accounts. Get-MgUser can apply a filter to fetch licensed accounts, but that set won’t include room mailboxes. Get-MgUser can fetch all member accounts, but this set will probably include a bunch of accounts that don’t have mailboxes. In addition, because the script loads the Exchange Online management module to use Get-ExoMailbox, it can also use Set-Mailbox to update a custom attribute with an indicator after processing a mailbox.

Maintaining an indicator in a custom attribute is important because the Get-ExoMailbox command can filter out mailboxes that have the permission set. For instance, if you run the script monthly, it will only process mailboxes created since the last run.

Here’s the Exchange Online script. The Set-MailboxFolderPermission cmdlet requires passing the name of the calendar folder, so there’s some code to figure out the value in different languages.

# Exchange Online version 
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, RoomMailbox -Filter {CustomAttribute10 -ne "OpenCalendar"} -ResultSize Unlimited -Properties Languages | Sort-Object DisplayName
Write-Host ("{0} mailboxes found" -f $Mbx.Count)
[int]$Updates = 0
ForEach ($M in $Mbx) {
  # Figure out the name of the Calendar folder in the user's preferred language
  [array]$Languages = $M.Languages
  Switch ($Languages[0]) {
      "en-US" { $CalendarName = "Calendar" }
      "fr-FR" { $CalendarName = "Calendrier" }
      "de-DE" { $CalendarName = "Kalender" }
      "es-ES" { $CalendarName = "Calendario" }
      "it-IT" { $CalendarName = "Calendario" }
      "nl-NL" { $CalendarName = "Agenda" }   
      Default { $CalendarName = "Calendar" }
  }
  # Build the path to the Calendar folder
  $CalendarFolder = ("{0}:\{1}" -f $M.UserPrincipalName, $CalendarName)
  [array]$Data = Get-MailboxFolderPermission -Identity $CalendarFolder | Where-Object {$_.User.usertype.value -eq "Default"} | Select-Object -ExpandProperty AccessRights
  If ([string]$Data -ne "LimitedDetails") {
      Write-Host ("Setting LimitedDetails permission for {0}" -f $M.displayName) -ForegroundColor Yellow
      Set-MailboxFolderPermission -Identity $CalendarFolder -User Default -AccessRights LimitedDetails
      Set-Mailbox -Identity $M.UserPrincipalName -CustomAttribute10 "OpenCalendar"
      $Updates++
  } Else {
      # for some reason the custom attribute is not set to reflect the calendar permission, so update it
      Write-Host "Setting custom attribute for" $M.UserPrincipalName
      Set-Mailbox -Identity $M.UserPrincipalName -CustomAttribute10 "OpenCalendar"
  }
}
Write-Host ("Calendar permission updated for {0} mailboxes" -f $Updates)

Here’s the version using a mixture of Exchange Online and Microsoft Graph PowerShell SDK cmdlet. This code doesn’t need to know anything about language values for folder names because the Graph uses different identifiers.

# Graph version
[int]$Updates = 0
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, RoomMailbox -Filter {CustomAttribute10 -ne "OpenCalendar"} -ResultSize Unlimited -Properties Languages | Sort-Object DisplayName
Write-Host ("{0} mailboxes found" -f $Mbx.Count)
ForEach ($M in $Mbx){
    [array]$CalendarPermissions = Get-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId
  If ($CalendarPermissions) {  
     $OrgDefault = $null
     [array]$OrgDefault = $CalendarPermissions | Where-Object {$_.EmailAddress.Name -eq "My Organization"}  
     If ($Permission -notin $OrgDefault.Role) {
        Write-Host ("Setting Limited Read permission for {1}" -f $M.DisplayName) -ForegroundColor Yellow
        Try {
           Update-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId `
             -Role "LimitedRead" -CalendarPermissionId $OrgDefault.id | Out-Null
           $Updates++
        } Catch {
            Write-Host ("Failed to update calendar permission for {0}" -f $M.DisplayName) -ForegroundColor Red
        }
        Set-Mailbox -Identity $M.ExternalDirectoryObjectId -CustomAttribute10 "OpenCalendar"
        } Else {
          Write-Host ("{0} already has the Limited Read permission" -f $M.DisplayName)
        }
  } 
}
Write-Host ("Calendar permission updated for {0} mailboxes" -f $Updates)

Here’s the version using a mixture of Exchange Online and Microsoft Graph PowerShell SDK cmdlet. This code doesn’t need to know anything about language values for folder names because the Graph uses different identifiers. I can’t account for why Microsoft decided to call the permission LimitedDetails in Exchange and LimitedRead in the Graph. The different roles available for the Graph are documented online.

# Graph version
[int]$Updates = 0
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, RoomMailbox -Filter {CustomAttribute10 -ne "OpenCalendar"} -ResultSize Unlimited -Properties Languages | Sort-Object DisplayName
Write-Host ("{0} mailboxes found" -f $Mbx.Count)
ForEach ($M in $Mbx){
    [array]$CalendarPermissions = Get-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId
  If ($CalendarPermissions) {  
     $OrgDefault = $null
     [array]$OrgDefault = $CalendarPermissions | Where-Object {$_.EmailAddress.Name -eq "My Organization"}  
    If ("LimitedRead" -notin $OrgDefault.Role) {
       Write-Host ("Setting Limited Read permission for {0}" -f $M.DisplayName) -ForegroundColor Yellow
       Try {
          Update-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId `
            -Role "LimitedRead" -CalendarPermissionId $OrgDefault.id | Out-Null
          $Updates++
       } Catch {
           Write-Host ("Failed to update calendar permission for {0}" -f $M.DisplayName) -ForegroundColor Red
       }
       Set-Mailbox -Identity $M.ExternalDirectoryObjectId -CustomAttribute10 "OpenCalendar"
       } Else {
         Write-Host ("{0} already has the Limited Read permission" -f $M.DisplayName)
       }
  } 
}
Write-Host ("Calendar permission updated for {0} mailboxes" -f $Updates)

The Measure-Command cmdlet generated the test results, which showed that the Exchange script required 2.84 seconds per mailbox to run. The Graph version was nearly a second faster per mailbox (1.96 seconds). Your mileage might vary.

No Need to Change Unless You Must

Using the Graph SDK cmdlets saves almost a second per mailbox. That doesn’t mean that you should update scripts to rip out and replace the Set-MailboxFolderPermission cmdlet. While it’s important to use code that runs quickly, this kind of script is not something you’re going to run daily. It’s more likely to run on a scheduled basis, such as an Azure Automation runbook, and you won’t notice the extra time.

Besides, the most important contribution to performance in this example is reducing the number of mailboxes to process by maintaining the indicator and using the indicator to filter mailboxes. One cmdlet might be faster than another, but it’s how you use cmdlets in a script that dictates overall performance.

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

Make Sure that Mailbox Audit Configurations Capture Important Events

Following Microsoft’s announcement about the availability of the promised additional audit events for Purview Audit (standard) customers, some folks got in touch to ask if I had a script to report current mailbox audit configurations. As it happens, I didn’t, but cracking open Visual Studio Code and GitHub Copilot soon put that right.

How Not to Find Accounts with Purview Audit (Advanced) Licenses

My original plan was to find and report mailboxes owned by licensed user accounts. I wanted to know which accounts use Purview Audit standard and which use the advanced variant. This is more difficult than it seems because, as far as I can tell, there’s no Purview Audit standard service plan. At least, I can’t find one on the Microsoft page listing all the license and service plan identifiers.

There is a service plan called M365_ADVANCED_AUDITING (2f442157-a11c-46b9-ae5b-6e39ff4e5849), which seemed like a good candidate for Purview Audit (advanced). However, if you use the Get-MgUser cmdlet from the Microsoft Graph PowerShell SDK to find accounts with this service plan identifier in the assignedPlans property (see below), the service plan name returned for the identifier is “exchange.”

[guid]$PurviewAuditAdvancedPlanId = "f6de4823-28fa-440b-b886-4783fa86ddba"

[array]$Users = Get-MgUser -filter "assignedPlans/any(x:x/serviceplanid eq $PurviewAuditAdvancedPlanId)" -ConsistencyLevel eventual -CountVariable Test -Property Id, displayName, userprincipalName, assignedLicenses, assignedPlans

The service plan identifier appears in accounts that don’t have Office 365 E5 or Microsoft 365 E5 licenses, which are the products that include Purview Audit (advanced). This is because the service plan identifier has a disabled status in those accounts. To solve that problem, amend the filter to check for enabled service plans:

[array]$Users = Get-MgUser -filter "assignedPlans/any(x:x/serviceplanid eq $PurviewAuditAdvancedPlanId and capabilityStatus eq 'Enabled')" -ConsistencyLevel eventual -CountVariable Test -Property Id, displayName, userprincipalName, assignedLicenses, assignedPlans

But then I found that the resulting set of accounts only included those with Microsoft 365 E5 licenses. No trace existed of the Office 365 E5 accounts, even though Microsoft includes the Office 365 E5 license in the set with access to Purview Audit (advanced) in this useful comparison chart.

Microsoft documentation assures me that there is an app for Purview Audit (advanced). Usually, an app equates to a service plan. When I checked the Microsoft 365 admin center as directed, the app shows up under the moniker Microsoft 365 advanced auditing (Figure 1).

Disabling and enabling the app in the Microsoft 365 admin center disables and enables the 2f442157-a11c-46b9-ae5b-6e39ff4e5849 service plan behind the scenes. After all that, we know that a service plan called exchange controls an app called Microsoft 365 advanced auditing (aka the Microsoft Purview Audit (advanced) product) that only shows up in accounts with Microsoft 365 E5 licenses. It’s all very confusing, so I lost interest at this point.

Back to Scripting Mailbox Audit Configurations

After wasting too much time discovering the mess of service plans, product names, and SKUs, I went back to scripting and wrote some straightforward code to:

• Connect to Exchange Online.
• Run Get-ExoMailbox to find user and shared mailboxes.
• Define some critical audit events to check for in the owner and delegate audit sets.
• Check each mailbox to see if it uses the default audit configuration (maintained by Microsoft). Report the audit set defined in the configuration.
• Check that the critical audit events are present in the owner and delegate audit sets and flag any critical audit events (like MailItemsAccessed) found missing.
• Report what’s been found.
• If the ImportExcel PowerShell module is available, generate an Excel worksheet containing the results (Figure 2). If not, generate a CSV file.

You can download the full script from GitHub.

A Note About Enabling Audit with Set-Mailbox

The script checks if auditing is enabled for a mailbox, and if it is, the script runs Set-Mailbox to set AuditEnabled to true. Microsoft documentation says that if mailbox auditing is turned on by default for an organization, mailbox auditing ignores the AuditEnabled mailbox property.

But their May 20 announcement about the new audit events says that “Every standard user mailbox should have AuditEnabled set to true to ensure all audit records are uploaded to Purview Audit” and “Please note that this Set-Mailbox command must be run for every Standard license user regardless of its current value to correctly enable their mailbox to upload the new standard logs to Purview Audit.” Microsoft documentation is confusing on this point. I think the situation is that Microsoft manages mailbox auditing for accounts with Purview Audit advanced licenses while manual intervention is needed for mailboxes with Purview Audit standard, Whatever the reason, it’s always better to be safe than sorry when dealing with audit events, the script runs Set-Mailbox. You can certainly eliminate this section of the script to speed things up if you want to.

Feel free to improve and embellish the script to meet your needs. In the meantime, I need a headache tablet to recover from the trials of audit licensing.

Stay updated with developments like new events for mailbox audit configurations 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.

SMTP AUTH Client Connections Deprecated in 2025 Together with Introduction of a New External Recipient Rate Limit

The Exchange development team has clearly been busy lately. On April 15, 2024, they announced two major changes:

• The deprecation of basic authentication for client submission (SMTP AUTH) in September 2025.
• The imposition of a new external recipient rate limit (ERR limit) from January 1, 2025.

Microsoft says that both announcements are part of the work to protect Exchange Online.

SMTP AUTH and Basic Authentication

The announcement about the demise of SMTP AUTH is not unexpected. For the past several years, Microsoft has steadily removed basic authentication (sending plain text credentials over a network connection) for email connectivity protocols. SMTP AUTH was left untouched by the previous initiative because this protocol is used by apps and devices to submit email for processing by Exchange Online (hence the client submission moniker). For instance, multifunction devices like printer/scanners can submit messages to inform users when their jobs are complete. Apps often submit email to transmit the results of processing to users. This includes the use of the PowerShell Send-MailMessage cmdlet.

The route forward is for developers to replace basic authentication with OAuth. It’s a perfectly acceptable resolution if developers are available to fix the problem. I suspect that organizations will discover that many apps and devices are unable to transmit messages when Microsoft imposes the block to close off basic authentication for SMTP connections in September 2025. And in some cases, it might not be possible to get an update to allow multifunction devices to continue to send email.

Update (June 2025): Microsoft pushed the deadline out six months and will now begin to deprecate SMTP AUTH connections on March 1, 2026 to complete by April 30, 2026.

To help, Microsoft says that they will update the SMTP AUTH Clients Submission Report in the Exchange admin center to indicate the protocol used to submit messages. They plan to follow up with message center notifications to tenants that continue to use SMTP AUTH in January 2025 to say that they must make changes. In August 2025, a final countdown notice will be issued to tell tenants still using SMTP AUTH that the block is about to descend.

The plan seems good, but human nature has the potential to get in the way. It’s well known that many tenant administrators are not as diligent (or curious) as they should be in reading message center notifications and reacting where action is necessary. The previous project to remove basic authentication from email connection protocols ran into this problem and it’s possible that Microsoft will need to delay the final depreciation. Nevertheless, the die is cast and people should realize that SMTP AUTH is on the way out, and soon.

The HVE Alternative

Microsoft positions the new High Volume Email (HVE) feature as an alternative for customers who cannot move to OAuth authenticated SMTP connections, albeit solely for internal connections. Announced in preview on April 1, 2024, HVE will allow apps and devices to connect to a different SMTP endpoint with basic authentication and send messages. Azure Communication Services is another alternative.

The downside of both suggestions is that using these services will cost where sending email using SMTP AUTH is free. Microsoft will point to the need to secure and protect Exchange Online and their long-held position that Exchange Online is not intended for bulk email as justification for diverting customers to HVE and Azure Communication Services. It’s a defensible position in some respects, but at the end of the day, it depends on how much the transition and ongoing operations cost.

Clamping Down on External Email

Speaking of HVE, it’s also associated with the introduction of an external recipient rate (ERR) limit. Today, the Exchange Online recipient rate limit controls the number of individual recipients for outgoing messages that can be on messages sent from a mailbox. The current rate is 10,000 recipients daily. When computing the number of recipients in a day, a distribution list or Microsoft 365 group counts as a single recipient.

The recipient rate limit has been in place for years. What’s different is the amount of email generated by spammers who sign up for Microsoft 365 tenants and use low-cost licenses to create and send email. The spammers can transfer licenses from mailbox to mailbox to send more email or send from shared mailboxes, which don’t need licenses unless they have an archive or need a 100 GB quota.

Spam doesn’t stay inside a tenant. It goes to external recipients. Today, the recipient rate limit allows a single mailbox to send to 10,000 individual recipients (or a lot more if distribution lists are used). Imposing the ERR at 2,000 messages (for new tenants from 1 January 2025 followed by existing tenants from July 2025) is a way to make Exchange Online less attractive to spammers. Microsoft’s announcement doesn’t cover whether this rate applies to email sent across a connector to Exchange on-premises servers in a hybrid environment. Other scenarios remain to be parsed out over the coming months.

However, I think the ERR is a short-term sticking plaster. I cannot believe that the world’s largest software company cannot implement a spam check in the transport pipeline to detect and block outbound spam – or at least, severely throttle outbound email that seems to be spam. You’d hope that a Copilot for Spam could detect and suppress spamming but given the ongoing problems Exchange Online Protection has in detecting some obvious malware that reaches user inbox, perhaps this is hoping for too much.

An Ongoing Battle

What’s for sure is that Microsoft continues to apply a squeeze on behaviors considered to conflict with the terms of service for Exchange Online or the real need to keep email secure for the over 400 million paid Office 365 seats. I don’t think we can quibble too much with initiatives to make email work better, even if some doubts exist about quite how the steps Microsoft is taking now.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Code Doesn’t Check for a Modified Role Assignment Policy

Message center notification MC762509 (published 30 March 2024) marks Microsoft’s latest attempt to rid itself of some of the lingering bits of the old Exchange admin center (EAC). The notification announces the replacement of the old Exchange Control Panel (ECP) component to allow OWA users to manage distribution lists with a modernized version that brings users to a page belonging to the new EAC.

Microsoft brought back the old ECP component in July 2023 when their previous attempt at modernizing distribution list management failed. This time round, Microsoft plans to deploy the change in early April 2024 and complete the worldwide roll-out in early May.

The Value of Role Assignment Policies

Unhappily, problems exist in the modernized version. It looks like the developers never heard of Exchange role-based access control (RBAC) and the ability to remove options from OWA users through user role assignment policies. Most organizations probably don’t try to customize the default role assignment policy, perhaps because they don’t know that such an adaptable mechanism exists.

A role assignment policy works by revealing OWA functionality to users if they are allowed to run the cmdlets that underpin different pieces of functionality. For instance, to display the set of distribution lists that they belong to, a user must be able to run the Get-DistributionGroup cmdlet. To update the settings of distribution lists, they must be able to run the Set-DistributionGroup cmdlet, and so on. Role assignments within the policy dictate what a user can do through OWA settings, such as updating their autosignature.

Role assignment policies only affect the OWA client. They don’t affect how Outlook for Windows or Mac work (including the new Outlook client) or how Outlook mobile works.

Modified Role Assignments for Distribution List Management

Coming back to distribution list management, Microsoft 365 Groups don’t exist in Exchange Server, and it is common to find that organizations allow users to manage distribution lists, especially the membership of lists that the user owns. Allowing users to create new distribution lists isn’t such a good idea as it can lead to a sprawl of lists in the GAL, like the way that end user can create a terrible mess if allowed to create teams without approval.

The solution is to create a custom role assignment policy that allows users to maintain distribution lists that they own while not being able to create new distribution lists. The change is easy to make and the block on creating new distribution lists is effective soon after assigning the policy to user mailboxes with the Set-Mailbox cmdlet:

Set-Mailbox -Identity Ben.Owens -RoleAssignmentPolicy 'Restricted Group Management'

Figure 1 shows the effect of the restricted role assignment policy. No option is available to create new distribution lists, but the user can edit any of the distribution lists they own.

Alas, things don’t go so well with the new EAC component. First, no block is implemented to prevent users from attempting to create new distribution lists. Second, if a restricted role assignment policy blocks a user from creating new distribution lists, they only find out at the final stage when EAC signals an error that they’re not allowed to run the New-DistributionGroup cmdlet (Figure 2). The error arises because the role assignment policy blocks the ability of the user to run the cmdlet.

Distribution Lists Get No Respect

Distribution lists continue to be very useful in any Exchange Online tenant. In particular, dynamic distribution lists are very powerful. Ten years after the introduction of Office 365 Groups (in preview), Microsoft’s attempts to convince customers to move distribution lists to (the renamed) Microsoft 365 Groups is a flop. Sure, Microsoft 365 Groups come with a SharePoint Online site, but the simplicity of a distribution list is exactly what’s needed in many situations. Many of those sites remain unused and empty, with the equivalent of digital tumbleweed blowing through their document libraries.

Failing to adequately test new code for managing distribution lists before launching it on the innocent public is just another reminder that Microsoft is intent on making distribution lists the Rodney Dangerfield of Microsoft 365. That’s a real pity.

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.

View Another Mailbox Allows Administrators to Access Settings for Mailboxes

Microsoft 365 message center notification MC720777 (published 28 Feb 2024) announces support for the View another mailbox option in the new Exchange admin center (EAC). Worldwide deployment of the View another mailbox option is expected to be complete in late March 2024.

This is not particularly exciting news as it’s simply a matter of adding functionality that exists in previous versions of the Exchange Online administration portal. It’s part of the work Microsoft needs to move functionality from the old EAC before they can turn off the old portal in mid-2024. Given that mail flow rules moved in November 2022, the process is taking forever. It’s almost as long as waiting for Microsoft to complete engineering for a new on-premises version of Exchange Server.

In most cases it’s easier and faster to update mailbox settings through PowerShell. The provision of a GUI option accommodates administrators who aren’t comfortable using PowerShell or don’t want to spin up a PowerShell session to update settings for a single mailbox.

Using View Another Mailbox

Access to the View another mailbox option is through the user details panel at the top right-hand corner of the EAC screen (Figure 1).

EAC then displays the set of mailboxes that the signed-in account can manage to allow the user to choose a target mailbox. The list (Figure 2) includes shared mailboxes, room mailboxes, and even a lingering team (site) mailbox. It would be nice if the list was sorted alphabetically (there’s no good reason why the Lotte Vetler mailbox is at the top). In addition, Microsoft should look at the “View site using another mailbox” heading. This makes sense in an odd sort of way because a browser accesses target mailbox settings, but “View other mailbox settings” would be better.

It would be nice if Microsoft had included some filtering capability to allow administrators to exclude objects such as room and equipment mailboxes. The fact is that the settings for these mailboxes are hardly ever changed after their initial creation. Being listed in the set of mailboxes only clutters up the list. It’s also evidence of sloppy development and testing by engineers who probably never use Exchange in anger.

It’s the Old Exchange Control Panel

Microsoft claims that the new feature is “modern, faster, and easier to use.” This is code for “we’ve created new screens that match the current design language for Microsoft 365 administrator portals.” The theory works until EAC displays mailbox settings in a new browser window when the full glory of the old Exchange Control Panel (ECP) is revealed (Figure 3). ECP first appeared in Exchange Server 2010, so its appearance is very familiar to generations of Exchange administrators.

The performance of the old ECP is not fast and I spent time waiting for ECP to fetch mailbox settings (Figure 4). Updating settings works as expected, but this experience is not modern nor faster as promised.

Further evidence of a lack of testing is in calendar settings where ECP displays an error message about a deprecated cmdlet (Figure 5). This is possibly because ECP calls the old Get-TxpUserSettings cmdlet to fetch information about creating events (like airline bookings) from inbound email.

The last time the Get-TxpUserSettings cmdlet featured in the Office 365 for IT Pros eBook was the 2020 edition, so the obsolete status for the cmdlet is not new.

Another Brick in the EAC Wall

Microsoft is slowly completing the new EAC. Progress is not as quick as expected but they’ll get there in the end. In achieving that goal, it would be nice if the quality of what’s produced was better.

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.

New Author to Handle Mail Flow Issues Like Impersonation Protection

We are delighted to announce that Michel de Rooij has joined the Office 365 for IT Pros eBook team as the author responsible for the Mail Flow chapter. Michel is a Microsoft MVP for Office Apps and Services, and a senior consultant at Rapid Circle, a Microsoft partner in the Netherlands. He has extensive experience in designing, implementing, and managing Exchange and Office 365 environments for various customers. You can contact Michel through his blog or Twitter.

Michel takes over from Gareth Gudger, who has been a valuable contributor to the Office 365 for IT Pros eBook for several years. We thank Gareth for his dedication and the care he lavished on the Mail Flow chapter, and we wish him all the best in his future endeavors.

Practical PowerShell

Apart from his expertise with Exchange, Michel is a PowerShell wizard. He’s started to share his experience in a new “Professional PowerShell” column published on Practical365.com. Starting with the March 2024 update (monthly update #105), I’m sure that Michel will look for opportunities to use his PowerShell talents to automate some common mail flow operations over the coming months.

Automating Impersonation Protection

For example, I’m a big fan of the impersonation protection settings in anti-phishing policies (available when a tenant has Microsoft 365 Defender for Office 365). Impersonation protection allows tenants to protect up to 350 internal or external email addresses against impersonation attempts. When Microsoft first introduced impersonation protection in late 2020, policies were limited to just 60 addresses, so the bump to 350 is appreciated.

Basically, this happens when spammers send email from addresses that are very close (usually just one character different) to a real address. For instance, Kim.Akers@office365ltpros.com instead of Kim.Akers@office365itpros.com.

Although there is a GUI option to update the list of protected users (Figure 1), to automate the process, I use an Azure Automation runbook that executes a scheduled job every Saturday. The job:

• Signs into Exchange Online using a managed identity.
• Finds the set of mailboxes with a custom attribute set to “VIP.”
• Creates an array of mailbox display names and user principal names in the format used by anti-phish policies.
• Updates the default anti-phish policy with the new list.
• Checks that the updated policy protects the expected number of mailboxes and declares success.

Here’s the basic PowerShell code executed by the scheduled job:

[array]$PhishUsersToProtect = $null
# Find the set of mailboxes to protect
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -Filter {CustomAttribute1 -eq "VIP"} -Properties CustomAttribute1 | Select-Object Displayname, UserPrincipalName
# Create an array in the required format with details of protected users
ForEach ($User in $Mbx) {
  [string]$UserAdd = ("{0};{1}" -f $User.DisplayName, $User.UserPrincipalName)
  $PhishUsersToProtect += $UserAdd
}

# Find the default anti-phish policy
$DefaultPhishPolicy = Get-AntiPhishPolicy | Where-Object IsDefault -match $True

# Update the set of protected users in the policy if there are less than 350 mailboxes
If ($PhishUsersToProtect.count -lt 350) {
    Set-AntiPhishPolicy -Identity $DefaultPhishPolicy.Identity -TargetedUsersToProtect $PhishUsersToProtect -EnableTargetedUserProtection $true
    [Array]$TargetedUsers = Get-AntiPhishPolicy -Identity $DefaultPhishPolicy.Policy | `
        Select-Object -ExpandProperty TargetedUsersToProtect
    Write-Host ("Policy {0} now protects {1} mailboxes" -f $Policy.Identity, $TargetedUsers.count)    
} Else {
  Write-Host ("{0} mailboxes identified for protection but the maximum supported is 350" -f $PhishUsersToProtect.count)
}

Functional Not Professional PowerShell

Of course, my PowerShell code is not polished. It’s functional rather than professional PowerShell. But now that the Office 365 for IT Pros eBook author team has a real pro on staff, I’m sure that the quality and beauty of the code featured in the book (well, at least in the Mail Flow chapter), will improve dramatically.

Learn more about how Exchange Online and the Microsoft 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.

Hide Individual Distribution List Members to Keep Their Identity Secret

A question in the Office 365 Technical Discussions Facebook group asked whether it is possible to hide individual distribution list members. This necessity might arise when you want to use a single distribution list to communicate information and you don’t want people to know the full set of recipients. Perhaps some recipients are external advisors or maybe you want to hide the fact that information is being shared with certain people within the organization.

The simple answer is no. Exchange Online supports the hiding of complete membership, but not an individual member of a distribution list. The same applies to hidden membership for Microsoft 365 groups. One workaround is to hide the distribution list from Exchange address lists. This stops users browsing the Global Address List (GAL), Offline Address List (OAB), or All Distribution Lists address list to find the list. Even if some discovers the SMTP address of the distribution list and sends a message, they can’t see the membership.

To hide a distribution list, edit its properties using the Exchange admin center (Figure 1). Hiding the list from the GAL is shorthand for hiding it from all address lists, including the OAB.

Alternatively, you can hide membership for a distribution list with PowerShell:

Set-DistributionList -Identity "Accounting Department" -HiddenFromAddressListsEnabled $True

Using a Nested Distribution List to Hide Members

However, hiding a distribution list that people might want to use removes a lot of its value. A better workaround exists dating back to Exchange 2000 or thereabouts, which is when I think the hidden membership feature first arrived (or maybe Exchange 2003).

The idea is simple. A distribution list can include nested distribution lists in its membership list. What we do is create a distribution list with hidden membership and include it in the membership of the public list. Here are the steps:

• Create a distribution list that includes all the users that you are happy for other users to know about.
• Create a second distribution list and set it to have hidden membership.
• Add the people you want to hide to the membership list of the second list.
• Add the second list to the membership of the first list.

You end up with a situation like that shown in Figure 2. The Public People List includes a distribution list called Secret People List in its membership.

If someone clicks on the Secret People List entry, they see the properties of the distribution list but not its membership (Figure 3). The members of the nested distribution list are invisible.

PowerShell Commands to Create the Public and Secret Lists

Here are the steps to use PowerShell to create what’s shown above. First, create the public list:

New-DistributionGroup -Name 'Public People List' -Alias Public.People.DL -Description 'People who want to be in a DL and be seen' -DisplayName 'Public People List' -IgnoreNamingPolicy

Now add the members that should be visible to the distribution list:

Add-DistributionGroupMember -Identity Public.People.DL -Member Hans.Geering
Add-DistributionGroupMember -Identity Public.People.DL -Member Otto.Flick
Add-DistributionGroupMember -Identity Public.People.DL -Member Michelle.duBois
Add-DistributionGroupMember -Identity Public.People.DL -Member James.Ryan
Add-DistributionGroupMember -Identity Public.People.DL -Member Ken.Bowers

The next step is to create the secret list. In this case, the HiddenGroupMembershipEnabled property is set to $True.

New-DistributionGroup -Name 'Secret People List' -Alias Secret.People.DL -Description 'People who want to be in a DL but not be seen' -DisplayName 'Secret People List' -HiddenGroupMembershipEnabled:$True -IgnoreNamingPolicy

Add the members of the secret list:

Add-DistributionGroupMember -Identity Secret.People.DL -Member Ann.Conroy
Add-DistributionGroupMember -Identity Secret.People.DL -Member Lotte.Vetler

Finally, add the secret list to the membership of the public list:

Add-DistributionGroupMember -Identity Public.People.DL -Member Secret.People.DL@office365itpros.com

To validate that the membership is as expected, run the Get-DistributionGroupMember cmdlet to check the membership of the public list:

Get-DistributionGroupMember -Identity Public.People.DL | Format-Table DisplayName, RecipientType

DisplayName                       RecipientType
-----------                       -------------
James Ryan                        UserMailbox
Ken Bowers                        UserMailbox
Otto Flick                        UserMailbox
Hans Geering (Project Management) UserMailbox
Michelle Dubois                   UserMailbox
Secret People List                MailUniversalDistributionGroup

When users send a message to the public list, the Exchange Online transport service resolves the membership, including the nested secret list. Figure 4 shows the recipients for a message sent to the public list as viewed through OWA. The secret list is in the recipients, and we know that this copy was delivered to Ann Conroy, a member of the secret list, because her name is in the window title bar.

You can run a message trace to confirm that the Exchange transport service expanded the message recipients to include members of the list:

Get-MessageTrace -MessageId DB7PR04MB441021BCEDA43033408C417C8B7B2@DB7PR04MB4410.eurprd04.prod.outlook.com | ft received, 'recipientaddress', subject

Received            RecipientAddress                     Subject
--------            ----------------                     -------
24/01/2024 22:37:16 ken.bowers@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 public.people.dl@office365itpros.com Interesting Information to Read
24/01/2024 22:37:16 hans.flick@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 secret.people.dl@office365itpros.com Interesting Information to Read
24/01/2024 22:37:16 michelle.dubois@office365itpros.com  Interesting Information to Read
24/01/2024 22:37:16 lotte.vetler@office365itpros.com     Interesting Information to Read
24/01/2024 22:37:16 james.ryan@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 ann.conroy@office365itpros.com       Interesting Information to Read
24/01/2024 22:37:16 hans.geering@office365itpros.com     Interesting Information to Read

Note that the name of the secret list does not feature in the set of recipients reported by the message trace, but the public list does. This is because the event reported by the message trace for the list is the expansion of the recipient list while the other events are deliveries.

Old Secrets Can Be the Best

Sometimes the old tricks are the best. In this instance, using a nested distribution list to cloak the identities of some recipients is a nice workaround and solves the question asked in the group.

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

Directory Lookups, the Address Book, and the Get-MgDomainNameReference Cmdlet

The news published in message center notification MC706449 (13 January 2024) is surprising only because people must still be accessing elements like the Global Address List online. This is surprising because I assume most people use Outlook in cached Exchange mode and take advantage of the Offline Address List (OAB). Access to the online address book is only necessary to find details of recipients added since Outlook last downloaded and applied an OAB update.

In any case, Microsoft wants people to stop browsing online address books and use search instead. They don’t want people doing what they call “infinite browsing,” which I assume means that users start scrolling through the address list to find interesting entries. Such activity causes the client to make multiple calls to fetch directory information.

Moving to a search-first posture makes sense and it’s the way things work with OWA and Outlook Monarch. Basically, Microsoft wants Outlook users to construct a search (like find people with “Tony” as their first name) and use the search to find matching entries. Microsoft says that they’ve improved search performance to ensure that users get fast results. In a further change, to encourage people to change habits, directory lookups against online address lists return only the first 500 entries, even if more exist.

Another tweak is that if you attempt to use a very broad search and more than 5,000 entries result, Outlook won’t show anything and you’ll be forced to narrow the search to see results. These changes have no effect on lookups against the OAB.

Finding Numbers of Directory Entries

Five hundred sounds like a lot of entries but the number is easily exceeded when you consider the number of mail-enabled objects that appear in address lists. Even though my tenant supports just 35 mailboxes, 490 mail-enabled objects are in the GAL:

[array]$MEObjects = Get-Recipient -ResultSize Unlimited -Filter {HiddenFromAddressListsEnabled -eq $False}
$MEObjects.count
490

$MeObjects | Group-Object RecipientTypeDetails -NoElement | Sort-Object Count -Descending | Format-Table Name, Count -AutoSize

Name                           Count
----                           -----
GroupMailbox                     174
GuestMailUser                    125
MailUniversalDistributionGroup    60
UserMailbox                       35
DynamicDistributionGroup          24
MailUser                          18
RoomMailbox                       17
MailUniversalSecurityGroup        12
SharedMailbox                     10
RoomList                           5
PublicFolder                       4
SchedulingMailbox                  4
EquipmentMailbox                   2

Fortunately, I use the OAB and search rather than browse to find entries, so MC706449 doesn’t affect me.

Issue with Domain Name References

Also related to the directory, last week, I discussed how to report issues to the Microsoft Graph PowerShell SDK development team. I suggested that browsing the reported issues is a good way to learn about how people use the SDK. Taking my own advice, I came to issue 2494, which discusses a problem with the Get-MgDomainNameReference cmdlet. The cmdlet is derived from the list domainNameReferences Graph API, which retrieves a list of directory objects referencing a specified registered domain belonging to a tenant. To see the valid domains for your domain, run the Get-MgDomain cmdlet:

Get-MgDomain | Format-Table Id, Isdefault

Id                                 IsDefault
--                                 ---------
microsoft365itpros.com                 False
office365itpros.com                    True
office365itpros.onmicrosoft.com        False
office365exchangebook.com              False
office365itproebook.com                False

For instance, if you ask for directory objects referencing office365itpros.com, Entra ID should retrieve a list of all user and group objects referencing the domain, such as in an object’s email address or user principal name. Figure 1 shows the Graph Explorer retrieving a list of office365itpros.com objects.

Here’s an example of the data returned for a user account:

Name                           Value
----                           -----
mail                           Ben.Owens@office365itpros.com
surname                        Owens
id                             a3eeaea5-409f-4b89-b039-1bb68276e97d
displayName                    Ben Owens (DCPG)
givenName                      Ben
jobTitle                       Chief bottle washer
businessPhones                 {}
officeLocation                 Moscow
@odata.type                    #microsoft.graph.user
userPrincipalName              Ben.Owens@office365itpros.com
preferredLanguage              en-US

The equivalent query can be run using the PowerShell Invoke-MgGraphRequest cmdlet:

$Uri = "https://graph.microsoft.com/v1.0/domains/office365itpros.com/domainNameReferences"

$Data = Invoke-MgGraphRequest -Uri $Uri -Method GET
Data

Name                           Value
----                           -----
@odata.context                 https://graph.microsoft.com/v1.0/$metadata#directoryObjects
value                          {a3eeaea5-409f-4b89-b039-1bb68276e97d, 96155a51-6885-4c8f-a8b6-e1614af08675, 67105a51-e…

What’s odd is that the query returns 300 items as a default and doesn’t include a nextlink pointer if further pages of data are available for retrieval:

$Items = $Data.Value
$items.count
300

Because the Get-MgDomainNameReference cmdlet is derived from the Graph query, it also returns 300 items, even if the All parameter is passed to instruct the cmdlet to retrieve all available pages:

[array]$DomainNames = Get-MgDomainNameReference -DomainId office365itpros.com -All
$DomainNames.count
300

You can increase the page size to retrieve up to 999 items, but that’s the limit. We can go no further because of the lack of a nextlink.

[array]$DomainNames = Get-MgDomainNameReference -DomainId office365itpros.com -PageSize 999
$DomainNames.count
424

SDK Cmdlets Depend on Underlying APIs

The same results occur in both the V1.0 and beta APIs. The original problem reported in issue 2494 was that the user accounts for shared mailboxes are not in the returned set. Perhaps the problem all along was the inability of the API to retrieve the complete set of available items? Who knows… Microsoft generates the SDK cmdlets from the underlying Graph APIs, so when a Graph API has a problem, it also shows up in the SDK.

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.

Failure to Update Compliance Search Action Capabilities Flaws Plan

Microsoft can be awfully persistent even when they are just plain wrong. The narrative around the Search-Mailbox cmdlet is a case in point. Microsoft originally announced the deprecation of the cmdlet in July 2020. However, the purported replacement (the purge action for compliance searches) has never worked and Microsoft could not remove Search-Mailbox because it is such a useful administrative cmdlet. Currently, if you run Search-Mailbox, you see the message:

WARNING: On September 1, 2023, the Search-Mailbox cmdlet will no longer be available.  See https://go.microsoft.com/fwlink/?linkid=2113221 to learn more.

Roll forward to January 4, 2024, and the publication of message center notification MC703706, headlined as the retirement post for the Search-Mailbox cmdlet. Or rather, the “Microsoft 365 Purview eDiscovery standard search-mailbox cmdlet.” It rather seems that the Microsoft Purview team has gained responsibility for the cmdlet and decided to progress with the retirement, despite the acknowledgement that Search-Mailbox is “a valuable tool for searching and exporting mailbox data for legal and compliance purposes.” Retirement is now scheduled to begin on March 1, 2024, and the cmdlet will disappear from all tenants by late March 2024.

Similar Functionality Promised

Microsoft then goes on to say that they intend moving “to other means of providing similar functionality” without specifying just what the replacement functionality is. MC703706 contains a link to the New-ComplianceSearch cmdlet. I think they mean the New-ComplianceSearchAction cmdlet because that’s how you add a purge action to an existing compliance search to hard- or soft-delete mailbox items (purging of documents or other types of Microsoft 365 items is unsupported).

Testing Mailbox Purges

In the past, I’ve tested the functionality of Search-Mailbox (Figure 1) against compliance search purges. To make sure that I hadn’t missed some developments in this area, I tested again using scripts to remove items from mailboxes. You can download the scripts I used from GitHub (here’s the Search-Mailbox version and here’s the compliance search actions version. Both scripts need a little setup to define the search queries, but the hardest part of testing is finding suitable test data to search for and remove followed by verification of the results. You’ll need to use the MFCMAPI utility to examine deleted items in the Purges folder in Recoverable Items.

Not much if anything has changed since I last spent some time figuring out how to use purge actions. Compliance searches are not fast and applying purge actions to the results of a compliance search isn’t fast either. Admittingly, in large environments, processing purges against a set of known search results that identify the mailboxes holding specific items offers an advantage over the need to open and search each target mailbox. Another factor is the complicated nature of creating a search, running the search, and then running a purge action against the search results. Using Search-Mailbox is simpler, especially when more than 10 items must be removed per mailbox or when you need to exclude items in the ‘dumpster’ (recoverable items). This is not surprising because the comparison is between a purpose-designed cmdlet and an add-on action processing content search results.

Both scripts search the online archive (you can disable archive searching with Search-Mailbox but not with compliance searches). Both hard-delete matching items. The big difference in the required time is because a search action can only remove 10 items per mailbox at a time whereas Search-Mailbox can remove up to 10,000 items from a mailbox. The history of Search-Mailbox in Exchange Server is as a response to the need to remove spam that ended up in user mailboxes, so it’s better able to remove many items. Compliance search actions are not intended as a method to clean up mailboxes.

Search-Mailbox can also copy items between mailboxes, which is not something that compliance search actions support.

Moving Forward

I’m not against Microsoft removing old cmdlets. The nature of Information Technology is that old components are replaced over time. Search-Mailbox only handles Exchange mailboxes and is out of touch with the trend to make compliance functionality work across all Microsoft 365 workloads. But as seen with mailbox retention policies, sometimes it is difficult to replicate workload-specific functionality (like folder-specific retention or move to archive) across all workloads. And compliance search actions can only purge mailbox items, so it’s not as if Microsoft plans to replace Search-Mailbox by workload-independent functionality.

It might make some happy (or check a box in a plan) to eradicate a vestige of Exchange Server from Microsoft 365, but if Microsoft retires Search-Mailbox without delivering comparable functionality in the Purview compliance suite, it will be a loss for customers and compliance administrators alike. I look forward to learning about what Microsoft plans in this space.

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 Default MRM Policy and the Deleted Items Folder

Vasil Michev’s recent post “Make sure Deleted items are automatically removed from Microsoft 365 mailboxes” covers Exchange Online mailbox retention policies. One of the points made is that the default mailbox retention policy (called Default MRM policy) doesn’t contain a folder retention tag for the Deleted Items folder. The effect is that items remain in Deleted Items indefinitely unless the policy assigned to a mailbox includes a default delete or default archive tag. In these circumstances, the Managed Folder Assistant (MFA) either deletes or archives items after items reach the retention period.

Microsoft removed the folder tag to control the Deleted Items folder from the default mailbox retention policies assigned to Exchange Online mailboxes in February 2015. For whatever reason, Microsoft was concerned that users “lost” items because the folder retention tag assigned to Deleted Items caused the MFA to remove items after 30 days. They said: “With this update, the length of time items remain in the Deleted Items folder is extended to indefinitely or according to the duration set by your administrator.”

In other words, if you left things alone, items remained in Deleted Items forever unless administrators stepped in to update the default mailbox retention policy or created a different mailbox retention policy and assigned it to mailboxes. At the time, I heeded the advice and updated the default mailbox retention policy to ensure that automatic removal of items from the Deleted Items folder continued.

Exchange Online Ignores Updates of the Default MRM Policy

Moving on to 2023, Vasil points out that it is no longer possible to assign a deleted items folder tag to the Default MRM policy in recently-created tenants. Vasil tested in a new tenant; I tested in my development tenant created in 2020. Here are the steps to demonstrate the issue. First, check that the Deleted Items retention tag exists and that it’s a folder tag for the Deleted Items folder:

Get-RetentionPolicyTag -Types DeletedItems | Format-Table Id, Type, RetentionAction, AgeLimitForRetention

Id            Type         RetentionAction        AgeLimitForRetention
--            ----         ---------------        --------------------
Deleted Items DeletedItems DeleteAndAllowRecovery 30.00:00:00

Now populate an array with the retention tags for the Default MRM policy. As expected, the tags are the default set defined by Microsoft for this policy:

[array]$RetentionTags = Get-RetentionPolicy -Identity 'Default MRM Policy' | Select-Object -ExpandProperty RetentionPolicyTagLinks
$RetentionTags

5 Year Delete
1 Year Delete
6 Month Delete
Personal 5 year move to archive
1 Month Delete
1 Week Delete
Personal never move to archive
Personal 1 year move to archive
Default 2 year move to archive
Junk Email
Recoverable Items 14 days move to archive
Never Delete

Now add the Deleted Items retention tag to the array of tags, update the mailbox retention policy, and check the set of retention tags in the policy:

$RetentionTags += "Deleted Items"
Set-RetentionPolicy -Identity "Default MRM Policy" -RetentionPolicyTagLinks $RetentionTags
Get-RetentionPolicy -Identity 'Default MRM Policy' | Select-Object -ExpandProperty RetentionPolicyTagLinks

5 Year Delete
1 Year Delete
6 Month Delete
Personal 5 year move to archive
1 Month Delete
1 Week Delete
Personal never move to archive
Personal 1 year move to archive
Default 2 year move to archive
Junk Email
Recoverable Items 14 days move to archive
Never Delete

There’s no sign of the Deleted Items folder tag in the set of retention tags for the Default MRM policy. Exchange Online simply ignored the update (Figure 1).

Everything Works With a New Retention Folder Tag for Deleted Items

But if you define a new retention tag for Deleted Items, the same commands work to add the new retention tag to the Default MRM policy:

New-RetentionPolicyTag -AgeLimitForRetention 365 -RetentionAction DeleteAndAllowRecovery -Name 'Deleted Items Remove After 1 Year' -RetentionEnabled $True -MessageClass * -Type DeletedItems

Name                      Type                      Description
----                      ----                      -----------
Deleted Items Remove Aft… DeletedItems              Managed Content Settings

 [array]$RetentionTags = Get-RetentionPolicy -Identity 'Default MRM Policy' | Select-Object -ExpandProperty RetentionPolicyTagLinks
$RetentionTags += 'Deleted Items Remove After 1 Year'
Set-RetentionPolicy -Identity "Default MRM Policy" -RetentionPolicyTagLinks $RetentionTags
Get-RetentionPolicy -Identity 'Default MRM Policy' | select-Object -ExpandProperty RetentionPolicyTagLinks

Deleted Items Remove After 1 Year
Delete After 10 Years
5 Year Delete
1 Year Delete
6 Month Delete
Personal 5 year move to archive
1 Month Delete
1 Week Delete
Personal never move to archive
Personal 1 year move to archive
Default 2 year move to archive
Junk Email
Recoverable Items 14 days move to archive
Never Delete

Something screwy is going on here. Microsoft’s documentation for “What you can do with the Default MRM policy” explicitly says that it’s possible to add a retention tag to the policy. No exceptions are called out for a specific Deleted Items folder tag. And Microsoft’s documentation makes no mention that attempts to add the Deleted Items folder tag to the Default MRM policy will be ignored without any error.

Why Handicap the Default MRM Policy

Software bugs happen and it’s entirely possible that a software engineer made a mistake in the code that processes addition of retention tags to a retention policy. However, surely Microsoft would have noticed and fixed such a bug before now? Another possibility is that Microsoft deliberately decided to handicap the Default MRM policy to encourage tenants to move to Microsoft 365 retention policies. Microsoft 365 retention operates on a container basis and a retention policy applied to a mailbox acts in the same manner as a default delete tag, meaning that items in the Deleted Items folder are processed in the same way as items in all other folders.

Microsoft 365 retention doesn’t support specific retention processing for selected folders, nor does it support a method to move items to archive mailboxes. Both are reasons why Exchange MRM persists and pose a challenge for Exchange Online tenants who want to move to the workload-agnostic approach taken by Microsoft 365 retention. In truth, Microsoft 365 retention tries to be agnostic, but all sorts of compromises exist to ensure that retention processing can deal with different kinds of items from email to documents to Copilot interactions.

Getting back to the point in hand, depowering the Default MRM policy for new tenants seems like a backward step. I don’t see the advantage gained by Microsoft and especially not by tenants. Microsoft should reverse this block and let Exchange Online administrators realize the promise made in Microsoft’s documentation to be able to configure retention as they need. It’s the right thing to do.

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.

A Better Check for Unused Distribution Lists Than a 10-day Lookback

A recent article explaining how to use historical message trace data to create an inbound email report for the last 90 days sparked an idea about how to improve checking for inactive distribution lists and clean up the directory

As explained in this article, using online message trace data limits the check to the last ten days and that’s probably not enough in some circumstances. For example, a distribution list might be used just once or twice a month for important communications. A ten-day lookback will consider the distribution list to be inactive if it isn’t used in that window. Further checks should prevent the deletion of the distribution list but an automated process might remove it.

Going back ninety days to check activity is a different matter. If a distribution list remains unused for three months, it’s probably a good candidate for removal. Let’s discuss how to implement the check.

Retrieving Historical Message Trace Data for Distribution Lists

As a quick refresh, we know that Exchange Online holds message trace data online for only ten days. After this, Exchange Online moves the message trace data to colder long-term Azure storage. Historical message trace searches initiated from the Exchange admin center or using the Start-HistoricalSearch cmdlet launch background search jobs to access the Azure storage and retrieve the requested data, which administrators can then download as CSV files.

In the article to build an inbuild email report for a tenant, I explain how to use multiple search jobs to fetch message trace data before combining the data to generate the report. This technique is necessary to avoid exceeding limits for historical search jobs, like the maximum of 100 email addresses a job can process. This is obviously a problem when dealing with mailboxes because to generate a report for a complete tenant, you must fetch message trace data for every mailbox, and that means splitting up mailboxes in batches of 100 to retrieve the data.

The lower number of distribution lists (usually) means that fewer historical search jobs are needed to fetch message trace data. For instance, if a tenant has 100 distribution lists or fewer, all the data needed can be fetched using a single historical search job, Here’s how to create and submit the job with PowerShell:

[array]$DLs = Get-DistributionGroup -ResultSize Unlimited
[array]$DLRecipientAddresses = $DLs.PrimarySMTPAddress
$StartDate = (Get-Date).AddDays(-90)
$ReportName = ("DL Historical Search from {0} Submitted {1}" -f $StartDate, (Get-Date -format g))

$Status = Start-HistoricalSearch -RecipientAddress $DLRecipientAddresses -StartDate $StartDate -EndDate (Get-Date) -ReportType MessageTrace -ReportTitle $ReportName -Direction Sent -NotifyAddress Jay.Redmond@office365itpros.com

Microsoft 365 runs the historical searches in the background and the results might take some time before the results are available for download. It’s time for a coffee. After the jobs finish, download the files to a folder for processing (I use c:\temp\).

Processing Historical Message Trace Data for Distribution Lists

The downloaded message trace data holds records for messages sent to distribution lists over the last 90 days. Using a PowerShell script, the steps to process the data to figure out if distribution lists are active goes something like this:

• Process the downloaded data to find entries relating to distribution lists and extract that information to an array. A message trace record can be for a message sent to multiple recipients, so it’s necessary to check each recipient to detect when a record relates to a distribution list.
• For each distribution list, check its primary SMTP address against the array of message trace data and select the record with the most recent timestamp.
• Report what’s found for a distribution list. Both conditions are covered – either the code finds a message trace record for a list or it doesn’t.
• Generate the output (a CSV file) and output some statistics:

No messages found for distribution list Users External Email Monitoring
No messages found for distribution list Users Who Don't Use MyAnalytics
No messages found for distribution list Vice Presidents
No messages found for distribution list VIP Users
Found message for Distribution list Yammer Development at 28/10/2023 15:56

Total distribution lists checked:     81
Active distribution lists:            7
Percentage active distribution lists: 8.64%
Inactive distribution lists:          74

Figure 1 shows some of the information collected about distribution lists. The records at the top have timestamps showing when message trace noted the delivery of a message sent to the distribution list as it passed through the Exchange Online transport service. If the timestamp is “N/A,” it means that no message trace record can be found for that distribution list, so we can conclude that no one has sent a message to that distribution list in the last 90 days.

My code is available from GitHub. Feel free to improve the script!

No Magic, Just Data

There’s no rocket science here. It’s a matter of using data captured by Exchange Online that’s available for analysis. The only magic is some PowerShell and a little bit of lateral thinking about how to prove when distribution lists are in active use.

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.

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.

Exploit Graph Usage Data Instead of PowerShell Cmdlets

The first report generated by Exchange administrators as they learn PowerShell is often a list of mailboxes. The second is usually a list of mailboxes and their sizes. A modern version of the code used to generate such a report is shown below.

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Sort-Object DisplayName | Get-ExoMailboxStatistics | Format-Table DisplayName, ItemCount, TotalItemSize -AutoSize

I call the code “modern” because it used the REST-based cmdlets introduced in 2019. Many examples persist across the internet that use the older Get-Mailbox and Get-MailboxStatistics cmdlets.

Instead of piping the results of Get-ExoMailbox to Get-ExoMailboxStatistics, a variation creates an array of mailboxes and loops through the array to generate statistics for each mailbox.

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
Write-Host ("Processing {0} mailboxes..." -f $Mbx.count)

$OutputReport = [System.Collections.Generic.List[Object]]::new()

ForEach ($M in $Mbx) {
  $MbxStats = Get-ExoMailboxStatistics -Identity $M.ExternalDirectoryObjectId -Properties LastUserActionTime
  $DaysSinceActivity = (New-TimeSpan $MbxStats.LastUserActionTime).Days
  $ReportLine = [PSCustomObject]@{
    UPN               = $M.UserPrincipalName
    Name              = $M.DisplayName
    Items             = $MbxStats.ItemCount
    Size              = $MbxStats.TotalItemSize.Value.toString().Split("(")[0]
    LastActivity      = $MbxStats.LastUserActionTime
    DaysSinceActivity = $DaysSinceActivity
   } 
   $OutputReport.Add($ReportLine)
 }
$OutputReport | Format-Table Name, UPN, Items, Size, LastActivity

In both cases, the Get-ExoMailboxStatistics cmdlet fetches information about the number of items in a mailbox, their size, and the last recorded user interaction. There’s nothing wrong with this approach. It works (as it has since 2007) and generates the requested information. The only downside is that it’s slow to run Get-ExoMailboxStatistics for each mailbox. You won’t notice the problem in small tenants where a script only needs to process a couple of hundred mailboxes, but the performance penalty mounts as the number of mailboxes increases.

Graph Usage Data and Microsoft 365 Admin Center Reports

Microsoft 365 administrators are probably familiar with the Reports section of the Microsoft 365 admin center. A set of usage reports are available to help organizations understand how active their users are in different workloads, including email (Figure 1).

The basis of the usage reports is the Graph Reports API, including the email activity reports and mailbox usage reports through Graph API requests and Microsoft Graph PowerShell SDK cmdlets. Here are examples of fetching email activity and mailbox usage data with the SDK cmdlets. The specified period is 180 days, which is the maximum:

Get-MgReportEmailActivityUserDetail -Period 'D180' -Outfile EmailActivity.CSV
[array]$EmailActivityData = Import-CSV EmailActivity.CSV
Get-MgReportMailboxUsageDetail -Period 'D180' -Outfile MailboxUsage.CSV
[array]$MailboxUsage = Import-CSV MailboxUsage.CSV

I cover how to use Graph API requests in the Microsoft 365 user activity report. This is a script that builds up a composite picture of user activity across different workloads, including Exchange Online, SharePoint Online, OneDrive for Business, and Teams. One difference between the Graph API requests and the SDK cmdlets is that the cmdlets download data to a CSV file that must then be imported into an array before it can be used. The raw API requests can fetch data and populate an array in a single call. It’s just another of the little foibles of the Graph SDK.

The combination of email activity and mailbox usage allows us to replace calls to Get-ExoMailboxStatistics (or Get-MailboxStatistics, if you insist on using the older cmdlet). The basic idea is that the script fetches the usage data (as above) and references the arrays that hold the data to fetch the information about item count, mailbox size, etc.

You can download a full script demonstrating how to use the Graph usage data for mailbox statistics from GitHub.

User Data Obfuscation

To preserve user privacy, organizations can choose to obfuscate the data returned by the Graph and replace user-identifiable data with MD5 hashes. We obviously need non-obfuscated user data, so the script checks if the privacy setting is in force. If this is true, the script switches the setting to allow the retrieval of user data for the report.

$ObfuscatedReset = $False
If ((Get-MgBetaAdminReportSetting).DisplayConcealedNames -eq $True) {
    $Parameters = @{ displayConcealedNames = $False }
    Update-MgBetaAdminReportSetting -BodyParameter $Parameters
    $ObfuscatedReset = $True
}

At the end of the script, the setting is switched back to privacy mode.

Faster but Slightly Outdated

My tests (based on the Measure-Command cmdlet) indicate that it’s much faster to retrieve and use the email usage data instead of running Get-ExoMailboxStatistics. At times, it was four times faster to process a set of mailboxes. Your mileage might vary, but I suspect that replacing cmdlets that need to interact with mailboxes with lookups against arrays will always be faster. Unfortunately the technique is not available for Exchange Server because the Graph doesn’t store usage data for on-premises servers.

One downside is that the Graph usage data is always at least two days behind the current time. However, I don’t think that this will make much practical difference because it’s unlikely that there will be much variation in mailbox size over a couple of days.

The point is that old techniques developed to answer questions in the earliest days of PowerShell might not necessarily still be the best way to do something. New sources of information and different ways of accessing and using that data might deliver a better and faster outcome. Always stay curious!

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.

List All Email Proxy Addresses for Exchange Online Objects

A reader of the Office 365 for IT Pros eBook asked if there’s an easy way to see a list of all the email addresses used in a tenant. The simple answer is that there’s no out-of-the-box method to see this information. Some work is needed to extract and report a list of all email addresses. It’s not just the primary SMTP address for mailboxes either – such a report must include all the proxy SMTP addresses for all mail-enabled objects.

Proxy Addresses

An Exchange Online mail-enabled object such as a user mailbox can have up to 300 different proxy addresses. Although most inbound email arrives addressed to a mail-enabled object’s primary SMTP address, Exchange Online can deliver messages to any of the proxy addresses (aliases) assigned to a mail-enabled object. Outbound, Exchange Online mailboxes can send email using any proxy address.

Proxy addresses are permanently assigned to a mail-enabled object and stored in the Exchange Online directory. They’re not the same as plus addressing, which individual people can use to create a specific form of a proxy address to receive email from certain senders. Apart from SMTP addresses, the proxy addresses assigned to user mailboxes include SIP and SPO addresses. The first is used for federated chat; the second is used to store SharePoint Online information into user mailboxes. The Microsoft 365 substrate ingests SharePoint Online content into mailboxes to create ‘digital twins’ that are used by cloud processes and services.

Creating a PowerShell Script to Report SMTP Proxy Addresses

Now that we’ve got the definitions out of the way, let’s use PowerShell to answer the question. The steps involved are very straightforward and can be summarized as:

For each type of mail-enabled objects supported by Exchange Online, find the SMTP proxy addresses and report them.

I wrote a script to do the job (you can download the code from GitHub). It breaks processing up into:

• Mailboxes (user, shared, room, and resource).
• Group mailboxes (for Microsoft 365 groups).
• Mail-enabled public folders.
• Distribution lists.
• Dynamic distribution lists.

For instance, here’s the code to process mailboxes:

Write-Host "Fetching details of user, shared, equipment, and room mailboxes..."
[array]$Mbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, RoomMailbox, EquipmentMailbox
Write-Host ("Processing details for {0} mailboxes..." -f $Mbx.count)
ForEach ($M in $Mbx) {
    ForEach ($Address in $M.EMailAddresses) {
        $AddressType = $Address.Split(":")[0]
        $AddressProxy = $Address.Split(":")[1]
        If ($AddressType -eq 'smtp') {
            $ReportLine = [PSCustomObject]@{ 
                ProxyAddress = $AddressProxy
                Name         = $M.DisplayName
                UPN          = $M.userPrincipalName
                ObjectId     = $M.ExternalDirectoryObjectId
                Type         = $M.RecipientTypeDetails
            }
            $Report.Add($ReportLine)
        }
    }
}

The code examines each proxy address. If its address type is SMTP, the script records the address and some other information. It’s really that simple. Figure 1 shows some of the list of SMTP proxy addresses extracted from my tenant.

Using the List of Email Proxy Addresses

The next question is how to use such a list? One idea is to load some of the list of proxy addresses into a hash table and use the table to add extra detail to the information provided in message trace logs by resolving email addresses to find the display name for message recipients.

To test the idea, I enhanced some code from the article about using message trace logs to analyze email traffic to add the creation and population of a hash table using data imported from the CSV file output for the list of proxy addresses. For each message in the trace data, I then attempt to find a match in the hash table and include the name of the recipient if found. The added code is in italics.

[array]$EmailProxies = Import-CSV "C:\Temp\EmailProxyAddresses.csv"
$EmailProxyHash = @{}
ForEach ($E in $EmailProxies) {
   $EmailProxyHash.Add($E.ProxyAddress, $E.Name) }

$MessageReport = [System.Collections.Generic.List[Object]]::new() 

ForEach ($M in $Messages) {
   $Direction = "Inbound"
   $DisplayName = $Null
   $SenderDomain = $M.SenderAddress.Split("@")[1]
   $RecipientDomain = $M.RecipientAddress.Split("@")[1]
   If ($SenderDomain -in $Domains) {
      $Direction = "Outbound" 
   }
   $DisplayName = $EmailProxyHash[$M.RecipientAddress] 

   $ReportLine = [PSCustomObject]@{
     TimeStamp       = $M.Received
     Sender          = $M.SenderAddress
     Recipient       = $M.RecipientAddress
     Name            = $DisplayName
     Subject         = $M.Subject
     Status          = $M.Status
     Direction       = $Direction
     SenderDomain    = $SenderDomain
     RecipientDomain = $RecipientDomain
    }
    $MessageReport.Add($ReportLine)
}

No doubt others will find more creative ways to use the listing of email proxy addresses. If you do, let us know in the comments.

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

Three Steps to Shrinking Memory Demands for Exchange Online PowerShell

I read the Exchange team’s blog post about Exchange Online PowerShell performance. The team behind the Exchange Online management module made three recommendations:

• Don’t load the module help when running scripts in non-interactive sessions. In other words, humans might need some help to understand what cmdlets do but computers don’t. Computers never ask for more detail about the commands they’re asked to execute. They just get on with the job.
• Restrict the number of cmdlets loaded into a PowerShell session. The Exchange Online management module spans some 800 cmdlets. Any session is likely to use less than ten cmdlets. In fact, many scripts might only use the REST-based cmdlets introduced in 2019. These cmdlets (like Get-ExoMailbox and Get-ExoMailboxStatistics) are always loaded by the module into memory along with some of the more recently introduced cmdlets, like Get-UserBriefingConfig. Along with the REST cmdlets, a script might use one or two modernized cmdlets (like Get-User). Modernized means that the cmdlets no longer support basic authentication and have discarded dependencies like WinRM.
• Create a new PowerShell process for each Exchange Online session. The idea here is that the new session starts off with an empty cache and that reduces the memory footprint. Sounds good, but I bet not many will follow this guidance. I say this for two reasons. First, people are generally lazy and don’t want to go through the hassle of starting and shutting down perfectly good PowerShell sessions. Second, most people working with Microsoft 365 load several modules such as the Microsoft Graph PowerShell SDK and Teams.

In any case, the advice is appreciated and should be considered in the light of whatever work you do with the Exchange Online management module.

New Parameter for Connect-ExchangeOnline

To support avoiding cmdlet help, the latest version of the Exchange Online management module (3.4) boasts the SkipLoadingCmdletHelp parameter. The implementation works very nicely and speeds up module loading. I recommend that you use this parameter in every script that runs without human intervention. For instance, I have some work to do to upgrade scripts (runbooks) written to run using Azure Automation. The next time I touch the code for any of the runbooks, I’ll be sure to add the parameter to Connect-ExchangeOnline.

Avoiding memory overhead like this should be very helpful in any script that combines the Exchange Online management module with the Microsoft Graph PowerShell SDK. When Microsoft created V2 of the Microsoft Graph PowerShell SDK, they split the cmdlets into V1.0 and beta sets to reduce the overhead of loading the SDK for Azure Automation runbooks.

Remember to update your Azure Automation accounts with the latest module so that runbooks can take advantage of the new feature. That might be even more important than keeping the module updated on your workstation (here’s a handy script that I use for that purpose).

Figuring Out Exchange Online PowerShell Cmdlets

Building a list of Exchange Online cmdlets used in a script is a matter of checking the cmdlets called and understanding if they come from the Exchange Online management module and then constructing a list to use with Connect-ExchangeOnline. The Get-Command module returns a small subset of the available cmdlets.

Get-Command -Module ExchangeOnlineManagement

Do not include any of these cmdlets in the set passed to Connect-ExchangeOnline as you’ll get an error like “OperationStopped: No cmdlet assigned to the user have this feature enabled.”

When you’ve determined the set of cmdlets needed by a session, put them in an array and pass the array in the CommandName parameter. This example combines the parameter to skip loading cmdlet help with a defined set of cmdlets to load into a session.

$Cmdlets = "Set-User", "Get-User", "Get-OWAMailboxPolicy", "Set-OWAMailboxPolicy"
connect-ExchangeOnline -SkipLoadingCmdletHelp -CommandName  $Cmdlets

Detail is Important When Running Exchange Online PowerShell

Of course, you could ignore these recommendations and continue running your scripts as before. It’s a good tactic if the scripts work and you’re happy. On the other hand, if you’re looking for some extra performance and reduced memory consumption, these tips are worth considering. I suspect that the folks who will benefit most are those who run PowerShell against tens of thousands of objects (mailboxes, user accounts, etc.).

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.

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.

MFCMAPI Exposes Data Stored by Microsoft 365 Apps in Exchange Online Mailboxes

I regularly use the MFCMAPI program to help understand the contents stored in Exchange Online mailboxes. When I mention this, people often look at me as if I have two heads. They have questions like what magic exists in MFCMAPI and how do I use the magic? That discussion could probably take hours, but let’s see if I can deliver a primer on how to get and use the program.

MFCMAPI Origins and Current Status

MFCMAPI originated as a program written by Microsoft escalation engineers to help debug Outlook desktop. This 2014 article explains some of the background. However, MFCMAPI was available several years beforehand, perhaps starting in 2008 or thereabouts. Since then, it’s been used for a variety of purposes (including creating Outlook profiles) and exporting mailbox data. You can also move or rename folders. However, modifying mailbox data with a low-level utility is not a recommended course of action because you could do serious damage to the mailbox.

I don’t think I have ever created anything with MFCMAPI; my use has always been to poke around the innards of a mailbox to discover what apps store there. In an on-premises environment, a mailbox stores email and some mailbox settings. But in the cloud, Exchange Online mailboxes are used by apps for a variety of purposes such as storing compliance records and Teams attendance records, mostly so that the data is indexed and becomes accessible to Search and services like eDiscovery. User mailboxes are a very convenient place for Microsoft 365 apps to store information and that’s why the program is so useful for administrators who want to understand how apps store data.

Today, Microsoft maintains MFCMAPI through a GitHub project. Stephen Griffin, one of the original brains behind MFCMAPI, still works on the code. You can download the latest release from GitHub. For instance, the latest 64-bit version is available in MFCMAPI.x64.exe.23.0.23089.01.zip.

Using MFCMAPI

MFCMAPI is only able to access user mailboxes, which it does through an Outlook profile. Before launching the program, go to Outlook desktop and make sure that the Outlook profile does not enable cached Exchange mode. If it does, MFCMAPI is limited to accessing synchronized folders and many of the more interesting server-based folders are inaccessible.

Now launch MFCMAPI and choose Logon from the Session menu. MFCMAPI displays a prompt to select the Outlook profile to use and then signs into your account using the information in the profile and lists the message stores available to the profile (Figure 1). Because MFCMAPI uses Outlook profiles for sign-ins, you can’t use the program to open anything other than user or shared mailboxes. This is logical because when the program started, objects like group mailboxes didn’t exist.

Although MFCMAPI lists public folders, you’ll see an error if you try and access them with the program.

Accessing Folders

Select the default store (marked with True in the Default Store column). This is your primary mailbox and double click to open the store. MFCMAPI opens a separate window positioned at the Root Container in the store. This is the root of everything in the mailbox – both the folders visible to users (IPM folders) and those never revealed by clients (non-IPM folders).

Click on Root Container to reveal the set of folders underneath. In Figure 2 you can see some of the folders contained in the mailbox. Three are highlighted:

• Recoverable items: This is where Exchange Online stores deleted items that users can still recover plus copies of items purged or altered when within the scope of a retention policy.
• TeamsMessagesData: This is where Teams stores its compliance records captured for personal and group chats involving the mailbox owner.
• Top of Information Store: This is where the IPM folders are located and you can see a couple of default mailbox folders (Calendar and Archive) plus a user-created folder (Amazon).

As a simple example of what MFCMAPI can reveal, double-click on the TeamsMessagesData folder. The program opens another window to list the items in the folder (Figure 3). Remember, this is a non-IPM folder, so users don’t know of its existence.

The lower pane shows the MAPI properties of the item like its creation date. Message items can have hundreds of properties, many of which are only understood by the generating app. In this instance, the text of the message sent in a Teams chat is available in the PR_HTML property (Figure 4).

The important thing here is that the compliance record is stored as a mailbox item. It is a partial version of the actual Teams message posted in the chat that caused the substrate to create the compliance item. These items exist to allow Microsoft Search to index the content of the chat and eDiscovery searches to find them when necessary.

Enough for a Primer

I think that’s enough for a primer on this topic. There’s lots more that can be done with MFCMAPI, but it serves a useful purpose even if you just use the program to understand what’s in Exchange Online mailboxes. Explore your own mailbox to see what you can find hidden behind the scenes. It can be very revealing!

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.

Updating Distribution List Proxy Addresses is a Good Example of PowerShell in Action

A question in the Microsoft Technical Community asks how to perform a bulk update of all distribution lists whose primary SMTP address uses the tenant service domain and replace this address with one from a “vanity” domain owned by the tenant. For example, replace onmicrosoft.contoso.com with contoso.com. This sometimes happens when a tenant begins operations and forgets to assign an address from a vanity domain when creating new distribution lists (Figure 1). It can also occur if an organization decides to use a different domain for whatever reason.

Updating primary SMTP addresses for any mail-enabled object is a great example of how PowerShell is so useful to tenant administrators. Let’s figure out what you might do.

Find Distribution Lists to Update

The first step is to extract the set of domains known for the tenant and find the domain marked as the default. We’ll use that domain to create new primary SMTP addresses:

[array]$Domains = Get-AcceptedDomain
$PreferredDomain = $Domains | Where-Object {$_.Default -eq $True} | Select-Object -ExpandProperty DomainName
If (!($PreferredDomain)) { Write-Host "Can't find the default domain" ; break }

You can use any of the accepted domain defined for the tenant, so if you want to use a different domain, amend the script to insert the desired domain in the $PreferredDomain variable.

Find the Target Distribution Lists

Now let’s find the set of distribution lists that use the service domain for their primary SMTP address:

[array]$DLs = Get-DistributionGroup | Where-Object {$_.PrimarySMTPAddress -like "*onmicrosoft.com*"}
If (!($DLs)) {
   Write-Host "No distribution lists use the service domain for their primary SMTP address" ; break
} Else {
   Write-Host ("{0} distribution lists found to update" -f $DLs.count)
}

To check details of the distribution lists, run this command:

$DLs | Format-Table DisplayName, PrimarySMTPAddress

Update the Distribution Lists with a New Primary SMTP Address

If you’re happy to go ahead, this code uses the Set-DistributionGroup cmdlet to update the primary SMTP address for the distribution lists. The code builds the new primary SMTP address for a list from its alias and the preferred domain:

ForEach ($DL in $DLs) {
  $NewSMTPAddress = $DL.Alias + "@" + $PreferredDomain
  Write-Host ("Updating distribution list {0} with new address {1}..." -f $DL.DisplayName, $NewSMTPAddress )
  Set-DistributionGroup -Identity $DL.Alias -PrimarySMTPAddress $NewSMTPAddress
}

Exchange Online keeps all previous SMTP proxy addresses (including the prior primary SMTP address) to make sure that it can correctly handle messages sent to the distribution lists using those addresses. You can see this by running the Get-DistributionGroup cmdlet to examine the email addresses:

Get-DistributionGroup -Identity 'San Francisco Rooms' | Select-Object -ExpandProperty EmailAddresses
SMTP:SanFranciscoRooms@Office365itpros.com
smtp:SanFranciscoRooms@office365itpros.onmicrosoft.com

Alternatively, you can see the proxy addresses by examining the distribution list properties in the Exchange admin center.

The primary SMTP address is only one distribution list proxy address. Like any Exchange Online recipient, a distribution list can have up to 300 proxy addresses (depending on the length of the addresses), so there’s usually plenty of room to store proxy addresses created for different reasons.

Distribution Lists Still Have a Place

Despite Microsoft’s ongoing efforts to persuade customers that Microsoft 365 groups are better than distribution lists, there’s no doubt that these objects still have a place in any tenant. A Microsoft 365 group is a great choice when you want to use Teams or Outlook groups for collaboration, but scenarios still exist where a simple distribution list is the best way to communicate, especially when you want to include external email addresses (guest accounts can also be members of distribution lists).

Here’s a script to report distribution list membership, just in case you’re looking for another project after fixing distribution list proxy addresses and making sure that the right primary SMTP address is in place.

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.

Shared Mailbox Quota Report a Take on an Old Script

In September 2019, I wrote about using PowerShell to generate an Exchange Online mailbox quota report. The idea was to allow administrators to identify mailboxes that surpassed a certain quota threshold (say 85%) so that they could proactively manage the situation and prevent users from exceeding quota. It’s never good for someone to be unable to send and receive email because of a blown quota.

The 2019 article came to mind when I was asked about writing a script to report quota usage for shared mailboxes. These mailboxes don’t have formal owners, but the idea was to regard anyone with full access to the mailbox as an owner. The purpose of the script is to capture details of quota usage and email that information to the mailbox owners.

Stitching Bits Together to Create a New Script

One of the nice things about PowerShell is that it’s easy to reuse code from scripts to form a new solution. In this case, I used the following:

• Code to calculate the percentage of quota used for a mailbox. The figures returned by the Get-ExoMailboxStatistics cmdlet need some manipulation to make them easier to work with.
• Create and send email using the Microsoft Graph PowerShell SDK. I decided to use the Send-MgUserMail cmdlet to send the notification message, and this cmdlet is best for simple messages.
• How to authenticate with the Microsoft Graph PowerShell SDK using a registered app and certificate thumbprint. If you use an interactive session to connect to the Graph, you can only send email from the mailbox belonging to the signed-in account (delegate permission). To use another account, you must authenticate via an app that has consent to use the Mail.Send.All permission. Using certificate-based authentication is more secure than account passwords. In a production environment, I’d use Azure Automation to run the job on a scheduled basis and use a managed identity for authentication.

Reusing code saves time, which is one of the prime benefits cited for GitHub Copilot. Why write code from scratch when you can find it on the internet (always test this code first) or on your workstation?

Script Code Flow to Create and Email Shared Mailbox Quota Reports

The major steps in the script are:

• Define settings such as the account used to send email, the account that will serve as the default recipient if no accounts with full access are found for a mailbox, app and tenant identifiers, and the certificate thumbprint to use for authentication.
• Sign into Exchange Online to use cmdlets like Get-ExoMailboxStatistics.
• Sign into the Graph using an app and certificate.
• Find the set of shared mailboxes with Get-ExoMailbox.
• For each mailbox, find the set of accounts with full access rights. This set might include security groups, so some processing is needed to identify groups and extract their membership.
• Check if mailboxes are assigned a product license containing the Exchange Online Plan 2 service plan. If so, their quota is higher (100 GB) than the default (50 GB). Some unlicensed mailboxes have the higher quota, but that’s only because Microsoft hasn’t reduced those quotas (yet).
• Fetch the current mailbox statistics.
• Compute the percentage of quota used.
• Write data about each shared mailbox into a list.

After processing the shared mailboxes, a second step loops through the list to create and send messages to the mailbox owners to tell them how much quota is used. Figure 1 shows an example of a quota message generated by the script.

The message is sparse and lots of possibilities exist for including other information in it, such as pointers to tell recipients what to do if the percentage quota used is more than a certain threshold. You’re only limited by your imagination!

You can download the full script from GitHub.

PowerShell Fills the Gaps

This is yet another example of how to use PowerShell to fill in the gaps in Microsoft 365 tenant administration. Some people might not care too much about shared mailbox quotas, other will be very concerned. PowerShell gives you the ability to code your own solution if you think it’s necessary.

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.

Use PowerShell to Analyze Message Trace Data to Find Out Who’s Sending External Email

Updated 8 November 2023

In an August 2023 article, I explain how to use PowerShell to analyze message trace data to report the volume of traffic going to external domains. A follow-up question about that article asked if it was possible to create a report showing the volume of external and internal email sent by each user. It seemed like this should be a straightforward thing to do, and that’s what I explain how to do here.

Message trace data captures the sender and recipient for each message. If the recipient address doesn’t belong to one of the domains registered for the tenant, we can conclude that it’s external email. The previous article explains how to fetch message data for the last ten days from Exchange Online and construct a list of messages suitable for analysis. This script uses exactly the same code to fetch message trace data. The difference is what we do with that data.

Finding Messages for Users

The first thing is to find the set of mailboxes we’re interested in reporting. The example script processed both user and shared mailboxes.

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, SharedMailbox -ResultSize Unlimited

Now the script loops through each mailbox and finds if any message trace transactions are available for the mailbox. If true, the script counts internal and external messages and calculates the percentage of the overall total for each category. The script also records to which external domains a mailbox sends messages before capturing the data in a PowerShell list:

ForEach ($User in $Mbx) {
  Write-Host ("Processing email for {0}" -f $User.DisplayName)
  # Get messages sent by the user
  [array]$UserMessages = $Messages| Where-Object {$_.Sender -eq $User.PrimarySmtpAddress}
  If ($UserMessages) {
  # We’ve found some messages to process, so let’s do that
  [int]$ExternalEmail = 0; [int]$InternalEmail = 0; [array]$ExternalDomains = $Null
  ForEach ($M in $UserMessages) {
    $MsgRecipientDomain = $M.RecipientAddress.Split('@')[1]    
        If ($MsgRecipientDomain -in $Domains) {
            $InternalEmail++ 
        } Else {
            $ExternalEmail++
            $ExternalDomains += $MsgRecipientDomain
        }
  }
  $ExternalDomains = $ExternalDomains | Sort-Object -Unique
  $PercentInternal = "N/A"; $PercentExternal = "N/A"
  If ($InternalEmail -gt 0) {
     $PercentInternal = ($InternalEmail/($UserMessages.count)).toString("P") }
  If ($ExternalEmail -gt 0) {
     $PercentExternal = ($ExternalEmail/($UserMessages.count)).toString("P") }

  $ReportLine = [PSCustomObject]@{
    User          = $User.UserPrincipalName
    Name          = $User.DisplayName
    Internal      = $InternalEmail
    "% Internal"  = $PercentInternal
    External      = $ExternalEmail 
    "% External"  = $PercentExternal
    "Ext.Domains" = $ExternalDomains -Join ", "
    “Mbx Type”    = $User.RecipientTypeDetails }
  $MessageReport.Add($ReportLine)
 } # End if user
} # End ForEach mailboxes

An example of the information reported for a mailbox is shown below:

User        : Tony.Redmond@office365itpros.com
Name        : Tony Redmond (User)
Internal    : 115
% Internal  : 64.97%
External    : 62
% External  : 35.03%
Ext.Domains : bermingham.com, codetwo.com, eastman.com, eightwone.com, microsoft.com, nordan.ie, o365maestro.onmicrosoft.com, office365.microsoft.com, ravenswoodtechnology.com, sharepointeurope.com, thecluelessguy.de

Generating an Analysis Report

After generating the report file, the script creates two output files: a CSV file that might be used for further analysis with Excel or another tool (perhaps it might be interesting to visualize the data in Power BI) and a HTML report (Figure 1).

An “N/A” value in either of the field reporting the percentage of email sent internally or externally means that the user sent no messages of this type during the reporting period (last 10 days). If a mailbox doesn’t send any email during that time, the script doesn’t include it in the report.

You can download the full script from GitHub.

It’s PowerShell

The point is that none of what the script does is magic. The message trace data is easily accessible and available for analysis. All you need to do is slice and dice the data as you wish, using PowerShell to sort, refine, or otherwise process the information. Learning how to use PowerShell is such a fundamental part of working with tenant data that it always surprises me when I meet tenant administrators who seem unwilling to master the shell. Oh well, at least it gives me topics to write about!

Learn about maximizing the use of Exchange Online data 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.

1 October 2026 Retirement Date Set for Exchange Web Services

On September 19 2023, Microsoft announced their intention to retire the Exchange Web Services (EWS) protocol on 1 October 2026 and replace it with Graph APIs. The retirement only affects non-Microsoft apps. Microsoft 365 apps like Teams can continue to use EWS to read data from Exchange Online mailboxes. EWS continues to be supported for Exchange Server as the Graph API is unavailable for on-premises servers.

Three years seems like a long way off. However, an extended period is needed by app developers to convert EWS code to Graph API requests. There shouldn’t be much difficulty in recreating code dealing with accounts, mailboxes, and calendars. Microsoft knows that the problems lie in areas not covered by the Graph API, such as archive mailboxes and public folders.

The Management Gap

Two particular topics deserve comment. First, if you’ve used EWS to develop management tools for Exchange, it’s likely that you’re going to find big gaps. Over recent years, the Exchange developers have concentrated on modernizing the Exchange Online management PowerShell module to remove dependencies like WinRM, remove support for basic authentication, and make the most heavily used cmdlets more robust and reliable. There’s no doubt that Exchange PowerShell works better now than it did, but a gap exists in coverage of Exchange management within the Graph APIs. There are many actions in the Exchange admin center that can’t be performed through a Graph request.

You might be able to bridge the functionality gap with PowerShell cmdlets, but if you want to swap EWS code for Graph code, you’ll probably have to wait until Microsoft extends support for management operations to the Graph APIs.

The Backup Conundrum

Microsoft did not design EWS to function as a backup/restore mechanism. Even so, the lack of a formal backup API for Exchange over the years led backup vendors to develop products around EWS. This situation persists today as all backup products currently available for Exchange Server and Exchange Online use EWS (Microsoft’s announced but not yet available Syntex Backup for Exchange Online uses a different API).

Other ISVs use EWS to move data into Exchange Online. Examples include transferring data migrated from a legacy archive system or tenant to tenant migrations.

Discussion of how EWS-based data transfer products can move to a replacement API was notably missing from Microsoft’s announcement. The simple fact is that Microsoft has no publicly-available backup API for Exchange Online. One needs to be created and tested to ensure that it works as least as well as EWS (which has some issues with throttling and robustness) before a transition is possible. There’s no word on such a replacement yet. And Microsoft’s saying nothing either about the possibility that any replacement will be a metered (paid-for) API such as the Teams Export API. Hopefully, Microsoft will ensure that any transition for ISVs away from EWS to replacement APIs will be cost neutral.

Well-Known Gaps Remain Unclosed

The gaps discussed here are not unknown. Customers and Microsoft have debated what’s missing for Exchange in the Graph APIs for several years but little has happened to close the gaps. A certain scepticism exists that Microsoft will suddenly swing into action to produce a bunch of updates to support Exchange Online management, archive mailboxes, and so on. The ball is in Microsoft’s court to prove to the development community and customers that Exchange Online has truly embraced the Graph APIs for all aspects of the product. Let’s hope that they get the work done.

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.

Analyze Traffic for Inbound and Outbound Domains Over the Last Ten Days

Updated 4-June-2025

I’ve covered how to use the Exchange Online message trace facility several times in the past to handle tasks like analyzing email sent to external domains. A reader asked if it’s possible to summarize the top inbound and outbound domains using the same data. The answer is that it’s certainly possible to extract this information, but only for the last ten days because that’s how long Exchange Online keeps message trace data online.

Figure 1 shows the output of the script I wrote to demonstrate the principles of the solution. You can download the script from GitHub and make whatever improvements you like.

Update: The GitHub script now uses Get-MessageTraceV2.

Fetching Message Trace Data

After connecting to Exchange Online, the first task is to retrieve message trace data for analysis. The Get-MessageTrace cmdlet fetches message trace events in pages of up to 5,000 objects. To fetch all available data, the script retrieves information page-by-page until there’s nothing left. This code does the job with a While loop:

[int]$i = 1
$MoreMessages = $True
[array]$Messages = $Null
$StartDate = (Get-Date).AddDays(-10)
$EndDate = (Get-Date).AddDays(1)

Write-Host ("Message trace data will be analyzed between {0} and {1}" -f $StartDate, $EndDate)
While ($MoreMessages -eq $True) {
    Write-Host ("Fetching message trace data to analyze - Page {0}" -f $i)
    [array]$MessagePage = Get-MessageTrace -StartDate $StartDate -EndDate $EndDate -PageSize 1000 -Page $i -Status "Delivered"
    If ($MessagePage)  {
        $i++
        $Messages += $MessagePage
    } Else {
        $MoreMessages = $False
    }
}

Update: Get-MessageTraceV2 uses a different paging mechanism. See the GitHub script for details.

My tenant includes public folders. Public folder mailboxes synchronize hierarchy data between each other to make sure that users can connect and access public folders no matter which public folder mailbox they select. The synchronization messages aren’t very interesting, so the script removes them:

# Remove Exchange Online public folder hierarchy synchronization messages
$Messages = $Messages | Where-Object {$_.Subject -NotLike "*HierarchySync*"}

Creating Data to Analyze

Next, the script fetches the set of accepted domains and extracts the domain names into an array. When the script analyzes messages, it uses the domain names to decide if a message is inbound or outbound based on the sender’s email address:

[array]$Domains = Get-AcceptedDomain | Select-Object -ExpandProperty DomainName

The script then loops through the message trace records to create a list with the sender domain extracted and the direction (inbound or outbound) determined:

$Report = [System.Collections.Generic.List[Object]]::new() 

ForEach ($M in $Messages) {
   $Direction = "Inbound"
   $SenderDomain = $M.SenderAddress.Split("@")[1]
   $RecipientDomain = $M.RecipientAddress.Split("@")[1]
   If ($SenderDomain -in $Domains) {
      $Direction = "Outbound" 
   }
   $ReportLine = [PSCustomObject]@{
     TimeStamp       = $M.Received
     Sender          = $M.SenderAddress
     Recipient       = $M.RecipientAddress
     Subject         = $M.Subject
     Status          = $M.Status
     Direction       = $Direction
     SenderDomain    = $SenderDomain
     RecipientDomain = $RecipientDomain
    }
    $Report.Add($ReportLine)

}

After that, it’s simply a matter of splitting the data into separate arrays containing inbound and outbound messages and piping the results to the Group-Object cmdlet to count the number of times domains appear in the set. We then display the top 10 domains for inbound traffic and the same for outbound traffic, which is what you see in Figure 1. For example, here’s the code to display the top ten outbound domains:

$OutboundMessages | Group-Object RecipientDomain -NoElement | Sort-Object Count -Descending | Select-Object -First 10 | Format-Table Name, Count -AutoSize

Traffic Sent to Groups

One thing to be aware of for inbound traffic is that entries for a message delivered to a Microsoft 365 group or distribution list appears in the message trace data for each recipient. This is logical because Exchange Online needs to track the progress of a message to its final destination. However, it does amplify the number of messages that an external domain appears to send to your tenant.

Use PowerShell to Supplement Standard Reports

The Reports section of the Exchange admin center features a top domain mail flow status report with tabs for inbound and outbound traffic. On the surface, these reports seem like they do the same job. They don’t because these reports are focused on different factors (read the documentation for details). Between what Microsoft provide and what you can create using PowerShell, you’ll have a pretty good idea of what’s happening for email traffic to and from your tenant.

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.

List Exchange Retention Tags Assigned to Folders

A reader wondered how they could create a report of folders in an Exchange Online mailbox to include the retention tag assigned to folders. Retention tags mean both mailbox records management (MRM) retention tags (Exchange legacy retention) and Microsoft 365 retention labels. The Managed Folder Assistant (MFA), the component responsible for retention processing of mailboxes, treats both types equally.

Although Microsoft would like customers to transition from Exchange MRM, the older implementation of retention tags still offers significant value that isn’t available in Microsoft 365. The major gaps in Microsoft 365 retention are the ability to move mailbox items to Exchange archive mailboxes and folder-level retention processing (using default folder tags or personal retention tags). You can transition most retention processing to Microsoft 365, but some elements of MRM retention are still required to use these two features. Microsoft tweaks Exchange MRM to make it behave more like Microsoft 365 retention, but the gap remains.

Getting Exchange Retention Tags from Folder Statistics

Our reader used the Get-ExoMailboxFolderStatistics cmdlet to retrieve details of mailbox folders. The DeletePolicy property is one of the properties fetched for each folder. This property stores the name of the retention tag (folder or personal) assigned to the folder. However, the property is blank if the folder is governed by the default delete and default archive tags defined in the MRM policy assigned to the mailbox. An MRM retention policy can have one default (move to) archive tag and one default delete tag. A policy doesn’t have to include default tags.

Script Steps to Report Exchange Retention Tags

To create a complete picture, I did the following:

Run Get-ExoMailboxFolderStatistics to fetch details of the default mailbox folders (like Inbox and Sent Items) plus user created folders (those likely to be exposed in a client for users to apply retention tags to).

$User = Read-Host "Enter name of user mailbox to examine"
$User = Get-ExoMailbox -Identity $User -ErrorAction SilentlyContinue -Properties RetentionPolicy
If (!($User)) { Write-Host ("Can't find mailbox for {0}" -f $User) ; break }
Write-Host ("Checking mailbox folders for {0}" -f $User.DisplayName)
[array]$MailboxFolders = Get-ExoMailboxFolderStatistics -Identity $User.UserPrincipalName | Where-Object {$_.FolderType -eq 'User created' -or $_.FolderType -eq 'Inbox' `
  -or $_.FolderType -eq 'SentItems' -or $_FolderType -eq 'DeletedItems' -or $_.FolderType -eq 'JunkEMail' -or $_.FolderType -eq 'Contacts'} | Sort-Object Name

Unfortunately, Exchange Online mailboxes contain a heap of system-generated folders that are marked as user created. I remove these from the folder set. This is the lazy way to remove the folders.

$MailboxFolders = $MailboxFolders | Where-Object {$_.Name -ne 'Social Activity Notifications'}
$MailboxFolders = $MailboxFolders | Where-Object {$_.Name -ne 'Clutter'}
$MailboxFolders = $MailboxFolders | Where-Object {$_.Name -ne 'Quick Step Settings'}
$MailboxFolders = $MailboxFolders | Where-Object {$_.Name -ne 'Suggested Contacts'}

The script then finds the MRM retention policy assigned to the mailbox and check if the policy contains any default delete or archive tags.

[array]$Tags = Get-RetentionPolicy $User.RetentionPolicy |Select-Object -ExpandProperty RetentionPolicyTagLinks

[array]$DefaultTags = $Null
ForEach ($Tag in $Tags) {
    If ((Get-RetentionPolicyTag -Identity $Tag | Select-Object -ExpandProperty Type) -eq 'All') {
    $DefaultTags += $Tag }
}

After that, it’s a matter of running down through the folder set to find if the folder has a tag noted. If it does, we report that. If not, we report the default tags. Figure 1 shows the result.

You can download the script from GitHub.

Get Retention Tags for Individual Messages

There’s no obvious way to get the retention tag for individual messages with PowerShell. I asked Glen Scales, an MVP with long experience of developing against Exchange with EWS and the Graph, and he pointed me to a property called Single Value Extended Properties where Exchange stores the retention tag data for messages. Here’s some code to fetch the top 10 messages from the Inbox folder in a mailbox, including the retention data:

$Uri = "https://graph.microsoft.com/v1.0/users('tony.redmond@office365itpros.com')/MailFolders/Inbox/messages/?`$select=ReceivedDateTime,Sender,Subject,IsRead,InternetMessageId,parentFolderId,hasAttachments&`$Top=10&`$expand=SingleValueExtendedProperties(`$filter=(Id%20eq%20'String%20%7B403FC56B-CD30-47C5-86F8-EDE9E35A022B%7D%20Name%20ComplianceTag'))"
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get

The “normal” properties are obvious in the output:

$data.value[0]
Name                           Value
----                           -----
@odata.etag                    W/"CQAAABYAAAA3tTkMTDKYRI6zB9VW59QNAAaLOoml"
singleValueExtendedProperties  {System.Collections.Hashtable}
sender                         {emailAddress}
parentFolderId                 AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNAAuAAAAAAB_7ILpFNx8TrktaK8VYWerAQBe9CuwLc2fTK7W4... 
isRead                         True
id                             AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNABGAAAAAAB_7ILpFNx8TrktaK8VYWerBwBe9CuwLc2fTK7W4... 
receivedDateTime               27/07/2023 19:43:43
hasAttachments                 False
subject                        Delivery estimate update for your Amazon.co.uk order #026-5997568-1550717
internetMessageId              <0102018998e0cc4a-0fef8181-323f-4bb1-b22f-951a6840abe4-000000@eu-west-1.amazonses.com>

The retention tag is in a hash table in Single Value Extended Properties. We can see that the name of the retention tag is “Inbox 7 Year.”

$data.value[0].singleValueExtendedProperties

Name                           Value
----                           -----
value                          Inbox 7 Year
id                             String {403fc56b-cd30-47c5-86f8-ede9e35a022b} Name ComplianceTag

Note: retention tag information is only present when an item has been stamped with a tag. Items under the control of a default retention tag (for deletion or archival) don’t have the retention information in their properties. When Managed Folder Assistant processes mailbox items, it applies the settings from default tags to items when if a more specific tag (folder or personal) is absent.

It is possible to fetch the information for every message in a mailbox and report its retention tag. Given the sheer number of messages in mailboxes, I’m not sure if the exercise would be useful in any way, but at least you know it can be done.

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.

More Details Revealed About Microsoft 365 Backup and Microsoft 365 Archive During Inspire session

A week or so after the launch of Microsoft 365 Backup and Microsoft 365 Archive at their annual Inspire conference (for partners), I took the time to listen to the recording of the session covering the topic delivered at the event. It’s hard to get much detail from a 14-minute session after filtering out all the marketing messages delivered by the avuncular Chris McNulty, but I found some interesting points to ponder.

As a reminder, these products are not yet available. They might be toward the end of 2023. Then again, product dates have an unfortunate habit of slipping, especially when they’re for solutions in a new area. This is doubly true when dealing with solutions targeted at backup and restore and touted as a great solution for ransomware because of their “unprecedented speed and scale.”

McNulty started with some statistics:

• Microsoft 365 users add two billion documents and emails daily. I assume this figure includes Office documents, PDFs, Loops, OneNote notebooks, emails, Teams messages, and everything else that can be stuffed into SharePoint Online, OneDrive for Business, and Exchange Online. In September 2022, Microsoft said that Exchange Online processes 9.2 billion messages daily, 2.4 billion of which are spam. However, it’s unclear if these figures include system messages that are transient and not stored.
• Microsoft 365 user activity consumes 200 petabytes of storage monthly. Much of the data is unstructured. I assume that imports from SharePoint Server and other non-Microsoft 365 sources consume some of this storage. While providing such a large amount of storage is a heavy expense for Microsoft, its existence inside Microsoft 365 creates opportunities. For instance, it is the raw material for Microsoft 365 Copilot.

Microsoft also said that the estimated annual cost of ransomware is $20 billion (2021). They also noted a 74% increase in password attacks in one year, which is yet another good reason for Microsoft 365 tenants to make better use of multi-factor authentication even if attacker tactics like password sprays are less effective due to the removal of basic authentication.

Microsoft 365 Backup

The basic value proposition for Microsoft 365 Backup is simple: the ability to backup and restore data more rapidly than any other backup solution. This is because the data remains within Microsoft 365 and therefore doesn’t have to be copied across an internet connection. Partners have access to the Microsoft APIs for backup, restore, and archiving to allow them to integrate Microsoft 365 in their solutions. In this context, Microsoft will take care of the background processing and the partner looks after the user interface and integration with backup and restore solutions that handle other non-Microsoft workloads to create a single pane for all backup and restore operations.

Of course, keeping backups of your SharePoint Online, OneDrive for Business, and Exchange Online data within the Microsoft trust (security) boundary is a double-edged sword. Keeping all your data eggs in the one Microsoft basket is convenient, enables fast restore, and easy to use because operations are integrated in the Microsoft 365 admin center.

Jacklynn Hiranaka’s demonstration of backup and restore showed how easy it is to configure full backup for a tenant (Figure 1). She made the point that once backup is enabled, it becomes effective immediately. This is likely because Microsoft can utilize techniques like capturing SharePoint changes in the Preservation Hold Library or Exchange changes in Recoverable Items to generate backup items. You can imagine how restores operate like a supercharged version of the SharePoint Restore this library feature or Exchange’s Recover deleted items.

Even more impressive was the assertion that Microsoft 365 Backup can perform parallel restores for SharePoint Online, OneDrive for Business, and Exchange Online to restore information very quickly.

Microsoft 365 Archive

Brad Gussin covered details of Microsoft 365 Archive. This is a SharePoint Online option (Exchange Online has its own archiving). You can already archive Teams and put the associated SharePoint Online sites into a read-only mode. Microsoft 365 Archive puts inactive SharePoint sites into a state where administrators can still manage the sites (to bring them back into an active state) but the data is no longer “hot” (available for immediate user access).

The major advantage gained by moving sites to an archived state is that the storage they consume is no longer charged against the tenant’s SharePoint storage quota. The data is still in SharePoint, but just like the storage consumed by Syntex Repository Services to hold Loop app data, it’s not accessible in the normal way.

Administrators will be able to search for inactive sites and decide which sites to archive. Site owners can protest this action and negotiate with administrators to keep their sites online. Once the final decision to archive, the process to archive sites takes a couple of hours. Actions to archive or reactivate sites are available through the SharePoint Online admin center (Figure 2) or PowerShell. Microsoft hasn’t specified how the PowerShell option will work, but it could be through an updated Set-SPOSite cmdlet or perhaps dedicated cmdlets to archive and reactivate sites. Long-term, Microsoft plans to enable finer granularity by supporting archival at the file level.

Microsoft 365 features such as data loss prevention, data lifecycle management (retention processing), information protection, and search remain in place for archived sites. eDiscovery can find items in archived sites (using the search indexes) and retrieve items using search exports.

A cynic might say that Microsoft created the need for an archive solution by restricting the amount of storage made available to tenants (1 TB plus 10 GB per eligible license) and the way that retention processing consumes quota. The more intelligent versioning planned for document libraries might help restrain storage consumption, but overall it’s still true that SharePoint Online storage is expensive when compared to the abundant storage made available to OneDrive for Business accounts.

No Pricing Available

Microsoft hasn’t revealed how much Microsoft 365 Backup and Microsoft Archive will cost. I’ve been surprised by some recent Microsoft pricing decisions (like the $7/user/month demanded for slightly more intelligent Entra ID access reviews). The good thing is that backup for Microsoft 365 is a competitive market. Microsoft has some strong advantages, but if it goes too far in terms of inflated pricing, customers will vote with their wallets and go elsewhere.

Learn about using SharePoint Online, 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.

Self-Service Group Management for End Users But OWA Option is Broken

By now, your tenant should have received the code for the “My Groups experience” described in message center notification MC522581 (updated on 18 April, 2023). Even though Microsoft predicted that they would complete worldwide deployment by late May, I haven’t invested any time in reviewing what value the new experience delivers. Now that we’ve published Office 365 for IT Pros (2024 edition), I plunged into My Groups to see what it can deliver.

The New My Groups Experience

The new My Groups page (Figure 1) replaces an older page that really didn’t get much attention. Microsoft says that the upgraded and refreshed experience “enables end users to easily manage groups, such as finding groups to join, managing groups they own, and managing existing group memberships.” Of course, self-service management depends on a tenant allowing this activity.

Microsoft’s documentation for My Groups explains the available functionality. Generally, everything works well for Microsoft 365 and security groups as you can update membership and group properties, and even delete the groups. My Groups can’t handle dynamic Microsoft 365 Groups through. This isn’t surprising as the membership of these groups is dictated by queries executed against Azure AD that “normal” users probably couldn’t construct.

The biggest issue with My Groups is its lack of support for distribution lists (groups), or as they’re referred to by My Groups, “Exchange mastered” objects. Distribution lists are valid Azure AD group objects (dynamic distribution lists only exist in Exchange Online) and the methods to update distribution list properties and membership are well known. It’s therefore a mystery why Microsoft should launch a page purporting to enable end-user management of groups when the page is incapable of dealing with a major group type.

The only conclusion I can reach is that the team that developed the My Groups page has an agenda to advance Microsoft 365 groups as the answer for all forms of collaboration. Of course, this is a ridiculous stance, but metrics drive behavior and it’s not unknown for people to do odd things when they’re set a task to advance one option over another. In any case, the lack of support for distribution lists makes the My Groups page a flawed and incomplete implementation that should have been much better.

OWA Distribution Group Management

At the same time, Microsoft has make changes (temporarily) to the ability for users to manage distribution lists through OWA. From a technical perspective, this is understandable because distribution list management depended on components from the old Exchange management center (ECP) that OWA reused. With the demise of the old EAC, those components are less accessible. Now, when you choose the Distribution groups option in OWA settings, you see an unwanted advertisement to use Microsoft 365 groups and a link to a “portal” to manage distribution lists (Figure 2).

The portal (https://outlook.office.com/ecp/MyGroups/PersonalGroups.aspx?showhelp=false) is no more than the old ECP component. Unlike the previous implementation, it takes between ten and fifteen seconds for the ECP code to load. Eventually, the “portal” appears (Figure 3).

On the upside, changes applied through user role assignment policies to restrict users from creating new distribution lists work. On the downside, the code used to update distribution list membership is terrible and doesn’t work. At least, I got tired of waiting to add a new member after sixty seconds of watching the circle of death rotating (Figure 4).

Little Evidence of Joined Up Thinking

It’s obvious that no joined up thinking exists within Microsoft when it comes to delivering functionality to allow end user to edit groups that they own. The old OWA distribution list code worked well but only handle distribution lists, and now it’s broken. The new My Groups page works for Microsoft 365 groups but ignores distribution lists. Is it any wonder why people become exasperated with how Microsoft delivers software, especially when it’s to do with features that have worked for years that fail when engineers step in to enhance their capabilities.

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.

Use Remove-CalendarEvents to Cancel Teams or Regular Meetings Owned By a Specific User

The question arose about how an administrator can cancel Teams meetings scheduled by a user who is currently unavailable. Because cancelling meetings on behalf of a user is not a day-to-day administrative operation, no option is available for this purpose in the Teams admin center or the Microsoft 365 admin center. However, the Remove-CalendarEvents cmdlet in the Exchange Online management module will do the job (the cmdlet is also available for Exchange 2019).

Normally, administrators don’t interfere with meeting arrangements. Those who create meetings (the organizers) take care of scheduling and maintaining meeting settings, whether they own the calendar or are a calendar delegate. Reasons why an administrator might intervene include:

• The organizer is unavailable for a sustained period and the need exists to rearrange the meeting.
• The organizer has left the company.
• The organizer is due to leave the company and part of the offboarding process involves cancellation of all their future meetings.

Mailbox Access Required

In all cases, Remove-CalendarEvents can only work if access is still available to the user’s mailbox. Exchange Online must be able to connect to the mailbox to access the organizer’s calendar to remove events. For this reason, if you plan to cancel a user’s meetings when they leave the company, the correct procedure is:

• Sign in as with an account holding the Exchange administrator or global administrator role.
• Revoke access to their account.
• Run Remove-CalendarEvents to cancel all future meetings in the user’s mailbox where they are the meeting organizer and the meeting has one or more attendees (including resources like meeting rooms). Cancellations cover both normal meetings and online meetings (using Teams or another online provider). Events without attendees (appointments) are left untouched. The mailbox sends meeting cancelations to meeting participants.
• Proceed with the remainder of the account removal process. If holds exist on the mailbox, it becomes inactive. However, you can’t cancel meetings from an inactive mailbox. If you forget to cancel meetings, restore the inactive mailbox, cancel the meetings, and then delete the mailbox again.

Running Remove-CalendarEvents

The Remove-CalendarEvents cmdlet can cancel meetings up to 1825 days (five years) in the future, which should be more than sufficient in most cases. You can perform a test run beforehand to see what meetings it will remove by including the PreviewOnly parameter. For example, this command previews what will happen if the cmdlet removes meetings from the current date up to 365 days in the future:

Remove-CalendarEvents –Identity chris.bishop@office365itpros.com -CancelOrganizedMeetings -QueryStartDate (Get-Date) -QueryWindowInDays 365 -PreviewOnly

Confirm
Are you sure you want to perform this action?
The meeting(s) will be canceled and removed from the calendar. This action cannot be undone.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
The meeting with subject "Glastonbury Meeting" and start date "09/06/2023" has been queued for cancellation.
The meeting with subject "Project X" and start date "09/06/2023" has been queued for cancellation.
The meeting with subject "Project Mercury" and start date "17/06/2023" has been queued for cancellation.
The meeting with subject "Project Botha" and start date "21/06/2023" has been queued for cancellation.
The meeting with subject "Project Botha" and start date "28/06/2023" has been queued for cancellation.

When ready to proceed, remove the PreviewOnly parameter and run the command again. Exchange Online connects to the mailbox, finds the relevant meetings, and cancels them.  Cancellation occurs immediately. Meeting participants receive a cancellation notice as normal (Figure 1).

Graph Delete Event API

If you need a programmatic method to remove calendar events, the Graph includes a Delete Event API. An app with the Calendars.ReadWrite application permission can connect to a mailbox, find relevant events in the calendar, and delete them.

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.

Tweaks to How Exchange Online MRM Processes Microsoft Purview Retention Labels

Microsoft introduced messaging records management (MRM) in Exchange 2007. The first version of MRM was unsuccessful, but the second (in Exchange 2010) remains with us today in both the on-premises and online services. Much as Microsoft would like tenants to move away from Exchange Online MRM and embrace Microsoft Purview data lifecycle management (retention labels and policies), MRM retains some advantages that Purview can’t deliver today. Being able to move items to an online archive mailbox and folder-specific retention tags are the two most notable advantages.

There’s lots to like in Microsoft Purview data lifecycle management. Being able to use the same retention labels and policies for multiple workloads is a good thing. Advanced features like adaptive scopes (to identify sets of accounts or sites as target locations for policies) and manual disposition (invoke special processing when an item reaches the end of its retention period) are too. Being able to meld MRM and Microsoft 365 retention policies and labels in a retention strategy gives tenants a way to keep the advantages of MRM for targeted processing of mailboxes while moving most retention activity to Microsoft Purview. Maybe that’s why Microsoft surfaces Exchange MRM (albeit with a legacy tag) in the Compliance portal (Figure 1).

All of which brings me to message center notification MC567472 (2 Jun 2023), titled “Enhancing inherited and auto-applied retention label behavior in Exchange Online.” The post describes internal changes to how Exchange Online deals with labeled items when moving them to the Deleted Items folder (the change only applies to the Deleted Items folder). Microsoft plans to roll-out the change at the end of June and complete worldwide deployment by the end of August 2023.

Current Exchange Online MRM Behavior for Deleted Items

Until now, if a folder tag for Deleted Items is in the mailbox retention policy applied to a mailbox, Exchange Online applies that folder tag to items moved to Deleted Items. Hard deletions (SHIFT+DEL) move items direct to Recoverable Items and bypass Deleted Items, so the existence of a folder tag for Deleted Items doesn’t matter. The exception is when a user explicitly assigns an Exchange retention tag or a Purview retention label to an item. Manual assignments always take precedence over automatic assignments or inheritance from a folder tag. Items with manually-assigned tags are untouched when they move to Deleted Items.

New Exchange Online MRM Behavior for Deleted Items

The changes are subtle and give more priority to Purview labels, especially those applied by auto-label policies.

First, if an item has a Purview label which retains content (it has a retention setting for a set period, like 730 days), the Purview label remains in place regardless of what method (user or automatic process) applied the label. This happened before for manually-applied labels. The change is for labels applied by policy and ensures the retention of items for their full retention period.

For items with labels that don’t retain content but enforce a set action (like delete the item) when the label’s retention period lapses, processing follows these rules:

• Items with a Purview label applied by an auto-label policy ignore the default folder tag applied to the Deleted Items folder. This avoids the chance that Exchange Online keeps items which an organization identifies for retention through an auto-label policy for their full retention period.
• Items with an Exchange Online retention tag or Purview label inherited from the folder they move from to go to Deleted Items retain their label if the Deleted Items folder does not have a default tag. For instance, if the Inbox has a default folder tag with a retention period of 365 days, that tag stays with items moved from the Inbox to Deleted Items. When the Managed Folder Assistant (MFA) processes the items, it complies with the 365-day retention period and will not remove the items until this period lapses.
• If the Deleted Items folder has a default folder tag, Exchange Online compares the retention periods for the retention labels or tags applied to items against the retention period defined in the default folder tag and acts based on the shortest deletion period.

Will Users Notice the New Retention Behavior?

I doubt that the average (or even not-so-average) end user will notice the change. Few people understand the complexities of Exchange MRM and possibly fewer the full spectrum of Microsoft Purview data lifecycle management. But it’s good to have consistent behavior and it seems like the tweaks Microsoft will introduce add some consistency to the mix of MRM and Purview.

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.

Run the Edge, Chrome or Firefox Browsers on Windows or Get OWA Lite

On June 2, 2023, Microsoft published an “initial communication” to inform Microsoft 365 tenants that they plan to redirect OWA connections created with unsupported browsers to use OWA Lite instead of the expected OWA Premium client. Microsoft says that they’re making the change to align OWA with the requirements for minimum browser support for other browser-based Microsoft 365 apps introduced earlier this year (MC518729, updated February 27, 2023). The changes announced in MC518729 affect apps like the Teams browser client and are due to take effect in July 2023.

OWA Lite

OWA Lite is a version of the browser client created for the on-premises versions of Exchange Server that still looks like the kind of email client you’d see around the year 2000. The client hasn’t changed much since its creation and is much simpler than OWA Premium. Although you can manage a mailbox with OWA Lite, don’t expect support for functionality like access to shared mailboxes.

In its place, OWA Lite can be useful. For instance, over a low-bandwidth connection, OWA Lite (Figure 1) consumes less network resources than the premium version does. I’ve even used the OWA Lite client on a Linux-based TV to create and send a few messages.

Another reason to use OWA Lite is when people have accessibility needs. The premium version of OWA is in an ever-changing state as Microsoft adds new features and tweaks the UI to prepare for the introduction of the new Outlook for Windows client (code name Monarch), which is based on OWA Premium. I’ve called Monarch a slightly prettier version of OWA, but because its UI is evolving, using the client can be hard for those who depend on client UIs being predictable.

Accessing OWA Lite

There used to be an option in OWA settings to select OWA Lite for a mailbox that seems to have disappeared. To test OWA Lite, connect to Exchange Online with the URL https://outlook.office.com/owa/?layout=light. To revert and return to the Premium client, use https://outlook.office.com/owa/?layout=premium.

Supported Browsers

Supported browsers for OWA Premium with Exchange Online include Microsoft Edge, Chrome, or Mozilla Firefox on Windows 11 and 10. For macOS, Safari is on the list. Curiously, there’s no mention of the Brave browser, which is based on Chromium like Edge and Chrome. It might be that some of the bits that Brave removes from the Chromium engine create some difficulties for OWA. I have never had any issues using Brave with OWA premium, but that doesn’t mean that I’ve never encountered some lurking problems with the browser. Opera is another common browser missing from the supported list.

Restriction Starts in September 2023

Microsoft says that they plan to roll out the change to targeted release tenants in September 2023 and complete the worldwide deployment in November 2023. After the code update to impose the restriction arrives in a tenant, users who attempt to use an unsupported browser will get OWA Lite.

Forcing people to use OWA Lite and being unable to switch to OWA Premium with a user’s preferred browser is likely to be the source of disruption, annoyance, and help desk calls if users do not receive warning to switch to a supported browser. Microsoft minimizes the difficulty of the situation by bluntly saying that tenants should check browsers in use and arrange for upgrades to make sure that users “can utilize the full set of features from Outlook on the web.” Just another thing to add to the to-do lists of tenant administrators.

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.

Mailbox Audit Events Problematic for Multi-Geo Audit Searches

At first glance, the title given to MC550039 (3 May 2023) is confusing. What exactly does “Configuration Change: Search-MailboxAuditLog cmdlet, multi-geo scenarios” mean?

Microsoft attempts to explain that in multi-geo tenants, a problem might arise when running the Search-MailboxAuditLog cmdlet to search mailbox audit records, leading to the message “An error occurred while trying to access the audit log.” The reason why this happens is that the administrator running the search uses a mailbox in a different region.

Remember that Exchange stores mailbox audit records in the Audits folder of Recoverable Items in user mailboxes. In a multi-geo organization, user mailbox can be in different regions. To make sure that searches work, administrators must “anchor” themselves in the target region by specifying a mailbox in the region when they run Connect-ExchangeOnline to connect PowerShell to Exchange Online. It’s a way of setting a scope for the mailbox audit log search.

The Unified Audit Log is a Better Search Target

Exchange Online generates mailbox audit events for mailboxes licensed with Exchange Online Plan 1 and 2. Enterprises running multi-geo organizations are likely to have Office 365 E3 or better licenses and therefore can use the unified audit log to gather data from multiple workloads in a single searchable store. In Office 365 E3 environments, administrators must enable mailboxes for auditing before mailbox audit events flow to the unified audit log. From March 2023, admin audit events from all regional locations end up in the unified audit log and can be searched there.

For instance, this command finds mailbox audit events recording the use of the Send As feature for a shared mailbox:

Search-MailboxAuditLog -Identity Customer.Communictions -LogonTypes Delegate -StartDate ((Get-Date).AddDays(-90)) -EndDate ((Get-Date).AddDays(+1)) -ShowDetails | Where-Object {$_.Operation -eq "SendAs"} | Select LogonUserDisplayName, LastAccessed

LogonUserDisplayName LastAccessed
-------------------- ------------
Tony Redmond         03/05/2023 20:29:39
Tony Redmond         03/05/2023 19:42:39
Tony Redmond         03/05/2023 19:13:41
Tony Redmond         20/04/2023 23:48:11
Tony Redmond         20/04/2023 17:44:10
Tony Redmond         20/04/2023 14:08:41

Within 15 minutes or so of creation, Exchange Online sends the mailbox audit events to the unified audit log. The events are immediately searchable through the Purview compliance portal (Figure 1) and PowerShell.

But, as MC550039 points out, unless you’re signed into an account in a satellite region, you won’t be able to see mailbox audit events from that region. Exchange Online does not transmit mailbox audit events from satellite regions to the unified audit log.

Admin Events

Exchange Online also generates admin audit events and transmits these events to the unified audit log. This process works for multi-geo environments, meaning that you can search for admin events using PowerShell or the audit search in the Microsoft Purview compliance portal.

Passing the Message

Microsoft hasn’t invested in Exchange mailbox audit logging for several years. Their focus is on the unified audit log. This is natural because the unified audit log offers better search options (even if the modern audit search GUI in the Purview compliance portal is very slow to retrieve audit data).

In general, it’s always best to use Search-UnifiedAuditLog or the Microsoft Purview compliance portal to search audit data. The exception, as appears to be in this case, is when searching for mailbox audit data from a satellite region, where you’re forced to run the Search-MailboxAuditLog cmdlet after connecting to an appropriate mailbox. It would be nice if Microsoft make it possible for mailbox audit events to flow from satellite regions to the unified audit log. Unified, after all, is the important word.

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.

Extra Year to Give Tenants Time to Overcome Technical Limitations that Prevent Migration

Without much fanfare, the Exchange Online team decided to give tenants that use client access rules an extra year to make the transition to Azure AD conditional access policies. The original deprecation date of September 2023 is now September 2024. The kicker in this statement is that only rules that cannot be migrated to conditional access policies because of a “technical limitation” can continue working for the extra year.

First announced at the Microsoft Ignite 2017 conference, client access rules are only available in Exchange Online and exist to control connections coming into Exchange Online. You can do things like block POP3 and IMAP4 connections or restrict access to these protocols from specific IP addresses.

Client access rules are a solution created by Exchange Online for an environment that was very different to today. In 2017, customers wanted help to control inbound connections to Exchange Online. Azure AD conditional access policies didn’t have the feature set that’s available now and Exchange Online still supported basic authentication across all its connectivity protocols.

The Current State of Microsoft 365 Connection Management

Moving forward to today, Microsoft has largely eliminated basic authentication from Exchange Online to cut off techniques like password sprays that attackers heavily depended on to retrieve user account credentials. Attackers still try, but attempts to use basic authentication to check username/password combinations fail at the first hurdle. Apart from keeping access to SMTP AUTH, there’s no further need for authentication policies.

Deprecating client access rules could be construed as another side effect of modern authentication becoming the norm in Exchange Online. But the more important factor is that Microsoft 365 favors features that function across the entire ecosystem instead of being tied to a single workload. Azure AD is the directory of record and conditional access policies are how Azure AD controls inbound connections. Dropping client access rules (specific to Exchange Online) to embrace conditional access policies is evidence of that trend. We see the same in the compliance and information protection areas where Microsoft 365 policies take prime position.

Microsoft is pouring engineering effort into Azure AD conditional access policies. In the last year alone, Microsoft has added features such as:

• Granular access for external user types.
• App filters.
• Authentication strengths.

Conditional access policies are closely associated with multi-factor authentication and are often configured to ensure that inbound user connections use MFA, especially for administrator accounts.

Migration Away from Workload-Specific Implementations Can be Problematic

Moving from a workload-specific implementation to a platform-wide implementation can be problematic. It’s likely that the workload-specific code covers narrower use cases that only occur within a workload. For example, Exchange Online mailbox retention policies can process items at a folder level and move items to the online archive when their retention period expires. By comparison, Microsoft 365 retention polices process mailboxes as a single unit and don’t go to folder level and can only delete or keep items instead of being able to move them to the archive. Then again, because Microsoft is actively developing Microsoft 365 retention policies, they benefit from recent innovations like adaptive scopes and disposition reviews, neither of which are available for Exchange mailbox retention policies.

In the case of client access rules, Microsoft acknowledges that they “have encountered a few scenarios where it’s not possible to migrate current rules” and say that they will allow the ongoing use of client access rules “until we can support them” (presumably the scenarios that migration is not currently possible).

Microsoft doesn’t describe what scenarios are problematic. They also don’t say how customers can discover if their client access rules fall into the category of those that Microsoft consider to have a technical limitation that prevents migration. Microsoft plans to disable client access rules that they consider can be migrated to conditional access policies in September 2023. Only rules that receive Microsoft approval can continue running until September 2024, at which point the curtain descends for all client access rules (Figure 1).

Apart from not documenting the technical limitations that get in the way of migration, Microsoft also doesn’t say how customers receive approval for the one-year extension for client access rules. The blog says that customers should “open a support ticket so we can investigate and understand your needs,” but doesn’t explain how this process results in a rule being allowed to continue running past September 2023.

The Filtering Issue

Browsing the documentation for client access rules, the obvious issue appears to be in the areas of filtering. Like in other areas (like dynamic distribution lists), Exchange Online supports recipient filters for client access rules in a different manner than operated for conditional access policies. You can assign conditional access policies to specific users and groups (including dynamic Microsoft 365 groups), but that’s not quite the same as using a recipient filter. I’m sure that I am missing something else, but recipient filtering seems like the big obstacle for migration.

I strongly support moving away from client access rules to embrace more secure implementations like conditional access policies that operate across the complete Microsoft 365 ecosystem. Microsoft throws continuous access evaluation (CAE) into the pot. Although CAE is a very good innovation to revoke access from accounts immediately important events like password changes occur, the issue here is all about migration.

Client Access Rules Migration Might Need Updates to Conditional Access Policies

If you’re using client access rules, it’s time to review the state of the migration.

• Remove client access rules that are no longer necessary.
• Migrate the remaining rules to conditional access policies.
• If any rules cannot be migrated, contact Microsoft Support to discover if a technical limitation exists to prevent migration. If it does, the rules can continue working until September 2024. If not, Microsoft Support should be able to tell you how to migrate to conditional access policies before September 2023.

Microsoft doesn’t say how they will address the technical limitations that allow some client access rules to remain operational until September 2024. This might be because the Exchange Online team is waiting for their Azure AD colleagues to implement some features in conditional access policies. At least, I hope that’s what’s happening.

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.

Clarifying Why Some Unsupported Exchange Servers Need an Upgrade

Yesterday, I was walking the dog and listening to the March 29 edition of the Windows Weekly podcast featuring Paul Thurrott and Richard Campbell. Typically, I listen to pass time without needing to engage my brain too highly, but then Richard mentioned that I could deliver a good “half-hour of rant” about Microsoft’s grand plan to force customers to upgrade unsupported Exchange servers.

I can’t deny that I have been known to rant in the past, maybe even when hosted by Richard on his RunAs Radio talk show, but that’s when I am pointed to a microphone and Richard goads me into action. In this case, I think it might be a reflection that people are struggling to understand what’s going on. Certainly, a fair degree of miscomprehension is apparent in some of the comments posted to Microsoft’s announcement. Let me try to summarize what’s happening without ranting even a little bit.

What Microsoft is Doing with Unsupported Exchange Servers

First, Microsoft is not targeting every on-premises Exchange server. You can absolutely continue to run on-premises Exchange if that’s the best option for your organization. However, if you have a hybrid organization, the rules of the game are changing to force you to use supported software to send email from the on-premises side.

Initially, Microsoft is targeting on-premises Exchange servers with two characteristics:

• The servers run unsupported software. Any Exchange 2007 or Exchange 2010 server is now unsupported. Exchange 2013 servers become unsupported on April 11, 2023.
• The servers send email to Exchange Online over an inbound connector of the on-premises type. In other words, the problem servers act as the routing point of contact with Exchange Online – Microsoft knows about the servers because they’re part of a hybrid organization connected to Exchange Online. These servers are also connected to the internet (otherwise they can’t route email to Exchange Online) and are therefore vulnerable to attack, and because they route messages direct to Exchange Online, they can be the vector used by attackers to inject malware into Exchange Online.

Servers that do not handle the transmission of email to Exchange Online via an inbound connector are unaffected. Anything that happens inside the privacy of an on-premises organization is up its administrators. For now, you could even connect in some Exchange 5.5 servers running a Wolfpack cluster if you wanted – if the server handling email to Exchange Online runs supported software.

Microsoft says that “The enforcement system will eventually apply to all versions of Exchange Server and all email coming into Exchange Online.” This seems a little harsh but it is intended to make sure that email flowing into Exchange Online is safe. The way things seem likely to pan out is that Microsoft will gradually bring Exchange 2010, Exchange 2013, Exchange 2016, and Exchange 2019 into the program. After they’ve made sure that only Exchange servers running supported software can communicate with Exchange Online, Microsoft will extend the requirement to all Exchange servers that communicate with Exchange Online using any means. In other words, even servers that communicate with Exchange Online via an intermediary are subject to throttling and then blocking.

The final stage is to protect Exchange Online against any server that sends email to Exchange Online over SMTP. I’m not quite sure how Microsoft plans to validate that remote SMTP servers are up to scratch, but that’s where they seem to be heading. This part of the plan is likely more of a long-term strategy than a well-defined plan. Practical issues such as identifying what is and is not a supported version of any particular SMTP server that communicates with Exchange Online need to be resolved.

The end game is to ensure that Exchange Online is not exposed to malware or other issues that come in from external servers (outside Exchange Online). In many respects, this is no different to what happens today when Exchange Online Protection blocks spam and malware. Judgement is passed at a server level rather than individual messages.

Initial Focus on Exchange 2007

The initial focus is on Exchange 2007 servers (Figure 1). As you might expect, this is a very small subset of servers in hybrid organizations. I’ve heard that there might be a couple of thousand servers in this category worldwide. Exchange 2007 reached end of life six years ago (April 2017). It has not received any support or security patches since.

These servers are vulnerable to a wide range of known threats. They should not be in active use. The potential exists that an attacker could compromise these servers and use this route to attempt to penetrate Exchange Online. This is the crux of the matter: Exchange Online will not accept email from organizations that transmit email to Exchange Online using obsolete and vulnerable Exchange servers.

Blocking of Unsupported Exchange Servers Starts in July

Microsoft will use a three-phase report-throttle-block process to “encourage” customers to upgrade the problem servers. Details are in this article. Microsoft will start to throttle traffic from Exchange 2007 servers in June and move to block traffic from those servers in July. It is entirely the responsibility of tenant administrators to respond before a block descends on their on-premises email to Exchange Online. Three options are available:

• Upgrade the problem server(s) to a supported version of Exchange Server (2016 or later, patched with the latest cumulative and security updates). This might involve replacement hardware. The load imposed by mail routing to Exchange Online is not likely to stress modern hardware, so a low-end server will suffice.
• Move the on-premises side of the inbound connector to a server running a supported version of Exchange Server.
• Direct email from Exchange on-premises to Exchange Online via a third-party mail gateway. (note: if the third-party gateway uses unsupported Exchange servers, its traffic is liable to be blocked).

In any of these cases, it makes absolutely no sense to keep vulnerable Exchange servers in production. It’s time to let Exchange 2007 die. Software designed twenty years ago simply cannot cope with the threat that exists today.

Microsoft is clear that Exchange 2007 is only the start. After they finish dealing with Exchange 2007, they will move on to Exchange 2010 and then Exchange 2013 servers that send email to Exchange Online over inbound connectors. It’s probable that the program will extend to Exchange 2016 and Exchange 2019 servers (that are not kept updated) as they age, and maybe even encompass third-party servers with known problem configurations.

The point is that the project is all about closing a potential attack vector into Microsoft 365. Just like stopping people using basic authentication to connect to Exchange Online (now almost done), this is the right thing to do.

Nothing to do with Consumer Email

Some reaction to the announcement focuses on spam generated from Microsoft cloud accounts. I believe this refers to consumer email accounts. At least one incident occurred where Exchange Online was hijacked and used for spam, but most spam does come from consumer accounts. Microsoft could tighten the use of consumer (Outlook.com) accounts for email, but that’s got nothing to do with the server initiative.

ISVs and Inbound Connectors

Speaking of inbound connectors, in February 2023 Microsoft disabled the ability of new Exchange Online tenants to activate inbound connectors of the on-premises type. This caused a bunch of problems for ISVs that depend on being able to route email for processing to a service that they run before sending messages back to Exchange Online for final delivery. The application of email signatures by a company like Code Two Software is a good example.

Microsoft has now issued guidance about how to handle the issue. Essentially, they have whitelisted some ISVs to reduce the friction caused by the restriction. In other cases, you’ll need to request activation through Microsoft support. According to the ISVs I have spoken with, the new scheme is acceptable. Let’s hope that this proves to be the case in practice.

Microsoft will hold an Ask Me Anything event on May 10 at 9AM PST on the topic of the Exchange Online transport enforcement system. For more details, check out this page. If you have any further questions, that’s the place to bring them.

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.

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.

Are Guest Accounts Better Than Mail Contacts?

During an online discussion following publication of my article about how to purge guest accounts with unredeemed invitations from Entra ID, Microsoft’s Jef Kazimer said that he sees many Microsoft 365 organizations using guest accounts instead of mail contacts because guest accounts have better lifecycle management, even if the guests never sign in.

That idea got me thinking. Exchange Online is the largest Microsoft 365 workload and some organizations create many thousands of mail contacts for different reasons. For instance, they might have contacts for people in partner organizations so that users can easily find those contacts in the Global Address List (GAL). Mail contacts also exist in Exchange Server and many of the contacts now in Exchange Online originated. Hybrid organizations can synchronize on-premises contacts to Entra ID, but the management of those objects must be done on-premises.

Understanding Mail Contacts

Before comparing mail contacts with guest accounts, we need to understand what a mail contact is. Mail contact objects exist in both the Exchange directory (EXODS) and Entra ID. For example, to create a mail contact, you run the New-MailContact cmdlet:

New-MailContact -Name Jef.Kazimer -DisplayName "Jef Kazimer" -ExternalEmailAddress "Jef.Kazimer@contoso.com" -FirstName "Jef" -LastName "Kazimer"

This action creates a contact object in both Exchange Online and Entra ID. The Exchange object is what people think of when they think about a mail contact. The Entra ID object exists to hold properties unrelated to email processing. Because it uses mail contacts as addressable email recipients, all Exchange Online really cares about is the email address. Once an object has an email address, Exchange can route messages to it and allow the object to participate in distribution lists. The Get-MailContact cmdlet confirms the details of the new contact object:

Get-MailContact -Identity Jef.Kazimer | Format-Table DisplayName, ExternalEmailAddress

DisplayName ExternalEmailAddress
----------- --------------------
Jef Kazimer SMTP:Jef.Kazimer@contoso.com

The external directory object identifier stored in the mail contact points to the Entra ID object, which we can retrieve using the Get-MgContact cmdlet from the Microsoft Graph PowerShell SDK:

Get-MgContact -OrgContactId (Get-MailContact -Identity Jef.Kazimer).ExternalDirectoryObjectId | Format-Table displayName, proxyAddresses

DisplayName ProxyAddresses
----------- --------------
Jef Kazimer {SMTP:Jef.Kazimer@contoso.com}

The mail contact is a sparse object so far. To populate the other properties that you might want users to see in the GAL (Figure 1), you must run the Set-Contact cmdlet to update the Entra ID object:

Set-Contact -Identity Jef.Kazimer -StreetAddress "14, Preston Villas" -City "Bellevue" -StateorProvince "Washington" -PostalCode "98004" -Phone "+1 425-214-765" -MobilePhone "+1 425-214-705" -Pager $Null -HomePhone "+1 425-270-765" -Company "Contoso" -Title "Azure AD Guru" -Department "Information Technology" -Fax "+1 425-214-761" -Initials "JK" -Notes "Distinguished Person" -Office "Liberty Square" -CountryOrRegion "United States"

The Get-MgContact cmdlet reports the newly-populated properties as does the Get-ExoRecipient cmdlet. There are some exceptions and caveats:

• Remember to include the PropertySet All parameter to force Get-ExoRecipient to retrieve the full set of properties.
• Get-ExoRecipient doesn’t retrieve the street address because it’s not included in the GAL.
• Get-MgContact uses compound properties to hold some information. For instance, to see the elements of a contact’s address, you must expand the properties stored in the Addresses property:

Get-MgContact -OrgContactId (Get-MailContact -Identity Jef.Kazimer).ExternalDirectoryObjectId | Select-Object -ExpandProperty Addresses


City     CountryOrRegion OfficeLocation PostalCode State      Street
----     --------------- -------------- ---------- -----      ------
Bellevue United States   Liberty Square 98004      Washington 14, Preston Villas

Managing Mail Contacts

A Set-MailContact cmdlet is available to update properties of the Exchange objects, including the set of custom attributes available for all mail-enabled objects. The Set-Contact cmdlet updates the information held in Entra ID contact objects such as the address data shown above.

When administrators manage mail contacts through the Microsoft 365 admin center or Exchange admin center, they can work with both Exchange Online and Entra ID object properties. The GUI hides the fact that the settings presented to the administrator come from two directories, much like it disguises the interaction between Entra ID and Exchange when managing mailbox-enabled user accounts.

Guest Accounts and Guest Mail Users

Now that we understand mail contacts, let’s discuss the relationship between Exchange Online and guest accounts. Following the creation of a guest account, a background process creates a special type of mail user object with a RecipientTypeDetails setting of GuestMailUser based on the properties of the guest account. The mail user object allows:

• Guest members of Outlook groups to participate in group conversations via email.
• Mail routing to guest accounts.
• Guest accounts to appear in the GAL and other Exchange address lists.

Guest mail user objects exist in the Exchange directory until the removal of their linked guest accounts from Entra ID. Although you can view guest mail user objects through the Exchange admin center, the GUI won’t allow you to update their properties.Changes must be made to the guest account using the Entra admin center or with a Graph API (including the Microsoft Graph PowerShell SDK cmdlets). You can update the Exchange-specific properties with the Set-MailUser cmdlet.

To see the set of guest mail user objects, run the Get-ExoRecipient cmdlet:

Get-ExoRecipient -RecipientTypeDetails GuestMailUser | Format-Table DisplayName, PrimarySmtpAddress, HiddenFromAddressListsEnabled

The last property is True (the default) if the guest account isn’t visible to Exchange address lists. Run the Set-MailUser cmdlet to update HiddenFromAddressListsEnabled to True to expose the object. Here’s an example:

Set-MailUser -Identity warren.gatland@o365maestro.onmicrosoft.com -HiddenFromAddressListsEnabled $False

Note that it takes at least a day before newly exposed objects show up in the offline address look (OAB).

Adding Guest Mail Users to Distribution Lists

Because the guest mail users are routable objects, they can be added to distribution lists. This example spells things out, but it’s possible to add a guest mail user to a distribution list by passing its display name or email address without going to the bother of fetching the object with Get-MailUser.

$GuestMailUser = Get-MailUser Get-MailUser -Filter {DisplayName -eq "Warren Gatland" -and RecipientTypeDetails -eq "GuestMailUser"}
Add-DistributionGroupMember -Identity "o365maestro Contacts" -Member $GuestMailUser.Name

Move to Guest Accounts or Stay with Mail Contacts

Getting back to the original point, Jef says that guest accounts have better lifecycle management. In other words, if an organization invests in creating guest accounts instead of mail contacts, they’ll benefit from the work Microsoft does to improve how Entra ID manages external identities.

There’s some truth here. A guest account supports more properties, including custom security attributes and support dynamic Entra ID Groups and dynamic Entra ID administrative units. They’re a Microsoft 365 entity rather than being restricted to just Exchange Online. Entra ID development for external identities, including guest accounts, is active whereas I suspect the development effort for Exchange mail contacts entered an “only fix bugs” maintenance stage years ago. On the other hand, mail contacts are simple and effective and work across hybrid Exchange organizations.

If you’re a cloud-only organization, the choice exists to use either. If you decide to use guest accounts, the existence of guest mail user objects smoothen the transition and make sure that address lists, distribution lists, an email routing continue working. guest accounts are a better long-term bet, but that doesn’t mean that anyone should switch anytime soon.

Learn more about how the Microsoft 365 applications like Exchange Online and Entra ID 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.

Use Test-Message to Validate Exchange Online Rules Processing Against Email

Announced in Microsoft 365 message center notification MC503297 (26 January 2023, roadmap item 100494), the Exchange Online Test-Message cmdlet is now generally available. The purpose of the cmdlet is very simple: it tests the path of a message through the rules applied by the Exchange Online transport service to reveal what actions those rules take. The intention is to help tenant administrators understand why a rule doesn’t function as expected without having to ask Microsoft support for assistance.

The set of tested rules include:

• Exchange Online transport rules (ETRs, also known as mail flow rules). Up to 300 ETRs can exist in an Exchange Online organization to do anything from automatically copying messages sent to a certain domain to applying disclaimers to outbound messages (here’s an example of using an ETR to apply a special disclaimer for calendar meeting notifications.
• Rules created to enforce actions from Microsoft 365 DLP policies. For example, to stop people sharing confidential information with external recipients.
• Rules created to apply Microsoft Purview retention or sensitivity labels.

Over time, my small tenant has accumulated 25 different transport rules plus a set of DLP policies and some auto-label policies. The permutations and combinations involved in rule processing within the transport service can become very complex indeed. ETRs have a priority order to determine how the transport service runs the rules. A rule can force processing to stop if necessary. DLP policies run after ETRs, and auto-labeling then kicks in if a message is allowed to proceed by ETRs and DLP.

Test-Message Examples

Here’s a simple example of the Test-Message cmdlet in action:

Test-Message -Sender Lotte.Vetler@office365itpros.com -Recipients Flayosc@outlook.com -SendReportTo Jim.Flynn@office365itpros.com -TransportRules -UnifiedDlpRules

This kind of test runs rules against a sample message. It can only check the message sender and recipients, so apart from cycling through all the available rules, it’s not a very extensive test.

A slightly more complicated example uses a test message that I created with Outlook and saved as a message file. Using a test message makes sure that rules run against precisely the kind of traffic that you expect the rule to detect and process. For instance, you might want to include some specific keywords in the message subject or body text, or an attachment of a certain type.

To pass the message to Test-Message, it must first be encoded and stored in a variable, which is then specified in the MessageFileData parameter.

$EncodedText = ([System.IO.File]::ReadAllBytes('c:\temp\TestMessage.msg'))

Test-Message -MessageFileData  $EncodedText -Sender Lotte.Vetler@office365itpros.com -Recipients Flayosc@outlook.com -SendReportTo Jim.Flynn@office365itpros.com -TransportRules -UnifiedDlpRules

Server                                  MessageId
------                                  ---------
PAXPR04MB8095.EURPRD04.PROD.OUTLOOK.COM 626b8a86-c262-4457-911b-641a027989d7@DB9PR04MB8445.eurprd04.prod.outlook.com

The server information reported by the cmdlet is the Exchange Online mailbox server where the transport rules run. Given the massive pool of Exchange Online servers, it’s likely that Test-Message will use a different server each time it runs.

Test-Message Output

The output is in messages delivered to the address specified in the SendReportTo parameter for each type of rule processed by the test. In my case, the test generated three messages (DLP, auto-label, and ETR). Figure 1 shows the results for the ETR test. We can see that a match occurred for the Office 365 Message Encryption for selected external domains rule, which executed two actions to apply rights management protection to the message with custom branding. After executing the two actions, the transport service stopped processing further rules because the rule settings forced an exit.

Steps to Follow for Rule Creation

Nice as it is to have a cmdlet to help test rules processing, it won’t replace the simple rules that experienced administrators follow when setting up new ETRs or DLP policies.

• Know what your rule should do (the actions).
• Know what conditions the rule needs to detect before it runs.
• Know what exceptions (if any) exist.
• Start with a simple rule and build complexity gradually.
• Always ask if your rule is likely to interfere with another rule before enabling it. You might be able to make a small adjustment to an existing rule to do what you want instead of creating a brand-new rule.

The last point is the most important.

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.

Restriction forces Customers with New Tenants to Ask Microsoft Support to Enable Inbound Connectors

In an unannounced change, Microsoft recently disabled the ability of new Exchange Online tenants to activate newly-created inbound connectors. The text in the inbound connector FAQ (refreshed on 15 February) says:

“When you create an Inbound connector of OnPremises type manually, you may see the warning message Inbound connector for this service offering is created in a disabled state. Contact Support to enable it.”

The FAQ goes on to say that the customer must contact Microsoft support and provide a business justification for why their tenant needs to use an inbound connector. Microsoft attempts to reassure everyone by saying “Legitimate usage is approved, and the connector is enabled by our service engineers.” I’m sure that’s true, if you manage to speak to a level 1 support engineer who knows about why Microsoft disabled inbound connectors and understand what to do to release the block.

The EX505293 Incident

The problem with creating and updating connectors surfaced in incident EX505293 (January 27). Microsoft determined the root cause to be “A recent change to the service introduced a regression that may have prevented some admins from creating or modifying Exchange email transport connectors” and applied a fix that was operational by February 6, 2023. Because the Exchange Hybrid Connection Wizard (HCW) creates connectors, it was affected by the problem.

Microsoft doesn’t describe the precise nature of the fix in EX505293, but it seems like it allows tenants to create new connectors (in a disabled state). Moreover, the text in EX505293 indicates that the restriction applies only to tenants created from 2023 onwards. Microsoft’s FAQ doesn’t mention why they’ve clamped down on newly-created tenants, but it’s possible that it’s easier for an attacker to spin up a new tenant and create connectors to do bad things than to break in and compromise an existing tenant to take over its connectors.

Good Reasons Exist to Disable Inbound Connectors

Good reasons exist for why Microsoft should block inbound connectors. First, an inbound connector is not required for normal mail flow. The usual reason is that an organization wants to use a third-party solution to process their email. For instance, you might want to route messages through a third-party service to apply corporate email signatures before sending the messages to their final destination. Many of the specialized email signature ISVs like Code Two Software use inbound connectors to bring traffic back into an organization after inserting appropriate email signatures into messages.

Second, attackers who compromise a tenant might create connectors to route email through their services in an attempt to either use the tenant to send spam or to inject malware into user mailboxes (see this report about an attack on a Microsoft 365 tenant). Placing newly-created connectors into an inactive state until the owning tenant justifies the use of the connector closes off this attack vector.

I don’t know why Microsoft decided to restrict newly-created connectors. My gut feel is that something happened to cause immediate action, such as emerging evidence of a new attack technique involving connectors. We won’t know and Microsoft won’t say. Such is the nature of the security war between attackers and defenders playing out every day across IT infrastructures.

The Effect on ISVs

Even if closing off an attack vector stops attackers dead, doing so without due consideration of legitimate usage by ISVs is bad practice, especially when Microsoft didn’t warn ISVs or announce the change in a post in the EHLO blog, post a notification to the Microsoft 365 message center, or publish plans as a Microsoft 365 roadmap item. The change appeared without warning, perhaps to surprise potential attackers. It certainly surprised the affected ISVs.

Instead of being able to install their products and configure everything needed to make their software work, ISVs are now forced to perform a partial installation and ask their customers to contact Microsoft support to enable the disabled inbound connector. Microsoft has left customer-facing ISVs in an invidious position.

Not Good Business

I don’t criticize anything Microsoft does to protect Exchange Online against attack. Too many people depend on Exchange Online to risk potential compromise of user mailboxes. My criticism is entirely focused on the total lack of communication since Microsoft introduced the change referred to in EX505293 and fixed in early February. Operating in a vacuum is good for no-one, especially when Microsoft leaves ISVs out to dry and doesn’t tell them why their code no longer works.

Failure to communicate is always bad for business. It increases costs for ISVs and creates friction between ISVs and their customers. It generates an increased number of calls (and cost) for Microsoft Support to deal with. It slows business productivity where the cloud is supposed to speed things up. It’s a great example of a solution that makes perfect sense when sketched out by engineers on a whiteboard that runs headlong into problems in the real world. All in all, even if it fixed a potential security hole, forcing customers to go to Microsoft support to justify their use of a connector is a poor plan that Microsoft snuck in without saying anything to anyone.

Microsoft might say that they made the change because they want to protect Exchange Online customers. I accept their bona fides, but I expect better from the world’s largest software company, especially in how they deal with ISVs. After all, ISVs help the Microsoft cloud work better for Microsoft customers. They can’t do that if Microsoft changes the rules without saying anything.

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.

Replaces Older Outlook-Based Message Recall

At Ignite 2019 (the last worthwhile event), the Exchange engineering group reported that they were working on a new version of the much-derided message recall feature. I say much-derided because message recall didn’t work most of the time. Microsoft said that Exchange Online users tried to recall messages 800,000 times daily at a 40% success rate. Given the current size of Exchange Online, that number can only have grown since late 2019, so more than half a million people are disappointed daily when they can’t recall a message.

Recall message is a feature that’s almost as old as Outlook for Windows. In the early days of Exchange, the simpler form of networks, fewer external messages, and a less diverse set of clients meant that message recall had some prospect of success. The old mechanism declined over time and badly needed refurbishment.

Deploying Now to Tenants Worldwide

Microsoft announced the new message recall in October 2022 in message center notification MC445411. The last update on 24 January said that the roll-out would start in mid-February, a date confirmed in Microsoft 365 roadmap 59438. The EHLO blog announcing the commencement of the deployment confirmed that tenants should see the new feature by mid-March.

Important Points About Message Recall

The important points about message recall for Exchange Online are:

• The implementation uses an Message Recall agent (a background process) that processes special recall messages (of the IPM.Outlook.Recall class) sent from Outlook for Windows to all message recipients. When enabled for a tenant, the existing recall message UI in Outlook (Figure 1) invokes the new feature instead of the old. No other client can recall messages for now, but Microsoft says that they’re working on an API that will allow other clients to recall messages.
• The agent steps in when it sees the special messages in the stream passing through the Exchange transport system and processes the recall instruction against recipient mailboxes. Apart from the need to recall a message from Outlook for Windows, no other client dependency exists. After the agent recalls a message, client synchronization makes sure that recalled messages disappear from user view. It doesn’t matter if a message has attachments or if it is protected with a sensitivity label or other encryption. However, because of the way the clients integrate with Microsoft Information Protection, message recall for protected messages is only supported from OWA or the new Outlook.
• The agent uses message identifiers to allow it to recall messages even after the recipient has moved them from the inbox.
• The message sender receives a message recall report after the agent finishes processing. The report summarizes the successful and failed attempts to recall the message. Typically, the recall report arrives within a minute or so after submission if the agent needs to deal with ten or so recipients. The more recipients, the longer it takes for the agent to collate the recall status for all recipients. Microsoft says that it could take five minutes for a summary report covering “a few hundred recipients.” Receiving this kind of confirmation should reassure people who recall messages that the process worked. However, even a successful recall is no guarantee that the recipient has not read, printed, or otherwise dealt with the message before its recall.
• Users can recall messages months after their original sending. Although the extended period means that more recipients are likely to have read the content, recall still removes the copy of the message from their mailboxes.
• Because a recalled message is effectively a hard delete of the item from user mailboxes, Exchange Online captures copies of messages recalled by the agent for mailboxes subject to retention or litigation holds to make the messages available for eDiscovery
• The Message Recall agent can only process messages delivered to recipients within the same organization. A message cannot be recalled if leaves the organization and goes to another Exchange Online organization, Exchange Server, or another email system. Microsoft has the technical capability to recall messages sent to any Exchange Online organization and to Outlook.com recipients but cites legal and privacy reasons for restricting recall to the sender’s organization.
• The Message Recall agent only works for Exchange Online. There’s no equivalent for Exchange on-premises servers.
• Messages from shared mailboxes can be recalled. However, the summary report is inaccessible. Microsoft is aware of the issue and is working on a fix.
• If organizations don’t want users to be able to recall read messages, they can update their organization configuration by running the Set-OrganizationConfig cmdlet to update the RecallReadMessagesEnabled setting. By default, the setting is null and the feature works. To disable message recall for messages that recipients have already read, run:

Set-OrganizationConfig -RecallReadMessagesEnabled $False

The setting affects all mailboxes in the tenant. You can’t enable message recall for selected mailboxes. The setting can also be changed through the Settings section of the Exchange admin center (Figure 2).

If you want to disable message recall completely, run Set-OrganizationConfig to update the MessageRecallEnabled setting:

Set-OrganizationConfig -MessageRecallEnabled $False

Overall, Microsoft estimates the improvements they have made allows message recall to have a 90% success rate. Your mileage will vary depending on the recipients of the messages that you attempt to recall. Obviously, if the majority of your email traffic is external, your success rate will be lower. This might be a factor in tenants where Teams is the preferred choice for internal communications and email is largely reserved for external communications.

Message Recall Helps People

Over my 27 years working with Exchange, I haven’t used message recall more than once or twice. The Microsoft data indicates that I might be unusual. It seems like many people find the need to recall a message and are subsequently disappointed. Let’s hope that the new message recall brings more happiness to those who need it after they make a mistake sending a message that they really wished they hadn’t.

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.

Calculating Statistics for Room Mailboxes

A Practical365.com article I wrote explaining how to extract and report statistics for room mailboxes is quite popular. The script uses Microsoft Graph API requests to fetch data about events from the calendars of the meeting rooms and analyzes the data. Apparently, many people need this data for one reason or another.

As I noted last week, when you publish a PowerShell script and make it available publicly, you’re likely to get requests for enhancements. Most of the time I don’t mind people sharing their ideas with me because I like hearing what others think and the issues they grapple with. Being forced to respond to questions also encourages research to find the right answers, and that’s a good way to acquire more knowledge.

In a minority of cases, I wonder why the person making a request doesn’t simply amend the code to do what they want. It could be that they don’t feel too confident with PowerShell or don’t know how to make a change. Basic familiarity with PowerShell and the modules used with Microsoft 365 is a core competency for administrators. At least, it is if you want to automate administrative operations.

Report Daily Usage Patterns for Room Mailboxes

In any case, this week a request came in to report the most popular days for meetings. Given that we already have the data about meetings and report statistics like the total events for a room, total minutes booked, average event duration, average attendees, and so on, it’s logical to ask when is a meeting room popular.

The information recorded for each meeting has a start and end date, so finding out the day of the week that the meeting occurred on is easily done with the PowerShell Get-Date cmdlet:

$Day = (Get-Date($MeetingStart)).DayOfWeek

Storing the day of the week for each event allows the script to analyze the information when it generates the other statistics. The basic approach I took is:

• Count the total events for each day.
• Compute the percentage of the overall events for each day.
• Build a very basic chart element for the day. The idea is to build a simple bar chart where the larger the bar, the higher the daily room usage is. I’ve no doubt that those with more artistic minds than mine can come up with a much nicer solution.
• Store the information.

After processing all room mailboxes, the script generates summary information, including the daily usage pattern for all rooms (Figure 1).

The daily usage data is stored for each room mailbox and the script outputs the same kind of chart for the individual rooms (Figure 2).

After I published the updated script, I was asked how the script aligns the bars. That’s simple. The script inserts a tab character when creating the output. That’s another old PowerShell trick. If the tab character wasn’t there, the bar chart wouldn’t line up properly.

Download Script from GitHub – But Check Article Comments

If you have issues running the script (downloadable from GitHub), check out my article about the most common errors people encounter when running PowerShell with Graph queries. Many of these issues are debated and resolved in the comments for the original article. Remember, it’s PowerShell, so the code is there to be amended. Enjoy!

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.

License Stacking Allows Workloads to Manage Multiple Licenses

The Exchange Online blog post of January 20 “Introducing Support for Concurrent Exchange Online License Assignments” caused some furrowed brows because on first glance it doesn’t seem like an important announcement. The impact of the change depends on the size of a Microsoft 365 tenant and the processes used for license management. If your tenant is small and licenses are relatively static, you can safely ignore this topic. But those who run large tenants and use features like group-based license assignments are likely to be much more interested.

License stacking means that an Azure AD user account can hold multiple licenses for the same workload. Some of the licenses might be inherited from products (SKUs) that bundle multiple service plans (a not-for-sale license included in a SKU). Others come from specific products or add-ons. For instance, an account might hold the Teams Exploratory license and also have a license for Teams through the Office 365 E3 or E5 SKUs. When license stacking is in place, the workload is responsible for resolving the capabilities made available through the different licenses and allowing the account access to the feature set available from the best (“most superior”) license. In the example above, Teams would respect the license from Office 365 E3 or E5 because it covers more functionality than the Teams Exploratory license.

Exchange Online Licenses

In the case of Exchange Online, four licenses are available:

• Exchange Online Essentials (BPOS_S_Essentials).
• Exchange Online Kiosk (BPOS_S_Deskless).
• Exchange Online Plan 1 (BPOS_S_Standard).
• Exchange Online Plan 2 (BPOS_S_Enterprise).

BPOS refers to Business Productivity Online Suite, a predecessor to Office 365 based on Exchange 2007.

Microsoft says that they have updated the Get-ExoMailbox (Get-Mailbox) and Get-Recipient cmdlets to give tenants insight into the Exchange capabilities assigned to accounts through the licenses assigned to the accounts. I found that the data isn’t fully populated for all mailboxes (this will happen over time). However, it’s possible to run a command like this to report assignments:

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Format-Table DisplayName, RootCapabilities

DisplayName                             RootCapabilities
-----------                             ----------------
Tony Redmond                            BPOS_S_Enterprise
Ben Owens (DCPG)                        None
Andy Ruth (Director)                    BPOS_S_Standard, BPOS_S_Enterprise
James Ryan                              BPOS_S_Enterprise

The Ben Owens account is an example where the assignment information isn’t yet populated. The Andy Ruth account is an example where two licenses are in place that include an Exchange service plan (one for Exchange Online Plan 1, the other for Plan 2). In this case, because Exchange Online Plan 2 enables more functionality than Plan 1, it’s the one that Exchange Online respects.

Concurrent License Assignments for Exchange Online

Traditionally, Exchange Online has not supported license stacking, which means that an Azure AD account can hold a single Exchange Online license. Most of the time this doesn’t matter because the usual situation is for an account to receive an Exchange Online license through a product SKU. For instance, Office 365 E3 and E5 both include the Exchange Online Plan 2 service plan.

However, it’s possible that an account might start out with a Microsoft 365 Business Basic license that includes Exchange Online Plan 1. The account belongs to a user who’s promoted to a management position that the organization requires to come within the scope of a retention policy and have an online archive. These features require Exchange Online Plan 2, so the organization removes the Microsoft 365 Business Basic license and assigns the account an Office 365 E3 license.

Exchange Online mandates that all user mailboxes have licenses. When the organization removes the Exchange Online Plan 1 license from the account, a chance exists that Exchange Online might soft-delete the mailbox and make it unavailable. The mailbox becomes available again when the account gains the Exchange Online Plan 2 license through Office 365 E3, but it’s not a great situation to be in if a user loses access to their mailbox while license administration is in progress.

Why Exchange Online License Stacking is Helpful

Support for license stacking (multiple concurrent licenses) means that the organization can assign the superior license to the account before removing the other license. This might happen through an automated process. For instance, a group-based licensing assignment might occur and assign the license because of the user’s new job means that they join a group. Later, another process might remove the inferior license from the account to return it to the unused license pool. Automated license assignment by reference to a property of Azure AD accounts is very common, both through Azure AD group-based assignment and purpose-built license management tools. Organizations often go down this route because of the complexity that’s sometimes found in understanding the combinations and permutations available in Azure AD licensing.

Group-Based Licensing for All

In August 2021, as part of their announcement about the retirement of the license assignment cmdlets in the Azure AD and MSOL PowerShell cmdlets. Microsoft promised to remove the additional licensing requirement for group-based licensing. That hasn’t happened yet because Microsoft has had to delay the move to the new licensing platform for Microsoft 365.

The current schedule deprecates the licensing cmdlets on March 31, 2023, and perhaps this will mark the point when Microsoft allows everyone to use group-based licensing. If you haven’t already migrated PowerShell scripts that do license management to the Microsoft Graph PowerShell SDK, it’s time to get going.

Good Housekeeping Change

Microsoft is rolling stacked licenses support for Exchange Online in  the commercial clouds. Government clouds are next and will be done by the end of H1 2023. It’s not an exciting change, but it’s a good example of a housekeeping enhancement that will stop users losing access to their mailboxes due to internal license management.

Configure Shared Mailbox Auto Reply for External Contacts

Contact handling is an important part of website communication. Most sites have a contact form that people can fill in to ask questions, perhaps after passing a CAPTCHA test. Behind the scenes, the information from the form might end up in an email to allow the site owners to deal with the query, which is how things should work normally.

Much to the embarrassment of the Office 365 for IT Pros team, we discovered that the contact form for our website has not worked for quite a time. We’ve fixed the problem now to make sure that if anyone uses the contact form to ask a question about the book or comment on book text, the site emails the query to a shared mailbox. If anyone’s interested, we upgraded the site to use the WPForms Lite plug-in for WordPress.

Suitably chastened, we have reached out to people who entered queries through the contact form to follow up and make sure that their questions are answered.

Shared Mailboxes versus Microsoft 365 Groups

Now that everything is fixed on our web site, contact messages sent to Office 365 for IT Pros flow into a shared mailbox. We could use the Microsoft 365 group to process book comments, but it’s cleaner to separate the two. And anyway, we want to use an auto-reply message to acknowledge the receipt of queries, and that feature isn’t supported yet by Microsoft 365 groups (see this comparison between shared mailboxes and Microsoft 365 groups). Some people don’t know that shared mailboxes support auto-reply, but they do and it’s a very useful option at times. For instance, when national holidays roll around, you can use PowerShell to quickly configure shared mailboxes used for customer communication with an appropriate auto-reply message saying that responses will be delayed.

We do use a Microsoft 365 group to organize the production of the book because we keep our chapter and other files in a SharePoint Online site and use Teams to discuss different aspects of the book, like what we’re working on in a monthly update or who hasn’t filed their chapter updates for a monthly update. So many options exist within Microsoft 365 to achieve goals in different ways that it’s often hard to decide which is best. In our case, being able to send auto-replies for contact messages tipped the balance.

Configuring the Distribution List

The email address used for comments configured on our website directs messages to a distribution list. The membership of the distribution list includes the shared mailbox and some other user mailboxes that might be involved in answering queries.

Because the first address reached by inbound messages is a distribution list, we need to configure the list to allow the generation of auto-reply messages and to allow external people to send messages to the list:

Set-DistributionGroup -Identity O365.Book.Comments -RequireSenderAuthenticationEnabled $False -SendOofMessageToOriginatorEnabled $True

To configure the shared mailbox auto reply, we use the Set-MailboxAutoReplyConfiguration cmdlet:

$AutoReplyText = "<h1>Thanks For Your Message</h1><p>We've received your email to <b>Office 365 for IT Pros</b>. If we need to respond to you, we'll be in touch by email within 48 hours. If you need help faster, reply to this email and we'll accelerate our response.</p><p>Best Regards</p><p><i>The Office 365 for IT Pros team</i></p>"
Set-MailboxAutoReplyConfiguration -Identity book.comments@office365itpros.com -AutoReplyState "Enabled" -InternalMessage $AutoReplyText –ExternalMessage $AutoReplyText -ExternalAudience 'All' 

Figure 1 shows the auto-reply we generate:

The technique of allowing Exchange Online to generate and deliver auto-reply messages for messages received by mailboxes through their membership of a distribution list is uncommon but it is used in practice (which is why the SendOofMessageToOriginatorEnabled parameter exists). For instance, this recent example of a use case is in the Microsoft Technical Community.

Another thing to check is to ensure that the shared mailbox doesn’t have a forwarding SMTP address set (this article is worth checking out when debugging OOF issues). Exchange Online won’t send auto-replies for a mailbox when a forwarding address is set.

Forwarding from a Shared Mailbox

We could have reversed the process and configured the shared mailbox to forward messages to another address. Any valid internal SMTP address works including one for a distribution list, but the outbound spam filter probably blocks forwarding to external addresses. If the organization blocks forwarding to external addresses, senders receive a non-delivery notification (5.7.520 Access Denied). In general, mail forwarding from mailboxes is a practice to avoid, so it’s one that we decided not to investigate too much.

Normal Service Resumed

Running a website throws up challenges on an ongoing basis. We should have caught the problem with our contact form earlier and sincerely regret if this caused anyone any extra hassle. On the upside, it did give us a chance to review the handling of contact queries from the website through to Exchange Online to make sure that everything now works as it should.

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.

Managing Azure AD User Country and Regional Settings

A question arose about why Exchange Online doesn’t synchronize country settings from Azure AD user accounts, leading to a situation where an Azure AD user account and its mailbox might have inconsistent values. Here’s an example where the Get-MgUser and Get-Recipient cmdlets report different country values for a user account:

Get-MgUser -UserId Sean.Landy@Office365itpros.com | Format-Table country, usagelocation

Country UsageLocation
------- -------------
Austria FR

Get-Recipient -Identity Sean.Landy@Office365itpros.com | Select-Object country*

CountryOrRegion
---------------
France

The technical reason for the apparent inconsistency is simple: Get-MgUser reads data for a user account from Azure AD while Get-Recipient reads information about a mailbox from EXODS, the Exchange Online directory. We’re dealing with two different objects stored in two different directories.

EXODS exists to manage mail-specific properties for mail-enabled objects, like mailboxes. EXODS also manages Exchange objects that aren’t in Azure AD such as public folders and dynamic distribution lists.

Dual Write Between Azure AD and EXODS

To ensure consistency across the two directories, Azure AD and EXODS use a dual-write process. In other words, when an application attempts to update an object, the write operation must succeed in both directories before Azure AD and EXODS commit the change.

However, this doesn’t happen for every property for every object in the two directories. Although the mailbox CountryOrRegion property receives the same value as the user account’s Country property when Exchange Online creates a new mailbox, synchronization doesn’t follow for further updates. Azure AD and EXODS synchronize updates to other elements of address information like the street address, city, and province made in either directory, but ignore changes to the Country property in Azure AD or the CountryOrRegion property in EXODS. Perhaps the reason is that the two properties have different names and purposes: One is specific to a country while the other can store a country or region name. In fact, EXODS doesn’t store a Country property for mailboxes.

All of which means that it is possible to update an Azure AD account with a new value for the country property without any effect on EXODS. For example, this command updates Azure AD without doing anything to EXODS:

Update-MgUser -UserId Sean.Landy@Office365itpros.com -Country "Ireland"

Likewise, the same is true of an update to EXODS with the Set-User cmdlet. Azure AD ignores this update:

Set-User -Identity Sean.Landy@Office365itpros.com -CountryOrRegion "United States"

In practical terms, the inconsistency might be irritating but it isn’t important. Azure AD is the directory of record for Microsoft 365 and applications should go to it for information about user accounts. The information stored in EXODS about mailbox owners is for informational purposes only. If you want everything to match, then you must create a mechanism (a PowerShell script most likely) to synchronize the properties you want to be consistent.

Azure AD Account Usage Location

Another potential inconsistency is the usage location assigned to an Azure AD account. In the example above, the usage location is FR (France) but the Country property says Austria. The usage location is where Microsoft delivers the service to the account and it’s important that it’s correct because Microsoft cannot deliver some elements of Microsoft 365 (mostly to do with encryption) in certain countries.

Life being what it is, the usage location set when creating an account can change. For instance, a user might relocate to work in an office in another country for a period. There’s no requirement to update the usage location for the account because this should reflect the user’s normal location. In addition, an account’s usage location isn’t associated with the tenant home location. The location (or datacenter region) for a tenant establishes where Microsoft delivers services to the tenant from and where tenant data resides. This can be a country-level datacenter (like France, Switzerland, or South Africa), or a regional datacenter (like the U.S. or Western Europe). Tenant accounts located in countries outside a datacenter location can access services delivered to the tenant. Multi-geo tenants are available should local data residency be necessary.

Mailbox Regional Settings

When you create a new Microsoft 365 account and license the account for Exchange Online, the mailbox does not inherit regional properties from the country or service location defined for the Azure AD account. This is deliberate because regional properties are personal to the user and define the language used to interact with the mailbox, its time zone, and the preferred date format. Different groups of people in the same country often use different regional settings. Examples include Welsh speakers in the United Kingdom and Flemish speakers in Belgium.

OWA applies default regional properties based on the tenant location the first time the mailbox owner signs in and creates a set of default folders. For example, mailboxes that use the English language have an Inbox folder, while mailboxes configured for French use Boîte de réception. Users can update regional settings for OWA through Outlook settings. (Figure 1). If they change the selected language, they have the option to rename the default folders.

Administrators can run the Set-MailboxRegionalConfiguration cmdlet to change the regional settings for a mailbox. In this example, the mailbox language, time zone, and date and time formats match the settings for a Dutch user working in the Netherlands. Notice the use of the LocalizeDefaultFolderName parameter, set to $True to force Exchange Online to create default folder names in Dutch for the mailbox:

Set-MailboxRegionalConfiguration –Identity 'Rob Young' –Language nl-NL 
–TimeZone 'W. Europe Standard Time' –DateFormat ‘d-M-yyyy’–TimeFormat 'HH:mm' 
–LocalizeDefaultFolderName:$True

Apart from the language, the time zone is the most important setting because it’s used by Microsoft 365 applications. For example, Teams displays the local time zone for other users when showing their details in profile cards. If your organization scripts the creation of new accounts, it’s a good idea to make sure that the code includes the configuration of an appropriate time zone setting for the mailbox.

Reporting Azure AD User Country and Regional Settings

It’s easy to audit the language settings of Azure AD accounts and mailboxes. Here’s some code to show how:

$Report = [System.Collections.Generic.List[Object]]::new()
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All
ForEach ($User in $Users) {
  Write-Host ("Processing account {0}" -f $User.DisplayName)
  $RegionalSettings = $Null
  $RegionalSettings = Get-MailboxRegionalConfiguration -Identity $User.UserPrincipalName -ErrorAction SilentlyContinue
  $CountryOrRegion = (Get-User -Identity $User.UserPrincipalName -ErrorAction SilentlyContinue) | Select-Object -ExpandProperty CountryOrRegion
  If ($RegionalSettings) {
  $ReportLine = [PSCustomObject]@{ 
    User                   = $User.UserPrincipalName
    DisplayName            = $User.DisplayName
    Country                = $User.Country
    "Preferred Language"   = $User.PreferredLanguage
    "Usage Location"       = $User.UsageLocation
    "Country or region"    = $CountryOrRegion
    Language               = $RegionalSettings.Language.DisplayName
    DateFormat             = $RegionalSettings.DateFormat
    TimeFormat             = $RegionalSettings.TimeFormat
    TimeZone               = $RegionalSettings.TimeZone }
 $Report.Add($ReportLine) }
}

Figure 2 shows the output. This data is from a test tenant, but it illustrates how easy it is for inconsistencies to occur across the range of country settings available for accounts and mailboxes.

The most important element to get correct is the time zone because it affects the user experience. It would be easy to make sure that Country (Azure AD) and CountryOrRegion (EXODS) contain the same value, but aside from configuring values during account creation, you should leave regional settings alone as they’re a matter of personal choice.

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.

Automatically Enable Archive Mailboxes Once the Primary Mailbox Exceeds a Threshold

A question following my article about how to transition from Exchange Online mailbox retention policies to Microsoft Purview retention policies asked:

“Is there a way in legacy or M365 online archiving policies , that it can be enabled based on primary mailbox data size ,say for example mailbox size crosses 40 gb , it’s online archive gets enabled automatically and older data gets move to online archive to keep primary mailbox at 40 gb limit.”

It’s a reasonable request. Essentially, the organization wants users to keep all email in their primary mailboxes until the mailboxes get to 40GB. Once that point is reached, the organization wants to enable archives for those mailboxes and start to move old email from the primary mailboxes to the archives to keep the size of the primary under 40 GB.

Archive Mailboxes and Sizing

These are proper archive mailboxes and not Outlook’s archive folder. Real archive mailboxes can grow to up to 1.5 TB using the Exchange Online auto-expanding mechanism. Note: if you enable auto-expanding archives, you cannot move those archive mailboxes back to an on-premises Exchange server.

Exchange Online enterprise mailboxes have quotas of between 50 GB and 100 GB based on the license assigned to the account, so the 40 GB threshold is a tad arbitrary. It might be that keeping under this size assures reasonable performance for the OST file. If so, that’s a good thing because you don’t want the OST to become so large that it impacts PC performance.

Assigning Archives Based on Mailbox Size

The outline of the solution is:

1. Find mailboxes that are not archive-enabled.
2. Check the mailbox size.
3. If the mailbox size exceeds the threshold, enable the archive mailbox, and assign an Exchange Online mailbox retention policy to instruct the Mailbox Folder Assistant to move items from the primary to the archive mailbox after they reach a certain age.

Exchange Online mailbox retention policies are the only way to move items into an archive mailbox. Microsoft Purview retention policies can keep or remove items, but they cannot move mailbox items.

To prepare, I created an Exchange Online mailbox retention policy with a single default move to archive tag (Figure 1). The policy can contain other retention tags to handle processing of default folders like the Inbox and Sent Items, or to allow users to mark items for retention. However, all that we need is the default move to archive tag. In this instance, the tag instructs the MFA to move items from the primary to the archive mailbox once they reach 730 days (2 years) old.

Now we need some PowerShell to check for and process mailboxes. Here’s the script that I came up with:

# Define archive threshold
$ArchiveThreshold = 40GB

# Find mailboxes without an archive
Write-Host "Looking for mailboxes that are not archive-enabled..."
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -Filter {ArchiveState -ne "Local"} -ResultSize Unlimited
If (!($Mbx)) { Write-Host "No mailboxes found without archives - exiting!" ; break }

Write-Host ("Checking {0} mailboxes" -f $Mbx.count); $MbxUpdated = 0
ForEach ($M in $Mbx) {
   
   $Stats = Get-ExoMailboxstatistics -Identity $M.ExternalDirectoryObjectId
   If ($Stats.TotalItemSize.Value -gt $ArchiveThreshold) { # Mailbox size is larger than the threshold
      Write-Host ("Enabling archive for mailbox {0}..." -f $M.UserPrincipalName)
      Enable-Mailbox -Archive -Identity $M.ExternalDirectoryObjectId
      Set-Mailbox -Identity $M.ExternalDirectoryObjectId -RetentionPolicy "Mailbox Two-Year Archive Policy"
      $MbxUpdated++
   } #End if
} #End ForEach Mbx

Write-Host ("All done. {0} mailboxes were processed and {1} were archive-enabled" -f $Mbx.Count, $MbxUpdated)

Wrapping Things Up

To complete the solution, we should arrange for the script to be run periodically to be sure that mailboxes receive archives once they exceed the threshold. The scheduler in Azure Automation is a great way to run scripts like this and the cost to execute scripts is very reasonable. V3.0 of the Exchange Online management module introduced support for Azure Automation managed identities so there’s no danger of compromise due to leaked credentials. Which is exactly how it should be.

Learn about exploiting 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.

Viva Briefing Highlights Data from Viva Insights

Microsoft’s history with the generation of personal insights for users based on their work patterns and activities goes back to the purchase of Volometrix in 2015. Volometrix helped organizations to figure out how to be more efficient based on information stored in user mailboxes and calendars, which later became Delve Analytics, MyAnalytics, and finally Viva Insights.

Viva Insights still aims to help people understand how they work so that they can make better use of their time. The Viva Insights suite includes the Viva Insights add-in for Outlook, the Viva Insights app for Teams, the twice-monthly digest email, and the daily briefing email. All surface information gleamed from user interaction with Microsoft 365 captured in the Graph.

Pausing Viva Briefings

Message center notification MC486289 (December 15) says that Microsoft plans to pause sending the Viva Briefing daily email to users who signed up to receive these messages. From an email perspective, Viva Briefing (Figure 1) and digest messages are not real email because Viva injects them directly into user mailboxes. Although the messages are mail items, they do not pass through the Exchange Online transport system and therefore are immune to processing by components like mail flow rules. Microsoft stamps the messages as coming from a trusted sender, so that makes the direct injection acceptable!

Microsoft plans to pause sending Viva Briefing messages after 15 January 2023. Following the normal time required to deploy changes within Microsoft 365, no users should receive these messages after 1 February 2023. Resumption will follow sometime later in 2023. I haven’t received a Viva Briefing message since last Monday. Perhaps my work life isn’t interesting enough to warrant a briefing, or maybe the pause kicked in early for the holiday period.

More Personalized Information

The pause is to allow Microsoft to make changes to the content of the Viva Briefing messages “to be more personalized for each recipient.” I don’t know what this means because the whole point of Viva Briefing is to deliver personalized content to the recipient. For example, Figure 2 shows items found by Cortana (lurking under the covers of Viva Insights) to remind me about things I might like to follow-up. This information comes from email in my mailbox, so it’s highly personalized.

Cortana finds follow-up items by scanning messages for key words and phrases that indicate when the recipient or sender might be committing to an action. The first item in Figure 1 is an example where Cortana highlights that fact that the mailbox owner made a commitment to take an action. The second item is a variation where the mailbox owner asked a recipient to do something.

I don’t depend on the Viva Briefing to find follow-up actions for me, but I do find the prompts to be moderately useful. Sometimes, Cortana highlights something that I have forgotten to do and proves its worth. I suspect that people who have busier calendars and take on more commitments than I do find the briefing email more valuable.

Finding Who’s Using Viva Briefing

Exchange Online automatically enables new mailboxes to receive the Viva Briefing email. However, users won’t receive briefing messages unless they are active. For instance, if you create a test mailbox and only use it from time to time, there’s no email activity for Cortana to analyze and highlight, so there’s no reason to send a briefing. Perhaps the reduced level of email traffic over the last few days is the reason why I haven’t received a briefing message since Monday.

To discover what mailboxes are enabled for Viva Briefing, run PowerShell to find the set of user mailboxes and check each mailbox with the Get-UserBriefingConfig cmdlet. Here’s an example:

$EnabledMbx = 0; $NonEnabledMbx = 0; [array]$EnabledUsers = $Null; [array]$NonEnabledUsers = $Null
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
Write-Host ("Checking {0} mailboxes for Viva Briefing status" -f $Mbx.count)
ForEach ($M in $Mbx) {
   $Status = Get-UserBriefingConfig -Identity $M.UserPrincipalName
   If ($Status.IsEnabled -eq $True) {
      $EnabledMbx++
      $EnabledUsers += $M.DisplayName
   } Else {
      $NonEnabledMbx ++
      $NonEnabledUsers += $M.DisplayName }
}
[string]$EnabledUsers = $EnabledUsers -Join ", " 
Write-Host ("Viva Briefing is enabled for {0} mailboxes and disabled for {1} mailboxes. The following mailboxes are enabled: {2}" -f $EnabledMbx, $NonEnabledMbx, $EnabledUsers)

Waiting for Briefings

Microsoft will likely describe the improvements they make to increase the personalized content in Viva Briefing messages when they relaunch the service. Until then, we’ll just have to track commitments and action items using Outlook tasks, To Do, Planner, Project, or any of the other methods available in Microsoft 365.

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.

Part of the Effort to Move Exchange Online to Modern Authentication

Updated March 27, 2023

Microsoft’s December 15 announcement of the deprecation of Remote PowerShell (RPS) for Exchange Online was predictable but regrettable. Not that I want to keep RPS. Microsoft built RPS to allow administrators to manage Exchange 2010 on-premises servers from local workstations. But time moves on and RPS started down the slippery slope to oblivion when Microsoft began to modernize Exchange Online PowerShell with the introduction of the REST-based cmdlets in 2019. That process came to a head with the launch of V3.0 of the Exchange Online management module in September 2022.

Update: Microsoft issued message center notification MC488586 (20 Dec 2022) for this change.

Update 2: Microsoft has stretched things out to allow customers some extra time to prepare for the change. Remote PowerShell will work in tenants where it’s used today until the end of September, 2023. After that, no more Remote PowerShell. An opt-out tool is available for tenants to request the extra time.

Heading to the V3 Module

What’s happening is part of a phased approach to force Exchange Online tenants to use the V3 module.

• Usage of the V1 module will cease when Microsoft finally blocks basic authentication for connectivity protocols on January 1, 2023. This is a good thing because all clients, including PowerShell, should use modern authentication.
• Usage of the V2 module (the version that originally launched the REST cmdlets) will stop with the deprecation of this module on July 1, 2023. Although the V2 module supports modern authentication, many of its cmdlets are not modernized and therefore still have some dependencies on components like basic authentication via WinRM.
• Microsoft will stop all RPS connections from October 1, 2023. This means that any script that connects to Exchange Online using the New-PSSession cmdlet or by specifying the –UseRPSSession parameter with the Connect-ExchangeOnline cmdlet will fail and you’ll see errors like that shown in Figure 1.

With the Exchange Online management V3 module available for over two months and a deprecation date set six months away (June 30, 2023), why would anyone be upset that Microsoft has chosen to proceed to retire RPS?

Easy Change to Remove Remote PowerShell

Making the change to modern authentication without Remote PowerShell for Exchange Online is easy. First, make sure that all workstations run V3 of the Exchange Online management module. If you use Azure Automation to run Exchange Online scripts, make sure to update the Azure accounts with the Exchange Online V3 module. I use script to periodically check and update modules on local workstations and Azure Automation.

Next, find all the scripts that connect to Exchange Online and look for instances of:

New-PSSession -ConfigurationName Microsoft-Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid

Editorial note: There are many internet articles that inform readers that this is the way to connect to Exchange Online PowerShell. Many of the blogs are quite old, but I found some published in 2022 (here’s an example).

Other scripts might use the Connect-ExchangeOnline cmdlet with the –UseRPSSession parameter. I think these scripts will be less common. My concern is with old scripts that no one has looked at in a while.

Once you find the scripts, you can modify their code to use Connect-ExchangeOnline. Be sure to test the scripts afterward. Apart from the connection, no changes are necessary to cmdlets.

The compliances cmdlets contained in the Exchange Online management module continue to have a dependency on remote PowerShell. Microsoft plans to remove that dependency in the future but hasn’t provided a firm date for the change.

The Azure AD Conundrum

Microsoft wants to eliminate RPS by the end of June 2023, which is the same deadline chosen for the deprecation of the Azure AD and Microsoft Online Services (MSOL) PowerShell modules (license management cmdlets stop working after March 31, 2023). The deprecation of these modules has been delayed multiple times, but as the date approaches tenant administrators know that they must upgrade scripts to use cmdlets from the Microsoft Graph PowerShell SDK or Graph API requests. No automatic tool is available to upgrade scripts. It’s a manual process to review code, decide what SDK cmdlet might be an appropriate alternative, make the change, and then test. This is time consuming work.

For the Exchange development group to choose the same date to deprecate RPS shows an unfortunate and unhappy lack of awareness of what’s happening in the Microsoft 365 ecosystem. It’s possible that an assumption exists that different developers deal with Azure AD and Exchange Online. That assumption might be correct on-premises where the lines between Active Directory and Exchange Server are more distinct. Inside Office 365, the need for close interconnection between Azure AD and Exchange Online is obvious. Even Microsoft acknowledged this when they introduced the dual-write mechanism to update Azure AD and the Exchange Online directory some years ago.

Overall, it would be better if Microsoft pushed the date out a little to give tenant administrators and developers time to finish the Azure AD transition before needing to deal with RPS.

New Year Might Bring Relief

No doubt the Exchange developers will let us know more details about the strategy they’re pursuing to eliminate RPS over time. For now, it seems like we’re heading for an unfortunate and avoidable clash of PowerShell update exercises. That’s bad news. Let’s hope that something changes to ease the problem in 2023.

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.

Set Message Expiration Timeout Interval From 12 hours to 1 Day

I haven’t heard of a demand for a customizable message expiration timeout interval but apparently the need exists. At least, according to message center notification MC441064 (updated 8 December), Microsoft is rolling out a change to enable the capability to tenants now, delayed about a month from the original intent to deploy between mid-October and mid-December. The change is covered by Microsoft 365 roadmap item 93315.

MC441064 says that the ability to customize the message expiration timeout interval is a common request. This might be true for large enterprises, who tend to make these kinds of request, but I’m unsure if the same is true for the majority of Microsoft 365 tenants where administrators often leave default settings in place simply because there are too many jobs to be done.

Expiring Queued Messages That Cannot be Sent

In any case, the message expiration timeout interval governs how long the Exchange transport service holds a message when it cannot be delivered. Normally, the transport service processes messages immediately after sending by making a connection to the destination server and passing the message to that server. Transient errors like network glitches or server unavailability can stop a message leaving Exchange Online, and when this happens, Exchange Online puts the message in a retry queue and attempts to deliver it periodically (after 30 minutes initially and then after every hour).

If a message expiration timeout interval didn’t exist, Exchange Online would keep on retrying to send failed messages from here to eternity. The function of the timeout interval is to set a period after which Exchange Online should inform the sender that it cannot process the message for some reason. The key thing in setting the expiration timeout is to give Exchange sufficient time to allow transient errors to subside and allow queued messages to travel to their destination while not taking so long that the sender is left in limbo with no indication that their message is stuck. After a while, an email can become like a dead fish: it’s still a message but its contents are no good because so much time has elapsed.

Setting a Message Expiration Timeout Interval

The default message expiration timeout interval for Exchange Online is one day. This is a reasonable balance between the time needed to resolve issues and a message still being valid when delivered. The change being made allows tenant administrators to set the interval to any value between 12 and 24 hours. Reducing the interval means that Exchange will expire queued messages faster. Users will receive a non-delivery response (NDR) when their messages expire and because this happens sooner, users will be able to action the problem faster. For instance, they might decide to send the email to a different address.

To configure the message expiration timeout interval, use PowerShell to connect to the Exchange Online management module and run the Set-TransportConfig cmdlet. For instance, to set the interval to 12 hours and 30 minutes, the command is:

Set-TransportConfig -MessageExpiration 12:30:00

To check the value, use the Get-TransportConfig cmdlet:

Get-TransportConfig | Select-Object MessageExpiration

MessageExpiration
-----------------
12:30:00

Figure 1 shows details from an NDR returned to a user after changing the message expiration timeout interval (in this instance, to 12 hours). The original message is dated 13:24 on December 9. The NDR arrives at 13:29 on December 10. We won’t quibble about the extra five minutes!

Things are a little different for on-premises Exchange Server as administrators have more control over how the transport service works. Here’s Microsoft’s advice about configuring message intervals for Exchange 2019.

Message Expiration Timeout is Now Tenant Choice

Any tenant can customize the message expiration timeout interval. However, I suspect that those who do will be organizations that want users to know as soon as possible if problems exist in sending email. Reducing the interval to 12 hours might help, but I guess that depends on if the user is available to receive the NDR and take action to reprocess the failed message.

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.

Report Who Released a Quarantined Message

The question was asked on Twitter about whether it is possible to notify end users when administrators release outbound messages from the quarantine. Most of the time, email ends up in quarantine when Exchange Online Protection decides that inbound messages contain spam or malware, but it’s possible to direct outbound email to quarantine using mail flow rules or actions invoked by Microsoft Purview DLP policies. Exchange Online can certainly quarantine problematic messages but as far as end users are concerned, outbound messages intercepted in this way go into a black hole.

Some good suggestions resulted. My initial response was to use the Get-QuarantineMessage cmdlet to periodically check messages in quarantine and detect released items on that basis. Michel de Rooij came up with a better solution to use a mail flow rule to look for the X-MS-TrafficTypeDiagnostic or X-MS-Exchange-Generated-Message-Source email headers to see if they were related to quarantine releases. That’s quite an innovative approach. However, in both cases, the problem exists that you don’t have all the information about a quarantined message following its release.

Check the Audit Log

Which brings me to the unified audit log. Exchange Online generates audit events for most operations, including when an administrator releases a message from quarantine. Administrators can search the unified audit log by running the Search-UnifiedAuditLog cmdlet to look for QuarantineReleaseMessage events. For example:

$StartDate = (Get-Date).AddDays(-90)
$EndDate = (Get-Date).AddDays(1)

[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 1000 -Operations QuarantineReleaseMessage
If (!($Records)) { Write-Host "No audit records found for quarantine release - exiting" ; break }

This search finds all events logged over the last 90 days when someone released a message from quarantine. The problem is that the information captured in audit log records tells us who released a message but doesn’t tell us anything about the message. For instance, the audit record doesn’t capture the direction of the message (inbound or outbound), the sender, its recipients, and the message subject.

That information is available in the data recorded for quarantined messages. It is therefore possible to capture information about quarantined messages periodically and store the data in a repository that can be checked to retrieve message details. To prove the point, I created a PowerShell list and populated it with details of quarantined messages. Here’s the code I used:

[array]$QM = Get-QuarantineMessage
$QMData = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Item in $QM) {
  $DataLine = [PSCustomObject] @{
   Received     = $Item.ReceivedTime
   MessageId    = $Item.MessageId
   Direction    = $Item.Direction
   Sender       = $Item.SenderAddress
   Recipients   = $Item.RecipientAddress -Join ", "
   Subject      = $Item.Subject
   Type         = $Item.Type
   Expires      = $Item.Expires
   Identity     = $Item.Identity 
   Id           = $Item.Identity.Split("\")[0]}

  $QMData.Add($DataLine)
} # End ForEach Item

Creating a Composite View of Quarantine Message Release

Now that we have data for quarantined messages, let’s use it to create the information needed to communicate with users. This code creates another PowerShell list and then loops through the audit records retrieved earlier. The code checks each audit record against the data for quarantined messages to see if a match exists. If it does, we grab the information about the message and combine it with the information from the audit record to generate a composite view about the release from quarantine.

$QMInfo = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Rec in $Records) {
  $AuditData = $Rec.AuditData | ConvertFrom-Json
  [array]$QMFound = $QMData | Where-Object {$_.Id -eq $AuditData.NetworkMessageId}
  If ($QMFound) {
     ForEach ($Item in $QMFound) {
       $DataLine = [PSCustomObject] @{
         MessageId  = $AuditData.NetworkMessageId
         Received   = $Item.Received
         Sender     = $Item.Sender
         Recipients = $Item.Recipients
         Subject    = $Item.Subject
         Type       = $Item.Type
         Expires    = $Item.Expires
         Releasedby = $AuditData.UserId
         ReleasedAt = $Rec.CreationDate }
       $QMInfo.Add($DataLine)
     } # End ForEach $QMFound
    } # End If
} # End ForEach $Records

Figure 1 shows examples of the composite records generated by the code.

After generating the composite data, it’s then a matter of deciding how to notify end users.

A Directional Oddity

One oddity I noticed is that PowerShell reported a quarantined message as “Outbound” (going out of the tenant) while the Microsoft 365 Defender admin center was certain that the message was “Inbound” (coming into the tenant). Figure 1 shows what Defender reports.

And here’s what Get-QuarantineMessage reported. The other message properties indicate that the message is definitely inbound, so I have no idea why PowerShell thinks otherwise.

Identity                   : 2a008698-201e-497f-3dee-08dad2e835e2\7129d58d-ca5e-7e32-a4f8-676d082ba9af
ReceivedTime               : 30/11/2022 15:33:20
Organization               : a662313f-14fc-43a2-9a7a-d2e27f4f3478
MessageId                  : <PA4PR06MB7264B28C1D73C9EB547DDC5AB8159@PA4PR06MB7264.eurprd06.prod.outlook.com>
SenderAddress              : missf0rtune@hotmail.co.uk
RecipientAddress           : {tony.redmond@xxx.com}
Subject                    : Document 49KB (tony.redmond@xxx.com)
Size                       : 93651
Type                       : High Confidence Phish
PolicyType                 : HostedContentFilterPolicy
PolicyName                 : Default
TagName                    : AdminOnlyAccessPolicy
PermissionToBlockSender    : True
PermissionToDelete         : True
PermissionToPreview        : True
PermissionToRelease        : True
PermissionToRequestRelease : False
PermissionToViewHeader     : False
PermissionToDownload       : True
Released                   : False
ReleaseStatus              : NOTRELEASED
SystemReleased             : False
RecipientCount             : 1
QuarantineTypes            : HighConfPhish
Expires                    : 15/12/2022 15:33:20
RecipientTag               : {Priority Account}
DeletedForRecipients       : {}
QuarantinedUser            : {}
ReleasedUser               : {}
Reported                   : False
Direction                  : Outbound

Looking Everywhere for Data

Often people become dismayed when they look for information and discover that a source doesn’t deliver all the detail they need. It’s often the case inside Microsoft 365 that you can combine data from different sources to come up with an answer. It would be nice if Microsoft captured all the relevant message for a quarantined message release in the audit records, but at least we can find the data.

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.

Use a Historical Message Trace to Find Inbound Email Delivered to Shared Mailboxes

Updated 24-Oct-2023

A question in the Facebook group for Office 365 Technical Discussions (no YouTube videos or marketing posts accepted) asked how to check shared mailboxes for email received from external senders over the past sixty days. The check should look for email received from a specific domain and report details of those messages.

Given the number of shared mailboxes that might be used in a tenant and the volume of email that these mailboxes might receive, running a manual check is not feasible. You would have to sign into each mailbox and review their content. This is a tiresome process that wouldn’t detect messages received from the specific domain that users subsequently deleted (or messages removed by a retention policy).

Exchange Historical Message Traces

Exchange Online historical message traces can go back a maximum of 90 days, so they can be used to search the data logged by Exchange Online when it delivers messages to mailboxes. A single historical message trace can cover up to 100 sender or recipient addresses. If a tenant wants to check email related to a larger number of addresses, they can split the check across multiple searches and combine the results.

It all sounds so easy to script. Run the Start-HistoricalSearch cmdlet to submit the message trace. Check the output. Find and report problem messages. Easy. But as is so often the case, some complexity lurks under the surface.

Submit a Historical Message Trace and Wait

The PowerShell code to automate the check must be split into two scripts. The first creates and submits the historical message trace job. The second analyzes the results of the trace. The two cannot be connected because Exchange Online runs historical message trace jobs in the background as service resources allow. If you’re lucky, a message trace might complete in less than twenty minutes. More often, it will take an hour or so.

Here’s the code I used to submit the job. It finds the set of shared mailboxes, sets the search period, and creates the parameters for the Start-HistoricalSearch cmdlet to process. As noted above, a historical message trace can process up to 100 mailboxes, so a check is there to make sure that we don’t attempt to schedule a job for more than this number of mailboxes.

# Find all shared mailboxes
[array]$SharedMailboxes = Get-ExoMailbox -RecipientTypeDetails SharedMailbox 
If ($SharedMailboxes.Count -gt 100) { 
   Write-Host ("Too many shared mailboxes found - we can't do a message trace for {0} mailboxes" -f $SharedMailboxes.Count) ; break 
}
[array]$RecipientAddresses = $SharedMailboxes.PrimarySmtpAddress

# Submit historical search (maximum of 250 per day)
Start-HistoricalSearch -RecipientAddress $RecipientAddresses -StartDate (Get-Date).AddDays(-60) -EndDate (Get-Date) -ReportType MessageTrace -ReportTitle ("Report Shared Mailbox {0}" -f (Get-Date))

Although you could code a loop to use the Get-HistoricalSearch cmdlet to check the progress of the search job and resume when the job completes, a further complication is that Exchange Online stores the message trace results in Azure storage. There’s no way for PowerShell to download the data for processing. Instead, an Exchange administrator goes to the Mail flow section of the Exchange admin center to view the status of historical message trace jobs and download the results if the job to scan for shared mailbox traffic is complete (Figure 1).

Processing Historical Message Trace Results

Exchange Online downloads the message trace results using a URL like:

https://admin.protection.outlook.com/ExtendedReport/Download?Type=OnDemandReport&RequestID=044439ab-614e-4ec6-b4d9-a095c92befbe

The result is a CSV file in the Downloads folder with a name with a “MTSummary_Report” prefix followed by the historical message trace name and an identifier. For instance:

MTSummary_Report Shared Mailbox Scan 12062022 184532_044439ab-614e-4ec6-b4d9-a095c92befbe

Occasionally, the data generated by Exchange Online doesn’t import properly into PowerShell using the Import-CSV cmdlet. To make sure that everything works, I open the downloaded file with Excel and save it to a known location, like c:\temp\MessageTraceResults.csv. The save seems to cure any lingering data formatting problems.

We can now process the data by first searching the records to find if any originated from the domain of interest. For the purpose of this exercise, I’ll search for messages originating from Practical365.com:

[array]$MessageData = Import-CSV c:\temp\MessageTraceResults.CSV
[array]$ProblemItems = $MessageData | Where-Object {$_.Sender_Address -like "*practical365.com"}
If (!($ProblemItems)) { Write-Host "No email found from Practical365.com - exiting" ; break }

Creating a report from the discovered items is simple:

$ProblemInfo = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Item in $ProblemItems) {
  $DataLine = [PSCustomObject] @{
   Timestamp = Get-Date($Item.origin_timestamp_utc) -format g
   Sender    = $Item.Sender_Address
   Subject   = $Item.Message_Subject
   Recipient = $Item.Recipient_Status.Split("##")[0] }
  $ProblemInfo.Add($DataLine)
} # End ForEach Item

Figure 2 shows the report of the messages received from Practical365.com.

Getting the Job Done

Some organizations extract and move message trace data to external repositories like Splunk to make it easier to perform this kind of tracing. An external repository usually allows for long-term storage and is more flexible in terms of its search capabilities. However, the basic tools built into Exchange Online can do the job, even if the PowerShell processing is split into two tasks. It would be nice if Microsoft allowed tenants to download the message trace data with PowerShell to avoid the messing around with CSV files, but that’s just a small complaint.

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.

A New Take on an Old Favorite Script

In the past, I’ve written several times about using PowerShell to report the membership of Exchange Online distribution lists. Support of multiple mail-enabled objects, including nested groups, makes the extraction of full distribution list membership trickier than simply running the Get-DistributionGroupMember cmdlet and a variety of techniques have been used over the years to expand and report all members using Exchange Online and Azure AD cmdlets and Microsoft Graph API requests.

Normally, I don’t return to the same topic again and again. The reason why I’m back here for a third bite at the cherry is that Microsoft will deprecate the Azure AD PowerShell module on June 30, 2023. Although it’s possible to use Microsoft Graph API requests to report distribution list membership (with a caveat), some would prefer to convert their scripts to another PowerShell module rather than going full-blown Graph. I guess the Microsoft Graph PowerShell SDK is that half-way stop, so here goes.

Using the Graph SDK with Group Memberships

It’s important to understand that the Microsoft Graph PowerShell SDK interacts with Azure AD groups. Distribution lists are Exchange Online objects that synchronize to appear as groups in Azure AD. However, although distribution lists support membership of mail-enabled objects that are unique to Exchange, like mail-enabled public folders, these objects don’t show up in membership reported by Azure AD. The reason is simple: the objects don’t exist in Azure AD. What does show up are the objects supported by Azure AD: user accounts (including guests), contacts, and groups. That’s what you see when you run the Get-MgGroupMember cmdlet to retrieve group membership.

Because distribution groups support nested groups, we need a way to expand the members of nested groups and resolve duplicate member entries that might exist. This can be done using a Graph query to fetch transitive members. The transitive query does all the work to expand nested groups and return a unified set of members.

Because a Graph API request exists to fetch transitive members, an equivalent cmdlet is available in the Microsoft Graph PowerShell SDK. That cmdlet is Get-MgGroupTransitiveMember. For example, this call fetches all the members in the group pointed to by the variable $DL.ExternalDirectoryObjectId.

[array]$Members = Get-MgGroupTransitiveMember -GroupId $DL.ExternalDirectoryObjectId

Objects synchronized from Exchange Online to Azure AD store their Azure AD identifier (GUID) in the ExternalDirectoryObjectId property. For instance, a mailbox stores the identifier for its owning Azure AD user account in the property. Azure AD treats a distribution list like any other group, and so it has a group identifier that’s stored in the property. That identifier is the one we use to extract distribution list membership with Get-MgGroupTransitiveMember.

Get-MgGroupTransitiveMember returns a list of identifiers. In earlier versions of the Microsoft Graph PowerShell SDK, you had to resolve the identifiers into useful information, like the display names of individual group members. Now, the group cmdlets return the information in an array of member details stored in the AdditionalProperties property, which means that we can find what we want by extracting it from the array. For convenience, I usually extract the array into a separate variable:

[array]$MemberData = $Members.AdditionalProperties

You might ask why Microsoft decided to update the groupcmdlets to output the member data in a separate property instead of changing the default to output the list of members (which is how cmdlets like Get-AzureADGroupMember work). One explanation is that changing the output of a cmdlet will break existing scripts. In that context, it’s understandable to include a new property.

Parsing Distribution List Membership

After fetching the transitive membership for a distribution list, the remaining task is to figure out how many members of the different categories are in the set (members, contacts, and groups). This is easily done by counting the items in the set. After it gathers this basic information about the group, the script updates a PowerShell list with the data.

You can drive some other processing from the list. For instance, you might decide to convert any distribution list with over 100 members to a team (use the same kind of approach as described here to covert a dynamic distribution list to a team). An easier decision might be to remove any distribution list found with zero members on the basis that they’re no longer in use. This is easily done with:

$Report | Where-Object {$_.Members -eq 0} | Remove-DistributionGroup

To be safe, I left the confirmation prompt in place so that you’re asked to confirm the deletion of each distribution list. You can suppress the prompt by adding -Confirm:$False to the command.

Reporting Distribution List Membership

The final stage is to generate output, which the script does in the form of a CSV file and HTML file (Figure 1). This ground is well-known and there’s no mystery in the code needed to generate the files.

Converting from Azure AD cmdlets to Microsoft Graph PowerShell SDK cmdlets is not challenging – once you understand how the Graph SDK works. The trick is to make no assumptions about the input parameters or the output a cmdlet produces. You might expect things to work in a certain way, but the chances are that they won’t, so go into the conversion in the spirit of a voyage of discovery and you won’t be disappointed. To help, here’s the script to report distribution list members using the Microsoft Graph PowerShell SDK.

Learn about exploiting 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.

Dynamic Group Membership is the Obvious But Not the Only Option

A member of the Microsoft Technical Community asks if it’s possible to automatically add newly-created accounts to an existing group. The initial response offered by the community focused on dynamic groups – either dynamic distribution lists or dynamic Azure AD groups.

It’s a reasonable suggestion. Dynamic distribution groups are part of base Exchange Online functionality and don’t require any additional licenses. Dynamic Azure AD groups require Azure AD Premium P1 licenses for every account covered by dynamic membership. In both cases, the trick is to make sure that the query used by Exchange Online or Azure AD to determine group membership finds the new account.

Dynamic Group Membership for Exchange Online Mailboxes

It’s possible to create a dynamic distribution group based on a simple query like “all mailboxes” that will automatically include new accounts (if they have mailboxes). Figure 1 shows the UX in the Exchange admin center (EAC) to define the membership of a new dynamic distribution list.

The list works and email sent to it arrives in the inbox of every mailbox in the tenant, including shared mailboxes. This is because the recipient filter generated by Exchange Online for the dynamic distribution group selects all mail-enabled objects with a recipient type of ‘UserMailbox’ and only filters out some system mailboxes.

A dynamic distribution list like this is said to use a “canned” recipient filter because Exchange Online generates the filter based on the choices the administrator makes when they create the new list. You can only edit canned filters through the EAC. Exchange Online gives greater flexibility through the support of custom recipient filters. These filters can only be created using PowerShell, but they’re much more flexible in terms of selecting the set of mail-enabled objects to address through the list. A simple custom recipient filter to find just user mailboxes is shown below together with a test with the Get-Recipient cmdlet to prove that the filter works.

$Filter = "{RecipientTypeDetails -eq 'UserMailbox'}"
Get-Recipient -RecipientPreviewFilter $Filter

Dynamic Group Membership for Azure AD User Accounts

Dynamic Azure AD groups can be used with Microsoft 365 groups and Teams. These groups use different membership filters (query rules) to find the set of target objects. Instead of mail-enabled objects like mailboxes, the query against Azure AD focuses on user accounts rather than mailboxes. However, the same capability exists in that it’s possible to create a dynamic Azure AD group that includes all user accounts, including those newly created.

Again, the key is to construct a query rule that finds all user accounts – of the right type. When Azure AD is used for a Microsoft 365 tenant, there are many non-interactive user accounts created to give identities to objects such as shared mailboxes and room mailboxes. These are all considered “member” accounts and it’s easy to build a rule to find all member accounts. However, you probably want a more refined version that finds just the accounts used by humans.

Azure AD doesn’t have a human filter, so we need to construct something that Azure AD can use to find matching accounts in its directory. One approach is to use licenses for the check. You could look for accounts assigned Office 365 E3 licenses but would have to check for accounts with F1 or E5 licenses too. An easy change is to look for accounts that have any license that has at least one enabled service. For instance, accounts with Office 365 E3 or E5 licenses with the Exchange Online, Teams, Planner, or SharePoint Online service would all match. Figure 2 shows a test of the rule against a “real” user account and some other user accounts belonging to room and shared mailboxes. You can see that the real account passes the validation test while the others do not.

Azure AD accounts used by shared mailboxes must be assigned licenses when they need more than 50 GB of mailbox storage or an online archive. These accounts satisfy the membership rule, but that’s perhaps not important. If it is, some tweaking of the membership rule is necessary to remove the shared mailbox accounts.

Dynamic Group Membership of Org-Wide Teams

If your organization is smaller than 10,000 accounts, new Azure AD accounts automatically join the org-wide teams in the tenant (a tenant can support up to five org-wide teams). Org-wide teams are a special form of dynamic Microsoft 365 group whose membership is controlled by Teams rather than Azure AD, so Azure AD Premium P1 license are not required.

The PowerShell Alternative to Manage Dynamic Group Membership

If you don’t want to use a dynamic object, it’s certainly possible to use standard distribution lists or Microsoft 35 groups. In this scenario, the tenant takes the responsibility for maintaining group membership. Usually, PowerShell is used to add new accounts to group membership. You don’t have to worry about removing deleted accounts from the group as this happens automatically following an account deletion.

To add a new user to a distribution list, use the Add-DistributionGroupMember cmdlet:

Add-DistributionGroupMember -Identity "All Tenant Mailboxes" -Member Lotte.Vetler@office365itpros.com

To add a new user account to a Microsoft 365 group, either run the Add-UnifiedGroupLinks cmdlet (from the Exchange Online management module) or the New-MgGroupMember cmdlet (from the Microsoft Graph PowerShell SDK):

Add-UnifiedGroupLinks -Identity "All Tenant Accounts" -LinkType Member -Links Lotte.Vetler@office365itpros.com

New-MgGroupMember -GroupId "107fe4dd-809c-4ec9-a3a1-ab88c96e0a5e" -DirectoryObjectId (Get-MgUser -UserId Lotte.Vetler@office365itpros.com).Id

If the tenant creates user accounts programmatically with PowerShell, these commands can be added to that script. If not, a background scheduled job could find accounts that don’t exist in group membership and add them. See this article for more information about group management with the Microsoft Graph PowerShell SDK.

Many Possibilities to Ponder

A simple question required a long answer. That’s because the questioner didn’t specify what type of group that they wanted to add new accounts to. In any case, it’s nice to be able to debate the possibilities and then settle on the best course of action to take.

Insight about the various options to manage dynamic group membership for new accounts 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.

No Support for Auto-Expanding Archives in Any Version of Exchange Server

I was surprised that Microsoft had to announce that they have had to programmatically block any attempts to move auto-expanding archive mailboxes from Exchange Online to on-premises servers (MC467234, updated 24 November 2022). The new block should be effective worldwide by the end of December 2022.

Microsoft’s documentation has always been precise on the topic, saying “after auto-expanding archiving is enabled for a cloud-based archive mailbox, you can’t off-board that archive mailbox back to the on-premises Exchange organization. Auto-expanding archiving isn’t supported for on-premises mailboxes in any version of Exchange Server.”

I cannot remember Microsoft being anything but clear on this point. Since the announcement of the feature in June 2015 (the blog post is now offline), it has always been the case that only Exchange Online supported auto-expanding archives. The technology appeared in Exchange Online in 2016 but experienced some teething difficulties that meant that full worldwide deployment didn’t happen until early 2018. At that point, Microsoft wasn’t going to retrofit such a huge technical change on Exchange 2016 and nothing was done to implement auto-expanding archives in Exchange 2019, which is the current situation.

Block to Stop Offboarding Auto-Expanding Archives to Exchange Server

The interesting question is why Microsoft feels it necessary to introduce a new block. Obviously, some customers have tried to move mailboxes with auto-expanding mailboxes back to on-premises servers to find that things don’t go so well. The new block will cause any attempted moves to “gracefully fail with no data loss,” which is quite a relief.

Essentially, once an organization enables auto-expanding archives, it increases its connection to Exchange Online. It’s possible to offboard a mailbox with an auto-expanding archive, but only the primary mailbox can move to on-premises Exchange. The archive remains in the cloud. It remains possible to move Exchange Online mailboxes with simple archives back on-premises.

Important Points About Auto-Expanding Archives

Other important facts about auto-expanding archives include:

• Exchange Online supports the choice of auto-expanding archives for the entire organization or selected mailboxes.
• After an archive mailbox becomes auto-expanding, it is always auto-expanding. The archive mailbox cannot be transformed into a simple archive mailbox again. Although the archive status for mailboxes is visible in the Exchange admin center, EAC doesn’t tell you if the archive is simple or auto-expanding (Figure 1).

• Administrators must use PowerShell to work with auto-expanding mailboxes. For example, to enable an individual mailbox, run the Enable-Mailbox cmdlet:

Enable-Mailbox -Identity Terry.Hegarty -AutoExpandingArchive 

• To find the set of mailboxes enabled for auto-expanding mailboxes, use the Get-EXOMailbox cmdlet to find the set of user and shared mailboxes and apply a client-side filter against the set to find those with the AutoExpandingArchiveEnabled property set to True.

Get-EXOMailbox -RecipientTypeDetails UserMailbox, SharedMailbox -Properties AutoExpandingArchiveEnabled -ResultSize Unlimited | Where-Object {$_.AutoExpandingArchiveEnabled -eq $True } | Format-Table DisplayName, RecipientTypeDetails

• Exchange Online automatically begins the auto-expanding process when an archive mailbox reaches 90% capacity (99 GB of the 110 GB assigned quota). Exchange Online increases the normal archive quota from 100 GB to 110 GB to accommodate auto-expansion. Some older mailboxes might still have 100 GB archive quotas even when enabled for auto-expansion. This problem can be fixed by re-enabling auto-expansion for the archive.
• You can’t recover or restore an inactive mailbox if it has an auto-expanding archive. Instead, you must export the data from the archive using the results of a content search and import the data into another mailbox.
• The limit for an auto-expanding archive is 1.5 TB (here’s a script to report archive status). Originally, Microsoft publicized auto-expanding archives as “bottomless,” but operational and software issues made it necessary to impose a limit.
• Shared mailboxes support auto-expanding archives if you assign an Exchange Online Plan 2 license to the mailbox.

Not Many Organizations Use Auto-Expanding Archives

My judgement is that this change is likely to affect relatively few organizations. First, not every Exchange Online organization uses archive mailboxes. Exchange Online makes large 100 GB primary mailboxes available to enterprise accounts, so there’s less need to offload old email to archive mailboxes. Only Exchange mailbox retention policies can move items automatically. Microsoft would like customers to use Microsoft Purview retention policies instead, but Purview policies can’t move items to the archive.

Second, of the total archive population, there’s probably a low percentage that is enabled for auto-expanding archives. It’s natural to leave mailboxes with simple archives unless they need auto-expansion. Those high-traffic mailboxes tend to be more important than the norm. For instance, those used for customer communications or by public-facing executives who receive large volumes of inbound email and need to retain copies for compliance purposes.

Mailboxes with auto-expanding archives must remain in the cloud. Apart from not being able to transfer these mailboxes to on-premises Exchange, it’s not altogether clear how you could move a large expanded archive anywhere else. Exporting the archive via a content search is the obvious answer, but processing up to 1.5 TB of data will take some time.

Although content search exports can accommodate up to 2 TB, the maximum size per PST for output is 2 GB and the search can upload a maximum of 2 GB of mailbox data per hour. All the data from the archive must upload to Azure before it can download to PSTs. Only a small number of auto-expanding archives will be more than 1 TB. In addition, search filters can reduce the amount of exported data to practical amounts at the expense of leaving some data behind. That might be an acceptable solution in some cases.

I’m not sure how many mailboxes will run into the new block. However, the news that a block is necessary will help organizations who have auto-expanding archives or those considering using auto-expanding archives to plan accordingly. It’s a good reminder that if you use a cloud-only feature, the technology is only available in 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.

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.

Part of the Ongoing Transition from the Legacy EAC

The ongoing saga of the transition from the old Exchange admin center (EAC) to the super-duper modern edition continues. The latest move involved mail flow rules (aka transport rules), described in Message center notification MC449929 (25 October). Microsoft flags the change as a major update, but it really isn’t because it will affect the very small minority of people who work with mail flow rules.

Microsoft will begin to retire the mail flow rules section from the old EAC in November and it should disappear from all tenants by the end of 2022. Eventually, the old EAC will disappear entirely. I won’t shed any tears when this happens as I never liked the layout of the now-legacy EAC (Figure 1). It is very much an artifact of a Microsoft design language that features large expanses of white space.

Two years ago, I noted that, despite missing some useful functionality, the new EAC represents the future. Time flies when you’re having fun and the developers must be laughing merrily because the last two years has gone without a huge amount of progress. No doubt some will point out the difficulty of moving existing infrastructure to a new framework, but it’s not like Microsoft hasn’t done this before. It seems like some of the experience gained in transitioning other administrative portals hasn’t been used. For instance, refreshing access tokens is not done as smoothly in EAC as it is in the Microsoft 365 admin center.

An Enhanced UX

The Microsoft documentation assures us that the new UX (Figure 2) “has been enhanced and modernized. This updated experience is consistent with the new EAC design and will enable easier rule management.” It also points out that the new UX exposes more information about rules. You can see the effect by comparing how the legacy and new EAC display details of the same rule (to include a disclaimer to calendar meeting requests) in Figures 1 and 2.

With that point in mind, let’s consider the details.

Revised Workflows

Although Microsoft says that most workflows (how you create and work with rules) are unchanged, they highlight three major differences:

EAC disables newly-created rules. This is a smart move because it stops mail flow rules becoming active immediately on creation. It’s quite likely that some tweaking is necessary before making a rule active.

EAC features a new rule creation wizard to guide people through the configuration of mail flow rules. Mail flow rules can be quite complex and having a wizard sounds like a good idea, if the wizard wasn’t just plain broken. Take the example shown in Figure 3, which creates a simple disclaimer rule. Despite completing all the necessary steps, there’s no way to move to the next stage in the process. The wizard stays dumb and refuses to say what’s wrong, so there’s no obvious way to proceed and complete the rule. No doubt Microsoft will sort out this glitch and in the interim, there’s always the New-TransportRule cmdlet!

The “landing page” shows if rules stop processing when executed. Mail flow rules have a priority order which dictates the sequence of processing within the Exchange transport service. The stop processing rules setting exists to prevent Exchange running any remaining rules. For instance, if a rule rejects a message and issues a non-delivery notification, it’s appropriate for it to signal to Exchange Online that it should stop processing any remaining rules. Knowing what rules stop processing is obviously important, so Microsoft now highlights the setting in the list of rules (Figure 4)

What’s Missing for Mail Flow Rules

Moving the mail flow rules over to the new EAC is a good thing. It’s just disappointing that everything associated with the new EAC seems to happen so slowly (even if Microsoft isn’t moving some features, like bulk distribution list migration). Taking up so much time to perform what appears to be relatively straightforward tasks leaves less time to improve management of mail flow rules. Essentially, the same type of management of mail flow rules exists in Exchange Online that Exchange 2007 had 16 years ago. The interface is prettier, but the same functionality largely exists.

The processing of Mail flow rules can become very complex when an organization uses more than ten rules. It would be nice if Exchange Online delivered some way to visualize the path of a message through the set of defined rules to help administrators understand what happens as different rules run. Maybe Microsoft will get to something like this when they’ve completed the transition to the new EAC sometime in the next decade.

Keep up to date with developments like the transition to the new EAC 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.

No Point in Preserving a Feature No One Uses

Tired of pushing water uphill, the Exchange development group announced plans to deprecate the EAC feature to migrate distribution lists in bulk to Microsoft 365 Groups (Figure 1). The news comes as no surprise because the feature has not been maintained since its introduction in August 2016. At least, that’s what it seems like.

Microsoft says that the feature “was designed to provide continuity for DL users and to enable continued collaboration without having to make new groups from scratch. As Microsoft 365 Groups is now a mature feature, we are deprecating the feature for migrating DLs to Groups. The deprecation will happen on February 1, 2023.” The announcement makes no mention of the ability to convert an individual distribution list to a Microsoft 365 Group that’s included in the new EAC. It’s all about bulk conversion.

Changes Since 2016 Affected Outlook Groups

First introduced in November 2014, Office 365 Groups (now Microsoft 365 Groups) are certainly a mature technology. But more importantly, the technology environment that existed when Microsoft launched the distribution list migration feature in August 2016 was very different to today. At the time, Office 365 Groups had just picked up support for Azure B2B Collaboration (guest access) and seemed poised to be the cornerstone of Microsoft 365 collaboration.

Everything changed with the preview of Teams in November 2016 (general availability in February 2017). Today, Teams has more than 270 million monthly active users. The last number for Outlook groups is “more than 10 million” (April 2017). I’m sure some growth has happened in the five years since but maybe not much. Teams has sucked a lot of the oxygen out of the Microsoft 365 collaboration space.

Today’s reality is that the importance of Outlook Groups disappeared a long time ago and the major function of Microsoft 365 Groups is as a coordinating mechanism for group resources and the provider of membership services to Teams.

Other Factors in Play in Distribution List Migration

Two other factors are in play. First, Microsoft is busy trying to move functionality from the old Exchange admin center (EAC) to a modernized version. That process is taking far too long. Cutting features enables the transition to accelerate, which is a good thing.

Second, the bulk migration feature can only process simple distribution lists. The value of many distribution lists lies in their ability to include different types of mail-enabled recipient, including other distribution lists. Dynamic distribution lists are very powerful, especially with custom recipient filters, but the migration feature doesn’t support these objects either, even though dynamic Microsoft 365 Groups (and Teams) are.

Admittingly, dynamic Microsoft 365 Groups were a long way away in August 2016, but the fact that the migration feature has not maintained pace with technical developments within Microsoft 365 is evidence that no one has paid much attention to updating the distribution list migration code recently.

Microsoft’s Suggested Replacement is a Manual Conversion

Microsoft’s suggested approach is extraordinarily manual. Essentially, it’s the same approach that you’d take to move an on-premises distribution list to the cloud (create a new Microsoft 365 group and switch the DL attributes to it).

Although their suggestion is a valid approach, I’m surprised that Microsoft hasn’t created a script to automate the process. The task is not particularly difficult, especially if only “eligible” (simple, non-nested) distribution lists are the target. Microsoft might even be able to repurpose the code in the to-be-deprecated EAC feature, if only the appetite existed to deliver a conversion script to customers. Some old migration scripts are still available in the Microsoft download center that could have been updated and brought into service. Maybe Microsoft doesn’t want the hassle of supporting the code.

It’s even possible to script the conversion of dynamic distribution lists to Microsoft 365 Groups, albeit with static group membership because of the different filtering capabilities that exist in Exchange Online and Azure AD.

Migrations can be tough. I’m sure Microsoft has some data to justify their decision to deprecate the conversion feature. Maybe they’ve noticed a reduction in the use of distribution lists or that the percentage of Microsoft 365 Groups that aren’t team-enabled is dropping. Only Microsoft knows. What’s real is that February 1, 2023, will see the disappearance of a feature that once promised so much and ended up being a neglected disappointment.

Historical Searches Scan Message Trace Data for Up to 90 Days in the Past

It’s a while since I had the need to run some message traces for Exchange Online. At least, run traces that exceed the 10-day online window that Exchange Online supports for instant access to trace results. After this period, Exchange Online moves the message trace data (essentially what’s called the message tracing logs for Exchange Server) to an offline store. To get trace information going back further, administrators must submit an “historical search.”

Historical searches can go back 90 days. Historic is just another way of saying “your data is offline and we need to run a background job to retrieve the data.”

Why Some Message Traces Need to be Historic

When you think about the situation, Microsoft’s approach is very logical. Given the size of the Exchange Online infrastructure (300K mailbox servers processing 9.2 billion messages daily), keeping message trace data online for more than 10 days would occupy a lot of storage. Microsoft’s telemetry no doubt tells them that most message traces occur within 10 days of a message being sent, so we end up with the 10-day online trace limit.

In fact, historical searches can find messages within 1-4 hours. Exchange Online continually offloads message trace data to the offline store. To reduce strain on the service, a tenant can run up to 250 historical searches daily (another form of throttling) and the CSV files created by historical searches can contain up to 100,000 lines. Most tenants won’t hit these limits, but if you try to run too many searches in a 24-hour period, Exchange Online will warn you.

Running a Historical Search

In any case, my requirement was simple. A user wanted to know if they had received email from a known sender about two weeks ago. Unlike normal message traces, which administrators can run from the Exchange admin center (EAC), you can only create historical searches through PowerShell by running the Start-HistoricalSearch cmdlet.

Apart from regular message trace searches (the type I wanted), Start-HistoricalSearch can generate different reports. Vasil Michev documents those reports on his blog, so I can ignore them here. Instead, our needs are met by running a simple message trace report where the essential elements are the sender address, recipient address, start and end date, and report type. A command like this submits the historical search as a background job for Exchange Online to process.

Start-HistoricalSearch -SenderAddress John.Doe@domain.com -RecipientAddress Terry.Hegarty@office365itpros.com -StartDate 1-Sep-2022 -EndDate 26-sep-2022 -ReportType MessageTrace -ReportTitle 'Investigation 999'


JobId                                SubmitDate          ReportTitle          Status     Rows ErrorCode ErrorDescriptio
                                                                                                        n
-----                                ----------          -----------          ------     ---- --------- ---------------
3afbd203-32b1-43d1-a7cc-9d279476ce19 26/09/2022 19:58:55 Investigation 999    NotStarted 0

Don’t expect Exchange Online to start processing the job immediately. Unless it’s a period of very low service demand, this won’t happen. Instead, the job remains queued until Exchange has some resources to handle the request. Go away and have a coffee and then check if the job has progressed. If you must, use the Get-HistoricalSearch cmdlet to monitor progress:

Get-HistoricalSearch -JobId 3afbd203-32b1-43d1-a7cc-9d279476ce19 | Select ReportTitle, Status

ReportTitle          Status
-----------          ------
Investigation 999    NotStarted

Don’t get excited when you see that a job status is “InProgress.” A job can stay in this state for an hour or more.

A Stop-HistoricalSearch cmdlet is also available if you make a mistake with a message trace request and want to cancel a job.

Retrieving Search Data

Eventually, stars will align and Exchange Online runs the job to retrieve the message trace data. You might wait between 20 minutes to eight hours. To access the report, head to the message trace section of the Exchange admin center and select the downloadable reports tab (Figure 1). Historical search reports are called enhanced summary reports, but what’s in a name?

Exchange Online creates historical message trace reports as CSV files. When downloaded, you can open the files with Notepad or Excel (Figure 2) to interrogate the contents as required, The same information as available about the path of an email as seen in an online message trace is included in a historical search report. Note that dates are all in UTC format, so they might need to be translated into local time to make sense.

90 Days is the Limit

Running message traces is not one of my core competencies. It’s also not something that I do frequently. It’s nice to know that the historical search facility is available if I want to use it. That is, if I remember to trace within 90 days of a message being sent.

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.

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.

Update User Email Addresses and User Principal Names

A recent reader question asked about the best way to update a bunch of user accounts after the organization buys a new vanity domain and wants the domain used for email addresses and user principal names (sign-in addresses). This sometimes happens when a business goes through a rebranding exercise and ends up with a new name. The requirement to update email addresses and user principal names also occurs in tenant-to-tenant migrations.

Tenant-to-tenant migrations are a specialized kind of activity that’s usually managed with software built for this purpose. We won’t plunge into the challenges that these projects can encounter. Instead, we’ll focus on the scenario where someone in authority decides that all accounts should use different email addresses and user principal names.

Registered Domains

The first requirement is to add the domain to Office 365. Until this is done, you cannot use the domain. Once the domain is known to the tenant, it appears in the set of verified domains seen in the Microsoft 365 admin center (Figure 1).

After verifying the domain for Microsoft 365, we can write some code to ask the administrator what domain to use. Here’s an example that uses the Get-MgOrganization cmdlet from the Microsoft Graph PowerShell SDK to fetch the verified domains:

Connect-MgGraph -Scopes Directory.Read.All, User.ReadWrite.All
# Get tenant information and the verified domains for the tenant
$TenantInfo = (Get-MgOrganization)
[array]$Domains = $TenantInfo.VerifiedDomains.Name
$DomainsList = $Domains -join ", "
Write-Host "Verified domains for this tenant:"
Write-Host "---------------------------------"
Write-Host ""
$Domains
Write-Host ""
$DomainToUse = Read-Host "What domain do you want to use for primary SMTP addresses and UPNs"
Write-Host ""
If ($DomainToUse -notin $Domains) {Write-Host ("The selected domain ({0}) is not in the set supported by the tenant ({1}). Please try again." -f $DomainToUse, $DomainsList); break }
$CompareDomain = "*" + $DomainToUse + "*"

Finding Mail Recipients

The next step is to find mail-enabled recipients that have email addresses that might need updating. This code finds user mailboxes, shared mailboxes, group mailboxes (for Microsoft 365 groups), distribution lists, and security-enabled distribution lists.

For each object, the code calculates a new primary SMTP address based on their existing address by swapping the existing domain for the new domain. A check makes sure that the new address isn’t already in use, and if it is, creates a new address by adding “.EXO” to the username. The code then checks if it’s necessary to update the user principal name for the Entra ID accounts used by user mailboxes and shared mailboxes. An account might already use the new domain, so the code checks the account’s current user principal name and updates it with the new domain if necessary.

The output is captured in a PowerShell list that’s exported to a CSV file.

If (!($DomainToUse)) {
   Write-Host "No domain to move to is defined. Please make sure that the $DomainToUse variable is defined"
   Break
} Else {
   Write-Host ("Processing accounts to move them to the {0} domain..." -f $DomainToUse)
}

[array]$Recipients = Get-Recipient -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, GroupMailbox, MailUniversalDistributionGroup, MailUniversalSecurityGroup, DynamicDistributionGroup

$i = 0
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($R in $Recipients) {
     $i++
     If ($R.PrimarySmtpAddress.Split("@")[1] -ne $DomainToUse) { #Need to process this mailbox
      Write-Host ("Processing {0} {1} ({2}/{3})" -f $R.RecipientTypeDetails, $R.DisplayName, $i, $Recipients.Count)
      $NewUPN = $Null
      # Figure out new email address
      $NewAddress = $R.Alias + "@" + $DomainToUse
      # Check that the address is available
      $Status = Get-Recipient -Identity $NewAddress -ErrorAction SilentlyContinue
      # If we get a status the recipient address already exists, so create a new address
      If ($Status) { $NewAddress = $M.Alias + ".EXO@" + $DomainToUse }
      
      # Figure out if the account's user principal name needs to change
      If ($R.RecipientType -eq "SharedMailbox" -or $R.RecipientType -eq "UserMailbox") {
        $UPNDomain = $R.WindowsLiveId.Split("@")[1]
        If ($UPNDomain -ne $DomainToUse) { # New UPN needed
          $NewUPN = $R.WindowsLiveId.Split("@")[0] + "@" + $DomainToUse
          $Status = Get-MgUser -UserId $NewUPN -ErrorAction SilentlyContinue
          If ($Status) { # UPN already exists, so create a new one
            $NewUPN = $R.WindowsLiveId.Split("@")[0] + ".EXO@" + $DomainToUse }
          }
       }

      $ReportLine   = [PSCustomObject] @{ 
         DisplayName            = $R.DisplayName
         OldUPN                 = $R.WindowsLiveId
         NewUPN                 = $NewUPN
         PrimarySmtpAddress     = $R.PrimarySmtpAddress
         NewAddress             = $NewAddress
         Type                   = $R.RecipientTypeDetails
         Alias                  = $R.Alias
    }
    $Report.Add($ReportLine) }
}
$Report = $Report | Sort-Object Type
$Report | Export-CSV -NoTypeInformation c:\temp\MailObjects.Csv

Administrators can check the CSV to remove any mail-enabled recipients they don’t want to receive new email addresses (Figure 2).

Update User Email Addresses with a New Domain

The next step is reads in and processes an array of objects from the updated CSV file.

The code uses a Switch statement to check the object type and calls the appropriate cmdlet to assign the new primary SMTP address to the object. If the account used for a mailbox (user or shared) requires an update for its user principal name, we go ahead and do it.

The final step in the loop through the objects is to report what’s been done, noting the old and new SMTP address and the old and new user principal name.

# Process mail objects array to update primary SMTP addresses and UPNs as necessary
[array]$MailObjects = Import-CSV MailObjects.CSV
$Report = [System.Collections.Generic.List[Object]]::new()

Write-Host "Processing mail-enabled objects..."
$i = 0
ForEach ($M in $MailObjects)  {
   $i++
   Write-Host ("Processing {0} {1} ({2}/{3})" -f $M.Type, $M.DisplayName, $i, $MailObjects.Count)

   # Assign new primary SMTP Address
   Switch ($M.Type) {
      "DynamicDistributionGroup" { # Dynamic distribution list
        Set-DynamicDistributionGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "GroupMailbox" { # Microsoft 365 group
        Set-UnifiedGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "MailUniversalDistributionGroup" { # Distribution list
        Set-DistributionGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "MailUniversalSecurityGroup" { #Mail-enabled security group
        Set-DistributionGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "SharedMailbox" { # Shared mailbox
        Set-Mailbox -Identity $M.PrimarySmtpAddress -WindowsEmailAddress $NewAddress 
     }
      "UserMailbox" { # User mailbox
        Set-Mailbox -Identity $M.PrimarySmtpAddress -WindowsEmailAddress $NewAddress 
     }
    }

   # Update UPN if necessary
   If ($M.NewUPN) {  
     Update-MgUser -UserId $M.UPN -UserPrincipalName $M.NewUPN }

   $ReportLine   = [PSCustomObject] @{ 
          DisplayName            = $M.DisplayName
          OldUPN                 = $M.UPN
          NewUPN                 = $M.NewUPN
          OldPrimarySmtpAddress  = $M.PrimarySmtpAddress
          NewPrimarySmtpAddress  = $M.NewAddress
          Type                   = $M.Type
          Alias                  = $M.Alias
    }
    $Report.Add($ReportLine) 

} # End ForEach 
Write-Host "All done!"

Figure 3 shows an example of the report that allows administrators to check that the expected email addresses and user principal names are in place.

The User Issue

Updated user principal names take effect the next time users sign in. If you want to force the switchover, you could disconnect users from their current sessions by invalidating refresh tokens using the Graph revokeSignInSessions API. Invaliding access tokens forces users to reauthenticate and reconnect, and to do that, they must use their new user principal names.

Be aware that some issues exist when changing user principal names such as the need to set up the new user principal name on the Microsoft Authenticator app so that MFA challenges work It’s worthwhile reading through this Microsoft article to understand and test problems that users might encounter in your organization. Knowing what might happen and being prepared to fix the issues will ensure a smoother transition.

Any change to the way people sign-in is likely to cause some angst if it’s not communicated clearly so that everyone understands why the change is happening and what they must do to sign-in to access services.

Tidying Up Entra ID

The process outlined above takes care of the bulk of the work. If some Entra ID accounts that don’t have email addresses need to receive updated user principal names, you can do this with the Update-MgUser cmdlet from the Microsoft Graph PowerShell SDK.

Giving accounts new email addresses and user principal names isn’t a difficult technical challenge. The likely problems arise in preparation and communication. Isn’t that always the way?

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.

But Practical Considerations Make Potential OME Weakness Not Worth Worrying About

I don’t quite know what to make of the October 14 WithSecure Labs report that Office 365 Message Encryption (OME) uses “a Broken or Risky Cryptographic Algorithm.” I also don’t know why Microsoft continues to use Electronic Codebook (ECB) to cipher message content.

OME, or rather “Microsoft Purview Message Encryption” is included in Office 365 E3 and E5 and other Microsoft 365 plans. An advanced form of OME is also available, but its functionality is not pertinent to this discussion. OME allows Exchange Online users to send encrypted email to literally any other email recipient, no matter what server their mailbox connects to. OME is built on top of Azure Rights Management, so users can protect messages with the default Do Not Forward and Encrypt-Only templates, or they can use custom rights management templates published to Outlook email clients as sensitivity labels.

Inferring Message Content

The problem discovered by the researchers is that a “Malicious 3rd party gaining access to the encrypted email messages may be able to identify content of the messages since ECB leaks certain structural information of the messages.” That certainly sounds like a problem, but the fact is that third parties can only dictate some structural information about emails and not the actual content. Their demonstration of an image extracted from an encrypted message is impressive, but only until you consider that the researchers had full control over the message content and were able to insert the necessary blocks to create the image they displayed. Exposing an image in a protected file makes a nice demo, but it is not the same as being able to extract information from a “real” file selected at random from a set of protected messages.

The practical implications of being able to intercept messages protected by OME is less certain. The researchers say that “an attacker with a large database of messages may infer their content (or parts of it) by analyzing relative locations of repeated sections of the intercepted messages.” The important thing here is that an attacker needs to acquire a large database of messages before they can move to a point where they can infer what the content of any specific message might be. Whether you consider this a practical and potential attack in the wild is up to your judgement. I don’t think it is something to worry about in the real world.

Little Likelihood of Exploitation

My experience is that relatively few messages created by Office 365 tenants use OME protection. Admittingly, even a small percentage of protected messages is a large volume when you consider that Exchange Online processes 9.2 billion messages daily. The counterargument is that the number of protected messages sent by individual tenants or users is usually small.

Some years ago, a conversation with the Microsoft Information Protection team indicated that the percentage of protected messages was in the low single digits. Of those messages, a large number probably remain inside Office 365 and are therefore impervious to interception unless an attacker can comprise the Microsoft 365 infrastructure. If that happens, being able to analyze some protected email to detect patterns that might reveal some potential content is the least of an Office 365 tenant’s problems.

We’re then left with a relatively small amount of messages protected by OME flow out of Office 365 to other mail systems. A potential attacker must therefore work out how to acquire “a large database of messages” to begin inferring what the messages content. Or “Even if specific message would not directly leak information in this way, an attacker with a large body of messages is able to perform analysis of the relation of the repeated patterns in the files to identify specific files. This may lead to ability to infer (parts of) clear text of encrypted messages.” The obvious fact here is that if an attacker can sit on a transmission path from Office 365 to another mail system, they’re likely to capture a vast quantity of unprotected email that can be analyzed and interrogated without any need to decrypt, infer, or otherwise go near protected content.

Microsoft’s Use of ECB

According to the researchers, even though Microsoft paid a $5,000 bounty for discovering the vulnerability, Microsoft’s response was “The report was not considered meeting the bar for security servicing, nor is it considered a breach.” Perhaps Microsoft believes that the practicality of exploitation is so low that the flaw doesn’t merit changing their code.

Interestingly, the researcher points out that the Microsoft Information Protection (MIP) ProtectionHandler::PublishingSettings class has a SetIsDeprecatedAlgorithmPreferred method which says that it “Sets whether or not deprecated crypto algorithm (ECB) is preferred for backwards compatibility.”

The researchers speculate that OME uses this flag to enable ECB rather than the more secure Cipher Block Chaining (CBC) mode.

They also point out that Microsoft’s FIPS 140-2 Compliance documentation explicitly states that “Legacy versions of Office (2010) require AES 128 ECB, and Office docs are still protected in this manner by Office apps.”

What’s weird here is that Office 365 hasn’t supported Office 2010 for years. At first glance, it doesn’t make sense for Microsoft to configure OME to support an ancient legacy version of Office. It would seem to make sense for Microsoft to move from ECB to CBC, but that’s without the benefit of understanding what this would mean in practice for end users. My understanding is that OME uses CBC for non-Office files because there is no reason to support backwards compatibility.

It’s clear from the Open XML format documentation that Office applies compression (Lempel-Ziv) to store documents. The RPMSG “wrapper message” generated by OME is also compressed (I believe that OME uses the Deflate algorithm for this purpose). Logically, compression occurs before encryption. The way compression works ensures that no repetitive patterns or fixed length sequences exist in the file, so the Office documents processed by ECB can’t exhibit the kinds of patterns reported by the researcher. If an attacker captures Office documents, there’s little hope of them being able to infer anything from the document content.

The Net Result

Given the lack of support for Office 2010 within Microsoft 365, it’s logical to ask why Microsoft has not upgraded OME and removed the use of ECB for Office documents. That step might make security researchers happier, but the use of compression in the existing implementation means that it might not make any real practical difference. Overall, the potential for a successful attack on OME-protected email in the wild seems low and the overwhelming percentage of unprotected email seems like a much more lucrative target for attackers.

WithSecure are certainly within their rights to recommend that Office 365 tenants should ignore OME until something better comes long. I disagree. It seems to me that increased use of OME would stop attackers being able to compromise the huge quantity of unprotected email that Office 365 tenants currently send. It’s wonderful to worry about an edge case; the real issue is to protect email in general. And that’s why it still remains so much better to protect confidential email with OME.

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.

Using the Exchange.ManageAsApp Permission with Exchange Online PowerShell

Updated 7 December 2022

With the addition of support for managed identities in V3.0 of the Exchange Online management PowerShell module, developers might be more interested in creating Azure Automation runbooks that use the Exchange Online cmdlets to process data like mailboxes. In this discussion, when I refer to a managed identity, I mean a system-assigned managed identity working within an Azure Automation Account. Essentially, a managed identity is a service principal used to access Azure resources that Azure manages automatically. No access is available to the credentials for the managed identity. Like the service principals for other apps, managed identity service principals can hold permissions to allow them access to resources like apps.

As an example, it’s now easy to connect to Exchange Online in a runbook with a command like:

Connect-ExchangeOnline -ManagedIdentity -Organization office365itpros.onmicrosoft.com 

Exchange Online connects using the managed identity owned by the Azure Automation account that’s executing the runbook.

As noted above, before it can do anything interesting after connecting, the managed identity needs permissions. The essential permission for Exchange Online is Exchange.ManageAsApp, which allows an app to run Exchange Online cmdlets as if the app was an administrator account. Service principals for registered apps and managed identities both need this permission to do useful work with Exchange Online cmdlets.

Some Background

In November 2020, Microsoft announced the deprecation of the Outlook REST API. This was part of a wider effort to move developers away from legacy APIs to the Graph. Microsoft also considers Exchange Web Services (EWS) to be a legacy API, but in this instance, the Exchange team focused on the Outlook REST API, which the Graph Outlook Mail API replaces.

At the same time, Microsoft said that they “removed the Exchange app permission from the Azure portal.” The Exchange.ManageAsApp permission is one of the permissions in the Office 365 Exchange Online API. Microsoft’s action didn’t remove the ability to assign the permission to apps in the Azure AD admin center. It just made the process a little harder.

Assigning Exchange.ManageAsApp

To assign the Exchange.ManageAsApp permission to a registered app, select the app in the Registered Apps blade. Go to API permissions to add a permission as normal. When Azure AD displays the range of permissions to select from, click the APIs my organization uses tab, and then type Office 365 Exchange Online into the search box. Azure AD will find the Office 365 Exchange Online API (Figure 1). Note the application identifier shown here. We’ll need this later.

Now browse the set of permissions in the Office 365 Exchange Online API and select Exchange.ManageAsApp (Figure 2). Make sure that you’ve selected application permissions and click Add permission. When you return to the app details, consent to the assignment, just like you’d do for a Graph API permission.

The registered app can now run Exchange Online cmdlets as an administrator. That’s all well and good, but what about a managed identity?

Managed Identities are Different

Unlike registered apps, managed identities show up under the enterprise apps section of the Azure AD admin center. Open enterprise apps and apply a filter to find managed identities (Figure 3).

Azure AD lists the Azure automation accounts with managed identities. Select the automation account you want to work with. When you access its permissions, Azure AD tells you that: “The ability to consent to this application is disabled as the app does not require consent. Granting consent only applies to applications requiring permissions to access your resources.” In other words, you can’t assign an API to an automation account, or rather the service principal for the managed identity, through the Azure AD admin center.

Instead, you can do the job with PowerShell using cmdlets from the Microsoft Graph PowerShell SDK. Here’s how:

• Note the name of the automation account used with the managed identity. In this example, the account name is “ExoAutomationAccount.”
• Connect to the Graph with the AppRoleAssignment.ReadWrite.All permission.
• Run the Get-MgServicePrincipal cmdlet to populate a variable with the service principal for the automation account. The filter passed to the cmdlet contains the name of the automation account.
• Populate a variable with details of the Office 365 Exchange Online enterprise app. Microsoft installs this app for tenants to allow administrative apps to manage Exchange. The app id for the Office 365 Exchange Online app is always 00000002-0000-0ff1-ce00-000000000000.
• Find the Manage Exchange As Application role in the set held by the Exchange Online application. This role holds the Exchange.ManageAsApp permission, so any app holding the role can use the permission.
• Create the parameters to assign the role to the managed identity.
• Use the New-MgServicePrincipalRoleAssignment cmdlet to assign the role.

Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All
Select-MgProfile Beta
$ManagedIdentityApp = Get-MgServicePrincipal -Filter "displayName eq 'ExoAutomationAccount'"
$ExoApp = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
$AppPermission = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$AppRoleAssignment = @{
"PrincipalId" = $ManagedIdentityApp.Id
"ResourceId" = $ExoApp.Id
"AppRoleId" = $AppPermission.Id
}
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityApp.Id -BodyParameter $AppRoleAssignment

The new role assignment is effective immediately. If you make a mistake, you can remove the assignment with the Remove-MgServicePrincipalAppRoleAssignment cmdlet. Here’s how:

[Array]$SPPermissions = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityApp.Id
$Role = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$Assignment = $SpPermissions | Where-Object {$_.AppRoleId -eq $Role.Id}
Remove-MgServicePrincipalAppRoleAssignment -AppRoleAssignmentId $Assignment.Id -ServicePrincipalId $ManagedIdentityApp.Id

Administrator Role

The final step is to make sure that Exchange Online recognizes the automation account which hosts the managed identity as an Exchange administrator. This is done by assigning the Exchange Administrator role to the automation account’s app in the Azure AD admin center. Figure 4 shows how to add the assignment of the Exchange administrator role to the app owned by an automation account.

If you don’t assign the Exchange administrator role to the automation account’s app, you’ll see an error telling you that the role assigned to the app isn’t supported in this scenario when you execute the runbook. For example:

“The role assigned to application 415e4ba8-635f-4689-b069-22dea1fcfdb3 isn’t supported in this scenario“

Assignment a Small Pain

Perhaps Microsoft under-estimated the continuing need to assign the Exchange.ManageAsApp permission to apps when they made their November 2020 announcement. Although it’s a pain to have to go to PowerShell to assign the permission, it’s something that only needs to happen once, so it’s not too bad. I have other more serious things to moan about inside Microsoft 365.

Learn more about how the Microsoft 365 ecosystem 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.

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.

Archive Mailboxes Return to Exchange Admin Center

Microsoft 365 notification MC433154 (posted 29 August) brought the not-unexpected news that Microsoft is eliminating the listing of archive mailboxes in the Microsoft Purview compliance portal (Figure 1) and transferring sole GUI responsibility for these objects to the Exchange Admin Center (EAC).

Microsoft says that this will simplify the customer experience. We say that the old Security and Compliance Center (which became the Purview portal) was a convenient resting place for archive mailboxes while Microsoft upgraded the EAC. In any case, it’s the right thing to do because archive mailboxes (which have nothing to do with Outlook’s Archive folder) belong in the EAC. You won’t be able to access the archive page in the Data lifecycle management section of the Purview portal from sometime in October 2022.

EAC and Archive Mailboxes

The implementation of the display about information about archive mailboxes is different in EAC, Instead of a dedicated page that lists just user mailboxes with archives, EAC includes the archive status of mailboxes in its Manage mailboxes list. If the status is None, the mailbox doesn’t have an archive. If Active, the mailbox is archive-enabled. EAC includes both user and shared mailboxes in its listing and doesn’t differentiate between mailboxes with enterprise archives and those limited to 50 GB due to the licenses assigned to accounts (Figure 2).

To manage the archive for a mailbox from EAC, select the mailbox from the list to view its properties and go to the Others tab (as in other services). Then select Manage mailbox archive. You can enable or disable the archive mailbox here, but you can’t manage an expandable archive (see below).

After they have an archive, users can move items from their primary mailbox into the archive using drag and drop from Outlook. However, this seldom happens, and default archive tags configured in mailbox retention policies and assigned to mailboxes are responsible for moving most items into archive mailboxes. The ability to move items to the archive Is unique to mailbox retention policies and is a good reason to continue using these policies alongside Microsoft 365 retention policies.

Shared mailboxes that are archive-enabled require Exchange Online Plan 2 licenses.

Auto-Expanding Archives

Enterprise archives are called auto-expanding archives. When they introduced the concept of “bottomless” archives in June 2015, Microsoft told customers that ever-expanding archive mailboxes could continue growing ad infinitum. However, operational and technical realties bit, and Microsoft decided to put a 1.5 TB limit on enterprise archives in 2021. Exchange Online constructs the expandable archive by adding new “storage chunks” (auxiliary mailboxes) to the archive. The storage chunks that form the structure are connected together to form a logical structure. Exchange Online adds new storage chunks to an archive automatically when it detects that the existing storage is 90% occupied.

Even if the organization enables expandable archives, mailboxes don’t automatically use this facility. Instead, an administrator must enable it for a mailbox by running the Enable-Mailbox cmdlet. The first command shown below enables the archive. The archive mailbox must be in place before you can transform it into an expandable archive.

Enable-Mailbox -Identity Michael.King -Archive
Enable-Mailbox -Identity Michael.King -AutoExpandingArchive

If you want to assign an archive mailbox to all mailboxes that aren’t already enabled, you can run a command like this:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -Properties ArchiveStatus | Where-Object {$_.ArchiveStatus -eq "None"} | Enable-Mailbox -Archive

While to ensure that all enabled mailboxes use auto-expandable archives, run a command like this:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -PropertySets Archive | Where-Object {$_.ArchiveStatus -eq "Active" -and $_.AutoExpandingArchiveEnabled -eq $False} | Enable-Mailbox -AutoExpandingArchive

Exchange Server doesn’t support expandable archives. If you plan to move a mailbox back to an on-premises server, you should not enable it for expandable archives.

Reporting Archive Mailboxes

The EAC GUI is acceptable for discovering details about small numbers of archive-enabled mailboxes, but PowerShell is a better option to report details of archive mailboxes. This script finds all the archive-enabled user and shared mailboxes and reports how active each archive mailbox is.

[array]$Mbx = Get-EXOMailbox -PropertySets Archive -Properties DisplayName  -RecipientTypeDetails UserMailbox, SharedMailbox -Filter {ArchiveStatus -eq "Active"} | Sort DisplayName
If (!($Mbx)) { Write-Host "No archive-enabled user or shared mailboxes found - exiting" ; break }
Write-Host ("Processing {0} archive-enabled mailboxes" -f $Mbx.count)

$MbxReport = [System.Collections.Generic.List[Object]]::new()
ForEach ($M in $Mbx) {
  Write-Host "Processing" $M.DisplayName
  $Stats = Get-ExoMailboxStatistics -Identity $M.ExternalDirectoryObjectId -Archive
  [long]$QuotaUsed =  $stats.TotalItemSize.Value.toString().Split("(")[1].Split("bytes")[0]
  [long]$Quota = $M.ArchiveQuota.Split("(")[1].Split("bytes")[0]
  $PercentQuotaUsed = ($QuotaUsed/$Quota).ToString("P")
  $ReportLine = [PSCustomObject][Ordered]@{  
   Mailbox      = $M.DisplayName
   UPN          = $M.UserPrincipalName
   Archive      = $M.ArchiveStatus
   ArchiveItems = $Stats.ItemCount
   ArchiveSize  = $Stats.TotalItemSize.Value.toString().Split("(")[0]
   ArchiveQuota = $M.ArchiveQuota.Split("(")[0] 
   PercentUsed  = $PercentQuotaUsed
   Type         = $M.RecipientTypeDetails
   }
   $MbxReport.Add($ReportLine)  
}
$MbxReport | Out-GridView

The output is stored in a PowerShell list, so it’s accessible by piping the list to the Out-GridView cmdlet (Figure 3) or exporting it to a CSV file, Excel workbook, or HTML report.

As you can see, some mailboxes have an archive quota of 110 GB. This is because a retention policy or hold applies to these mailboxes. At least, that’s what Microsoft says in its documentation. However, several of these mailboxes have only a 100 GB archive quota and they are very much subject to retention policies.

As a quick test, I created some new mailboxes, put them on litigation hold, and enabled them for archives, and then for auto-expanding archives. The mailboxes all received 110 GB archive quotas. I conclude that older mailboxes that received expandable archives stay at the original 100 GB allocation. Perhaps Exchange Online will lift the quota the next time it adds a chunk to expand the archive.

Move Won’t Make a Difference

I doubt many people knew that the Microsoft Purview Compliance portal featured archive mailboxes and the reported move back to EAC won’t make much difference. Archive mailboxes are back where they should have been all along, even if PowerShell is a better way to manage them at scale.

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.

Keeping Group Membership Secret

Customers expressed the desire to hide the membership of Microsoft 365 Groups soon after Microsoft launched Office 365 Groups in November 2014. Microsoft duly shipped the feature in early 2015.

Many scenarios exist to cloak the membership of a group. Some educational establishments don’t like revealing the full membership of classes; corporations engaged in confidential activities (like a merger and acquisition project) might like to hide the fact that external advisors have joined an internal team. Other organizations like to hide the membership of some committees, and so on.

Creating Groups with Hidden Memberships

A Microsoft 365 group with hidden membership can only be created with PowerShell. This code creates a new group with the New-UnifiedGroup cmdlet and adds some members and a second owner with the Add-UnifiedGroupLinks cmdlet. The account that runs the New-UnifiedGroup cmdlet automatically becomes an owner:

New-UnifiedGroup -Alias "Super.Secret.Team" -PrimarySmtpAddress Super.Secret.Team@office365itpros.com -HiddenGroupMembershipEnabled:$True -Name "Super Secret Team" -DisplayName 'Super Secret Team'
Add-UnifiedGroupLinks -Identity Super.Secret.Team -LinkType Member -Links Sean.Landy, Terry.Hegarty, James.Ryan, Jackson.Hoare, Jane.Sixsmith, Michael.King
Add-UnifiedGroupLinks -Identity Super.Secret.Team -LinkType Owner -Links Michael.King

When a group has hidden membership, it means that Exchange Online only reveals details of the group membership to its members (through client interfaces) and tenant administrators (through administrative interfaces). This statement isn’t 100% true. As shown in Figure 1, when users browse an address list, they can’t see the group membership, but they can see one of the group owners, who are also group members. This means that part of the group membership is exposed.

Distribution lists also support hidden membership. Like Microsoft 365 Groups, you can set hidden membership when creating a new distribution list or you can hide membership for an existing distribution list. For example, this command creates a new distribution list with hidden membership.

New-DistributionGroup -Alias "SecretDL" -Name "Secret Distribution List" -DisplayName "Secret Distribution List" -PrimarySmtpAddress SecretDl@office365itpros.com -HiddenGroupMembershipEnabled:$True

When a Microsoft 365 group has hidden membership, its membership cannot be revealed by updating group properties. The Set-UnifiedGroup cmdlet doesn’t support updating the HiddenGroupMembershipEnabled setting. However, you can restore visible membership for a distribution list. For example:

Set-DistributionGroup -Identity SecretDL -HiddenGroupMembershipEnabled:$False

And if you make a mistake, you can reverse course and hide the membership again.

Set-DistributionGroup -Identity SecretDL -HiddenGroupMembershipEnabled:$True

Remember that Exchange Online must generate updated OAB files for Outlook to download and apply before changes to membership visibility become completely effective in Outlook desktop.

Sensitivity Labels and Hidden Group Privacy

Only a private Microsoft 365 group can have hidden membership. PowerShell and the other administrative interfaces will stop administrators changing the access type from private to public. Another thing to consider is what sensitivity label the new group should receive. Remember that sensitivity labels can control the privacy type for a group. If you assign a sensitivity label that applies container management settings, the access type set by the label must be Private. If not, you’ll see an error.

Figure 2 shows the group settings in the Microsoft 365 admin center. The group sensitivity label is Confidential Access, which is fine because it sets the access type to Private. Any attempt to use a label that sets the access type to Public will result in a cryptic error message that’s not very clear.

In addition, attempts to change the privacy (access type) through this interface won’t work because “visibility of a group with hidden membership cannot be updated.”

Hiding Groups from Address Lists

The “don’t show team email address in Outlook” setting controls the group’s HiddenFromAddressListsEnabled property. By default, the value of the property is False, meaning that Exchange Online includes the group in its address lists, including the Offline Address Book (OAB) and Global Address List (GAL). The effect of choosing this option is to stop users finding an entry for the group (and therefore being able to see its SMTP address) when they browse Outlook address lists. For example, there’s no sign of the group in the Outlook address book (Figure 3).

To make the group visible in address lists, update the setting in the admin center or run Set-UnifiedGroup to update the property:

Set-UnifiedGroup -Identity Super.secret.team -HiddenFromAddressListsEnabled $False

Remember that hiding the SMTP address of a group doesn’t stop people from sending messages to the group. It’s a visual block, not a hard block imposed in the transport service. If you want to restrict the people who can send messages to a group, use the AcceptMessagesOnlyFromSendersOrMembers property. This example stops the group accepting messages from anyone but group members.

Set-UnifiedGroup -Identity Super.secret.team -AcceptMessagesOnlyFromSendersOrMembers "Super.Secret.Team@Office365itpros.com"

Teams and Hidden Membership

Teams supports Microsoft 365 Groups with hidden membership. To team-enable our group, use the Add Teams option in the General tab of the group’s properties in the Microsoft 365 admin center. Alternatively, connect to Teams with PowerShell and run the New-Team cmdlet with the GroupId parameter pointing to the Azure AD identifier for the Microsoft 365 group:

Connect-MicrosoftTeams
New-Team -GroupId (Get-UnifiedGroup -Identity Super.Secret.Team | Select-Object -ExpandProperty ExternalDirectoryObjectId)

As only team members can access a team, they’re the only ones who can see the membership.

Impact on Reporting

Because administrative interfaces always have access to group membership data, setting group membership to be hidden might or might not affect the data returned by PowerShell cmdlets and Graph API requests. For example, the script to generate a report of Teams membership includes hidden membership because the code accesses each team to retrieve its membership. However, because the Graph TransitiveMemberOf API doesn’t include hidden membership in its results, the script to generate a report of membership of Microsoft 365 Groups (and Teams) doesn’t include groups and teams with hidden membership data.

Hidden is Good for Some

I don’t come across many situations where tenants use groups with hidden memberships and Office365ITPros.com hasn’t had many questions about this topic over the years. The feature is there, it works, and it solves a problem for some. I guess that’s all we need to say about it.

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.

Big Red Switch Moved to Off

I don’t know whether this happened somewhere in the bowels of a Microsoft data center, but I imagined Greg Taylor flipping a big red switch marked Basic Authentication for Exchange Online at midnight on October 1 (Figure 1). Perhaps he even sipped a glass of red wine as he started the final process of removing the bulk of dangerous connectivity from Exchange Online (elegantly described during his recent MEC session). Given the effort expended over the last three years, he deserved a drink. Or maybe two.

Nothing Happened – Yet

Nothing happened after the switch moved to off. The sky didn’t fall and birds continued to sing. No small animals were harmed by Microsoft’s campaign to remove basic authentication for seven connection protocols. At least, nothing happened for the millions of Microsoft 365 tenants that have already embraced modern authentication.

Of course, some tenants are living on borrowed time. These organizations opted for the three-month last-gasp delay granted by Microsoft to those who needed a little extra time to prepare. I hope these folks make good use of the time between now and January 1, 2023.

For those who didn’t seek a postponement and basic authentication remains in use, they could run into issues at any time now. October 1 marked the point when Microsoft will start to disable basic authentication permanently for the affected protocols in tenants. Given the scale of Exchange Online (remember the statistics revealed at MEC), it takes time to work through the tenants now eligible to be turned off. You don’t know when Microsoft will enforce the block on basic authentication within a tenant. The process is automatic and anonymous. No one gets to choose when their tenant’s turn comes around.

Some Potential Holes for Tenant to Fall Into

When Microsoft disables basic authentication for a tenant, two outcomes can happen:

• No problems.
• Stuff stops working.

Organizations that paid attention to the warnings sounded by Microsoft and amplified by many commentators should be OK. They’ve upgraded clients, updated apps and scripts, and communicated with their users.

Others might not be quite as prepared. Indeed, I suspect that some don’t realize what might happen to them soon. The data presented at MEC (Figure 2) indicated where some problems might lie, including POP3 and IMAP4 clients, mobile devices using Exchange ActiveSync, older versions of Outlook, and apps based on Exchange Web Services (and to a lesser degree, PowerShell).

The key to everything is modern authentication (OAuth2). If clients attempt to authenticate with a simple username and password combination, they’ll fail. In some cases, the fix is simple, as with iOS devices where the mail app profile can be upgraded to use modern authentication. Apple did this automatically for tens of millions of devices when it released iOS 15.6, but devices managed by MDM solutions might still need attention. Or consider an update to Outlook Mobile (yes, I know this is much harder than my trite remark implies).

In other scenarios, a brand new client might be needed. There’s a lot of old POP3 and IMAP4 clients out there, and while some software developers have upgraded their clients, others have not. The same is true for apps that use these protocols to poll Exchange mailboxes for messages.

Users might be annoyed and frustrated to discover that their favorite client can no longer connect, but unless that client supports OAuth, Exchange Online will refuse to allow access to mailboxes (see this Microsoft post for advice on how to solve the immediate “I can’t access my mailbox” problem. by reenabling an access protocol. This is a short-term sticking-plaster solution to buy some time until January 2023.

I hope help desk staff are briefed to know how to deal with people who can’t get their email, a situation that can impact business effectiveness. Tenant administrators won’t be thanked if key staff can’t close deals because of obsolete software.

Multi-Factor Authentication is the Next Step

I’ve been writing about this project for years. Removing basic authentication is a very good thing. You don’t get to vote and it will happen, and when it does, users will be safer from password sprays and other attacks. Do yourself a favor at the same time and protect users with multi-factor authentication (MFA) too. According to Microsoft, only 26.84% of Azure AD accounts are protected with MFA. That’s sad, but look at the changeover from basic authentication as a forcing factor to increase user email security by making people switch to more secure clients. MFA should be part of that discussion.

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.

300K Physical Mailbox Servers

Among the fun and games at the online MEC 2022 conference this week was the revealing of new statistics about Exchange Online, the largest workload within Office 365. The data (Figure 1) is quite staggering in terms of the size of the infrastructure supporting Exchange Online.

Mailboxes – Lots of Mailboxes

Every Exchange Online server is a physical Windows server, and there’s 300,000 of them to support 7.3 billion mailboxes. That’s not a typo. As of April; 2022, the latest number for Office 365 monthly active users is 345 million users (maybe 375 million now). The number of mailboxes might seem surprising, but there’s many other types of mailboxes in use within Exchange Online than a simple user count. The mailboxes include:

• Group mailboxes.
• System mailboxes like arbitration mailboxes.
• Shared mailboxes.
• Archive mailboxes.
• Scheduling mailboxes (used by the Microsoft Booking app).
• Cloud-only mailboxes used to hold compliance data for apps like Teams generated by hybrid accounts and guest users.
• Audit mailboxes used to hold Office 365 unified audit log records.

Many of the mailboxes hold substrate data necessary to support Microsoft 365 services like search, eDiscovery, and compliance processing.

Each mailbox is in a mailbox database within a Database Availability Group (DAG). The DAG keeps three active copies and one lagged copy of each mailbox database. Deploying Native Data Protection protects that 1.4 exabytes of data spanning 42 trillion mail items (messages, calendar items, and so on).

The Joy of MEC

It was nice to be back presenting at a MEC event, even if it was a virtual event. Everything seemed to run smoothly and I only noticed one network hiccup during the sessions I attended. Microsoft has published session recordings on YouTube. Links to the decks and recordings for my sessions are at the end of this post.

I had planned to use PowerPoint Live when presenting my sessions but discovered that this facility isn’t available when presenting using a guest account in another tenant. I had to use the tried-and-trusted method of sharing a screen in the Teams meetings. However, I did see luminaries like Greg Taylor present using PowerPoint Live and enjoyed changing Greg’s slides about the details of removing basic authentication for Exchange Online connection protocols into different languages, including Irish (Figure 2). It’s amazing what cloud translation services can do these days.

Speaking about the campaign to remove basic authentication, it seems like everything is going OK with the possible exception of IMAP4 and POP3 clients and apps. Figure 3 shows some interesting information shared by Greg, this time in English. To put this information in a sharper context, consider the number of Exchange connections and mailboxes listed above.

There still seems to be a lot of connections using basic authentication from these sources that could be surprised when the hammer drops. It’s time to upgrade to clients that use modern authentication like the latest Thunderbird client.

Implement an Authentication Policy

A good suggestion that I heard is that tenants can take control of the switch-off by deploying an authentication policy to block basic authentication to see what apps and clients are effected. If some apps and clients need a little extra time to prepare, you can deploy another authentication policy that allows selective access to specific protocols to those accounts.

The great advantage of an authentication policy is that it blocks incoming connections before any authentication processing happens. In other words, if an attacker attempts a password spray to guess the credentials of an account using a protocol like POP3, the attempt fails immediately if the policy blocks POP3 connections. The attacker doesn’t get the chance to know that credentials work, even if they possess valid account credentials obtained in some manner.

On to TEC for Even More Exchange Online Statistics!

I had a great time talking about how to turbo-charge Exchange Online PowerShell using the Microsoft Graph APIs. What was nice about the session was the number of well-known individuals from the Exchange community in the audience. My sole regret was that I couldn’t mingle with people after the presentation as you can during an in-person conference. I’ll get that at The Experts Conference (TEC) in Atlanta next week. I am really looking forward to the event, even if Greg Taylor will be there (only kidding…)

Exchange PowerShell Examples

During my session about Exchange Online PowerShell and the Microsoft Graph (PPTX below), I published a list of articles for people to check out to learn more. Some people might have missed the information that I posted in the meeting chat, so here it is for everyone (alternatively, read the 110-page PowerShell chapter in the Office 365 for IT Pros eBook).

• Mailbox Cleanup using the Microsoft Graph https://practical365.com/mailbox-clean-up-script/
• Figuring out Graph permissions https://practical365.com/microsoft-graph-api-permission/
• Azure Automation and Exchange Online https://practical365.com/use-azure-automation-exchange-online/
• Azure Automation Managed Identities and Exchange Online https://practical365.com/azure-automation-managed-identity-exo/
• •Azure Automation and Microsoft Graph PowerShell SDK https://practical365.com/microsoft-graph-sdk-powershell-azure-automation/
• License management https://practical365.com/microsoft-365-license-graph-sdk/
• Generate licensing report https://practical365.com/create-licensing-report-microsoft365-tenant/
• Creating a new Azure AD group (and team-enable new group) https://practical365.com/create-new-microsoft-365-group-sdk/
• Basic User management with Microsoft Graph PowerShell SDK https://office365itpros.com/2022/03/24/azure-ad-user-account-powershell/
• Basic group management with Microsoft Graph PowerShell SDK https://office365itpros.com/2022/03/29/azure-ad-group-management/
• Assign Azure AD roles with the Microsoft Graph PowerShell SDK https://office365itpros.com/2022/03/30/azure-ad-role-assignments/
• Ups and downs of connecting to the Microsoft Graph PowerShell SDK https://practical365.com/connect-microsoft-graph-powershell-sdk/

Worked out examples

• Reporting the activity of Microsoft 365 Groups and Teams.
• Reporting user activity across multiple workloads.
• Decrypting SharePoint Online documents protected with sensitivity labels.
• Calculate counts of distribution list members.
• Sending email with the Graph.
• Creating organization contacts in user mailboxes.

PowerPoint Decks and Session Recordings

Admin’s Guide to the Microsoft 365 substrate

Master the Graph for Exchange PowerShell

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.

It’s Good to Have the Microsoft Exchange Conference Back

Twenty-six years ago, I attended the Microsoft Exchange Deployment Conference in Austin, Texas. I brought copies of Microsoft Exchange Server: Planning, Design, and Implementation, the book I’d written about Exchange 4.0 (Figure 1).

The book had been put together quite quickly based on experience of the beta version of Exchange 4.0 and some exposure to the final version released to customers. The conference was a great chance to glean some extra knowledge about Exchange and fill the gaps in the book. I don’t pretend that the 4.0 book was perfect, a fact that the then Exchange product manager Elaine Sharpe expressed to me rather forcefully. Elaine and I made up and she wrote the foreword to my Exchange 5.0 book.

Presenting at MEC

A year later, I presented at the first Microsoft Exchange Conference (MEC) in San Diego, California. Compared to other MEC events, I have no real memories of that conference, but it began a relationship with MEC that’s lasted 25 years. MEC 1998 in Boston evokes strong memories of competition with Lotus Notes and some wild parties. I presented a keynote at MEC 2000 in Dallas (Figure 2) when Windows 2000, Exchange 2000, and Active Directory were the new kids on the block. It was a blast to speak to 8,000 people, even if I couldn’t see past the front row.

Flat Tony

After a hiatus caused by Microsoft marketing dictats and an unfortunate focus on TechEd, Microsoft brought MEC back in 2012. The early days of Office 365 meant that MEC 2012 featured many discussions about mailbox migrations to the cloud. Two years later, the last MEC (in Austin), brought Flat Tony to the scene. Microsoft asked me for copies of all the books I had written about Exchange Server for a display at the conference. Microsoft embellished the display with a cardboard cut-out figure created by placing a photo of my head on top of a body from someone in significantly better shape (Figure 3).

Flat Tony survived MEC and the Exchange development group then took the figure on tour through bars in Austin. Eventually, the figure reached Redmond and subsequently turned up at a couple of MVP summits before meeting its end in Greg Taylor’s wood. Good times!

Sessions at MEC 2022

This week, I will present two sessions at MEC 2022, now renamed the Microsoft Exchange Community Airlift. MECA is a horrible acronym, so MEC will do. My sessions are:

• An administrator’s guide to the Microsoft 365 substrate (September 13, 10AM Pacific).
• Master the Graph for Exchange PowerShell (September 14, 11AM Pacific).

All sessions are run as Teams meetings and recordings will be available on the MEC website afterward.

In-Person Events are Even Better

Happy as I am to present at MEC 2022, I will be even more pleased to travel to Atlanta to attend The Experts Conference (TEC) on September 20-21. There’s nothing quite like an in-person event to get the creative juices going. TEC is close to being sold out, but I think some tickets might still be available.

TEC is a small event that’s quite unlike the large-scale Microsoft events in terms of access to speakers and subject matter experts. It should be a fun gathering. In particular, I’m looking forward to hearing from Alex Weinert, who always reveals some solid data about the current security landscape. His session at the RSA 2020 conference captured the reasons why basic authentication is so bad for email connection protocols. Speaking of which, Greg Taylor will be at TEC to tell people about the progress Microsoft is making in turning off basic authentication for Exchange Online. That should be a fun session. Meantime, I’ll talk about the challenge of mastering the many technologies that make up Microsoft 365. I might not have a perfect answer, but I have some views on the topic.

Conferences Restarting

It seems like conferences are returning to some level of normality, which is nice. After MEC and TEC, the next conference on my list is the European SharePoint, Office 365, and Azure Conference in Copenhagen (November 28-December 1) where I’ll discuss how to manage Teams for success. At least, that’s what the session title says.

I plan not to attend Microsoft Ignite. I can’t get excited about an event that’s succumbed to the same marketing disease that afflicted TechEd. At least MEC allows independent experts to give their view about Microsoft technology, something that’s become much more difficult to do at Ignite because of the lack of speaking opportunities Microsoft makes available to non-Microsoft speakers. While Ignite remains on its current course, it’s just not attractive to me. But at least I have MEC and TEC to look forward to. Rumors exist that MEC 2023 will be an in-person event. That’s something even more pleasant to contemplate.

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.

Five Years On, the Use Case for the Archive Folder is Still Unclear

Generally, I am positive about the changes that Microsoft makes in Microsoft 365. Well, maybe we complain about some of the updates. From time to time, Microsoft throws some curve balls to cause me to scratch my heads. For instance, the time when they decided that it would be a great idea to create Microsoft 365 group for each manager with the manager’s direct reports as the group members. Anyone concerned with privacy could see that was a bad idea. Fortunately, that bright spark fizzled out quickly.

The Odd Archive Folder

Which brings me to Outlook’s strange Archive folder. This appeared in March 2017 and promptly caused massive confusion with Exchange Online’s archive mailboxes.

Microsoft’s support documentation says:

“There are several ways to archive messages in Outlook. The methods that you can use depend on the type of email accounts that you have set up in Outlook.

All accounts have access to an Archive folder. For Microsoft 365, Outlook.com, and Exchange accounts, the Archive folder is one of Outlook’s default folders, like Inbox, Sent Items, and the Deleted Items folder. This folder can’t be deleted. If you use Outlook with an Exchange or Exchange Online account, folder policies such as retention policies apply to the Archive folder.”

And

“Using the Archive button to move messages to the Archive folder doesn’t reduce your mailbox size.”

This description makes it seem like someone thought that it would be convenient to give users an Archive button to move items into the Archive folder as some sort of primitive file-out-of-sight mechanism. I don’t see any trace of the Archive button in my version of Outlook for Windows in either the classic or simplified ribbon. Perhaps competition for space in the ribbon from new-fangled options like Viva Insights caused the Archive button to drop out. Who knows?

After five years of ignoring the Archive folder, I’m still not sure why Microsoft thought it would be a good idea to add an Archive folder to everyone’s mailboxes, but there it lingers today. The only reasons I can see for its existence are:

• The Archive folder is available to mobile clients whereas no mobile client can access items in an archive mailbox because of the lack of protocol support in Exchange ActiveSync or Outlook Mobile.
• Outlook can synchronize items in the archive folder for offline access.

However, these reasons are undermined by the simple fact that keeping items in other folders in the primary mailbox gains the same advantages. There’s no need to move items into a special folder to be able to access them on mobile clients or offline.

The archive folder is like your appendix. It’s there, no one really knows why it is there and you probably wouldn’t miss it if it wasn’t there.

Confusion with the Online Archive

From an administrative perspective, the big issue with the Archive folder is that it muddies the water with Exchange Online’s online archive. The online archive exists as a place where old messages go to rot until the organization is sure that no conceivable reason exists for them to be retrieved. Items in the online archive are indexed and available for eDiscovery. By comparison, the Archive folder is in the primary mailbox and has nothing to do with the online archive.

Items move from the primary mailbox to the online archive (archive mailbox) when:

• A user moves items explicitly using a client like Outlook. This accounts for 0.000000184% of all items that reach archive mailboxes (I made that figure up, but it’s defendable).
• The Exchange Managed Folder Assistant moves items because they have an archive tag assigned by the user or because a default archive tag exists in the mailbox retention policy assigned to the mailbox.

Only Exchange mailbox retention policies include tags with move to archive actions. Microsoft 365 retention policies can remove mailbox items, but they cannot archive the items.

Automatic policy-driven movement of items from primary to archive mailboxes is the right way to keep messages for the long term. The Managed Folder Assistant processes mailbox retention policies (including the move to archive) while a separate assistant applies Microsoft 365 retention policies to other workloads.

Stopping the Backspace Key Archiving Items

One interesting pointer from the support documentation is that if you use the Microsoft 365 apps for Enterprise (Outlook click to run), the backspace key moves the selected item to the Archive folder. I never knew that this happened, but it accounts for why items unexpectedly turn up in the folder. Usually, I just scratch my head and delete the mystery items, but it now seems that I put them there by pressing the backspace key!

To disable this one-click-to-archive behavior, update the system registry to add the DisableOneClickArchive DWORD value at HKEY_CURRENT_USER\SOFTWARE\microsoft\office\16.0\outlook\options. Set the value to 1 to stop the backspace key moving items to the Archive folder (Figure 1).

The backspace key will start to behave properly the next time you restart Outlook. This fix isn’t available for the perpetual versions of Outlook like Outlook 2019 and Outlook 2021. It’s just another example of the gap between the Outlook perpetual and Outlook subscription versions. The fix doesn’t work for the current beta version of the Outlook Monarch client, which merrily moves items to the Archive folder with the backspace key. Oddly, OWA doesn’t move items with the backspace key.

No Joy in Archive Folder

No good reason exists for the Outlook Archive folder. It is what it is and is probably going to persist for the foreseeable future. The best thing to do is to ignore the folder, that is, after you stop Outlook putting items into the Archive folder with the backspace key.

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.