October 14 2025 is a Big Day for Exchange Server

On October 14, 2025, Exchange Server 2019 reaches its formal end-of-life. The same is true for Exchange Server 2016 and the only supported version of an Exchange on-premises server is Exchange Server Subscription Edition (SE). No cataclysmic event will happen on October 18, and servers will continue to work as before and not burst into flames spontaneously, but the transition to subscription-based licensing is a big event in the 29-year history of Exchange Server (to date).

To be fair to Microsoft, they have made the technical aspect of the upgrade to Exchange SE very simple. Exchange SE is essentially the same as Exchange 2019 CU15 with some extra tweaks. I’ve only heard of minor difficulties during server upgrades. The biggest issue customers seem to have is understanding exactly what licenses they need to run SE (the same as Exchange 2019), especially in hybrid environments where the organization has Microsoft 365 licenses and there is a very small (but important) presence on-premises.

Moving to Cloud First Identity

Speaking of the on-premises presence, Microsoft released its Guide for Cloud-First Identity Management (guidance for IT architects) to lay out principles for transferring the Source of Authority (SOA) for user and group management from Active Directory to Entra ID in what Microsoft calls a “phased, low-risk migration path” to minimize the use of Active Directory.

There are many threads involved here. Organizations want to improve their security posture and remove a dependency on Active Directory that might be exploited by attackers. Moving as much as possible to Entra ID makes sense from an administration perspective too because better tools and APIs are available for that platform. Microsoft wants customers to move to Entra ID not only to improve security but also to enable a market for its Entra premium licenses and products, like ID Governance. Apps that depend on Active Directory for authentication are the usual blocker because these apps must be upgraded to authenticate with Entra ID, and sometimes there isn’t the knowledge or drive to do this work.

Microsoft can encourage the move to cloud-first identities by helping organizations to move system objects like users and groups to Entra ID. Exchange Server has a big influence over Active Directory. Exchange 2000 was the first enterprise application to exploit Active Directory (based in many ways on the Exchange 5.5 X.500 Directory Store) and the two have stayed in lockstep since. Moving mail-enabled recipients like accounts with mailboxes, contacts, public folders, and groups from on-premises to the cloud enables the removal of the last Exchange Server, unless one is needed to provide SMTP routing for apps and/or devices.

The HVE Conundrum

Speaking of SMTP routing, last year I wrote about Microsoft’s High Volume Email (HVE) and Email Communication Services (ECS) solutions. Both are based on Exchange Online. In an attempt to clarify the roles of the two products, Microsoft removed the limited ability to send email to external recipients from HVE and points customers who want to send large quantities of email outside their tenant to ECS.

HVE is still in preview with general availability now scheduled for March 2026. Microsoft posted the latest update five months ago to say that support for Basic authentication would persist in HVE until September 2028. The move is indicative of the pressure from customers because of the issues involved in upgrading apps and devices to use modern (OAuth 2.0) authentication. I’m not sure that the new date is feasible because I hear that many organizations have multi-function devices that use SMTP to send email via Exchange Online that have zero chance of being upgraded. Will customers cave in and junk these devices or will more pressure go into Microsoft to extend the retirement date for basic authentication even further. We shall see.

Auto-Archiving for Exchange Online

On October 7, Microsoft announced auto-archiving for Exchange Online, due to be rolled out to commercial tenants later this month and into the government cloud in November 2025. Archiving has been around since Exchange 2010 and Exchange retention policies can configure a move to archive action for items after they reach a certain age (still an unsupported action for Microsoft 365 retention policies).

The new feature moves the oldest items from user mailboxes to their archive mailboxes when mailboxes become 90% full. For most Exchange Online mailboxes, that point is reached when mailboxes use 90 GB of the normal 100 GB quota. The idea is that “threshold-based” archiving is more proactive and effective than when the Managed Folder Assistant only moves items based on date. It seems like a good idea and I’m looking forward to seeing it in action (not that my mailbox is close to 90 GB).

Update: After a bunch of adverse comments, Microsoft has paused the introduction of auto-archiving to do some more preparatory work.

Two Types of Contacts

You might not know this, but Exchange Online supports two types of contact object. The MailContact object is a mail-enabled object (for example, every guest account has a matching mail contact object), and the Contact object is not. Microsoft has decided to deprecate the Contact object from December 2025. I don’t think this should cause any disruption because as far as I can tell, Contact objects are vestiges of long-forgotten synchronization with on-premises Exchange.

Don’t use the PowerShell example from the article to check your tenant for Contact objects. Always use server-side filtering, so the right command is:

Get-Contact -RecipientTypeDetails Contact -ResultSize Unlimited

On the other hand, who cares if a single PowerShell command isn’t as fast as it can be? You’ll only run it once.

Severe Limitations to be Applied to Outbound Email from MOERA Domains

On August 20, 2025, Microsoft announced their latest step to limit misuse of Exchange Online by spammers by limiting the ability of mailboxes with primary SMTP addresses based on a MOERA (Microsoft Online Exchange Routing Address) to send email to external recipients. For years, spammers have created Microsoft 365 tenants and promptly used the tenant to send email. New tenants come with a default sub-domain in the onmicrosoft.com domain, like spamforus.onmicrosoft.com (a MOERA domain).

New mailboxes created in the domain receive primary SMTP addresses based on the MOERA domain, like John.Smith@spamforus.onmicrosoft.com. All of this is deliberate and intended to allow new tenants to be able to send email. However, spammers take advantage of Microsoft’s email routing infrastructure to share their content with anyone they can reach. The consequence is that onmicrosoft.com domains have poor reputations, so much so that many tenants block all email from onmicrosoft.com domains to reduce the amount of spam that reaches user mailboxes.

Microsoft has acted elsewhere in Microsoft 365 to limit the communication horizon for trial tenants by blocking federated Teams chat. Receiving an unwanted chat from some unknown external sender is the rough equivalent of receiving email spam. It’s a distraction and interrupts real work, so actions to limit unwanted communications is always welcome.

In this case, Microsoft will introduce a new throttling restriction to limit tenants that use MOERA domains to 100 external recipients per 24-hour rolling window. That’s very restrictive because the limit applies to email sent across an entire organization. Once the threshold is reached, the Exchange transport system refuses to accept more outgoing email and responds to the sender with a non-delivery notification with a 550 5.7.236 code.

