Use PowerShell to Check Shared Mailboxes for Microsoft Defender for Office 365 Protection

I’ve spent a lot of time pursuing clarification about the licensing requirements for shared mailboxes when Microsoft Defender for Office 365 (MDO) is active within a Microsoft 365 tenant. Essentially, once a Microsoft 365 or Office 365 E5 license is assigned to a user account, MDO is activated and delivers protection to the mailboxes that come within the scope of its policies. The default is to protect all mailboxes, including shared mailboxes, and every mailbox that “benefits” from MDO protection must be licensed. This is the change Microsoft made to the MDO licensing terms, which originally required MDO licenses for all user and shared mailboxes in the tenant.

User accounts with Office 365 E5 or Microsoft 365 E5 licenses are licensed because both the MDO Plan 1 (identifier f20fedf3-f3c3-43c3-8267-2bfdd51c0939) and the MDO Plan 2 service plan (identifier 8e0c0a52-6a6c-4d40-8370-dd62790dcd70) are included in the set of service plans (apps) covered by these licenses (Figure 1).

Licensing Shared Mailboxes

Shared mailboxes, or rather the disabled Entra ID accounts used to these mailboxes, must be licensed if they receive MDO protection. The tenant doesn’t need to assign licenses to the accounts. All that’s needed is for the tenant to have sufficient MDO licenses (product SKU identifier 3dd6cf57-d688-4eed-ba52-9e40b5468c3e, THREAT_INTELLIGENCE) to cover the licensing requirement (see this page for product identifiers).

To reduce the potential liability for MDO licenses, tenants can exclude shared mailboxes that don’t benefit from MDO protection. For example, organizations often convert user mailboxes to shared mailboxes when people leave (inactive mailboxes are a better option for this purpose), some shared mailboxes are only used for internal communications, and some shared mailboxes are simply not in active use. Shared mailboxes in these categories don’t benefit from the Threat Processing and other Microsoft Defender for Office 365 features, so they don’t need to be licensed.

Use PowerShell to Find Shared Mailboxes That Should be Licensed

One simple test of whether shared mailboxes need MDO licenses is if the mailboxes receive external email. By definition, MDO processes external email as it passes through the transport pipeline, so any message received from a domain that doesn’t belong to the tenant is evidence that a mailbox has received benefit from MDO.

Two methods are available to check for external email. You could check the mailbox for messages from external domains or use Exchange’s message trace logs to analyze the traffic going to shared mailboxes to isolate any external messages. The second method is simpler than the first, so that’s what I used. The limitation is that the data retrieved by the Get-MessageTraceV2 cmdlet only goes back ten days.

An advantage of using message trace logs is that the processing to find shared mailboxes and check each mailbox can be done with the Exchange Online management module, providing that the signed-in user holds the Exchange administrator role. Things get more complicated when the script needs to check if the accounts are licensed for MDO. And it’s even more complicated if you want to run the script as a scheduled Azure Automation task or allow accounts that aren’t Exchange administrators to run the script.

License checking is easily done using the Microsoft Graph PowerShell SDK. The SDK also has all the necessary cmdlets to create and send email with the processing results. Making it possible for non-privileged accounts to run the script means using an app to authenticate against both the Graph and Exchange Online so that the code can run in app-only mode. Apart from that, the app must have the Exchange.ManageAsApp permission to manage Exchange as an app and its service principal must be added to the Exchange administrator role.

The full set of application permissions that must be assigned to the app is:

• Microsoft Graph: User.Read.All (fetch license information for accounts), Mail,Send (send email), and Domain.Read.All (read domain information to find default domain for the tenant).
• Office 365 Exchange Online: Exchange.ManageAsApp

If you want, the script can be easily converted to run as an Azure Automation runbook or using delegated permissions (in which case the signed in account must be an Exchange administrator).

The output is a report listing the set of shared mailboxes that do not have MDO licenses that have received external email over the last ten days (Figure 2).

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

Don’t Overspend on Microsoft Defender for Office 365 Licenses

Some Microsoft 365 tenants have thousands of shared mailboxes. Although E3 is still the norm for many organizations, an increased number of tenants are moving to use E5 licenses and therefore use Microsoft Defender for Office 365. It’s important to keep an eye on the potential MDO licensing liability and only license the mailboxes that receive benefit from MDO. Hopefully, this script helps.

Need help to write and manage PowerShell scripts for Microsoft 365, including Azure Automation runbooks? 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.