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.

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

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.

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
    }
}

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 Azure AD, 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 Azure AD, but the management of those objects must be done on-premises.

Understanding Mail Contacts

Before comparing mail contacts with Azure AD guest accounts, we need to understand what a mail contact is. Mail contact objects exist in both the Exchange directory (EXODS) and Azure AD. 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 Azure AD. The Exchange object is what people think of when they think about a mail contact. The Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD 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 Azure AD. 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 Azure AD 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 Azure AD manages external identities.

There’s some truth here. An Azure AD guest account supports more properties, including custom security attributes and support dynamic Azure AD Groups and dynamic Azure AD administrative units. They’re a Microsoft 365 entity rather than being restricted to just Exchange Online. Azure AD 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 Azure AD 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. Azure AD 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 Azure AD 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.
• The agent uses message identifiers to allow it to recall messages even after the recipient has moved them from the inbox.
• The message sender receives a message recall report after the agent finishes processing. The report summarizes the successful and failed attempts to recall the message. Typically, the recall report arrives within a minute or so after submission if the agent needs to deal with ten or so recipients. The more recipients, the longer it takes for the agent to collate the recall status for all recipients. Microsoft says that it could take five minutes for a summary report covering “a few hundred recipients.” Receiving this kind of confirmation should reassure people who recall messages that the process worked. However, even a successful recall is no guarantee that the recipient has not read, printed, or otherwise dealt with the message before its recall.
• Users can recall messages months after their original sending. Although the extended period means that more recipients are likely to have read the content, recall still removes the copy of the message from their mailboxes.
• Because a recalled message is effectively a hard delete of the item from user mailboxes, Exchange Online captures copies of messages recalled by the agent for mailboxes subject to retention or litigation holds to make the messages available for eDiscovery
• The Message Recall agent can only process messages delivered to recipients within the same organization. A message cannot be recalled if leaves the organization and goes to another Exchange Online organization, Exchange Server, or another email system. Microsoft has the technical capability to recall messages sent to any Exchange Online organization and to Outlook.com recipients but cites legal and privacy reasons for restricting recall to the sender’s organization.
• The Message Recall agent only works for Exchange Online. There’s no equivalent for Exchange on-premises servers.
• Messages from shared mailboxes can be recalled. However, the summary report is inaccessible. Microsoft is aware of the issue and is working on a fix.
• If organizations don’t want users to be able to recall read messages, they can update their organization configuration by running the Set-OrganizationConfig cmdlet to update the RecallReadMessagesEnabled setting. By default, the setting is null and the feature works. To disable message recall for messages that recipients have already read, run:

Set-OrganizationConfig -RecallReadMessagesEnabled $False

The setting affects all mailboxes in the tenant. You can’t enable message recall for selected mailboxes. The setting can also be changed through the Settings section of the Exchange admin center (Figure 2).

If you want to disable message recall completely, run Set-OrganizationConfig to update the MessageRecallEnabled setting:

Set-OrganizationConfig -MessageRecallEnabled $False

Overall, Microsoft estimates the improvements they have made allows message recall to have a 90% success rate. Your mileage will vary depending on the recipients of the messages that you attempt to recall. Obviously, if the majority of your email traffic is external, your success rate will be lower. This might be a factor in tenants where Teams is the preferred choice for internal communications and email is largely reserved for external communications.

Message Recall Helps People

Over my 27 years working with Exchange, I haven’t used message recall more than once or twice. The Microsoft data indicates that I might be unusual. It seems like many people find the need to recall a message and are subsequently disappointed. Let’s hope that the new message recall brings more happiness to those who need it after they make a mistake sending a message that they really wished they hadn’t.

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

Calculating Statistics for Room Mailboxes

A Practical365.com article I wrote explaining how to extract and report statistics for room mailboxes is quite popular. The script uses Microsoft Graph API requests to fetch data about events from the calendars of the meeting rooms and analyzes the data. Apparently, many people need this data for one reason or another.

As I noted last week, when you publish a PowerShell script and make it available publicly, you’re likely to get requests for enhancements. Most of the time I don’t mind people sharing their ideas with me because I like hearing what others think and the issues they grapple with. Being forced to respond to questions also encourages research to find the right answers, and that’s a good way to acquire more knowledge.

In a minority of cases, I wonder why the person making a request doesn’t simply amend the code to do what they want. It could be that they don’t feel too confident with PowerShell or don’t know how to make a change. Basic familiarity with PowerShell and the modules used with Microsoft 365 is a core competency for administrators. At least, it is if you want to automate administrative operations.

Report Daily Usage Patterns for Room Mailboxes

In any case, this week a request came in to report the most popular days for meetings. Given that we already have the data about meetings and report statistics like the total events for a room, total minutes booked, average event duration, average attendees, and so on, it’s logical to ask when is a meeting room popular.

The information recorded for each meeting has a start and end date, so finding out the day of the week that the meeting occurred on is easily done with the PowerShell Get-Date cmdlet:

$Day = (Get-Date($MeetingStart)).DayOfWeek

Storing the day of the week for each event allows the script to analyze the information when it generates the other statistics. The basic approach I took is:

• Count the total events for each day.
• Compute the percentage of the overall events for each day.
• Build a very basic chart element for the day. The idea is to build a simple bar chart where the larger the bar, the higher the daily room usage is. I’ve no doubt that those with more artistic minds than mine can come up with a much nicer solution.
• Store the information.

After processing all room mailboxes, the script generates summary information, including the daily usage pattern for all rooms (Figure 1).

The daily usage data is stored for each room mailbox and the script outputs the same kind of chart for the individual rooms (Figure 2).

After I published the updated script, I was asked how the script aligns the bars. That’s simple. The script inserts a tab character when creating the output. That’s another old PowerShell trick. If the tab character wasn’t there, the bar chart wouldn’t line up properly.

Download Script from GitHub – But Check Article Comments

If you have issues running the script (downloadable from GitHub), check out my article about the most common errors people encounter when running PowerShell with Graph queries. Many of these issues are debated and resolved in the comments for the original article. Remember, it’s PowerShell, so the code is there to be amended. Enjoy!

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

License Stacking Allows Workloads to Manage Multiple Licenses

The Exchange Online blog post of January 20 “Introducing Support for Concurrent Exchange Online License Assignments” caused some furrowed brows because on first glance it doesn’t seem like an important announcement. The impact of the change depends on the size of a Microsoft 365 tenant and the processes used for license management. If your tenant is small and licenses are relatively static, you can safely ignore this topic. But those who run large tenants and use features like group-based license assignments are likely to be much more interested.

License stacking means that an Azure AD user account can hold multiple licenses for the same workload. Some of the licenses might be inherited from products (SKUs) that bundle multiple service plans (a not-for-sale license included in a SKU). Others come from specific products or add-ons. For instance, an account might hold the Teams Exploratory license and also have a license for Teams through the Office 365 E3 or E5 SKUs. When license stacking is in place, the workload is responsible for resolving the capabilities made available through the different licenses and allowing the account access to the feature set available from the best (“most superior”) license. In the example above, Teams would respect the license from Office 365 E3 or E5 because it covers more functionality than the Teams Exploratory license.

Exchange Online Licenses

In the case of Exchange Online, four licenses are available:

• Exchange Online Essentials (BPOS_S_Essentials).
• Exchange Online Kiosk (BPOS_S_Deskless).
• Exchange Online Plan 1 (BPOS_S_Standard).
• Exchange Online Plan 2 (BPOS_S_Enterprise).

BPOS refers to Business Productivity Online Suite, a predecessor to Office 365 based on Exchange 2007.

Microsoft says that they have updated the Get-ExoMailbox (Get-Mailbox) and Get-Recipient cmdlets to give tenants insight into the Exchange capabilities assigned to accounts through the licenses assigned to the accounts. I found that the data isn’t fully populated for all mailboxes (this will happen over time). However, it’s possible to run a command like this to report assignments:

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Format-Table DisplayName, RootCapabilities

DisplayName                             RootCapabilities
-----------                             ----------------
Tony Redmond                            BPOS_S_Enterprise
Ben Owens (DCPG)                        None
Andy Ruth (Director)                    BPOS_S_Standard, BPOS_S_Enterprise
James Ryan                              BPOS_S_Enterprise

The Ben Owens account is an example where the assignment information isn’t yet populated. The Andy Ruth account is an example where two licenses are in place that include an Exchange service plan (one for Exchange Online Plan 1, the other for Plan 2). In this case, because Exchange Online Plan 2 enables more functionality than Plan 1, it’s the one that Exchange Online respects.

Concurrent License Assignments for Exchange Online

Traditionally, Exchange Online has not supported license stacking, which means that an Azure AD account can hold a single Exchange Online license. Most of the time this doesn’t matter because the usual situation is for an account to receive an Exchange Online license through a product SKU. For instance, Office 365 E3 and E5 both include the Exchange Online Plan 2 service plan.

However, it’s possible that an account might start out with a Microsoft 365 Business Basic license that includes Exchange Online Plan 1. The account belongs to a user who’s promoted to a management position that the organization requires to come within the scope of a retention policy and have an online archive. These features require Exchange Online Plan 2, so the organization removes the Microsoft 365 Business Basic license and assigns the account an Office 365 E3 license.

Exchange Online mandates that all user mailboxes have licenses. When the organization removes the Exchange Online Plan 1 license from the account, a chance exists that Exchange Online might soft-delete the mailbox and make it unavailable. The mailbox becomes available again when the account gains the Exchange Online Plan 2 license through Office 365 E3, but it’s not a great situation to be in if a user loses access to their mailbox while license administration is in progress.

Why Exchange Online License Stacking is Helpful

Support for license stacking (multiple concurrent licenses) means that the organization can assign the superior license to the account before removing the other license. This might happen through an automated process. For instance, a group-based licensing assignment might occur and assign the license because of the user’s new job means that they join a group. Later, another process might remove the inferior license from the account to return it to the unused license pool. Automated license assignment by reference to a property of Azure AD accounts is very common, both through Azure AD group-based assignment and purpose-built license management tools. Organizations often go down this route because of the complexity that’s sometimes found in understanding the combinations and permutations available in Azure AD licensing.

Group-Based Licensing for All

In August 2021, as part of their announcement about the retirement of the license assignment cmdlets in the Azure AD and MSOL PowerShell cmdlets. Microsoft promised to remove the additional licensing requirement for group-based licensing. That hasn’t happened yet because Microsoft has had to delay the move to the new licensing platform for Microsoft 365.

The current schedule deprecates the licensing cmdlets on March 31, 2023, and perhaps this will mark the point when Microsoft allows everyone to use group-based licensing. If you haven’t already migrated PowerShell scripts that do license management to the Microsoft Graph PowerShell SDK, it’s time to get going.

Good Housekeeping Change

Microsoft is rolling stacked licenses support for Exchange Online in  the commercial clouds. Government clouds are next and will be done by the end of H1 2023. It’s not an exciting change, but it’s a good example of a housekeeping enhancement that will stop users losing access to their mailboxes due to internal license management.

Configure Shared Mailbox Auto Reply for External Contacts

Contact handling is an important part of website communication. Most sites have a contact form that people can fill in to ask questions, perhaps after passing a CAPTCHA test. Behind the scenes, the information from the form might end up in an email to allow the site owners to deal with the query, which is how things should work normally.

Much to the embarrassment of the Office 365 for IT Pros team, we discovered that the contact form for our website has not worked for quite a time. We’ve fixed the problem now to make sure that if anyone uses the contact form to ask a question about the book or comment on book text, the site emails the query to a shared mailbox. If anyone’s interested, we upgraded the site to use the WPForms Lite plug-in for WordPress.

Suitably chastened, we have reached out to people who entered queries through the contact form to follow up and make sure that their questions are answered.

Shared Mailboxes versus Microsoft 365 Groups

Now that everything is fixed on our web site, contact messages sent to Office 365 for IT Pros flow into a shared mailbox. We could use the Microsoft 365 group to process book comments, but it’s cleaner to separate the two. And anyway, we want to use an auto-reply message to acknowledge the receipt of queries, and that feature isn’t supported yet by Microsoft 365 groups (see this comparison between shared mailboxes and Microsoft 365 groups). Some people don’t know that shared mailboxes support auto-reply, but they do and it’s a very useful option at times. For instance, when national holidays roll around, you can use PowerShell to quickly configure shared mailboxes used for customer communication with an appropriate auto-reply message saying that responses will be delayed.

We do use a Microsoft 365 group to organize the production of the book because we keep our chapter and other files in a SharePoint Online site and use Teams to discuss different aspects of the book, like what we’re working on in a monthly update or who hasn’t filed their chapter updates for a monthly update. So many options exist within Microsoft 365 to achieve goals in different ways that it’s often hard to decide which is best. In our case, being able to send auto-replies for contact messages tipped the balance.

Configuring the Distribution List

The email address used for comments configured on our website directs messages to a distribution list. The membership of the distribution list includes the shared mailbox and some other user mailboxes that might be involved in answering queries.

Because the first address reached by inbound messages is a distribution list, we need to configure the list to allow the generation of auto-reply messages and to allow external people to send messages to the list:

Set-DistributionGroup -Identity O365.Book.Comments -RequireSenderAuthenticationEnabled $False -SendOofMessageToOriginatorEnabled $True

To configure the shared mailbox auto reply, we use the Set-MailboxAutoReplyConfiguration cmdlet:

$AutoReplyText = "<h1>Thanks For Your Message</h1><p>We've received your email to <b>Office 365 for IT Pros</b>. If we need to respond to you, we'll be in touch by email within 48 hours. If you need help faster, reply to this email and we'll accelerate our response.</p><p>Best Regards</p><p><i>The Office 365 for IT Pros team</i></p>"
Set-MailboxAutoReplyConfiguration -Identity book.comments@office365itpros.com -AutoReplyState "Enabled" -InternalMessage $AutoReplyText –ExternalMessage $AutoReplyText -ExternalAudience 'All' 

Figure 1 shows the auto-reply we generate:

The technique of allowing Exchange Online to generate and deliver auto-reply messages for messages received by mailboxes through their membership of a distribution list is uncommon but it is used in practice (which is why the SendOofMessageToOriginatorEnabled parameter exists). For instance, this recent example of a use case is in the Microsoft Technical Community.

Another thing to check is to ensure that the shared mailbox doesn’t have a forwarding SMTP address set (this article is worth checking out when debugging OOF issues). Exchange Online won’t send auto-replies for a mailbox when a forwarding address is set.

Forwarding from a Shared Mailbox

We could have reversed the process and configured the shared mailbox to forward messages to another address. Any valid internal SMTP address works including one for a distribution list, but the outbound spam filter probably blocks forwarding to external addresses. If the organization blocks forwarding to external addresses, senders receive a non-delivery notification (5.7.520 Access Denied). In general, mail forwarding from mailboxes is a practice to avoid, so it’s one that we decided not to investigate too much.

Normal Service Resumed

Running a website throws up challenges on an ongoing basis. We should have caught the problem with our contact form earlier and sincerely regret if this caused anyone any extra hassle. On the upside, it did give us a chance to review the handling of contact queries from the website through to Exchange Online to make sure that everything now works as it should.

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

Managing Azure AD User Country and Regional Settings

A question arose about why Exchange Online doesn’t synchronize country settings from Azure AD user accounts, leading to a situation where an Azure AD user account and its mailbox might have inconsistent values. Here’s an example where the Get-MgUser and Get-Recipient cmdlets report different country values for a user account:

Get-MgUser -UserId Sean.Landy@Office365itpros.com | Format-Table country, usagelocation

Country UsageLocation
------- -------------
Austria FR

Get-Recipient -Identity Sean.Landy@Office365itpros.com | Select-Object country*

CountryOrRegion
---------------
France

The technical reason for the apparent inconsistency is simple: Get-MgUser reads data for a user account from Azure AD while Get-Recipient reads information about a mailbox from EXODS, the Exchange Online directory. We’re dealing with two different objects stored in two different directories.

EXODS exists to manage mail-specific properties for mail-enabled objects, like mailboxes. EXODS also manages Exchange objects that aren’t in Azure AD such as public folders and dynamic distribution lists.

Dual Write Between Azure AD and EXODS

To ensure consistency across the two directories, Azure AD and EXODS use a dual-write process. In other words, when an application attempts to update an object, the write operation must succeed in both directories before Azure AD and EXODS commit the change.

However, this doesn’t happen for every property for every object in the two directories. Although the mailbox CountryOrRegion property receives the same value as the user account’s Country property when Exchange Online creates a new mailbox, synchronization doesn’t follow for further updates. Azure AD and EXODS synchronize updates to other elements of address information like the street address, city, and province made in either directory, but ignore changes to the Country property in Azure AD or the CountryOrRegion property in EXODS. Perhaps the reason is that the two properties have different names and purposes: One is specific to a country while the other can store a country or region name. In fact, EXODS doesn’t store a Country property for mailboxes.

All of which means that it is possible to update an Azure AD account with a new value for the country property without any effect on EXODS. For example, this command updates Azure AD without doing anything to EXODS:

Update-MgUser -UserId Sean.Landy@Office365itpros.com -Country "Ireland"

Likewise, the same is true of an update to EXODS with the Set-User cmdlet. Azure AD ignores this update:

Set-User -Identity Sean.Landy@Office365itpros.com -CountryOrRegion "United States"

In practical terms, the inconsistency might be irritating but it isn’t important. Azure AD is the directory of record for Microsoft 365 and applications should go to it for information about user accounts. The information stored in EXODS about mailbox owners is for informational purposes only. If you want everything to match, then you must create a mechanism (a PowerShell script most likely) to synchronize the properties you want to be consistent.

Azure AD Account Usage Location

Another potential inconsistency is the usage location assigned to an Azure AD account. In the example above, the usage location is FR (France) but the Country property says Austria. The usage location is where Microsoft delivers the service to the account and it’s important that it’s correct because Microsoft cannot deliver some elements of Microsoft 365 (mostly to do with encryption) in certain countries.

Life being what it is, the usage location set when creating an account can change. For instance, a user might relocate to work in an office in another country for a period. There’s no requirement to update the usage location for the account because this should reflect the user’s normal location. In addition, an account’s usage location isn’t associated with the tenant home location. The location (or datacenter region) for a tenant establishes where Microsoft delivers services to the tenant from and where tenant data resides. This can be a country-level datacenter (like France, Switzerland, or South Africa), or a regional datacenter (like the U.S. or Western Europe). Tenant accounts located in countries outside a datacenter location can access services delivered to the tenant. Multi-geo tenants are available should local data residency be necessary.

Mailbox Regional Settings

When you create a new Microsoft 365 account and license the account for Exchange Online, the mailbox does not inherit regional properties from the country or service location defined for the Azure AD account. This is deliberate because regional properties are personal to the user and define the language used to interact with the mailbox, its time zone, and the preferred date format. Different groups of people in the same country often use different regional settings. Examples include Welsh speakers in the United Kingdom and Flemish speakers in Belgium.

OWA applies default regional properties based on the tenant location the first time the mailbox owner signs in and creates a set of default folders. For example, mailboxes that use the English language have an Inbox folder, while mailboxes configured for French use Boîte de réception. Users can update regional settings for OWA through Outlook settings. (Figure 1). If they change the selected language, they have the option to rename the default folders.

Administrators can run the Set-MailboxRegionalConfiguration cmdlet to change the regional settings for a mailbox. In this example, the mailbox language, time zone, and date and time formats match the settings for a Dutch user working in the Netherlands. Notice the use of the LocalizeDefaultFolderName parameter, set to $True to force Exchange Online to create default folder names in Dutch for the mailbox:

Set-MailboxRegionalConfiguration –Identity 'Rob Young' –Language nl-NL 
–TimeZone 'W. Europe Standard Time' –DateFormat ‘d-M-yyyy’–TimeFormat 'HH:mm' 
–LocalizeDefaultFolderName:$True

Apart from the language, the time zone is the most important setting because it’s used by Microsoft 365 applications. For example, Teams displays the local time zone for other users when showing their details in profile cards. If your organization scripts the creation of new accounts, it’s a good idea to make sure that the code includes the configuration of an appropriate time zone setting for the mailbox.

Reporting Azure AD User Country and Regional Settings

It’s easy to audit the language settings of Azure AD accounts and mailboxes. Here’s some code to show how:

$Report = [System.Collections.Generic.List[Object]]::new()
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All
ForEach ($User in $Users) {
  Write-Host ("Processing account {0}" -f $User.DisplayName)
  $RegionalSettings = $Null
  $RegionalSettings = Get-MailboxRegionalConfiguration -Identity $User.UserPrincipalName -ErrorAction SilentlyContinue
  $CountryOrRegion = (Get-User -Identity $User.UserPrincipalName -ErrorAction SilentlyContinue) | Select-Object -ExpandProperty CountryOrRegion
  If ($RegionalSettings) {
  $ReportLine = [PSCustomObject]@{ 
    User                   = $User.UserPrincipalName
    DisplayName            = $User.DisplayName
    Country                = $User.Country
    "Preferred Language"   = $User.PreferredLanguage
    "Usage Location"       = $User.UsageLocation
    "Country or region"    = $CountryOrRegion
    Language               = $RegionalSettings.Language.DisplayName
    DateFormat             = $RegionalSettings.DateFormat
    TimeFormat             = $RegionalSettings.TimeFormat
    TimeZone               = $RegionalSettings.TimeZone }
 $Report.Add($ReportLine) }
}

Figure 2 shows the output. This data is from a test tenant, but it illustrates how easy it is for inconsistencies to occur across the range of country settings available for accounts and mailboxes.

The most important element to get correct is the time zone because it affects the user experience. It would be easy to make sure that Country (Azure AD) and CountryOrRegion (EXODS) contain the same value, but aside from configuring values during account creation, you should leave regional settings alone as they’re a matter of personal choice.

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

Automatically Enable Archive Mailboxes Once the Primary Mailbox Exceeds a Threshold

A question following my article about how to transition from Exchange Online mailbox retention policies to Microsoft Purview retention policies asked:

“Is there a way in legacy or M365 online archiving policies , that it can be enabled based on primary mailbox data size ,say for example mailbox size crosses 40 gb , it’s online archive gets enabled automatically and older data gets move to online archive to keep primary mailbox at 40 gb limit.”

It’s a reasonable request. Essentially, the organization wants users to keep all email in their primary mailboxes until the mailboxes get to 40GB. Once that point is reached, the organization wants to enable archives for those mailboxes and start to move old email from the primary mailboxes to the archives to keep the size of the primary under 40 GB.

Archive Mailboxes and Sizing

These are proper archive mailboxes and not Outlook’s archive folder. Real archive mailboxes can grow to up to 1.5 TB using the Exchange Online auto-expanding mechanism. Note: if you enable auto-expanding archives, you cannot move those archive mailboxes back to an on-premises Exchange server.

Exchange Online enterprise mailboxes have quotas of between 50 GB and 100 GB based on the license assigned to the account, so the 40 GB threshold is a tad arbitrary. It might be that keeping under this size assures reasonable performance for the OST file. If so, that’s a good thing because you don’t want the OST to become so large that it impacts PC performance.

Assigning Archives Based on Mailbox Size

The outline of the solution is:

1. Find mailboxes that are not archive-enabled.
2. Check the mailbox size.
3. If the mailbox size exceeds the threshold, enable the archive mailbox, and assign an Exchange Online mailbox retention policy to instruct the Mailbox Folder Assistant to move items from the primary to the archive mailbox after they reach a certain age.

Exchange Online mailbox retention policies are the only way to move items into an archive mailbox. Microsoft Purview retention policies can keep or remove items, but they cannot move mailbox items.

To prepare, I created an Exchange Online mailbox retention policy with a single default move to archive tag (Figure 1). The policy can contain other retention tags to handle processing of default folders like the Inbox and Sent Items, or to allow users to mark items for retention. However, all that we need is the default move to archive tag. In this instance, the tag instructs the MFA to move items from the primary to the archive mailbox once they reach 730 days (2 years) old.

Now we need some PowerShell to check for and process mailboxes. Here’s the script that I came up with:

# Define archive threshold
$ArchiveThreshold = 40GB

# Find mailboxes without an archive
Write-Host "Looking for mailboxes that are not archive-enabled..."
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -Filter {ArchiveState -ne "Local"} -ResultSize Unlimited
If (!($Mbx)) { Write-Host "No mailboxes found without archives - exiting!" ; break }

Write-Host ("Checking {0} mailboxes" -f $Mbx.count); $MbxUpdated = 0
ForEach ($M in $Mbx) {
   
   $Stats = Get-ExoMailboxstatistics -Identity $M.ExternalDirectoryObjectId
   If ($Stats.TotalItemSize.Value -gt $ArchiveThreshold) { # Mailbox size is larger than the threshold
      Write-Host ("Enabling archive for mailbox {0}..." -f $M.UserPrincipalName)
      Enable-Mailbox -Archive -Identity $M.ExternalDirectoryObjectId
      Set-Mailbox -Identity $M.ExternalDirectoryObjectId -RetentionPolicy "Mailbox Two-Year Archive Policy"
      $MbxUpdated++
   } #End if
} #End ForEach Mbx

Write-Host ("All done. {0} mailboxes were processed and {1} were archive-enabled" -f $Mbx.Count, $MbxUpdated)

Wrapping Things Up

To complete the solution, we should arrange for the script to be run periodically to be sure that mailboxes receive archives once they exceed the threshold. The scheduler in Azure Automation is a great way to run scripts like this and the cost to execute scripts is very reasonable. V3.0 of the Exchange Online management module introduced support for Azure Automation managed identities so there’s no danger of compromise due to leaked credentials. Which is exactly how it should be.

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

Viva Briefing Highlights Data from Viva Insights

Microsoft’s history with the generation of personal insights for users based on their work patterns and activities goes back to the purchase of Volometrix in 2015. Volometrix helped organizations to figure out how to be more efficient based on information stored in user mailboxes and calendars, which later became Delve Analytics, MyAnalytics, and finally Viva Insights.

Viva Insights still aims to help people understand how they work so that they can make better use of their time. The Viva Insights suite includes the Viva Insights add-in for Outlook, the Viva Insights app for Teams, the twice-monthly digest email, and the daily briefing email. All surface information gleamed from user interaction with Microsoft 365 captured in the Graph.

Pausing Viva Briefings

Message center notification MC486289 (December 15) says that Microsoft plans to pause sending the Viva Briefing daily email to users who signed up to receive these messages. From an email perspective, Viva Briefing (Figure 1) and digest messages are not real email because Viva injects them directly into user mailboxes. Although the messages are mail items, they do not pass through the Exchange Online transport system and therefore are immune to processing by components like mail flow rules. Microsoft stamps the messages as coming from a trusted sender, so that makes the direct injection acceptable!

Microsoft plans to pause sending Viva Briefing messages after 15 January 2023. Following the normal time required to deploy changes within Microsoft 365, no users should receive these messages after 1 February 2023. Resumption will follow sometime later in 2023. I haven’t received a Viva Briefing message since last Monday. Perhaps my work life isn’t interesting enough to warrant a briefing, or maybe the pause kicked in early for the holiday period.

More Personalized Information

The pause is to allow Microsoft to make changes to the content of the Viva Briefing messages “to be more personalized for each recipient.” I don’t know what this means because the whole point of Viva Briefing is to deliver personalized content to the recipient. For example, Figure 2 shows items found by Cortana (lurking under the covers of Viva Insights) to remind me about things I might like to follow-up. This information comes from email in my mailbox, so it’s highly personalized.

Cortana finds follow-up items by scanning messages for key words and phrases that indicate when the recipient or sender might be committing to an action. The first item in Figure 1 is an example where Cortana highlights that fact that the mailbox owner made a commitment to take an action. The second item is a variation where the mailbox owner asked a recipient to do something.

I don’t depend on the Viva Briefing to find follow-up actions for me, but I do find the prompts to be moderately useful. Sometimes, Cortana highlights something that I have forgotten to do and proves its worth. I suspect that people who have busier calendars and take on more commitments than I do find the briefing email more valuable.

Finding Who’s Using Viva Briefing

Exchange Online automatically enables new mailboxes to receive the Viva Briefing email. However, users won’t receive briefing messages unless they are active. For instance, if you create a test mailbox and only use it from time to time, there’s no email activity for Cortana to analyze and highlight, so there’s no reason to send a briefing. Perhaps the reduced level of email traffic over the last few days is the reason why I haven’t received a briefing message since Monday.

To discover what mailboxes are enabled for Viva Briefing, run PowerShell to find the set of user mailboxes and check each mailbox with the Get-UserBriefingConfig cmdlet. Here’s an example:

$EnabledMbx = 0; $NonEnabledMbx = 0; [array]$EnabledUsers = $Null; [array]$NonEnabledUsers = $Null
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
Write-Host ("Checking {0} mailboxes for Viva Briefing status" -f $Mbx.count)
ForEach ($M in $Mbx) {
   $Status = Get-UserBriefingConfig -Identity $M.UserPrincipalName
   If ($Status.IsEnabled -eq $True) {
      $EnabledMbx++
      $EnabledUsers += $M.DisplayName
   } Else {
      $NonEnabledMbx ++
      $NonEnabledUsers += $M.DisplayName }
}
[string]$EnabledUsers = $EnabledUsers -Join ", " 
Write-Host ("Viva Briefing is enabled for {0} mailboxes and disabled for {1} mailboxes. The following mailboxes are enabled: {2}" -f $EnabledMbx, $NonEnabledMbx, $EnabledUsers)

Waiting for Briefings

Microsoft will likely describe the improvements they make to increase the personalized content in Viva Briefing messages when they relaunch the service. Until then, we’ll just have to track commitments and action items using Outlook tasks, To Do, Planner, Project, or any of the other methods available in Microsoft 365.

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

Part of the Effort to Move Exchange Online to Modern Authentication

Updated March 27, 2023

Microsoft’s December 15 announcement of the deprecation of Remote PowerShell (RPS) for Exchange Online was predictable but regrettable. Not that I want to keep RPS. Microsoft built RPS to allow administrators to manage Exchange 2010 on-premises servers from local workstations. But time moves on and RPS started down the slippery slope to oblivion when Microsoft began to modernize Exchange Online PowerShell with the introduction of the REST-based cmdlets in 2019. That process came to a head with the launch of V3.0 of the Exchange Online management module in September 2022.

Update: Microsoft issued message center notification MC488586 (20 Dec 2022) for this change.

Update 2: Microsoft has stretched things out to allow customers some extra time to prepare for the change. Remote PowerShell will work in tenants where it’s used today until the end of September, 2023. After that, no more Remote PowerShell. An opt-out tool is available for tenants to request the extra time.

Heading to the V3 Module

What’s happening is part of a phased approach to force Exchange Online tenants to use the V3 module.

• Usage of the V1 module will cease when Microsoft finally blocks basic authentication for connectivity protocols on January 1, 2023. This is a good thing because all clients, including PowerShell, should use modern authentication.
• Usage of the V2 module (the version that originally launched the REST cmdlets) will stop with the deprecation of this module on July 1, 2023. Although the V2 module supports modern authentication, many of its cmdlets are not modernized and therefore still have some dependencies on components like basic authentication via WinRM.
• Microsoft will stop all RPS connections from October 1, 2023. This means that any script that connects to Exchange Online using the New-PSSession cmdlet or by specifying the –UseRPSSession parameter with the Connect-ExchangeOnline cmdlet will fail and you’ll see errors like that shown in Figure 1.