Throttling Starts in October 2025

As is normal when Microsoft introduces a new email send threshold for Exchange Online, the new limit will roll out from October 15, 2025, starting with trial tenants and slowly progressing through small and medium tenants until the final step on June 1, 2026, when the limit applies to tenants with more than 10,000 accounts with paid Exchange licenses (“paid seats”).

The solution to avoid throttling is to acquire a regular domain and add it as an accepted domain for Exchange Online in the Microsoft 365 admin center (Figure 1). Sometimes these domains are referred to as “vanity” domains because they become part of an organization’s branding strategy, much like we use the office365itpros.com for email and this site.

I can’t imagine running a Microsoft 365 tenant with more than 10,000 accounts that doesn’t use a regular domain. It’s not as if acquiring a domain is expensive. Many cost less than $50/year from a domain registrar like Godaddy.com or WordPress.com.

Finding MOERA Senders

Microsoft recommends using the message trace facility to find e mail sent using a tenant’s MOERA domain. That’s certainly one way to approach the problem, but it won’t reveal all the problem mailboxes. A better idea is to use the Get-ExoMailbox cmdlet to search for mailboxes whose primary SMTP address uses the MOERA domain. This code shows how to look for user, shared, and group mailboxes that need to have their primary SMTP address updated to a regular domain. The code excludes mailboxes created for accounts in other tenants in a multi-tenant organization.

Get-EXOMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, GroupMailbox | Where-Object {$_.PrimarySmtpAddress -like "*.onmicrosoft.com*" -and $_.PrimarySMTPAddress -notLike "*#EXT*"} | Sort-Object DisplayName | Format-Table DisplayName, PrimarySmtpAddress, RecipientTypeDetails -AutoSize

DisplayName               PrimarySmtpAddress                         RecipientTypeDetails
-----------               ------------------                          --------------------
"Popeye" Doyle            Popeye.Doyle@o365maestros.onmicrosoft.com   UserMailbox
Adele Vance               AdeleV@o365maestros.onmicrosoft.com         UserMailbox
Alain Charnier            Alain.Charnier@o365maestros.onmicrosoft.com UserMailbox
Break Glass               Break.Glass@o365maestros.onmicrosoft.com    UserMailbox
Buddy Russo               Buddy.Russo@o365maestros.onmicrosoft.com    UserMailbox

Later, the code can be used to find the affected mailboxes before updating their primary SMTP address with a new address belonging to the regular domain. For example, if the new domain is Beachdums.com, the command to update a mailbox is something like this:

Set-Mailbox -Identity Buddy.Russo@o365maestros.onmicrosoft.com -WindowsEmailAddress Buddy.Russo@beachdums.com

To ensure that messages addressed to the previous address can be delivered, Exchange Online keeps the address in the EmailAddresses property of the mailbox.

The Microsoft article contains other points that need to be attended to after switching domains. None of these are difficult tasks, but detail is important.

Good Change

The battle against spam is longstanding and permanent. Microsoft is closing as many holes as possible to make Exchange Online a poor host for spammers to target. Closing off the MOERA hole is a good step forward that shouldn’t cause too much pain for legitimate tenants. That is, if you don’t use MOERA domain addresses for outbound email.

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.

Cleaning Up Obsolete Mobile Devices is Always a Good Idea

After publishing the article about the removal of mobile device management settings for users from OWA and the new Outlook, I was contacted by several people to ask should they clean up the obsolete devices that exist for so many mailboxes.

Generally speaking, I am all for removing clutter. Cleaning out unwanted data is a good thing. Just ask any of the Copilot tenants who struggle with digital debris (old, unwanted, inaccurate, and misleading information stored in Microsoft 365) that corrupt Copilot responses to user prompts. Removing some old device partnerships is not in the same category as cleaning up a bunch of old files from SharePoint Online and OneDrive for Business, but the same principle applies.

Mobile Device Partnerships with Mailboxes

When a mobile device begins to synchronize information from Exchange Online, it creates a partnership between the device and the target mailbox. The Get-MobileDevice cmdlet lists active partnerships. If you run the cmdlet without any parameters, it returns all the partnerships in the tenant. That’s not a great idea in anything other than a demo tenant, but I’ve seen people advising others that this is the way to go.

It’s better to run Get-MobileDevice to check the partnerships for a mailbox (which is what happens to populate the set of devices shown by OWA and the new Outlook). This is the command I use:

[array]$Devices = Get-MobileDevice -Mailbox James.Ryan@office365itpros.com

The information returned by the cmdlet reveals a lot about the device. Here’s a snippet:

FriendlyName            :
DeviceId                : C05A87A5DE4F468DA2399763634D4686
DeviceImei              :
DeviceMobileOperator    :
DeviceOS                : iOS 18.6 22G86
DeviceOSLanguage        :
DeviceTelephoneNumber   :
DeviceType              : Outlook
DeviceUserAgent         : Outlook-iOS/2.0
DeviceModel             : Outlook for iOS and Android
FirstSyncTime           : 14/12/2022 17:01:58
UserDisplayName         : Tony Redmond
DeviceAccessState       : Allowed
DeviceAccessStateReason : DeviceRule
DeviceAccessControlRule : Outlook for iOS and Android (DeviceModel)
ClientVersion           : 1.0
ClientType              : Outlook

Some properties don’t have values. While I can’t be certain why this is so, it’s likely because of the changing focus within Microsoft to device management. Intune is the preferred solution now, so Exchange mobile device management is limited to what’s needed for Exchange and devices to synchronize. However, there’s enough here to confirm that it is an iOS device running Outlook for iOS and that the user first connected the device to their mailbox in December 2022.

Getting Device Statistics

What’s missing from the partnership information is any indication of activity. That information comes from the Get-ExoMobileDeviceStatistics cmdlet (use Get-MobileDeviceStatistics for on-premises mailboxes). Device statistics show the last time the device synchronized with the mailbox:

LastPolicyUpdateTime               : 15/08/2025 02:52:24
LastSuccessSync                    : 15/08/2025 10:32:27
LastSyncAttemptTime                : 15/08/2025 10:32:27
MailboxLogReport                   :
NumberOfFoldersSynced              : 0
Status                             : DeviceOk

Again, there are many properties that are not populated or don’t contain useful information. For instance, the Status property reflects the state of the device as known to Exchange the last time synchronization occurred. The device could be lost, stolen, or wrecked. The important property is LastSuccessSync, the timestamp for the last successful synchronization. It’s reasonable to use the timestamp as an indicator of activity. If a device hasn’t synchronized in a year (or less), it’s likely an obsolete mobile device. In many cases, people replace devices and never remove the old device, leaving an accumulation of obsolete devices to build up.

Cleaning up the Mess with PowerShell

When users don’t clean up, it’s up to administrators to swing into action. Some PowerShell will do the trick. To illustrate the point, I wrote a script (downloadable from the Office 365 for IT Pros GitHub repository) that:

• Finds all user mailboxes.
• Checks each mailbox for device partnerships.
• Checks each device for the last synchronization time.
• If the device hasn’t synchronized in over a year (customizable threshold), note it as an obsolete device.
• Report what’s been found and ask the administrator if the obsolete devices should be removed. As you can see from Figure 1, some of the devices haven’t synchronized in years. The entry for Outlook for Mac is there because that client uses Microsoft synchronization technology to fetch information from Exchange Online, just like Outlook for iOS and Android do.
• Clean up the old devices with the Remove-MobileDevice cmdlet.

The script isn’t very complicated and took less than an hour to write in front of the TV (my excuse for any errors). Feel free to amend the code to suit your purposes. The script should run with on-premises Exchange if you replace Get-ExoMailbox with Get-Mailbox and Get-ExoMobileDeviceStatistics with Get-MobileDeviceStatistics.

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.

Unverified Sender Visual Marker to Warn of Potential Problems

It’s easy to forget details of the reports about new features that appear in the Microsoft 365 message center, especially when a delay occurs between the expected availability date and when the feature appears in plain sight. This is the case with MC1112452 (10 July 2025, Microsoft 365 roadmap item 491471), which reports the arrival of a new visual indicator in Outlook mobile to highlight messages from unverified senders. The indicator doesn’t mean that the message contains spam or malware; just that its properties are unexpected in a way that might be problematic.

I knew about the feature and had read that mid-July 2025 was the scheduled rollout date. Alas, after that I forgot about unverified visual indicators until a bunch of messages were tagged on August 18 (Figure 1).

MC1112452 says that the new visual warning “aligns with existing functionality in Outlook for desktop and web, bringing a consistent experience across platforms.” Later, the text adds “This feature is available by default when the unverified signal is received by the service.” The support documentation notes “If the message is suspicious but isn’t deemed malicious, the sender will be marked as unverified to notify the receiver that the sender may not be who they appear to be.”

No administrative controls exist to enable or disable the marking of unverified senders. This seems like a pity because external mail tagging, which is another marking applied to inbound messages by Exchange Online, can be turned off or on. The same is true for the first contact safety tip, which can be disabled through the anti-phishing policy actions in the Microsoft Defender portal.

Message Headers and Visual Markers

After examining the headers of several unverified messages, it seems like if the Exchange Online transport service determines that an inbound message can’t be fully verified in terms of the normal tests it applies like SPF, DKIM, and DMARC, the service marks the message as unverified, and users see the warning alongside the message in the message list.

For example, Figure 2 (generated by the Message Header Analyzer) shows that Exchange was unable to check the DKIM status for a message, perhaps because DKIM configuration error in DNS or the email is routed through a third-party mail hygiene system like Mimecast that must be configured in a certain manner for DKIM to work properly.

Same Warnings in other Outlook Clients

As noted above, the functionality now implemented in Outlook mobile matches what users see in Outlook classic, OWA, and the new Outlook for Windows (adjusted to match the UX of the client).

The interesting thing is that Outlook only displays the unverified sender warning in the message list for the first message in a thread. If you reply to an unverified sender, the warning is still present, but only for that message. Any subsequent messages received from that sender are not highlighted, even if the same issues persist with DKIM etc. Perhaps the logic here is that if you engage in an email conversation with a sender, that person is verified by your action and Outlook no longer considers them to be unverified. It’s the best theory that I have to explain what I see happen.

Most Unverified Senders are OK, and Then There’s a Bad One

Marking email coming from unverified senders is a good idea. In many cases, a perfectly simple reason exists for why the verification checks fail and the sending system can quickly adjust their configuration to address the problem. In others, a user could receive a message that’s an attempt to impersonate someone else. Hopefully, messages from attackers will be intercepted by Exchange Online Protection, Microsoft Defender for Office 365, or whatever anti-malware service is deployed, but it’s nice to have another check. Just in case.

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.

Microsoft to Remove Mobile Device Management Options

Message Center Notification MC1130607 (7 Aug 2025) announces that Microsoft plans to remove the Mobile Devices section (Figure 1) from the Settings options available in OWA and New Outlook for Windows. Removal will commence starting on September 9, 2025, and is due to be complete in all tenants by October 9, 2025.

According to Microsoft, the change “simplifies device management and aligns with modern tools that offer more robust controls for administrators and end users.” From a user perspective, the biggest impact is that they will no longer be able to remove mobile devices linked to their account. I don’t think many users are very good at cleaning up old devices, so this aspect might not be noticed.

I’m in the category of people who don’t clean up old devices. Part of the problem is that the information presented in OWA settings isn’t very helpful because it simply lists “Outlook” as the device name. Including the device O/S, which is available for a device (Figure 2), would make it easier to identify unused devices.

In any case, this doesn’t matter any more because the options to manage mobile devices will disappear from OWA and the New Outlook soon. What people might miss more is the ability to wipe lost or stolen devices.

Other Options for Users to Disable or Wipe Mobile Devices

Microsoft points out that devices can still be managed through the device list available in the My Account portal (Figure 3). The portal lists all devices that are registered to the user and only allows users to disable a mobile device. This means that the device is blocked from accessing any tenant resources. It is not a device wipe and any sensitive information present on the device remains accessible if someone can get past whatever security methods are used to sign into the device.

Microsoft also points out that administrators can initiate a remote wipe for a registered device through Intune Endpoint Manager. The issue here is that someone who’s lost a device that contains sensitive data often wants an immediate wipe instead of waiting for an administrator to act.

Options also exist for a device owner to use vendor tools to remote wipe a device (iOS or Android).