With the Exchange Online management V3 module available for over two months and a deprecation date set six months away (June 30, 2023), why would anyone be upset that Microsoft has chosen to proceed to retire RPS?

Easy Change to Remove Remote PowerShell

Making the change to modern authentication without Remote PowerShell for Exchange Online is easy. First, make sure that all workstations run V3 of the Exchange Online management module. If you use Azure Automation to run Exchange Online scripts, make sure to update the Azure accounts with the Exchange Online V3 module. I use script to periodically check and update modules on local workstations and Azure Automation.

Next, find all the scripts that connect to Exchange Online and look for instances of:

New-PSSession -ConfigurationName Microsoft-Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid

Editorial note: There are many internet articles that inform readers that this is the way to connect to Exchange Online PowerShell. Many of the blogs are quite old, but I found some published in 2022 (here’s an example).

Other scripts might use the Connect-ExchangeOnline cmdlet with the –UseRPSSession parameter. I think these scripts will be less common. My concern is with old scripts that no one has looked at in a while.

Once you find the scripts, you can modify their code to use Connect-ExchangeOnline. Be sure to test the scripts afterward. Apart from the connection, no changes are necessary to cmdlets.

The compliances cmdlets contained in the Exchange Online management module continue to have a dependency on remote PowerShell. Microsoft plans to remove that dependency in the future but hasn’t provided a firm date for the change.

The Azure AD Conundrum

Microsoft wants to eliminate RPS by the end of June 2023, which is the same deadline chosen for the deprecation of the Azure AD and Microsoft Online Services (MSOL) PowerShell modules (license management cmdlets stop working after March 31, 2023). The deprecation of these modules has been delayed multiple times, but as the date approaches tenant administrators know that they must upgrade scripts to use cmdlets from the Microsoft Graph PowerShell SDK or Graph API requests. No automatic tool is available to upgrade scripts. It’s a manual process to review code, decide what SDK cmdlet might be an appropriate alternative, make the change, and then test. This is time consuming work.

For the Exchange development group to choose the same date to deprecate RPS shows an unfortunate and unhappy lack of awareness of what’s happening in the Microsoft 365 ecosystem. It’s possible that an assumption exists that different developers deal with Azure AD and Exchange Online. That assumption might be correct on-premises where the lines between Active Directory and Exchange Server are more distinct. Inside Office 365, the need for close interconnection between Azure AD and Exchange Online is obvious. Even Microsoft acknowledged this when they introduced the dual-write mechanism to update Azure AD and the Exchange Online directory some years ago.

Overall, it would be better if Microsoft pushed the date out a little to give tenant administrators and developers time to finish the Azure AD transition before needing to deal with RPS.

New Year Might Bring Relief

No doubt the Exchange developers will let us know more details about the strategy they’re pursuing to eliminate RPS over time. For now, it seems like we’re heading for an unfortunate and avoidable clash of PowerShell update exercises. That’s bad news. Let’s hope that something changes to ease the problem in 2023.

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

Set Message Expiration Timeout Interval From 12 hours to 1 Day

I haven’t heard of a demand for a customizable message expiration timeout interval but apparently the need exists. At least, according to message center notification MC441064 (updated 8 December), Microsoft is rolling out a change to enable the capability to tenants now, delayed about a month from the original intent to deploy between mid-October and mid-December. The change is covered by Microsoft 365 roadmap item 93315.

MC441064 says that the ability to customize the message expiration timeout interval is a common request. This might be true for large enterprises, who tend to make these kinds of request, but I’m unsure if the same is true for the majority of Microsoft 365 tenants where administrators often leave default settings in place simply because there are too many jobs to be done.

Expiring Queued Messages That Cannot be Sent

In any case, the message expiration timeout interval governs how long the Exchange transport service holds a message when it cannot be delivered. Normally, the transport service processes messages immediately after sending by making a connection to the destination server and passing the message to that server. Transient errors like network glitches or server unavailability can stop a message leaving Exchange Online, and when this happens, Exchange Online puts the message in a retry queue and attempts to deliver it periodically (after 30 minutes initially and then after every hour).

If a message expiration timeout interval didn’t exist, Exchange Online would keep on retrying to send failed messages from here to eternity. The function of the timeout interval is to set a period after which Exchange Online should inform the sender that it cannot process the message for some reason. The key thing in setting the expiration timeout is to give Exchange sufficient time to allow transient errors to subside and allow queued messages to travel to their destination while not taking so long that the sender is left in limbo with no indication that their message is stuck. After a while, an email can become like a dead fish: it’s still a message but its contents are no good because so much time has elapsed.

Setting a Message Expiration Timeout Interval

The default message expiration timeout interval for Exchange Online is one day. This is a reasonable balance between the time needed to resolve issues and a message still being valid when delivered. The change being made allows tenant administrators to set the interval to any value between 12 and 24 hours. Reducing the interval means that Exchange will expire queued messages faster. Users will receive a non-delivery response (NDR) when their messages expire and because this happens sooner, users will be able to action the problem faster. For instance, they might decide to send the email to a different address.

To configure the message expiration timeout interval, use PowerShell to connect to the Exchange Online management module and run the Set-TransportConfig cmdlet. For instance, to set the interval to 12 hours and 30 minutes, the command is:

Set-TransportConfig -MessageExpiration 12:30:00

To check the value, use the Get-TransportConfig cmdlet:

Get-TransportConfig | Select-Object MessageExpiration

MessageExpiration
-----------------
12:30:00

Figure 1 shows details from an NDR returned to a user after changing the message expiration timeout interval (in this instance, to 12 hours). The original message is dated 13:24 on December 9. The NDR arrives at 13:29 on December 10. We won’t quibble about the extra five minutes!

Things are a little different for on-premises Exchange Server as administrators have more control over how the transport service works. Here’s Microsoft’s advice about configuring message intervals for Exchange 2019.

Message Expiration Timeout is Now Tenant Choice

Any tenant can customize the message expiration timeout interval. However, I suspect that those who do will be organizations that want users to know as soon as possible if problems exist in sending email. Reducing the interval to 12 hours might help, but I guess that depends on if the user is available to receive the NDR and take action to reprocess the failed message.

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

Report Who Released a Quarantined Message

The question was asked on Twitter about whether it is possible to notify end users when administrators release outbound messages from the quarantine. Most of the time, email ends up in quarantine when Exchange Online Protection decides that inbound messages contain spam or malware, but it’s possible to direct outbound email to quarantine using mail flow rules or actions invoked by Microsoft Purview DLP policies. Exchange Online can certainly quarantine problematic messages but as far as end users are concerned, outbound messages intercepted in this way go into a black hole.

Some good suggestions resulted. My initial response was to use the Get-QuarantineMessage cmdlet to periodically check messages in quarantine and detect released items on that basis. Michel de Rooij came up with a better solution to use a mail flow rule to look for the X-MS-TrafficTypeDiagnostic or X-MS-Exchange-Generated-Message-Source email headers to see if they were related to quarantine releases. That’s quite an innovative approach. However, in both cases, the problem exists that you don’t have all the information about a quarantined message following its release.

Check the Audit Log

Which brings me to the unified audit log. Exchange Online generates audit events for most operations, including when an administrator releases a message from quarantine. Administrators can search the unified audit log by running the Search-UnifiedAuditLog cmdlet to look for QuarantineReleaseMessage events. For example:

$StartDate = (Get-Date).AddDays(-90)
$EndDate = (Get-Date).AddDays(1)

[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 1000 -Operations QuarantineReleaseMessage
If (!($Records)) { Write-Host "No audit records found for quarantine release - exiting" ; break }

This search finds all events logged over the last 90 days when someone released a message from quarantine. The problem is that the information captured in audit log records tells us who released a message but doesn’t tell us anything about the message. For instance, the audit record doesn’t capture the direction of the message (inbound or outbound), the sender, its recipients, and the message subject.

That information is available in the data recorded for quarantined messages. It is therefore possible to capture information about quarantined messages periodically and store the data in a repository that can be checked to retrieve message details. To prove the point, I created a PowerShell list and populated it with details of quarantined messages. Here’s the code I used:

[array]$QM = Get-QuarantineMessage
$QMData = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Item in $QM) {
  $DataLine = [PSCustomObject] @{
   Received     = $Item.ReceivedTime
   MessageId    = $Item.MessageId
   Direction    = $Item.Direction
   Sender       = $Item.SenderAddress
   Recipients   = $Item.RecipientAddress -Join ", "
   Subject      = $Item.Subject
   Type         = $Item.Type
   Expires      = $Item.Expires
   Identity     = $Item.Identity 
   Id           = $Item.Identity.Split("\")[0]}

  $QMData.Add($DataLine)
} # End ForEach Item

Creating a Composite View of Quarantine Message Release

Now that we have data for quarantined messages, let’s use it to create the information needed to communicate with users. This code creates another PowerShell list and then loops through the audit records retrieved earlier. The code checks each audit record against the data for quarantined messages to see if a match exists. If it does, we grab the information about the message and combine it with the information from the audit record to generate a composite view about the release from quarantine.

$QMInfo = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Rec in $Records) {
  $AuditData = $Rec.AuditData | ConvertFrom-Json
  [array]$QMFound = $QMData | Where-Object {$_.Id -eq $AuditData.NetworkMessageId}
  If ($QMFound) {
     ForEach ($Item in $QMFound) {
       $DataLine = [PSCustomObject] @{
         MessageId  = $AuditData.NetworkMessageId
         Received   = $Item.Received
         Sender     = $Item.Sender
         Recipients = $Item.Recipients
         Subject    = $Item.Subject
         Type       = $Item.Type
         Expires    = $Item.Expires
         Releasedby = $AuditData.UserId
         ReleasedAt = $Rec.CreationDate }
       $QMInfo.Add($DataLine)
     } # End ForEach $QMFound
    } # End If
} # End ForEach $Records

Figure 1 shows examples of the composite records generated by the code.

After generating the composite data, it’s then a matter of deciding how to notify end users.

A Directional Oddity

One oddity I noticed is that PowerShell reported a quarantined message as “Outbound” (going out of the tenant) while the Microsoft 365 Defender admin center was certain that the message was “Inbound” (coming into the tenant). Figure 1 shows what Defender reports.

And here’s what Get-QuarantineMessage reported. The other message properties indicate that the message is definitely inbound, so I have no idea why PowerShell thinks otherwise.

Identity                   : 2a008698-201e-497f-3dee-08dad2e835e2\7129d58d-ca5e-7e32-a4f8-676d082ba9af
ReceivedTime               : 30/11/2022 15:33:20
Organization               : a662313f-14fc-43a2-9a7a-d2e27f4f3478
MessageId                  : <PA4PR06MB7264B28C1D73C9EB547DDC5AB8159@PA4PR06MB7264.eurprd06.prod.outlook.com>
SenderAddress              : missf0rtune@hotmail.co.uk
RecipientAddress           : {tony.redmond@xxx.com}
Subject                    : Document 49KB (tony.redmond@xxx.com)
Size                       : 93651
Type                       : High Confidence Phish
PolicyType                 : HostedContentFilterPolicy
PolicyName                 : Default
TagName                    : AdminOnlyAccessPolicy
PermissionToBlockSender    : True
PermissionToDelete         : True
PermissionToPreview        : True
PermissionToRelease        : True
PermissionToRequestRelease : False
PermissionToViewHeader     : False
PermissionToDownload       : True
Released                   : False
ReleaseStatus              : NOTRELEASED
SystemReleased             : False
RecipientCount             : 1
QuarantineTypes            : HighConfPhish
Expires                    : 15/12/2022 15:33:20
RecipientTag               : {Priority Account}
DeletedForRecipients       : {}
QuarantinedUser            : {}
ReleasedUser               : {}
Reported                   : False
Direction                  : Outbound

Looking Everywhere for Data

Often people become dismayed when they look for information and discover that a source doesn’t deliver all the detail they need. It’s often the case inside Microsoft 365 that you can combine data from different sources to come up with an answer. It would be nice if Microsoft captured all the relevant message for a quarantined message release in the audit records, but at least we can find the data.

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

Use a Historical Message Trace to Find Inbound Email Delivered to Shared Mailboxes

Updated 24-Oct-2023

A question in the Facebook group for Office 365 Technical Discussions (no YouTube videos or marketing posts accepted) asked how to check shared mailboxes for email received from external senders over the past sixty days. The check should look for email received from a specific domain and report details of those messages.

Given the number of shared mailboxes that might be used in a tenant and the volume of email that these mailboxes might receive, running a manual check is not feasible. You would have to sign into each mailbox and review their content. This is a tiresome process that wouldn’t detect messages received from the specific domain that users subsequently deleted (or messages removed by a retention policy).

Exchange Historical Message Traces

Exchange Online historical message traces can go back a maximum of 90 days, so they can be used to search the data logged by Exchange Online when it delivers messages to mailboxes. A single historical message trace can cover up to 100 sender or recipient addresses. If a tenant wants to check email related to a larger number of addresses, they can split the check across multiple searches and combine the results.

It all sounds so easy to script. Run the Start-HistoricalSearch cmdlet to submit the message trace. Check the output. Find and report problem messages. Easy. But as is so often the case, some complexity lurks under the surface.

Submit a Historical Message Trace and Wait

The PowerShell code to automate the check must be split into two scripts. The first creates and submits the historical message trace job. The second analyzes the results of the trace. The two cannot be connected because Exchange Online runs historical message trace jobs in the background as service resources allow. If you’re lucky, a message trace might complete in less than twenty minutes. More often, it will take an hour or so.

Here’s the code I used to submit the job. It finds the set of shared mailboxes, sets the search period, and creates the parameters for the Start-HistoricalSearch cmdlet to process. As noted above, a historical message trace can process up to 100 mailboxes, so a check is there to make sure that we don’t attempt to schedule a job for more than this number of mailboxes.

# Find all shared mailboxes
[array]$SharedMailboxes = Get-ExoMailbox -RecipientTypeDetails SharedMailbox 
If ($SharedMailboxes.Count -gt 100) { 
   Write-Host ("Too many shared mailboxes found - we can't do a message trace for {0} mailboxes" -f $SharedMailboxes.Count) ; break 
}
[array]$RecipientAddresses = $SharedMailboxes.PrimarySmtpAddress

# Submit historical search (maximum of 250 per day)
Start-HistoricalSearch -RecipientAddress $RecipientAddresses -StartDate (Get-Date).AddDays(-60) -EndDate (Get-Date) -ReportType MessageTrace -ReportTitle ("Report Shared Mailbox {0}" -f (Get-Date))

Although you could code a loop to use the Get-HistoricalSearch cmdlet to check the progress of the search job and resume when the job completes, a further complication is that Exchange Online stores the message trace results in Azure storage. There’s no way for PowerShell to download the data for processing. Instead, an Exchange administrator goes to the Mail flow section of the Exchange admin center to view the status of historical message trace jobs and download the results if the job to scan for shared mailbox traffic is complete (Figure 1).

Processing Historical Message Trace Results

Exchange Online downloads the message trace results using a URL like:

https://admin.protection.outlook.com/ExtendedReport/Download?Type=OnDemandReport&RequestID=044439ab-614e-4ec6-b4d9-a095c92befbe

The result is a CSV file in the Downloads folder with a name with a “MTSummary_Report” prefix followed by the historical message trace name and an identifier. For instance:

MTSummary_Report Shared Mailbox Scan 12062022 184532_044439ab-614e-4ec6-b4d9-a095c92befbe

Occasionally, the data generated by Exchange Online doesn’t import properly into PowerShell using the Import-CSV cmdlet. To make sure that everything works, I open the downloaded file with Excel and save it to a known location, like c:\temp\MessageTraceResults.csv. The save seems to cure any lingering data formatting problems.

We can now process the data by first searching the records to find if any originated from the domain of interest. For the purpose of this exercise, I’ll search for messages originating from Practical365.com:

[array]$MessageData = Import-CSV c:\temp\MessageTraceResults.CSV
[array]$ProblemItems = $MessageData | Where-Object {$_.Sender_Address -like "*practical365.com"}
If (!($ProblemItems)) { Write-Host "No email found from Practical365.com - exiting" ; break }

Creating a report from the discovered items is simple:

$ProblemInfo = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Item in $ProblemItems) {
  $DataLine = [PSCustomObject] @{
   Timestamp = Get-Date($Item.origin_timestamp_utc) -format g
   Sender    = $Item.Sender_Address
   Subject   = $Item.Message_Subject
   Recipient = $Item.Recipient_Status.Split("##")[0] }
  $ProblemInfo.Add($DataLine)
} # End ForEach Item

Figure 2 shows the report of the messages received from Practical365.com.

Getting the Job Done

Some organizations extract and move message trace data to external repositories like Splunk to make it easier to perform this kind of tracing. An external repository usually allows for long-term storage and is more flexible in terms of its search capabilities. However, the basic tools built into Exchange Online can do the job, even if the PowerShell processing is split into two tasks. It would be nice if Microsoft allowed tenants to download the message trace data with PowerShell to avoid the messing around with CSV files, but that’s just a small complaint.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

A New Take on an Old Favorite Script

In the past, I’ve written several times about using PowerShell to report the membership of Exchange Online distribution lists. Support of multiple mail-enabled objects, including nested groups, makes the extraction of full distribution list membership trickier than simply running the Get-DistributionGroupMember cmdlet and a variety of techniques have been used over the years to expand and report all members using Exchange Online and Azure AD cmdlets and Microsoft Graph API requests.

Normally, I don’t return to the same topic again and again. The reason why I’m back here for a third bite at the cherry is that Microsoft will deprecate the Azure AD PowerShell module on June 30, 2023. Although it’s possible to use Microsoft Graph API requests to report distribution list membership (with a caveat), some would prefer to convert their scripts to another PowerShell module rather than going full-blown Graph. I guess the Microsoft Graph PowerShell SDK is that half-way stop, so here goes.

Using the Graph SDK with Group Memberships

It’s important to understand that the Microsoft Graph PowerShell SDK interacts with Azure AD groups. Distribution lists are Exchange Online objects that synchronize to appear as groups in Azure AD. However, although distribution lists support membership of mail-enabled objects that are unique to Exchange, like mail-enabled public folders, these objects don’t show up in membership reported by Azure AD. The reason is simple: the objects don’t exist in Azure AD. What does show up are the objects supported by Azure AD: user accounts (including guests), contacts, and groups. That’s what you see when you run the Get-MgGroupMember cmdlet to retrieve group membership.

Because distribution groups support nested groups, we need a way to expand the members of nested groups and resolve duplicate member entries that might exist. This can be done using a Graph query to fetch transitive members. The transitive query does all the work to expand nested groups and return a unified set of members.

Because a Graph API request exists to fetch transitive members, an equivalent cmdlet is available in the Microsoft Graph PowerShell SDK. That cmdlet is Get-MgGroupTransitiveMember. For example, this call fetches all the members in the group pointed to by the variable $DL.ExternalDirectoryObjectId.

[array]$Members = Get-MgGroupTransitiveMember -GroupId $DL.ExternalDirectoryObjectId

Objects synchronized from Exchange Online to Azure AD store their Azure AD identifier (GUID) in the ExternalDirectoryObjectId property. For instance, a mailbox stores the identifier for its owning Azure AD user account in the property. Azure AD treats a distribution list like any other group, and so it has a group identifier that’s stored in the property. That identifier is the one we use to extract distribution list membership with Get-MgGroupTransitiveMember.

Get-MgGroupTransitiveMember returns a list of identifiers. In earlier versions of the Microsoft Graph PowerShell SDK, you had to resolve the identifiers into useful information, like the display names of individual group members. Now, the group cmdlets return the information in an array of member details stored in the AdditionalProperties property, which means that we can find what we want by extracting it from the array. For convenience, I usually extract the array into a separate variable:

[array]$MemberData = $Members.AdditionalProperties

You might ask why Microsoft decided to update the groupcmdlets to output the member data in a separate property instead of changing the default to output the list of members (which is how cmdlets like Get-AzureADGroupMember work). One explanation is that changing the output of a cmdlet will break existing scripts. In that context, it’s understandable to include a new property.

Parsing Distribution List Membership

After fetching the transitive membership for a distribution list, the remaining task is to figure out how many members of the different categories are in the set (members, contacts, and groups). This is easily done by counting the items in the set. After it gathers this basic information about the group, the script updates a PowerShell list with the data.

You can drive some other processing from the list. For instance, you might decide to convert any distribution list with over 100 members to a team (use the same kind of approach as described here to covert a dynamic distribution list to a team). An easier decision might be to remove any distribution list found with zero members on the basis that they’re no longer in use. This is easily done with:

$Report | Where-Object {$_.Members -eq 0} | Remove-DistributionGroup

To be safe, I left the confirmation prompt in place so that you’re asked to confirm the deletion of each distribution list. You can suppress the prompt by adding -Confirm:$False to the command.

Reporting Distribution List Membership

The final stage is to generate output, which the script does in the form of a CSV file and HTML file (Figure 1). This ground is well-known and there’s no mystery in the code needed to generate the files.

Converting from Azure AD cmdlets to Microsoft Graph PowerShell SDK cmdlets is not challenging – once you understand how the Graph SDK works. The trick is to make no assumptions about the input parameters or the output a cmdlet produces. You might expect things to work in a certain way, but the chances are that they won’t, so go into the conversion in the spirit of a voyage of discovery and you won’t be disappointed. To help, here’s the script to report distribution list members using the Microsoft Graph PowerShell SDK.

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

Dynamic Group Membership is the Obvious But Not the Only Option

A member of the Microsoft Technical Community asks if it’s possible to automatically add newly-created accounts to an existing group. The initial response offered by the community focused on dynamic groups – either dynamic distribution lists or dynamic Azure AD groups.

It’s a reasonable suggestion. Dynamic distribution groups are part of base Exchange Online functionality and don’t require any additional licenses. Dynamic Azure AD groups require Azure AD Premium P1 licenses for every account covered by dynamic membership. In both cases, the trick is to make sure that the query used by Exchange Online or Azure AD to determine group membership finds the new account.

Dynamic Group Membership for Exchange Online Mailboxes

It’s possible to create a dynamic distribution group based on a simple query like “all mailboxes” that will automatically include new accounts (if they have mailboxes). Figure 1 shows the UX in the Exchange admin center (EAC) to define the membership of a new dynamic distribution list.

The list works and email sent to it arrives in the inbox of every mailbox in the tenant, including shared mailboxes. This is because the recipient filter generated by Exchange Online for the dynamic distribution group selects all mail-enabled objects with a recipient type of ‘UserMailbox’ and only filters out some system mailboxes.

A dynamic distribution list like this is said to use a “canned” recipient filter because Exchange Online generates the filter based on the choices the administrator makes when they create the new list. You can only edit canned filters through the EAC. Exchange Online gives greater flexibility through the support of custom recipient filters. These filters can only be created using PowerShell, but they’re much more flexible in terms of selecting the set of mail-enabled objects to address through the list. A simple custom recipient filter to find just user mailboxes is shown below together with a test with the Get-Recipient cmdlet to prove that the filter works.

$Filter = "{RecipientTypeDetails -eq 'UserMailbox'}"
Get-Recipient -RecipientPreviewFilter $Filter

Dynamic Group Membership for Azure AD User Accounts

Dynamic Azure AD groups can be used with Microsoft 365 groups and Teams. These groups use different membership filters (query rules) to find the set of target objects. Instead of mail-enabled objects like mailboxes, the query against Azure AD focuses on user accounts rather than mailboxes. However, the same capability exists in that it’s possible to create a dynamic Azure AD group that includes all user accounts, including those newly created.

Again, the key is to construct a query rule that finds all user accounts – of the right type. When Azure AD is used for a Microsoft 365 tenant, there are many non-interactive user accounts created to give identities to objects such as shared mailboxes and room mailboxes. These are all considered “member” accounts and it’s easy to build a rule to find all member accounts. However, you probably want a more refined version that finds just the accounts used by humans.

Azure AD doesn’t have a human filter, so we need to construct something that Azure AD can use to find matching accounts in its directory. One approach is to use licenses for the check. You could look for accounts assigned Office 365 E3 licenses but would have to check for accounts with F1 or E5 licenses too. An easy change is to look for accounts that have any license that has at least one enabled service. For instance, accounts with Office 365 E3 or E5 licenses with the Exchange Online, Teams, Planner, or SharePoint Online service would all match. Figure 2 shows a test of the rule against a “real” user account and some other user accounts belonging to room and shared mailboxes. You can see that the real account passes the validation test while the others do not.

Azure AD accounts used by shared mailboxes must be assigned licenses when they need more than 50 GB of mailbox storage or an online archive. These accounts satisfy the membership rule, but that’s perhaps not important. If it is, some tweaking of the membership rule is necessary to remove the shared mailbox accounts.

Dynamic Group Membership of Org-Wide Teams

If your organization is smaller than 10,000 accounts, new Azure AD accounts automatically join the org-wide teams in the tenant (a tenant can support up to five org-wide teams). Org-wide teams are a special form of dynamic Microsoft 365 group whose membership is controlled by Teams rather than Azure AD, so Azure AD Premium P1 license are not required.

The PowerShell Alternative to Manage Dynamic Group Membership

If you don’t want to use a dynamic object, it’s certainly possible to use standard distribution lists or Microsoft 35 groups. In this scenario, the tenant takes the responsibility for maintaining group membership. Usually, PowerShell is used to add new accounts to group membership. You don’t have to worry about removing deleted accounts from the group as this happens automatically following an account deletion.

To add a new user to a distribution list, use the Add-DistributionGroupMember cmdlet:

Add-DistributionGroupMember -Identity "All Tenant Mailboxes" -Member Lotte.Vetler@office365itpros.com

To add a new user account to a Microsoft 365 group, either run the Add-UnifiedGroupLinks cmdlet (from the Exchange Online management module) or the New-MgGroupMember cmdlet (from the Microsoft Graph PowerShell SDK):

Add-UnifiedGroupLinks -Identity "All Tenant Accounts" -LinkType Member -Links Lotte.Vetler@office365itpros.com

New-MgGroupMember -GroupId "107fe4dd-809c-4ec9-a3a1-ab88c96e0a5e" -DirectoryObjectId (Get-MgUser -UserId Lotte.Vetler@office365itpros.com).Id

If the tenant creates user accounts programmatically with PowerShell, these commands can be added to that script. If not, a background scheduled job could find accounts that don’t exist in group membership and add them. See this article for more information about group management with the Microsoft Graph PowerShell SDK.

Many Possibilities to Ponder

A simple question required a long answer. That’s because the questioner didn’t specify what type of group that they wanted to add new accounts to. In any case, it’s nice to be able to debate the possibilities and then settle on the best course of action to take.

Insight about the various options to manage dynamic group membership for new accounts doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

No Support for Auto-Expanding Archives in Any Version of Exchange Server

I was surprised that Microsoft had to announce that they have had to programmatically block any attempts to move auto-expanding archive mailboxes from Exchange Online to on-premises servers (MC467234, updated 24 November 2022). The new block should be effective worldwide by the end of December 2022.

Microsoft’s documentation has always been precise on the topic, saying “after auto-expanding archiving is enabled for a cloud-based archive mailbox, you can’t off-board that archive mailbox back to the on-premises Exchange organization. Auto-expanding archiving isn’t supported for on-premises mailboxes in any version of Exchange Server.”

I cannot remember Microsoft being anything but clear on this point. Since the announcement of the feature in June 2015 (the blog post is now offline), it has always been the case that only Exchange Online supported auto-expanding archives. The technology appeared in Exchange Online in 2016 but experienced some teething difficulties that meant that full worldwide deployment didn’t happen until early 2018. At that point, Microsoft wasn’t going to retrofit such a huge technical change on Exchange 2016 and nothing was done to implement auto-expanding archives in Exchange 2019, which is the current situation.

Block to Stop Offboarding Auto-Expanding Archives to Exchange Server

The interesting question is why Microsoft feels it necessary to introduce a new block. Obviously, some customers have tried to move mailboxes with auto-expanding mailboxes back to on-premises servers to find that things don’t go so well. The new block will cause any attempted moves to “gracefully fail with no data loss,” which is quite a relief.

Essentially, once an organization enables auto-expanding archives, it increases its connection to Exchange Online. It’s possible to offboard a mailbox with an auto-expanding archive, but only the primary mailbox can move to on-premises Exchange. The archive remains in the cloud. It remains possible to move Exchange Online mailboxes with simple archives back on-premises.

Important Points About Auto-Expanding Archives

Other important facts about auto-expanding archives include:

• Exchange Online supports the choice of auto-expanding archives for the entire organization or selected mailboxes.
• After an archive mailbox becomes auto-expanding, it is always auto-expanding. The archive mailbox cannot be transformed into a simple archive mailbox again. Although the archive status for mailboxes is visible in the Exchange admin center, EAC doesn’t tell you if the archive is simple or auto-expanding (Figure 1).

• Administrators must use PowerShell to work with auto-expanding mailboxes. For example, to enable an individual mailbox, run the Enable-Mailbox cmdlet:

Enable-Mailbox -Identity Terry.Hegarty -AutoExpandingArchive 

• To find the set of mailboxes enabled for auto-expanding mailboxes, use the Get-EXOMailbox cmdlet to find the set of user and shared mailboxes and apply a client-side filter against the set to find those with the AutoExpandingArchiveEnabled property set to True.

Get-EXOMailbox -RecipientTypeDetails UserMailbox, SharedMailbox -Properties AutoExpandingArchiveEnabled -ResultSize Unlimited | Where-Object {$_.AutoExpandingArchiveEnabled -eq $True } | Format-Table DisplayName, RecipientTypeDetails

• Exchange Online automatically begins the auto-expanding process when an archive mailbox reaches 90% capacity (99 GB of the 110 GB assigned quota). Exchange Online increases the normal archive quota from 100 GB to 110 GB to accommodate auto-expansion. Some older mailboxes might still have 100 GB archive quotas even when enabled for auto-expansion. This problem can be fixed by re-enabling auto-expansion for the archive.
• You can’t recover or restore an inactive mailbox if it has an auto-expanding archive. Instead, you must export the data from the archive using the results of a content search and import the data into another mailbox.
• The limit for an auto-expanding archive is 1.5 TB (here’s a script to report archive status). Originally, Microsoft publicized auto-expanding archives as “bottomless,” but operational and software issues made it necessary to impose a limit.
• Shared mailboxes support auto-expanding archives if you assign an Exchange Online Plan 2 license to the mailbox.

Not Many Organizations Use Auto-Expanding Archives

My judgement is that this change is likely to affect relatively few organizations. First, not every Exchange Online organization uses archive mailboxes. Exchange Online makes large 100 GB primary mailboxes available to enterprise accounts, so there’s less need to offload old email to archive mailboxes. Only Exchange mailbox retention policies can move items automatically. Microsoft would like customers to use Microsoft Purview retention policies instead, but Purview policies can’t move items to the archive.