Mobile Device Management in EAC

Microsoft doesn’t say anything about the mobile device management options in the Exchange admin center (EAC) or the PowerShell cmdlets that underpin mobile device management in both EAC and OWA (here’s an example of using the cmdlets to create a report of registered devices).

EAC has a mobile devices section, but that only deals with access and mailbox policies. Management of devices for a specific user is done by selecting the mailbox and choosing the manage mobile device link from mailbox properties (Figure 4). Care must be taken to select the correct target device before performing a remote wipe as it’s all too easy to select an old or inactive device.

A Justified Change

I’m unconvinced that this change simplifies device management, but I’m sure that Microsoft telemetry probably tells a tale of poor usage of mobile device management by users through OWA and the new Outlook. If that is the case, it’s reasonable for Microsoft to reduce their engineering and support costs by removing these options from the clients and push the responsibility for remote wipes to administrators. The fact that O/S vendors have options to disable and wipe devices gives additional justification for the change.

What’s clear is that tenants should give users clear and precise instructions about what they should do to secure sensitive information should a mobile device be lost or stolen. If you have this kind of advice, it’s time to update it to reflect the new reality.

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 insights updated monthly into what happens within Microsoft 365, why it happens, and what new features and capabilities mean for your tenant.

Problems with the Connect-IPPSSession Cmdlet in Azure Automation

Earlier this week, I discussed how to create a Microsoft 365 retention policy for shared mailboxes. In that article, I noted that additional processing would be needed to keep the retention policy updated as new shared mailboxes are created, mailboxes deleted, and even the conversion of user mailboxes to shared mailboxes and vice versa. This is the kind of scheduled background processing that is well suited to Azure Automation.

At least, that’s what I thought when I started to write the PowerShell script to do the work. The code to run interactively is simple to write. All the problems arise when making the code work in an Azure Automation runbook. The root problem is that the cmdlets in the security and compliance module (the ones accessed by running the Connect-IPPSSession cmdlet) don’t support managed identities like the main Exchange Online management modules does.

Support for managed identities makes running Exchange Online management cmdlets in an Azure Automation runbook a straightforward exercise. Care must be taken to ensure that the service principal for the automation account has the Exchange administrator role and is assigned the Manage Exchange as Application permission. After that, the connection with a managed identity works without a flaw.

The problem is that the developers who maintain the Security and Compliance module haven’t done the work to support managed identities. Microsoft publishes guidance for app-only access for unattended scripts, but the information doesn’t address the environment where Azure Automation runbooks execute. At least, I’ve had zero luck with any of Microsoft’s recommendations.

Back to PowerShell Credentials

Much to my disgust, I had to revert to account credentials passed in a PowerShell credential object. Not only does this seem like the kind of thing we did ten years ago, it means that you can’t use an account that is enabled for multifactor authentication. The only saving grace is that the credential object can be saved in the automation account and doesn’t need to be hardcoded in the script. My doubts were somewhat assuaged by using a long and complex password (Figure 1).

The stored credential can be retrieved in a runbook using the Get-AutomationPSCredential cmdlet and passed to the Connect-IPPSSession cmdlet with the Credential parameter. Here’s the code from the script that checks if the code is running interactively or not. You can see that Connect-ExchangeOnline and Connect-IPPSSession cmdlets run because access is needed to fetch details of shared mailboxes and to update the retention policy.

If ([Environment]::UserInteractive) { 
    # We're running interactively...
    Write-Host "Script running interactively... connecting to Exchange Online PowerShell" -ForegroundColor Yellow
    [array]$Modules = Get-Module | Select-Object -ExpandProperty Name
    If ("ExchangeOnlineManagement" -Notin $Modules) {
        Write-Output "Connecting to Exchange Online..." 
        Connect-ExchangeOnline -showBanner:$false 
    }
    Write-Output "Connecting to Security & Compliance Center PowerShell..." 
    Connect-IPPSSession -ShowBanner:$false
} Else { 
    # We're not, so likely in Azure Automation
    Write-Output "Running the update retention policy for Microsoft 365 shared mailboxes in Azure Automation"
    # Fetch the account credentials to use
    $O365Cred = Get-AutomationPSCredential -Name "AzureExchangeOperations"
    Connect-ExchangeOnline -Credential $O365Cred -DisableWAM
    Connect-IPPSSession -Credential $O365Cred
}

The Need to Disable Windows Account Manager

The Connect-ExchangeOnline command uses the DIsableWAM parameter to disable Windows Account Manager. WAM is enabled by default from Exchange Online Management V3.7 onward and must be disabled in environments where normal interactive authentication is not possible. This fact is not widely known. WAM can also be used with the Microsoft Graph PowerShell SDK, but it’s not the default.

If a script only needs to run Connect-IPPSSession without first connecting to Exchange Online in a non-interactive environment, the call to Connect-IPPSSession should include the DisableWAM parameter. Of course, if you only need to connect to Exchange Online, use a managed identity.

Updating the Retention Policy

After solving the connection issue, the rest of the code was simple enough:

• Find the current set of shared mailboxes with Get-ExoMailbox.
• Find the set of shared mailboxes covered by the retention policy with the Get-RetentionCompliancePolicy cmdlet. It’s important to include the DistributionDetail parameter to force the population of targeted locations.
• Add shared mailboxes that aren’t covered by the retention policy.
• Remove any locations that aren’t shared mailboxes (deleted mailboxes or shared mailboxes converted to be user mailboxes).
• Update the retention policy with the Set-RetentionCompliancePolicy cmdlet.
• Remove Exchange MRM retention policies from the new shared mailboxes.

You can download the complete script from the Office 365 for IT Pros repository. Figure 2 shows a successful runbook in Azure Automation. The only thing to do is to add the runbook to an Azure Automation schedule so that it runs at an appropriate interval. Weekly should be sufficient.

Consistency Would be Nice

It would be nice if all the Microsoft 365 PowerShell modules supported managed identities and Azure automation in a constant and predictable manner. The priorities of different engineering groups means that this is not the current case. We can but hope that the situation will improve over time.

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.

If a Tenant Has Microsoft Defender for Office 365, Its Shared Mailboxes Need Licenses

When discussing the need to license Exchange Online shared mailboxes, the usual answer is that Exchange Online Plan 2 licenses are needed when shared mailboxes have an extended quota (100 GB instead of 50 GB), an archive mailbox, or are on litigation hold. In other areas of functionality, like Microsoft 365 retention policies, Microsoft makes it clear that no licenses are needed unless premium features like auto-label policies or adaptive scopes are used.

The usual line taken by Microsoft for licensing shared mailboxes is anchored on the features available in Exchange Server. For example, basic retention processing doesn’t require licenses because Exchange Server includes similar retention policies. But Exchange Server doesn’t support adaptive scopes, so use of that feature creates the need for licenses.

Microsoft Defender for Office 365 Plan 1 and Plan 2

This brings me neatly to the question of licensing shared mailboxes for Microsoft 365 Defender for Office 365 (MDO), an advanced version of Exchange Online Protection (EOP) that offers significantly better protection against threats communicated in email. MDO is available in two plans: MDO Plan 1 for small to medium businesses and included in SKUs like Microsoft 365 Business Premium, and MDO Plan 2, which is targeted at enterprises but can be bought and deployed by SME tenants.

From an enterprise perspective, the thing to remember is that MDO Plan 2 is only included in E5 SKUs like Microsoft 365 E5 (see this chart for more information). Figure 1 shows the Threat Analytics feature licensed by MDO Plan 2.

The MDO service description says that shared mailboxes in MDO Plan 1 tenants must have licenses if the mailboxes “benefit from Defender for Office 365 protections.” No further guidance is given to define how shared mailboxes benefit from MDO but given that MDO includes features like Safe Attachments and Safe Links, you could say that any shared mailbox that receives email from external senders benefits from malware scanning and threat protection performed by MDO. And because any shared mailbox can send and receive email, Microsoft considers that all shared mailboxes need MDO licenses.

The situation is simpler for enterprise tenants because the guidance here is that MDO licenses are required for “All shared mailboxes on the tenant.” In effect, this means that any Microsoft 365 tenant that implements the features licensed by Microsoft Defender for Office 365 Plan 2 (see the service description) because they have acquired some E5 licenses must license all shared mailboxes for MDO. In fact, the text of the Microsoft Defender for Office 365 service description goes on to say that user accounts that don’t have E5 licenses must also be licensed for MDO. The text says that licenses must be acquired for “All Exchange Online users on the tenant. This is because Plan 2 features and capabilities protect all users in the tenant.”

The Sudden Realization that Shared Licenses Need MDO Licenses

I’m not sure that many tenants with MDO understand the need to license shared mailboxes. The MDO Plan 2 license costs $5/month with a 12-month commitment, or $60 per shared mailbox annually. Some organizations make heavy use of shared mailboxes, including as a method to preserve mailboxes for ex-employees (inactive mailboxes are the recommended approach). A thousand shared mailboxes will therefore rack up an unexpected $60,000 bill, and that amount doesn’t include any additional licenses that might be needed to bring non-E5 mailboxes into compliance.

I haven’t heard of any Microsoft campaign to make tenants aware of how MDO licensing works for shared mailboxes, nor is there a code check in Outlook to detect and advise when MDO licenses are necessary. The Exchange Admin Center (EAC) includes an option to switch a user mailbox to a shared mailbox, and that option doesn’t warn administrators about potential licensing requirements.

To be honest, I was unaware of the need until I read the service description after being asked if shared mailboxes needed MDO licenses because a customer had been unexpectedly told that the licenses were required. I suspect that many others are in the same state of blissful licensing ignorance.

Unexpected Painful Costs

Any unexpected cost is bad news. Suddenly discovering that a tenant has a batch of unlicensed shared mailboxes is firmly in that category. Discovering that some user accounts that don’t have E5 licenses might need MDO licenses is also painful. There’s nothing good to report here.

Dedicated Hybrid Connectivity App Fails to Gain Traction

In April 2025, Microsoft announced a dedicated Entra ID app for hybrid connectivity as part of its campaign to dump Exchange Web Services (EWS) from Exchange Online tenants in October 2026. Microsoft has a separate goal to remove EWS from its own apps by October 2025, a move that affects popular apps like Outlook (classic) and Teams.

The dedicated hybrid connectivity app is not an enterprise app created and controlled by Microsoft. Instead, each tenant that runs a hybrid Exchange environment must create a separate tenant-specific version of the app using a Microsoft-provided script.

Once created, the app’s service principal holds the necessary permissions for Exchange Online to use Graph APIs to enable “rich coexistence,” which is code for allowing Exchange Online to act as a broker to fetch data stored in user mailboxes for use by apps, such as the Teams calendar app (in passing, MC1129730 (5 August 2025), says that Microsoft will remove the toggle to allow users to switch between the old and new versions of the Teams calendar app in September 2025).

Power Outages Coming

Unhappily, great plans have a nasty habit of running into problems, which is what has happened here. Tenants are not complying with Microsoft’s wish to create the dedicated hybrid connectivity app, which led to an August 6 EHLO post saying: “the number of customers who have created the dedicated app remains very low.”

To encourage customers to make the switch, Microsoft says that they will “introduce short-term EWS traffic blocks” during the following dates:

Crucially, these interruptions in service do not affect tenants that have created the dedicated hybrid connectivity app. Like a flickering alarm light, the time-outs are intended to prompt customers to act. Of course, this depends on tenant administrators or users noticing the effect of an EWS outage and figuring out what happened. You’ve got to assume that even the least attentive administrator will notice a three-day loss of service…

Microsoft says that tenants won’t get exemptions from the time outs and the dedicated hybrid connectivity app needs to be in place before October 31, 2025, before EWS connectivity via the old app is permanently removed.

The New HCW

The good news is that a revamped version of the Hybrid Configuration Wizard (HCW) can configure the dedicated hybrid connectivity app for a tenant. A setting override is still needed to complete the switchover, but all the steps to configure the app with the permissions (EWS for now, Graph API after a future update) and certificates is done.

Security Advisory for EWS Weakness

Microsoft also points out that changing to the new configuration will improve tenant security. EWS is not very secure, and evidence exists that attackers have exploited the protocol in the past in tenant compromises. Indeed, Microsoft cites MSRC advisory CVE-2025-53786 describing an elevation of permission when “an attacker who first gains administrative access to an on-premises Exchange server could potentially escalate privileges within the organization’s connected cloud environment without leaving easily detectable and auditable trace. This risk arises because Exchange Server and Exchange Online share the same service principal in hybrid configurations.”