Second, of the total archive population, there’s probably a low percentage that is enabled for auto-expanding archives. It’s natural to leave mailboxes with simple archives unless they need auto-expansion. Those high-traffic mailboxes tend to be more important than the norm. For instance, those used for customer communications or by public-facing executives who receive large volumes of inbound email and need to retain copies for compliance purposes.

Mailboxes with auto-expanding archives must remain in the cloud. Apart from not being able to transfer these mailboxes to on-premises Exchange, it’s not altogether clear how you could move a large expanded archive anywhere else. Exporting the archive via a content search is the obvious answer, but processing up to 1.5 TB of data will take some time.

Although content search exports can accommodate up to 2 TB, the maximum size per PST for output is 2 GB and the search can upload a maximum of 2 GB of mailbox data per hour. All the data from the archive must upload to Azure before it can download to PSTs. Only a small number of auto-expanding archives will be more than 1 TB. In addition, search filters can reduce the amount of exported data to practical amounts at the expense of leaving some data behind. That might be an acceptable solution in some cases.

I’m not sure how many mailboxes will run into the new block. However, the news that a block is necessary will help organizations who have auto-expanding archives or those considering using auto-expanding archives to plan accordingly. It’s a good reminder that if you use a cloud-only feature, the technology is only available in the cloud.

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

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

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

New Support for Folders and Rules

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

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

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

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

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

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

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

Organization-Wide Settings

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

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

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

Group-Level Setting

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

Rules

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

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

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

Progress But More to Do

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

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

Part of the Ongoing Transition from the Legacy EAC

The ongoing saga of the transition from the old Exchange admin center (EAC) to the super-duper modern edition continues. The latest move involved mail flow rules (aka transport rules), described in Message center notification MC449929 (25 October). Microsoft flags the change as a major update, but it really isn’t because it will affect the very small minority of people who work with mail flow rules.

Microsoft will begin to retire the mail flow rules section from the old EAC in November and it should disappear from all tenants by the end of 2022. Eventually, the old EAC will disappear entirely. I won’t shed any tears when this happens as I never liked the layout of the now-legacy EAC (Figure 1). It is very much an artifact of a Microsoft design language that features large expanses of white space.

Two years ago, I noted that, despite missing some useful functionality, the new EAC represents the future. Time flies when you’re having fun and the developers must be laughing merrily because the last two years has gone without a huge amount of progress. No doubt some will point out the difficulty of moving existing infrastructure to a new framework, but it’s not like Microsoft hasn’t done this before. It seems like some of the experience gained in transitioning other administrative portals hasn’t been used. For instance, refreshing access tokens is not done as smoothly in EAC as it is in the Microsoft 365 admin center.

An Enhanced UX

The Microsoft documentation assures us that the new UX (Figure 2) “has been enhanced and modernized. This updated experience is consistent with the new EAC design and will enable easier rule management.” It also points out that the new UX exposes more information about rules. You can see the effect by comparing how the legacy and new EAC display details of the same rule (to include a disclaimer to calendar meeting requests) in Figures 1 and 2.

With that point in mind, let’s consider the details.

Revised Workflows

Although Microsoft says that most workflows (how you create and work with rules) are unchanged, they highlight three major differences:

EAC disables newly-created rules. This is a smart move because it stops mail flow rules becoming active immediately on creation. It’s quite likely that some tweaking is necessary before making a rule active.

EAC features a new rule creation wizard to guide people through the configuration of mail flow rules. Mail flow rules can be quite complex and having a wizard sounds like a good idea, if the wizard wasn’t just plain broken. Take the example shown in Figure 3, which creates a simple disclaimer rule. Despite completing all the necessary steps, there’s no way to move to the next stage in the process. The wizard stays dumb and refuses to say what’s wrong, so there’s no obvious way to proceed and complete the rule. No doubt Microsoft will sort out this glitch and in the interim, there’s always the New-TransportRule cmdlet!

The “landing page” shows if rules stop processing when executed. Mail flow rules have a priority order which dictates the sequence of processing within the Exchange transport service. The stop processing rules setting exists to prevent Exchange running any remaining rules. For instance, if a rule rejects a message and issues a non-delivery notification, it’s appropriate for it to signal to Exchange Online that it should stop processing any remaining rules. Knowing what rules stop processing is obviously important, so Microsoft now highlights the setting in the list of rules (Figure 4)

What’s Missing for Mail Flow Rules

Moving the mail flow rules over to the new EAC is a good thing. It’s just disappointing that everything associated with the new EAC seems to happen so slowly (even if Microsoft isn’t moving some features, like bulk distribution list migration). Taking up so much time to perform what appears to be relatively straightforward tasks leaves less time to improve management of mail flow rules. Essentially, the same type of management of mail flow rules exists in Exchange Online that Exchange 2007 had 16 years ago. The interface is prettier, but the same functionality largely exists.

The processing of Mail flow rules can become very complex when an organization uses more than ten rules. It would be nice if Exchange Online delivered some way to visualize the path of a message through the set of defined rules to help administrators understand what happens as different rules run. Maybe Microsoft will get to something like this when they’ve completed the transition to the new EAC sometime in the next decade.

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

No Point in Preserving a Feature No One Uses

Tired of pushing water uphill, the Exchange development group announced plans to deprecate the EAC feature to migrate distribution lists in bulk to Microsoft 365 Groups (Figure 1). The news comes as no surprise because the feature has not been maintained since its introduction in August 2016. At least, that’s what it seems like.

Microsoft says that the feature “was designed to provide continuity for DL users and to enable continued collaboration without having to make new groups from scratch. As Microsoft 365 Groups is now a mature feature, we are deprecating the feature for migrating DLs to Groups. The deprecation will happen on February 1, 2023.” The announcement makes no mention of the ability to convert an individual distribution list to a Microsoft 365 Group that’s included in the new EAC. It’s all about bulk conversion.

Changes Since 2016 Affected Outlook Groups

First introduced in November 2014, Office 365 Groups (now Microsoft 365 Groups) are certainly a mature technology. But more importantly, the technology environment that existed when Microsoft launched the distribution list migration feature in August 2016 was very different to today. At the time, Office 365 Groups had just picked up support for Azure B2B Collaboration (guest access) and seemed poised to be the cornerstone of Microsoft 365 collaboration.

Everything changed with the preview of Teams in November 2016 (general availability in February 2017). Today, Teams has more than 270 million monthly active users. The last number for Outlook groups is “more than 10 million” (April 2017). I’m sure some growth has happened in the five years since but maybe not much. Teams has sucked a lot of the oxygen out of the Microsoft 365 collaboration space.

Today’s reality is that the importance of Outlook Groups disappeared a long time ago and the major function of Microsoft 365 Groups is as a coordinating mechanism for group resources and the provider of membership services to Teams.

Other Factors in Play in Distribution List Migration

Two other factors are in play. First, Microsoft is busy trying to move functionality from the old Exchange admin center (EAC) to a modernized version. That process is taking far too long. Cutting features enables the transition to accelerate, which is a good thing.

Second, the bulk migration feature can only process simple distribution lists. The value of many distribution lists lies in their ability to include different types of mail-enabled recipient, including other distribution lists. Dynamic distribution lists are very powerful, especially with custom recipient filters, but the migration feature doesn’t support these objects either, even though dynamic Microsoft 365 Groups (and Teams) are.

Admittingly, dynamic Microsoft 365 Groups were a long way away in August 2016, but the fact that the migration feature has not maintained pace with technical developments within Microsoft 365 is evidence that no one has paid much attention to updating the distribution list migration code recently.

Microsoft’s Suggested Replacement is a Manual Conversion

Microsoft’s suggested approach is extraordinarily manual. Essentially, it’s the same approach that you’d take to move an on-premises distribution list to the cloud (create a new Microsoft 365 group and switch the DL attributes to it).

Although their suggestion is a valid approach, I’m surprised that Microsoft hasn’t created a script to automate the process. The task is not particularly difficult, especially if only “eligible” (simple, non-nested) distribution lists are the target. Microsoft might even be able to repurpose the code in the to-be-deprecated EAC feature, if only the appetite existed to deliver a conversion script to customers. Some old migration scripts are still available in the Microsoft download center that could have been updated and brought into service. Maybe Microsoft doesn’t want the hassle of supporting the code.

It’s even possible to script the conversion of dynamic distribution lists to Microsoft 365 Groups, albeit with static group membership because of the different filtering capabilities that exist in Exchange Online and Azure AD.

Migrations can be tough. I’m sure Microsoft has some data to justify their decision to deprecate the conversion feature. Maybe they’ve noticed a reduction in the use of distribution lists or that the percentage of Microsoft 365 Groups that aren’t team-enabled is dropping. Only Microsoft knows. What’s real is that February 1, 2023, will see the disappearance of a feature that once promised so much and ended up being a neglected disappointment.

Historical Searches Scan Message Trace Data for Up to 90 Days in the Past

It’s a while since I had the need to run some message traces for Exchange Online. At least, run traces that exceed the 10-day online window that Exchange Online supports for instant access to trace results. After this period, Exchange Online moves the message trace data (essentially what’s called the message tracing logs for Exchange Server) to an offline store. To get trace information going back further, administrators must submit an “historical search.”

Historical searches can go back 90 days. Historic is just another way of saying “your data is offline and we need to run a background job to retrieve the data.”

Why Some Message Traces Need to be Historic

When you think about the situation, Microsoft’s approach is very logical. Given the size of the Exchange Online infrastructure (300K mailbox servers processing 9.2 billion messages daily), keeping message trace data online for more than 10 days would occupy a lot of storage. Microsoft’s telemetry no doubt tells them that most message traces occur within 10 days of a message being sent, so we end up with the 10-day online trace limit.

In fact, historical searches can find messages within 1-4 hours. Exchange Online continually offloads message trace data to the offline store. To reduce strain on the service, a tenant can run up to 250 historical searches daily (another form of throttling) and the CSV files created by historical searches can contain up to 100,000 lines. Most tenants won’t hit these limits, but if you try to run too many searches in a 24-hour period, Exchange Online will warn you.

Running a Historical Search

In any case, my requirement was simple. A user wanted to know if they had received email from a known sender about two weeks ago. Unlike normal message traces, which administrators can run from the Exchange admin center (EAC), you can only create historical searches through PowerShell by running the Start-HistoricalSearch cmdlet.

Apart from regular message trace searches (the type I wanted), Start-HistoricalSearch can generate different reports. Vasil Michev documents those reports on his blog, so I can ignore them here. Instead, our needs are met by running a simple message trace report where the essential elements are the sender address, recipient address, start and end date, and report type. A command like this submits the historical search as a background job for Exchange Online to process.

Start-HistoricalSearch -SenderAddress John.Doe@domain.com -RecipientAddress Terry.Hegarty@office365itpros.com -StartDate 1-Sep-2022 -EndDate 26-sep-2022 -ReportType MessageTrace -ReportTitle 'Investigation 999'


JobId                                SubmitDate          ReportTitle          Status     Rows ErrorCode ErrorDescriptio
                                                                                                        n
-----                                ----------          -----------          ------     ---- --------- ---------------
3afbd203-32b1-43d1-a7cc-9d279476ce19 26/09/2022 19:58:55 Investigation 999    NotStarted 0

Don’t expect Exchange Online to start processing the job immediately. Unless it’s a period of very low service demand, this won’t happen. Instead, the job remains queued until Exchange has some resources to handle the request. Go away and have a coffee and then check if the job has progressed. If you must, use the Get-HistoricalSearch cmdlet to monitor progress:

Get-HistoricalSearch -JobId 3afbd203-32b1-43d1-a7cc-9d279476ce19 | Select ReportTitle, Status

ReportTitle          Status
-----------          ------
Investigation 999    NotStarted

Don’t get excited when you see that a job status is “InProgress.” A job can stay in this state for an hour or more.

A Stop-HistoricalSearch cmdlet is also available if you make a mistake with a message trace request and want to cancel a job.

Retrieving Search Data

Eventually, stars will align and Exchange Online runs the job to retrieve the message trace data. You might wait between 20 minutes to eight hours. To access the report, head to the message trace section of the Exchange admin center and select the downloadable reports tab (Figure 1). Historical search reports are called enhanced summary reports, but what’s in a name?

Exchange Online creates historical message trace reports as CSV files. When downloaded, you can open the files with Notepad or Excel (Figure 2) to interrogate the contents as required, The same information as available about the path of an email as seen in an online message trace is included in a historical search report. Note that dates are all in UTC format, so they might need to be translated into local time to make sense.

90 Days is the Limit

Running message traces is not one of my core competencies. It’s also not something that I do frequently. It’s nice to know that the historical search facility is available if I want to use it. That is, if I remember to trace within 90 days of a message being sent.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

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

Updated 6-Jan-2024

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

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

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

All Outlook Clients Covered

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

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

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

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

Sending Reactions

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

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

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

Notifications

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

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

Cross-Tenant Outlook Reactions

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

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

Outlook Reactions in MAPI Message Properties

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

The Teams Oreo Emojis

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

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

Will Outlook Reactions Succeed?

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

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

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

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

Update User Email Addresses and User Principal Names

A recent reader question asked about the best way to update a bunch of user accounts after the organization buys a new vanity domain and wants the domain used for email addresses and user principal names (sign-in addresses). This sometimes happens when a business goes through a rebranding exercise and ends up with a new name. The requirement to update email addresses and user principal names also occurs in tenant-to-tenant migrations.

Tenant-to-tenant migrations are a specialized kind of activity that’s usually managed with software built for this purpose. We won’t plunge into the challenges that these projects can encounter. Instead, we’ll focus on the scenario where someone in authority decides that all accounts should use different email addresses and user principal names.

Registered Domains

The first requirement is to add the domain to Office 365. Until this is done, you cannot use the domain. Once the domain is known to the tenant, it appears in the set of verified domains seen in the Microsoft 365 admin center (Figure 1).

After verifying the domain for Microsoft 365, we can write some code to ask the administrator what domain to use. Here’s an example that uses the Get-MgOrganization cmdlet from the Microsoft Graph PowerShell SDK to fetch the verified domains:

Connect-MgGraph -Scopes Directory.Read.All, User.ReadWrite.All
# Get tenant information and the verified domains for the tenant
$TenantInfo = (Get-MgOrganization)
[array]$Domains = $TenantInfo.VerifiedDomains.Name
$DomainsList = $Domains -join ", "
Write-Host "Verified domains for this tenant:"
Write-Host "---------------------------------"
Write-Host ""
$Domains
Write-Host ""
$DomainToUse = Read-Host "What domain do you want to use for primary SMTP addresses and UPNs"
Write-Host ""
If ($DomainToUse -notin $Domains) {Write-Host ("The selected domain ({0}) is not in the set supported by the tenant ({1}). Please try again." -f $DomainToUse, $DomainsList); break }
$CompareDomain = "*" + $DomainToUse + "*"

Finding Mail Recipients

The next step is to find mail-enabled recipients that have email addresses that might need updating. This code finds user mailboxes, shared mailboxes, group mailboxes (for Microsoft 365 groups), distribution lists, and security-enabled distribution lists.

For each object, the code calculates a new primary SMTP address based on their existing address by swapping the existing domain for the new domain. A check makes sure that the new address isn’t already in use, and if it is, creates a new address by adding “.EXO” to the username. The code then checks if it’s necessary to update the user principal name for the Entra ID accounts used by user mailboxes and shared mailboxes. An account might already use the new domain, so the code checks the account’s current user principal name and updates it with the new domain if necessary.

The output is captured in a PowerShell list that’s exported to a CSV file.

If (!($DomainToUse)) {
   Write-Host "No domain to move to is defined. Please make sure that the $DomainToUse variable is defined"
   Break
} Else {
   Write-Host ("Processing accounts to move them to the {0} domain..." -f $DomainToUse)
}

[array]$Recipients = Get-Recipient -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, GroupMailbox, MailUniversalDistributionGroup, MailUniversalSecurityGroup, DynamicDistributionGroup

$i = 0
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($R in $Recipients) {
     $i++
     If ($R.PrimarySmtpAddress.Split("@")[1] -ne $DomainToUse) { #Need to process this mailbox
      Write-Host ("Processing {0} {1} ({2}/{3})" -f $R.RecipientTypeDetails, $R.DisplayName, $i, $Recipients.Count)
      $NewUPN = $Null
      # Figure out new email address
      $NewAddress = $R.Alias + "@" + $DomainToUse
      # Check that the address is available
      $Status = Get-Recipient -Identity $NewAddress -ErrorAction SilentlyContinue
      # If we get a status the recipient address already exists, so create a new address
      If ($Status) { $NewAddress = $M.Alias + ".EXO@" + $DomainToUse }
      
      # Figure out if the account's user principal name needs to change
      If ($R.RecipientType -eq "SharedMailbox" -or $R.RecipientType -eq "UserMailbox") {
        $UPNDomain = $R.WindowsLiveId.Split("@")[1]
        If ($UPNDomain -ne $DomainToUse) { # New UPN needed
          $NewUPN = $R.WindowsLiveId.Split("@")[0] + "@" + $DomainToUse
          $Status = Get-MgUser -UserId $NewUPN -ErrorAction SilentlyContinue
          If ($Status) { # UPN already exists, so create a new one
            $NewUPN = $R.WindowsLiveId.Split("@")[0] + ".EXO@" + $DomainToUse }
          }
       }

      $ReportLine   = [PSCustomObject] @{ 
         DisplayName            = $R.DisplayName
         OldUPN                 = $R.WindowsLiveId
         NewUPN                 = $NewUPN
         PrimarySmtpAddress     = $R.PrimarySmtpAddress
         NewAddress             = $NewAddress
         Type                   = $R.RecipientTypeDetails
         Alias                  = $R.Alias
    }
    $Report.Add($ReportLine) }
}
$Report = $Report | Sort-Object Type
$Report | Export-CSV -NoTypeInformation c:\temp\MailObjects.Csv

Administrators can check the CSV to remove any mail-enabled recipients they don’t want to receive new email addresses (Figure 2).

Update User Email Addresses with a New Domain

The next step is reads in and processes an array of objects from the updated CSV file.

The code uses a Switch statement to check the object type and calls the appropriate cmdlet to assign the new primary SMTP address to the object. If the account used for a mailbox (user or shared) requires an update for its user principal name, we go ahead and do it.

The final step in the loop through the objects is to report what’s been done, noting the old and new SMTP address and the old and new user principal name.

# Process mail objects array to update primary SMTP addresses and UPNs as necessary
[array]$MailObjects = Import-CSV MailObjects.CSV
$Report = [System.Collections.Generic.List[Object]]::new()