Moving to the dedicated hybrid connectivity app addresses the weakness reported in CVE-2025-53786.

Path Forward is Clear

The call to action is clear. Any Microsoft 365 tenant with a hybrid Exchange configuration needs to get with the program and create the dedicated hybrid connectivity app. Failure to do so will only lead to disruption and pain. Don’t put this off: make your tenant more secure and take a positive step to jettison EWS. You know it’s the sensible thing to do.

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 Need for Licenses to Include Shared Mailboxes in Retention Policies

After writing about how to replace Exchange litigation holds with Microsoft 365 retention policies, I received a question whether retention policies cover mailboxes that don’t have an Exchange Online Plan 2 service plan, like shared mailboxes. Exchange Online Plan 2 is included in many Office 365 and Microsoft 365 licenses and can be bought and assigned as a separate license. For instance, you can assign an Exchange Online Plan 2 license to a shared mailbox to allow that mailbox to use an archive mailbox, increase its storage quota from 50 GB to 100 GB, or be placed on litigation hold (here’s how to check shared mailboxes against licensing requirements).

The answer is that retention policies with static locations cover shared and other resource mailboxes without requiring a license. The relevant text says: “For many [data lifecycle management] features, a shared or resource mailbox does not need a license assigned.” Shared mailboxes do need licenses when use is made of data lifecycle management features that require user mailboxes to have E5 or Microsoft 365 Compliance or Microsoft 365 Information Protection and Governance licenses. Retention policies based on adaptive scopes are an example.

Adding a Shared Mailbox to a Retention Policy

When a new shared mailbox is created, it receives a default mailbox retention policy. The retention policy is defined in the mailbox plan applied by Exchange Online when it creates the mailbox. In many cases, the Exchange retention policy (called a legacy retention policy by Microsoft) is sufficient to clear out old messages from the mailbox on a regular basis (or move items to an archive mailbox). If a tenant has a Microsoft 365 retention policy covering all Exchange Online mailboxes, shared mailboxes are covered by that policy.

You can also add the shared mailbox to a specific Microsoft 365 retention policy by editing the policy and selecting the shared mailbox, just like any other mailbox (Figure 1).

Mixing the two types of retention policy doesn’t matter because the Exchange managed folder assistant (MFA) combines the settings from all the policies that apply when it processes a mailbox to remove expired items. After the shared mailbox is added to a Microsoft 365 retention policy, you should see the hold applied by the policy in the set of in-place holds noted for the mailbox. For example:

Get-Mailbox Customer.Services@office365itpros.com| Format-List InPlaceholds
InPlaceHolds : {UniHcac6fa1f-ce89-43ef-9e56-839a0e164662}

Creating a Special Microsoft 365 Retention Policy for Shared Mailboxes

Although Exchange retention policies are usually all that’s needed for shared mailboxes, you might feel that it’s best to use Microsoft 365 retention policies for all retention processing and create a Microsoft 365 retention policy for shared mailboxes. The advantage of using a targeted retention policy for shared mailboxes is the ability to apply different retention settings to those used for user mailboxes.

Remember the two downsides of this approach:

• Folder-specific processing isn’t possible with Microsoft 365 retention. All folders have the same retention setting.
• Microsoft 365 retention policies can’t move items to archive mailboxes. This feature requires shared mailboxes to have an Exchange Online Plan 2 license.

To illustrate the point, I wrote a PowerShell script to create a Microsoft 365 retention policy especially for shared mailboxes. The script does the following:

• Connect to Exchange Online and Compliance PowerShell endpoints.
• Find all shared mailboxes.
• Create a new Microsoft 365 retention policy.
• Add the shared mailboxes to the retention policy. Up to 1,000 individual mailboxes can be added to a single retention policy. If a tenant has more than 1,000 shared mailboxes, you’ll need to split the mailboxes across multiple policies. In this scenario, I would write the name of the policy used for a mailbox into one of the 15 custom attributes available for mailboxes.
• Create a retention rule to keep items for two years (730 days). Obviously, you can choose a different retention period.
• Remove the Exchange retention policy from the shared mailboxes.

You can download the script from the Office 365 for IT Pros repository).

Another step to consider is to exclude shared mailboxes from any Microsoft 365 retention policy that processes “All Exchange mailboxes.” This simplifies the retention processing for shared mailboxes to make sure that retention periods and actions from other policies don’t interfere with settings in the retention policy for shared mailboxes.

Some More Work

The retention policy created by the script processes shared mailboxes which exist at that time. More work is needed to maintain the retention policy by adding new shared mailboxes (deleted shared mailboxes are automatically removed from policies). That task is easily done with another script, which I’ll cover in a different post.

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. Only humans contribute to our work!

Same NoSignOnReply Control for S/MIME Inheritance for Replies as Outlook (Classic)

Message center notification MC1072404 (last updated 21 July 2025) announces the provision of a control over S/MIME inheritance for email replies. The new setting allows tenant administrators to determine whether S/MIME signatures are inherited by default when people use the Reply and Reply All options to generate responses to signed messages.

Essentially, this is the same capability as previously implemented through ADMX Group Policy template files for Outlook (classic), so it’s part of the ongoing work to make sure that the new Outlook is as functional as Outlook classic before the eventual retirement of the old client sometime in 2029 (that date might change if features aren’t in place).

As an online client, the new Outlook depends more on server-based controls than the policy settings stored in the system registry as used by traditional Office apps. Support is rolling out now and should be complete worldwide by early August 2025. Deployment then moves to GCC and should be finished there by late August 2025.

Dropping OWA

When first announced, Microsoft included OWA along with the new Outlook for Windows. This is logical because the two clients share a lot of code. The new Outlook supports functionality that isn’t in OWA, like PSTs (including the recently-introduced export to PST feature) and better offline access, but generally the two clients support the same set of server settings. This is not the case here as Microsoft has decided not to support S/MIME inheritance for replies in OWA.

Updating S/MIME Settings

MC1072404 states that the NoSignOnReply setting is available in Entra ID. This might mean that the tenant S/MIME configuration is stored in Entra ID. However, the Set-SMIMEConfig cmdlet is very much part of both Exchange Server and Exchange Online (the cmdlet goes back at least as far as Exchange 2013 – I can’t recall if it was available for previous versions). Most of the settings manipulated by the cmdlet affect how OWA deals with S/MIME. The NoSignOnReply setting is explicitly excluded for OWA.

In any case, the default value for NoSignOnReply is $true. This means that reply messages created with Reply or Reply All do not inherit the S/MIME signature (Figure 1) from the original message. However, if the original message is encrypted, the replies inherit the same encryption. Microsoft notes that the default setting is useful when an organization has not configured S/MIME signatures for all users.

When the setting is $false, replies inherit the S/MIME signature from the original message. If this is undesirable (for instance, it’s the wrong signature), the user must open S/MIME settings and remove the signature.

Set-SMIMEConfig -NoSignOnReply $false

Details of the S/MIME configuration can be retrieved using the Get-SMIMEConfig cmdlet.

Sites that Duplicate Message Center Notifications are Useless

While checking details of MC1072404, I noticed that there are many sites that simply take the text of message center notifications and publish them as written. No attempt is made to add any value whatsoever in terms of interpretation, insight, or additional information. It’s a wonder to me why people republish message center notifications in this manner. They might get a few page views, but apart from that they clutter up the internet with duplicated material. In fact, given the way that generative AI summaries are now used by Google and other search engines, the number of page views that these sites gain must be much decreased.

We do report on message center notifications, but only when we think we have something useful to add that helps readers understand the nature of the change and how it impacts the Microsoft 365 ecosystem. We don’t always get things right, but at least we’re not a “me too” site.

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.

Six Months of an Extended Security Update Program from October 2025 to April 2026

Those who aren’t dedicated followers of the EHLO blog might have missed two interesting posts this week. The first covers delicensing resiliency for Exchange Online and the news that Microsoft is reducing the threshold for this feature to 5,000 tenant mailboxes. I think the feature should be available to all Exchange Online tenants, but let’s leave that debate aside.

Coping with the consequences of a mailbox becoming delicensed isn’t such an issue for Exchange on-premises organizations. They have their own challenge, notably the need to upgrade to Exchange Server Subscription Edition (SE) before Exchange 2016 and Exchange 2019 exit support on October 14, 2025.

Updating a Server to Exchange Server SE is Boringly Easy

The second EHLO post of the week offers a lifeline to organizations who don’t believe that they can deploy Exchange Server SE by the October 2025 deadline. Performing an in-place server upgrade to Exchange Server SE is the easiest Exchange upgrade an on-premises administrator is likely to ever know. It’s been described as “boring” because literally nothing happens apart from version numbers being updated and a few other minor tweaks. The fact that Exchange 2019 and SE share the same documentation for system requirements testifies to the closeness of the two products.

Microsoft designed the upgrade to the first iteration of Exchange Server SE to be boring to remove the barrier where administrators believe that an Exchange upgrade is a major event with many potential problems lurking under the surface waiting to make a server inoperative. Read the documentation, follow the steps laid down, and your update will proceed smoothly.

Factors Stopping Upgrades Happening

Although the server upgrade is easy, there’s usually some other factors that come into play that can slow deployment. Now is peak vacation period so people might not be available. The organization might decide to introduce new hardware or roll out Windows Server 2025. This might be especially so when the organization runs Exchange 2016 on an older version of Windows Server (here’s the operating systems matrix). In any case, lots of preliminary steps might need to be resolved before anyone sits down to update a server.

To help organizations that are struggling to get their ducks in a row to allow the deployment of Exchange Server SE to proceed, Microsoft is therefore introducing a six-month Extended Security Update program. The idea is simple: After August 1, 2025, customers can contact their Microsoft account team to request a subscription to a new product SKU that entitles them to receive security updates for Exchange 2016 and Exchange 2019 for six months. The price of the SKU is per-server, and it’s assumed that the Microsoft account team knows how many servers a customer operates so that they can calculate an initial price before any discounts are negotiated. If you don’t have a Microsoft account team, call the local Microsoft office and get them involved.

There are several important points to consider before proceeding to enrol in the Extended Security Program:

• The agreement only lasts six months and Microsoft doesn’t plan to extend it past April 14, 2026.
• During the agreement, Microsoft will deliver security updates for problems that the Microsoft Security Response Center deems to be critical or important. In other words, a security issue must meet a threshold before Microsoft will create a security update for Exchange 2016/2019.
• Security updates issued through the program will be released privately to program participants. You won’t be able to download the updates from the Microsoft download center.
• There’s no guarantee that any security problems will emerge between October 15, 2025, and April 14, 2026. In other words, this is insurance in case a problem happens, and no refunds are coming if the security landscape remains calm throughout the six-month program lifetime.
• Microsoft says that they will inform program participants if a security update is available on Patch Tuesdays during the covered period.
• The Extended Security Update Program does not affect the end-of-lifetime support dates for Exchange 2016 and Exchange 2019. Those dates remain as they are. This program only covers security issues.

Not a Revenue Generating Opportunity

Cynics will say that this is yet another example of Microsoft adjusting deadlines, this time to create an opportunity for a little extra revenue by charging customers for six months of security insurance. Pragmatists will recognize just how slow Exchange Server updates have been since Exchange 2000 appeared. Given the engineering costs involved, I doubt Microsoft will make much if anything from the Extended Security Update program. This is no more and no less than a lifeline for those who need that extra time.

Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work, which includes topics like Exchange Server SE that are important to hybrid Microsoft 365 deployments.

Delicensing Resiliency Protects Against Data Loss – Should Be Available to All

According to an EHLO July 15 post, Microsoft has decided to reduce the threshold for delicensing resiliency from the original level of 10,000 mailboxes announced in November 2024 to 5,000. In other words, the feature to protect against inadvertent data loss due to mailboxes becoming unlicensed is only available for tenants with more than 5,000 mailboxes.

I think the feature should be available to all Exchange Online tenants. Apart from some notional accounting savings accrued by removing unlicensed mailboxes from tenants without a 30-day grace period, Microsoft has no good justification for restricting delicensing resiliency to large tenants. Here’s why.

A Sticking Plaster for Group-Based Licensing