Write-Host "Processing mail-enabled objects..."
$i = 0
ForEach ($M in $MailObjects)  {
   $i++
   Write-Host ("Processing {0} {1} ({2}/{3})" -f $M.Type, $M.DisplayName, $i, $MailObjects.Count)

   # Assign new primary SMTP Address
   Switch ($M.Type) {
      "DynamicDistributionGroup" { # Dynamic distribution list
        Set-DynamicDistributionGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "GroupMailbox" { # Microsoft 365 group
        Set-UnifiedGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "MailUniversalDistributionGroup" { # Distribution list
        Set-DistributionGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "MailUniversalSecurityGroup" { #Mail-enabled security group
        Set-DistributionGroup -Identity $M.PrimarySmtpAddress -PrimarySmtpAddress $NewAddress
     }
      "SharedMailbox" { # Shared mailbox
        Set-Mailbox -Identity $M.PrimarySmtpAddress -WindowsEmailAddress $NewAddress 
     }
      "UserMailbox" { # User mailbox
        Set-Mailbox -Identity $M.PrimarySmtpAddress -WindowsEmailAddress $NewAddress 
     }
    }

   # Update UPN if necessary
   If ($M.NewUPN) {  
     Update-MgUser -UserId $M.UPN -UserPrincipalName $M.NewUPN }

   $ReportLine   = [PSCustomObject] @{ 
          DisplayName            = $M.DisplayName
          OldUPN                 = $M.UPN
          NewUPN                 = $M.NewUPN
          OldPrimarySmtpAddress  = $M.PrimarySmtpAddress
          NewPrimarySmtpAddress  = $M.NewAddress
          Type                   = $M.Type
          Alias                  = $M.Alias
    }
    $Report.Add($ReportLine) 

} # End ForEach 
Write-Host "All done!"

Figure 3 shows an example of the report that allows administrators to check that the expected email addresses and user principal names are in place.

The User Issue

Updated user principal names take effect the next time users sign in. If you want to force the switchover, you could disconnect users from their current sessions by invalidating refresh tokens using the Graph revokeSignInSessions API. Invaliding access tokens forces users to reauthenticate and reconnect, and to do that, they must use their new user principal names.

Be aware that some issues exist when changing user principal names such as the need to set up the new user principal name on the Microsoft Authenticator app so that MFA challenges work It’s worthwhile reading through this Microsoft article to understand and test problems that users might encounter in your organization. Knowing what might happen and being prepared to fix the issues will ensure a smoother transition.

Any change to the way people sign-in is likely to cause some angst if it’s not communicated clearly so that everyone understands why the change is happening and what they must do to sign-in to access services.

Tidying Up Entra ID

The process outlined above takes care of the bulk of the work. If some Entra ID accounts that don’t have email addresses need to receive updated user principal names, you can do this with the Update-MgUser cmdlet from the Microsoft Graph PowerShell SDK.

Giving accounts new email addresses and user principal names isn’t a difficult technical challenge. The likely problems arise in preparation and communication. Isn’t that always the way?

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

But Practical Considerations Make Potential OME Weakness Not Worth Worrying About

I don’t quite know what to make of the October 14 WithSecure Labs report that Office 365 Message Encryption (OME) uses “a Broken or Risky Cryptographic Algorithm.” I also don’t know why Microsoft continues to use Electronic Codebook (ECB) to cipher message content.

OME, or rather “Microsoft Purview Message Encryption” is included in Office 365 E3 and E5 and other Microsoft 365 plans. An advanced form of OME is also available, but its functionality is not pertinent to this discussion. OME allows Exchange Online users to send encrypted email to literally any other email recipient, no matter what server their mailbox connects to. OME is built on top of Azure Rights Management, so users can protect messages with the default Do Not Forward and Encrypt-Only templates, or they can use custom rights management templates published to Outlook email clients as sensitivity labels.

Inferring Message Content

The problem discovered by the researchers is that a “Malicious 3rd party gaining access to the encrypted email messages may be able to identify content of the messages since ECB leaks certain structural information of the messages.” That certainly sounds like a problem, but the fact is that third parties can only dictate some structural information about emails and not the actual content. Their demonstration of an image extracted from an encrypted message is impressive, but only until you consider that the researchers had full control over the message content and were able to insert the necessary blocks to create the image they displayed. Exposing an image in a protected file makes a nice demo, but it is not the same as being able to extract information from a “real” file selected at random from a set of protected messages.

The practical implications of being able to intercept messages protected by OME is less certain. The researchers say that “an attacker with a large database of messages may infer their content (or parts of it) by analyzing relative locations of repeated sections of the intercepted messages.” The important thing here is that an attacker needs to acquire a large database of messages before they can move to a point where they can infer what the content of any specific message might be. Whether you consider this a practical and potential attack in the wild is up to your judgement. I don’t think it is something to worry about in the real world.

Little Likelihood of Exploitation

My experience is that relatively few messages created by Office 365 tenants use OME protection. Admittingly, even a small percentage of protected messages is a large volume when you consider that Exchange Online processes 9.2 billion messages daily. The counterargument is that the number of protected messages sent by individual tenants or users is usually small.

Some years ago, a conversation with the Microsoft Information Protection team indicated that the percentage of protected messages was in the low single digits. Of those messages, a large number probably remain inside Office 365 and are therefore impervious to interception unless an attacker can comprise the Microsoft 365 infrastructure. If that happens, being able to analyze some protected email to detect patterns that might reveal some potential content is the least of an Office 365 tenant’s problems.

We’re then left with a relatively small amount of messages protected by OME flow out of Office 365 to other mail systems. A potential attacker must therefore work out how to acquire “a large database of messages” to begin inferring what the messages content. Or “Even if specific message would not directly leak information in this way, an attacker with a large body of messages is able to perform analysis of the relation of the repeated patterns in the files to identify specific files. This may lead to ability to infer (parts of) clear text of encrypted messages.” The obvious fact here is that if an attacker can sit on a transmission path from Office 365 to another mail system, they’re likely to capture a vast quantity of unprotected email that can be analyzed and interrogated without any need to decrypt, infer, or otherwise go near protected content.

Microsoft’s Use of ECB

According to the researchers, even though Microsoft paid a $5,000 bounty for discovering the vulnerability, Microsoft’s response was “The report was not considered meeting the bar for security servicing, nor is it considered a breach.” Perhaps Microsoft believes that the practicality of exploitation is so low that the flaw doesn’t merit changing their code.

Interestingly, the researcher points out that the Microsoft Information Protection (MIP) ProtectionHandler::PublishingSettings class has a SetIsDeprecatedAlgorithmPreferred method which says that it “Sets whether or not deprecated crypto algorithm (ECB) is preferred for backwards compatibility.”

The researchers speculate that OME uses this flag to enable ECB rather than the more secure Cipher Block Chaining (CBC) mode.

They also point out that Microsoft’s FIPS 140-2 Compliance documentation explicitly states that “Legacy versions of Office (2010) require AES 128 ECB, and Office docs are still protected in this manner by Office apps.”

What’s weird here is that Office 365 hasn’t supported Office 2010 for years. At first glance, it doesn’t make sense for Microsoft to configure OME to support an ancient legacy version of Office. It would seem to make sense for Microsoft to move from ECB to CBC, but that’s without the benefit of understanding what this would mean in practice for end users. My understanding is that OME uses CBC for non-Office files because there is no reason to support backwards compatibility.

It’s clear from the Open XML format documentation that Office applies compression (Lempel-Ziv) to store documents. The RPMSG “wrapper message” generated by OME is also compressed (I believe that OME uses the Deflate algorithm for this purpose). Logically, compression occurs before encryption. The way compression works ensures that no repetitive patterns or fixed length sequences exist in the file, so the Office documents processed by ECB can’t exhibit the kinds of patterns reported by the researcher. If an attacker captures Office documents, there’s little hope of them being able to infer anything from the document content.

The Net Result

Given the lack of support for Office 2010 within Microsoft 365, it’s logical to ask why Microsoft has not upgraded OME and removed the use of ECB for Office documents. That step might make security researchers happier, but the use of compression in the existing implementation means that it might not make any real practical difference. Overall, the potential for a successful attack on OME-protected email in the wild seems low and the overwhelming percentage of unprotected email seems like a much more lucrative target for attackers.

WithSecure are certainly within their rights to recommend that Office 365 tenants should ignore OME until something better comes long. I disagree. It seems to me that increased use of OME would stop attackers being able to compromise the huge quantity of unprotected email that Office 365 tenants currently send. It’s wonderful to worry about an edge case; the real issue is to protect email in general. And that’s why it still remains so much better to protect confidential email with OME.

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

Using the Exchange.ManageAsApp Permission with Exchange Online PowerShell

Updated 7 December 2022

With the addition of support for managed identities in V3.0 of the Exchange Online management PowerShell module, developers might be more interested in creating Azure Automation runbooks that use the Exchange Online cmdlets to process data like mailboxes. In this discussion, when I refer to a managed identity, I mean a system-assigned managed identity working within an Azure Automation Account. Essentially, a managed identity is a service principal used to access Azure resources that Azure manages automatically. No access is available to the credentials for the managed identity. Like the service principals for other apps, managed identity service principals can hold permissions to allow them access to resources like apps.

As an example, it’s now easy to connect to Exchange Online in a runbook with a command like:

Connect-ExchangeOnline -ManagedIdentity -Organization office365itpros.onmicrosoft.com 

Exchange Online connects using the managed identity owned by the Azure Automation account that’s executing the runbook.

As noted above, before it can do anything interesting after connecting, the managed identity needs permissions. The essential permission for Exchange Online is Exchange.ManageAsApp, which allows an app to run Exchange Online cmdlets as if the app was an administrator account. Service principals for registered apps and managed identities both need this permission to do useful work with Exchange Online cmdlets.

Some Background

In November 2020, Microsoft announced the deprecation of the Outlook REST API. This was part of a wider effort to move developers away from legacy APIs to the Graph. Microsoft also considers Exchange Web Services (EWS) to be a legacy API, but in this instance, the Exchange team focused on the Outlook REST API, which the Graph Outlook Mail API replaces.

At the same time, Microsoft said that they “removed the Exchange app permission from the Azure portal.” The Exchange.ManageAsApp permission is one of the permissions in the Office 365 Exchange Online API. Microsoft’s action didn’t remove the ability to assign the permission to apps in the Azure AD admin center. It just made the process a little harder.

Assigning Exchange.ManageAsApp

To assign the Exchange.ManageAsApp permission to a registered app, select the app in the Registered Apps blade. Go to API permissions to add a permission as normal. When Azure AD displays the range of permissions to select from, click the APIs my organization uses tab, and then type Office 365 Exchange Online into the search box. Azure AD will find the Office 365 Exchange Online API (Figure 1). Note the application identifier shown here. We’ll need this later.

Now browse the set of permissions in the Office 365 Exchange Online API and select Exchange.ManageAsApp (Figure 2). Make sure that you’ve selected application permissions and click Add permission. When you return to the app details, consent to the assignment, just like you’d do for a Graph API permission.

The registered app can now run Exchange Online cmdlets as an administrator. That’s all well and good, but what about a managed identity?

Managed Identities are Different

Unlike registered apps, managed identities show up under the enterprise apps section of the Azure AD admin center. Open enterprise apps and apply a filter to find managed identities (Figure 3).

Azure AD lists the Azure automation accounts with managed identities. Select the automation account you want to work with. When you access its permissions, Azure AD tells you that: “The ability to consent to this application is disabled as the app does not require consent. Granting consent only applies to applications requiring permissions to access your resources.” In other words, you can’t assign an API to an automation account, or rather the service principal for the managed identity, through the Azure AD admin center.

Instead, you can do the job with PowerShell using cmdlets from the Microsoft Graph PowerShell SDK. Here’s how:

• Note the name of the automation account used with the managed identity. In this example, the account name is “ExoAutomationAccount.”
• Connect to the Graph with the AppRoleAssignment.ReadWrite.All permission.
• Run the Get-MgServicePrincipal cmdlet to populate a variable with the service principal for the automation account. The filter passed to the cmdlet contains the name of the automation account.
• Populate a variable with details of the Office 365 Exchange Online enterprise app. Microsoft installs this app for tenants to allow administrative apps to manage Exchange. The app id for the Office 365 Exchange Online app is always 00000002-0000-0ff1-ce00-000000000000.
• Find the Manage Exchange As Application role in the set held by the Exchange Online application. This role holds the Exchange.ManageAsApp permission, so any app holding the role can use the permission.
• Create the parameters to assign the role to the managed identity.
• Use the New-MgServicePrincipalRoleAssignment cmdlet to assign the role.

Connect-MgGraph -Scopes AppRoleAssignment.ReadWrite.All
Select-MgProfile Beta
$ManagedIdentityApp = Get-MgServicePrincipal -Filter "displayName eq 'ExoAutomationAccount'"
$ExoApp = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
$AppPermission = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$AppRoleAssignment = @{
"PrincipalId" = $ManagedIdentityApp.Id
"ResourceId" = $ExoApp.Id
"AppRoleId" = $AppPermission.Id
}
New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityApp.Id -BodyParameter $AppRoleAssignment

The new role assignment is effective immediately. If you make a mistake, you can remove the assignment with the Remove-MgServicePrincipalAppRoleAssignment cmdlet. Here’s how:

[Array]$SPPermissions = Get-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentityApp.Id
$Role = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$Assignment = $SpPermissions | Where-Object {$_.AppRoleId -eq $Role.Id}
Remove-MgServicePrincipalAppRoleAssignment -AppRoleAssignmentId $Assignment.Id -ServicePrincipalId $ManagedIdentityApp.Id

Administrator Role

The final step is to make sure that Exchange Online recognizes the automation account which hosts the managed identity as an Exchange administrator. This is done by assigning the Exchange Administrator role to the automation account’s app in the Azure AD admin center. Figure 4 shows how to add the assignment of the Exchange administrator role to the app owned by an automation account.

If you don’t assign the Exchange administrator role to the automation account’s app, you’ll see an error telling you that the role assigned to the app isn’t supported in this scenario when you execute the runbook. For example:

“The role assigned to application 415e4ba8-635f-4689-b069-22dea1fcfdb3 isn’t supported in this scenario“

Assignment a Small Pain

Perhaps Microsoft under-estimated the continuing need to assign the Exchange.ManageAsApp permission to apps when they made their November 2020 announcement. Although it’s a pain to have to go to PowerShell to assign the permission, it’s something that only needs to happen once, so it’s not too bad. I have other more serious things to moan about inside Microsoft 365.

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

Outlook Sweep Works in Monarch Client Too

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

Sweep Options

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

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

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

Comparing Inbox and Sweep Rules

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

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

Get-InboxRule -Mailbox James.Ryan | fl

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

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

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

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

Outlook Sweep Rules and PowerShell

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

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

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

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

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

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

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

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

Outlook Sweep Removes Junk

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

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

Better Late than Never for the Windows Desktop Client

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

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

Fitting External Tagging into Outlook for Windows

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

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

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

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

Raising User Awareness

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

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

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

External Tagging for Some, Not All

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

Set-ExternalInOutlook -Enabled $False

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

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

Archive Mailboxes Return to Exchange Admin Center

Microsoft 365 notification MC433154 (posted 29 August) brought the not-unexpected news that Microsoft is eliminating the listing of archive mailboxes in the Microsoft Purview compliance portal (Figure 1) and transferring sole GUI responsibility for these objects to the Exchange Admin Center (EAC).

Microsoft says that this will simplify the customer experience. We say that the old Security and Compliance Center (which became the Purview portal) was a convenient resting place for archive mailboxes while Microsoft upgraded the EAC. In any case, it’s the right thing to do because archive mailboxes (which have nothing to do with Outlook’s Archive folder) belong in the EAC. You won’t be able to access the archive page in the Data lifecycle management section of the Purview portal from sometime in October 2022.

EAC and Archive Mailboxes

The implementation of the display about information about archive mailboxes is different in EAC, Instead of a dedicated page that lists just user mailboxes with archives, EAC includes the archive status of mailboxes in its Manage mailboxes list. If the status is None, the mailbox doesn’t have an archive. If Active, the mailbox is archive-enabled. EAC includes both user and shared mailboxes in its listing and doesn’t differentiate between mailboxes with enterprise archives and those limited to 50 GB due to the licenses assigned to accounts (Figure 2).

To manage the archive for a mailbox from EAC, select the mailbox from the list to view its properties and go to the Others tab (as in other services). Then select Manage mailbox archive. You can enable or disable the archive mailbox here, but you can’t manage an expandable archive (see below).

After they have an archive, users can move items from their primary mailbox into the archive using drag and drop from Outlook. However, this seldom happens, and default archive tags configured in mailbox retention policies and assigned to mailboxes are responsible for moving most items into archive mailboxes. The ability to move items to the archive Is unique to mailbox retention policies and is a good reason to continue using these policies alongside Microsoft 365 retention policies.

Shared mailboxes that are archive-enabled require Exchange Online Plan 2 licenses.

Auto-Expanding Archives

Enterprise archives are called auto-expanding archives. When they introduced the concept of “bottomless” archives in June 2015, Microsoft told customers that ever-expanding archive mailboxes could continue growing ad infinitum. However, operational and technical realties bit, and Microsoft decided to put a 1.5 TB limit on enterprise archives in 2021. Exchange Online constructs the expandable archive by adding new “storage chunks” (auxiliary mailboxes) to the archive. The storage chunks that form the structure are connected together to form a logical structure. Exchange Online adds new storage chunks to an archive automatically when it detects that the existing storage is 90% occupied.

Even if the organization enables expandable archives, mailboxes don’t automatically use this facility. Instead, an administrator must enable it for a mailbox by running the Enable-Mailbox cmdlet. The first command shown below enables the archive. The archive mailbox must be in place before you can transform it into an expandable archive.

Enable-Mailbox -Identity Michael.King -Archive
Enable-Mailbox -Identity Michael.King -AutoExpandingArchive

If you want to assign an archive mailbox to all mailboxes that aren’t already enabled, you can run a command like this:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -Properties ArchiveStatus | Where-Object {$_.ArchiveStatus -eq "None"} | Enable-Mailbox -Archive

While to ensure that all enabled mailboxes use auto-expandable archives, run a command like this:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -PropertySets Archive | Where-Object {$_.ArchiveStatus -eq "Active" -and $_.AutoExpandingArchiveEnabled -eq $False} | Enable-Mailbox -AutoExpandingArchive

Exchange Server doesn’t support expandable archives. If you plan to move a mailbox back to an on-premises server, you should not enable it for expandable archives.

Reporting Archive Mailboxes

The EAC GUI is acceptable for discovering details about small numbers of archive-enabled mailboxes, but PowerShell is a better option to report details of archive mailboxes. This script finds all the archive-enabled user and shared mailboxes and reports how active each archive mailbox is.

[array]$Mbx = Get-EXOMailbox -PropertySets Archive -Properties DisplayName  -RecipientTypeDetails UserMailbox, SharedMailbox -Filter {ArchiveStatus -eq "Active"} | Sort DisplayName
If (!($Mbx)) { Write-Host "No archive-enabled user or shared mailboxes found - exiting" ; break }
Write-Host ("Processing {0} archive-enabled mailboxes" -f $Mbx.count)

$MbxReport = [System.Collections.Generic.List[Object]]::new()
ForEach ($M in $Mbx) {
  Write-Host "Processing" $M.DisplayName
  $Stats = Get-ExoMailboxStatistics -Identity $M.ExternalDirectoryObjectId -Archive
  [long]$QuotaUsed =  $stats.TotalItemSize.Value.toString().Split("(")[1].Split("bytes")[0]
  [long]$Quota = $M.ArchiveQuota.Split("(")[1].Split("bytes")[0]
  $PercentQuotaUsed = ($QuotaUsed/$Quota).ToString("P")
  $ReportLine = [PSCustomObject][Ordered]@{  
   Mailbox      = $M.DisplayName
   UPN          = $M.UserPrincipalName
   Archive      = $M.ArchiveStatus
   ArchiveItems = $Stats.ItemCount
   ArchiveSize  = $Stats.TotalItemSize.Value.toString().Split("(")[0]
   ArchiveQuota = $M.ArchiveQuota.Split("(")[0] 
   PercentUsed  = $PercentQuotaUsed
   Type         = $M.RecipientTypeDetails
   }
   $MbxReport.Add($ReportLine)  
}
$MbxReport | Out-GridView

The output is stored in a PowerShell list, so it’s accessible by piping the list to the Out-GridView cmdlet (Figure 3) or exporting it to a CSV file, Excel workbook, or HTML report.

As you can see, some mailboxes have an archive quota of 110 GB. This is because a retention policy or hold applies to these mailboxes. At least, that’s what Microsoft says in its documentation. However, several of these mailboxes have only a 100 GB archive quota and they are very much subject to retention policies.

As a quick test, I created some new mailboxes, put them on litigation hold, and enabled them for archives, and then for auto-expanding archives. The mailboxes all received 110 GB archive quotas. I conclude that older mailboxes that received expandable archives stay at the original 100 GB allocation. Perhaps Exchange Online will lift the quota the next time it adds a chunk to expand the archive.

Move Won’t Make a Difference

I doubt many people knew that the Microsoft Purview Compliance portal featured archive mailboxes and the reported move back to EAC won’t make much difference. Archive mailboxes are back where they should have been all along, even if PowerShell is a better way to manage them at scale.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Keeping Group Membership Secret

Customers expressed the desire to hide the membership of Microsoft 365 Groups soon after Microsoft launched Office 365 Groups in November 2014. Microsoft duly shipped the feature in early 2015.

Many scenarios exist to cloak the membership of a group. Some educational establishments don’t like revealing the full membership of classes; corporations engaged in confidential activities (like a merger and acquisition project) might like to hide the fact that external advisors have joined an internal team. Other organizations like to hide the membership of some committees, and so on.

Creating Groups with Hidden Memberships

Only PowerShell supports the creation of a Microsoft 365 group with hidden membership. This code creates a new group with the New-UnifiedGroup cmdlet and adds some members and a second owner with the Add-UnifiedGroupLinks cmdlet. The account that runs the New-UnifiedGroup cmdlet automatically becomes an owner:

New-UnifiedGroup -Alias "Super.Secret.Team" -PrimarySmtpAddress Super.Secret.Team@office365itpros.com -HiddenGroupMembershipEnabled:$True -Name "Super Secret Team"
Add-UnifiedGroupLinks -Identity Super.Secret.Team -LinkType Member -Links Sean.Landy, Terry.Hegarty, James.Ryan, Jackson.Hoare, Jane.Sixsmith, Michael.King
Add-UnifiedGroupLinks -Identity Super.Secret.Team -LinkType Owner -Links Michael.King

When a group has hidden membership, it means that Exchange Online only reveals details of the group membership to its members (through client interfaces) and tenant administrators (through administrative interfaces). This statement isn’t 100% true. As shown in Figure 1, when users browse an address list, they can’t see the group membership, but they can see one of the group owners, who are also group members. This means that part of the group membership is exposed.

Distribution lists also support hidden membership. Like Microsoft 365 Groups, you can set hidden membership when creating a new distribution list or you can hide membership for an existing distribution list. For example, this command creates a new distribution list with hidden membership.

New-DistributionGroup -Alias "SecretDL" -Name "Secret Distribution List" -DisplayName "Secret Distribution List" -PrimarySmtpAddress SecretDl@office365itpros.com -HiddenGroupMembershipEnabled:$True

When a Microsoft 365 group has hidden membership, its membership cannot be revealed by updating group properties. The Set-UnifiedGroup cmdlet doesn’t support updating the HiddenGroupMembershipEnabled setting. However, you can restore visible membership for a distribution list. For example:

Set-DistributionGroup -Identity SecretDL -HiddenGroupMembershipEnabled:$False

And if you make a mistake, you can reverse course and hide the membership again.

Set-DistributionGroup -Identity SecretDL -HiddenGroupMembershipEnabled:$True

Remember that Exchange Online must generate updated OAB files for Outlook to download and apply before changes to membership visibility become completely effective in Outlook desktop.

Sensitivity Labels and Hidden Group Privacy

Only a private Microsoft 365 group can have hidden membership. PowerShell and the other administrative interfaces will stop administrators changing the access type from private to public. Another thing to consider is what sensitivity label the new group should receive. Remember that sensitivity labels can control the privacy type for a group. If you assign a sensitivity label that applies container management settings, the access type set by the label must be Private. If not, you’ll see an error.

Figure 2 shows the group settings in the Microsoft 365 admin center. The group sensitivity label is Confidential Access, which is fine because it sets the access type to Private. Any attempt to use a label that sets the access type to Public will result in a cryptic error message that’s not very clear.

In addition, attempts to change the privacy (access type) through this interface won’t work because “visibility of a group with hidden membership cannot be updated.”

Hiding Groups from Address Lists

The “don’t show team email address in Outlook” setting controls the group’s HiddenFromAddressListsEnabled property. By default, the value of the property is False, meaning that Exchange Online includes the group in its address lists, including the Offline Address Book (OAB) and Global Address List (GAL). The effect of choosing this option is to stop users finding an entry for the group (and therefore being able to see its SMTP address) when they browse Outlook address lists. For example, there’s no sign of the group in the Outlook address book (Figure 3).

To make the group visible in address lists, update the setting in the admin center or run Set-UnifiedGroup to update the property:

Set-UnifiedGroup -Identity Super.secret.team -HiddenFromAddressListsEnabled $False

Remember that hiding the SMTP address of a group doesn’t stop people from sending messages to the group. It’s a visual block, not a hard block imposed in the transport service. If you want to restrict the people who can send messages to a group, use the AcceptMessagesOnlyFromSendersOrMembers property. This example stops the group accepting messages from anyone but group members.

Set-UnifiedGroup -Identity Super.secret.team -AcceptMessagesOnlyFromSendersOrMembers "Super.Secret.Team@Office365itpros.com"

Teams and Hidden Membership

Teams supports Microsoft 365 Groups with hidden membership. To team-enable our group, use the Add Teams option in the General tab of the group’s properties in the Microsoft 365 admin center. Alternatively, connect to Teams with PowerShell and run the New-Team cmdlet with the GroupId parameter pointing to the Azure AD identifier for the Microsoft 365 group:

Connect-MicrosoftTeams
New-Team -GroupId (Get-UnifiedGroup -Identity Super.Secret.Team | Select-Object -ExpandProperty ExternalDirectoryObjectId)

As only team members can access a team, they’re the only ones who can see the membership.

Impact on Reporting

Because administrative interfaces always have access to group membership data, setting group membership to be hidden might or might not affect the data returned by PowerShell cmdlets and Graph API requests. For example, the script to generate a report of Teams membership includes hidden membership because the code accesses each team to retrieve its membership. However, because the Graph TransitiveMemberOf API doesn’t include hidden membership in its results, the script to generate a report of membership of Microsoft 365 Groups (and Teams) doesn’t include groups and teams with hidden membership data.

Hidden is Good for Some

I don’t come across many situations where tenants use groups with hidden memberships and Office365ITPros.com hasn’t had many questions about this topic over the years. The feature is there, it works, and it solves a problem for some. I guess that’s all we need to say about it.

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

Big Red Switch Moved to Off

I don’t know whether this happened somewhere in the bowels of a Microsoft data center, but I imagined Greg Taylor flipping a big red switch marked Basic Authentication for Exchange Online at midnight on October 1 (Figure 1). Perhaps he even sipped a glass of red wine as he started the final process of removing the bulk of dangerous connectivity from Exchange Online (elegantly described during his recent MEC session). Given the effort expended over the last three years, he deserved a drink. Or maybe two.

Nothing Happened – Yet

Nothing happened after the switch moved to off. The sky didn’t fall and birds continued to sing. No small animals were harmed by Microsoft’s campaign to remove basic authentication for seven connection protocols. At least, nothing happened for the millions of Microsoft 365 tenants that have already embraced modern authentication.

Of course, some tenants are living on borrowed time. These organizations opted for the three-month last-gasp delay granted by Microsoft to those who needed a little extra time to prepare. I hope these folks make good use of the time between now and January 1, 2023.

For those who didn’t seek a postponement and basic authentication remains in use, they could run into issues at any time now. October 1 marked the point when Microsoft will start to disable basic authentication permanently for the affected protocols in tenants. Given the scale of Exchange Online (remember the statistics revealed at MEC), it takes time to work through the tenants now eligible to be turned off. You don’t know when Microsoft will enforce the block on basic authentication within a tenant. The process is automatic and anonymous. No one gets to choose when their tenant’s turn comes around.

Some Potential Holes for Tenant to Fall Into

When Microsoft disables basic authentication for a tenant, two outcomes can happen:

• No problems.
• Stuff stops working.

Organizations that paid attention to the warnings sounded by Microsoft and amplified by many commentators should be OK. They’ve upgraded clients, updated apps and scripts, and communicated with their users.

Others might not be quite as prepared. Indeed, I suspect that some don’t realize what might happen to them soon. The data presented at MEC (Figure 2) indicated where some problems might lie, including POP3 and IMAP4 clients, mobile devices using Exchange ActiveSync, older versions of Outlook, and apps based on Exchange Web Services (and to a lesser degree, PowerShell).

The key to everything is modern authentication (OAuth2). If clients attempt to authenticate with a simple username and password combination, they’ll fail. In some cases, the fix is simple, as with iOS devices where the mail app profile can be upgraded to use modern authentication. Apple did this automatically for tens of millions of devices when it released iOS 15.6, but devices managed by MDM solutions might still need attention. Or consider an update to Outlook Mobile (yes, I know this is much harder than my trite remark implies).

In other scenarios, a brand new client might be needed. There’s a lot of old POP3 and IMAP4 clients out there, and while some software developers have upgraded their clients, others have not. The same is true for apps that use these protocols to poll Exchange mailboxes for messages.

Users might be annoyed and frustrated to discover that their favorite client can no longer connect, but unless that client supports OAuth, Exchange Online will refuse to allow access to mailboxes (see this Microsoft post for advice on how to solve the immediate “I can’t access my mailbox” problem. by reenabling an access protocol. This is a short-term sticking-plaster solution to buy some time until January 2023.

I hope help desk staff are briefed to know how to deal with people who can’t get their email, a situation that can impact business effectiveness. Tenant administrators won’t be thanked if key staff can’t close deals because of obsolete software.

Multi-Factor Authentication is the Next Step

I’ve been writing about this project for years. Removing basic authentication is a very good thing. You don’t get to vote and it will happen, and when it does, users will be safer from password sprays and other attacks. Do yourself a favor at the same time and protect users with multi-factor authentication (MFA) too. According to Microsoft, only 26.84% of Azure AD accounts are protected with MFA. That’s sad, but look at the changeover from basic authentication as a forcing factor to increase user email security by making people switch to more secure clients. MFA should be part of that discussion.

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

300K Physical Mailbox Servers

Among the fun and games at the online MEC 2022 conference this week was the revealing of new statistics about Exchange Online, the largest workload within Office 365. The data (Figure 1) is quite staggering in terms of the size of the infrastructure supporting Exchange Online.

Mailboxes – Lots of Mailboxes

Every Exchange Online server is a physical Windows server, and there’s 300,000 of them to support 7.3 billion mailboxes. That’s not a typo. As of April; 2022, the latest number for Office 365 monthly active users is 345 million users (maybe 375 million now). The number of mailboxes might seem surprising, but there’s many other types of mailboxes in use within Exchange Online than a simple user count. The mailboxes include:

• Group mailboxes.
• System mailboxes like arbitration mailboxes.
• Shared mailboxes.
• Archive mailboxes.
• Scheduling mailboxes (used by the Microsoft Booking app).
• Cloud-only mailboxes used to hold compliance data for apps like Teams generated by hybrid accounts and guest users.
• Audit mailboxes used to hold Office 365 unified audit log records.

Many of the mailboxes hold substrate data necessary to support Microsoft 365 services like search, eDiscovery, and compliance processing.

Each mailbox is in a mailbox database within a Database Availability Group (DAG). The DAG keeps three active copies and one lagged copy of each mailbox database. Deploying Native Data Protection protects that 1.4 exabytes of data spanning 42 trillion mail items (messages, calendar items, and so on).

The Joy of MEC

It was nice to be back presenting at a MEC event, even if it was a virtual event. Everything seemed to run smoothly and I only noticed one network hiccup during the sessions I attended. Microsoft has published session recordings on YouTube. Links to the decks and recordings for my sessions are at the end of this post.

I had planned to use PowerPoint Live when presenting my sessions but discovered that this facility isn’t available when presenting using a guest account in another tenant. I had to use the tried-and-trusted method of sharing a screen in the Teams meetings. However, I did see luminaries like Greg Taylor present using PowerPoint Live and enjoyed changing Greg’s slides about the details of removing basic authentication for Exchange Online connection protocols into different languages, including Irish (Figure 2). It’s amazing what cloud translation services can do these days.

Speaking about the campaign to remove basic authentication, it seems like everything is going OK with the possible exception of IMAP4 and POP3 clients and apps. Figure 3 shows some interesting information shared by Greg, this time in English. To put this information in a sharper context, consider the number of Exchange connections and mailboxes listed above.

There still seems to be a lot of connections using basic authentication from these sources that could be surprised when the hammer drops. It’s time to upgrade to clients that use modern authentication like the latest Thunderbird client.

Implement an Authentication Policy

A good suggestion that I heard is that tenants can take control of the switch-off by deploying an authentication policy to block basic authentication to see what apps and clients are effected. If some apps and clients need a little extra time to prepare, you can deploy another authentication policy that allows selective access to specific protocols to those accounts.

The great advantage of an authentication policy is that it blocks incoming connections before any authentication processing happens. In other words, if an attacker attempts a password spray to guess the credentials of an account using a protocol like POP3, the attempt fails immediately if the policy blocks POP3 connections. The attacker doesn’t get the chance to know that credentials work, even if they possess valid account credentials obtained in some manner.

On to TEC for Even More Exchange Online Statistics!

I had a great time talking about how to turbo-charge Exchange Online PowerShell using the Microsoft Graph APIs. What was nice about the session was the number of well-known individuals from the Exchange community in the audience. My sole regret was that I couldn’t mingle with people after the presentation as you can during an in-person conference. I’ll get that at The Experts Conference (TEC) in Atlanta next week. I am really looking forward to the event, even if Greg Taylor will be there (only kidding…)

Exchange PowerShell Examples

During my session about Exchange Online PowerShell and the Microsoft Graph (PPTX below), I published a list of articles for people to check out to learn more. Some people might have missed the information that I posted in the meeting chat, so here it is for everyone (alternatively, read the 110-page PowerShell chapter in the Office 365 for IT Pros eBook).

• Mailbox Cleanup using the Microsoft Graph https://practical365.com/mailbox-clean-up-script/
• Figuring out Graph permissions https://practical365.com/microsoft-graph-api-permission/
• Azure Automation and Exchange Online https://practical365.com/use-azure-automation-exchange-online/
• Azure Automation Managed Identities and Exchange Online https://practical365.com/azure-automation-managed-identity-exo/
• •Azure Automation and Microsoft Graph PowerShell SDK https://practical365.com/microsoft-graph-sdk-powershell-azure-automation/
• License management https://practical365.com/microsoft-365-license-graph-sdk/
• Generate licensing report https://practical365.com/create-licensing-report-microsoft365-tenant/
• Creating a new Azure AD group (and team-enable new group) https://practical365.com/create-new-microsoft-365-group-sdk/
• Basic User management with Microsoft Graph PowerShell SDK https://office365itpros.com/2022/03/24/azure-ad-user-account-powershell/
• Basic group management with Microsoft Graph PowerShell SDK https://office365itpros.com/2022/03/29/azure-ad-group-management/
• Assign Azure AD roles with the Microsoft Graph PowerShell SDK https://office365itpros.com/2022/03/30/azure-ad-role-assignments/
• Ups and downs of connecting to the Microsoft Graph PowerShell SDK https://practical365.com/connect-microsoft-graph-powershell-sdk/

Worked out examples

• Reporting the activity of Microsoft 365 Groups and Teams.
• Reporting user activity across multiple workloads.
• Decrypting SharePoint Online documents protected with sensitivity labels.
• Calculate counts of distribution list members.
• Sending email with the Graph.
• Creating organization contacts in user mailboxes.

PowerPoint Decks and Session Recordings

Admin’s Guide to the Microsoft 365 substrate

Master the Graph for Exchange PowerShell

The Wonders of AutoMapping

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

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

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

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

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

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

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

Synchronization Concerns

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

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

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

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

Mailbox Access Without Outlook Automapping

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

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

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

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

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

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

OSTs and NSTs

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

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

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

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

Making Things Better

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

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

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

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

It’s Good to Have the Microsoft Exchange Conference Back

Twenty-six years ago, I attended the Microsoft Exchange Deployment Conference in Austin, Texas. I brought copies of Microsoft Exchange Server: Planning, Design, and Implementation, the book I’d written about Exchange 4.0 (Figure 1).

The book had been put together quite quickly based on experience of the beta version of Exchange 4.0 and some exposure to the final version released to customers. The conference was a great chance to glean some extra knowledge about Exchange and fill the gaps in the book. I don’t pretend that the 4.0 book was perfect, a fact that the then Exchange product manager Elaine Sharpe expressed to me rather forcefully. Elaine and I made up and she wrote the foreword to my Exchange 5.0 book.

Presenting at MEC

A year later, I presented at the first Microsoft Exchange Conference (MEC) in San Diego, California. Compared to other MEC events, I have no real memories of that conference, but it began a relationship with MEC that’s lasted 25 years. MEC 1998 in Boston evokes strong memories of competition with Lotus Notes and some wild parties. I presented a keynote at MEC 2000 in Dallas (Figure 2) when Windows 2000, Exchange 2000, and Active Directory were the new kids on the block. It was a blast to speak to 8,000 people, even if I couldn’t see past the front row.

Flat Tony

After a hiatus caused by Microsoft marketing dictats and an unfortunate focus on TechEd, Microsoft brought MEC back in 2012. The early days of Office 365 meant that MEC 2012 featured many discussions about mailbox migrations to the cloud. Two years later, the last MEC (in Austin), brought Flat Tony to the scene. Microsoft asked me for copies of all the books I had written about Exchange Server for a display at the conference. Microsoft embellished the display with a cardboard cut-out figure created by placing a photo of my head on top of a body from someone in significantly better shape (Figure 3).

Flat Tony survived MEC and the Exchange development group then took the figure on tour through bars in Austin. Eventually, the figure reached Redmond and subsequently turned up at a couple of MVP summits before meeting its end in Greg Taylor’s wood. Good times!

Sessions at MEC 2022

This week, I will present two sessions at MEC 2022, now renamed the Microsoft Exchange Community Airlift. MECA is a horrible acronym, so MEC will do. My sessions are:

• An administrator’s guide to the Microsoft 365 substrate (September 13, 10AM Pacific).
• Master the Graph for Exchange PowerShell (September 14, 11AM Pacific).

All sessions are run as Teams meetings and recordings will be available on the MEC website afterward.

In-Person Events are Even Better

Happy as I am to present at MEC 2022, I will be even more pleased to travel to Atlanta to attend The Experts Conference (TEC) on September 20-21. There’s nothing quite like an in-person event to get the creative juices going. TEC is close to being sold out, but I think some tickets might still be available.

TEC is a small event that’s quite unlike the large-scale Microsoft events in terms of access to speakers and subject matter experts. It should be a fun gathering. In particular, I’m looking forward to hearing from Alex Weinert, who always reveals some solid data about the current security landscape. His session at the RSA 2020 conference captured the reasons why basic authentication is so bad for email connection protocols. Speaking of which, Greg Taylor will be at TEC to tell people about the progress Microsoft is making in turning off basic authentication for Exchange Online. That should be a fun session. Meantime, I’ll talk about the challenge of mastering the many technologies that make up Microsoft 365. I might not have a perfect answer, but I have some views on the topic.

Conferences Restarting

It seems like conferences are returning to some level of normality, which is nice. After MEC and TEC, the next conference on my list is the European SharePoint, Office 365, and Azure Conference in Copenhagen (November 28-December 1) where I’ll discuss how to manage Teams for success. At least, that’s what the session title says.

I plan not to attend Microsoft Ignite. I can’t get excited about an event that’s succumbed to the same marketing disease that afflicted TechEd. At least MEC allows independent experts to give their view about Microsoft technology, something that’s become much more difficult to do at Ignite because of the lack of speaking opportunities Microsoft makes available to non-Microsoft speakers. While Ignite remains on its current course, it’s just not attractive to me. But at least I have MEC and TEC to look forward to. Rumors exist that MEC 2023 will be an in-person event. That’s something even more pleasant to contemplate.

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

Five Years On, the Use Case for the Archive Folder is Still Unclear

Generally, I am positive about the changes that Microsoft makes in Microsoft 365. Well, maybe we complain about some of the updates. From time to time, Microsoft throws some curve balls to cause me to scratch my heads. For instance, the time when they decided that it would be a great idea to create Microsoft 365 group for each manager with the manager’s direct reports as the group members. Anyone concerned with privacy could see that was a bad idea. Fortunately, that bright spark fizzled out quickly.

The Odd Archive Folder

Which brings me to Outlook’s strange Archive folder. This appeared in March 2017 and promptly caused massive confusion with Exchange Online’s archive mailboxes.

Microsoft’s support documentation says:

“There are several ways to archive messages in Outlook. The methods that you can use depend on the type of email accounts that you have set up in Outlook.

All accounts have access to an Archive folder. For Microsoft 365, Outlook.com, and Exchange accounts, the Archive folder is one of Outlook’s default folders, like Inbox, Sent Items, and the Deleted Items folder. This folder can’t be deleted. If you use Outlook with an Exchange or Exchange Online account, folder policies such as retention policies apply to the Archive folder.”

And

“Using the Archive button to move messages to the Archive folder doesn’t reduce your mailbox size.”

This description makes it seem like someone thought that it would be convenient to give users an Archive button to move items into the Archive folder as some sort of primitive file-out-of-sight mechanism. I don’t see any trace of the Archive button in my version of Outlook for Windows in either the classic or simplified ribbon. Perhaps competition for space in the ribbon from new-fangled options like Viva Insights caused the Archive button to drop out. Who knows?

After five years of ignoring the Archive folder, I’m still not sure why Microsoft thought it would be a good idea to add an Archive folder to everyone’s mailboxes, but there it lingers today. The only reasons I can see for its existence are:

• The Archive folder is available to mobile clients whereas no mobile client can access items in an archive mailbox because of the lack of protocol support in Exchange ActiveSync or Outlook Mobile.
• Outlook can synchronize items in the archive folder for offline access.

However, these reasons are undermined by the simple fact that keeping items in other folders in the primary mailbox gains the same advantages. There’s no need to move items into a special folder to be able to access them on mobile clients or offline.

The archive folder is like your appendix. It’s there, no one really knows why it is there and you probably wouldn’t miss it if it wasn’t there.

Confusion with the Online Archive

From an administrative perspective, the big issue with the Archive folder is that it muddies the water with Exchange Online’s online archive. The online archive exists as a place where old messages go to rot until the organization is sure that no conceivable reason exists for them to be retrieved. Items in the online archive are indexed and available for eDiscovery. By comparison, the Archive folder is in the primary mailbox and has nothing to do with the online archive.

Items move from the primary mailbox to the online archive (archive mailbox) when:

• A user moves items explicitly using a client like Outlook. This accounts for 0.000000184% of all items that reach archive mailboxes (I made that figure up, but it’s defendable).
• The Exchange Managed Folder Assistant moves items because they have an archive tag assigned by the user or because a default archive tag exists in the mailbox retention policy assigned to the mailbox.

Only Exchange mailbox retention policies include tags with move to archive actions. Microsoft 365 retention policies can remove mailbox items, but they cannot archive the items.

Automatic policy-driven movement of items from primary to archive mailboxes is the right way to keep messages for the long term. The Managed Folder Assistant processes mailbox retention policies (including the move to archive) while a separate assistant applies Microsoft 365 retention policies to other workloads.

Stopping the Backspace Key Archiving Items

One interesting pointer from the support documentation is that if you use the Microsoft 365 apps for Enterprise (Outlook click to run), the backspace key moves the selected item to the Archive folder. I never knew that this happened, but it accounts for why items unexpectedly turn up in the folder. Usually, I just scratch my head and delete the mystery items, but it now seems that I put them there by pressing the backspace key!

To disable this one-click-to-archive behavior, update the system registry to add the DisableOneClickArchive DWORD value at HKEY_CURRENT_USER\SOFTWARE\microsoft\office\16.0\outlook\options. Set the value to 1 to stop the backspace key moving items to the Archive folder (Figure 1).

The backspace key will start to behave properly the next time you restart Outlook. This fix isn’t available for the perpetual versions of Outlook like Outlook 2019 and Outlook 2021. It’s just another example of the gap between the Outlook perpetual and Outlook subscription versions. The fix doesn’t work for the current beta version of the Outlook Monarch client, which merrily moves items to the Archive folder with the backspace key. Oddly, OWA doesn’t move items with the backspace key.

No Joy in Archive Folder

No good reason exists for the Outlook Archive folder. It is what it is and is probably going to persist for the foreseeable future. The best thing to do is to ignore the folder, that is, after you stop Outlook putting items into the Archive folder with the backspace key.

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

If You Have Office 365 E3 Licenses, Check the Flow of Mailbox Audit Events

A reader contacted me to report some problems that a compliance exercise had thrown up when it was discovered that the Office 365 audit log did not contain mailbox audit records for some Exchange Online mailboxes. As it turned out, all the affected mailboxes belonged to Azure AD accounts with Office 365 E3 licenses. Not having some expected mailbox audit events available in the audit log is not a great situation for any compliance officer or tenant administrator to find themselves in.

When the customer organization contacted Microsoft support, they were told that a bug existed in Exchange Online that stops the AuditEnabled setting being accurately reported for mailboxes with Office 365 E3 licenses. When administrators examined the setting with the Get-Mailbox or Get-ExoMailbox cmdlets, Exchange Online reported $True, meaning that auditing is enabled for the mailbox:

Get-ExoMailbox -Identity Brian.Weakliam -Properties AuditEnabled | Format-Table DisplayName, AuditEnabled

DisplayName                 AuditEnabled
-----------                 ------------
Brian Weakliam (Operations)         True

However, the mailbox audit events remain in Exchange Online and never make it into the Office 365 audit log. Everything works perfectly for mailboxes assigned Office 365 E5 licenses.

What Microsoft Says

Microsoft’s documentation says:

Although mailbox audit logging on by default is enabled for all organizations, only users with E5 licenses will return mailbox audit log events in audit log searches in the Microsoft Purview compliance portal (Figure 1) or via the Office 365 Management Activity API by default.

The page also says:

Even when mailbox auditing on by default is turned on for your organization, you might notice that mailbox audit events for some users aren’t found in audit log searches by using the compliance center, the Search-UnifiedAuditLog cmdlet, or the Office 365 Management Activity API. The reason for this is that mailbox audit events will be returned only for users with E5 licenses when you [use] one of the previous methods to search the unified audit log.

Apparently, Microsoft doesn’t consider it a bug when audit data from mailboxes with Office 365 E3 licenses doesn’t reach the Office 365 audit log. The justification is that:

• The audit events are available in Exchange Online (in the Audits folder in the Recoverable Items part of each mailbox) and can be found there.
• If the organization wishes to ingest the audit events into the Office 365 audit log, all they need to do is run the Set-Mailbox cmdlet to update the AuditEnabled setting to $True. In other words, the $True value reported by Exchange Online is accurate because it reports that mailbox events are available. Running Set-Mailbox to update the setting to $True (again) doesn’t change anything (the setting is still $True) but Exchange Online takes the hint and will ingest mailbox events into the Office 365 audit log thereafter.

Clearly, this is a non-optimal situation. I wrote about the same issue in March 2020 when Microsoft rolled out mailbox auditing by default across Exchange Online. It seems like the same documentation is online and people are still running into problems. And that this Exchange Online functionality hasn’t progressed much since.

Audit Events Appear to Flow for New Mailboxes

Or has it? I created a couple of new Azure AD accounts and assigned them Office 365 E3 licenses and then signed into each mailbox to perform several actions that I knew should generate audit records. After waiting 30 minutes to allow ingestion to occur, I ran the Search-UnifiedAuditLog cmdlet to see if any events existed in the Office 365 audit log. They were!

[array]$records = Search-UnifiedAuditLog -StartDate 18-Aug-2022 -EndDate 19-Aug-2022 -Formatted -userids michael.king@office365itpros.com
$records | ft creationdate, operations
 
CreationDate        Operations
------------        ----------
18/08/2022 12:54:31 SoftDelete
18/08/2022 12:54:23 MoveToDeletedItems
18/08/2022 12:54:19 SoftDelete
18/08/2022 12:53:19 SoftDelete
18/08/2022 12:53:14 MoveToDeletedItems

This result is exactly what you’d hope to see. No administrator intervention was necessary to have events flow from Exchange Online to the Office 365 audit log. I obtained the same results with mailboxes in another tenant. I asked Microsoft about the issue and learned that mailbox auditing was enabled by default because of the configuration of the Exchange Online forest that hosts the mailboxes. For performance reasons (to reduce the number of audit events processed by Office 365), this is not the situation for every Exchange Online forest. This is why Microsoft’s documentation recommends that you should re-enable auditing for the E3 mailboxes to force ingestion of audit events for these mailboxes into the Office 365 audit log.

The conclusion is there might be many mailboxes with Office 365 E3 licenses running in tenants around the world that don’t feed data into the Office 365 audit log. The only solution is to run Set-Mailbox. And you might as well run the cmdlet for all mailboxes with Office 365 E3 licenses just to be sure.

The script included in my previous post will do the job of finding mailboxes with Office 365 E3 licenses and updating their audit settings. The script uses the Get-AzureADUser cmdlet to find the relevant accounts. If you’ve switched to the Microsoft Graph PowerShell SDK, the updated code is:

[array]$Mbx = Get-MgUser -filter "assignedLicenses/any(s:s/skuId eq $Office365E3)" -All

Good for the Future?

If you use Office 365 E3 licenses, be sure to check that mailbox auditing works as you expect. It’s odd that Microsoft forces customers to go through the additional step to enable auditing for mailboxes that appear to be already enabled for auditing, but that’s the way the system works.

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.

Shared Mailbox License Only Needed Under Three Specific Conditions

Exchange Online shared mailboxes don’t need licenses unless they:

• Exceed 50 GB in mailbox size.
• Have an archive mailbox. This allows the Managed Folder Assistant to offload older items through an Exchange Online mailbox retention policy.
• Are on litigation hold. As Exchange Online won’t allow an administrator to put a shared mailbox on litigation hold, this implies that the mailbox originally belonged to a user before conversion to a shared mailbox. Organizations sometimes preserve the mailboxes of ex-employees by converting them into shared mailboxes. In many cases, making the mailboxes inactive is a better choice.

In these cases, Microsoft requires the shared mailbox to have an Exchange Online Plan 2 license, which you can assign in the Microsoft 365 admin center or with PowerShell. If you don’t have an Exchange Online Plan 2 license, you can also use a license like Office 365 E3 that contains the Exchange Online Plan 2 service plan. In effect, you assign the license to the Azure AD account that Exchange Online creates automatically for the shared mailbox. Azure AD doesn’t disable the account and it works like other Azure AD accounts, but you should never sign into it.

For instance, to assign an Office 365 E3 license to a shared mailbox, you could run these commands:

$M = Get-ExoMailbox -RecipientTypeDetails SharedMailbox -Identity 'Customer Services'
Set-MgUserLicense -UserId $M.ExternalDirectoryObjectId -Addlicenses @{SkuId = '6fd2c87f-b296-42f0-b197-1e91e994b900'} -RemoveLicenses @()

See this page for details of the identifiers for Microsoft 365 licenses and this article for more information about how to manage licenses for Azure AD accounts with PowerShell.

Finding Shared Mailboxes that Need Licenses

Microsoft doesn’t actively block shared mailboxes that breach the licensing conditions. However, it’s a good idea to make sure that all the shared mailboxes in a tenant have licenses when required. The shared mailboxes section in the Microsoft 365 admin center gives no hint of when mailboxes need licenses, but some processing with PowerShell should do the trick.

The steps seem easy enough:

• Find all shared mailboxes.
• Check each mailbox to see if it has an archive, exceeds 50 GB, or is on litigation hold.
• Check the mailbox’s account to see if it has an Exchange Online Plan 2 license.
• Report what we find.

The full script is available from GitHub. The main loop for each mailbox is below.

Write-Host ("Processing mailbox {0} ({1} of {2})" -f $M.DisplayName, $i, $Mbx.count)
   $NeedsLicense = $False; $ArchiveStatus = $Null; $ExoArchiveLicense = $False; $ExoPlan2License = $False; $LicenseStatus = "OK"; $ArchiveStats = $Null
   $MailboxOverSize = $False; $ExoPlan1License = $False; $ArchiveMbxSize = $Null
   
   $MbxStats = Get-ExoMailboxStatistics -Identity $M.ExternalDirectoryObjectId
   $MbxSize = [math]::Round(($MbxStats.TotalItemSize.Value.toBytes() / 1GB),5)
   If ($M.ArchiveStatus -ne "None") { #Mailbox has an archive
      $ArchiveStats = Get-ExoMailboxStatistics -Archive -Identity $M.ExternalDirectoryObjectId 
      If ($ArchiveStats) {       
          $ArchiveMbxSize = [math]::Round(($ArchiveStats.TotalItemSize.Value.toBytes() / 1GB),5)}
   }
   $Licenses = Get-MgUserLicenseDetail -UserId $M.ExternalDirectoryObjectId | Select-Object -ExpandProperty ServicePlans | Where-Object {$_.ProvisioningStatus -eq "Success"} | Sort ServicePlanId -Unique
   If ($Licenses) { # The mailbox has some licenses
     If ($ExoArchiveAddOn -in $Licenses.ServicePlanId) { $ExoArchiveLicense = $True }
     If ($ExoPlan2 -in $Licenses.ServicePlanId) { $ExoPlan2License = $True }
     If ($ExoPlan1 -in $Licenses.ServicePlanId) { $ExpPlan1License = $True }
  }

  # Mailbox has an archive and it doesn't have an Exchange Online Plan 2 license, unless it has Exchange Online Plan 1 and the
  # archive add-on
  If ($M.ArchiveStatus -eq "Active") {
    If ($ExoPlan2License -eq $False) { $NeedsLicense = $True }
    If ($ExoPlan1License -eq $True -and $ExoArchiveLicense -eq $True) { $NeedsLicense = $False }
  }
  # Mailbox is on litigation hold and it doesn't have an Exchange Online Plan 2 license
  If ($M.LitigationHoldEnabled -eq $True -and $ExoPlan2License -eq $False)  { $NeedsLicense = $True }
  # Mailbox is over the 50GB limit for unlicensed shared mailboxes
  If ($MbxStats.TotalItemSize.value -gt $MailboxLimit) { # Exceeds mailbox size for unlicensed shared mailboxes
      $MailboxOverSize = $True
      $NeedsLicense = $True}

Analyzing the Outcome

The code is rough and ready but serves its purpose (which is always a good state for a PowerShell script to be in). At the end of the processing, the script generates some basic statistics, including highlighting any shared mailboxes it thinks need licenses together with the reason why (Figure 1).

Figure 2 shows the kind of information the script gathers for the shared mailboxes. In this case, I had assigned a license to one of the two mailboxes highlighted in Figure 1, so only one mailbox shows up as still needing a license.

Shared Mailboxes Don’t Need Much Attention

Usually, shared mailboxes don’t need much attention. They function like they’ve always functioned because Microsoft hasn’t changed their functionality much over the past few years. However, some shared mailboxes might need licenses. It’s best to find and rectify the issue before you run into problems. Unlicensed shared mailboxes that exceed their 50 GB allocation can’t send any new emails until they receive a license and will eventually stop receiving inbound messages. That’s a sad situation to be in!

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.

Unlikely to Make Much Difference in Reality

Some folks got worried about the contents of message center notification MC411428 (August 8, 2022). This notification tells us that Microsoft is making a change to the retention period for an inactive mailbox after all holds are released. A mailbox becomes inactive upon the hard-deletion of its Azure AD account if any of the myriad types of retention holds exist over items in the mailbox. Holds include all-mailbox litigation holds to retention labels placed on specific items. Inactive mailboxes are a form of soft-deleted mailboxes designed to allow organizations to keep information belonging to ex-employees for compliance purposes (shared mailboxes are another option). Because inactive mailboxes are online (but hidden from user view), Microsoft Search indexes their contents and makes them available for eDiscovery.

The nice thing about inactive mailboxes is that they don’t require any licenses. Exchange Online keeps inactive mailboxes for as long as you want, or rather, until the removal of the last hold that retains mailbox data. Some of the inactive mailboxes in my tenant go back to 2015, as seen in the Microsoft Purview compliance portal (Figure 1).

Soft-Deleted Mailboxes and Azure AD Account Recovery

Exchange Online keeps soft-deleted mailboxes for the deleted mailbox retention period (30 days). This period matches the time that Azure AD keeps deleted user accounts in its recycle bin and means that if an administrator restores the Azure AD account, the restore can reconnect the mailbox to the account.

After 30 days, Azure AD permanently removes the account. Once the Azure AD account is gone, Exchange Online either permanently removes the mailbox (if no hold exists) or puts it into an inactive state. The mailbox remains inactive until the removal of all holds and retention policies from the mailbox. At this point, Exchange Online updates the mailbox state to make it soft-deleted (but not inactive). The owner’s Azure AD account is long gone, so if normal logic applies, Exchange Online will immediately move to permanently remove the mailbox.

Additional Recovery Period for Old Inactive Mailboxes

However, accidents do happen and it’s possible that administrators might release holds keeping inactive mailboxes online. You don’t want to run the risk that an accident leads to unexpected loss of information needed for compliance purposes, so Microsoft built in an extra recovery period that starts once an inactive mailbox becomes soft-deleted. Previously, the recovery period was 183 days. During this time administrators can run an eDiscovery search to recover and export the information in the soft-deleted mailbox.

The change announced in MC411428  is that Microsoft will reduce the recovery period to 30 days in late August with the change available worldwide by late September. Microsoft says that they’ve sought customer feedback for the change, and it will maintain consistency with other solutions. Following the 30-day recovery period, Exchange Online permanently deletes the once inactive mailboxes and their content becomes irrecoverable.

Keeping Inactive Mailboxes Around

On the surface, reducing the time allowed to administrators to recover data if mistakes happen seems like a bad thing. However, given the array of holds and policies that can keep a mailbox inactive, it’s not. If you’re worried about the change, create a retention policy that keeps all Exchange Online mailbox content for an extended period (say, 20 years) and apply it to all mailboxes. Alternatively, if you have Office 365 E5 or Microsoft 365 E5, you can create a retention policy with an adaptive scope to find and preserve inactive mailboxes. Either way means that there’s little danger that inactive mailboxes will ever be released from all holds to enter the soft-deleted state.

There’s no downside to keeping inactive mailboxes for extended periods. They don’t do any harm, don’t interfere with administrative processes, and don’t cost you any money (Microsoft pays for the storage consumed by inactive mailboxes).

Depending on the compliance environment your organization operates under, there might be a case for making every deleted mailbox inactive as described above and then ignoring them. Other organizations might need a more subtle approach and make only certain mailboxes inactive.

One Last Point

Unconnected with inactive mailboxes (except that you can run the Get-Mailbox -InactiveMailboxOnly cmdlet to see them), it’s worth emphasizing that Microsoft will end support for the old Exchange Online PowerShell with MFA module on August 31, 2022 and retire it on December 31, 2022 (MC407050, July 29). This method of connecting to Exchange Online with MFA is based on the V1 module inherited from on-premises. Scripts should use the Exchange Online PowerShell V2 module instead. This version supports modern authentication out-of-the-box, including certificate-based authentication.

Keep up to date with developments like changes to Exchange Online 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.

An Attempt to Make Scheduling Meetings Easier

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

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

Using Booking for Me

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

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

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

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

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

Sharing Meeting Types

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

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

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

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

Booking Meetings

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

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

Likely to be a Popular Tool

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

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

A New Mailbox Type to Appreciate

It’s always interesting when you discover something about an application that’s been around for a long time, like when I found some “scheduling” mailboxes in Exchange Online.

Get-EXOMailbox -Filter {RecipientTypeDetails -eq "SchedulingMailbox"} | Format-Table DisplayName

DisplayName
-----------
Professional Financial Advice
Office 365 for IT Pros
Sean Landy Medical Appointments

Scheduling mailboxes host the calendars used by the Microsoft Bookings app. Let’s explore how the app works and uses the scheduling mailboxes.

Note: the Microsoft Bookings app is very different to the Outlook Booking with me feature.

Controlling Access to Microsoft Bookings

Bookings is available in all Office 365 and Microsoft 365 plans unless it’s blocked at the organization level or for specific individuals. At the organization level, granular controls are available in the Microsoft 365 admin center (org settings) over different aspects of Bookings (Figure 1).

These settings can also be retrieved and updated using PowerShell:

Get-OrganizationConfig | Format-List Bookings*

BookingsEnabled                             : True
BookingsEnabledLastUpdateTime               : 21/07/2022 16:39:06
BookingsPaymentsEnabled                     : False
BookingsSocialSharingRestricted             : True
BookingsAddressEntryRestricted              : False
BookingsAuthEnabled                         : False
BookingsCreationOfCustomQuestionsRestricted : False
BookingsExposureOfStaffDetailsRestricted    : False
BookingsNotesEntryRestricted                : False
BookingsPhoneNumberEntryRestricted          : False
BookingsMembershipApprovalRequired          : False
BookingsSmsMicrosoftEnabled                 : True

To disable Bookings for an individual account, you remove the Microsoft Bookings app from the set of apps licensed to the account. This can be done by editing the account in the Microsoft 365 admin center, or with PowerShell. For example, here’s how to remove the Microsoft Bookings service plan (199a5c09-e0ca-4e37-8f7c-b05d533e1ea2) from an account licensed with Office 365 E3 (6fd2c87f-b296-42f0-b197-1e91e994b900):

$LicenseOptions = @{SkuId = "6fd2c87f-b296-42f0-b197-1e91e994b900"; DisabledPlans = @("199a5c09-e0ca-4e37-8f7c-b05d533e1ea2")}
Set-MgUserLicense -UserID Terry.Hegarty@Office365itpros.com -AddLicenses @($LicenseOptions) -RemoveLicenses @()

See this article for more details about how to use the Microsoft Graph PowerShell SDK to manage licenses for Azure AD accounts.

Creating a New Booking Page

New Booking pages (and calendars) are created through the Bookings icon in the OWA resource bar. You can block the ability to create new pages with the BookingsMailboxCreationEnabled setting in the OWA mailbox policy assigned to a mailbox. By default, the setting is True, which allows users to create new Bookings pages. Set it to False to stop this. For example:

Set-OWAMailboxPolicy -Identity "No Signatures" -BookingsMailboxCreationEnabled $False
Set-CASMailbox -Identity James.Ryan -OWAMailboxPolicy "No Signatures

Users can create a new booking page (and calendar) by selecting the Bookings icon in OWA. Oddly, people blocked from creating new pages are allowed to open the app and go through the process of entering details of the new page. It’s only when the time comes to create the page that the block descends, and they’re informed that permissions are needed to create a new booking calendar. When you think about it, the block imposed in the OWA mailbox policy refers to mailbox creation, and that’s what the block prevents. It’s just a pity that the app doesn’t stop people sooner.

When a user creates a new booking page, a background process creates a scheduling mailbox to host the calendar to store booking appointments. User mailboxes are associated with Azure AD accounts, and a first-party Microsoft enterprise app called Microsoft Substrate Management (object identifier e6ff64fa-aad6-4944-8e6c-c746c7b613a6) creates the accounts for the scheduling mailboxes. You can see this in the audit record created for a new account.

RecordType   : AzureActiveDirectory
CreationDate : 21/07/2022 13:01:58
UserIds      : ServicePrincipal_e6ff64fa-aad6-4944-8e6c-c746c7b613a6
Operations   : Add user.
AuditData    : {
                 "CreationTime": "2022-07-21T13:01:58",
                 "Id": "d007ed08-2dd8-436c-a12b-bad7df04e51e",
                 "Operation": "Add user.",
                 "OrganizationId": "a662313f-14fc-43a2-9a7a-d2e27f4f3478",
                 "RecordType": "AzureActiveDirectory",
                 "ResultStatus": "Success",
                 "UserKey": "Not Available",
                 "UserType": "System",
                 "Version": 1,
                 "Workload": "AzureActiveDirectory",
                 "ObjectId": "SeanLandyMedicalAppointments@office365itpros.com",
                 "UserId": "ServicePrincipal_e6ff64fa-aad6-4944-8e6c-c746c7b613a6",
                 "AzureActiveDirectoryEventType": 1,

The person who creates the new booking page becomes its administrator. Once the page is ready, the administrator can define the services to offer, their cost, and the people (staff) who can provide the service. Each user can be assigned a role for the page, such as team member (the default), supervisor, and viewer. Guest accounts are supported, but they can’t open the scheduling mailbox to view the calendar, so all their interactions are via email.

I noted that users granted the administrator role have full permission over the scheduling mailbox. However, if a user’s role is subsequently downgraded (say, to team member), they don’t lose the permission.

Making a Booking

As an example, let’s assume that the Office 365 for IT Pros writing team wanted to offer an IT consulting service. To set this up, I added the writers as staff members, defined a couple of very attractive services, and assigned different people as responsible for delivery of each service. I then enabled the page so that it’s available on the internet, and we’re open for business. Anyone can make a booking with us, even if they don’t have a Microsoft account.

When customers go to the bookings page, they see the information displayed in Figure 2 and can choose the service they want, who they want to deliver the service (or “anyone” to get a random consultant), and a time slot.

After everything is ready, the customer saves the appointment. Bookings creates a new Teams meeting for the selected date and time and sends out meeting requests to the participants. When the appointed time arrives, everyone joins the Teams meeting and the service is delivered. The only thing that’s missing is an integration with an online billing service like Stripe to collect the cash (a payment system originally offered by Microsoft is retired).

Because everything is organized around a calendar, the process of checking the calendar to see who’s occupied or available, assign time off (an appointment in the calendar), and so on is straightforward. If you can use OWA, you can use Bookings. Another good thing is that because all the bookings are stored in scheduling mailboxes, their content is indexed and discoverable.

Bookings for All

The Microsoft Bookings FAQ includes a list of ideas for how Bookings might be used. There’s lots of other good information to assimilate in the FAQ before plunging into an implementation of Bookings. I’d also spend some time playing with a couple of dummy Bookings pages to understand how the app works and how it meets the needs of different scenarios. It’s an app that’s worth checking out.

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.

Scripts Stop Working without Warning

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

The Broken Set-MailboxMessageConfiguration Cmdlet

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

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

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

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

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

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


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

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

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

Only One Fix (or Patience Required)

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

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

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

Easy When Vendor Does the Work to Upgrade Client

Last week, I discussed the need for email client upgrades to cope with the imminent termination of support for basic authentication for seven protocols used to connect to Exchange Online. In some cases, vendors are stepping up to the mark and making sure that clients switch easily over to modern authentication, with Apple’s project to upgrade mail app profiles being a notable example. Apparently, that’s going to happen when devices apply the iOS 15.6 upgrade.

Connecting IMAP4 clients to Exchange Online is popular in some market segments. Microsoft upgraded the IMAP4 and POP3 protocols with OAuth 2 support in April 2020, but an internet search doesn’t reveal much activity in terms of client upgrades with the except of Mozilla Thunderbird. The instructions to connect Thunderbird to Exchange Online using OAuth 2.0 are available online, including some nice write-ups from universities (here’s an example).

It’s a while since I used an IMAP4 client with Exchange Online, so to test the OAuth 2.0 connection, I downloaded Thunderbird 102.0.2.

Thunderbird’s Azure AD App

The implementation to achieve OAuth 2.0 support is interesting. Like any app that depends on Graph permissions, Thunderbird needs to create a registered Azure AD. In turn, the service principal for the app can receive consent for the permissions needed to access Exchange Online with POP3 and IMAP4, and to send messages using SMTP. Michel de Rooij has a good write-up on how the OAuth flow works for Thunderbird. Essentially, you to open a browser and run a command to add the app identifier created by Thunderbird to your tenant. The command I used was:

https://login.microsoftonline.com/22e90715-3da6-4a78-9ec6-b3282389492b/oauth2/authorize?client_id=08162f7c-0fd2-4200-a84a-f25a4db0b584&response_type=code&prompt=admin_consent

This command breaks down into:

• Login to Microsoft Online.
• Pass your tenant identifier (use the Get-MgOrganization cmdlet to get the identifier or look for it in the Azure AD admin center).
• Pass the client identifier (app identifier) for the Thunderbird app. This is always 08162f7c-0fd2-4200-a84a-f25a4db0b584.
• Prompt for consent.

When you create a registered app in Azure AD, you decide if the app is available in just your tenant or any organizational directory (any Microsoft 365 tenant). The app knows what permissions it needs to function, so when you run the command, you do two things:

• Create an entry for the app in the tenant’s Azure AD.
• Consent to the permissions needed by the app to run. As you can see from Figure 1, these are read and write access to mailboxes using IMAP4 and POP3. and send messages using SMTP AUTH. It’s best if an admin gives consent for an organization as this avoids the need for individual users to grant consent for the app to access their mailbox (if allowed by Azure AD settings).

When these permissions are in place, users can follow the instructions to configure their client to use OAuth for authorization (Figure 2). The important thing is to use SSL/TLS with OAuth2 to fetch messages from Exchange Online and StartTLS and OAuth2 to send messages via SMTP.

Guidance online (like these hints) offers some good suggestions like subscribing to folders in your Exchange Online mailbox to make them available to Thunderbird. It’s worth reading and passing to end users if they don’t already know this stuff.

SMTP AUTH Needed to Send Email

Everything works swimmingly. That is, if the mailbox is allowed to use SMTP AUTH to send messages. Usually, the IMAP4 connection works without a hitch and no problems are detected until the time comes to send messages, at which the server refuses to accept the message. Invariably, this is because the mailbox isn’t allowed to use SMTP AUTH. To fix the problem, run the Set-CasMailbox cmdlet to remove the block:

Set-CasMailbox -id "Tony Redmond" -SmtpClientAuthenticationDisabled $False

Once the block is lifted, mail should flow freely and you should have a happy IMAP4 user (Figure 3).

Connecting IMAP4 Clients to Exchange Online Might Need Upgrades

The Thunderbird implementation is smooth and should be easy for anyone to use. The difficulties I see are:

• People who have old Thunderbird clients with configurations that use basic authentication. These folk won’t be able to connect to Exchange Online after Microsoft switches basic authentication off and will need to change their settings and potentially update their client. Before anything works, the tenant administrator must create the registered app and consent to the necessary permissions.
• People who have other IMAP4 and POP3 clients where the app creator hasn’t produced an upgraded version to support OAuth 2.0. These people are out of luck and will need to adopt a different client.

With 78 days to go before October 1, it’s time to ensure that the IMAP4 clients to Exchange Online connection remains intact after basic authentication disappears. And while you’re at it, make sure that all your ActiveSync clients can too.

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.

First Step Along the Path in Loopifying Email

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

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

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

Implementing Loop for OWA

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

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

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

For Now, Loop is Focused on Internal Collaboration

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

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

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

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

The Need for Client Updates Will Slow Adoption of Loop Components

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

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

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

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

Good Tactical Move but Not the Right Strategy

Although I understand the tactical necessity for Microsoft to enable OAuth 2.0 authorization for programs wishing to use the POP3 and IMAP4 protocols to retrieve emails from Exchange Online, I don’t think it is the correct strategy for Exchange Online IMAP4 and POP3 access. Essentially, Microsoft is facilitating the continued use of antique messaging protocols instead of forcing developers to change to the Microsoft Graph APIs. I think that’s wrong, but I know why Microsoft is doing it.

The big basic authentication turnoff for Exchange Online is now just 88 days away. October 1 marks the point when Microsoft begins to disable seven email connectivity protocols for Exchange Online. It will take time for Microsoft to process all tenants, but eventually those wishing to use protocols like POP3, IMAP4, and Exchange ActiveSync will have no choice but to use modern authentication. In other words, a username and password won’t be enough.

Microsoft has been preparing to remove basic authentication from Exchange for over two years. The scale of Exchange Online, the product’s history, and the number of protocols and devices combine to create a myriad of complexities. Automatically upgrading the profiles for Apple’s device Mail app on iOS and iPadOS devices is a good example of the kind of detailed planning and technical execution involved in this project.

I don’t know how many companies have applications that use POP3 or IMAP4 to programmatically retrieve messages from mailboxes. Enough must exist for Microsoft’s fabled telemetry to detect a potential customer satisfaction problem should the turnoff proceed without an answer released with sufficient time for customers to prepare.

Registered Apps and IMAP4/POP3 Permissions

Microsoft’s solution is to allow customers to create Azure AD registered apps and assign the necessary permissions to allow the apps to use IMAP4 or POP3 to interact with mailboxes. Figure 1 shows the assignment of the IMAP.AccessAsApp permission to an app. The equivalent permission for POP3 access is POP.AccessAsApp.

After assigning the permissions, an administrator must grant consent to allow the app to use the permissions to access user mailboxes.

There’s nothing strange here. Apps follow the same process to allow them to use Graph API permissions to access other kinds of information from user accounts to Microsoft 365 groups. The only difference is that two specific permissions exist to control access via the IMAP4 and POP3 protocols.

Service Principals and Exchange Online

Registered apps have service principals, which are, in the words of a Graph API architect, “convenient holders for permissions.” Exchange Online boasts a new PowerShell cmdlet called New-ServicePrincipal to make the service principal of an app holding IMAP4 or POP3 permissions known. In this example, the $ClientId variable holds the application or client identifier for the app, the $ServiceId variable holds the object identifier for the service principal, and the $TenantId variable holds the tenant identifier.

$ServiceId = (Get-MgServicePrincipal -All | ? {$_.displayname -eq "POP3 and IMAP4 OAuth 2.0 Authorization"} | Select -ExpandProperty Id)
$TenantId = (Get-MgOrganization).Id
$ClientId = (Get-MgServicePrincipal -All | ? {$_.displayname -eq "POP3 and IMAP4 OAuth 2.0 Authorization"} | Select -ExpandProperty AppId)
New-ServicePrincipal -AppId $ClientId -ServiceId $ServiceId -Organization $TenantId -DisplayName "OAuth for POP3 and IMAP4"

Once a service principal is registered with Exchange Online, administrators can run the Add-MailboxPermission cmdlet to assign receive permissions to the service principal, just like the granting of regular delegate access to mailboxes.

Add-MailboxPermission -Identity "Kim.Akers@office365itpros.com" -User $ServiceId -AccessRights FullAccess

In passing, I should note that this is all theoretical on my part because the New-ServicePrincipal cmdlet is not available yet in any tenant that I have access to. In any case, the theory is clear:

• Create a registered app.
• Assign the appropriate permission(s) to the app.
• Make the app’s service principal known to Exchange Online.
• Use the app’s service principal to gain delegate access to specific mailboxes.

Application Access

I have no need to use IMAP4 or POP3 to access Exchange Online mailboxes, but I did want to test that I could get an OAuth 2.0 access token containing the necessary permissions. In production use, an app should use a certificate for authentication. To test, I used a client secret and ran this PowerShell code:

$Uri = "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token"
$Body = @{
    client_id     = $ClientId
    scope         = "https://ps.outlook.com/.default"
    client_secret = $AppSecret
    grant_type    = "client_credentials" }

# Get OAuth 2.0 Token
$TokenRequest = Invoke-WebRequest -Method Post -Uri $Uri -ContentType "application/x-www-form-urlencoded" -Body $Body -UseBasicParsing
# Unpack Access Token
$Token = ($tokenRequest.Content | ConvertFrom-Json).access_token

I then checked the access token and found that the expected permissions were present (Figure 2). All is well and the app has authorization to access the mailboxes.

Pragmatic, but Wrong Strategy

Developers will probably welcome Microsoft’s approach because it means minimal change for their code. All they need to do is replace the code to sign into a mailbox using basic authentication with code to get an access token. Afterward, the rest of the app code to access messages in a mailbox should work.

Pragmatic as it is, I think Microsoft’s approach is a short-term tactical win. The long-term solution is to move to the Outlook Graph API to access mailboxes. This uses the same registered app approach with different permissions, but it’s more functional. And anyway, app developers will have to embrace the Graph sooner or later to send email via SMTP. The SMTP AUTH protocol is a current exception to Microsoft’s effort to remove basic authentication for email connectivity, but that exception won’t last forever.

I guess that October 1 date is just too close to ask developers to recode their applications. But if you’re in the position where your tenant has some apps that exploit Exchange Online IMAP4 or POP3 mailbox access , consider dumping these old protocols and laying a better foundation for the future. If you have the time…

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

Cleaning Up a Mess

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

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

The good news is that Microsoft is enabling some control to how Outlook clients allow delegates to access and work with MIP-protected messages and their attachments. Differences exist between Outlook for Windows and the other Outlook clients interact with encrypted items and the controls Microsoft is now rolling out apply only to:

• Outlook Web App.
• Outlook for Mac.
• Outlook Mobile for iOS and Android.
• Mail App for Windows.

In their June 6 post, Microsoft acknowledges that “some inconsistencies” exist across the set of Outlook clients. Here’s what’s happening.

New PowerShell Cmdlets

The control is in the form of a set of three new PowerShell cmdlets in the Exchange Online management module. These are:

• Set-MailboxIRMAccess: Block a specified delegate from accessing encrypted messages in a user or shared mailbox.
• Get-MailboxIRMAccess: Check if a block exists for a specified delegate in a user or shared mailbox.
• Remove-MailboxIRMAccess: Remove a block from a user.

Full Access and Different Outlook Clients

Delegate access to encrypted messages depends on the type of mailbox and how the delegate receives full access permission:

• Outlook for Windows clients do not support delegate access to encrypted messages sent to user mailboxes. Delegates can only read encrypted messages if the sender includes the delegate as a TO or CC recipient. In this scenario, the delegate’s ability to read the message depends on the rights granted to them as a recipient. If the rights assigned to recipients include one applicable to the delegate, they can read the content. If not, they cannot.
• Outlook for Windows clients support delegate access to encrypted messages sent to shared mailboxes if the delegate has full access and auto-mapping is specified when the delegate receives permission to the mailbox. Auto-mapping forces Outlook for Windows to open the shared mailbox as part of the resources available to the delegate. It is the default used by Exchange Online and is assigned when granting full access to a delegate for a mailbox using the Microsoft 365 admin center or Exchange admin center.
• The other Outlook clients support delegated access to encrypted messages in both user and shared mailboxes if the delegate has full access to the mailbox.

Microsoft documents some restrictions that apply to delegate access for encrypted messages.

Blocking Access

To prevent delegates with full access to a user or shared mailbox from being able to view encrypted messages using clients other than Outlook for Windows, you can block their access by running the Set-MailboxIRMAccess cmdlet. For example, this command blocks the ability of Kim Akers to read any encrypted messages delivered to the Customer Services mailbox:

Set-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com -AccessLevel Block

To make sure that a block is in place, use the Get-MailboxIRMAccess cmdlet.

Get-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com

Identity                       User                           AccessLevel
--------                       ----                           -----------
Customer Services              Kim.Akers@office365itpros.com  Block

The time required to implement the block depends from client to client. OWA imposes the block within a few minutes, while other clients might take longer. It all depends when a client checks with the server to learn that a block is in place. When a block applies, delegates see that they don’t have the necessary permissions when they attempt to access encrypted messages (Figure 1).

A block placed on delegate access remains in place until an administrator removes it and only affects the ability of a delegate to read encrypted messages using clients that support the block. For instance, the block will stop a delegate reading encrypted messages in a shared mailbox using OWA or Outlook for iOS, but they can switch to Outlook for Windows to see the message content. In addition, blocking access does not hide message subjects, which can contain sensitive information, nor does it prevent a delegate from deleting or moving encrypted messages. The block exists for reading, and only works for clients that support the block.

To remove the block and restore the ability to read encrypted messages to a delegate, run the Remove-MailboxIRMAccess cmdlet:

Remove-MailboxIRMAccess -Identity Customer.Services@Office365itpros.com -User Kim.Akers@Office365itpros.com

Good Block for Confidential Information

Microsoft is addressing a real customer need with these controls. There’s no point in protecting confidential messages with sensitivity labels if an unintended recipient (a delegate) can read the content. It would be nice if all the Outlook clients worked the same way. However, that’s probably too much to hope for until the One Outlook project delivers a common client across all platforms. Given the speed that Project Monarch is moving at, that might take some time yet.

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

Options for Dealing with Leaver Mailboxes

When someone leaves an organization, a discussion often takes place about what to do with their mailbox and other data. For Exchange Online, the choice is straightforward:

• Delete mailboxes.
• Keep the mailboxes and let someone else take over the Azure AD accounts (and mailboxes).
• Change mailboxes to become shared mailboxes.
• Preserve them as inactive mailboxes.

Usually, the choice comes down to either a shared or inactive mailbox. Of course, the mailboxes belonging to ex-employees store other personal information in places like OneDrive for Business and Teams chat. Other information, like the documents kept in SharePoint Online sites, is by definition shared and remains accessible to other users. This discussion focuses on what to do about “leaver” mailboxes.

Shared Mailboxes

Shared mailboxes have existed in Exchange for a long time and are well understood. The advantages of transforming a user mailbox to be a shared mailbox are:

• The mailbox remains online and is accessible using any Outlook client. It appears in Exchange address lists like the GAL and can continue to receive inbound emails.
• Users can receive permission to access and recover mailbox contents. If necessary, administrators can grant users Send As and Send on Behalf Of permissions to allow them to send emails from the shared mailbox.
• When a user mailbox becomes shared, it no longer needs an Exchange Online license unless it is larger than 50 GB or has an archive.
• If necessary, administrators can easily change the mailbox back to become a regular user mailbox. At this point, it must have an Exchange Online license.

Changing a mailbox to be shared is a good approach when it’s necessary for other users to take over responsibility for the work of a departed employee. For example, the manager of a sales representative who leaves the organization needs to follow up on customer engagements and commitments. Privacy can be a big concern when someone gains access to another person’s mailbox because there’s probably some personal material among business-related emails. For this reason, organizations often limit access to a mailbox for a set period after which the mailbox is deleted.

Inactive Mailboxes

In an on-premises organization, it doesn’t matter if leaver mailboxes remain online. Licenses are not required because no one uses the mailboxes. If storage is available, leaver mailboxes can stay in place for as long as the organization wishes.

The situation is different within Office 365 as Exchange Online removes unlicensed mailboxes soon after the deletion of their owner’s Azure AD accounts. To make it possible for organizations to retain leaver mailboxes for compliance purposes, Microsoft introduced inactive mailboxes several years ago. If a hold applies to a mailbox or retention labels with holds exist on items in a mailbox, Exchange Online won’t delete the mailbox following the removal of its owner’s account. Instead, Exchange Online puts the mailbox into a hidden and inactive state. The content of the mailbox remains indexed and discoverable and can be found by eDiscovery searches.

The important things to remember about inactive mailboxes are:

• Inactive mailboxes remain online until the last hold (policy or retention label) lapses or an administrator removes a litigation hold on the mailbox. At this point, Exchange Online will retain the mailbox in a soft-deleted state for a further 183 days and then permanently removes the mailbox. Inactive mailboxes don’t need any type of license. Microsoft is reducing the recovery period to 30 days from September 2022 (it won’t make much difference).
• Inactive mailboxes are invisible to normal client interfaces, like OWA and Outlook desktop. They do not appear in Exchange address lists and cannot receive new emails.
• The complete content of a mailbox remains available when it becomes inactive, including its archive and the compliance records captured by the Microsoft 365 substrate for Teams, Yammer, and Planner.
• To access mailbox content, administrators must either recover or restore an inactive mailbox. Recovering an inactive mailbox makes it active and usable again. Restoring means that material from the inactive mailbox (or its archive) is merged into another mailbox.

Essentially, inactive mailboxes are a compliance tool. They facilitate long-term storage of mailbox content to ensure that the material in the mailboxes remains accessible if necessary. Inactive mailboxes are a good way to keep mailboxes of senior employees and other staff subject to regulatory oversight for extended periods. Figure 1 shows a tenant with shared mailboxes going back to February 2015 as viewed through the Microsoft 365 Purview portal.

If you have the licenses needed to use adaptive scopes with Microsoft 365 retention policies, you can create a user scope for inactive mailboxes. If the organization has the need to keep mailboxes for an extended period (say, five years), it’s a good idea to create a retention policy with a five-year retention period and an adaptive scope targeting inactive mailboxes. That way, even if the retention period for other holds and retention labels expire, you’ll know that Exchange Online will retain the inactive mailboxes for the required period.

The Choice is Clear

GUI access to inactive mailboxes is via the Microsoft Purview compliance portal. That gives you a good clue about the essential choice between inactive and shared mailboxes. If you want to keep information because it’s needed to satisfy some regulatory or legal requirements, use inactive mailboxes. But if the organization needs information in a mailbox for immediate business reasons, transforming a leaver mailbox into a shared mailbox is a better choice.

Learn about 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.

Second Major Issue with Exchange Online Audit Data

On May 19, Microsoft published Microsoft 365 message center notification MC382148 to disclose that an eight-week hiatus in generating audit events for delegated email send activity had happened. According to Microsoft, between January 28, 2022, and March 26. 2022, “some audit log entries were not generated for the Send As and Send on Behalf of delegate scenarios.” These events are captured when people use the Exchange SendAs and SendOnBehalfOf permissions to send email for other mailboxes.

Microsoft says that the root cause is a change in logging telemetry within auditing services. A fix is now in place to “help us minimize the possibility of an event like this happening again and will expedite future investigations.” However, because Exchange Online never generated the events, the Office 365 audit log never ingested the data, and the information is not in the log. Microsoft says that the missing data is irrecoverable.

This isn’t the first time that Microsoft has had a longstanding problem with ingestion into the Office 365 audit log (or unified audit log) for Exchange Online events. In September 2018, the developers knew of a problem with truncated data for group creation events. Microsoft didn’t fix that problem until May 2019.

Checking SendAs Events

To check the current situation, I searched for SendAs audit events in my tenant and found some generated during the problem period. I also ran a script that I’ve used in the past to report on these events and found some “interesting” information in the audit events. Here’s an example of a message sent by me on May 16 using Outlook mobile:

CreationTime          : 2022-05-16T11:03:47
Id                    : b5c89d0a-bb88-4620-6df9-08da372bc089
Operation             : SendAs
OrganizationId        : b662313f-14fc-43a2-9a7a-d2e27f4f3478
RecordType            : 2
ResultStatus          : Succeeded
UserKey               : 1003BFFD805C87B0
UserType              : 0
Version               : 1
Workload              : Exchange
ClientIP              : 2a01:b340:63:7141:a5cd:a160:e805:aae7
UserId                : Tony.Redmond@office365itpros.com
AppId                 : 27922004-5251-4030-b22d-91ecd9a37ea4
ClientIPAddress       : 2a01:b340:63:7141:a5cd:a160:e805:aae7
ClientInfoString      : Client=OutlookService;Outlook-iOS/2.0;
ClientRequestId       : 5009
ExternalAccess        : False
InternalLogonType     : 0
LogonType             : 2
LogonUserSid          : S-1-5-21-458367025-2064581115-2950179075-392557
MailboxGuid           : 0370f354-2752-4437-878d-cf0e5310a8d4
MailboxOwnerSid       : S-1-5-21-458367025-2064581115-2950179075-392557
MailboxOwnerUPN       : Tony.Redmond@office365itpros.com
OrganizationName      : Office365itpros.onmicrosoft.com
OriginatingServer     : DB7PR04MB4410 (15.20.4200.000)
SessionId             : 3431534d-331e-4924-b324-cbfa9cc55e24
Item                  : @{Id=LgAAAAAdhAMRqmYRzZvIAKoAL8RaDQA3tTkMTDKYRI6zB9VW59QNAAVriOkWAAAJ; InternetMessageId=<DB7PR04MB4410C9FC675493950D68FE668BCF9@DB7PR04MB4410.eurprd04.prod.outlook.com>; ParentFolder=;Sensitivity=2fe7f66d-096a-469e-835f-595532b63560; SizeInBytes=4428; Subject=Phone number}
SendAsUserMailboxGuid : 0370f354-2752-4437-878d-cf0e5310a8d4
SendAsUserSmtp        : Tony.Redmond@office365itpros.com

Three Properties with the Same Value

The problem with this audit record is that the User, MailboxOwnerUPN, and SendAsUserSmtp properties all have the same value. When a delegate impersonates another user to send a message, Exchange Online logs the delegate’s name in the User and MailboxOwnerUPN properties and captures the SMTP address of the impersonated user in the SendAsUserSmtp property. Having the same value in the three properties doesn’t make sense.

A closer examination of the SendAs events in the audit log revealed multiple cases where the three properties had the same value. Most of the events originated using the Outlook mobile client and, in all cases, the mailbox owner sent the message. There’s no reason why Exchange Online should consider this message to be a SendAs event because the mailbox owner sent the message. A common feature of all the messages logged erroneously as SendAs events is that they were addressed to external recipients.

Tests revealed that audit events for delegate messages sent using the Send As permission from the OWA and Outlook desktop clients capture the correct information. However, despite being present in the Exchange Online mailbox audit log, messages sent using delegate access from Outlook Mobile didn’t show up in the Office 365 audit log.

Interestingly, SendAs events also appeared for messages sent by mailbox owners from the preview version of the One Outlook client for Windows (Monarch). This client uses the same Microsoft sync technology connection as Outlook mobile does, so perhaps that’s where the issue lies. Figure 1 shows Exchange SendAs events from the audit log. The instances were owners sent messages rather than delegates are highlighted. All instances used the Outlook Mobile or Monarch clients.

In summary, two problems were found:

• Messages sent using delegate access from Outlook Mobile are not captured in the Office 365 audit log.
• Exchange Online captures messages sent by mailbox owners to external recipients using Outlook Mobile and Outlook Monarch in the Office 365 audit log as Send As events..

It’s an odd situation that appears to go back to at least February 2022. I guess no one noticed because we all accepted the validity of SendAs events in the audit log.

Problems Persist With Exchange SendAs Audit Data

Organizations depend on audit data to know what happens inside their tenants. Delegate email action are often examined to answer questions like “who sent that message,” and can make important contributions to compliance investigations.

Microsoft needed several attempts to fix the truncated audit record problem in 2018-2019. Now we have another instance where a longstanding problem with audit events generated by Exchange Online results in data loss and some odd results in audit data generated by Outlook mobile and Monarch clients. Testing software in the age of the cloud certainly appears to be a lost skill.

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 ultimate eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Sometimes PowerShell Needs a Little Help

Retrieving information about mailbox folder statistics is a common administrative activity. Exchange Online administrators usually reach for the Get-ExoMailboxStatistics and Get-ExoMailboxFolderStatistics cmdlets and build scripts around their output. This approach works, but it has some downsides:

• The cmdlets are “heavy” – they take a long time to run.
• Some of the output (like folder sizes) need manipulation before they can be used in computations.

Running Get-ExoMailboxStatistics to process a batch of mailboxes fetched using Get-ExoMailbox is not a quick operation. However, it gets the job done in terms of fetching mailbox folder statistics and that’s why you see this approach taken in scripts so often.

The history of these cmdlets goes back to the original implementation of PowerShell in Exchange Server 2007. At the time, the Exchange developers made the brave decision to build all of the Exchange 2007 administrative functionality around PowerShell, including the Exchange Management Console (EMC). The design focus for the cmdlets was on the retrieval and manipulation of data required by the console. No consideration was given to being able to access more than raw data, such as the size of the mailbox or the size of an individual folder and the number of items it contained.

The Role of EWS and the Graph

At the time, Exchange Web Services (EWS) was the public API available to developers who needed to go deeper into mailbox contents. For example, if you want to return both the number of items in the Inbox together with the unread count (here’s a StackOverflow discussion on the topic)

Today, the Microsoft Graph is the preferred option, which is where I headed when a reader noted their frustration at not being able to report the unread count for mailboxes. One reason why you might want to report unread counts is to monitor activity for shared mailboxes used to process customer requests. In any case, some business reason exists, so let’s explore how to respond.

Using the Mail API to Fetch Mailbox Folders

The Microsoft Graph Mail API contains the List Mail Folders call to return a collection of folders from a user’s mailbox. Some properties of interest to calculate mailbox folder statistics are included for each folder. Here’s an example of the data returned for a folder. As you can see, this folder is the Inbox, and the Graph returns an unread count.

id               : AQMkADY5NmJhYzk4LTA2ZGYtNGZkMy05NDJlLThlNDA1ZTMxZTU1AGMALgAAA4-72A-LRNdArLgWql46nuMBAEulavbT-91Jpzh8YFiJOcwAAAIBDAAAAA==
displayName      : Inbox
parentFolderId   : AQMkADY5NmJhYzk4LTA2ZGYtNGZkMy05NDJlLThlNDA1ZTMxZTU1AGMALgAAA4-72A-LRNdArLgWql46nuMBAEulavbT-91Jpzh8YFiJOcwAAAIBCAAAAA==
childFolderCount : 0
unreadItemCount  : 1715
totalItemCount   : 2818
sizeInBytes      : 721593032
isHidden         : False

Equipped with this knowledge, it’s easy to create a PowerShell script to fetch mailbox folder statistics by:

• Use an Azure AD registered app and an app secret to acquire an access token to interact with the Graph. The registered app must have consent to use the application Mail.Read permission (to access user mailboxes).
• Run Get-ExoMailbox to return the set of user mailboxes in the tenant.
• Loop through each mailbox to fetch the set of mail folders. This call doesn’t return folders like Contacts, Calendar, Tasks, and so on.
• Extract information about the Inbox.
• Capture the information in a report.
• Output the report (as a CSV file, Excel file, or other format – I decided to use Excel as described in this post).

The main loop is shown below:

ForEach ($M in $Mbx) {
    Write-Host ("Processing mailbox {0} of {1}: {2}" -f $i, $Mbx.Count, $M.DisplayName); $i++
    $Uri = "https://graph.microsoft.com/v1.0/users/" + $M.ExternalDirectoryObjectId + "/mailFolders?`$top=250"    
    $FolderData = Invoke-RestMethod -Headers $Headers -Uri $Uri -UseBasicParsing -Method "GET" -ContentType "application/json"
    $InboxData = $FolderData.Value | ? {$_.displayname -eq "Inbox"}
    $TotalMbxItems = ($FolderData.Value.totalitemcount | Measure-Object -Sum | Select -ExpandProperty Sum)
    $TotalMbxSize = ($FolderData.Value.SizeInBytes | Measure-Object -Sum | Select -ExpandProperty Sum)
    $ReportLine = [PSCustomObject][Ordered]@{  # Write out details of the mailbox
       "User"              = $M.DisplayName
       UPN                 = $M.UserPrincipalName
       InboxCount          = $InboxData.totalItemCount
       UnreadCount         = $InboxData.unreadItemCount
       TotalMbxFolders     = $FolderData.Value.Count
       TotalMbxItems       = $TotalMbxItems
       TotalMbxFolderSize  = [math]::Round($TotalMbxsize/1Mb,2)  }
      $Report.Add($ReportLine) 
}

By default, a call to retrieve mailbox folders returns the first 10 folders matching the query. Microsoft Graph queries limit the amount of data they return to minimize demand on services. A process called pagination allows developers to fetch successive pages of data until they exhaust all available data. In this case, we can either instruct the Graph to return more than the default amount (done here by using the Top parameter to specify that the script will accept up to mail 250 folders), or use a nextlink to fetch the next page of data until a nextlink is no longer available.

Figure 1 shows the output generated from the mailbox folder data returned by the Graph.

Graph is No Panacea

Because it includes only mail folders, the total mailbox data reported by the Graph API is not the same as returned by the Get-ExoMailboxStatistics cmdlet. The difference is accounted for by folders like Calendar, Contacts, and Tasks.

The Graph is not a universal panacea for access to mailbox data. It’s a tool that adds to the capabilities available to tenant administrators. In this instance, the combination of PowerShell and the Graph allowed us to find the unread count for the Inbox folder in mailboxes. It’s nice to have an additional method to get at data.

You can download the script I used from GitHub.

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.

October Deadline Looming

On May 16, Microsoft announced an update for scripts used for public folder migration to use modern authentication. With just 136 days to go before Microsoft starts the final turn-off of basic authentication for seven email connectivity protocols, including PowerShell, it’s evidence that even Microsoft has to do work to prepare for the transition of basic authentication PowerShell.

Exchange Online Remote PowerShell Still Used with Basic Authentication

This brings me to the sad fact that many who use PowerShell to interact with Exchange Online still use Remote PowerShell (RPS) with basic authentication. Among the reasons why this situation exists are:

• Lack of awareness that Microsoft will disable basic authentication for PowerShell in remaining tenants starting on October 1. Once Microsoft removes basic authentication from a tenant, scripts that attempt to connect using basic authentication will fail.
• Lack of visibility for scripts running within the tenant. Scripts might have been created and implemented without the knowledge of administrators, or maybe even by previous administrators who might not have documented their work.
• Lack of time and serendipity. For example, it’s common to find that people include commands to connect to different services in their PowerShell profile. If the profile is more than a year old, it’s likely to use outdated connectivity.

In addition, if you search for “How to connect to Exchange Online with PowerShell” in blogs, articles, and books, you’ll probably find that the recommended method is to run the New-PSSession cmdlet to connect to Microsoft Exchange. Anyone checking out best practices in this area can be forgiven if they come away from a search with the impression that this is the best method. The only problem is that it creates a Remote PowerShell session using basic authentication, just like people have done for a decade.

Exchange Online Management Module

Microsoft introduced the Exchange Online Management module in 2019. At the time, the big headline was the creation of nine REST-based cmdlets designed to replace the set most likely to experience problems in cloud environments. The new cmdlets like Get-ExoMailbox and Get-ExoMailboxStatistics are faster and more tolerant of network issues and I was happy to talk about the cmdlets at the Ignite 2019 conference.

The new module also supported modern authentication. From version 2.0.3 onward, the module supports certificate-based authentication. The RPS cmdlets have a dependency on WinRM. Microsoft is removing the WinRM dependency by upgrading the RPS cmdlets. Substantial progress has been made in the preview version of the module and the most heavily used of the RPS cmdlets no longer depend on WinRM.

Work is ongoing to complete the upgrade for the remainder of the RPS cmdlets and hopefully, Microsoft will make the preview module that includes the upgraded RPS cmdlets generally available soon. The work to upgrade the remaining RPS cmdlets doesn’t have to be completed by October because Microsoft is not deprecating the WinRM connection when it turns off basic authentication for Exchange Online connections.

Note that if you use the preview version of the module, you must include the UseRPSSession parameter to load all the RPS cmdlets. If you don’t, Exchange only loads the upgraded RPS cmdlets. For more information about the different combinations of PowerShell and authentication supported by Exchange Online, see this blog post.

Call to Action: Avoid Basic Authentication PowerShell

The need for action is real. If tenants don’t check Exchange Online scripts to make sure that they connect to Exchange Online using modern authentication, they’ll have problems sometime after October 1 when scripts stop working. Because the Connect-ExchangeOnline cmdlet loads the old RPS cmdlets when it runs, the work to upgrade scripts is straightforward. That is, if you can find all the scripts that need to be updated.

While you’re making sure that scripts connect properly, take the time to check that any connections made to the security and compliance endpoint do so through the Connect-IPPSSession cmdlet.

You can go ahead and convert old cmdlets like Get-Mailbox to their upgraded equivalents to gain extra performance and stability, but this work doesn’t have to be done now (and will take substantially more effort in terms of coding and testing). The immediate priority is to make sure that scripts continue to connect and function after October.

Remember Azure AD Too

PowerShell developers have an even closer date to focus on. Microsoft plans to introduce a new license management platform for Microsoft 365 on 26 August 2022. That’s only a hundred days away before scripts that use cmdlets from the Azure AD and Microsoft Online Services (MSOL) modules for license management cease to work. It’s the first step along the path toward full depreciation of the modules in late 2022 or early 2023.

Limited time exists to validate that Exchange Online scripts work with modern authentication. No one wants to be the person who fails to take the necessary steps to update scripts, or to take the call when people discover that important scripts stop working.

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.

Good and Bad in Every Change

Last month, I discussed the change Microsoft will make to the composition of the Name and Distinguished Name properties for new mailboxes. According to MC365786 (April 30), deployment of the change will start at the end of May to finish in late July. It’s important to emphasize that the Exchange Online Name change applies only to new mailboxes: the properties of existing mailboxes remain intact unless you decide to update them.

Update 30 November 2022: Microsoft continues to push out the deployment date for this change. The earliest date is now January 2023.

Like any change, there are good and bad points to consider. Microsoft likes the change because the use of the external directory object identifier (EDOID) guarantees uniqueness for the Name and Distinguished Name properties. The EDOID is the GUID for the Azure AD object which owns a mail-enabled object in the Exchange Online Directory.

It’s worth noting that the Microsoft 365 and Exchange Online (Figure 1) admin centers do not expose the Name or Distinguished Name properties. If you want to apply the Exchange Online name change to pre-existing mailboxes, you must do this through PowerShell by running the Set-Mailbox cmdlet.

Care Needed with PowerShell Scripts

In my previous post, I gave some examples of where PowerShell developers might need to be careful about dealing with the output returned by an Exchange Online cmdlet, such as the owners of a distribution list. I ran into such a situation when looking at the script that creates the Microsoft 365 Groups and Teams membership report.

The report includes the owners of each group. The original code referenced the group owners using the ManagedBy property returned by the Get-UnifiedGroup cmdlet. This is an array list containing the Name property of each of the group owners. This was fine when EDOIDs are not involved, but when these values are present, a list of owners might look something like this:

$Group.ManagedBy

bff4cd58-1bb8-4899-94de-795f656b4a18
Sean.Landy
Ben.James

The EDOID is unique, but it’s hard for humans to understand.

The updated code loops through the array returned by Get-UnifiedGroup and then calls the Get-Recipient cmdlet to return the display name of each owner. Finally, we join the list of owners together into a value that goes into the report:

[array]$Owners = $Null
ForEach ($Owner in $Group.ManagedBy) { # Unpack the owners and retrieve a display name that's usable.
        $OwnerDisplayName = (Get-Recipient -Identity $Owner.trim()).DisplayName
        $Owners += $OwnerDisplayName }
     [string]$OwnersOutput = $Owners -join ", "

$Owners
Tony Redmond
Sean Landy
Ben James

The change doesn’t affect Microsoft Graph queries executed through PowerShell because the Graph returns full details of group owners, and you can pick what properties to use. This is a typical query to return the owners of a group (identified by the EDOID passed in $Group.Id):

$Uri = "https://graph.microsoft.com/v1.0/groups/" + $Group.Id + "/owners?"
If you use the Microsoft Graph PowerShell SDK, the solution is:
[array]$ManagedBy= Get-MgGroupOwner -GroupId $Group.ExternalDirectoryObjectId
[array]$Owners = $Null
ForEach ($Owner in $ManagedBy) {
    $OwnerDisplayName = (Get-MgUser -UserId $Owner.Id).DisplayName
    $Owners += $OwnerDisplayName }

an update to return human-friendly values. Sometimes (as when Get-Recipient lists mailboxes), Exchange Online tells you when it uses the Name property. Sometimes (as in checking the holders of the Send on behalf of permission for a mailbox), it doesn’t.

The Problem with Special Characters in Distinguished Names

Updating the Name property to use the EDOID has a knock-on effect on the DistinguishedName property. After updating the Name property, Exchange Online rewrites the DistinguishedName property with the new Name value. One advantage from this change is that you’ll no longer need to deal with distinguished names containing special characters.

For example, the surname for this guest account is O’Malley, and some of the account properties are as follows:

Get-Recipient -Identity 388d29d7-4c72-476d-be96-53060043122e | fl Name, DisplayName, DistinguishedName, Name

Name              : o'Malley.Linda_contoso.com#EXT#
DisplayName       : Linda O'Malley
DistinguishedName : CN=o'Malley.Linda_contoso.com\#EXT\#,OU=office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com
Name              : o'Malley.Linda_contoso.com#EXT#

You can see that Exchange derives the first part of the DistinguishedName from the Name property.

Using Distinguished Names in Scripts

It’s common to use the DistinguishedName to find the groups that an account belongs to in code like this:

[string]$DN = (Get-Recipient -Identity $User.ExternalDirectoryObjectId).DistinguishedName
[array]$Groups = (Get-Recipient -ResultSize Unlimited -RecipientTypeDetails GroupMailbox -Filter "Members -eq '$DN'"

Running the code for the Linda O’Malley account generates this error:

Cannot bind parameter 'Filter' to the target. Exception setting "Filter": "Invalid filter syntax. For a description of
the filter parameter syntax see the command help.
"Members -eq 'CN=o'Malley.Linda_contoso.com\#EXT\#,OU=Office365ITPros.onmicrosoft.com,OU=Microsoft Exchange Hosted
Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com'" at position 19."

One solution is to adjust the filter to handle mailboxes with special characters in distinguished names. A check for apostrophes invokes special processing to “escape” the character before performing the check.

$DN = (Get-Recipient -Identity $Guest.Id).DistinguishedName 
#    The distinguished name for some accounts might contain an apostrophe, so we need to handle this
     If ($Dn -like "*'*")  {
       $DNNew = "'" + "$($dn.Replace("'","''''"))" + "'"
       $Cmd = "Get-Recipient -Filter 'Members -eq '$DNnew'' -RecipientTypeDetails GroupMailbox | Select DisplayName, ExternalDirectoryObjectId"
       $GuestGroups = Invoke-Expression $Cmd }
     Else {
       $GuestGroups = (Get-Recipient -Filter "Members -eq '$Dn'" -RecipientTypeDetails GroupMailbox | Select DisplayName, ExternalDirectoryObjectId) }

Updating Mail User Objects

Using the EDOID for the Name property removes the need write code to accommodate accounts with special characters in their names. The downside is that Microsoft’s change only affects new mailboxes. However, there’s nothing to stop us updating the Name property for mail user objects for guest accounts to eliminate special characters. Here’s how to make the change for all mail users in a tenant:

[Array]$MailUsers = Get-MailUser -ResultSize Unlimited
ForEach ($Mu in $MailUsers) {
 Write-Host ("Updating mail user object for {0}" -f $Mu.DisplayName)
 Set-MailUser -Identity $Mu.ExternalDirectoryObjectId -Name $Mu.ExternalDirectoryObjectId }

I haven’t run into any problems with scripts after updating all the mail user objects for guest accounts in my tenant.

Pause for Thought

I’m not advocating that organizations should rush out to update the name property of every mail-enabled object. It’s better to wait and see if Microsoft updates their code to use the EDOID for the Name and DistinguishedName properties of all mail-enabled objects in Exchange Online. However, if your tenant has some mail-enabled objects with special characters in their name, you can simplify PowerShell scripts by applying a quick and simple change to those objects. And that’s a nice thing.

And Microsoft Issues Block to Stop People Using Leaked Client

Update: Microsoft has now released a public preview of the Monarch client. You can download the preview if you are a member of the Office Insiders program. See this post for details. The preview version is not very different to the leaked software.

A leaked build of Microsoft’s “One Outlook” client emerged last week. It wasn’t very exciting because it’s what Microsoft described during sessions at the Ignite conference in September 2020. “Project Monarch” is making progress, but it’s not the kind of fundamental breakthrough redevelopment of Microsoft’s venerable email client that some anticipated.

What leaked is a version of the Outlook Web App (OWA) client currently available to Exchange Online users. The client is complete with links in the navigation bar to invoke Yammer and Bookings, and icons to start a Teams chat or fast access to To Do tasks (Figure 1).

Support for shared mailboxes, Microsoft 365 Groups, sensitivity labels, and calendar board views is included, as is full support for Microsoft Editor, tab completion of phrases (with some interesting hiccups), and so on. I was even able to open a public folder. One thing that’s missing is Loop components, which Microsoft plans (MC370366) for both OWA and Outlook for Windows this month.

The Project Monarch client is packaged as a Progressive Web App (PWA) with limited offline capabilities (some calendar and email information is available, but not item contents). You can sign into the client with an Azure AD account, but not a consumer Microsoft Services account.

Prettier OWA

In a nutshell, this Project Monarch build is a slightly prettier version of OWA. When it’s feature-complete, it’s easy to see how Microsoft will slip this client in to replace:

• OWA in Exchange Online (Office 365).
• OWA in Outlook.com.
• The basic Mail app in Windows 11.

Of course, each version of the client will have different capabilities, but they’ll all use the same basic framework, and that’s the important point.

Core Technologies

Three core technologies form the One Outlook framework (see this Ignite 2020 video):

• OPX – OWA Powered Experiences (Figure 2): a method to allow other clients to consume features developed for OWA. A good example is how Outlook for Windows uses the OWA Room Finder. OPX depends on the WebView2 component, developed by the Edge team. WebView2 is also key to the Teams 2.0 client architecture.
• Microsoft Sync Technology: the synchronization protocol currently used by the Outlook mobile (iOS and Android) and the Outlook for Mac clients to interact with Exchange Online. The word is that Outlook for Windows will eventually move away from MAPI over HTTP to use this protocol.
• Augmentation Loop: a way to coordinate the services and data consumed by Outlook clients. Instead of Outlook building separate interfaces to plug new services into clients, they plug into the augmentation loop.

Synchronize My Mailbox

Offline working is the big gap that Microsoft must plug before replacing the Outlook desktop client is possible. For the last twenty years, Outlook has been able to synchronize a user’s entire mailbox using network smarts like drizzle-mode synchronization and priority threads. A replacement for Outlook desktop must be capable of sophisticated offline working, meaning that the client needs to be able to do more than basic send and receive of email. There’s no evidence of progress toward this goal in the leaked PWA.

Blocking the Leak

In response to the leak, Microsoft released MC376710 late on May 6 to say that “some users can access an unsupported early test version of the new Outlook for Windows.” The announcement appealed for customers to wait until Microsoft releases an official beta, promising more news about the beta “in the coming weeks.”

Microsoft also gave instructions about how to block mailboxes from synchronizing with the new Outlook. To do this, connect to Exchange Online with PowerShell and run the Set-CasMailbox cmdlet to block access, just like you’d block a mailbox from accessing a protocol like IMAP4 or Exchange ActiveSync.

Set-CasMailbox -Identity Kim.Akers -OneWinNativeOutlookEnabled $False

When the block is in place, the new client fails to connect to the user mailbox and issues the error shown in Figure 3.

Microsoft suggests that organizations use the block to prevent people from using the new client until the official beta is ready. In other words, they’d like you to run some code like this:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-CasMailbox -OneWinNativeOutlookEnabled $False

And when Microsoft releases the official beta, you can reverse the block with:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-CasMailbox -OneWinNativeOutlookEnabled $True

The Slow Pace of Development

After all the excitement dies down, we’re left with the conclusion that Project Monarch is moving ahead, albeit slowly. We see the tip of the iceberg in the leaked client. Underneath, I’m sure that Microsoft is working through a bunch of software engineering challenges to create the foundation for a single base that can support multiple variations of Outlook clients. We await the news of the official beta as promised by Microsoft.

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

October 1 Marks the Start

On May 3, Microsoft published its May update describing progress toward their goal of removing basic authentication for seven email connection protocols starting in October 2022. With 150 days to go, Microsoft wants tenants to make sure that they’re prepared for the big turnoff.

Update (September 1): Microsoft is granting tenants the ability to get a three-month extension before retiring basic authentication. See this article for more detail. January 1, 2023 is the new drop-dead date.

By now, there should be no need to rehearse the logic behind the move. Basic authentication for email is a major vector for the compromise of user accounts. Attackers use techniques like password sprays to penetrate accounts using the flimsy protection afforded by basic authentication and proceed to wreak havoc. Business email compromise (BEC) leading to financial loss is only one of the joys available following account penetrations.

Five Big Points to Understand

Among the nuggets in Microsoft’s post, I noted five important points:

• They have already disabled basic authentication in millions of tenants that were not using the affected protocols. “Millions” is the keyword here. It demonstrates the scale and scope of this effort and the size of Exchange Online.
• Disabling of basic authentication for Exchange Web Services (EWS), Remote PowerShell, POP3, IMAP4, MAPI over RPC, Exchange ActiveSync, and the Exchange Offline Address Book (OAB) commences on October 1. Remember the scale of Exchange Online? It will take time for Microsoft to work through all the Office 365 data center regions to turn off the protocols for millions of tenants. They anticipate completion at the end of 2022, but protocol disablement could come to your tenant at any time after October 1, so you need to be prepared.
• No one gets to vote when Microsoft blocks basic authentication for their tenant. Selection is random. It just happens.
• SMTP AUTH is an exception and support of basic authentication for this protocol continues for now. But that’s no reason to ignore the bright lights signaling that Microsoft is likely to disable basic authentication for SMTP AUTH soon. Microsoft isn’t saying when they will proceed, but you should start to upgrade scripts and devices which send email using SMTP AUTH connections to Exchange Online as soon as possible.
• Apple devices running recent operating systems that use Exchange ActiveSync to connect the native Apple Mail app to Exchange Online mailboxes can use modern authentication. However, the configuration of the connection to Exchange must specify modern authentication. If a new device copies an existing configuration from an old device (for example, when someone updates an old iPhone to the latest model), the configuration might specify basic authentication. These devices won’t be able to connect to Exchange Online after Microsoft blocks basic authentication. Read this article for more information and consider auditing Apple device connections to identify the devices still using basic authentication.

Use Authentication Policies to Block Protocols

Another important point is that authentication policies are available to block basic authentication for selected protocols now. You can be proactive and block protocols like POP3 and IMAP4 that attackers love using to compromise accounts. It’s a good step to take to stop people using old and vulnerable clients.

A tenant administrator might be lulled into a false sense of security because they’ve deployed Azure AD conditional access policies to protect user accounts, or because they’ve disabled protocols like POP3 and IMAP4 for mailboxes through the Set-CasMailbox cmdlet. These are good steps to take, but they only kick on after an account successfully authenticates – and that might be too late. Blocking protocols with authentication policies stops attackers from authenticating (and knowing that they have valid credentials), meaning that attempted attacks come to a crashing halt.

Time to Get Going

When this post appears, it will be 147 days until 1 October. Three days have slipped away since Microsoft posted its blog. If you’ve had other things on your plate and haven’t progressed the preparation for the big basic authentication turn-off, it’s time to get going.

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

Recipient Moderation Works for All Mail-Enabled Objects

A discussion about moderated distribution lists was a throwback to the past. You hardly hear much about recipient moderation these days, but it was a big thing when Microsoft added it to Exchange 2010. Moderation works for both on-premises and cloud recipients, and it works in hybrid deployments too (there’s a good write-up about troubleshooting moderation on the EHLO blog).

Moderation works for all kinds of mail-enabled objects: mailboxes, dynamic and normal distribution lists, mail users and contacts, public folders, and Microsoft 365 groups. It’s a good feature to use to protect sensitive recipients from receiving emails from all and sundry.

A typical deployment scenario is to moderate messages sent to senior executives by forcing a review by an executive assistant before Exchange can deliver the messages to the target mailboxes. Moderation supports bypassing, meaning that you can define sets of users or distribution lists whose messages are not subject to checks. When an email comes from bypass senders, Exchange delivers it directly.

Moderation in Action

When moderation happens, an arbitration mailbox sends details of the email to the designated reviewers (moderators), who can approve or reject the message (Figure 1).

The response goes back to the arbitration mailbox, which releases the message for final delivery if the response is positive. If the response is negative, the arbitration mailbox returns the email to the original sender with a note to tell them that a moderator rejected its delivery. If a moderator doesn’t process the message within two days, it’s returned to the original sender to tell them that moderation didn’t happen.

Moderators have full access to messages awaiting approval, even if sensitivity labels encrypt message content and they wouldn’t normally have the right to read it. Because it needs to be able to check messages as they pass through the transport pipeline, the Exchange transport service has super-user access to all encrypted content. The transport service can decrypt the protected message when it sends the copy for approval, which is how the moderator can review the email.

You can even have a situation where a moderator reads a message, approves it for delivery, and the final recipient can’t read the email because the sensitivity label doesn’t grant them the right to access it. This underlines the point that senders should always know what rights a sensitivity label applied to email grants to recipients.

The Problem with Outlook

Coming back to the problem under discussion, the query was about why OWA can expand the membership of a moderated distribution list and Outlook for Windows cannot. On the surface, there’s no good reason why this should be so. Unlike a dynamic distribution list whose membership depends on directory attributes, the membership of a moderated distribution list is static and known. Even the Outlook address book agrees and is perfectly willing to display a list’s members (Figure 2).

When a user asks OWA to expand the membership of a moderated distribution list, it’s happy to do so (Figure 3).

But Outlook refuses point-blank, even if the plus sign appears to show that the client supports the expansion of a distribution list (Figure 4). Normally, if you click the plus sign, Outlook warns that if you expand the list, Outlook replaces the distribution list with the individual addresses of its members. Once this happens, you can’t collapse the individual members back to the list. I don’t know what Outlook means by a moderated public group either (as noted in the comments, this turns out to be a Microsoft 365 group…)

For the record, Outlook mobile avoids the issue by not offering the option to expand the membership for any distribution list.

One Outlook

Inconsistencies like this in client families madden users. In this case, it’s probably a small issue that affects very few users and an obvious and viable workaround exists, all of which means that Microsoft is unlikely to fix whatever is causing Outlook to fail to deal with moderated distribution lists. Maybe the fabled Project Monarch (aka “One Outlook”) app, apparently due to enter public preview soon, will address the inconsistency. But I wouldn’t hold your breath!

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

Distinguished Names and Exchange History

Update November 18, 2022: Microsoft began the rollout of the change to make the Name parameter have the same value as the ExternalDirectoryObjectId (EDOID) in September. However, they have paused the rollout until January 2023. Some tenants have the feature now.

On April 13, the Exchange development group announced a change that took a little part away from the product’s history. Microsoft wants to alter the format of the Name and DistinguishedName attributes for mailboxes to make them more unique and plans to use the external directory object identifier (aka EDOID) instead.

When Microsoft launched Exchange 4.0 in 1996, the X.400 and X.500 standards still exerted a huge influence on the world of email. Because of this, the developers used X.500-like naming conventions within the Exchange directory store (DS), the forerunner of what became Active Directory when Windows 2000 launched in 1999 and Azure Active Directory later. X.500 objects use distinguished names as unique identifiers. To create an X.500 distinguished name, you concatenate attributes to form a path to the named entry. Exchange Online mail-enabled objects still have these values in the LegacyDn property, where you’ll find something like this:

o=ExchangeLabs/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=43bdc98a69d147568728728be0335b34-James.Keane

Exchange Online has its own form of distinguished names, which still serve as unique identifiers for objects. Here’s an example:

CN=James.Keane,OU=office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

The CN (common name) portion comes from the mailbox name. The OU (organization) entities identify the Microsoft 365 tenant and Exchange Online, while the DC entities give the path to the Outlook.com domain controller Exchange Online connected to when it created the mailbox.

Make Synchronization Happy

What Microsoft is now saying is that the format used for Exchange Online distinguished names needs to change. They have encountered situations where conflicts happened when objects synchronize from Azure Active Directory to Exchange Online. When they considered how the conflicts occurred, they decided that a better source of uniqueness is necessary.

Microsoft proposes to change the generation of the Name property for mail-enabled objects from its current basis (the MailNickName or Alias) to use the external directory object identifier pointing to the Azure AD account owning the object. Let’s explore what that means.

Using Unique Identifiers

All Azure AD objects have unique identifiers (GUIDs). When you create a new Microsoft 365 account with an Exchange Online license, Exchange Online takes the account’s MailNickName property and uses that for the mailbox name and alias properties. For example, if you create a new account with a username of Sue.P.Pickett@office365itpros.com, among the Azure AD account properties are:

• GivenName: Sue
• Surname: Pickett
• MailNickName: Sue.P.Pickett
• Mail: Sue.P.Pickett@office365itpros.com
• UserPrincipalName: Sue.P.Pickett@office365itpros.com
• ObjectId: b67c8bd7-a8d3-4358-b42f-cd51821f7ba3

When Exchange Online creates a mailbox, it takes the MailNickName value and uses it to create the mailbox alias, name, and distinguished name. The first two properties have the same value as MailNickName, while the distinguished name becomes:

CN=Sue.P.Pickett,OU=office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

In addition, Exchange Online writes the Azure AD account ObjectId into the mailbox’s ExternalDirectoryObjectId property. You can use this value to find a mailbox, as in:

Get-ExoMailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Properties Name

ExternalDirectoryObjectId : b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
UserPrincipalName         : Sue.P.Pickett@office365itpros.com
Alias                     : Sue.P.Pickett
DisplayName               : Sue Pickett
Name                      : Sue.P.Pickett
DistinguishedName         : CN=Sue.P.Pickett,OU=Office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

Microsoft’s proposed change means that Exchange Online will use the Azure AD account identifier for the mailbox name and as the CN part of the distinguished name. Hence, we end up with:

Get-ExoMailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Properties Name

ExternalDirectoryObjectId : b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
UserPrincipalName         : Sue.P.Pickett@office365itpros.com
Alias                     : Sue.P.Pickett
DisplayName               : Sue Pickett
Name                      : b67c8bd7-a8d3-4358-b42f-cd51821f7ba3
DistinguishedName         : CN= b67c8bd7-a8d3-4358-b42f-cd51821f7ba3, OU=Office365itpros.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EURPR04A002,DC=prod,DC=outlook,DC=com

Because an Azure AD account identifier is unique within Microsoft 365, the properties of the Exchange mailbox will also be unique, and it solves the synchronization problems. In fact, you can write the account identifier into a mailbox’s Name property today if you want:

Set-Mailbox -Identity b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 -Name b67c8bd7-a8d3-4358-b42f-cd51821f7ba3

When you update the Name property, Exchange updates the mailbox’s distinguished name so that the CN part of the name matches the value assigned to the Name property.

Distinguished Names and Exchange Online

Distinguished names only exist within Exchange Online. No trace of them exists in Azure AD object properties because the link between Azure AD and Exchange Online is via the external directory object identifier. This property exists for all Exchange Online objects which have a corresponding object in Azure AD:

• Mailboxes (all types – user, shared, room, group).
• Distribution lists (but not dynamic distribution lists or room lists).
• Mail contacts.
• Mail users.

Microsoft says that the change will apply only to new mail-enabled objects. They don’t plan to retrospectively update older objects with the new naming scheme. When the new naming scheme rolls out, Microsoft says that they will stop the ability of administrators to update the mailbox Name property using cmdlets like Set-Mailbox and Set-User, which seems logical.

A Pause for Reflection

Soon after Microsoft posted their blog, they added an update saying that based on feedback, they will delay making the change and will give a new schedule at the end of April. I think this is reasonable. Although I’m not worried about using object identifiers in distinguished names, the Name property is a little different because Exchange Online exposes it more often. For instance, if you look at who manages a distribution group, this output doesn’t look right:

Get-DistributionGroup -Identity "Users External Email Monitoring" | ft ManagedBy

ManagedBy
---------
{bff4cd58-1bb8-4899-94de-795f656b4a18}

And listing user mailboxes with Get-Recipient looks odd:

Get-Recipient -RecipientTypeDetails UserMailbox

Name                                 RecipientType
----                                 -------------
bff4cd58-1bb8-4899-94de-795f656b4a18 UserMailbox
Kim Akers                            UserMailbox
Ben Owens                            UserMailbox
Terry.Hegarty                        UserMailbox
John.West                            UserMailbox
66b08473-dff2-4058-9170-0b4eab6e0987 UserMailbox
b67c8bd7-a8d3-4358-b42f-cd51821f7ba3 UserMailbox

While checking who has the Send As permission for a shared mailbox becomes more of a chore:

Get-EXOMailbox -Identity CServices -Properties GrantSendOnBehalfTo | ft DisplayName, GrantSendOnBehalfTo

DisplayName       GrantSendOnBehalfTo
-----------       -------------------
Customer Services {bff4cd58-1bb8-4899-94de-795f656b4a18}

Exchange and Microsoft 365 user interfaces will hide the switchover because they can take the GUIDs and resolve them into “pretty” values like display names (Figure 1).

Any potential problems will arise in administrative scripts which use the Name or DistinguishedName properties and expect values returned by Exchange Online to follow a certain format. Scripts (like this one to report distribution lists and their managers) that resolve values to retrieve display names are unaffected by the change.

Like any modification proposed for something which has been in use for a very long time, there are bound to be some edge cases that turn up and need resolution. I believe the Exchange developers are on the right path to seek unique anchors for synchronization. I just hope that they can get there without causing too much upheaval for customers.

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.

Useful but Aging Cmdlet

I’m bemused when I see sites treat the Get-MailTrafficSummaryReport cmdlet as if it has some magical powers, like proclaiming it to be one of the top 10 cmdlets for email monitoring. The sad fact is that although the cmdlet is useful, it has aged without much progression over the last few years, which might be why Microsoft attempted to retire it in 2021. That venture failed because of customer feedback, but I’m insure why people feel so strongly about the cmdlet.

Summarizing Message Trace Data

Essentially, the Get-MailTrafficSummaryReport cmdlet takes the message trace data retained by Exchange Online for the last 90 days (give or take a day or two depending on background processing) and summarizes the data under various categories. The most popular are:

• TopMailSender: Report the number of messages sent by different mail-enabled objects, including user mailboxes, shared mailboxes, and guest accounts. Separate counts are given for each proxy address assigned to a mail-enabled object.
• TopMailRecipient: Report the number of messages received by different proxy addresses for mail-enabled recipients. As for senders, separate counts are available for each proxy address assigned to a mailbox.
• TopMalware: Report malware (like Win32/Tnega.SM!MTB) detected in inbound messages.
• TopSpamRecipient: Report the number of spam messages intercepted for mail-enabled recipients. I use different test accounts for articles. Within a week of publishing a test account’s email address in an article, I know that spam begins to arrive for that account. The report also shows spam addressed to mail-enabled recipients that no longer exist, like mailboxes belonging to deleted accounts.
• TopMalwareRecipient: Like spam, but these messages are deemed by Exchange Online Protection to contain malware.
• InboundTransportRuleHits: Report the transport rules which process inbound email. The report lists the individual rules and the number of messages processed by each rule. You can filter by the name of one or more transport rules by passing the names of the rules in the TransportRule parameter.
• OutboundTransportRuleHits: Report transport rules which process outbound email.

The cmdlet supports reporting for Data Loss Prevention (DLP) rule hits. I don’t use categories like OutboundDLPPolicyRuleHits (DLP rules detected a policy violation in an outbound email) as much as the categories listed above.

The statistics generated by the cmdlet come from a data warehouse. As such, the information is not real-time in the same way that running Get-MessageTrace can report the progress of a message sent a few seconds ago. Having a time lag for usage data isn’t unusual within Microsoft 365. The normal delay before data becomes available is around two days.

Example of Get-MailTrafficSummaryReport

Most articles covering Get-MailTrafficSummaryReport focus on the top senders and top recipients reports. Looking at something different, here’s how to run a report for outbound messages processed by transport rules. The outbound shows that the transport rule to apply a disclaimer to responses for calendar meeting requests is the most popular in my tenant.

Get-MailTrafficSummaryReport -Category OutboundTransportRuleHits -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2, C3

C1                                   C2                  C3
--                                   --                  --
Calendar Disclaimer                  SetAuditSeverityLow 201
Automatic BCC                        SetAuditSeverityLow 22
Block Email to Tenant Admin Accounts SetAuditSeverityLow 11
Block Power Automate                 SetAuditSeverityLow 7

The cmdlet output uses C1, C2, and C3 (columns 1, 2, and 3) as non-specific header names because the various reports generate different pieces of data. Sometimes C1 is used for email addresses, and sometimes, like in this example, for the names of transport rules.

Alternatives

The alternatives to using the Get-MailTrafficSummaryReport cmdlet include:

• Export message trace information to an external repository like Splunk. Organizations do this to retain data for longer than the 90 days supported by Microsoft and to gain more sophisticated querying capabilities. Here’s an example of a script written to extract large quantities of message trace data.
• Use the Microsoft Graph reports API to work with the same data as appears in the usage reports in the Microsoft 365 admin center. The data is limited to a 90-day horizon and the email usage data is nowhere near as comprehensive as message trace data and doesn’t include access to data about spam, malware, and rule-based activity. The major advantage of this approach is the ability to build a picture of overall user activity across multiple Microsoft 365 workloads.

My bet is that Microsoft’s focus will be on Graph-based usage reporting. It’s likely they will try to deprecate the Get-MailTrafficSummaryReport cmdlet in the future. With that in mind, I don’t plan to spend much time on this cmdlet going forward as I don’t anticipate any change in coverage or functionality. But if Get-MailTrafficSummaryReport does a job for you, continue using it until the future direction becomes apparent.

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.

Monitor Who’s Sending Email Outside the Organization

A question about message tracing arose last week in the Facebook Office 365 Technical Discussions group:

“I have a request from management to report for a set of users where I need to report how many emails they send outside of the company, the recipients and date and time.”

My initial response was that the management involved must be devotees of mid-20^th century time and motion methodologies. Further reflection brought me to the point where the request might be justifiable by some form of investigation into suspected wrongdoing. Hopefully, management has legal and HR advice about reporting user activity in this way. Assuming they do, it’s an interesting technical problem to solve.

Message Tracing Provides the Data

Exchange Online message tracing is core to the solution. You can track the path of messages through the Exchange Online transport system using GUIs in the Exchange admin center or Microsoft 365 Defender portal. Message tracing data is also available through PowerShell using the Get-MessageTrace cmdlet, which is what we use here.

Exchange Online retains message trace data for up to 90 days. However, only the last ten days are available online. To track messages sent to external recipients, we can interrogate the message tracing data and report what we find. This isn’t the only useful purpose for message tracing. For instance, you can understand how active distribution lists are by tracking their email activity.

Identify Target Mailboxes

First, we need to identify the set of target mailboxes to monitor. The simplest method is to run the Get-ExoMailbox cmdlet to find a set of mailboxes belonging to a certain department or matching another attribute. For example, this command returns all the mailboxes with the Office property set to Boston:

[array]$Mbx = Get-EXOMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter {Office -eq 'Boston'} -Properties Office

Given the nature of investigations, you might not find a suitable property to query against. In this situation, using one of the 15 custom attributes available for mailboxes is a good way to mark the target mailboxes.

I decided to use a different approach by creating a distribution group containing the target mailboxes. The account assigned ownership of the group will receive the reports. To avoid users seeing the new group, I hid it from address lists and gave it a difficult to guess email address:

New-DistributionGroup -Name "Monitored Users" -Alias Monitored.Users -DisplayName "Users External Email Monotoring" -IgnoreNamingPolicy
Set-DistributionGroup -Identity Monitored.Users -HiddenFromAddressListsEnabled $True -ManagedBy Compliance.Administrator -PrimarySmtpAddress Monitored.Users.Investigation101@office365itpros.com
Add-DistributionGroupMember -Identity Monitored.Users -Member Kim.Akers
Add-DistributionGroupMember -Identity Monitored.Users -Member Terry.Hegarty
Add-DistributionGroupMember -Identity Monitored.Users -Member Chris.Bishop
Add-DistributionGroupMember -Identity Monitored.Users -Member James.Ryan

Message Tracing in PowerShell

With a set of target mailboxes, we can go ahead and do some message tracing to find details of their external email. Here’s the loop I used to run a message trace for each mailbox and extract records for external email by checking the recipient address. A PowerShell list stores details of the messages for use later.

Write-Host ("Checking external email for {0} mailboxes" -f $Users.count)
$Report = [System.Collections.Generic.List[Object]]::new() 
ForEach ($User in $Users) {
   Write-Host ("Checking messages sent by {0}" -f $User.DisplayName)
   # Get message information for the last ten days and filter so that we end up with just external addresses
   [string]$SenderAddress = $User.PrimarySmtpAddress
   [array]$Messages = Get-MessageTrace -StartDate $StartDate -EndDate $EndDate -SenderAddress $SenderAddress -Status Delivered | Where-Object {$_.RecipientAddress -notlike "*@Office365itpros*"}
   ForEach ($M in $Messages) {
     $ReportLine = [PSCustomObject][Ordered]@{
          Date      = Get-Date($M.Received) -format g 
          User      = $M.SenderAddress
          Recipient = $M.RecipientAddress
          Subject   = $M.Subject
          MessageId = $M.MessageId }
     $Report.Add($ReportLine)
   } #End Foreach messages
} # End ForEach Users

Notifying Management by Email

The request didn’t specifically say how management should receive the report of external email activity. It’s easy to create output from the data and provide it as a CSV file or HTML document. For the purposes of this exercise (and because we have some suitable code), we’ll email the report using cmdlet from the Microsoft Graph PowerShell SDK.

Management say that they want to know about external recipients and message timestamps. I assume they also want to know who sends messages and the message subjects, so we’ll take that information extracted from the message traces and format it as a HTML bodypart.

The next steps are to select the mailbox to send the message, its recipient, and a subject. I use the logged-in user to send the message to the person who manages the distribution list. Alternatively, you could hardcode these assignments. Here’s what I did:

$MsgFrom = $O365Cred.UserName
[string]$EmailRecipient = (Get-DistributionGroup -Identity Monitored.Users).ManagedBy
[string]$EmailRecipientAddress = (Get-EXOMailbox -Identity $EmailRecipient).PrimarySmtpAddress
$MsgSubject = "User External Email Report"

Finally, we build the message body using the HTML bodypart, create a draft message with the New-MgUserMessage cmdlet, and send it with Send-MgUserMessage. Here’s the relevant code:

# Construct the message body
     $MessageBody = @{
         content = "$($Body)"
         ContentType = 'html'
     }
# Create a draft message in the signed-in user's mailbox
$NewMessage = New-MgUserMessage -UserId $MsgFrom -Body $MessageBody -ToRecipients $EmailToRecipient -Subject $MsgSubject
# Send the message
Send-MgUserMessage -UserId $MsgFrom -MessageId $NewMessage.Id

Figure 1 shows what the message received by the manager looks like. The HTML formatting is basic and could be made much prettier if that need exists.

Making Things Work

Although I don’t agree with the idea of monitoring user email activity in any way, this is an interesting example of using the message tracing information available to all Exchange Online tenants to deliver a reasonable response to a request. Combined with some PowerShell snippets from other scripts, it’s possible to create a fully working solution in a few hours. To get started, you can download my code from GitHub.

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.

No Point in Having User Mailboxes That Aren’t in Active Use

I don’t like to post repeats of articles, but sometimes it’s necessary. In this case, a reader had difficulty running some PowerShell code in a Petri.com article I wrote in 2019 to discuss how to find unused Exchange Online mailboxes using diagnostic information. Often the issue is something small (like making sure that you use the correct webhook URI), but I don’t write for Petri any longer and no longer have access to the article, so it seemed like a good idea to revisit the topic here.

Often, the second attempt at writing code takes a different approach to the first. You know what needs to be done and might approach the issue in a different way. New PowerShell cmdlets or Microsoft Graph APIs might be available. Or the original code might simply be not very good, even if it’s written to demonstrate a principal rather than be a complete solution.

Microsoft increased prices for Office 365 and Microsoft 365 licenses on March 1, 2022. The extra $3 or so per month might not seem a lot, but it’s always a good thing to avoid paying license fees for unused mailboxes. Of course, email activity is only one aspect of how someone might use Office 365, and usually people don’t pay separately for Exchange Online because Microsoft bundles it in many SKUs like Office 365 E3. Over the last few years, many Office 365 users have reduced the level of email they send and receive by moving communications to Teams, which means that gathering and analyzing activity data from multiple workloads is a better way to conclude if an account is active or not.

Analyzing Sources of Mailbox Information

The original idea was to use diagnostic information extracted from user mailboxes to understand if mailboxes are in active use. I’m only concerned about user mailboxes because they’re the ones which need licenses. Shared mailboxes don’t need licenses unless they are larger than 50 GB or have an archive.

Three sources of information give some insight into the activity level of mailboxes:

• The Export-MailboxDiagnosticLogs extracts mailbox diagnostic information (changed subtly over the years). After converting the information to XML format, it’s easy to extract and use the various pieces of data which might tell you about the use of a mailbox.
• The Get-ExoMailboxStatistics cmdlet provides some basic statistics about each mailbox because unused mailboxes are usually small and hold relatively few items. Thus, if we see a mailbox that hasn’t been logged into for a while and has less than a couple of hundred items, it’s an indication that that this is an unused mailbox.
• The last logon date for a mailbox is a piece of information that’s long been of suspect quality, largely because so many background processes connect to mailboxes to perform housekeeping tasks like retention processing. Mailbox diagnostics include a last logon time property, so the script reports that. As a backup, the script also calls the Get-MgAuditLogSignIn cmdlet to fetch the last signin audit record from Azure AD (which can only go back 30 days). The last signin event might be associated with Exchange Online, but it could also come from another workload. It’s just another check to help detect unused mailboxes. Access to the signin logs requires an Azure AD Premium P1 license. You can cut this code from the script if you don’t have the necessary license.

As usual for demo scripts, we pipe the output to Out-GridView to view the results sorted by the number of days since the last active date reported by mailbox diagnostics (Figure 1). The most unused Exchange Online mailboxes appear at the top.

The new script also includes the code from this post to post notifications about the top 25 potentially unused mailboxes to a Teams channel through the incoming webhook connector (Figure 2). I explored this topic previously in this post and have now refined and integrated the code in a single script.

The method used to create the body of the message to post to Teams is different from the approach taken in this article. In the first instance, the code deals with a single item. In this script, the body comprises up to 25 different items. In both cases, you end up with a HTML body of JSON data, which is what Teams expects through the incoming webhook connector.

The full script is available on GitHub. Before you run it, be sure to update the code with the webhook URI for the target teams channel.

Doing Something About the Unused Mailboxes

If some suspiciously unused Exchange Online mailboxes come to light, the next step is to figure out what to do with them. You can:

• Leave the mailbox alone and find out why its owner is not using the mailbox. Obviously, you’ll need to contact the mailbox owner using something other than email.
• Convert the mailbox to be a shared mailbox to remove the need to license the mailbox. However, if the mailbox owner uses other workloads, they might have a license like Office 365 E3 which includes Exchange Online, so converting the mailbox to be a shared mailbox won’t have much impact.
• Put the mailbox on litigation hold and then delete the user account. This makes the mailbox inactive and releases any licenses assigned to the account. Exchange Online keeps the mailbox in this state until the hold lapses. This is a bad approach to take if the account is active in other Microsoft 365 workloads, which is why the data analyzed includes the last sign-in date from Azure AD. This article explains how to use the Microsoft Graph usage reports API to report per-user data from multiple workloads.
• Relax and do not worry too much. Maybe this isn’t the best way to chase down licensing costs.

Perhaps chasing and closing down unused Exchange Online mailboxes is a pipe dream that isn’t worth the effort. Still, it’s nice to know how to approach the problem.

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

Update Exchange Online Organization Configuration by April 17

Last August, I reported that Microsoft intended to introduce plus addressing by default for Exchange Online for all tenants. Exchange Online plus addressing is enabled for new tenants already. At the time, Microsoft’s target date to switch on plus addressing for all tenants was January 2022, but like many other Microsoft 365 features, the pace of development to create tenant-ready features can slow. This is especially true when customers affected by the change make their feelings known to Microsoft.

When released in preview in September 2020, tenants could opt-in to enable plus addressing early by updating the organization configuration. Microsoft is now making another setting available to allow tenants to opt-out of Exchange Online plus addressing before Microsoft starts to roll-out the change to make plus addressing available by default in mid-April 2022. The roll-out is scheduled to complete by mid-May.

Why You Wouldn’t Want to Use Plus Addressing

The usual reason why organizations don’t want to use Exchange Online plus addressing is that they’ve configured a bunch of mail-enabled objects with proxy addresses which contain the plus character. This was the only way that Exchange Online supported plus addressing in the past and it might be the case that organizations have deployed these addresses to support business processes.

The new method introduced for Exchange Online plus addressing removes the need to create and assign proxy addresses (which can only be done by administrators). Instead, end users can create their own plus addresses using clients which support the feature, like OWA and Outlook desktop. So far, I can’t see how to create a plus address using Outlook mobile. It’s also unlikely that non-Microsoft clients will support the feature in the short term.

Opt-Out for Plus Addressing

Announced in message center notification MC343788 on March 16, Microsoft says that if an organization wants to opt-out of plus addressing, they can do so by logging into a PowerShell session with the Exchange Online management module and running the command:

Set-OrganizationConfig -DisablePlusAddressInRecipients $True

Checking my tenant, I discovered that DisablePlusAddressInRecipients is set to False, which implies that Microsoft has already populated the setting to tenants. If you want to opt-out, you need to update it to True before April 17. In other words, a 30-day countdown clock has started for organizations to decide if they wish to use Exchange Online plus addressing before Microsoft switches on the feature.

When Microsoft deploys the plus addressing update to tenants, it will remove the old AllowPlusAddressInRecipients organization setting used to control the preview and respect the DisablePlusAddressInRecipients setting. If you find at that point that some proxy addresses exist which contain the plus character, you can disable plus addressing by updating the setting to True.

The Mail Flow settings section of the Exchange admin center (EAC) already includes a setting to enable plus addressing for an organization (Figure 1). Turning off plus addressing in the EAC doesn’t affect the DisablePlusAddressInRecipients setting. No doubt it will in the future. At least, that would be the sensible option.

Check for Proxy Addresses

My January article includes some PowerShell code to check for the existence of proxy addresses with plus characters. You can use the script to help decide if you need to set DisablePlusAddressInRecipients to True. Otherwise, stay calm and wait for the deployment of Exchange Online plus addressing to start!

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.

Dynamic Distribution Lists to Dynamic Microsoft 365 Groups

Earlier this week, I described how to create a Microsoft 365 group and team from an Exchange Online dynamic distribution list. The code creates a group with static membership, but the input dynamic distribution list has its membership computed by Exchange Online using a recipient filter (aka a membership rule). Why can’t we take the filter used by the dynamic distribution list and apply it to create a dynamic Microsoft 365 group, which in turn becomes a team with dynamic membership. Well, as it turns out, it’s not quite as simple as taking a filter from one Microsoft 365 workload and using it in another.

Translating Recipient Filters for Dynamic Microsoft 365 Groups

Conceptually, it is possible to convert a dynamic distribution list to a be the membership rule for a dynamic Azure AD group. Two challenges exist: filter syntax and filter properties.

The query stored in a dynamic distribution list looks like this:

((((((Title -eq 'Architect') -or (Title -eq 'Senior Architect'))) -or (((Title -eq 'Principal Architect') -and (ExchangeUserAccountControl -ne 'AccountDisabled'))))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')))

We know this is a custom recipient filter created using PowerShell because the properties it uses are not covered by the precanned filters created using EAC. The custom filter comes first followed by a bunch of exclusions inserted by Exchange to make sure that system mailboxes are not in the returned set. Exchange adds these exclusions automatically when it saves the recipient filter for a dynamic distribution list.

It’s technically possible to take a recipient filter from a dynamic distribution list and parse it to extract the custom part using Regex expressions. By using a function to remove special characters, I was able to process the recipient filter shown above like this:

$Filter = (Get-DynamicDistributionGroup -Identity "System Architects").RecipientFilter
$i = $Filter.IndexOf("-and (ExchangeUser")
$f = $Filter.Substring(0,$i)
$ExoFilter = Remove-StringSpecialCharacter -String $f -SpecialCharacterToKeep '-', " "

The output is:

Title -eq Architect -or Title -eq Senior Architect -or Title -eq Principal Architect

However, a complicating factor is that Exchange has changed the format of the exclusions it inserts over time. This means that you can never be sure how the recipient filter is formatted, and my code didn’t work when tested against several other dynamic distribution lists in my tenant, some of which go back to 2014.

In any case, the output I generated isn’t a valid Azure AD filter, and some additional work is needed to make it work with a dynamic Azure AD group (team). Briefly:

• Title is the name of the Exchange property. It is JobTitle in Azure AD. Also, user properties are prefixed with “User,” meaning that you end up with User.JobTitle.
• The -eq and -or operators in Exchange lose the leading hyphen in Azure AD.

Different Filterable Properties

A more fundamental issue is that while Exchange supports many mail-enabled properties for custom recipient filters in dynamic distribution lists, the set of filterable properties don’t match the set available for Azure AD. You might be able to convert some queries, but you won’t be able to convert others. The difference is accounted for by the fact that Exchange queries against its own directory, which stores details of mail-enabled objects, while Azure AD queries its directory. The two directories have different schemas.

Once I realized the extent of the incompatibility between the two sets of properties, I stopped trying to figure out how an automatic conversion could be done. Too much time would be needed to figure out the permutations and combinations involved in formatting membership rules. And given the number of times a conversion might be necessary, the easiest solution is to let human administrators generate the membership rules.

Previewing Azure AD Filters

The GUI in the Azure AD admin center to deal with dynamic groups include a rules editor. You can paste the outline of a membership rule taken from an Exchange dynamic distribution list and modify it there. The Azure AD admin center also includes a nifty preview feature to validate that a membership rule works. After making whatever changes are necessary to create a valid rule for Azure AD, you can test the rule by nominating one or more users that you know should match the membership rule. Click the validate button and Azure AD will tell you if the directory can find the users you selected using the rule (Figure 1).

Exchange Online doesn’t have a similar way to validate the membership of a dynamic distribution list. Maybe that’s why Microsoft considers dynamic Azure AD groups to be a premium feature and charges accordingly.

Creating a Dynamic Azure AD Group with PowerShell

For the record, you can create a dynamic Azure AD group with PowerShell. In this instance, I use the New-MgGroup cmdlet from the Microsoft Graph PowerShell SDK (the New-AzureADMSGroup cmdlet from the preview version of the Azure AD module will work too). The important point is that the group has dynamic membership rather than static and has a rule to control the membership:

$Group = New-MgGroup -DisplayName "System Architects (Dynamic x2)" -Description "People with an architect job title" -MailEnabled:$True -SecurityEnabled:$True -MailNickName "System.Architects.Dynamic2" -GroupTypes "DynamicMembership", "Unified" -MembershipRule "(User.JobTitle -eq ""Architect"" or  User.JobTitle eq ""Senior Architect

After creating the dynamic Azure AD group, you can team-enable it with the New-Team cmdlet by passing the identifier of the newly created group.

New-Team -GroupId $Group.Id

Incompatible schemas, properties, and syntax might stop the automatic conversion of membership rules, but you can at least get the job done with a little manual effort.

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.

Creating Teams from Exchange Online DDLs

After writing about the recent revamp of Exchange Online dynamic distribution lists, I was asked if it was possible to create a team from the membership of a dynamic distribution list. The answer is that the steps are straightforward to create a static Microsoft 365 group. Things get more complicated if you contemplate using a dynamic Microsoft 365 group.

Available in both Exchange Online and Exchange Server, dynamic distribution lists are very powerful. That is, if the organization directory is well-maintained with details about people, job titles, department names, offices, country, and so on. The membership of dynamic distribution lists can include any kind of mail-enabled recipient, including other groups. And that’s the first challenge to face: the Microsoft 365 groups used by Teams support a flat membership (no nested groups) composed solely of accounts belonging to the host organization (members and guests): only user mailboxes can migrate to become members of a target Microsoft 365 group.

The second challenge comes into play if you decide that the target Microsoft 365 group should have dynamic membership. The issue here is that dynamic distribution lists use filters executed against Exchange Online’s directory while dynamic Microsoft 365 groups use filters based on Azure AD. Different filters, different syntax, and different properties. More on this later.

Converting a Dynamic Distribution List to a Team with Static Membership

Starting with the simple issue of finding the members of a dynamic distribution list and using this information to create a new Microsoft 365 group, the steps are straightforward:

• Identify the source dynamic distribution list.
• Get the members of the dynamic distribution list and throw away any that can’t be members of a Microsoft 365 group.
• Check that the owner of the source dynamic distribution list is a valid mailbox.
• Create the new Microsoft 365 group using properties like name and description inherited from the source dynamic distribution group. The person who manages the dynamic distribution list becomes the owner of the Microsoft 365 group.
• Add the members to the new Microsoft 365 group to the membership.
• Team-enabled the new Microsoft 365 group.

The script I created is available in GitHub. Normal caveats apply: the code works but it doesn’t have much error checking. It’s there to prove a principle, not be an off-the-shelf solution.

Finding the Source

Multiple ways exist to identify a source dynamic distribution list. This example prompts the user to select one. The code could become a lot more complex to allow the user to make a mistake and select from a numbered list, and so on, but for the purpose of the example all we want is the object identifier for a valid dynamic distribution list:

$InputDDL = Read-Host "Enter the name of the Dynamic Distribution List to convert to a Microsoft 365 Group"
[array]$SourceDDL = Get-DynamicDistributionGroup -Identity $InputDDL -ErrorAction SilentlyContinue

If (!($SourceDDL)) {Write-Host ("Sorry! We can't find the {0} dynamic distribution list" -f $InputDDL); break}
If ($SourceDDL.Count -gt 1) {
   CLS
   Write-Host "We found multiple matching dynamic distribution lists"
   Write-Host "-----------------------------------------------------"
   Write-Host " "
   $SourceDDL | Format-Table DisplayName, Alias, PrimarySMTPAddress
   Write-Host " "
   Write-Host "Please try again..."; break }

[string]$SourceDDLId = $SourceDDL.ExternalDirectoryObjectId

Two methods exist to return the membership of the dynamic distribution list:

• Run Get-Recipient using the filter stored in the dynamic distribution list.
• Use the new Get-DynamicDistributionGroupMember cmdlet.

The first method resolves against the Exchange directory and its results are up to date. The second fetches membership data as at the last time Exchange processed the list (more information here). After retrieving the membership using the chosen method, we apply a filter to extract mailboxes.

# Now that we have a source DDL, let's get its membership
[array]$SourceMembers = Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity $SourceDDLId).RecipientFilter
# could also be 
# [array]$SourceMembers = Get-DynamicDistributionGroupMember -Identity $SourceDDL.Id
# Throw away anything but user mailboxes because that's all a Microsoft 365 group supports
[array]$ValidMembers = $SourceMembers | ? {$_.RecipientTypeDetails -eq "UserMailbox"}

The next piece of code establishes the owner of the new group. Microsoft 365 groups must have an owner, so if the ManagedBy property of the source list results in an invalid result (for instance, it’s empty), we need to assign ownership to a default account. One way of doing this is to find the set of Exchange administrators for the organization and select one of them, which is done here using the Get-MgDirectoryRoleMember cmdlet from the Microsoft Graph PowerShell SDK and filtering out any service principals assigned the Exchange administrator role. You could simplify the script by hardcoding a default group member.

# We've got to assign an owner to the new Microsoft 365 group, so we need to have a default in case the source DDL doesn't have an owner
# Find the set of accounts that are Exchange admins (you can also use Get-AzureADDirectoryRoleMember here)
[array]$ExoAdmins = Get-MgDirectoryRoleMember -DirectoryRoleId "53add08e-5b0c-4276-a582-9ce02fb6c947" | Select Id, AdditionalProperties 
# Throw away any service principals which might have the Exchange Admin role
$ExoAdmins = $ExoAdmins | ? {$_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.user'} | Select -ExpandProperty Id
# Select the first and use them as the default owner
$ExoDefaultAdmin = Get-MgUser -UserId $ExoAdmins[0] | Select -ExpandProperty UserPrincipalName
# Check that the group owner is a mailbox
$GroupOwner = Get-ExoMailbox -Identity $SourceDDL.Managedby -ErrorAction SilentlyContinue
# If it's null or something weird like a shared mailbox, use the default owner
If (($GroupOwner -eq $Null) -or ($GroupOwner.RecipientTypeDetails -ne "UserMailbox")) {
   $GroupOwner = $ExoDefaultAdmin }
Else {
   $GroupOwner = $GroupOwner.PrimarySmtpAddress
  }

# Populate other group properties
$AliasDDL = $SourceDDL.Alias + "M365"
$GroupDisplayName = $SourceDDL.DisplayName + " (Group)"

Creating the New Group and Team

With everything ready, we can go ahead and create the new Microsoft 365 Group, add the members, and team-enable the group. All the members can be added with a single Add-UnifiedGroupLinks command because we have an array of email addresses. Exchange processes each item in the array and adds it as a member.

# Create the new Microsoft 365 Group
Write-Host "Creating the new Microsoft 365 group..."
$Description = "Created from the " + $SourceDDL.DisplayName + " dynamic distribution list on " + (Get-Date -Format g)
$NewGroup = New-UnifiedGroup -DisplayName $GroupDisplayName –AccessType Private -Alias $AliasDDL -RequireSenderAuthenticationEnabled $True -Owner $SourceDDL.ManagedBy -AutoSubscribeNewMembers -Notes $Description
# Add the members to the group
Write-Host "Adding members from the dynamic distribution list to the Microsoft 365 group..."
Add-UnifiedGroupLinks -Identity $NewGroup.ExternalDirectoryObjectId -LinkType Members -Links $ValidMembers.PrimarySmtpAddress
Write-Host "Enabing Microsoft Teams for the Microsoft 365 group..."
New-Team -Group $NewGroup.ExternalDirectoryObjectId

The code doesn’t add a sensitivity label, so if you use these to apply container settings to groups and teams, you should add the label when creating the new group by passing the identifier for the selected label in the SensitivityLabel parameter.

That’s it. We have a new team built from the membership of a dynamic distribution list. The code is straightforward and works without a hitch, but if we throw dynamic membership for the Microsoft 365 group/team into the equation, things become much more complex. I’ll cover that subject in another post.

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

Bringing RCA Back to Life

For many years, the Microsoft Remote Connectivity Analyzer (MRCA) was in the doldrums. No Microsoft engineering group wanted to take responsibility for its development and maintenance, and issues like expiring certificates occurred all the time. RCA was not in good shape and not much happened between October 2015 and January 2020.

The history of RCA is that it started in 2009 as the Exchange Remote Connectivity Analyzer (ExRCA), a utility program to help Microsoft support and Exchange administrators debug connectivity problems. At the time, Exchange server handled protocols like Exchange ActiveSync (mobile), Exchange Web Services, Outlook Anywhere (RPC over HTTP), and SMTP, with tests later appearing for POP3 and IMAP4. ExRCA was very popular and boasted its own Twitter account and YouTube video (a real trip into the past).

In 2011, Microsoft updated ExRCA to support Office 365, but its focus remained firmly fixed on Exchange (the URL at the time was testexchangeconnectivity.com). However, Microsoft dropped some hints that they wanted to incorporate connectivity tests for other applications than Exchange. Those plans and other ideas for enhancements foundered due to a lack of investment and engineering availability.

Debugging Teams and Exchange Hybrid

Despite the five year hiatus, the good news is that MRCA is better than ever before. It has a new lease of life and backing within Microsoft that has allowed its developers to create new tests to help Microsoft 365 tenant administrators figure out when connectivity goes wrong. The latest tests, revealed in a Microsoft technical community post of March 3, analyze the connections between Teams and an Exchange hybrid environment.

Teams works best when it interacts with an Exchange Online mailbox. However, as we know, many on-premises Exchange servers still host mailboxes, and given the success of Teams, it’s likely that millions of Teams users have on-premises mailboxes. Microsoft documents what how Teams and Exchange interact and issues that occur between Teams and Exchange Server. Over the years, connectivity has become smoother as customers upgraded to Exchange 2016 CU3 or later (always upgrade to the latest cumulative update to avoid problems like last year’s Hafnium debacle).

The latest MRCA diagnostic test for Teams-Exchange connectivity (Figure 1) checks the common problems known to exist and validates that the Exchange hybrid configuration is correct for Teams users.

Running the test is simple. All that’s needed is the user principal name of a Teams user. You are asked to sign into the account, and thereafter the diagnostics exercise different aspects of connectivity to identify any lurking issues (Figure 2).

The REST Reference

Everything looks good. The only nagging doubt I had is the reference to checking the EWS and REST endpoints for Exchange Server. Twenty-seven minutes after announcing the new MRCA tests for Teams, Microsoft said that they plan to remove support for the REST API for on-premises mailboxes in March 2023. Microsoft introduced REST API access to mailboxes as a preview feature in Exchange 2016 CU3. The API never progressed from its preview status, which means that it was always liable for discontinuation. When the axe descends next year, Exchange will block requests made via the REST API. EWS continues and remains the approved method for programmatic access to Exchange server mailboxes.

The MRCA developers point to the need to check the REST endpoint, so does this imply that the Teams hybrid connection to Exchange Server uses the REST API? I guess all will become clear in time and, if necessary, the MRCA developers will make the necessary adjustment as they continue to develop this valuable and worthwhile utility.

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.

A Complex Software Engineering Problem

First announced in May 2020, Microsoft’s efforts to deliver Outlook roaming signatures in the click-to-run version of Outlook desktop (part of Microsoft 365 apps for enterprise) have stalled several times since. The latest information in Microsoft 365 roadmap item 60371 points to preview in September 2022 and general availability in October 2022. Given Microsoft’s record with this feature so far, few would bet that they will achieve this date.

As I explained in my original May 2020 post, the current implementation of Outlook signatures in the desktop client makes them more difficult to manipulate than the OWA equivalent, which require a simple update using the Set-MailboxMessageConfiguration cmdlet.

You’d hope that Microsoft has come up with a simpler and more elegant implementation for Outlook roaming signatures, but that’s no reason why it is taking Microsoft so long to deliver a solution to a problem that many other companies have solved, especially with their access to internal structures of Exchange Online and Outlook. According to Microsoft 365 message center notification MC305463 (December 15, now unavailable in the message center), the delay is due to the need for “further stabilization.”

Cynics might note that Microsoft finishes its FY22 fiscal year on June 30, and engineering management will be keen to ship features before that milestone. We may yet see at least a public preview of Outlook roaming signatures soon.

Signature Settings in Mailboxes

The roadmap item promises that Outlook will store signature information in the cloud, likely meaning that Outlook will retrieve signatures from a hidden folder in the Non-IPM section of Exchange Online mailboxes. Users who choose not to store signatures in the cloud will continue using the system registry to store signatures. Outlook 2016 and Outlook 2019 perpetual license clients will also use the system registry.

There’s no indication that Microsoft will bring roaming signatures to Exchange on-premises servers. Then again, Microsoft has gone dumb about the future of Exchange Server recently, with no news about when the successor to Exchange 2019 will appear.

The ISV Approach

Although customers are exasperated at the lack of Microsoft’s progress in delivering roaming signatures, I’m sure that ISVs like Code Two Software, Exclaimer, and Crossware are happy to have had two extra years to hone their signature management software to compete with Outlook roaming signatures. In 2020, Microsoft said that third-party add-ins will have to disable the Outlook feature to continue to work. They also committed to deliver an API to allow add-ins to work with roaming signatures. No details of the API are yet available, but given Microsoft’s focus on the Graph, it’s likely it will be a Graph API. Whether the API appears at the same time as roaming signatures or afterwards is another question.

On another front, signature management ISVs are leveraging the Outlook Signatures add-in API to integrate their products with Outlook desktop. First announced at Ignite 2020 and subsequently followed by a set of product releases from ISVs, the Outlook API is different to the one promised by the developers of roaming signatures and leverages the Outlook add-in model developed by the Office extensibility team. It’s a classic example of two solutions for the same problem coming from different Microsoft development groups.

I don’t think that Microsoft’s implementation of roaming signatures will materially affect ISV signature management products. After many years of development, these products are very sophisticated and tailored to meet the needs of enterprises who want common signatures used by all employees. Those who want an out of the box solution can have it today without waiting for roaming signatures by implementing signatures through transport rules. This approach works, it’s free, but it’s crude in comparison to what’s available in ISV products.

Confusing Outlook Signatures

As things stand, multiple different signature mechanisms exist for Outlook clients (OWA, Outlook for Windows, Outlook for Mac, Outlook mobile). This situation is due to the historical differences in client architectures and is confusing and cumbersome. Perhaps roaming signatures will be the first step on the road to a common signature used across all clients. Delivering such a capability might justify some of the two-year delay, but don’t hold your breath.

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

Handling Encryption, Signing, and Permission Controlled Email

A recent question in the Microsoft Technical Community about Data Loss Prevention (DLP) policies covered the difference between encrypted, permission controlled, and signed messages. In this instance, the DLP policy rule included an exception to allow a message containing some sensitive data to pass if encrypted. However, the exception wasn’t triggered for messages protected by Office 365 message encryption (OME) or sensitivity labels. The documentation covering email exceptions didn’t add much insight.

Email encryption has been around for years. S/MIME and PGP are two examples of commonly used email encryption technologies. First supported by Exchange Server 2003, S/MIME support for message encryption and signing is still available in Exchange Online, with the caveat that tenants must take charge of the details of deploying and managing S/MIME to users.

Microsoft acknowledges that its OME and sensitivity labels technologies are direct competitors to S/MIME. These products are based on Azure Rights Management rather than public key technology. For Office 365 tenants, Microsoft protection is easier to deploy and manage, and it can encrypt email sent to other Microsoft 365 tenants and external domains without the need for the receiving organizations to take any action.

It’s even possible to configure sensitivity labels to use S/MIME instead of rights management protection. This is a custom configuration for sensitivity labels that requires the unified labeling client (and Azure Information Protection licenses). I have never used this facility and do not know how well it works in practice.

Email Exceptions for DLP

All of which brings me to the set of email message type exceptions available for a DLP rule (Figure 1). When Microsoft started to develop service-wide Data Loss Prevention capabilities, the set of actions, exceptions, and conditions available for Microsoft 365 DLP policies was more limited for email than Exchange Online DLP. Over time, Microsoft 365 DLP processing capabilities became better and better. Building out the exceptions available in rule processing is an example of where improvements have occurred. A year or so ago, tenants could move their Data Loss Prevention focus away from Exchange Online transport rules (ETRs) to Microsoft 365 DLP without losing functionality.

Apart from wanting to maintain the same DLP processing for both on-premises and cloud email workloads, I don’t know of any obvious reason to continue using ETRs within Microsoft 365. That being said, some organizations have enormously complex DLP rules which require substantial effort to move to Microsoft 365 DLP policies. In some cases, these tenants will stay using ETRs until they’re forced to move.

What we learn from Figure 1 is that the available message types for DLP exceptions are:

• Signed messages (digital signature applied by S/MIME).
• Encrypted messages (S/MIME). See this Exchange 2010 documentation.
• Permission controlled (rights management).

Permission controlled is an odd term. I can understand why it’s used because rights management is all about granting permissions to users or groups to interact with content, but the term doesn’t tell the administrator that it means rights management. But it does, and despite the fact that rights management can encrypt email, using Encrypted as an exception won’t work for messages protected by OME or sensitivity labels.

Permission Controlled the Way to Go

For most organizations, the Signed and Encrypted message types are now firmly in the legacy category, and they’ll never need to deploy Data Loss Prevention rules to deal with these types. The majority will use OME and/or sensitivity labels and should therefore use the permission-controlled message type in DLP policy rule exceptions. I never knew this detail until now. Discovering new things about how Microsoft 365 works daily is one of the unique joys (or pains) of coping with the cloud. At least, I think it does…

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.

Privacy and Protection Might Not be Enough

MVP Ingo Gegenwarth’s post about Outlook and private items is a good example of the problems which arise when user assumptions running into software limitations. The assumption is that if you mark an item as private, only you can see its contents. The limitation is that it depends on clients containing code to respect private items. Some do, and some don’t, much to the chagrin of users when they find out.

Delegate Access to Protected Email

Similar confusion exists around protected email which arrives in a user mailbox and is read by a delegate. Email protected by a sensitivity label uses rights management to know what a user can do with the content. If they don’t have the right to view the encrypted content, the mail client shouldn’t open the message. But if someone has delegate access to a user or shared mailbox, they might be able to read protected messages. It all depends on the client used and the rights assigned in the sensitivity label.

For instance, here’s an example where a protected message arrives in a mailbox. The delegate (full mailbox access) can read the protected message with OWA (left), but not with Outlook desktop (right). They can also read the message with Outlook mobile if they add their delegate account there.

Change Coming for Some Outlook Clients

In their FAQ for protected email, Microsoft says:

“Is delegated access supported with opening encrypted messages? Even if a delegate has full access to another user’s mailbox?

Delegated access of encrypted mail is supported in Outlook on the web, Outlook for Mac, Outlook for iOS, and Outlook for Android. Outlook for Windows does not support delegated access.”

A change described in Microsoft 365 roadmap item 88888 appears as if it will help. The item says:

“Outlook will provide consistent access control on protected emails for delegates and shared mailbox members. For delegates or shared mailbox members, when they have full access of the owner’s mailbox but are not allowed to read encrypted email, Outlook will have a new setting to block the owner’s protected email access which covers ad-hoc encrypted email as well as email with protected MIP sensitivity labels.”

According to the roadmap, we will see this change in April 2022. However, it only applies to OWA, Mac, iOS, and Android. Outlook for Windows remains an outlier. And that’s the problem because Outlook for Windows is often the client of choice for administrative assistants who process email on behalf of others.

Protecting Confidentiality

Is there anything that can be done in the situation where the organization uses sensitivity labels to protect confidential email and documents and want to be sure that delegates cannot access this material? Well, you could remove OWA and Outlook Mobile access from delegate accounts to force them to use Outlook desktop, but that’s probably not realistic.

Instead, an old technique from on-premises Exchange might be useful. For executives who need the assurance that delegates cannot access protected email, you could create two accounts with mailboxes. Let’s take the example of the CEO. They would have:

• A primary mailbox accessed by the delegate to manage inbound email and the calendar. The mailbox appears in the GAL and is accessible to anyone in the organization (or maybe not, as the case demands).
• A hidden mailbox which only the owner can access. This mailbox is not listed in the GAL and is limited so that only certain people can send email to it. This mailbox is used for protected or other confidential email, so the rights assigned in sensitivity labels grant access to the hidden mailbox instead of the primary mailbox.

A certain amount of configuration to make sure that the two accounts work as planned. However, if protected email is sent to the hidden mailbox and only the owner of that mailbox accesses the email, there’s no chance that the delegate can see confidential material.

Yes, this is a pain. Delegate access to protected email should work better with Outlook for Windows. Let’s hope that Microsoft moves on this point soon. Perhaps it’ll be an example of their One Outlook strategy of bringing OWA features to Outlook desktop.