First, delicensing resiliency is a sticking plaster fix to a problem in Microsoft group-based licensing that can cause an account to end up in a situation where it has no license that includes an Exchange Online service plan. When this happens, Exchange Online detects the unlicensed state of the mailbox and disconnects the mailbox to make it inaccessible. The grace period granted through delicensing resiliency allows administrators the time to recognize and correct license allocation mistakes.

The problem was more evident before Exchange Online supported license stacking (the ability for an account to have several licenses with Exchange Online service plans). Stacking allows a mailbox to remain licensed even when an Exchange license is removed from an account. But group-based licensing can become complex when multiple groups are used to assign licenses, including dynamic groups. A change to someone’s membership of a group (or a change to a property that includes them in a dynamic membership) can result in license removal and hence a mailbox disconnection.

It would be better if Microsoft sorted out group-based licensing to remove the possibility of accounts becoming unlicensed. Perhaps the Microsoft 365 admin center, which took responsibility from Entra ID for the management UX for group-based licensing in 2024, could develop a “what if” feature to show administrators what will happen if a change is made to a group and warn against removal of access to critical apps like Teams and Exchange. And in the interim, Exchange Online could make delicensing resiliency available to all tenants.

OneDrive for Business is the Other Major User Personal Storage

It’s not as if such a step would be something new and dramatic. The default retention period for OneDrive for Business accounts belonging to deleted user accounts is 30 days, and that period can be extended to allow nominated individuals to check OneDrive to harvest essential business information. OneDrive and mailboxes are the two primary personal storage locations within Microsoft 365. A similar level of access to the two types of objects should be possible following license removal (often because of account deletion).

Use Retention to Make Unlicensed Mailboxes into Inactive Mailboxes

Another reason for extending delicensing resilience to all tenants is that “big” tenants usually can protect against inadvertent deletion by putting a retention or litigation hold (or holds) on mailboxes to ensure that Exchange Online puts deleted mailboxes into an inactive state. This is another good way to ensure that mailboxes remain available even if a deletion in error occurs. Inactive mailboxes are available to any size of tenant that can set retention holds and there’s no arbitrary number of mailboxes that must be met.

Delicensing resiliency is easier for tenants to use than inactive mailboxes are because the mailboxes remain online and connected. Inactive mailboxes need to be reconnected through administrator intervention. That might have an advantage because the administrator might then understand that a problem exists in how the tenant manages licenses.

All We Need is Simplicity and Consistency

Although there is goodness in building features that protect against data loss, it would be even better if Microsoft was consistent in its policies and practices for controlling user data across the entire Microsoft 365 suite. We’re 14 years into the Office 365 era and while great progress has been made in some area to achieve consistency across workloads, gaps still exist. Blaming the roots of on-premises products is not acceptable any longer. Joined-up thinking is needed, and that doesn’t appear to be the case here.

In the interim, if your tenant has more than 5,000 mailboxes, update your organization configuration to enable Delicensing Resliency using the following command:

Set-OrganizationConfig -DelayedDelicensingEnabled:$true

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. Only humans contribute to our work!

July 1 Announcement of Exchange Server SE Launches the Subscription Era for Exchange Server

Right on schedule, July 1 saw the Exchange engineering team celebrating Microsoft’s new fiscal year by announcing the general availability of Exchange Server Subscription Edition (SE). I’m always suspicious about announcements just made at the end or start of a fiscal year because updates can be timed to satisfy artificial deadlines set by executives (to justify their bonuses). I don’t think that applies in this case because Exchange Server SE is a lightly rebranded version of Exchange 2019. At least, that’s what you might conclude by reading the slim list of changes (like a version number update).

Mentioning the Release to Manufacturing (RTM) build brought back memories of waiting for physical media containing a new release of Exchange Server, going right back to 1994 and the initial builds of “Touchdown” made available to customers. It was a charming look back into the past. Now we simply head online to grab the latest bits (Figure 1) and read the deployment instructions.

Moving to Evergreen Support

The big change is the move away from Exchange development based on three-year cycles (extended to six for Exchange 2019) to “evergreen” development. In some respects, the quarterly cumulative updates for Exchange Server showed the way forward in terms of keeping software refreshed. However, Exchange Server still followed the traditional support model based on versions whereas Exchange Server SE remains supported if customers keep the software refreshed with updates released by Microsoft.

Nine months ago, Microsoft flagged the end of support for Exchange 2016 and Exchange 2019 on October 14, 2025. After this date, Microsoft will no longer provide technical support for problems (aka bugs). The writing is on the wall: to continue in a supported state, customers must adopt Exchange Server SE or move to Exchange Online. Obviously, we’re now deep into the prime vacation period and thoughts might be more focused on suntan lotion than server upgrades, but this is an issue that cannot be overlooked, especially in hybrid environments where Microsoft requires on-premises servers that host connectors to Exchange Online to remain supported.

Email Bombs Away

If you don’t read the Microsoft Defender for Office 365 blog, you might have missed the update about protection against “email bombs.” Essentially, an email bomb is a form of attack against a mailbox where a large volume of messages (the bomb) hit a mailbox. The messages often originate from legitimate sources such as newsletters, but the target user never signed up receive the messages. Given the large quotas assigned to Exchange Online mailboxes, it’s unlikely that an email bomb will cause the mailbox to exceed quota, but the arrival of large numbers of unwanted and unexpected messages is certainly a distraction. And when someone’s distracted, they might make bad decisions, such as accepting help from an attacker who poses as a support representative.

In any case, an update to Microsoft Defender for Office 365 can monitor for the characteristics of email bombs, such as a sudden significant spike in the number of messages received by a mailbox. The spike is detected by comparison against the historical pattern of email traffic observed for the mailbox together with spam signals. When an attack is detected, Defender redirects the problem messages into the mailbox’s Junk Email folder. Microsoft says that they have blocked between 20K and 30K email bombs daily since the initial deployment of the technology in early May 2025.

Microsoft Defender for Office 365 includes a lot of useful protection against different types of email threat. For more details, including licensing, see the service description.

Ongoing Updates

Email security is never a static topic. Whether you’re upgrading on-premises servers to the latest version of Exchange Server to harden servers against external attack or deploying new software to detect and deflect attacks, this is an area we need continuous focus on. The joys of staying up-to-date!

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.

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 saying 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.