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.

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.

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.

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.

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.

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.

Tasks and Exchange Online

Office 365 Notification MC229058 (8 December 2020) had the headline “Planner tasks storage location update.” In fact, it meant nothing of the sort. Planner continues to use Azure to store its plans and tasks while taking the same route as Teams and Yammer by storing copies of tasks (compliance records) in Exchange Online mailboxes to make those items available for eDiscovery. Microsoft’s original intention was to push the change out in early 2021. Things didn’t quite turn out as they thought, but Planner data is now in Exchange Online mailboxes. In my case, it seemed like a background process populated data for preexisting tasks on 14 December 2021. This closes a gap in Microsoft 365 compliance which existed since Microsoft launched Planner in 2016.

The copies of Planner tasks stored in Exchange Online are automatically indexed and become available to compliance functionality like eDiscovery (core and advanced), communication compliance policies, and retention policies. Microsoft hasn’t said yet when Planner data will be picked up by other compliance features but this can be expected over time.

Substrate and Digital Twins

The Microsoft 365 substrate and brings items together from across Microsoft 365 to let common services like Microsoft Search and eDiscovery work efficiently. Obviously, it’s much easier when a service like Search doesn’t need to process multiple repositories. To make this possible, Planner uses the substrate to create “digital twins” when tasks are created and edited and stores them as items in the mailboxes belonging to the assignees. These items are also called compliance records or secondary copies. The Planner data in Azure remains the storage repository of record.

Tasks assigned to a single user result in the creation of a compliance record in their mailbox. Tasks assigned to multiple users generate compliance records in the mailboxes of all assignees. This mimics the approach taken by Teams when it creates compliance records for personal chats and conversations in private channels.

And like Teams and Yammer, digital twins of tasks assigned to hybrid and guest accounts are stored in cloud-only mailboxes (aka shards), which are also indexed. Unassigned tasks are ignored.

Teams stores its compliance records to a hidden folder in the non-IPM part of mailboxes, the part which isn’t usually exposed by clients like Outlook and OWA. Yammer stores its compliance records in a similar place. Planner uses a folder called AllToDoTasks to store its compliance records. This folder also holds compliance records for To Do items. To generate just the items for Planner tasks, Exchange Online has a MAPI search folder called Folder Memberships\Assigned to Me. Planner displays the contents of this folder when users take the Assigned to Me option in the Planner hub. Exchange Online also stores personal tasks created with Outlook or To Do in the Tasks folder in the client-visible part of the mailbox.

End users aren’t affected by storing compliance records for Planner in Exchange Online. The Planner browser and mobile clients continue to use the Graph API to access plans and tasks in Azure.

Integration with To Do

The original text of MC229058 says that the update supports work “to build deeper integrations between To Do and Planner. Perhaps the existence of copies of Planner tasks in the same mailboxes will make the type of integration demonstrated in the Teams Tasks app easier. There’s no obvious sign of what these integrations might be, but time will tell.

Learn more about Planner, the Microsoft 365 substrate, and eDiscovery in the Office 365 for IT Pros eBook. Updated monthly to keep abreast with important changes in apps like Planner.

Despite the central importance of Exchange Online in many Microsoft 365 tenants, it’s natural that some administrators might not have grasped the finer details of mailbox management. There’s lots to look after elsewhere from SharePoint Online sharing permissions to the many management policies used by Teams. One detail that I often think is overlooked is the role played by mailbox plans, specifically how mailbox plans affect mailbox settings.

Four Mailbox Plans for Each Tenant

Every tenant comes equipped with four mailbox plans, which you can see by running the Get-MailboxPlan cmdlet. These plans accommodate the different variations of Exchange available in different Office 365 and Microsoft 365 products.

Get-MailboxPlan | Format-Table DisplayName, IsDefault, Name

DisplayName              IsDefault Name
-----------              --------- ----
ExchangeOnlineEnterprise      True ExchangeOnlineEnterprise-8fc1c029-5e32-485e-9810-179fb4701447
ExchangeOnlineDeskless       False ExchangeOnlineDeskless-bc1e76cc-4c0b-491c-a518-3a0a43cbf78e
ExchangeOnline               False ExchangeOnline-12c139bc-eafa-4a43-b4d2-e285f83e075d
ExchangeOnlineEssentials     False ExchangeOnlineEssentials-1a1bf516-90d5-4c4b-a047-5b3544ad9826

The role of the mailbox plan is to be a template holding settings for mailbox properties. When you create a new mailbox, the new mailbox inherits settings from the mailbox plan chosen by Exchange Online. Most mailboxes are created along with new accounts via the Microsoft 365 admin center. When this happens, Exchange Online uses the license assigned to the account to select the mailbox plan to apply to the new mailbox. Table 1 shows the match-up between licenses and mailbox plans.

Default Plan

In the output for Get-MailboxPlan shown above, the Exchange Online Enterprise plan is marked as the default. If you create a user mailbox without a license, Exchange Online uses the default plan to populate its settings. Mailboxes which don’t need licenses, like shared and resource mailboxes, use the Exchange Online mailbox plan. An administrator can specify the mailbox plan to use when creating a new mailbox with the New-Mailbox cmdlet.

Updating Mailbox Plans

The Set-MailboxPlan cmdlet configures settings in mailbox plans while the Get-MailboxPlan cmdlet reports the settings. Because the idea behind mailbox plans is to configure basic mailbox settings, not every property configurable with the Set-Mailbox cmdlet is available in a mailbox plan. The settings cover:

• Mailbox quotas and warning thresholds.
• Message send and receive size.
• Deleted items retention period.
• Mailbox retention policy.
• User role assignment policy.

In this example, we use Set-MailboxPlan to update the Exchange Online enterprise plan to update the largest supported message size for send and receive to 125 MB, change the deleted item retention period from 14 to 30 days, and assign a new default mailbox retention policy.

Set-MailboxPlan -Identity ExchangeOnlineEnterprise -MaxSendSize 125MB -MaxReceiveSize 125MB -RetainDeletedItemsFor 30.00:00:00 -RetentionPolicy "General Mailbox Retention Policy"

Somewhat frustratingly, although Get-MailboxPlan returns a large set of mailbox properties and values, Set-MailboxPlan is unable to update most settings listed by Get-MailboxPlan. If you want to update a mailbox property outside the set supported by Set-MailboxPlan, you must run Set-Mailbox after creating the mailbox. For instance, you might want to write a value into one of the custom attributes.

Modifying the settings of a mailbox plan does not affect existing mailboxes. If you want to change settings for existing mailboxes, you’ll need to run the Set-Mailbox or Set-CASMailbox cmdlets. However, if the license assigned to a user mailbox changes, Exchange Online applies the settings for the relevant plan to the mailbox.

CAS Mailbox Plans

Each mailbox plan has a corresponding CAS mailbox plan. This mimics the relationship between Set-Mailbox and Set-CasMailbox where the first cmdlet updates essential mailbox settings while the second deals with connectivity. In this instance, the Set-CASMailboxPlan cmdlet allows administrators to control the following settings.

• Enabling Exchange ActiveSync.
• Enabling IMAP4 and POP3.
• OWA mailbox policy.

The protocol settings only disable or enable connections. They do nothing to force modern authentication (and as we know for Apple iOS clients, even when an email app supports modern authentication, it might not be used).

Here’s an example of disabling the POP3 and IMAP4 protocols in all mailbox plans. Given Microsoft’s well-founded focus on the elimination of basic authentication for email connectivity, it’s probably a good idea to disable these protocols for new mailboxes. You can always enable the protocols on a per-mailbox basis if someone convinces you that they have a good reason to use these ancient protocols (suitably upgraded for modern authentication).

Get-CASMailboxPlan | Set-CASMailboxPlan -PopEnabled $False -IMAPEnabled $False

You can check the protocol settings by running the Get-CASMailboxPlan cmdlet to return the different protocol settings:

Get-CASMailboxPlan -Identity ExchangeOnlineEnterprise | Format-List DisplayName, ImapEnabled, PopEnabled, MapiEnabled, ActiveSyncEnabled, OwaEnabled, OutlookMobileEnabled

Name                 : ExchangeOnlineEnterprise
ImapEnabled          : False
PopEnabled           : False
MAPIEnabled          : True
ActiveSyncEnabled    : True
OWAEnabled           : True
OutlookMobileEnabled : True

Surprisingly, you can’t control access to Exchange Web Services (EWS) through a mailbox plan. This is one of the protocols you’ll need to disable by running Set-CASMailbox after creating a mailbox.

To check how many mailboxes have each mailbox plan, we can check the plan registered for each mailbox. Note that the filter used to find mailboxes requires the distinguished name for the mailbox plan.

$MbxPlans = Get-MailboxPlan
ForEach ($Plan in $MbxPlans) {
   $Dn = (Get-MailboxPlan -Identity $Plan.Name).DistinguishedName
   # Find mailboxes with the plan
   [Array]$Mbx = Get-ExoMailbox -Filter "MailboxPlan -eq '$Dn'" -Properties MailboxPlan -ResultSize Unlimited
   If ($Mbx) {
     ForEach ($M in $Mbx) {
      $ReportLine  = [PSCustomObject][Ordered]@{ 
         Name           = $M.DisplayName
         UPN            = $M.UserPrincipalName
         Plan           = $Plan.DisplayName }
   $Report.Add($ReportLine) }
   }
} #End ForEach
$Report | Group Plan | Format-Table Name, Count

Name                     Count
----                     -----
ExchangeOnlineEnterprise    43
ExchangeOnline              17

Mailbox Plans Summary

Mailbox plans help Exchange Online to run a little smoother by making sure that some essential settings are in place for new mailboxes. It’s likely that you will need to do some further tuning of mailbox settings post creation and it would be nice if Microsoft expanded the set of updatable settings in mailbox plans to make the plans more powerful. At least PowerShell is available to fill the gaps left by Microsoft, a role that’s as important today as it was when Exchange 2007 was the first major server product to support PowerShell many years ago.

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

Read Receipts Is a Very Old Email Feature

I haven’t thought about email read receipts for years. It’s a very old email feature that goes back to the days when unreliable SMTP and X.400 connections linked organizations together and you never quite knew if email got through to its destination. The reliability of computer networks today means that read receipts are less important, or maybe it’s just that other communication methods have replaced some email traffic, like Teams. The introduction of read receipts for Teams in early 2020 doesn’t count because the read receipt for chats is more of a “seen” indicator than a message returned to a sender to confirm that an addressee has opened an email (Figure 1).

Helping a Police Chief

Which brings me to a request from an Office 365 for IT Pros reader. Apparently, a police chief is sick and tired that their email sent to some recipients is not being responded to. They want to know when the addressees open the messages he sends. The request was to be able to turn on automatic read receipts for mailboxes and disable the ability of users to change the setting.

Read receipt is a message option, like delivery receipt (confirming the delivery of a message to a mailbox). When set, the read receipt shows up in the message properties as a Disposition-Notification-To header with the return address to receive the read receipt (Figure 2). A blast from the past EHLO blog post from 2011 explains more.

The presence of the Disposition-Notification-To header is what prompts clients to check if they should ignore the request, send the receipt automatically, or ask the user if they’d like to send the receipt. The immediate problem in satisfying the user request is that Exchange Online considers read receipts to be a client-side function. In other words, the action to respond to the sender is invoked when a recipient uses a client to open a message with a read receipt requested. Clients have different settings to control how to respond.

OWA Read Receipt Settings

Take OWA for example. It’s easy to configure the user settings for read receipts through the Message handling section in OWA settings (Figure 3).

There’s also an Exchange Online PowerShell cmdlet to do the job. For instance, let’s assume that we want a set of users to always send read receipts when requested. This code uses the CustomAttribute12 property to hold the value “RR” to indicate that a mailbox should be in the set. We can use a server-side filter to find the mailboxes and call the Set-MailboxMessageConfiguration cmdlet to update the read receipts setting.

# Find mailboxes to update and then update their read receipt setting to always send read receipts
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter {CustomAttribute12 -eq "RR"}
If ($Mbx.Count -eq 0) {Write-Host "No mailboxes found"; break}
ForEach ($M in $Mbx) {
   Write-Host "Setting mailbox read receipt configuration for" $M.DisplayName
   Set-MailboxMessageConfiguration -Identity $M.UserPrincipalName -ReadReceiptResponse AlwaysSend }

Using RBAC to Remove Read Receipt Settings from OWA

Although administrators can update user mailbox settings to control read receipts, it does nothing to stop users changing the read receipt options through OWA settings. To block that happening, we need to remove the read receipt options from the GUI. Exchange Online has a well-developed role-based access control (RBAC) system to control features available to users. RBAC works through the user role assignment policy set on user mailboxes. These policies enable or disable features by controlling the cmdlets available to users. For instance, I’ve written in the past about how to use RBAC to stop people updating their OWA autosignature.

To stop users changing the read receipt setting, we need to:

• Create a new RBAC role based on the regular set of user options.
• Remove the entry in the role for the cmdlet used to update read receipt settings (Set-MailboxMessageConfiguration).
• Remove the entry in the role for the cmdlet used to fetch add display the read receipt settings (Get-MailboxMessageConfiguration).
• Create a new user role assignment policy containing the roles usually granted to users with the exception that we replace the base options with the edited version which blocks the ability to update the read receipt settings.

All of this sounds complicated, but it’s a system that worked well since its introduction in Exchange 2010. Here’s the PowerShell code to do the work listed above:

New-ManagementRole MyBaseOptions-NoRR -Parent MyBaseOptions

Set-ManagementRoleEntry MyBaseOptions-NoRR\Set-MailboxMessageConfiguration -Parameters ReadReceiptResponse -RemoveParameter

Remove-ManagementRoleEntry MyBaseOptions-NoRR\Get-MailboxMessageConfiguration

New-RoleAssignmentPolicy -Name PolicyWithNoRR -Roles MyContactInformation, MyRetentionPolicies, MyMailSubscriptions, MyTextMessaging, MyVoiceMail, MyDistributionGroupMembership, MyDistributionGroups, MyProfileInformation, MyBaseOptions-NoRR -Description "User Role Assignment Policy to block users updating read receipt settings"

The last thing to do is to assign the user role assignment policy to the mailboxes we want to block. This is done with the Set-Mailbox cmdlet:

Set-Mailbox -Identity Chris.Bishop -RoleAssignmentPolicy PolicyWithNoRR

Thirty minutes or so later, the new policy will take effect. You’ll know that it works if you go to OWA settings and don’t see the options to update the read receipt settings (Figure 4).

To bring the solution together, you can add the Set-Mailbox command to the code described above to update the read receipt setting and assign the user role assignment policy for the set of target mailboxes.

ForEach ($M in $Mbx) {
   Write-Host "Setting mailbox read receipt configuration for" $M.DisplayName
   Set-Mailbox -Identity $M.UserPrincipalName -RoleAssignmentPolicy PolicyWithNoRR
   Set-MailboxMessageConfiguration -Identity $M.UserPrincipalName -ReadReceiptResponse AlwaysSend }

Controlling Read Receipts in Outlook

Our problem is solved if OWA is the sole client in use. Unhappily, that’s probably not the case. Clients like Outlook for Windows, Outlook for Mac, and Outlook mobile might be in use, as might third-party clients. Every client has its own method to control the processing of read receipts. For instance, Figure 5 shows the settings in Outlook for Windows (click to run version).

For historic reasons, most Outlook for Windows settings are stored in the system registry. A check of the settings available in the administrative templates for Outlook reveals that the read receipts are controlled by the receipt response  DWORD value at HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Mail. The values are:

• 0: Always send a response.
• 1: Never send a response.
• 2: Ask the user before sending a response.

You can update the value manually by editing the registry (Figure 6), which is fine for a test case. In production, you’re likely to use a group policy object (GPO) or other technique to deploy the policy setting to client workstations.

Once the policy is in place, Outlook greys out the options to control read receipts.

Client-Side Feature Dependant on Client-Side Controls

In summary, read receipts are a client-side feature invoked by the presence of the Disposition-Notification-To message header. Because it’s a client-side feature, any attempt to force the client to process read receipts in a particular manner depends on the controls available in a client. We can satisfy the police chief’s request for OWA and Outlook for Windows. I see no way to do this for Outlook mobile and didn’t investigate Outlook for Mac or any of the many other email clients which can connect to Exchange Online using Exchange ActiveSync (EAS), IMAP4, or POP3 (hopefully without using basic authentication). Now you know what you should look for, checking how to deal with other clients is an exercise for the reader!

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

Just a Few Terabyte-Plus Archives in Use

Microsoft’s decision to enforce a new 1.5 TB limit for auto-expanding archives from November 1, 2021, caused more interest than I thought would happen. Although the idea of having a “bottomless archive” seems like a nice capability, the real situation is that relatively few of the 300-odd million Office 365 licensed users have archive mailboxes anywhere close to a terabyte.

Identify Large Expanding Archives with PowerShell

In the note I published on Practical365.com, I included a PowerShell script to report the status of archive-enabled mailboxes. Afterwards, I was asked whether it would be easy to adapt the script to report mailboxes which might be in danger of approaching the new 1.5 TB limit.

Good idea, I thought, and set to work. The full script is downloadable from GitHub, and here’s the flow of the processing.

• Declare variables to hold the number of bytes in 1.5 TB (1649267441664) and the warning level. I selected 90% as a good warning threshold. You could select a lower or higher value.
• Find the mailboxes with archives. This is a server-side filter with Get-ExoMailbox, so it’s reasonably fast. I then use a client-side filter to remove mailboxes which don’t use expandable archives.
• Calculate the mailbox size. In this instance, Microsoft is taking an all-up approach and will assess the 1.5 TB limit against the complete mailbox contents, including Recoverable Items. This is unlike normal mailbox storage quotas, which only count “non-dumpster” folders.
• Check if each mailbox is within the warning limit and create a status message if true.
• I wanted some way to assess of the daily growth rate for the archive. There’s no obvious way to generate this figure from PowerShell, so I use the creation date for the mailbox to calculate the number of days in use. I then divide the number of days into the current archive size to calculate the average daily growth. It’s a crude mechanism but better than nothing.
• I also use the average daily growth to estimate the number of days until the archive hits the limit. For most mailboxes, this is a big number.

Here’s the main processing loop for the mailboxes:

$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($M in $ExMbx) {
   $Status = $Null
   Write-Host "Processing mailbox" $M.DisplayName
   [int]$DaysSinceCreation = ((New-TimeSpan -Start ($M.WhenCreated) -End ($Now)).Days)
   $Stats = Get-ExoMailboxStatistics -Archive -Identity $M.UserPrincipalName
   [string]$ArchiveSize = $Stats.TotalItemSize.Value
   [string]$DeletedArchiveItems = $Stats.TotalDeletedItemSize.Value 
   [long]$BytesInArchive = $Stats.TotalItemSize.Value.ToBytes()
   [long]$BytesInRecoverableItems = $Stats.TotalDeletedItemSize.Value.ToBytes()
   [long]$TotalBytesInArchive = $BytesInArchive + $BytesInRecoverableItems
   # Check if archive size is within 10% of the 1.5 TB limit - the size that counts is the combination of Recoverable Items and normal folders
   If ($TotalBytesInArchive -ge $TBBytesWarning) 
       { Write-Host ("Archive size {0} for {1} is within 10% of 1.5 TB limit" -f $ArchiveSize, $M.DisplayName ) 
         $Status = "Archive within 10% of 1.5 TB limit" }
   [long]$BytesPerDay = $TotalBytesInArchive/$DaysSinceCreation
   [long]$NumberDaysLeft = (($TBBytes - $TotalBytesInArchive)/$BytesPerDay)
   $BytesPerDayMB = $BytesPerDay/1MB
   $GrowthRateDay = [math]::Round($BytesPerDayMB,4)
   $TotalArchiveSizeGB = [math]::Round(($TotalBytesInArchive/1GB),2) 
   
   $ReportLine = [PSCustomObject][Ordered]@{  
       Mailbox                   = $M.DisplayName
       UPN                       = $M.UserPrincipalName
       Created                   = $M.WhenCreated
       Days                      = $DaysSinceCreation
       Type                      = $M.RecipientTypeDetails
       "Archive Quota"           = $M.ArchiveQuota.Split("(")[0] 
       "Archive Status"          = $M.ArchiveStatus
       "Archive Size"            = $ArchiveSize.Split("(")[0] 
       "Archive Items"           = $Stats.ItemCount
       "Deleted Archive Items Size" = $DeletedArchiveItems.Split("(")[0] 
       "Deleted Items"           = $Stats.DeletedItemCount
       "Total Archive Size (GB)" = $TotalArchiveSizeGB
       "Daily Growth Rate (MB)"  = $GrowthRateDay
       "Days Left to Limit"      = $NumberDaysLeft
       Status                    = $Status   
    }
    $Report.Add($ReportLine) 
} #End ForEach

Considering the Data

The script generates a CSV file containing the mailbox data. I also like to output the data on screen using the Out-GridView cmdlet to get some insight into the results. For example, Figure 1 shows some output from mailboxes in my tenant. As you can see, at a 18.07 MB/day growth rate, it will take my archive 84,228 days to get from its current 9.129 GB to 1.5 TB. What a relief!

Example of PowerShell Flexibility

The script works as an example of how PowerShell delivers insight for Microsoft 365 tenant administrators, which is why every tenant administrator should be familiar with PowerShell and be able to run scripts and make simple code changes. Because most archives are less than 100 GB and won’t get near the new 1.5 TB limit in their lifetime, I suspect that few tenants will find the script valuable in an operational sense. However, it’s always nice to be able to answer questions with a few lines of code.

Learn more about how Office 365 really works (including PowerShell and archive mailboxes) 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.

The Transition of the EAC

Updated 30 May 2022

The news that Microsoft will finally retire the old Exchange Online admin center (inherited from the on-premises server) in 2022 started me thinking about information which Microsoft should expose in the new EAC. Not every tenant administrator likes PowerShell, and even fewer enjoy grappling with the Microsoft Graph APIs. The kind of situation I’m thinking of is where it would be useful to have a GUI to manage data that’s not exposed today. Like inactive mailboxes.

As I pointed out in the article, Microsoft still has work to do to move functionality from the old EAC to wherever it’s going to be in the future. Exchange’s Mailbox Records Management (MRM) is a special concern because some retention operations (like moving messages to archive mailboxes) is unsupported by Microsoft 365 retention policies. Mobile device access policies are another example.

Some Objects Never Featured in the EAC

And then there are some parts of Exchange which have never shown up in EAC. Inactive mailboxes are an example of what I’m thinking of. These objects occur when an administrator deletes a Microsoft 365 account which is still subject to a litigation or eDiscovery hold. In either circumstance, the mailbox of the now-deleted account holds information which might be needed, so Exchange Online keeps the mailbox in an inactive state. The contents are online, indexed, and discoverable (including non-user data like Teams compliance records), but the mailbox is inaccessible to users unless it is restored. Microsoft created inactive mailboxes to allow tenants to retain Exchange Online user mailboxes for eDiscovery without being connected to a licensed account. This problem doesn’t arise on-premises, which is why inactive mailboxes never appeared in the old EAC.

Inactive mailboxes remain online until the last hold elapses. At this point, the Managed Folder Assistant removes the mailbox. The hold might be:

• An Exchange Online litigation hold (on the whole mailbox).
• A Microsoft 365 retention policy (which could be scoped to cover the entire mailbox).
• A hold placed by a retention label.
• A hold placed by a Core or Advanced eDiscovery case.

In addition, some old holds from Exchange eDiscovery might still be in place. Microsoft deprecated these holds in 2020, but the nature of eDiscovery is that some cases last a long time.

Management of Inactive Mailboxes

Inactive mailboxes don’t need a lot of management unless you want to recover data from an inactive mailbox or restore the inactive mailbox to a new mailbox. Apart from that, inactive mailboxes are self-managing and remain in place until the holds supporting their status expire. Note that the Managed Folder Assistant continues to process inactive mailboxes and will remove items which are not needed by the holds in place.

It’s reasonable to ask administrators to use PowerShell to preform infrequent tasks like recovery and restore of inactive mailboxes. What’s less acceptable is the invisibility of inactive mailboxes across the Microsoft 365 administrative interfaces. That’s excepting PowerShell, because you can always run the Get-ExoMailbox cmdlet to return the set of inactive mailboxes, like this:

Get-ExoMailbox –InactiveMailboxOnly -Properties WhenSoftDeleted | Sort WhenSoftDeleted -Descending | Format-Table DisplayName, WhenSoftDeleted

DisplayName                                  WhenSoftDeleted
-----------                                  ---------------
Jack Smith                                   17/06/2021 15:37:53
Sanjay Patel                                 26/11/2020 14:10:56
Nancy Anderson                               03/10/2020 13:14:05
Boris Johnstone                              29/05/2020 09:23:00
Sanjoyan Mustafi                             12/05/2020 15:33:08
Kerry Jones                                  12/05/2020 15:12:03
John Hubbard                                 12/05/2020 15:12:02

The WhenSoftDeleted property tells us when Exchange Online put the mailbox in that state. After a mailbox spends 30 days in a soft-deleted state, Exchange Online will remove it permanently. That is, unless a hold exists on the mailbox, in which case it becomes inactive. All of the mailboxes listed above are well past the 30-day soft-deletion period, so the holds on the mailboxes must still be active.

Inactive Mailboxes in the Purview Compliance Portal

A change which I recently noticed is the addition of an inactive mailboxes listing under Retention in the Data Lifecycle section of the Microsoft Purview Compliance portal. The case for inclusion here rather than the new EAC is that inactive mailboxes are more important to compliance than day-to-day operations. It’s a reasonable position.

Apart from acknowledging this as a starting point, it’s hard to get excited about the listing because it’s currently not very functional. You can see a list of inactive mailboxes and select a mailbox to view its properties. Unfortunately, the set of properties shown is limited (Figure 1) and you can’t do anything with a selected mailbox.

It would be nice if Microsoft allowed administrators to use the new GUI to:

• Update the display name of an inactive mailbox (the Set-Mailbox -InactiveMailbox command only updates the LitigationHoldEnabled and LitigationHoldDuration parameters for inactive mailboxes. I like to mark inactive mailboxes by updating their display name (as in Figure 1). Unfortunately, I often forget, and once the mailbox becomes inactive, its display name cannot be changed.
• Recover an inactive mailbox.
• Restore an inactive mailbox.
• Report the holds which make a mailbox inactive.
• Release a litigation hold.
• Exclude the mailbox from retention policies (so that the hold doesn’t apply).

I don’t advocate releasing inactive mailboxes from eDiscovery holds as investigators often run eDiscovery cases and administrators might be unaware of the reasons for holds placed on mailboxes.

In any case, the new page in the Purview Compliance portal is a start. Let’s hope Microsoft expands its functionality to make it easier to manage inactive mailboxes.

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.

The Woes of Core eDiscovery

Last May I wrote about the GUI makeover Microsoft delivered for the Core eDiscovery functionality in the Microsoft 365 compliance center. In a nutshell, I wasn’t impressed because the update was slower and buggier than its predecessor. A few months on, some of the bugs don’t seem as obvious but the performance is still not as it should be. The lack of performance shows up in PowerShell too, where cmdlets like New-ComplianceSearch and New-ComplianceSearchAction do not perform as they once did and return more errors than before. I suspect that something is very wrong on the back end.

This all brought me back to Search-Mailbox, a cmdlet that Microsoft would like to eliminate from Exchange Online. Microsoft deprecated the cmdlet on July 1, 2020, along with a bunch of other search and compliance features specific to Exchange. However, even if it’s unsupported, the cmdlet continues to work perfectly well, especially when used to remove mailbox items.

Good Architecture, Flawed Outcome

I’m sure the architecture chosen for Microsoft 365 compliance searches seemed like a good idea at the time. Searches need to work across multiple workloads rather than just mailboxes, which is why Microsoft chose to decouple searches from the actions you can take with the results of the searches (like preview, export, and purge). For some unknown reason, they’ve never managed to get around to expanding the ability of the purge action to deal with anything other than Exchange mailboxes.

Even if you only need to remove mailbox items, content search actions restrict purging 10 items per mailbox at one time. Apparently, this is because a purge action isn’t designed to clean up mailboxes. Instead, it is to surgically remove items from mailboxes, which is fine if you need to remove 10 or less from each mailbox. If not, you’ll be forced to write a PowerShell script to loop through searches until all matching items are exhausted, like we describe in this article. And when you throw in some errors (transient or otherwise) because the backend has problems of its own, content search actions suddenly look pretty undesirable.

Search-Mailbox Basics

Search-Mailbox is simpler. It searches user mailboxes to:

• Estimate how many items a search will find, including searching the Recoverable Items folders and archive mailboxes.
• Copy items from one mailbox to another.
• Remove items.

Search-Mailbox can process up to 10,000 items per mailbox (when copying messages), which is enough to deal with most situations. The cmdlet will complain but can go higher when simply deleting messages. I haven’t found its upper limit.

There’s no GUI. Everything is done through PowerShell, and those who need to run Search-Mailbox must be hold the RBAC Mailbox Import Export role before they can remove mailbox items. To discover who holds the role, I use this code:

[array]$Users = Get-ManagementRoleAssignment -Role "Mailbox Import Export" -GetEffectiveUsers | Select -ExpandProperty EffectiveUserName
$Users | Sort -Unique

Scripting a Demonstration of Search-Mailbox

To demonstrate how useful Search-Mailbox remains, I wrote a script (available on GitHub) that can either generate estimates or remove items based on a search query. The mode is controlled by a simple parameter which is True to remove items or False to estimate items.

.\PurgeMessagesWithSearchMailbox.PS1 -DeleteItems $True

The body of the script has some hardcoded parameters to generate the search query, which is formed in the Keyword Query Language. You could prompt the user for the different elements which compose the query, but it was easier to hard code the values for demonstration purposes.

For instance, to remove the digest emails sent by MyAnalytics (now rebranded as Viva Insights), the values are:

$Sender = "no-reply@microsoft.com"
$StartDate = "1-Jan-2019"
$EndDate = "13-Sep-2021"
$BodyText = "Your month in review"
$Subject = "MyAnalytics"

To create the search query, we do:

$SearchQuery = "From:" + $Sender + " Sent:" + $StartDate + ".." + $EndDate
If ([string]::IsNullOrWhiteSpace($BodyText) -eq $False) { $SearchQuery = $SearchQuery + ' Body: "*' + $BodyText + '*"' }
If ([string]::IsNullOrWhiteSpace($Subject) -eq $False) { $SearchQuery = $SearchQuery + ' Subject:"*' + $Subject + '*"' }

Using the hardcoded parameters, the code generates this search query, which is a good example of the kind of complex queries Search-Mailbox can use to find messages:

From:no-reply@microsoft.com Sent:1-Jan-2019..13-Sep-2021 Body: "*Your month in review*" Subject:"*MyAnalytics*"

After generating the search query, the code finds some mailboxes (you could limit the set to certain mailboxes) and loops to run Search-Mailbox against each mailbox. If an estimate is requested, the command is:

$SearchOutput = Search-Mailbox -Identity $M.UserPrincipalName -SearchQuery $SearchQuery -EstimateResultOnly -Force -WarningAction SilentlyContinue -SearchDumpster

While removal of items is done with:

$SearchOutput = Search-Mailbox -Identity $M.UserPrincipalName -SearchQuery $SearchQuery -DeleteContent -Force -WarningAction SilentlyContinue -SearchDumpster

The script runs very nicely (Figure 1) and is much faster than using a content search action to purge mailbox items. Its output is a CSV file containing details of the items found and removed (if that’s what happened).

Removal Means Retention Until Holds Lapse

Removal means that Exchange Online keeps the items in the Recoverable Items structure until the last hold expires. This could be a simple matter of a mailbox’s single item recovery period lapsing (14 days by default), or it could be an-place litigation or eDiscovery hold. In either case, the Managed Folder Assistant removes the items after the last hold expires. Until then, the items remain inaccessible to users but available for eDiscovery.

Remember that searches will find deleted items in Recoverable Items, which means that if you run Search-Mailbox multiple times it might seem that you’re deleting the same items. In fact, the first deletion run removes the items from user view. Subsequent runs process the items in Recoverable Items, but as they’re already where they should be, nothing much happens.

Old Stuff Can Be Good Too

I realize that Microsoft wants to eliminate what they consider to be old code that harks back to on-premises roots. They are right to do so, but only when a reasonable alternative exists to allow customers to have the same functionality through a new method. Although content search actions seem to do the same job, the sad fact is that they are not as effective as the Search-Mailbox cmdlet is in dealing with day-to-day removal of mailbox items in situations like when spam arrives in user mailboxes, or someone sends out a message they shouldn’t have. It saddens me that the new code is not as good as the old. Let’s hope Microsoft closes the performance and functionality gap soon.

Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work. Search-Mailbox is covered in the companion volume (which we refreshed today).

A reader asks what’s the best way to transfer the membership of distribution lists from one user account to another? If this is a one-off operation involving just a few DLs, the right answer is to add the new account to the DLs using your preferred administrative interface (Microsoft 365 admin center, Exchange admin center, or PowerShell).

Automating Distribution List Updates

Handling a few adjustments to distribution list membership through a GUI is acceptable. But if the membership of 30 or 40 distribution lists must be adjusted, which sometimes happens when people change jobs, it’s better to automate the process (if only to avoid boredom).

The capabilities of Exchange Online PowerShell make this task very straightforward. The basic approach is:

• Find the source mailbox (check it exists, etc.).
• Find the target mailbox.
• Find the set of distribution lists the source mailbox is a member of. If the mailbox doesn’t belong to any distribution lists, say so and exit.
• Display the set of distribution lists to be transferred and prompt for approval to proceed.
• If yes, go ahead and add the target mailbox to the membership of each of the distribution lists in the set. Optionally, remove the source mailbox from the same distribution lists.

Here’s some code to illustrate the principle.

$SM = Read-Host "Enter name of source mailbox"
$SourceMailbox = (Get-ExoMailbox -Identity $SM -ErrorAction SilentlyContinue -RecipientTypeDetails UserMailbox)
If (!($SourceMailbox)) { Write-Host "Unable to find mailbox for" $SM " - exiting"; break }
$TM = Read-Host "Enter name of target mailbox"
$TargetMailbox = (Get-ExoMailbox -Identity $TM -ErrorAction SilentlyContinue -RecipientTypeDetails UserMailbox)
If (!($TargetMailbox)) { Write-Host "Unable to find mailbox for" $TM " - exiting"; break }
$DN = $SourceMailbox.DistinguishedName
$NewDN = $TargetMailbox.DistinguishedName
[array]$DLs = (Get-DistributionGroup -ResultSize Unlimited -Filter "Members -eq '$DN'" | Select DisplayName, Notes, ExternalDirectoryObjectId, ManagedBy, PrimarySmtpAddress)

If ($DLs.Count -eq 0) { Write-Host "Sorry, but" $SourceMailbox.DisplayName "isn't a member of any distribution groups - exiting" ; break }

CLS
$DLs | Format-Table DisplayName, PrimarySMTPaddress -AutoSize
$PromptTitle = 'Transfer membership of Distribution Lists'

$PromptMessage = 'Please confirm whether to go ahead and transfer membership of ' + $DLS.Count + ' distribution lists from ' + $SM  + ' to ' + $TM
$yes = New-Object System.Management.Automation.Host.ChoiceDescription "&yes", 'yes?'
$no = New-Object System.Management.Automation.Host.ChoiceDescription "&no", 'no?'
$cancel = New-Object System.Management.Automation.Host.ChoiceDescription "&cancel", 'Exit'
$PromptOptions = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no, $cancel)
$PromptDecision = $host.ui.PromptForChoice($PromptTitle, $PromptMessage, $PromptOptions, 0) 

If ($PromptDecision -eq 0) { # Yes
  ForEach ($DL in $DLs) {
     Write-Host "Adding user" $TargetMailbox.DisplayName "to DL" $DL.DisplayName "and removing" $SourceMailbox.DisplayName
     Add-DistributionGroupMember -Identity $DL.ExternalDirectoryObjectID -BypassSecurityGroupManagerCheck -Member $TargetMailbox.PrimarySmtpAddress -ErrorAction SilentlyContinue
     Remove-DistributionGroupMember -Identity $DL.ExternalDirectoryObjectId -Confirm:$False -Member $SourceMailbox.PrimarySmtpAddress -BypassSecurityGroupManagerCheck -ErrorAction SilentlyContinue
  } # End Foreach
} # End if

[array]$NewDLs = (Get-DistributionGroup -ResultSize Unlimited -Filter "Members -eq '$NewDN'" | Select DisplayName, Notes, ExternalDirectoryObjectId, ManagedBy, PrimarySmtpAddress)
Write-Host " "
Write-Host ("All done. {0} is now a member of {1} distribution lists." -f $TargetMailbox.DisplayName, $NewDLs.Count)
$NewDLs | Format-Table DisplayName, PrimarySmtpAddress

There are many enhancements you could make to the code, including checking if the source mailbox is the owner of any of the distribution lists and if their removal leaves the distribution list in an ownerless state (this isn’t good). The code is written for Exchange Online but should work on-premises with a few adjustments (like switching Get-Mailbox for Get-ExoMailbox and using a different property for the distribution list identity).

Handling Dynamic Distribution List Membership

Transferring membership of dynamic distribution lists is more difficult. Dynamic distribution lists depend on a query (filter) executed against the Exchange Directory to resolve the set of recipients. Filters can be precanned, meaning that they execute against a set of well-known object properties like the department or city. Alternatively, the list owner or maintainer can create a custom filter with PowerShell to query against any property available for mail-enabled objects. Custom filters can be an excellent way to find the

Both precanned and custom filters depend on directory data. It therefore follows that to transfer membership from one mailbox to another, you need to understand the properties used by the filter and then adjust the properties of the target mailbox in the directory so that the filter includes the target mailbox in its result set when it runs. It’s possible to update directory properties with PowerShell to make sure that mailboxes are found by precanned or simple custom filters, but this becomes more difficult for complex custom filters. Given the number of dynamic distribution lists which are probably involved in moving membership from one mailbox to another, it’s probably best to make the changes manually.

And the Graph?

It would also be possible to transfer membership of distribution lists using the Microsoft Graph Groups API. However, this is an example of a situation where plain and simple PowerShell is all that’s needed. You won’t speed up the updates to any significant degree and will spend longer writing the code. That’s not a good trade-off, so stick with PowerShell and contemplate how easy it is to automate operations like this with just a few commands.

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

Sixty Times Larger Than in 1996

Browsing the pages of my 1996 book on Microsoft Exchange Server 4.0, I discovered that the average size of an email 25 years ago was in the 2-4 KB range. This got me thinking about what the current average might be, so I checked my Inbox by running the Get-ExoMailboxFolderStatistics cmdlet to retrieve the total size of the folder and the number of items in it. The code I used is as follows:

$CheckName = Read-Host "What User Mailbox Shall I Check?"
If (Get-ExoMailbox -Identity $CheckName) {
   $Stats = $Null
   Write-Host "Checking Mailbox for" $CheckName...
   $Stats = Get-EXOMailboxFolderStatistics -Identity $CheckName -FolderScope Inbox | Select Name, ItemsInFolder, FolderSize ,@{Name="FolderSizeBytes"; expression={((($_.FolderSize -replace '^(.*\()(.*)(\sbytes\))$','$2').Replace(',','')) -as [int])}} 

    Write-Host ("Results for mailbox {0}: {1} Inbox items {2} folder size with an average message size of {3} KB" -f $CheckName, $Stats.ItemsInFolder, $Stats.FolderSize.Split("(")[0], [math]::round(($Stats.FolderSizeBytes/$Stats.ItemsInFolder)/1KB,2))}

The code looks complicated, but it’s not too bad. We fetch some of the properties returned by Get-ExoMailboxFolderStatistics and put them into a variable. One of the properties is calculated to return the total number of bytes in the folder as a integer variable. We then calculate the average size of a message and write out what we found.

In any case, the result is that the average size of messages in my Inbox is sixty times larger than they were in 1996. Other mailboxes will likely show different results (run the code against your Inbox to see what it reports) as it all depends on the volume of traffic and the type of messages you receive. However, I think everyone can agree that the size of messages sent and received today are larger than they were in the past.

Reasons for Swelling Messages

The reasons why today’s messages are much larger vary across organizations. However, I think four core reasons exist:

• More Headers: Today’s SMTP traffic include more message headers than ever before.
• Rich Editors: Old text-only messages are now jazzy HTML rich-text messages.
• Fat Attachments: Capable networks make users think nothing about sending a 25 MB PowerPoint presentation in email. They wouldn’t do this if connected on a dial-up telephone link.
• User Habits: We’re lazy and reply-all to messages which include all previous replies.

SMTP messages used to include just enough headers to get the email through. Now, a bunch of new headers exist, some of which are essential to authenticate that email comes from the right source and isn’t spam (DMARC, ARC, SPF, etc.). Other x-headers are added by servers like Exchange to track the progress of messages, include anti-spam reports, and measure latency. Fire up Outlook’s Message Header Analyzer add-in to examine the headers in a message to see what I mean.

Rich Format Email

Rich editors mean that text and formatting instructions must be sent where plain text was the norm. Embedded graphics drive up message sizes, including the autosignatures inserted by users and organizations. Complex autosignatures with corporate logos and social networking links add even more to message sizes, especially when organizations lose control and insist that every message goes out complete with graphic-intense marketing messages.

It’s lucky for everyone that servers are so fast and networks so capable that they can deal with the processing overhead required to transport messages in and out of Exchange Online and between Microsoft’s datacenters and email servers elsewhere across the internet. I’m not sure that Exchange’s original IMC (Internet Mail Connector) would have been up to the task.

The Size and Intelligence of Notification Email

Even relatively simple notification messages generated by applications can be huge. For instance, a brief review of notifications from different Microsoft 365 apps telling me that people are trying to contact me resulted in the following sizes:

• LinkedIn: 174 KB
• Teams: 265 KB,
• Yammer: 472 KB (Figure 1).

To be fair to Yammer, the latest generation of notification email are graphically rich and interactive to allow recipients to respond within the email client. The code necessary to enable this functionality increases the amount of HTML carried around in messages. It’s a price we must pay for intelligent messages.

Cloudy Attachments and Bad Habits

Microsoft’s efforts to convince users of the goodness of sending “cloudy attachments” (links to files in OneDrive for Business and SharePoint Online) are showing signs of progress, especially within Office 365. Consistent sharing links, the ability to co-author (now even when documents are protected with sensitivity labels), and easy access to files stored in other tenants mean that users send an increasing number of links where files were once attached. However, the default option for many is still to attach files (or rather, a copy of a file), and once that happens, the average size of message swells quickly.

People are creatures of habit, which is one reason why we continue to send traditional attachments. We also tend to take the path of least resistance, which is why we reply to messages without thinking about the long trail of previous replies sent along with our response. The outcome is that a message at the end of a thread might be 1 MB, roughly 10% of which is useful non-repetitive information.

Large Cloud Mailboxes Required

The world of email is very different to what it was when Exchange 4.0 appeared in 1996. I doubt anyone today could cope with the 20 MB mailbox quota often assigned to users in those days. Given the growing size of messages, it’s a good thing that Microsoft makes generous mailbox quotas available for Exchange Online users. Even so, if the trend of ever-swelling messages continues, we’ll all need 200 GB mailboxes soon.

The Office 365 for IT Pros eBook hasn’t covered developments in Exchange mailbox technology since 1996. Some of our authors remember back that far, but mostly we live in the modern world and track new developments as they happen inside Office 365.

Antiquated Report Revived Because of Customer Feedback (But Better Alternatives Exist)

Updated April 2022 with details of the new location for the Top Senders report and Top Recipients report in the Microsoft 365 Defender portal

Microsoft published an update to message center notification MC237975 on April 22, 2021 to cancel the proposed retirement of the Top Senders report and the Top Recipients report and its associated PowerShell cmdlet (Get-MailTrafficSummaryReport) previously advised on February 5, 2021. According to the update, Microsoft based its decision on customer feedback, which means that some customers must like the report and the cmdlet. I am mystified why this is so. It’s a simply horrible report. In their defense, those advocating its retention must not understand that better alternatives exist.

Reports in the Microsoft 365 Defender Portal

Originally located in the Office 365 Security and Compliance Center (SCC), the Top Senders report and Top Recipients report are now found under Email & Collaboration in the Reports section of the Microsoft 365 Defender portal. The reports section is organized into a series of widgets, each representing a report. The Top Senders and Recipients report can look back 90 days (the period for which Exchange Online preserves message trace data) and the data it presents is moderately interesting (Figure 1).

The Top Senders report and Top Recipients report and the underlying cmdlet are old (the cmdlet dates to at least 2015) and Microsoft has given them little or no tender loving care since. The data presented in the reports in the old SCC including all sorts of crud, such as message sent to replicate public folders between public folder mailboxes, updates sent by SharePoint Online when users share documents, and so on. You can’t apply a filter to remove all the system junk from the data, so you end up with useless statistics such as public folder replication represents 80.77% of all send message activity over the last 90 days. Thankfully, Microsoft applies better filters to the reports available in the Microsoft 365 Defender portal.

However, the Top Senders and Top Recipients reports don’t take account of recent advances such as plus addressing and the support in Exchange Online to allow users to send messages using any proxy address assigned to their mailbox. Each plus and proxy address is listed separately instead of being grouped under the mailbox.

It’s not difficult to filter out messages like those for system, group, and shared mailboxes to create a report based on mailbox activity. Take the PowerShell example below, which uses the Get-MailTrafficSummaryReport cmdlet to create two arrays of sender and recipient data for the last 90 days. After fetching the set of user mailboxes in the tenant, we loop through each mailbox to calculate the total number of messages sent and received. Because we focus solely on messages sent and received by user mailboxes, this approach excludes any system-generated traffic.

$StartDate = (Get-Date).AddDays(-92); $EndDate = (Get-Date).AddDays(+1)
[array]$SenderData = Get-MailTrafficSummaryReport -Category TopMailSender -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2 
[array]$RecipientData = Get-MailTrafficSummaryReport -Category TopMailRecipient -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2 
$MbxReport = [System.Collections.Generic.List[Object]]::new()

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
ForEach ($M in $Mbx) {
Write-Host "Processing" $M.DisplayName   
# Check each email proxy address to see if it was used to send email
[int]$TotalSentMessages = 0 ; [int]$Messages = 0
ForEach ($A in $M.EmailAddresses) {
      If ($A.Substring(0,4) -eq "smtp") {
         $Messages = $SenderData | ? {$_.C1 -eq $A.Split(":")[1] } | Select -ExpandProperty C2
         # Write-Host "Messages found for" $A " " $Messages
         $TotalSentMessages = ($TotalSentMessages + $Messages) }
}
# Check each email proxy address to see if it was used to receive email
[int]$TotalReceivedMessages = 0 ; [int]$Messages = 0
ForEach ($A in $M.EmailAddresses) {
      If ($A.Substring(0,4) -eq "smtp") {
         $Messages = $RecipientData | ? {$_.C1 -eq $A.Split(":")[1] } | Select -ExpandProperty C2
         Write-Host "Messages found for" $A " " $Messages
         $TotalReceivedMessages = ($TotalReceivedMessages + $Messages) }
}
     $ReportLine = [PSCustomObject] @{
        User                = $M.DisplayName
        Address             = $M.UserPrincipalName
        "Sent messages"     = $TotalSentMessages
        "Received messages" = $TotalReceivedMessages }    
      $MbxReport.Add($ReportLine) 
}
$MbxReport | Out-GridView

Figure 2 shows the output from the script. You can download a copy of the script from the Office 365 for IT Pros GitHub repository.

The Modern Usage Reporting Option

I imagine that the customers who protested the removal of the Top Senders and Recipients report did so because they use the report. Well, a better mousetrap exists for reports about user activity: the Microsoft Graph Reports API. The most important reason why is that the Graph API is the focus for future Microsoft development. The old Office 365 data warehouse, used as the basis for the older Exchange-based usage cmdlets, will eventually disappear.

The Exchange usage report in the Microsoft 365 admin center (Figure 3) is the closest to the Top Senders and Recipients report. It’s not perfect (what do “receive actions” really mean in terms of the number of messages received by a mailbox?), but it’s a good start. The data doesn’t line up exactly with what’s reported in the Microsoft 365 Defender portal. Usually, the Graph-based data for messages sent and received comes in under the figures reported by the Microsoft 365 Defender portal, but I’m willing to put that down to inconsistencies in the Office 365 data warehouse. In any case, tracking data about user activities is like using a personal step counter. The data might vary from device to device depending on how a device accounts for factors like stride length, but once you use the same device on a consistent basis, you have something to compare progress against.

The usage reports in the Microsoft 365 admin center use the Graph API and support features like the deidentification of personal user information. They also support going back 180 days instead of 90 days, and because the reports use a fully supported API, you can write your own code to generate the type of usage reports you want. An example of this is the per-user activity report spanning multiple Microsoft 365 workloads (Exchange, SharePoint, OneDrive, Teams, and Yammer) written using a combination of PowerShell and Graph API calls.

Time to Switch from the Old Reports

If you’re one of the customers discommoded by Microsoft’s plan to retire the Top Senders and Recipients report, it’s time for you to consider looking at the replacements which already exist within Microsoft 365. The reports available in the admin center might be different, but the usage data is there. And if you don’t like what you see, consider investing some time to develop familiarity with the Microsoft Graph Reports API, maybe using PowerShell. The Graph is the future; the old reports will eventually disappear. Why stay fixed in the past when the future beckons?

We offer insights like this throughout the 24 chapters of the Office 365 for IT Pros eBook. It’s one of the reasons why our subscribers stay on top of new developments inside Office 365.

Questions About Clients, Addresses, and Support

Following last week’s very underplayed disclosure that Exchange Online supports sending email using any proxy address for a mailbox, some questions popped up in the various ways people communicate with me. Here are the most common questions with the best answers I can come up with.

Outlook Support for Send with a Proxy Address

OWA is explicitly mentioned in the Microsoft 365 roadmap item describing using proxy addresses to send email. Many asked when Outlook desktop will support the feature. The answer is “right now,” if you use a recent version (I tested the feature with Outlook version 2014 build 13929.20216).

Microsoft has done the heavy lifting to make Exchange Online understand how to deal with proxy addresses; some work is still to be done to upgrade OWA (first) and Outlook to allow users to select proxy addresses more easily, but the fact is that you can use any version of Outlook today. The trick is to expose the From field for a new message and populate the field with your preferred proxy address (Figure 1).

Sending Using a Proxy from Outlook Mobile

The Outlook mobile clients don’t currently support sending from a proxy address. Now that Exchange Online supports the feature, the hope is that Microsoft will allow Outlook mobile clients to expose the From field and support sending messages using a proxy address.

Send Using Proxy Address in Exchange On-premises?

Another common question is if support for sending email using proxy addresses will ever appear in Exchange Server? I don’t know the answer. On the surface, it seems like Microsoft has done the work to upgrade the Exchange transport service to deal with sending messages using proxy addresses and that it should be easy to transfer the code to Exchange Server. But software engineering is seldom as straightforward as people assume, and I don’t know if any dependencies exist which could stop Microsoft moving the code over. Exchange Server and Exchange Online used to share a common code bas, but not now. The code bases are different and who knows what work must be done to upgrade Exchange Server, including the GUI change to OWA.

In addition, what version of Exchange Server is the target? Exchange 2019, an earlier version, or the next version of Exchange Server due in the second half of 2021? A bet might win if placed on Exchange 2022 or whatever the new version is called, but I have doubts that Microsoft will bring the code to Exchange 2019 or earlier.

Using Proxy Addresses in Replies

Others asked if the proxy address is used for replies. The answer is yes. When you choose a proxy address for a new message, Exchange puts the address in the From and Return-Path message properties, meaning that any response to the message picks up and uses the proxy address. The inbound message with the proxy address is treated by Exchange like any other email and checked against the directory. Because the proxy address belongs to a mailbox, Exchange accepts the message and routes it to the mailbox. This is easily verified by sending a message using a proxy address and examining any response which comes back (the Outlook Message Header Analyzer add-in makes this easy to do). Figure 2 shows that the reply to the message I created in Figure 1 comes back to the specified address.

Although a response to a message sent using a proxy address will go back to that proxy address, the use of the proxy address is not maintained in subsequent replies in a thread. This is likely a client restriction that Microsoft will address when they upgrade clients to support send from proxy addresses fully. In the meantime, the workaround is to use the From field to choose the appropriate address when you respond to a message.

Can All Proxy Addresses Be Used?

I was asked if all proxy addresses available for a mailbox can be used to send email. The answer is that this is an SMTP feature so only SMTP proxy addresses are usable, including plus addresses (another question). In fact, you might note that I use a plus address in Figure 1.

As a recap, Microsoft added support for plus addressing to Exchange Online in August 2020. Newer tenants (created since September 2020) enable users to create their own plus addresses while older tenants need to enable the feature by running the Set-OrganizationConfig cmdlet:

Set-OrganizationConfig -AllowPlusAddressInRecipients $True

When AllowPlusAddressInRecipients is True, users can add whatever text string they want after a plus sign when they give an email address to companies or other people. In the example in Figure 1, I use Tony.Redmond+eCommerce@office365itpros.com. When the message arrives, Exchange trims the plus sign together with everything following and delivers the message to Tony.Redmond @office365itpros.com. Administrators can also assign a persistent plus address as a proxy address through EAC or PowerShell. For example:

Set-Mailbox -Identity Tony.Redmond -EmailAddresses @{add="Tony.Redmond+eCommerce@office365itpros.com"}

The advantage of having a persistent plus address which is part of the set of proxy addresses assigned to a mailbox is that it can then be used to send email.

Finding What Proxy Addresses Exist for User Mailboxes

Finally, someone asked how easy it is to discover what proxy addresses exist for mailboxes. You can examine the properties of individual mailboxes through the EAC or Microsoft 365 admin center, but that doesn’t work so well at scale. Instead, here’s some PowerShell to create a quick and dirty report for all user mailboxes and their proxy addresses.

$Report = [System.Collections.Generic.List[Object]]::new()
$Mbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox
ForEach ($M in $Mbx) {
    $DefaultEmailAddress = ($M.EmailAddresses | ? {$_ -cLike "SMTP:*"}).Split(":")[1]
    [array]$OtherEmailAddresses = $M.EmailAddresses | ? {$_ -cLike "smtp:*"}
    $Addresses = [System.Collections.Generic.List[Object]]::new()
    ForEach ($Address in $OtherEmailAddresses) {
        $ThisAddress = $Address.Split(":")[1] + " "
        $Address = [PSCustomObject][Ordered]@{  
            Address  = $ThisAddress.Trim() }
        $Addresses.Add($Address) 
    } # End Foreach $Address
    $Addresses = $Addresses.Address -join ", "
    If ($M.EmailAddresses -contains "SIP") {
        $SIPAddress = ($M.EmailAddresses | ? {$_ -cLike "SIP:*"}).Split(":")[1]}
    Else {$SIPAddress = "None"}
    $ReportLine = [PSCustomObject][Ordered]@{  
       User                   = $M.DisplayName 
       UPN                    = $M.UserPrincipalName 
      "Default Email Address" = $DefaultEmailAddress
      "Other Email Addresses" = $Addresses
      "SIP Address"           = $SIPAddress }
    $Report.Add($ReportLine) 
} #End ForEach $M
$Report | Out-GridView

The script reports its results via the Out-GridView cmdlet. You could easily amend it to export the results to a CSV file.

A Welcome Feature

Most of the people I have spoken to agree that allowing the use of proxy addresses to send email is a good thing. Many say that it’s odd that Microsoft hasn’t added the feature before but are glad that it is here now. I guess Exchange is sometimes like a large ocean liner – it takes time to make adjustments.

As I hear of other questions, I will update this post.

Need more information about how Exchange Online works inside Microsoft 365? The Office 365 for IT Pros eBook has the answers and because it’s updated monthly, we make sure that our subscribers know about important new features soon after Microsoft delivers the code.

Clearing Outlook Calendars

A member of the Microsoft Technical Community reported that a teacher’s calendar had become cluttered with events for classes. So much so that the number of events caused the Teams calendar app to crash. The request was for a way to clear calendar events for selected users for a set period. What a great opportunity for the Search-Mailbox cmdlet, my go-to tool for mailbox cleanups for many years.

The Exchange Online management PowerShell module includes the Remove-CalendarEvents cmdlet. Unfortunately, this cmdlet is forward-looking and can only cancel future meetings in someone’s calendar. It cannot remove old calendar events, which is the problem faced here.

The solution is to search the affected mailboxes to find calendar events and delete them. Microsoft has deprecated the old Search-Mailbox cmdlet, but it’s still available and can be used, even if Microsoft won’t support it. I’ve used Search-Mailbox many times to find and remove items from mailboxes, so it could solve this problem.

A Script to Remove Items from Mailboxes

The script written to do the job (downloadable from GitHub) is quite straightforward and involves the following steps:

1. Find the mailboxes to process. I use the Get-ExoMailbox cmdlet to look for mailboxes with a value in the CustomAttribute12 attribute. You could also use a CSV file to provide the input (if you do, make sure to include the UserPrincipalName and DisplayName of each mailbox. The important thing is to create a set of mailboxes to process. For instance, a simple Get-ExoMailbox -RecipientTypeDetails UserMailbox will find all user mailboxes to process.
2. Call the Search-Mailbox cmdlet to run an estimate search against each mailbox. An estimate search tells us how many items match the search query without doing anything else. The result of the query is logged.
3. Present the details of mailboxes with items matching the search and ask the user to proceed (Figure 1).
4. If affirmative, run Search-Mailbox again to remove the matching items. This stage is the longest to complete.

Obviously, by changing the search query and target set of users, the same script could be used to remove mailbox items in different circumstances, such as deleting malware.

Test Query Thoroughly

Remember that Search-Mailbox is what’s called a destructive cmdlet: it can and will remove mailbox items if told to do so. For this reason, it’s wise to test the search query that you plan to use to remove items from multiple mailboxes to make sure that it finds the correct items. Create a test mailbox and populate it with different types of meetings to ensure that the search query finds the right items. Or if you’re really brave (or stupid), test the search and deletion against your own mailbox.

The query used in this script looks for calendar meeting items between two dates with an exclusion for Teams call data records (CDRs), which will be found and removed if the query looks only for meeting items. It’s a simple query that could be expanded to check against other message properties, such as the sender of the meeting invitation.

Upgrading to use Content Searches

Even though the cmdlet works, Microsoft would prefer that you don’t use Search-Mailbox. That’s an understandable stance, so the next thing to do is to update the script to use content searches to find and remove mailbox items. That’s another day’s work because of the way that purge actions work for content searches. Where Search-Mailbox is happy to remove thousands of items from a mailbox, a content search is more restrained to make sure that a mistake in a search query doesn’t lead to a mass deletion in error.

The Search-Mailbox cmdlet is covered in the companion volume of the Office 365 for IT Pros eBook. We’ll keep that text until Microsoft finally removes this useful cmdlet from Exchange Online

New Information Surfaces All the Time

It’s amazing what is available online. When refreshing Chapter 20 of the Office 365 for IT Pros eBook, I found an interesting Microsoft article from 2018 about how to investigate partially indexed Exchange Online items and what this means for content searches.

Why Some Exchange Online Items Aren’t Fully Indexed

Microsoft 365 indexes items as they are added to workloads like Exchange Online, SharePoint Online, and OneDrive for Business and the compliance records generated for Teams and Yammer. The indexes are the foundation for content searches and eDiscovery cases.

Microsoft 365 encounters problems when indexing a percentage of items in a tenant for reasons like an unsupported format, their size, or an error occurs during indexing. For instance, indexing can only process Excel attachments if they are under 4 MB (this page says that the first 4 MB is indexed but the remainder is not), while indexable attachments for other file types can be up to 150 MB. And some files, like graphic and audio files, have metadata (document or email properties such as subject, creation date, author, etc.) but no indexable content. In the fun fact category, the maximum body size of an item in the index is 67 million characters (including up to 250 attachments).

Items which the indexer cannot fully process are referred to as partially indexed (their metadata is indexed, but their content is partially or not indexed). Content search results report these as unindexed items. For example, the search in Figure 1 shows that 3,928 items were found in a search returning 1,462,570 items, or around 0.27%.

Even if their content can’t be indexed, content searches do return partially indexed items if matches occur against their metadata. You can export the partially indexed items found by a content search to perform further analysis to determine if they are of interest to an investigation. Sometimes human beings can make more sense of unindexed items than computers can.

Analyzing Partially Indexed Items with PowerShell

The article about investigating the number and type of partially indexed Exchange Online items in a tenant includes a PowerShell script (PartiallyIndexedItems.ps1), which performs a content search for all items in all Exchange Online mailboxes (including user, group, and shared mailboxes). The output of the script is some summary data about the number and size of mailbox items and the ratio of partially indexed items. As you can see, the script reported 0.27% of items in my tenant are partially indexed (also the data reported in Figure 1). In terms of file size, the ratio is higher at 2.51%, which implies that most of the items are attachments.

===== Partially indexed items =====
         Total          Ratio
Count    1,462,570      0.27%
Size(GB) 95.35          2.51%

The next step is to report the reasons why items are partially indexed and the file type of those items. The script generates output like this:

===== Reasons for partially indexed items =====
attachmentrms
     => 25
parserencrypted
    encoffmetro => 24
    pdf => 5
    xls => 4
    zip => 2
parsererror
    doc => 7
    docm => 1
    docx => 32
    encoffmetro => 8
    gzip => 37
    json => 1
    pdf => 168
    png => 2
    pptx => 11
    xml => 5
    zip => 1
retrieverrms
     => 1797

Generating More Readable Output

I amended the script to produce more readable data that also can be exported to a CSV file (see below). The error text used here is my explanation of what caused partial indexing. As you can see, most of the issues are caused by messages protected by Office 365 Message Encryption (OME) or sensitivity labels, graphic files, and zipped files.

FileType                           Count ErrorText
--------                           ----- ---------
                                    1797 Rights Management Encrypted Item
PNG graphic file                     966 Parser encountered unsupported format
Unknown/no format                    529 Parser encountered unknown format
GZIP file                            320 Parser encountered unsupported format
PDF file                             168 Parser encountered an error
Password protected PowerPoint PPTX    90 Parser encountered unsupported format
GZIP file                             37 Parser encountered an error
Bitmap graphic file                   34 Parser encountered unsupported format
Word (DOCX) document                  32 Parser encountered an error
                                      25 Rights Management Encrypted Attachment
Password protected PowerPoint PPTX    24 Parser couldn't decrypt item
PDF file                              20 Parser encountered malformed item
ZIP file                              17 Parser error on output size

You can download a copy of the modified script from GitHub.

SharePoint Online and OneDrive for Business also have partially indexed items but seem to be less prone to the problem than Exchange Online is. This is due to the higher volume of individual items flowing through email and the wide spectrum of attachments accompanying messages.

Understanding the data which exists inside an Office 365 tenant is obviously a good thing to do. The script throws some insight into the complexities of indexing for high volumes of items of different types and might explain why searches don’t always return what you might expect.

Stop Forwarding Email Outside Exchange Online

There’s no doubt that automatically forwarding messages to an email address outside Office 365 can pose a significant risk for a business. Messages can end up in places where they shouldn’t go, including when an attack infiltrates an account and sets up forwarding on a mailbox by setting a mail forwarding address or with an inbox rule. In addition, removing email from Exchange Online compromises compliance and oversight because messages are no longer available for eDiscovery.

Various techniques exist to combat the problem, including:

• Restricting the ability of users to set forwarding addresses in OWA.
• Applying more general restrictions to block forwarding to specific domains.
• Blocking email forwarding from Power Automate (Flow).

These techniques work and all allow users to manually forward individual messages, but administrators must be aware of the problem caused by automatic forwarding and act to stop it. What’s different now is that Microsoft is making automatic forwarding more of an opt-in feature rather than forcing tenants to block automatic forwarding (roadmap item 63831) and make organizations more secure by default.

In some ways, it’s like the approach taken to disable basic authentication for Exchange connection protocols. Start by showing disapproval of something which contributes to insecure tenants and gradually escalate to close the hole.

Tuning Mail Forwarding in the Default Ant-Spam Outbound Filter Policy

A series of Office 365 notifications posted to the message center, starting with MC218984 (July) and more recently MC221113 (September), advised tenants of a change to the default outbound spam filter policy. The default outbound spam filter policy is present and active in all Exchange Online tenants.

First, Microsoft introduced automatic forwarding settings for anti-spam policies. The settings were inactive but allowed administrators to define how they wanted forwarding to happen. Tenants identified as having mailboxes with autoforwarding enabled also received notification that they had some work to do to decide how to handle these forwards. The next step was to enable the forwarding setting in the default anti-spam outbound policy using On as the Automatic (default) setting, meaning that mail forwarding acted as before.

This week, Microsoft changed the Automatic setting to Off to block mail forwarding. If you didn’t choose a different setting (possibly because you missed the notification), the Automatic setting is active. Some administrators overlooked the previous communications and were surprised when users began to report that forwarding doesn’t work. Life is full of surprises!

Mail Forwarding Settings

The available settings in anti-spam outbound policies to govern mail forwarding (Figure 1) are:

• Automatic: Exchange Online decides if mail forwarding is allowed or not. This is the default setting and normally means that users cannot forward email from Exchange Online mailboxes to external addresses.
• On: Users can forward email.
• Off: Users cannot forward email. Exchange will not change this value.
  

If automatic mail forwarding is blocked, users can still configure a mail forwarding address through OWA options (which is a good reason to remove the option from OWA) or create an inbox rule to redirect messages to an external address, but any attempt to send a message to that user which results in an attempted forward is rejected by the transport service and won’t be delivered. The sender receives an NDR to let them know about the problem (Figure 2).

The key thing for administrators to note is the NDR code: “5.7.520 Access denied. Your organization does not allow external forwarding.” Once you see this, you know a message was blocked by the outbound spam filter policy.

Allowing Automatic Forwarding for Specific Users

The default outbound spam policy is always active and cannot be disabled. If you want to stop mail forwarding in general and allow it for specific people, you should create a custom outbound spam filter policy and add the people and distribution lists to that policy. As you can see in Figure 3, SMTP addresses are used to specify people and distribution lists, not display names.

A Good Change to End a Bad Practice

There’s not much to argue about in this change. Automatically forwarding mail to an external address is not good practice. If someone really needs to forward email to an external address, they should be able to quantify the need in terms of a business justification to be added to a custom outbound spam filter policy. I doubt that many will be able to come up with such a justification, but those who do will be able to continue while the rest of the organization remains just a little bit safer.

Need to know more about the various policies used by Exchange Online to manage mail transport? It’s all described in the Office 365 for IT Pros eBook.

Send Email to Filtered Sets of Recipients

After explaining how to use a custom attribute to store users’ beverage of choice and surface that information in Office 365 apps through the Microsoft 365 profile card, the question came up if it is possible to create a dynamic distribution list using the same custom attribute. The answer is “absolutely!”

Dynamic distribution lists are a very powerful way of addressing specific sets of mail-enabled recipients. Table 1 compares their capabilities against those of dynamic Microsoft 365 groups.

Some on-premises Exchange organizations use thousands of dynamic distribution groups. Because of the presence of other methods to address sets of users like Microsoft 365 Groups and Teams in Office 365, dynamic distribution lists are not as heavily used. But as we’ll see, these lists are easily to create and use.

Filters Against the Directory

The core of both types of dynamic groups is the filter used to find objects in the source directory. The filters can be very complex when multiple attributes are involved, but in this case the filter needed to find users with a particular value in a custom attribute is straightforward. For example, to create a dynamic distribution list of mailboxes whose owners like beer, we can either use the Exchange admin center or run the New-DynamicDistributionGroup cmdlet:

New-DynamicDistributionGroup -Name DynamicBeer -DisplayName "Dynamic Beer Drinkers" -ConditionalCustomAttribute9 Beer -IncludedRecipients MailboxUsers -PrimarySmtpAddress Beer.Drinkers@office365itpros.com -Alias Beer.Drinkers

In this case, because we use CustomAttribute9 to hold the drink preference, we can use what’s called a “precanned” filter. In other words, Exchange knows that custom attributes are often used for filters, so the cmdlet supports an easy way to include these attributes in filters. The ConditionalCustomAttribute9 parameter is set to “Beer” and the IncludedRecipients parameter is set to MailboxUsers. Together, this creates a filter to find any user mailbox whose CustomAttribute9 is “Beer.”

If the attribute you want to use isn’t covered by a precanned filter, dynamic distribution lists can also use custom filters to find mail-enabled recipients. This is a little more complex because you must construct the filter instead of Exchange doing the job for you.

To complete the setup of the new dynamic distribution list, we use Set-DynamicDistributionGroup to define who is the list owner and create a mail tip to give an indication to users about the list’s purpose:

Set-DynamicDistributionGroup -Identity Beer.Drinkers -ManagedBy James.Joyce@Office365itpros.com -MailTip "Mailbox users who like beer"

Some judicious cut and pasting will quickly generate a set of dynamic distribution lists for people who like water, wine, cola, and so on.

Testing Recipient Filters

If you want to be sure that the filter created for a dynamic distribution list will locate the correct mailboxes, you can run the Get-Recipient cmdlet and input the recipient filter for the list. Here’s how:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity Beer.Drinkers).RecipientFilter | Select DisplayName

DisplayName
-----------
Kim Akers
Imran Khan
James Ryan

To have more mailboxes picked up by the filter, update their CustomAttribute9 with the value used by the filter. For example:

Set-Mailbox -Identity James.Joyce -CustomAttribute9 "Beer"

Using the List

Using the dynamic distribution list is as easy as using any distribution list. The notable difference from an end user perspective is that there’s no option to expand the list and reveal the individual members by adding them to the message header (Figure 1).

The list membership is evaluated each time a message addressed to the list passes through the Exchange transport service and messages for matching recipients are generated at that point.

We’re rather fond of dynamic distribution lists, so they are covered in the Office 365 for IT Pros eBook. It’s an Office 365 feature that hasn’t changed in years… but we still like it.

A Daily Task, Sometimes Overlooked

Checking the set of messages Exchange Online Protection (EOP) places in quarantine is not always a high-priority daily activity for most tenant administrators.. Opening the Security and Compliance Center to browse the set of quarantined messages (Figure 1) might be on the list of good things to do, but maybe also one of the tasks which is done when time and other tasks allow.

The point to remember is that some messages EOP quarantines are valuable. If you don’t rescue these messages within 15 days (the period set in the default spam filter policy), they disappear and will never be delivered, and that might be a bad thing.

User Notifications

One way to remove the burden on administrators is to configure the spam policy to generate end-user notifications. Users will then receive email according to a schedule set in the policy when spam or phish messages arrive for their account (Figure 2). The idea is that the user will know better than anyone whether a message is good or not. Unfortunately, without training and updates about recent spam techniques, this is not always the case, and some organizations disable the option because of the load it creates for the help desk.

Reviewing Quarantined Messages

If you examine the details of quarantined messages, you’ll discover why EOP considers them suspect. Each quarantined message is assigned a reason why EOP stopped its delivery to the destination mailbox(es):

• Bulk: EOP suspects that the message is commercial bulk email.
• Policy: The message matched the conditions of a transport rule (also known as a mail flow rule).
• Phish: EOP suspects the message to be a phishing attempt.
• High Confidence Phish: EOP has extra reasons to suspect the message to be a phishing attempt.
• Malware: EOP suspects the message to contain malware.
• Spam: EOP considers the message to be plain old spam. Regretfully, EOP sometimes thinks email from Gumroad.com is spam, which is why some of our subscribers don’t receive receipts or news about book updates.

Many factors combine and contribute to EOP deciding that a message is problematic. The sender or the sender domain could be a known spammer. The content of the message might contain clues (lots of hyperlinks is often deemed suspicious) or an attachment that might redirect the unwitting to a site. EOP uses tons of machine learning, artificial intelligence, and information gathered from around the internet to make the decision to quarantine. Most of the time EOP’s suspicions are well justified and accurate, and sometimes they fail, which is why it’s important for humans to review quarantined email.

Take the message shown in Figure 3. EOP regards the message to be potential phish. The sending domain is eliophot.com, a French marketing company specializing in the hospitality industry. This fact, allied to previewing the message and noting the return address as that of a valid hotel in the South of France, means that it’s likely this message is OK and has been blocked because of the number of hyperlinks in the text.

If we believe everything’s OK with the message, we can release it using the Release message button and EOP will deliver the message to the recipients. If you want to delete the message, click Remove from quarantine.

A More Complex Case

When I scan quarantined messages, my attention is always drawn to those marked as high confidence phish. As the name implies, these are messages that EOP considers to be very suspicious. And sometimes things conspire to throw EOP off the scent. Take the message shown in Figure 4, which is a notification sent from Amazon when someone signs into one of their services, like the Kindle Direct Publishing (KDP) service we use to create the Kindle version of the Office 365 for IT Pros eBook.

In this case, the message identifier tells us that the email came from Amazon’s Simple Email Service domain, which is what you’d expect. The sender address looks good too, and the preview shows the kind of content of the usual type in notification messages. On the surface, all checks out.

The problems lie in the message header, which contains DKIM (Domain Keys Identified Mail) and SPF (Sender Policy Framework) fails. In other words, EOP has tried to authenticate the source of the message as being valid for the purported sender and failed. You can argue if this should be enough to regard the message as high confidence phish, but remember that EOP considers other factors, such as the “click here” hyperlink in the message body.

The original recipient for this message was my outlook.com address. The message was forwarded from outlook.com to Office 365, and this might have caused the issues with DKIM and SPF. In any case, it’s a good example of why quarantined messages sometimes need careful examination before they can be released for delivery.

PowerShell Support

Exchange Online includes some PowerShell cmdlets to work with quarantined messages. For more information, read this post.

Learn more about EOP and Exchange Online mail flow in Chapter 7 of the Office 365 for IT Pros eBook.

Maybe Not Brain-Dead but Certainly Poor Thinking

Recently, the folks responsible for running the Microsoft Technical Community contacted me to say that someone was offended at a comment I made in a discussion about Office 365 backup. Apparently, the person didn’t like me saying (Figure 1):

“In this case, the backup product copies mail to PST files, which is just about the most brain-dead and stupid approach to backup of a cloud email solution known since the dawn of Office 365.”

The forum moderators removed the original note I replied to. It can be summarized as one of the almost Pavlovian responses from some working for ISVs who create backup software. As soon as a discussion starts in a forum about backup, they rush to talk about their product even when the product is wildly inappropriate.

In this case, the vendor representative advanced the case to use PSTs as a backup solution for Exchange Online mailboxes. I don’t regret calling this suggestion brain-dead and stupid because I honestly consider that anyone who thinks that backing up cloud-based mailboxes to personal files on workstations has lost their marbles.

Uses of PSTs

Despite all the flaws documented in PSTs over the years, these files continue to be used. Even Office 365 tolerates PSTs, but only for necessity when nothing else is available. PSTs can be used as an import source for mailboxes and to export the results of eDiscovery searches (typically for investigation and review by an external expert); aside from these uses, I can’t think of why I would even consider using a PST.

Using a PST for backup exports information from cloud mailboxes and creates potential compliance and retention issues for the company. The action could lead to loss of data to attackers, which is what happened to Sony in 2014. Users sometimes think that it’s a good idea to create their own personal mailbox archives in PSTs, but there’s really no reason to do this, especially with the large mailbox quotas available in Office 365 (the classic reason why people used PSTs was to remove old mail from their online mailbox).

Exchange Native Data Protection ensures that four copies of their mailbox exist in at least two Office 365 datacenters. An extra copy in a PST will only help if all those datacenters are offline. Even if this were to happen, the email in the PST might remain inaccessible if protected with sensitivity labels (which also make sure that people can’t take email with them to another employer).

No Room for Misleading Advocacy

To be fair to the ISVs who create PST-based backup solutions, a reasonable need existed for their products in the on-premises world at one time. Time and technology developments have passed them by and they’re struggling to maintain relevance in the cloud world. But that’s no reason to pollute discussion forums with wildly inappropriate advocacy for their products.

In saying this, I also note that some vendors of cloud backup products are guilty of the same tactics, especially those who represent backup for Exchange Online mailboxes as coverage for other parts of Office 365, notably Teams. Inaccurate and misleading assertions might lure the unwary into signing up for their products, but the reputation of the company and their software suffers overall.

No Perfect Office 365 Backup Solution

No perfect backup solution exists for Office 365. The interconnectivity of applications and lack of supported backup APIs for Office 365 workloads create a challenging environment for backup vendors. If you’re considering investing in a backup product, my advice is:

• Only consider cloud-based backup solutions.
• Understand what the standard features in Office 365 can do to identify where you need extra protection which can be provided by a backup product. Don’t accept what backup vendors say – test and verify their assertions yourself. I’m not saying that backup vendors deliberately misrepresent Office 365 functionality; some don’t seem to understand the technology as well as they should.
• Optional add-ons for Office 365 might be better solutions for some of the reasons often cited to justify backups. For instance, Privileged Access Management can mitigate the damage which a rogue administrator can inflict.
• Understand how backup products access information in Office 365 workloads to copy data to their repositories. Remember that the quantity of cloud data is often larger than is kept in on-premises deployments.
• Understand how the products deal with cloud-only applications like Teams, Yammer, and Planner and how they deal with protected (encrypted) items.
• Understand how restore operations work, including the restoration of complete Microsoft 365 Groups.

Equipped with answers to these questions, you’ll be able to make an informed choice if you need backups for your Office 365 tenant and if so, the best backup software to meet your needs.

And never ever consider using PSTs as a backup mechanism for Exchange Online mailboxes…

Exchange Online Isn’t for Bulk Email

Microsoft makes it quite clear that Exchange Online is not a platform for mass mailing. Limits exist to stop people who want to send bulk mail (spam) or whose mailboxes are taken over by malware. Essentially, even though Microsoft recently increased the maximum recipient limit for a message from 500 to 1,000, it doesn’t mean that you should switch mass mailings to Exchange Online from commercial mailing platforms like Mailchimp.

Most of the time, my mailbox never comes to the attention of Exchange Online Protection and the monitoring tools that look for evidence of misuse. I usually don’t send enough email to ever run into the limits. But occasionally, I need to send messages to reasonably large distribution lists (200 to 600 members). I was curious to discover at what point Exchange Online clamped down.

Sender Limits

The documented limit for accounts holding Office 365 E3 or E5 licenses is 10,000 recipients per day. A distribution list managed by the tenant (not a personal list) counts as a single recipient. Controlling mailboxes by measuring the number of messages they send is a crude control mechanism. Exchange Online Protection applies more intelligent algorithms to pick up unusual activity which might be a sign that something’s going on. The settings used by Microsoft to detect problematic senders are undocumented (as you’d expect), but you can force Exchange Online Protection to take an interest in your sending activity.

For instance, if someone who typically send 10-15 messages daily suddenly sends 200 messages over a short period or suddenly starts to send messages to large distribution lists, it might be that they’ve been told to get a message out about something like a new price list to customers. A one-off event isn’t enough to create suspicion, but other signs might exist to increase confidence that something’s wrong. An example is that because hyperlinks can lead the unwary into bad places, messages containing links are more suspect than those with plain text.

A single spike in traffic from a mailbox probably isn’t serious, but if the observed behavior of the mailbox over time deviates significantly from its expected norm, then the account might be compromised, and action is necessary. To ensure that a potentially-compromised account can’t be used to send spam or malware, Exchange Online Protection restricts (blocks) the mailbox. This means that the user is permitted to send messages to internal recipients but not to external recipients, including mail contacts and guest users registered in the tenant directory.

The Block Descends

I tested the theory by sending some messages containing hyperlinks to distribution lists over the course of a working day. Sure enough, after sending messages to circa 2,500 recipients spread across several distribution lists, Exchange Online Protection decided enough was enough and blocked my mailbox. When it imposes a block, Exchange Online generates NDRs (Figure 1) for every external message the user tries to send. The text of the message is:

“Your message couldn’t be delivered because you weren’t recognized as a valid sender. The most common reason for this is that your email address is suspected of sending spam and it’s no longer allowed to send email. Contact your email admin for assistance. Remote Server returned ‘550 5.1.8 Access denied, bad outbound sender.”

In addition, tenant administrators receive a notification about the blocked user. A HygieneEvent Office 365 audit event is logged to record the blocking and an AlertEntityGenerated event logged for the alert which generates the notification to administrators. “User restricted from sending email” is one of the standard alert policies created by Office 365 to alert administrators about problems in the tenant.

Unblocking Accounts

To investigate and unblock restricted accounts, an administrator goes to the Restricted Users section of the Security and Compliance Center to check the current list of blocked users (Figure 2). In this case, an account (mine) is restricted because Exchange Online Protection observed a high percentage (20.75%) of suspicious messages over the last 24 hours.

total for outbound messages is noted as 36. The two figures don’t quite make sense; 747 divided by 36 is 20.75, which is the percentage of spam reported. Microsoft needs to do some work to clarify the reported data and make it more precise.

Unblocking in PowerShell

As expected, the underlying Get-BlockedSenderAddress cmdlet doesn’t help much either. The message trace identifier reported here doesn’t work with the Get-MessageTrace cmdlet.

Get-BlockedSenderAddress | Format-List SenderAddress, Reason

SenderAddress: TONY.REDMOND@OFFICE365ITPROS.COM
Reason: OutboundSpamLast24Hours=747;OutboundMailLast24Hours=36;OutboundSpamPercent=2075;Last Spam Message MessagetraceId:b2223b2d-469d-440c-b409-08d82a588f0e;AS:1135

If you recognize a blocked account and know that it shouldn’t be blocked, you can release the account using the Microsoft Purview Compliance portal or with PowerShell. Here’s how to do it with the Remove-BlockedSenderAddress cmdlet:

Remove-BlockedSenderAddress -SenderAddress Tony.Redmond@Office365itpros.com -Reason "No problem with this account"

I can’t find an audit event logged when an account is unblocked. An unblocked account can’t send messages immediately as mail servers which handle outbound messages must be updated about the block being released. Updating all servers can take up to an hour.

Blocking is Unusual

Dealing with blocked accounts should be an unusual incident. Mailboxes must exhibit some out-of-course behavior before Exchange Online Protection regards them as potentially compromised or a source of spam. And if a block descends, the question is if the account is compromised or it’s because of some unusual email activity on the part of its owner. And that’s where the administrator earns their pay keeping their tenant safe.

We try to discover where limits are in Office 365 and how the limits are implemented so that you don’t find the limits in production. Or at least, if you do, you know what to do next. All documented in the Office 365 for IT Pros eBook.

Automated Lifting of Throttling Restrictions

Microsoft recently made an interesting change to the automated support handling capabilities of the Microsoft 365 admin center to handle requests for Exchange Web Services (EWS) throttling to be lifted for up to 90 days without human intervention.

Migrations from other platforms often use EWS to move information to Exchange Online mailboxes. When large amounts of data flow from the other platform, EWS throttling is likely to be imposed to conserve resources. It was always possible in the past to create a support request to ask Microsoft to lift throttling for EWS temporarily to allow migrations to proceed and Microsoft would invariably grant the request. Now, tenants can request throttling to be lifted through a simple automated process. Here’s how:

• Go to the Help (?) section of the Microsoft 365 admin center.
• Click the Need Help icon.
• Enter “EWS throttling” as the search phrase.
• Click Run tests when asked to check your environment (Figure 1). Essentially, the tests check what EWS throttling applies to the tenant.

• The support assistant checks the tenant settings and concludes that EWS is throttled (the normal situation). You’ll then be offered the chance to update the settings to the tenant EWS policy to lift throttling for 30, 60, or 90 days.
• Select the number of days you’d like to adjust the policy for and then Update Settings (Figure 2).
• After a short delay, the support assistant should confirm that the settings have been changed.

The new setting will be effective for the tenant in about 15 minutes and you should then be able to start migration transfers at full speed.

The Support Assistant is only able to automatically lift throttling for EWS-based migrations. It can’t deal with migrations based on other protocols, such as IMAP4 (like migrations from Gmail).

Understanding Events in Audit Log the First Step

Generating a report about some aspect of Office 365 is all very well, but it doesn’t lead to much unless there’s some action that can be easily taken due to the reported data. Take the report on Exchange Online SendAs and other permissions. It’s nice to know which accounts hold permissions over different mailboxes, but what will you do with that information?

In a small tenant, it might be easy to review the data and identify problems, like someone keeping Send As permission for a shared mailbox long past the time when their job mandates this access. In a medium to large tenant, you can slice and dice the report data to highlight issues, but it’s a lot harder to pinpoint definite problems.

Using Technology to Highlight Items

Microsoft is adding a lot of machine learning and artificial intelligence to Office 365 at present. Taking that as a hint, we can use technology to help filter the report data and identify the accounts to focus on. And best of all, this is easy to do in PowerShell.

The output from the script is a CSV file listing all the Send As, Full Access, and Send On Behalf Of permissions assigned to accounts. The first step is to read in the data from the CSV file, filtering items so that only SendAs records are loaded into an array.

Grabbing Data from the Office 365 Audit Log

The next step is to find a way to check each SendAs assignment against usage. The easiest way I know is to search the Office 365 audit log for SendAs events. Data is kept for 90 days for Office 365 E3 accounts (but only if their mailboxes are enabled). Data is kept for 365 days if an account has an Office 365 E5 license. Either way, I think 90 days is enough on the basis that if someone hasn’t used their right to impersonate another user or shared mailbox to send email in the last three months, maybe they don’t need that permission and it can be removed.

We can collect the SendAs events for the last 90 days by running the Search-UnifiedAuditLog cmdlet, unpacking the AuditData content in each audit event, and storing the data. Fortunately, we already have a script to do the job, which stores its output in another CSV file.

Comparing Audit Data with Permissions

A few lines of code later, we have the SendAs audit events loaded and we’re ready to start checking. The basic idea is to go through the assignments and check each against the audit data to see if the permission has been used. If it has, we store some usage details (last time and number of uses), and if it hasn’t, we note that fact too.

Hey Presto! After running through the permissions, we have a filtered list of accounts who haven’t used their assigned Send As permissions in the last three months and another set who have. You can review the assignments by piping the analyzed data to Out-GridView (Figure 1) or use the output CSV file for further processing.

You can pick up a copy of the script to analyze and filter SendAs records from GitHub. Remember that you need the other scripts to fetch SendAs records from the Office 365 audit log and report mailbox permissions to provide the two inputs.

Humans Decide Next Step

At this point, the script finishes and it’s up to the tenant administrators to decide what to do about the defunct permissions. Perhaps you want to send a polite email to users to tell them that you plan to remove the permission in a week’s time, or maybe you just go ahead and remove the permission on the basis that if anyone misses it, they’ll scream.

This is a great example of how to put together PowerShell scripts as building blocks for a solution. The code isn’t all that complex. It’s simply a matter of knowing where to find the data and how to use it. Isn’t that always the case?

One Script to Report all Mailbox-Level Permissions

Shortly after publishing Reporting Exchange Online Mailbox Permissions, I received two notes. One was from Vasil Michev to say that I should have used the REST-based cmdlets from the Exchange Online Management module. The other was a reply to my note in the Microsoft Technical Community to point me to some script snippets covering “the other” mailbox-level permissions that you might assign over mailboxes. These are the Send As and the Send on Behalf Of permissions.

The snippets were just that: bits of code. These bits are valuable because the nature of PowerShell and the way the community works is that you can always (try to) improve what’s gone before. As it happens, I found much the same code in examples in my Exchange Inside Out 2010 book (still available from Amazon). In any case, the point was that knowing all about FullAccess permissions assigned to users is all very well, but to get a full perspective of the permissions set on mailboxes, you should include details of the sending permissions as well.

Three Exchange Online Cmdlets Needed

It would be nice if Exchange returned all mailbox permissions with a single cmdlet, but three are needed:

• Get-ExoMailbox/Get-Mailbox: Returns a list of users with the right to Send as Behalf Of for a mailbox.
• Get-ExoMailboxPermission/Get-MailboxPermission: Returns permissions granted on the mailbox, like FullAccess.
• Get-ExoRecipientPermission/Get-RecipientPermission: Returns a list of users with SendAs permission for the mailbox.

The script uses the REST-based cmdlets but it’s easy to convert the calls to use the older Remote PowerShell cmdlets if you prefer.

The reasons why three cmdlets are needed are hidden in the mists of time and go back to the first implementation of PowerShell in Exchange 2007. The situation is unlikely to change now.

The Combined Script

The script is shown below. It’s a modified version of the previous script and you’ll need to connect to the Exchange Online Management module with an administrator account to run it. You can also download a copy from GitHub.

# ReportMailboxSendPermissionsMailboxes.PS1
# Quick and simple script to generate a report of non-standard permissions applied to Exchange Online user and shared mailboxes
# Needs to be connected to Exchange Online PowerShell with an administrative account to run
# V1.0 16-Mar-2020
# https://github.com/12Knocksinna/Office365itpros/blob/master/ReportMailboxSendPermissionsMailboxes.PS1
CLS
Write-Host "Fetching mailboxes"
$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, SharedMailbox -ResultSize Unlimited -PropertySet Delivery -Properties RecipientTypeDetails, DisplayName | Select DisplayName, UserPrincipalName, RecipientTypeDetails, GrantSendOnBehalfTo
If ($Mbx.Count -eq 0) { Write-Error "No mailboxes found. Script exiting..." -ErrorAction Stop } 
CLS
$Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
$ProgressDelta = 100/($Mbx.count); $PercentComplete = 0; $MbxNumber = 0
ForEach ($M in $Mbx) {
    $MbxNumber++
    $MbxStatus = $M.DisplayName + " ["+ $MbxNumber +"/" + $Mbx.Count + "]"
    Write-Progress -Activity "Checking permissions for mailbox" -Status $MbxStatus -PercentComplete $PercentComplete
    $PercentComplete += $ProgressDelta
    $Permissions = Get-ExoRecipientPermission -Identity $M.UserPrincipalName | ? {$_.Trustee -ne "NT AUTHORITY\SELF"}
    If ($Null -ne $Permissions) {
    # Grab information about SendAs permission and output it into the report
       ForEach ($Permission in $Permissions) {
       $ReportLine  = [PSCustomObject] @{
           Mailbox     = $M.DisplayName
           UPN         = $M.UserPrincipalName
           Permission  = $Permission | Select -ExpandProperty AccessRights
           AssignedTo  = $Permission.Trustee
           MailboxType = $M.RecipientTypeDetails } 
         $Report.Add($ReportLine) }}

    # Grab information about FullAccess permissions
    $Permissions = Get-ExoMailboxPermission -Identity $M.UserPrincipalName | ? {$_.User -Like "*@*" }    
    If ($Null -ne $Permissions) {
       # Grab each permission and output it into the report
       ForEach ($Permission in $Permissions) {
         $ReportLine  = [PSCustomObject] @{
           Mailbox     = $M.DisplayName
           UPN         = $M.UserPrincipalName
           Permission  = $Permission | Select -ExpandProperty AccessRights
           AssignedTo  = $Permission.User
           MailboxType = $M.RecipientTypeDetails } 
         $Report.Add($ReportLine) }} 

    # Check if this mailbox has granted Send on Behalf of permission to anyone
    If (![string]::IsNullOrEmpty($M.GrantSendOnBehalfTo)) {
       ForEach ($Permission in $M.GrantSendOnBehalfTo) {
       $ReportLine  = [PSCustomObject] @{
           Mailbox     = $M.DisplayName
           UPN         = $M.UserPrincipalName
           Permission  = "Send on Behalf Of"
           AssignedTo  = (Get-ExoRecipient -Identity $Permission).PrimarySmtpAddress
           MailboxType = $M.RecipientTypeDetails } 
         $Report.Add($ReportLine) }}
}

$Report | Sort -Property @{Expression = {$_.MailboxType}; Ascending= $False}, Mailbox | Export-CSV c:\temp\MailboxAccessPermissions.csv -NoTypeInformation
Write-Host "All done." $Mbx.Count "mailboxes scanned. Report of send permissions available in c:\temp\MailboxAccessPermissions.csv"

The output is a CSV file sorted by mailbox type (user mailboxes then shared mailboxes) and mailbox name. You can also pipe the output to Out-GridView (Figure 2) to quickly sort and review the results.

A Note About Get-ExoMailbox

The call to Get-ExoMailbox is a good example of how you need to pay attention to upgrading scripts from the older Get-Mailbox cmdlet. Get-ExoMailbox speeds access to data fetched from Exchange Online by forcing coders to specify the properties that they need to process. In this case, we need the Delivery property set (to access the GrantSendOnBehalfTo property) as well as the DisplayName and RecipientTypeDetails properties, which are specified individually.

As always, feel free to customize the script code to your heart’s content. Happy scripting!

Exchange Online is a well-known product at this point. Even so, a new development can throw up something that you don’t know about, just like the property sets used by the EXO cmdlets. Stay current by subscribing to the Office 365 for IT Pros eBook and let us do the heavy lifting of staying updated.

Delegate Access and Mailbox Permissions Bring Us to Folder Permissions

Two recent posts about Outlook Mobile supporting delegate access to Exchange Online mailboxes and reporting mailbox permissions bring us to the topic of folder permissions. Outlook Mobile uses full access permission to access delegate mailboxes and the report captures this information. But Exchange Online has supported folder-level permissions for many years (here’s a 2006 blog based on Exchange 2003 SP2) and it’s common to find these permissions in use, especially with Outlook desktop.

Outlook Delegate Access

Folder-level permissions have been core to Outlook’s ability to satisfy the traditional manager-assistant work model where the assistant takes care of the manager’s inbox and calendar. This capability is still supported and documented today for Outlook ProPlus and Outlook 2019.

The option to assign delegate access to mailbox folders in Outlook ProPlus is in the backstage area (Figure 1). Alternatively, you can search for “delegates” and Outlook will find it for you.

Setting Outlook Delegate Permissions

Figure 2 shows delegates (left – none are listed because I’m in the process of assigning one) and folder permissions (right). In this case, I’ve selected a user to act as a delegate and chosen the permissions I wanted to assign. When ready, click OK to save the delegated permissions.

When someone assigns folder permissions to a delegate, Exchange Online creates and sends an automatic notification to the delegate to inform them that they can now open the folders (Figure 3).

The support article emphasizes that you should grant Folder visible permission on the root folder of the your mailbox to delegates. This is especially important if the delegate wants to access the delegated folders as shared folders in OWA. In Outlook, delegates should add the mailbox to their profile.

Steps to Script a Folder-Level Access Report

Just like it’s good advice to run a periodic check of mailbox permissions, it’s good to validate that everyone who is assigned permission over folders outside their own mailbox still need that permission. Exchange Online doesn’t come with a report to tell us what folder permissions are in place, so we need to do this with PowerShell.

The Get-MailboxPermission cmdlet fetches permissions for a mailbox. Its counterpart, Get-MailboxFolderPermission, does the same for a folder. Conceptually, the steps to create a report are straightforward:

• Find a set of mailboxes to check.
• Find the folders in each mailbox to check. Exchange Online mailboxes often hold hundreds of folders. We only need to check folders that are commonly delegated, like the Inbox, Sent Items, and Calendar.
• Fetch the permissions for each folder and extract delegated assignments to users who aren’t the mailbox owner.
• Report any delegated access to the selected folders.

You could use the Get-Mailbox, Get-MailboxFolderStatistics, and Get-MailboxFolderPermission cmdlets to create the report. To be a little different, I used the new REST cmdlets because an equivalent is available for each of the three cmdlets listed above (Get-ExoMailbox, Get-ExoMailboxFolderStatistics, and Get-ExoMailboxFolderPermission).

Differences in REST Cmdlets

Using the REST cmdlets means that things run faster, especially when you’re dealing with hundreds or thousands of mailboxes. This is important, especially when the cmdlets are all quite demanding in terms of system resources.

It’s also true that the Exchange Online Management module (which holds these cmdlets) is easier to use with modern authentication, which helps the transition away from basic authentication. Remote PowerShell will no longer support basic auth connections after October 13, 2020.

The downside is that sometimes the REST cmdlets return data in different formats to their Remote PowerShell counterparts. For example, after retrieving permissions for a folder with Get-MailboxFolderPermission, you might want to fetch the name of the delegated user. If the variable $Permission holds the retrieved permission, the name of the user is available as $Permission.User.DisplayName, but it’s $Permission.User with Get-ExoMailboxPermission. It’s the detail that counts when you move from one set of cmdlets to another!

CSV Output

You can grab a copy of the script from GitHub. Its output is a CSV file (Figure 4) that might reveal some interesting delegations. For instance, I found an entry for a user (Michael Harty) that no longer exists in my tenant.

Outlook Mobile to Support Folder-Level Permissions

Microsoft says that Outlook Mobile will support folder-level permissions in the future to remove the need to grant complete access to everything in a delegate mailbox. This is a good step forward that will be welcome by those who don’t really want to expose everything they have just to let someone else manage part of their email.

Using PowerShell like this proves that it’s a great skill for any Office 365 administrator to have. You can find out a lot more about using PowerShell to manage Office 365 in the Office 365 for IT Pros eBook. Join our happy band of subscribers today!

Make Sure The Right People Access Your Exchange Online Mailboxes

One of the recommendations made in the Office 365 for IT Pros eBook is that tenant administrators should conduct periodic reviews of permissions assigned to mailboxes to ensure that the right people (other than the mailbox owners) have access, perhaps by creating an Exchange Online mailbox permissions report. A recent request in the Microsoft Technical Community prompted me to look at the situation again to make sure that our advice was still accurate (it is).

Scripting a Report

I responded to the original question with some quick and dirty PowerShell but decided that a better job could be done. If you use the Get-MailboxPermission cmdlet to examine permissions on an Exchange Online mailbox, several types exist:

• The mailbox owner (if you’re unsure, run Get-MailboxPermission with the -Owner parameter to see this entry).
• Permissions needed by Exchange Online to access the mailbox for different purposes, such as removing items during retention policy processing. These entries appear like EXOForest\Organization Management, where “EXOForest” is the name of the Exchange Online forest hosting the mailbox.
• An entry for “JitUsers” (Just in time access) assigned to Microsoft support personnel when they need access to the mailbox.
• System entries like NT AUTHORITY\System and NT AUTHORITY\NETWORK SERVICE.

For the purpose of this exercise we don’t care about these permissions because they exist on all mailboxes. What we’re looking for are delegated permissions used to grant non-owner accounts access to the mailbox. Vasil Michev, our esteemed technical editor, has a script in the TechNet Gallery to report non-standard permissions, but there’s always room for another PowerShell answer to a problem.

My script (the full version of the Exchange Online mailbox permissions report is available on GitHub) selects user and shared mailboxes (those most likely to have extra permissions). For each mailbox, we extract the permissions and look for those assigned to other Office 365 accounts. We store details of these permissions into a list that is written out to a CSV file after all mailboxes are processed. Here’s the basic idea:

# Quick and simple script to generate a report of non-standard permissions applied to Exchange Online user and shared mailboxes
# Needs to be connected to Exchange Online PowerShell with an administrative account to run
CLS
Write-Host "Fetching mailboxes"
[array]$Mbx = Get-Mailbox -RecipientTypeDetails UserMailbox, SharedMailbox -ResultSize Unlimited | Select DisplayName, UserPrincipalName, RecipientTypeDetails
If ($Mbx.Count -eq 0) { Write-Error "No mailboxes found. Script exiting..." -ErrorAction Stop } 
# We have some mailboxes, so we can process them...
CLS
$Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
$ProgressDelta = 100/($Mbx.count); $PercentComplete = 0; $MbxNumber = 0
ForEach ($M in $Mbx) {
    $MbxNumber++
    $MbxStatus = $M.DisplayName + " ["+ $MbxNumber +"/" + $Mbx.Count + "]"
    Write-Progress -Activity "Processing mailbox" -Status $MbxStatus -PercentComplete $PercentComplete
    $PercentComplete += $ProgressDelta
    $Permissions = Get-MailboxPermission -Identity $M.UserPrincipalName | ? {$_.User -Like "*@*" }    
    If ($Null -ne $Permissions) {
       # Grab each permission and output it into the report
       ForEach ($Permission in $Permissions) {
         $ReportLine  = [PSCustomObject] @{
           Mailbox    = $M.DisplayName
           UPN        = $M.UserPrincipalName
           Permission = $Permission | Select -ExpandProperty AccessRights
           AssignedTo = $Permission.User
           MailboxType = $M.RecipientTypeDetails } 
         $Report.Add($ReportLine) }
     } 
}     
$Report | Sort -Property @{Expression = {$_.MailboxType}; Ascending= $False}, Mailbox | Export-CSV c:\temp\MailboxPermissions.csv -NoTypeInformation
Write-Host "All done." $Mbx.Count "mailboxes scanned. Report of non-standard permissions available in c:\temp\MailboxPermissions.csv"

The CSV file is stored by user mailbox and then shared mailbox (you must use a calculated expression to sort by multiple properties when the first property is sorted in descending order).

Note: The full Exchange Online mailbox permissions report script uses the REST-based cmdlets in the Exchange Online Management module.

Reviewing the Results

As you can see from Figure 1, the Exchange Online mailbox permissions report details FullAccess and SendAs permissions assigned to mailboxes. The fact that these permissions exist isn’t an issue by itself as the permissions are usually well-justified. For instance, FullAccess permission is needed by delegates to have full control over a shared or user mailbox (as in the case of Outlook Mobile delegation). However, it’s important to review each assignment to understand if it is still valid and necessary. If not, the permission should be removed.

The Exchange Online mailbox permissions report doesn’t include folder-level permissions assigned by Outlook. These permissions can be reviewed with the Get-MailboxFolderPermission cmdlet. To find all such permissions for a mailbox, you would need to run Get-MailboxFolderStatistics to generate a list of mailbox folders and then check each folder to see if any permissions exist. I’ll cover how to do this in a future post.

For many more examples of using PowerShell to manage Exchange Online and other Office 365 components, subscribe to the Office 365 for IT Pros eBook and find some hidden jewels.

Exchange Online Mailbox Auditing for All

Updated 10 September 2023

When Microsoft announced in March 2019 that they had enabled mailbox auditing by default for Exchange Online, it seemed to be a good news story. Busy Office 365 administrators would no longer have to enable auditing for new mailboxes to have mailbox audit events flow into the Office 365 audit log (also known as the unified audit log). The announcement told tenants they could “search and retrieve your audit data with Search-MailboxAuditLog.” This was a little strange as the cmdlet searches mailboxes and not the audit log, but it seemed like a glitch and not a problem. All was well.

The logic for enabling mailbox auditing by default is undeniable. In July 2018, when Microsoft announced the plan to enable mailbox auditing by default, they said: “Mailboxes generating audit records can be found in the Security & Compliance Center’s Audit Log interface, or in the mailbox audit log through the Search-MailboxAuditLog cmdlet.” Given that both interfaces access the Office 365 audit log, the only reasonable interpretation was that Exchange Online would transmit mailbox audit events to the Office 365 audit log.

Office 365 E5 Events Flow, E3 Not So Much

As it turns out, this only happens if mailboxes have Office 365 E5 licenses. Mailboxes with Office 365 E3 licenses can have their events sent to the Office 365 audit log, but only if the mailboxes are explicitly enabled by running Set-Mailbox to set the AuditEnabled property to $True. With mailbox auditing enabled by default, brand-new E3 mailboxes report AuditEnabled to be $True. No indication exists that anything else must be done before audit events flow from these mailboxes to the Office 365 audit log.

It’s quite a bizarre situation. In Figure 1, we’re working with a newly-created mailbox. Because mailbox auditing is enabled by default, when Get-Mailbox queries its audit properties, Exchange reports that AuditEnabled is True and the default audit set is present. If you run Set-Mailbox to disable auditing, PowerShell reports that “no settings have been modified.” That’s strange because we just updated AuditEnabled from True to False…

Looking for Exchange Online Mailbox Audit Events

I discovered the problem when I started to look for MailItemsAccessed events. These “crucial events” capture access to mailbox items. They are recorded when accounts have specific licenses (see below). I found that some records were captured for some accounts and not for others, which caused me to look at mailbox data captured in the audit log more closely.

Although mailbox auditing is enabled by default for my tenant and all mailboxes have the default audit configuration, I found that records existed for some accounts and not for others. For instance, when testing Outlook mobile’s support for delegate access, when the SendAs permission was used to send messages for one mailbox, an audit record turned up in the audit log, but not when SendAs was used for other mailboxes. So I went looking to find out why.

The Documentation Says…

On February 20, I read the documentation for mailbox auditing and found: “By default, only mailbox audit events for E5 users are available in audit log searches in the Security & Compliance Center.” This seemed incorrect to me because I could clearly see events for E3 users in audit log searches. I pointed this out to Microsoft, who subsequently amended the text to read “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 Security & Compliance Center or via the Office 365 Management Activity API by default.” (Microsoft emphasis).

Update: Following the publication of this article, Microsoft updated its documentation to explain how to manually enable Exchange Online mailboxes with E3 licenses to have their events uploaded to the Office 365 audit log.

I’m reasonably experienced with Exchange. I know something about Office 365 too, and I have conducted many searches of the audit log. Yet nowhere did I ever see the advice that: “You can use audit log searches in the Security & Compliance Center or via the Office 365 Management Activity API after you’ve manually enabled mailbox auditing on the individual mailboxes.”

The Real Situation

To be charitable, Microsoft’s documentation is still confusing. The situation is:

• Mailbox audit events for Office 365 E5 accounts are always transmitted from Exchange Online to the Office 365 audit log (including the new MailItemsAccessed event, which only appear in E5 accounts). The same is true if the accounts have Microsoft 365 E5 licenses or Microsoft 365 E3 with the Compliance-add-on.
• Mailbox audit events for Office 365 E3 accounts are not transmitted by Exchange Online even when mailbox auditing is enabled by default. You can force Exchange Online to transmit the events by running Set-Mailbox to set AuditEnabled to $True for E3 mailboxes.
• Events will be in the Office 365 audit log for E3 mailboxes enabled prior to the introduction of mailbox auditing by default or if you manually enabled E3 mailboxes for auditing since.

In effect, the goodness of having mailbox auditing enabled by default has been stripped away because admins still need to take action to ensure audit capture of mailbox events. The situation isn’t helped by the way that Exchange Online uses the AuditEnabled property to report the audit status for mailboxes. This property should clearly show when audit events are being sent to the Office 365 audit log.

A cynic might say that the perspective expressed in Microsoft’s documentation is almost Jesuitical in its nit-picking. Yes, E3 mailboxes are enabled, but only for storing audit records in the mailboxes. If you want Exchange to move audit records from those E3 mailboxes to the audit log, you must enable them again.

No Data Loss for Audit Events

Mailbox audit events for Office 365 E3 accounts are not lost. They remain stored in the Audits sub-folder of Recoverable Items in the mailbox and can be found there using the Search-MailboxAuditLog cmdlet. They just don’t go through the ingestion process to become events in the Office 365 audit log.

Enable Exchange Online Mailboxes Again

If you want Exchange Online to send mailbox audit events for all mailboxes to the Office 365 audit log, you must make sure that E3 mailboxes are manually enabled. Because you can’t depend on the AuditEnabled property to tell you when events for a mailbox will get to the audit log, you should run Set-Mailbox to enable auditing for all user and shared mailboxes. A script like the one shown below (downloadable from GitHub) will make sure that auditing is enabled for all user and shared mailboxes:

# UpdateMailboxAuditing.PS1
# A script to update Office 365 E3 user and shared mailboxes and make sure that they are enabled for mailbox audit events
# https://github.com/12Knocksinna/Office365itpros/blob/master/UpdateMailboxAuditing.PS1
# GUID for Office 365 E3
$Office365E3 = "6fd2c87f-b296-42f0-b197-1e91e994b900"
$Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
$ProgressDelta = 100/($Mbx.count); $PercentComplete = 0; $MbxNumber = 0; $SharedMailboxNumber = 0; $MbxUpdated = 0; $SharedMbxUpdated
CLS
Write-Host "Finding Office 365 E3 mailboxes"
# Process mailboxes - Check Azure Active Directory to find accounts with Office 365 E3 licenses
[array]$Mbx = Get-MgUser -filter "assignedLicenses/any(s:s/skuId eq $Office365E3)" -All
# Loop through accounts, find if they have not been enabled by checking CustomAttribute6, and enable if needed
ForEach ($M in $Mbx) {
    $MbxNumber++
    $MbxStatus = $M.DisplayName + " ["+ $MbxNumber +"/" + $Mbx.Count + "]"
    Write-Progress -Activity "Checking mailbox" -Status $MbxStatus -PercentComplete $PercentComplete
    $PercentComplete += $ProgressDelta
    $MbxProps = (Get-ExoMailbox -Identity $M.UserPrincipalName -Properties CustomAttribute6, RecipientTypeDetails)
    If ($MbxProps.CustomAttribute6 -ne "Mailbox Auditing Enabled") {
       Set-Mailbox -Identity $M.UserPrincipalName -AuditEnabled $True -CustomAttribute6 "Mailbox Auditing Enabled"
       $MbxUpdated++
       $ReportLine  = [PSCustomObject] @{
           Mailbox         = $M.DisplayName
           UPN             = $M.UserPrincipalName
           Department      = $M.Department
           Country         = $M.Country
           AuditingEnabled = "Y"
           MailboxType     = $MbxProps.RecipientTypeDetails} 
         $Report.Add($ReportLine) }
}
# Now process shared mailboxes. These don't have a license, so we fetch them from Exchange Online and check
$SharedMbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails SharedMailbox -Properties CustomAttribute6 -Filter {CustomAttribute6 -eq $Null}
$ProgressDelta = 100/($SharedMbx.count); $PercentComplete = 0; $MbxNumber = 0
ForEach ($M in $SharedMbx) {
    $SharedMailboxNumber++
    $MbxStatus = $M.DisplayName + " ["+ $SharedMailboxNumber +"/" + $SharedMbx.Count + "]"
    Write-Progress -Activity "Checking shared mailbox" -Status $MbxStatus -PercentComplete $PercentComplete
    $PercentComplete += $ProgressDelta
    If ($M.CustomAttribute6 -ne "Mailbox Auditing Enabled") {
       Set-Mailbox -Identity $M.UserPrincipalName -AuditEnabled $True -CustomAttribute6 "Mailbox Auditing Enabled"
       $SharedMbxUpdated++
       $ReportLine  = [PSCustomObject] @{
           Mailbox         = $M.DisplayName
           UPN             = $M.UserPrincipalName
           Department      = "Shared Mailbox"
           AuditingEnabled = "Y"
           MailboxType     = $M.RecipientTypeDetails} 
         $Report.Add($ReportLine) }
}
Write-Host "All done!"
Write-Host "---------"
Write-Host ""
Write-Host "Mailbox auditing enabled for Office 365 E3 mailboxes:" $MbxUpdated
Write-Host "Mailbox auditing enabled for shared mailboxes       :" $SharedMbxUpdated
$Report | Out-GridView

You’ll notice that the script first processes user mailboxes for accounts assigned Office 365 licenses. The script relies on using the Get-MgUser cmdlet from the Microsoft Graph PowerShell SDK to find Entra ID accounts assigned a license SKU of 6fd2c87f-b296-42f0-b197-1e91e994b900, which is the GUID for the Office 365 E3 license. Shared mailboxes don’t have licenses, so they are checked separately. We also use one of the custom attributes available for mailboxes to store an indicator when a mailbox is enabled for mailbox auditing to speed up processing in the future.

Process New Mailboxes

Remember that you will need to enable auditing when you add new mailboxes. That doesn’t sit well with Microsoft’s statement that after mailbox auditing is on by default, “you don’t need to do anything to manage mailbox auditing. (Figure 2).

The Investigation Problem

A communications snafu caused by conflict between product announcement and implementation might not seem that serious. After all, the mailbox audit records are there to be found in the mailboxes. But the issue from a compliance perspective is that investigators might have depended on data being in the Office 365 audit log when they looked for information. It is, after all, the definitive place to look for audit information within an Office 365 tenant and the Microsoft announcements about mailbox auditing by default point to the audit log as the font of all knowledge.

You could say that people should check the latest documentation before embarking on an investigation to know where to look for data. That’s fine in theory, but who says “I must check that documentation again” when in the middle of searching for evidence. Some important pieces of information might have remained hidden in plain view in mailboxes when investigators went looking, and that’s not right.

Other Audit Products Suffer Too

Another problem that arises is that when events don’t get into the audit log, they are not picked up by other products which consume audit data. For example, the activity feed for Microsoft’s own Office 365 Cloud App Security (OCAS) comes from the audit log, so mailbox events that don’t reach the audit log don’t get to OCAS, nor will they be processed by any other repository which depends on a feed from the audit log.

The missing data could create a big compliance issue for organizations who use repositories outside Office 365 to retain audit data for accounts longer than the standard 90-day period allowed for Office 365 E3 accounts (365 days for E5 accounts). Because the mailbox events never reached the audit log, they never got to the other repository either.

Pity to Compromise an Excellent Idea

Enabling mailbox auditing by default is an excellent idea. It’s the right thing to do and aligns with Microsoft’s “commitment to providing our customers with an easy-to-use set of security features.” (July 12, 2018 blog post).

Microsoft has sown confusion in Office 365 tenants by the way mailbox audit events are processed for E3 mailboxes. Let’s hope that they can resolve this issue as quickly as possible. In the meantime, remember to manually enable those E3 mailboxes to make sure the audit log gives a complete picture for all mailbox activities.

This is an example of the work the Office 365 for IT Pros writing team puts in to discover just what happens under the cover of Office 365. Subscribe and learn from what we discover.

Capturing Crucial Office 365 Audit Data Requires E5 Licenses

In January 2019, Microsoft announced that they were adding an event called MailItemsAccessed to the set of audited operations captured in the Office 365 audit log. Microsoft claimed that the new event would “capture details of when a message in a mailbox is opened by the mailbox owner, delegate (someone with read access to the mailbox) or using administrative access” leading to audit information delivering “comprehensive forensic coverage of mailbox accesses.”

Time moved on and in March 2019, Microsoft said that they had halted the deployment of MailItemsAccessed to Office 365 tenants. Software has a habit of hitting delays and it was speculated that the overhead involved in gathering a massive number of message access events would place a strain on Exchange Online.

All went quiet for a while, which prompted me to ask Microsoft in June what was happening. They provided an odd statement that faintly indicated that the MailItemsAccessed event might appear in Q3 (July to September).

Crucial Security or Compliance Audit Events

Q3 came and went without a trace of any message access being captured in the Office 365 audit log. But last month Microsoft released documentation for Advanced Audit in Microsoft 365 (now Purview Audit Premium) which makes it clear that MailItemsAccessed is now regarded as the first example of a “crucial” security or compliance-related audit event included in their advanced audit offering. Previously, Microsoft called these events “high-value.” In either case, Microsoft defines the event as “one that can help you investigate possible breaches or other forensic-related investigations.”

Update October 19: Microsoft has released three additional crucial events to handle email sends and searches of mailboxes and sites.

In a nutshell, if you want to see information about who accessed an item in a mailbox, you need to buy some Office 365 E5, Microsoft 365 E5 or Microsoft 365 E3 with Compliance licenses.

Some MailItemsAccessed records can be found in the Office 365 audit log for my tenant audit and viewed using the Search-UnifiedAuditLog cmdlet or the Audit log search (Figure 1). But all the records that have turned up so far (in about a month) are for “sync” activities for various folders like the Inbox. Sync records aren’t very exciting because all they record is the synchronization of a complete folder using a client like Outlook desktop. The really interesting data lie in bind records, which record access to individual messages.

It’s also interesting to learn that Exchange Online applies throttling for MailItemsAccessed events. If a mailbox generates more than 1,000 bind events in a 24-hour period, Exchange Online stops recording MailItemsAccessed events for bind operations for another 24 hours before resuming capture of these events. Microsoft says that less than 1% of mailboxes are subject to throttling.

You can download an example of how to extract and report MailItemsAccessed audit events from GitHub.

Audit Log Retention Policies

Apart from capturing crucial audit events, the advanced audit feature also allows tenants to configure audit log retention policies. These policies work much like mailbox retention policies. You define a retention policy for selected audit events with a set retention period and Office 365 removes those items after that period. A tenant supports up to 50 audit log retention policies.

This example runs the New-UnifiedAuditLogRetentionPolicy cmdlet to create an audit retention policy to remove any SearchQueryPerformed event executed by the background app@sharepoint process after three months instead of the twelve-month retention of audit events if the tenant has E5 licenses.

New-UnifiedAuditLogRetentionPolicy -Name "90-day Retention SearchQueryPerformed by app@sharepoint" -Description "Remove SearchQueryPerformed events from the app@sharepoint process after 90 days" -RecordTypes SharePoint -Operations SearchQueryPerformed -UserIds "app@sharepoint" -RetentionDuration ThreeMonths -Priority 8

You can only manage audit log retention policies with PowerShell using cmdlets accessible by connecting to the Compliance Center endpoint.

Purging the Office 365 Audit Log

You can choose to apply retention for any of the events captured in the Office 365 audit log and keep them for three, six, nine, or twelve months. That is, you can keep audit events for longer than 90 days for accounts with E5 licenses. Office 365 restricts E3 accounts to a 90-day retention period, which is also the period for which you can search audit events in the Compliance Center. Searches earlier than this point must be done with the Search-UnifiedAuditLog PowerShell cmdlet.

It’s a good idea for tenants who either want precise control over how long audit data is retained or want to clean up events that don’t add much value in terms of investigations. SharePoint is a notoriously “chatty” application when it comes to the capture of audit events, so I can see why tenants  might decide to keep important events like FileUploaded or FileAccessed for as long as possible while removing some of the chatter after 90 days.

Communication Woes

I don’t have any issue with Microsoft classifying the MailItemsAccessed event as crucial and demanding a premium for its capture into the audit log. Only some tenants will be interested in these events and they might well have E5 licenses already. I can also see the sense of not imposing a huge overhead on Office 365 to capture these events for E3 tenants. It’s just a pity that the communication around the introduction of MailItemsAccessed and its evolution to become a crucial audit event has been so fractured and incoherent. Microsoft can do better.

We track developments in Office 365 auditing, including the kind of events you can extract from the audit log, in a chapter in the Office 365 for IT Pros eBook. Knowing what goes on in a tenant is important and the audit log holds the answers to many mysteries.

Using Delegate Permissions to Manage Mailboxes

Office 365 Notification MC203923 published on Valentine’s Day gives the welcome news that Outlook mobile clients are gearing up to be able to use the Exchange Online delegate permissions to manage another user’s mailbox. This work builds on the shared mailbox support delivered for Outlook mobile last August. The net is that Outlook Mobile Delegate Access for Exchange Online mailboxes is now available.

The associated Microsoft 365 roadmap items (53666 for iOS and 53667 for Android) are somewhat obscure in what they say: “Delegates can access and manage messages within an owner’s inbox folder.” This is what shared mailbox support is all about. Fortunately, the notification is more helpful when it tells us that: “Delegates who have been granted full access permissions to send email and respond to calendar invitations on the behalf of another person will soon be able to do so from Outlook for iOS and Android.” Delegate access is described in this Microsoft support article.

Deployment Done by mid-April

Microsoft says that they are deploying the feature now. The minimum supported versions are Outlook mobile 4.25.0 for iOS (available in Testflight) and Outlook mobile 4.1.31 for Android. As always with Outlook mobile features, it takes a little time to get the new software everywhere. Microsoft says that worldwide deployment should be done by mid-April.

Full Access Permissions Needed

Delegate access only works when the user and the delegate both have Exchange Online mailboxes. The delegate must be assigned full access permission for the target mailbox before Outlook mobile can add it as a delegate mailbox. Permission is granted by editing the mailbox with the Microsoft 365 Admin Center. Open the mailbox properties and select the manage mailbox permissions tab. Then add the user to whom you want to grant access. Figure 1 shows the assignment of Full Access permission, referred to by the Admin Center as “Read and manage permission.”

Alternatively, run the Add-MailboxPermission PowerShell cmdlet. This example gives James Ryan full access to the mailbox owned by Kim Akers. The automapping parameter is set to false to stop Outlook desktop including the mailbox in the set of resources automatically opened by the client.

# Add full access permission to mailbox but don't automap
Add-MailboxPermission -Identity Kim.Akers -AccessRights FullAccess -User James.Ryan@Office365itpros.com -AutoMapping $False

Full Access grants a delegate the ability to open the mailbox and interact with its content. It grants the delegate access to every folder, meaning that they can manage the calendar. The delegate can also read every message in the mailbox. Outlook mobile doesn’t use the set of granular folder-level permissions supported by Outlook desktop to grant delegate access to specific folders.

Permission to Send Email Needed Too

Full Access doesn’t allow a delegate to impersonate the mailbox owner when sending messages. A second permission is needed, and the delegate needs to be assigned either Send On Behalf or SendAs permission. These permissions can be added through EAC or by running the Add-MailboxRecipientPermission (SendAs) or Set-Mailbox (Send On Behalf) cmdlets. For example:

# Add permission for a user to send as another user
Add-MailboxRecipientPermission -Identity Kim.Akers -AccessRights SendAs -Trustee James.Ryan
Set-Mailbox -Identity Kim.Akers -GrantSendOnBehalfTo James.Ryan

It takes a few minutes to ensure that the new permissions are fully respected across Office 365.

Adding the Mailbox to Outlook Mobile

Open Outlook mobile and go to the Settings section. Select Add Email Account and then Add Shared Mailbox. Input the SMTP address of the mailbox you want to add. If your account has delegate permissions for the mailbox, Outlook mobile lists it in the set of mailbox resources accessible in the client (Figure 2).

You can also add a delegate mailbox from the list of mailboxes displayed by Outlook mobile (left-hand navigation) by selecting the mailbox add icon at the bottom of the list.

Processing Email

After adding the delegate mailbox, you should be able to see all the folders in the mailbox including the calendar. You can interact with any of the messages in the delegated mailbox as if you are the owner, meaning that you can delete messages, move them between folders, and so on.

To send a message, click the New message icon and compose the message ad normal. The name of the mailbox being used is displayed under the New Message label (Figure 3). Note that in this case my signature is included in messages created for the delegated mailbox.

If you’re using delegate mailboxes, you’ll want to create a separate signature for each mailbox. Do in Settings by selecting Signature and then enabling per-account signature. You can then enter a signature for each account.

Another way to send from a delegated mailbox is to compose a message and then select the mailbox to use from the drop-down list of accounts under the New Message label (Figure 4).

Delegate Access is Another Reason to Use Outlook Mobile

Adding functionality like delegate access to mailboxes underscores the advantage of using Outlook mobile with Exchange Online compared to clients based on the ActiveSync protocol. ActiveSync is a very successful protocol that helped Microsoft evangelize mobile connections to Exchange across a wide range of email clients, but it’s an aging protocol now and just doesn’t have the same functionality as the newer Microsoft sync technology. If you’re not using Outlook mobile now, maybe now’s the time to consider switching?

The Office 365 for IT Pros eBook covers clients in some detail, including how delegate access works. It’s another reason why you should be a subscriber.

Quickly Find Attachments in Primary Mailbox

In the run-up to the Christmas holidays, you might have missed Office 365 notification MC198342 posted on 17 December to announce the advent of the OWA Files view. According to Microsoft 365 Roadmap item 59643 this is “a view of all the files sent and received as attachments in your inbox.” In reality, the Files view enables quick access to every sent or received attachment in every folder in your primary mailbox.

The feature is now rolling out to tenants and should be available throughout Office 365 by the end of March. You’ll know if it’s available when the Files icon shows up in OWA’s module switcher (Figure 1). Clicking the icon takes you to https://outlook.office.com/files/.

Microsoft hasn’t said if they will add this feature to OWA for Exchange on-premises. My feeling is that this is doubtful.

The Files View

The Files View presents attachments found in a mailbox in five columns, each of which is sortable. The default sort is by received date (newer to older), while Figure 2 shows attachments sorted by name (Z to A).

Newly received or sent attachments don’t show up immediately in the view.

If you select an attachment, OWA opens it and the message it belongs to in a viewer. You can hide the message if you want to concentrate on the attachment.

Types of Attachments

By default, all types of attachment are shown. OWA differentiates between Files (Office documents, PDFs, text, email, and other non-graphic types) and Photos (files in graphic formats like JPEG or PNG). When browsing photo attachments, choosing Tiles rather than a list can help locate the right attachment faster (Figure 3).

Filtering Attachments

You can choose to see all attachment types or switch between Files and Photos using the options in the left-hand navigation pane or the Filter drop-down (Figure 4), which allows you to select exactly what you want to see. The date range part of the filter is very useful when you want to find attachments sent in a specific period. You can combine a date range with filters for specific file types.

To refine the view further, you can input search terms into the search box. OWA will apply the search to the items in the view and display what it finds.

No Archived Attachments

OWA’s Files view only shows attachments stored in the primary mailbox. Attachments moved into archive mailboxes (not to be confused with the Archive folder in mailboxes) are not shown in the Files view. You’ll have to open the archive mailbox and use a search to find information stored there. This isn’t surprising because archive mailboxes are intended to hold information that is not needed very often.

The Substrate is the Key

Microsoft dipped their toes into a Files view for OWA with “group files” for Office 365 Groups in 2016. That feature is less functional than the generalized Files view now being introduced. In both cases, the features depend on the capture and storage of information by the Office 365 substrate. Hidden folders in user mailboxes (like GraphFilesAndWorkingSetSearchFolder) hold metadata and copies of attachments. OWA uses this data for fast access to information and to avoid the need to scan a mailbox looking for messages with attachments.

Poking around the folders in the “non interpersonal messaging” (aka Non-IPM subtree) part of an Exchange Online mailbox with a tool like MFCMAPI reveals that cloud mailboxes hold a lot more information than their on-premises counterparts. The overall size of these mailboxes is much larger than you’d expect. Features must be paid for with resources, and cloud storage is cheap (except for SharePoint Online).

OWA Files is an example of a new feature that may or may not make a difference to you. But it’s good to know about stuff like this, which is why we keep an eye on Office 365 developments for you and document the most important in the Office 365 for IT Pros eBook. Subscribe today to stay informed.

New Configurable Mailbox Property for Maximum Recipients for a Message

As a cloud service, Office 365 uses preset limits (like custom recipient limits) to protect both Microsoft and its customers from abuse. Although most of the limits are set to reasonable values, in some cases organizations want to be able to modify them and complaints about “loss of control” after the switch to the cloud are not uncommon. Throttling policies in Exchange Online are one such example – the corresponding UI and PowerShell cmdlets have been removed from Exchange Online.

Custom recipient limits are a more specific example. This setting controls the maximum number of recipients for a single message sent from an Exchange Online mailbox. Ever since Office 365 launched, this limit has been 500 recipients, and could not be changed. Now, Microsoft is releasing a feature that allows organizations to customize this value. This was originally announced back at the Microsoft Ignite 2019 conference, and just recently the feature started rolling out through the different regions.

Any Value Between 1 and 1000

The feature does what it says, allowing you to configure custom values for the RecipientLimits property of a mailbox. You can set the value to anything between 1 and 1000. If you try to set it to a value outside of this range, an error is generated. So no, you cannot set it to 0, if you want to prevent the user from sending any message you have to use a mail flow rule. For additional information about the customizable recipient limits feature, you can refer to the feature description in Microsoft 365 Roadmap item 55025 (Figure 1).

Setting a Custom Recipients Limit on a Mailbox

Currently you can only change the recipient limits via PowerShell, but the corresponding UI bits are also rolling out and should be available at some point in the EAC. Here are some examples on how you can utilize this. First, if you want to change the recipient limit for a single mailbox, you can use the Set-Mailbox cmdlet:

Set-Mailbox user@domain.com -RecipientLimits 999

If you want to perform the change against a group of users, you can easily do so by using filters or importing the list from a CSV file. For example, here’s how to do it on all users in a specific department:

Get-User -RecipientTypeDetails UserMailbox -Filter {Department -eq "Marketing"} | Set-Mailbox -RecipientLimits 100

Or if you want to change it for all user mailboxes in the organization:

Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-Mailbox -RecipientLimits 10

Note: The new Get-ExoMailbox cmdlet is faster at finding large sets of mailboxes. To confirm the limit is changed, you can use the Get-Mailbox cmdlet to check the values on each mailbox.

It is important to understand that Set-Mailbox can only be used to change the limit for mailboxes that are already provisioned. If you want to make sure that a given limit applies to any newly created mailboxes, you can do so via the Set-MailboxPlan cmdlet. For example, to set the recipient limit to 100 on any newly provisioned Exchange Online Plan 1 mailboxes, you need to change the value on the corresponding “ExchangeOnline” plan. Similarly, you must change the “ExchangeOnlineEnterprise” plan for Exchange Online Plan 2 mailboxes, and so on.

Update Mailbox Plans for New Mailboxes

Set-MailboxPlan ExchangeOnline -RecipientLimits 50

To find the default recipient limits values for the different mailbox plans, use the following command:

Get-MailboxPlan | ft DisplayName, RecipientLimits

DisplayName              RecipientLimits
-----------              ---------------
ExchangeOnline           50
ExchangeOnlineEnterprise 500
ExchangeOnlineDeskless   500
ExchangeOnlineEssentials 500

Organization Recipient Limits in the Anti-Spam Policy

Recipient limits are also specified in the outbound anti-spam policy (Figure 1), managed through the Security and Compliance Center. The limits discussed above are limits applied to a single message. The limits in the anti-spam policy control the number of internal and external recipients a user can address in an hour or day (for both types).

The limits set in the outbound spam policy can’t exceed the sending limits for Exchange Online, which allow for a user to send to a maximum of 10,000 recipients per day.

There is lots of information about different aspects of Office 365 and Exchange Online management in the Office 365 for IT Pros eBook. Subscribe to learn and keep up to date with developments inside Office 365.

Use PowerShell to Create the Exchange Mailbox Quota Report

Updated 24 September 2023

One of the first PowerShell scripts created after the launch of Exchange 2007 was to report the quotas assigned to mailboxes and the amount of quota consumed by each mailbox. Scripts of this type are relatively simple and rely on the Get-ExoMailbox and Get-ExoMailboxStatistics cmdlets to provide data about quotas and usage.

Over time, many variations on this report have appeared. The variant shown here is a response to a request in a Facebook group about Office 365 for a script to identify mailboxes whose quota is nearly exhausted. In this case, the Office 365 tenant has many frontline accounts whose Exchange Online mailbox quota are 2 GB instead of the much more generous 100 GB assigned to enterprise accounts. It’s obviously much easier to fill a 2 GB quota, especially if you use Teams and share images in personal chats. The idea therefore is to scan for mailboxes whose usage exceeds a threshold of quota used (expressed as a percentage). Mailbox owners who fall into this category might need to remove some items (and empty the Deleted Items folder) or receive a larger quota.

Exchange Online Mailbox Numbers and PowerShell

Two things are notable. First, if you want to do comparisons with the information returned by the cmdlets, you should convert the returned values into numbers (byte count), which is what is done here. This is because the Get-ExoMailbox and Get-ExoMailboxStatistics cmdlets return values like:

Get-ExoMailboxStatistics -Identity Kim.Akers | Format-List TotalItemSize                                    

TotalItemSize : 3.853 GB (4,136,899,622 bytes)

It’s hard to do computations on these values, so some processing is needed to ensure that calculations proceed smoothly.

Dealing with the Exchange Mailbox Quota Report Output

Second, the output is a CSV file sorted by mailbox display name. You could use the output in different ways. For instance, you could use the incoming webhook connector to post information about users whose mailboxes need some attention to Teams or Microsoft 365 Groups (here’s an example).

Here’s the script. As always, no claims are made that this is perfect PowerShell code. It’s entirely up to the reader to improve, enhance, or debug the script to match their needs. You can download the script from GitHub.

# Set threshold % of quota to use as warning level
$Threshold = 85
# Get all user mailboxes
Clear-Host
Write-Host "Finding mailboxes..."
[array]$Mbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox -Properties ProhibitSendReceiveQuota | Select-Object DisplayName, ProhibitSendReceiveQuota, DistinguishedName
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($M in $Mbx) {
    # Find current usage
    Write-Host "Processing" $M.DisplayName
    $Mailbox = $M.DisplayName
    $ErrorText = $Null
    $MbxStats = Get-ExoMailboxStatistics -Identity $M.DistinguishedName | Select ItemCount, TotalItemSize
    # Return byte count of quota used
    [INT64]$QuotaUsed = [convert]::ToInt64(((($MbxStats.TotalItemSize.ToString().split("(")[-1]).split(")")[0]).split(" ")[0]-replace '[,]',''))
    # Byte count for mailbox quota
    [INT64]$MbxQuota = [convert]::ToInt64(((($M.ProhibitSendReceiveQuota.ToString().split("(")[-1]).split(")")[0]).split(" ")[0]-replace '[,]',''))
    $MbxQuotaGB = [math]::Round(($MbxQuota/1GB),2)
    $QuotaPercentUsed = [math]::Round(($QuotaUsed/$MbxQuota)*100,2)
    $QuotaUsedGB = [math]::Round(($QuotaUsed/1GB),2)
    If ($QuotaPercentUsed -gt $Threshold) {
       Write-Host $M.DisplayName "current mailbox use is above threshold at" $QuotaPercentUsed -Foregroundcolor Red
       $ErrorText = "Mailbox quota over threshold" }
    # Generate report line for the mailbox
    $ReportLine = [PSCustomObject]@{ 
        Mailbox          = $M.DisplayName 
        MbxQuotaGB       = $MbxQuotaGB
        Items            = $MbxStats.ItemCount
        MbxSizeGB        = $QuotaUsedGB
        QuotaPercentUsed = $QuotaPercentUsed
        ErrorText        = $ErrorText} 
   $Report.Add($ReportLine)
} 
# Export to CSV
$Report | Sort-Object Mailbox | Export-csv -NoTypeInformation MailboxQuotaReport.csv

Figure 1 shows an example of the kind of report that the script generates.

Tailoring the Exchange Mailbox Quota Report

The script is reasonably simple PowerShell code so there shouldn’t be much difficulty in tailoring it to fit the needs of a specific organization. The nice thing about PowerShell is that it’s easy to customize and easy to stitch bits of code from different scripts together to create a new solution. Hopefully you’ll be able to use the code presented here for your purposes.

Need more information about how to manage Exchange Online mailboxes? Look no further than the Office 365 for IT Pros eBook, which is filled with practical ideas, suggestions, and lots of PowerShell examples.

Microsoft Announces Deprecation of Basic Auth for Multiple Connection Protocols

Following the introduction of protocol authentication policies for Exchange Online last year (also available for Exchange 2019), the Exchange development group has moved to reduce the attack surface available to hackers by announcing the deprecation of basic auth connections for a set of mailbox protocols from October 2020. The affected protocols are:

• Exchange Web Services (previously announced in July 2019).
• Exchange ActiveSync (EAS).
• IMAP4.
• POP3.
• Remote PowerShell.

Deprecation is due to happen on October 13, 2020. The usual approach inside Office 365 is that the cut-off doesn’t happen immediately but can occur at any point without warning after the announced date. When the axe descends, clients running any of the listed protocols won’t be able to connect to Exchange Online using basic auth. Customers therefore have just over a year to prepare for the change.

Update: Microsoft has pushed the deprecation date out to mid-2021.

The Challenge of Mobile Clients

The biggest issue is likely to be with mobile clients. Microsoft licenses ActiveSync (EAS) to many mobile device vendors to enable connectivity from clients like the iOS mail app to Exchange. Microsoft argues that it’s time for customers to move to clients that support modern authentication and point to Outlook Mobile for iOS and Android as the logical choice for anyone with an Exchange Online mailbox. The big advantage of Outlook Mobile is that you get more features delivered for these clients, such as the recent support delivered for dark mode and shared mailboxes.

Although it’s true that Outlook Mobile has more than 100 million users, the facts remains that this number counts both consumer and commercial customers and there’s way more Exchange Online mailboxes in use. The last active number for Office 365 seats was 180 million (April) and that’s likely to be past 200 million now. Given the mobile nature of email, roughly 50% of the Exchange Online community might use a client today that depends on basic auth for EAS, IMAP4, or POP3.

I’m sure Microsoft has been in touch with its EAS licensees with an update for the new connectivity rules. It’s then up to licensees to update the mail apps for their devices to support modern authentication (Apple already has for iOS 11 onward). However, just because a mail app proclaims its support for modern authentication, software must still be checked out against Office 365 to make sure that everything works as expected across all client versions on all device families (some folks have run into problems with the iOS app).

Time to Go for IMAP4 and POP3

Microsoft says that they will update their POP3 and IMAP4 connections to support modern authentication soon. This will help, but tenants will still have to validate that any IMAP4 and POP3 clients still in use can connect,. including applications where IMAP4 or POP3 is used to send messages. I recommend that tenants take the opportunity to move users on from these now-ancient email protocols to something that’s more secure and functional, even if it means ripping Thunderbird and other clients out of user hands. They’ll be better for the experience.

Upgrading to a more functional email client is one thing; upgrading an application that uses IMAP4 to fetch messages from Exchange Online is another. Microsoft has committed to update the IMAP4 protocol for Exchange Online to support OAuth and say that they will make an announcement when this support is available. Upgrading an application will involve code changes, so now’s a good time to collect a roster of applications that will need to be updated. On the other side of the coin, the SMTP AUTH protocol used by many applications and devices to send messages is not being changed.

Of course, if you feel adventurous, you could upgrade apps to use the Microsoft Graph REST API instead of IMAP4. I suspect that this won’t happen as the work involved is likely to be more onerous (especially testing) than upgrading an IMAP4 connection to support modern authentication.

Remote PowerShell

Exchange has used Remote PowerShell since Exchange 2010 (more software to hit the ropes in October 2020) and people are very accustomed to making remote connections to work with mailboxes and other Exchange objects through PowerShell. The issues involved in Remote PowerShell for Exchange Online are not limited to basic auth, but at least MFA-enabled connections are available.

Discovering Basic Auth Connections

Microsoft says that they will deliver a tool to allow Office 365 tenant administrators to discover who’s using basic auth to connect to their mailboxes. No details of the tool are yet available.

A Good Change

Overall, getting rid of insecure basic auth connections is a very good idea. The only downside is the work that Office 365 tenants must do to identify what usage basic auth has inside their environment and then come up with plans to remove the dependency. At least there’s plenty of time to do the work.

For more information about Exchange Online, read the Office 365 for IT Pros eBook. Our earliest editions focused on Exchange Online, but we’ve got much broader coverage across Office 365 now.

Wellbeing for All, Unless You Want to Disable the Fitness Tracker for Work

Updated 4 September 2021

Recently Office 365 users have received email from the MyAnalytics service (Figure 1) apparently out of the blue. Being coached about the steps to achieving wellbeing is all very well, but you’d like to be asked whether you need to use the “fitness tracker for work.”

The reason why this is happening is that Microsoft decided in January 2019 to remove MyAnalytics from its previous status of only being available in the Office 365 E5 plan or as a separate add-on and make the service available for everyone with an Exchange Online license (see roadmap item 52276). They are now getting around to rolling out the feature (see Office 365 notification MC186372 of July 23, 2019).

Disabling MyAnalytics

Even though the data is personal and is never shared with others, some people hate the idea of Office 365 analyzing and reporting their activity, let alone sending well-intended messages to help them work smarter, which is why you might need to disable MyAnalytics for the entire tenant (perhaps to prepare users for its introduction) or for individual users (mailboxes).

There are two ways to disable MyAnalytics: for the tenant or for an Exchange Online mailbox. To disable MyAnalytics for a tenant, go to the Settings section of the Microsoft 365 Admin Center, then Org settings, and finally select MyAnalytics from the list. You can now select the default settings to apply to all mailboxes (Figure 2). You can disable just the weekly message to encourage better work habits by unchecking Weekly insights email.

The weekly digest messages sent by MyAnalytics are interesting. They are submitted direct to user mailboxes and don’t seem to go through the Exchange Online transport service. If they do, the items pick up no message headers and no trace is left in the message tracking logs. Another minor irritation is that tenants have no control when the messages are delivered; they arrive when MyAnalytics is ready.

User Settings

Users can go to the MyAnalytics dashboard (selectable from the Office 365 waffle menu), and disable the service from the Settings menu (Figure 3). Note that it can take up to a week for changes to take effect, which means that a user might receive another email while the setting change is being implemented.

Users can also opt out of receiving the weekly email using the unsubscribe link in the message.

Updating the Analytics Mailbox Settings with PowerShell

Alternatively, you can run the PowerShell Set-MyAnalyticsFeatureConfig cmdlet to update the MyAnalytics privacy setting for mailboxes . The Get-MyAnalyticsFeatureConfig cmdlet is also available to check the current state of affairs. Previous to the introduction of the V2.0.4 of the Exchange Online Management module (or later), the cmdlets were Set-UserAnalyticsConfig and Get-UserAnalyticsConfig. Both sets of cmdlets use the same syntax. For example:

# Report what mailboxes are enabled for MyAnalytics
$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select DisplayName, UserPrincipalName
$MyAnalyticsCount = 0
ForEach ($M in $Mbx) {
   $MyAnalytics = Get-MyAnalyticsFeatureConfig -Identity $M.UserPrincipalName | Select PrivacyMode
   If ($MyAnalytics.PrivacyMode -eq "opt-in") { 
       $MyAnalyticsCount++
       Write-Host "MyAnalytics is enabled for" $M.DisplayName }
   Else { Write-Host "MyAnalytics is not enabled for" $M.DisplayName}
}
Write-Host "MyAnalytics is enabled for" $MyAnalyticsCount "of" $Mbx.Count "mailboxes"

The PrivacyMode setting governs whether data for a mailbox is used by MyAnalytics. In this example, we select mailboxes based on their CustomAttribute7 attribute, which we set to “NoMyAnalytics” when a mailbox has been removed from MyAnalytics processing.

# Disable Selected Mailboxes for MyAnalytics
$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter {CustomAttribute7 -eq "NoMyAnalytics"} | Select DisplayName, UserPrincipalName
ForEach ($M in $Mbx) {
     Write-Host "Disabling MyAnalytics for" $M.DisplayName
     Set-MyAnalyticsFeatureConfig -Identity $M.UserPrincipalName -PrivacyMode "opt-out" }

The Set-MyAnalyticsFeatureConfig cmdlet can control individual mailbox feature settings for analytics. Three feature settings are currently available:

• Dashboard: Access to the MyAnalytics dashboard.
• Add-in: Access to the Outlook Insights add-in.
• Digest-email: Access to the email digest.

You can opt-in mailboxes for analytics but block individual features. For instance, here’s how to block the digest email while allowing users to access the dashboard and Outlook add-in:

$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select DisplayName, UserPrincipalName
ForEach ($M in $Mbx) {
     Write-Host "Disabling the monthly analytics digest email for" $M.DisplayName
     Set-MyAnalyticsFeatureConfig -Identity $M.UserPrincipalName -PrivacyMode "opt-in" -Feature digest-email -IsEnabled $False}

If you examine mailbox details afterwards, you should find that the account is enabled for analytics but won’t receive the mail digest:

Get-MyAnalyticsFeatureConfig -Identity Stale.Hansen@office365itpros.com | ft UserId, PrivacyMode, IsDigestEmailEnabled

UserId                           PrivacyMode IsDigestEmailEnabled
------                           ----------- --------------------
Stale.Hansen@office365itpros.com opt-in                     False

Removing the MyAnalytics License from User Accounts

If you need to remove MyAnalytics totally for a mailbox, the best approach is to remove the Insights by MyAnalytics license assigned to the account. You can do this in the Microsoft 365 admin center by selecting the account and editing the Apps section of the license configuration to uncheck Insights by MyAnalytics. It’s also possible to do this with PowerShell. Here’s an example. The code uses a mixture of Microsoft Online Services and Exchange Online cmdlets to remove the MyAnalytics license from users with Office 365 E3 licenses.

• Define a new license option which excludes MyAnalytics. You must change the definition of the $Office365E3License variable to replace “yourtenantname” with the actual name of your tenant. If you want to remove the MyAnalytics license from users with other Office 365 licenses, you’ll need to add some more code to process these licenses.
• Read in a set of users for which we want to remove MyAnalytics license. I use a distribution group here. You could also create a list by applying a filter to select a set of Azure Active Directory accounts or Exchange Online mailboxes.
• For each user, set the new license option with the Set-MsolUserLicense cmdlet.
• To make sure that we don’t process the user again, set the CustomAttribute8 property of their mailbox with a value to indicate that the license is removed.

# Remove MyAnalytics licenses from Office 365 accounts
$Office365E3License = "yourtenantname:ENTERPRISEPACK"
$NewE3Options = New-MsolLicenseOptions -AccountSkuId $Office365E3License -DisabledPlans "MYANALYTICS_P2"
$Users = Get-DistributionGroupMember -Identity NoMyAnalytics
Foreach ($U in $Users) {
      If ((Get-ExoMailbox -Identity $U.WindowsLiveId).CustomAttribute8 -ne "MyAnalytics disabled") {
         Write-Host "Disabling MyAnalytics for" $U.DisplayName
         Set-MsolUserLicense -UserPrincipalName $U.WindowsLiveId -LicenseOptions $NewE3Options   
         Set-Mailbox -Identity $U.WindowsLiveId -CustomAttribute8 "MyAnalytics disabled"  }
}

Like all PowerShell samples, this code is intended to illustrate a principal. It works, but it might not be what you want to use in production on an ongoing basis. A more developed version of code which can handle the removal of any individual service plan from an Office 365 SKU is described here.

We cover MyAnalytics in the companion volume of the Office 365 for IT Pros eBook. That doesn’t mean that the information isn’t valuable: it simply means that we have tons of other stuff to discuss in the main book. However, we do cover the topic of removing licenses from Office 365 accounts with PowerShell in Chapter 4…

Microsoft Clarifies Search Capability for Disconnected Exchange Online Mailboxes

After some spirited discussions between the Exchange engineering group and several MVPs (with special credit to the Office 365 for IT Pros technical editor, Vasil Michev), Microsoft has agreed that the content in disconnected mailboxes is not available and cannot be found in Office 365 content searches executed through the Security and Compliance Center. This is now documented online.

A disconnected mailbox is one that belonged to an Azure Active Directory account (cloud only or synchronized from on-premises) where the Exchange Online license is removed from the account. This can be the Exchange Online license within an Office 365 plan (like E3 or E5) or the entire plan. When a license is removed, the mailbox enters a 30-day disconnected state (this doesn’t happen immediately as it depends on a background process). Eventually, the 30-day period elapses and Exchange Online removes the mailbox from its database.

The problem raised by the MVPs arose from some inconsistency in Microsoft’s documentation which led people to believe that the content in disconnected mailboxes could be searched during the 30-day retention period. Tests proved that this seemed to be the case, but it’s always best to go to the source and seek confirmation from engineers who write the code.

Use Inactive Mailboxes to Keep Mailbox Content Online

Inactive mailboxes are the only supported method of keeping mailbox content online and available for searching when a user is no longer licensed for Exchange Online. To make a mailbox inactive, you put a hold on the mailbox before removing the user account from Office 365. The inactive mailbox will remain online as long as a hold is in place. Once the hold (or holds) are removed, the mailbox loses its inactive status and will be deleted.

For lots more tips about how to manage Exchange Online mailboxes, read what we’ve got to say in the Office 365 for IT Pros eBook. And if you find something that we don’t cover well, let us know and we’ll get to it.

Time to Phase out Exchange Online Retention Policies for Office 365 Retention Policies?

Exchange mailbox retention policies were introduced in Exchange 2010. They are still a popular method to control what users can keep in both on-premises and cloud mailboxes, but as time goes by, Office 365 tenants might consider moving to Office 365 retention policies to enforce a common retention framework across all workloads.

Because Exchange mailbox retention policies are designed to process email, they offer different functionality to the general-purpose Office 365 retention policies. By their very nature, compromises exist in any policy that applies across multiple Office 365 workloads like Exchange Online, SharePoint Online, and Teams. One such compromise is the inability of users to assign personal retention tags to items.

How Exchange Makes Personal Retention Tags Available

Personal retention tags allow users to define different retention behavior for items stored outside system folders (like the Inbox). For example, you might define a retention tag to keep items for ten years and make it available to users to assign to items that they don’t want removed from their mailbox. Personal retention tags are published to users through the mailbox retention policies assigned to their mailboxes. Users can also browse available personal retention tags through the Mail section of OWA options (Figure 1) and add tags that are not included in their policy which they would like to use. When they select a personal tag, Outlook adds it to the set defined in their assigned mailbox retention policy.

But I Don’t Want People Using Personal Retention Tags

Recently I heard some people questioning why users should be able to add personal tags through OWA options. The logic here is that the organization wants to exert complete control over the retention of mailbox items and don’t want users deciding to do anything different. You might decide to follow the same course if you’re preparing to switchover to Office 365 retention policies and don’t want to confuse people when they then can’t use personal tags.

Just like mailbox retention policies, Exchange 2010 introduced role-based access control (RBAC). Each mailbox is assigned a user role assignment policy to control what options are available to the mailbox. Many tweaks can be made to user role assignment policies to control features down to individual PowerShell cmdlet parameters (all Exchange management functionality is built on top of PowerShell), but in this case all we need to do is create a new user role assignment policy and remove the retention policy option.

Go to the Permissions section of the Exchange Admin Center (EAC), select User roles, and create a new policy. Give the policy a name and then check off the different user roles you want to include in the policy. Some of the roles (like MyTextMessaging) are antique memories of a long-past time and can be excluded without affecting user functionality. To remove the ability to select personal retention tags, uncheck the MyRetentionPolicies role (Figure 2) and save the new policy.

Assign the New User Role Assignment Policy

After making sure that the settings in the new policy are correct, you can assign it to mailboxes. Do this by selecting mailboxes in EAC and assigning the policy to them (Figure 3) or with PowerShell (below).

# Assign user role assignment policy to mailbox
Set-Mailbox -Identity "Oisin Johnston" -RoleAssignmentPolicy "Restricted Retention Tags"

After assignment, wait at least fifteen minutes for OWA to refresh its settings (or sign the user out and back into OWA) before checking that the retention policies option is unavailable in OWA settings.

A lot of Exchange Online mailbox management has its roots in the on-premises mechanisms. We cover this information in two chapters in the Office 365 for IT Pros eBook, suitably updated for the cloud of course…

Shared Mailboxes for All, Dark Mode for Some

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

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

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

Outlook Mobile Goes Dark

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

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

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

Enabling Dark Mode

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

When Your Client Can Go Dark

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

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

How Outlook Clients Use the Places Service to Display Location Information

Updated January 2020.

Exchange Online has a new Outlook Places service that’s designed to help users find meeting locations, notably with room mailboxes. A new “suggested calendar locations” feature (Office 365 notification MC187963, roadmap 20974) makes use of the location data to suggest meeting locations for new events. The data is also used in the OWA room card as described on Dec 20, 2019 in MC198678, roadmap 59430.

Populating Places

To make sure that the Outlook Places service works well and to prepare for whatever use Microsoft puts the Places service in the future, you should update room metadata that the service can consume and present to users. Currently, clients search for meeting locations using room mailbox names and room lists (Outlook desktop) together with suggested locations based on what the user enters in the Location field. Outlook creates suggested locations using the Bing Locations API.

Because room names are common across all clients, it’s best to make sure that the name assigned to a room helps users understand where it is located. You can supplement the information by updating the Places entry for a room with information like a label, building, floor number, and geocoordinates.

Updating Place Information for Room Mailboxes

The Set-Place cmdlet updates the location metadata for a room mailbox. For example:

# Set the location metadata for a room mailbox
Set-Place -Identity "San Francisco Room" -CountryOrRegion "US" -City "San Francisco" -Floor 1 -Capacity 54 -Street "10 Sutter Street" -GeoCoordinates "37.790507; -122.400274" -Building "Western HQ" -State CA -PostalCode 94104 -Phone “+1 206 177 4151" -Label "Training" -VideoDeviceName "Crestron Flex UC-M150-T" -Tags Training, Development, Videoconference

Note that the CountryOrRegion parameter uses the two-character ISO country code.

Time-based assistants running in the background synchronize information for room mailboxes to the Places service. OWA fetches information from the Places service to display place information about locations in room cards (Figure 1).

Updating OWA Mailbox Policies

Note that OWA doesn’t display place information (like the map shown in Figure 1) if the PlacesEnabled setting in the OWA mailbox policy assigned to user mailboxes is set to $False. This might be the case if you have multiple policies as Microsoft only automatically updated the default OWA mailbox policy for tenants to set PlacesEnabled to $True. When PlacesEnabled is set to $False, OWA doesn’t display the extended place information in the room card and limits the information to whatever’s defined for the room mailbox.

To make sure that users can access the information you populate for places, update OWA mailbox policies as follows:

# Update all OWA mailbox policies in a tenant to allow use of Place information by OWA
Get-OWAMailboxPolicy | ? {$_.PlacesEnabled -eq $False} | Set-OWAMailboxPolicy -PlacesEnabled $True

Finding Place Information

The Get-Place cmdlet returns details of room mailboxes and their location metadata.

Get-ExoMailbox -RecipientTypeDetails RoomMailbox | Get-Place | Format-Table DisplayName, Building, Floor

DisplayName               Building   Floor
-----------               --------   -----
Dublin Conference Room    Building 1     1
Las Vegas Conference Room
Room 101
Room 102
Room 103
Room 104                  HQ             1
SF Room 101               Western HQ     1

Finding GeoCoordinates for Locations

You’ll notice that the geocoordinates for the location are included in the metadata for a room mailbox. Outlook uses geocoordinates to retrieve map information to help users find the building where a room is located. The easiest way to find the geoordinates for a building is to search for the place with Google Maps, click What’s Here to reveal details of the map point, and then click the coordinates. Google Maps then displays the detail in a pane (Figure 2). Replace the comma in the coordinates with a semi-colon to make the data suitable for input to Set-Place.

Client Use of Geocoordinates

At present, OWA and Outlook mobile are the only clients to use the geocoordinates for rooms. OWA displays maps when scheduling new meetings or displaying meeting information (Figure 1) together with a Directions link. Clicking the link feeds the longitude and latitude information in the room geocoordinates to the Bing Locations API to find and display directions to the room with Bing Maps. You can’t configure OWA to use a different maps provider.

Outlook Mobile displays map information when scheduling a new meeting (Figure 3) but doesn’t when viewing meetings in the calendar.

For more information about room mailboxes, read the Office 365 for IT Pros eBook.

Tell External People that the Company’s on Holiday

The question arose about the best way to set auto-reply for a shared mailbox to inform external senders that the company is on holiday (public or otherwise). Some suggested using Flow for the job. I, of course, thought of PowerShell. I’m not against Flow: I simply think that PowerShell offers more control and flexibility, especially when multiple shared mailboxes are involved. For instance, you might want to set appropriate auto-reply messages up for all the shared mailboxes in an organization, especially if those mailboxes are used for customer interaction.

Auto-replies, or OOF (Out of Facility) notifications as they are known in the trade, go back to the dawn of email (before Exchange 4.0). Even Teams supports out of office notifications. For Exchange (on-premises and online), it’s easy to manage auto-replies with PowerShell using the Set-MailboxAutoReplyConfiguration cmdlet. The Get-MailboxAutoReplyConfiguration cmdlet reports the current auto-reply state of a mailbox. You can have separate auto-reply messages for internal (any mail-enabled object within the organization) and external senders (anyone else).

A New Auto-Reply for Shared Mailboxes

The example solution uses a quick and dirty script to find all shared mailboxes in the tenant and set two auto-replies on each mailbox. One (brief) for internal correspondents; the other (less terse and nicer) for external people. Two variables are declared to set the start and end time for the scheduled auto-reply. If you specify a time, remember that Exchange Online runs on UTC so any time you set is in UTC. In other words, you should convert your local time to UTC when you set up the auto-reply. Rather bizarrely, Get-MailboxAutoReplyConfiguration converts the UTC time to local (workstation) time when it reports an auto-reply configuration.

#These times are in UTC
 $HolidayStart = "04-Aug-2019 17:00"
 $HolidayEnd = "6-Aug-2019 09:00"
 $InternalMessage = "Expect delays in answering messages to this mailbox due to the holiday between <b>" + $HolidayStart + "</b> and <b>" + $HolidayEnd + "</b>"
 $ExternalMessage = "Thank you for your email. Your communication is important to us, but please be aware that some delay will occur in answering messages to this mailbox due to the public holiday between <b>" + $HolidayStart + "</b> and <b>" + $HolidayEnd + "</b>"
 [array]$Mbx = (Get-ExoMailbox -RecipientTypeDetails SharedMailbox | Select DisplayName, Alias, DistinguishedName)
    ForEach ($M in $Mbx) {
    # Set auto reply
    Write-Host "Setting auto-reply for shared mailbox:" $M.DisplayName
    Set-MailboxAutoReplyConfiguration -Identity $M.DistinguishedName -StartTime $HolidayStart -AutoReplyState "Scheduled" -EndTime $HolidayEnd -InternalMessage $InternalMessage –ExternalMessage  $ExternalMessage -ExternalAudience 'All' -CreateOOFEvent:$True }

The code above uses the Get-ExoMailbox cmdlet from the Exchange Online management module, which is what you should use in Exchange Online. However, the Get-Mailbox cmdlet will work, and it’s what you use for Exchange on-premises.

Figure 1 shows the result when an external person sends an email to a shared mailbox. You can be as creative as you like with the text when you set the auto-reply on the mailbox. Because Exchange stores the auto-reply message in HTML format, most basic HTML formatting commands work when you set auto-reply for a shared mailbox. I only use bolded text in this example, but you could also include something like a mailto: link to tell people who they should contact if someone is out of the office and unavailable.

Removing Auto-Replies

The scheduled auto-reply lapses when the end time arrives. If you want to remove the auto-replies from all shared mailboxes, run the command:

# We assume that all shared mailboxes are in $Mbx
 ForEach ($M in $Mbx) {
   Set-MailboxAutoReplyConfiguration -Identity $M.DistinguishedName  -AutoReplyState "Disabled" }

For more information about working with shared mailboxes, see the Exchange Online chapter in the Office 365 for IT Pros eBook. There’s over a thousand PowerShell examples in the book, including lots of examples of using PowerShell to work with the Microsoft Graph.

Teams and Compliance Records

When people use Teams to communicate, Office 365 captures compliance records in Exchange Online mailboxes. Records for conversations in channels are captured in the group mailbox belonging to the team while records for personal and group chats are in the mailboxes of all chat participants. Teams supports the capture of compliance records for on-premises users in hybrid organizations and for guest accounts using special “phantom” mailboxes. Generally, the scheme works well and the compliance records are available for eDiscovery.

That is, unless your account has a frontline (Office 365 F1) license. In this case, your mailbox quota is 2 GB, which seems enough if it’s only going to be used for an occasional email. But Teams compliance records are charged against the mailbox quota and if the user is involved in many personal or group chats, their quota might be substantially eroded, especially if chat participants share graphics. One of our readers reported that they’ve seen instances where a quarter of the mailbox quota was absorbed by Teams compliance records.

Team Chat Folder

Teams compliance records are stored in the hidden Team Chat sub-folder under Conversation History. Because Team Chat is a system folder that isn’t available to users, you’d assume that its contents would not count against mailbox quota. And for most Office 365 accounts the fact that Team Chat is charged against mailbox quota isn’t an issue because of the standard 100 GB quota.

But the situation is different when a mailbox has a 2 GB quota. I say this in the knowledge that 2 GB is still a big amount. In 1996, original Exchange 4.0 mailboxes enjoyed quotas of between 20 MB and 50 MB. But things are different now. Messages are much larger, we keep everything, and Exchange Online stuffs all manner of data into user mailboxes. In this case, the net result is that a frontline user could find themselves running out of mailbox quota because of compliance records, which doesn’t seem like a good thing.

What You Can Do

Unless Microsoft changes the way they measure usage against mailbox quota, the only thing you can do is to periodically check the consumption of frontline mailboxes to ensure that none exhausts their quota. As usual, PowerShell comes in handy. Here’s a code snippet to process all user mailboxes and report the user, total items in mailbox, total size of mailbox, and the amount taken up by Teams compliance items.

# Find out what Teams compliance record are in user mailboxes
$Mbx = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select Alias, DisplayName, UserPrincipalname
$Report = @()
ForEach ($M in $Mbx) {
 # Retrieve message stats
   Write-Host "Processing" $M.DisplayName
   $MbxStatus = Get-MailboxStatistics -Identity $M.Alias | Select ItemCount, TotalItemSize
   $ConvHistory = Get-MailboxFolderStatistics -Identity $M.Alias -FolderScope ConversationHistory
   $ReportLine = [PSCustomObject]@{
           User          = $M.DisplayName
           UPN           = $M.UserPrincipalName
           MbxSize       = $MbxStatus.TotalItemSize
           MbxItems      = $MbxStatus.ItemCount
           TeamsItems    = $ConvHistory[1].ItemsInFolder
           TeamsSize     = $ConvHistory[1].FolderSize }
   $Report += $ReportLine }
$Report | Sort MbxItems -Desc | Export-CSV -NoTypeInformation c:\Temp\TeamsComplianceItems.csv

The output is a CSV file (Figure 1), as it’s usually easier to analyze this information in Excel.

To improve the script, you could:

• Only process mailboxes that have frontline licenses.
• Convert the mailbox size data returned by PowerShell into numeric values (to make it sortable).
• Add extra mailbox properties to the output.
• Allocate a higher license to any mailbox approaching their quota.
• Go wild with your imagination.

Of course, you could also deploy a Teams retention policy for frontline workers to remove items after a shorter period.

In the meantime, we’ve reported the issue to Microsoft and they are looking into the matter.

For more information about managing Teams, including Teams compliance records, read the Office 365 for IT Pros eBook.

Reclaiming Office 365 Licenses

A reader asks: “I’m in the situation where I need to remove Office 365 accounts fast to free licenses. What’s the best way to do this and will the mailboxes belonging to these accounts become inactive?” We could have referred the reader to Chapter 6 of the Office 365 for IT Pros eBook where the scenario is discussed, but it’s probably worth a blog post too.

Deleting and Restoring an Office 365 Account

The simple answer is that you reclaim an Office 365 license if you remove a user account from the tenant using the Office 365 Admin Center (Figure 1 – new version shown) or by running the PowerShell cmdlets Remove-MsolUser or Remove-AzureADUser.

Deleted accounts go into the Azure Active Directory recycle bin and remain there for 30 days, during which time you can restore them by accessing the Deleted Users section of the Office 365 Admin Center (Figure 2) or by running the PowerShell cmdlets Restore-MsolUser or Restore-AzureADMSDeletedDirectoryObject.

The big point to remember is that restoring a user account makes the account active again, recovers its mailbox, and reconnects it to distribution lists, Office 365 Groups, and Teams. However, the restore process does not reassign the Office 365 license that the account had when you removed it and if you want to make the account fully operational again, you must assign it a license. If you don’t, Exchange Online will remove the mailbox belonging to the unlicensed account after 30 days.

Removing an Account Permanently

If you want to remove an account permanently and you know that you will never want to restore the account, you can force the negation of the 30-day wait period in the recycle bin. To do this, you remove the account as normal (via the admin center or with PowerShell) and then remove it from the recycle bin. For example, here are the PowerShell commands to delete the account and then remove the deleted object.

$ObjectId = (Get-AzureADUser -ObjectId Ken.Jones@Office365itpros.com).ObjectId
Remove-AzureADUser -ObjectId $ObjectId
Remove-AzureADMSDeletedDirectoryObject -Id $ObjectId

There’s no way back once you remove a deleted object from the Azure Active Directory recycle bin; it can never be recovered.

The question then is whether the mailboxes belonging to accounts that are force-removed from Azure Active Directory become inactive. The answer is yes, assuming that a hold exists on the mailboxes before you remove them. If not, the mailboxes are removed along with the accounts.

Outlook Mobile Shared Mailboxes in IOS and Android – Sharing is Caring!

August 29 note: The current versions of Outlook mobile include support for shared mailboxes. See this post for details or read on to learn how to add shared mailboxes to Outlook mobile.

Last week, we learned that Microsoft will soon roll out support for shared mailboxes in Outlook Mobile. Well, some people already have access to the feature through Apple’s Testflight for iOS program. Testflight allows developers to offer test versions of applications like Outlook mobile to people who don’t mind running beta software. The upside is that you see new features sooner. The downside is that the new features might not work or might change before the final version is released. With those caveats in mind, let’s explore how to add a shared mailbox to Outlook mobile using Testflight version 3.27.0.

Add Shared Mailboxes to Outlook Mobile

Before you can add a shared mailbox to Outlook mobile, you should meet these criteria:

• The shared mailbox must already exist on Exchange Online. Outlook mobile can only access existing shared mailboxes; it can’t create a new shared mailbox.
• Your primary mailbox must be in Exchange Online. Users in a hybrid organization whose mailbox is on-premises can’t add shared mailboxes to Outlook mobile.
• Your account has access to the shared mailbox. This means that an administrator assigns your account full access to the shared mailbox. In addition, if you want to send from Outlook Mobile as the shared mailbox, your account must hold SendAs permission for the mailbox.
• You must know the primary SMTP address of the shared mailbox. Why? Because you need to input the mailbox’s SMTP address when you add the shared mailbox.

With everything in place, go to the list of resources available to Outlook mobile and click the + icon and then choose Add Shared Mailbox (Figure 1).

Now input the primary SMTP address of the shared mailbox and click the Add Shared Mailbox button.

That’s all you need to do. Outlook Mobile adds the shared mailbox to its resource list and you can access the contents like any other mailbox.

One big benefit of native support in Outlook mobile for shared mailboxes is that it removes the need for people to use outdated protocols like IMAP4 to access shared mailboxes. From a Microsoft perspective, it gives customers another good reason to move to Outlook mobile and away from apps like the native iOS mail app that use the Exchange ActiveSync protocol to interact with mailboxes (ActiveSync doesn’t support shared mailboxes, which is why people end up using IMAP4).

Outlook Insiders and Testflight

If you want to test shared mailboxes with Outlook Mobile now, you can sign up for the Outlook Insiders program (limited slots are available). You’ll also need to download and install Testflight from the iOS app store. You can then download the test version of Outlook.

One side effect of using the test version is that Office 365 automatically provisions your tenant to use the Microsoft Sync Technology (if it didn’t, you wouldn’t be able to test new features). This process takes about 24 hours. When it’s done, you’ll be able to add shared mailboxes to your heart’s content, but only with iOS clients for now. According to a tweet from Outlook Mobile development last Friday, support for Android is coming “soon.”

Need more information about Office 365 clients, including Outlook Mobile? Read the Clients chapter in the Office 365 for IT Pros eBook!

Removes Need for IMAP4 Workaround

Office 365 notification MC181641 posted on June 5 includes the good news that Outlook mobile (iOS and Android) will soon support connections to Exchange Online shared mailboxes. This will remove the need for the IMAP4 connection currently used as a workaround to access shared mailboxes. Apart from the general kludginess of the IMAP4 workaround, if you log onto a shared mailbox with IMAP4., that mailbox should technically have an Office 365 license.

The development also addresses a huge feature gap that Microsoft has acknowledged to exist for years. This update relates to Office 365 Roadmap items 32571 (iOS) and 32572 (Android) and not the two listed in the announcement.

The announcement says: “You will be able read, write and send emails from the Exchange Online Shared Mailboxes in Outlook for iOS and Android. If you are part of the Office Insider program for iOS and using the Microsoft sync technology (MC165218), you will be able get an early preview of the capabilities via TestFlight this week. It is anticipated that we will start to roll out Shared Mailboxes in Outlook for iOS and Android (using Microsoft sync technology) for general availability in the next several weeks.”

In other words, expect to see shared mailbox support appear in July 2019. That is, if support for the Microsoft Sync Technology is deployed to your Office 365 tenant. To check, look at the settings for your account (Figure 1), or use the PowerShell script in this article.

Microsoft Sync Technology is the new connection protocol for Outlook mobile clients that Microsoft has deployed to Outlook.com and the Government Cloud (GCC) and is now rolling out to commercial tenants. Hopefully, the advent of shared mailbox support serves as a spur for Microsoft to complete the deployment of the new sync technology.

Updated Files, Calendar Events in Search, and Calendar Sync

Microsoft includes some other updates in MC181641. These are:

• Updated Files: The way Outlook mobile presents files will become more coherent with the rest of Office 365 and include a list of recently used files plus cloud sources (like OneDrive for Business or Google Drive). You’ll be able to add a link to share a file that complies with default tenant sharing permissions.
• Calendar Events in Search: When you search for someone or use a keyword, the results returned will include any matching events found in your calendar. This feature also depends on Microsoft Sync Technology.
• Calendar Sync: Outlook for Android now supports syncing calendar events from the native calendar app. This is a one-way sync and Microsoft says that the ability to sync from Outlook to local calendar apps is still in development.

Lots Happening in Mobile

Mobile apps tend to evolve quickly. Outlook mobile is no different. These changes, particularly shared mailbox support, will make many people very happy.

Need more information about Outlook clients? Or Office 365 clients in general? We have a complete chapter on the topic in the Office 365 for IT Pros eBook.

How Outlook 2003 Changed the World of Email Clients

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

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

The Slight Problem of Shared Folders

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

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

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

A New Approach

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

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

Changes Available Now

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

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

No New for Other Outlook Versions

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

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

Connecting Internet Client Protocols to Exchange Online

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

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

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

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

Configuring IMAP4 Access

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

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

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

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

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

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

Handling Calendars

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

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

PowerShell to Set IMAP4 Options

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

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

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

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

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

Sometimes You Want to Get Rid of Inactive Mailboxes

Updated 17 April 2023

Sometimes Microsoft doesn’t communicate changes made to PowerShell cmdlets that introduce interesting new functionality. There’s so much change in the service that they could be forgiven for an occasional slip-up, unless of course you need to use the specific feature that is undocumented.

New Parameters for Set-Mailbox

Which brings me to the well-known Set-Mailbox cmdlet, which boasts two parameters called ExcludeFromOrgHolds and ExcludeFromAllOrgHolds, a fact highlighted by MVP Vasil Michev in his ongoing crusade to discover what’s hidden in the corners of Office 365.

These parameters allow administrators to exclude some or all org-wide retention holds from inactive mailboxes. Remember that an inactive mailbox is one belonging to an Azure AD account that has been deleted but is kept because a hold exists on the mailbox. The hold can be any form of hold supported by Exchange Online, including litigation holds and those set by Office 365 retention policies. Retention holds come in two flavors, org-wide and non-org-wide (in other words, holds that apply to all mailboxes and those that apply to selected mailboxes).

Excluding an org-wide hold means that when Exchange evaluates whether to keep an inactive mailbox, it ignores that hold. If all org-wide holds are ignored, the inactive mailbox will only be kept if a specific non org-wide hold exists.

Controlling Org-Wide Holds on Inactive Mailboxes

Why do these parameters exist? Well, Microsoft introduced inactive mailboxes several years ago as a way for organizations to keep mailboxes around for compliance purposes without having to pay for Office 365 licenses. The most common use case is when mailboxes are kept for ex-employees. The idea is that a tenant will apply a hold to keep the mailboxes inactive for the desired period and then release the hold when the mailboxes are no longer needed.

Org-wide holds apply to both active and inactive mailboxes. Over time, it’s possible that a tenant will add new org-wide holds. The effect is that the set of inactive mailboxes is likely to grow because any mailbox that is deleted will become inactive because one or more org-wide holds exist.

Keeping inactive mailboxes is good if intended. It’s not so good if you don’t want or need those mailboxes. One of the principles of data governance in Office 365 is that tenants should be able to decide what data to keep and what to remove, and keeping inactive mailboxes longer than they should be goes against that principle. I imagine that Microsoft introduced these cmdlets to give tenants the ability to decide what org-wide holds should apply to inactive mailboxes.

Discovering Org-Wide Holds

Org-wide holds are registered in the Exchange Online organization configuration. To see the set, run the PowerShell command:

# Retrieve org-wide holds for the Exchange Online 
Get-OrganizationConfig | Select-Object -ExpandProperty InPlaceHolds

mbx15382841af9f497c83f9efe73e51888d:1
mbx9696959111f74ecda8a40aef97edd2c2:1
mbx703105e3b8804a1093bb5cb777638ea8:1
grp703105e3b8804a1093bb5cb777638ea8:1
mbxc1e2d6f1785d4bf8a7746a26e58e5f66:1
grpc1e2d6f1785d4bf8a7746a26e58e5f66:1
mbxf6a1654abdba4712a43c354e28a4d56c:2
grpf6a1654abdba4712a43c354e28a4d56c:2

The holds we’re interested in start with mbx. Those starting with grp apply to Office 365 Groups. The values following are GUIDs that point to the retention policies defining the holds. If you’re interested in understanding how to resolve the GUID to find the retention policy, see the Compliance chapter in the Office 365 for IT Pros eBook.

Excluding Org-Wide Holds from Inactive Mailboxes

To exclude specific org-wide holds from a mailbox, run the Set-Mailbox cmdlet and pass the GUIDs for the holds you want to exclude in a comma-separated list for the ExcludeFromOrgHolds parameter. Use the same format for the GUIDs as reported by Get-OrganizationConfig. When you run the command, Exchange updates the InPlaceHolds property for the mailbox to note the excluded holds.

# Exclude specific org-wide holds from a mailbox
Set-Mailbox -Identity Kim.Akers -ExcludeFromOrgHolds "mbx9696959111f74ecda8a40aef97edd2c2:1", "mbx19200b9af08442529be070dae2fd54d3:1" 

Microsoft recommends that you use the distinguished name or ExchangeGUID property to identify the mailbox. This is to be absolutely sure that a unique value is passed because if you exclude the holds for the wrong inactive mailboxes, you run the risk that Exchange will remove these mailboxes permanently when it evaluates the holds that exist on them.

To remove all org-wide holds from a mailbox, run Set-Mailbox and pass the ExcludeFromAllOrgHolds parameter. Because you’re now removing all org-wide holds, it’s even more important to be certain that you’re processing the right mailboxes.

#Exclude all org-wide holds from the target mailbox 
Set-Mailbox -Identity $Mbx.DistinguishedName -ExcludeFromAllOrgHold

The Effect of Exclusion

I wrote a script to exclude all org-wide holds from the inactive mailboxes in my tenant. Here’s the relevant code to retrieve org-wide holds from the Exchange Online configuration and exclude inactive mailboxes from the mailbox holds. Figure 1 shows the script running.

[array]$InPlaceHolds = Get-OrganizationConfig | Select-Object -ExpandProperty InPlaceHolds
$InPlaceHoldsMbx = $InPlaceHolds | Where-Object {$_ -like "*mbx*"}

[array]$InactiveMbx = Get-ExoMailbox -InactiveMailboxOnly -ResultSize Unlimited | Select-Object -ExpandProperty Alias 

ForEach ($Mbx in $InactiveMbx) {
   Write-Host ("Excluding inactive mailbox {0} from org-wide holds" -f $Mbx)
   $Status = Set-Mailbox -Identity $Mbx -ExcludeFromOrgHolds $InPlaceHoldsMbx }

Immediately Set-Mailbox processes a mailbox, Exchange evaluated the holds to decide whether to remove the mailbox. After the script finished, the number of inactive mailboxes reduced from 39 to 17. This proves that you need to be ultra-careful when you exclude any org-wide hold from an inactive mailbox.

For more information about managing Exchange Online mailboxes, read Chapter 6 in the Office 365 for IT Pros eBook to discover even more valuable tips and techniques.

The blog posted by the Exchange development group yesterday to announce new tools to migrate from G Suite should really have been titled “migrate email from G Suite” because the solution only handles mail, calendar, and contacts. Or maybe the experience is intended to migrate the bits of G Suite that people really use and ignore Docs, Drive, and the other pieces. In any case, the Exchange guys are obviously very excited that the functionality is now rolling out and should appear in Office 365 tenants over the coming weeks.

The MRS Key to Migration

The advent of better migration tools is a good thing. Microsoft has built the migration on top of a well-known and robust foundation in the Mailbox Replication Service (MRS), which has been moving mailboxes between servers since Exchange 2010. Since its initial ability to move mailboxes from one version of Exchange to another, MRS has expanded its abilities to handle more scenarios and has moved literally millions of mailboxes from on-premises organizations to Office 365 tenants. Now it can move messages, contacts, and calendar items from Gmail to Exchange Online, treating each Gmail user as a migration request and bundling those requests into migration batches that MRS processes in the background.

There’s no great magic involved in connecting to G Suite. MRS uses the IMAP4 protocol to access and read information from Gmail mailboxes. Only 2 GB can be read from a mailbox daily. As Microsoft notes, this limit is enforced by Google (at least the limit is per mailbox). In any case, MRS will process mailboxes larger than 2 GB until they are completely moved over to Exchange Online using incremental synchronization before performing the final switchover. The process will just take a little longer (well, potentially days longer).

Limits

Some limits exist. The default for the largest item is 35 MB, but this can be increased to 150 MB by adjusting the transport configuration of Exchange Online in the target tenant. Note that the size of any message can be larger than expected because of the packaging used to preserve fidelity when messages pass between different servers. The 150 MB limit might, for instance, mean that a Gmail message of 135 MB (including all attachments) can be moved, but depending on the attachments and the format of the message, the limit might be smaller. Like for any other migration, it is a good idea to ask users due to be migrated to find large messages in their Gmail account and remove any that they don’t need to be moved.

Other limits exist in terms of the data that can be migrated. Essentially, users should be prepared to recreate rules and automatic replies and to review contacts after their mailbox is moved. Migration is all about moving mailbox data and not the settings for the Gmail account or other Google-related settings.

Cultural Changes for Users

Another cultural change facing migrated users is the change from Gmail labels to folders. The impact of this might be slight for people who only ever use the Inbox and Sent Items folders, but others who have created their own system of labels to mark and process email will need some coaching to transition to folders, understand the Focused Inbox,(which some people hate), and how Exchange Online archives messages (with retention policies or the Archive option), and other features such as OWA’s clean up mailbox.

If people have used Outlook to connect to Gmail, their transition to Outlook connected to Exchange Online should be smooth. However, their client might need to be updated to make sure that they use a supported version (and if their Office 365 plan includes it, the click to run version). The same is true for people who have used Outlook Mobile to connect to Gmail as Outlook Mobile (considered by some to be the best mobile client for Gmail). On the other hand, those transitioning from the traditional Gmail browser client to OWA will need some retraining to become comfortable with their new mailbox.

More G Suite Data to Migrate

There’s more than email to migrate when an organization moves from G Suite to Office 365. Microsoft suggests that you can move files from Team Drive to SharePoint Online, but there’s also many commercial migration products that should be considered before launching into a full-scale migration.

Going to G Suite?

If you want to go the opposite way and move from Office 365 to G Suite, Google launched the beta of G Suite Migrate in March 2019. In the early days of Office 365, it was quite common to hear about companies moving from on-premises Exchange to Gmail, but that doesn’t seem so common now.

Google’s tool supports migration from Exchange (on-premises and online), SharePoint, OneDrive for Business, and file shares, but misses out big parts of Office 365 like Teams and Planner. All of which proves that migration is a complex business and that any migration project deserves substantial up-front planning before a single byte is moved.

Administrators who move from G Suite to Office 365 need help too. Our advice is to buy a copy of the Office 365 for IT Pros eBook. The book contains far too much information to digest immediately, but it will be a source of comfort as they navigate their new home in the cloud.

Relieves Some of the Boredom Involved in Adding Users

The Office 365 Admin Center and its latest iteration, the preview version of the Microsoft 365 Admin Center (much nicer to use in parts), both offer the option to bulk-create Office 365 accounts. The processing flow is simple:

• Populate a CSV file with account details (a limited number of properties are supported).
• Upload the CSV file to the Admin Center.
• Verify that the CSV file is valid.
• Use the data in the CSV file to create accounts.

The idea is to relieve the tedium of creating multiple accounts, a value that anyone who has had to populate a tenant with account information (for real or to build out a test tenant) can easily recognize. However, there are some issues that need to be taken into account.

Preparing a CSV for Bulk Account Creation

To begin, head to the Active Users section of the Admin Center and select Add multiple users. You now have the choice to download a prototype CSV file to populate with details of the accounts you want to create. If you’ve done this before, you might already have prepared a file for processing – or if you’re very lucky, someone else has done the work manually or by generating the necessary data from another application, like a HR system.

The CSV file is very straightforward. All you really need to populate is the User Name (User Principal Name or UPN), which must be unique. Ideally, the UPN is the same as the email address you want to assign to the new account, and the email address must also be unique. Apart from the UPN, you can leave all the other fields blank except the Country or Region, which Office 365 needs to assign licenses as some features are country-dependent.

As far as I can tell, there’s no limit about the number of accounts you can include in a CSV. However, it’s probably wise to limit the number in a batch to a manageable amount (100 or so). Once you’ve populated the CSV with account information, you can ask Office 365 to verify the information.

Validation is very basic and the errors generated by the process are not very helpful. For instance, it will detect if you include accounts for more than one country and generate an error like:

[{“Row number”:2,”Errors”:[“Invalid domain name used in username. “]},{“Row number”:3,”Errors”:[“Invalid domain name used in username. “]}]

Only engineers would love the formatting of the error report. In any case, don’t expect validation to check that accounts already exist. The real intention of the validation seems to check that the CSV file is in the correct format.

Assigning Office 365 Licenses

Clicking Next brings you to license assignment. Obviously, you can’t assign licenses that you don’t own, but you can create accounts that don’t have the right licenses. One thing that you can’t do is assign different licenses to the accounts you create. You’re limited to the one license for everyone. The limitation on multiple country and license choice within a CSV file is a good reason to divide accounts into batches.

After selecting a license, you can go ahead to the final phase and create the accounts. If all goes well, you’ll have the choice to see the automatically-assigned passwords for the new accounts in email or in a downloadable CSV file. If things don’t go so well, you can download the log file (another CSV) to see errors like

The email address is being used by user (Rory Best) Rory.Best@Office365itpros.com. Please use a different email address.

This error is pretty self-explanatory.

Bare-Bones Office 365 Accounts Generated

Bulk account creation works, but the amount of time the process saves is possibly limited. You must create the CSV file, check that it works, process it, and resolve errors. And then you’ve still got to build out the account to make it fully functional by:

• Adjusting licenses if necessary.
• Adding the new user to distribution lists, Office 365 Groups, and Teams. The new accounts will be added to org-wide teams, if these are available in the tenant.
• Adding manager (reporting) information so that the Office 365 apps can show organizational structures.
• Add a photo for the account.
• Allocate calling plans or numbers if you use Teams or Skype for Business Online to replace a traditional PBX.
• Assign administrative roles.
• Assign extra email proxy addresses (if needed).
• Enable multi-factor authentication.
• Manage mailbox properties, like disabling access to mailboxes via older protocols such as IMAP4 and POP3.

It’s unsurprising that a ton of work remains to transform a bare-bones account to something that is fully usable by the account holder. To be fair to Microsoft, they don’t know how each tenant organizes its affairs, so they have delivered something that works at a basic level for all.

Maybe Roll Your Own Bulk Creation with PowerShell?

Given the situation, a more satisfactory answer for many tenants is to create their own bulk creation process using PowerShell where the script can do all the work to create the Office 365 account, populate all the necessary properties, add the user to appropriate distribution lists, groups, and teams, and so on. Or use what Microsoft provides in the Admin Center and be prepared to fix things up afterwards, perhaps with the assistance of a tool like Hyperfish to find obvious gaps in your tenant directory.

Need help figuring out how to automate Office 365 account creation? The Office 365 for IT Pros eBook has lots of examples of how to use PowerShell to accomplish tasks like account creation, license assignment, joining distribution lists and teams, and so on. You might find your answer in our example scripts!

Exchange Online: Mailboxes at Scale

Exchange Online uses Native Data Protection to avoid the need for backups. Given that the service spans more than 175,000 mailbox servers storing 1.1 exabyte of data, Microsoft’s desire to avoid backups is understandable. At this scale, managing backups and responding to the inevitable requests for restore would be a huge undertaking.

Enter Native Data Protection

Along with features like Single Item Recovery (SIR – enabled for all Exchange Online mailboxes), the Database Availability Group (DAG) is a pillar of Native Data Protection. Every Exchange Online mailbox is in a database with four copies spread across multiple datacenters. One of the database copies is lagged. Microsoft says: “The lagged database copy is not intended for individual mailbox recovery or mailbox item recovery. Its purpose is to provide a recovery mechanism for the rare event of system-wide, catastrophic logical corruption.” In other words, don’t ask Microsoft to recover mailbox items from the lagged database copy. Other methods exist to make sure that items deleted in error can be restored, like the Recoverable Items folder or retention policies.

DAGs depend on log shipping between mailbox servers to keep database copies synchronized. Microsoft introduced the DAG in Exchange 2010 and have improved its resilience and dependability over the three major releases shipped since.

Backup FUD in Office 365

Even with ten years of experience with DAGs, this doesn’t stop some FUD being spread to justify the need for database backups. Take this statement from a white paper distributed by a backup vendor:

…”data is replicated in near real-time between datacenters to ensure very high availability. No snapshots or backups are performed. The drawback of this approach is that any corruption is also replicated with no rollback possible. For legal discovery, this means that messages can be lost…”

The white paper covers Office 365 and is not specific whether the statement applies to SQL (for SharePoint Online and OneDrive for Business), the Azure data services used for Teams and Planner, or Exchange Online (Office 365 stores messages in all these repositories). But that’s the nice thing about FUD: throw something out that’s non-specific and hope that the dirt lands someone interesting.

History of Exchange Corruption

If this was 2002, the assertion that corruption can lead to message loss in Exchange might be true. Those of us who remember the joys of -1018 errors in the Exchange database and the need to run the ESEUTIL utility afterwards to rebuild the database can certainly attest to the woe that logical or physical corruption can wreak on Exchange.

Using Database Copies to Fix Corruption

But the situation has improved enormously since the introduction of the DAG and the Exchange mailbox servers running in the cloud don’t replicate corruption to cause data loss. Bad database pages do occur and if this happens in a single-copy database it can lead to data loss. To avoid this issue, the DAG includes a page patching mechanism to detect and recover from corruption. Here’s some text from my Microsoft Exchange Server 2013 Inside Out: Mailbox and High Availability book.

If the Store detects a problem page in the active database, it places a marker in the log stream (in the current transaction log) that acts as a request for a valid copy of the corrupted page. The request is sent to all database copies, where it is inspected and processed along with other log content. When the Information Store replays data for the passive copy, it notices the marker and responds to the request by invoking a replication service callback to ship a copy of the page to the server that hosts the active database. When this server receives the replicated page, the Store patches it back into the active database to remove the corruption. Other servers that host passive copies might also respond with pages, but these are ignored after the active database has been restored to good health.

The process to fix a corrupted page in a passive database copy is slightly different. In this case, the server that hosts the passive copy immediately pauses log replay. Log copying continues to ensure that all the transaction logs that will eventually be required to bring the database completely up to date are available on the server. The server then requests a copy of the corrupted page from the server that hosts the active database, using the internal ESE seeding mechanism. The active server responds with the page data. The passive server then waits until all the log files necessary to bring it up to date past the point at which the active server provided the page (as indicated by the maximum required generation) have been copied and inspected. When it is sure that all the required data is available, the passive server then restores the corrupt page and resumes log replay to clear the backlog of transaction logs that have accumulated since the corruption was first detected.

In addition to background database scanning, page patching is used by other resiliency features baked into the Information Store, like lost flush detection. Obviously, a feature like this works best when multiple database copies exist to service the request for good pages. That’s why Exchange Online runs with four database copies, one of which is lagged (7 days behind the active copy).

Other features that contribute to avoiding physical or logical corruption in Exchange Online mailbox databases include single bit correction and consistency checking of transaction logs before they are replayed into passive database copies. Exchange Online also uses the ReFS file system for its databases to reduce the chance of storage corruption. In short, there’s a lot of technology deployed to suppress the chance of physical or logical corruption creeping into a mailbox database.

Not Against Backups

Exchange Online uses servers based on Exchange 2019, two full versions past Exchange 2013. Information about how Exchange deals with page corruption within a DAG has been available for a long time. You’d think that people who publish white papers about Office 365 and Exchange Online would take the time to understand how the technology works before concluding that corruption will cause data loss.

I’m not against backups of Exchange Online data, but only if your organization really needs them. Regulations might mandate such a need, but feelings that corruption will happen don’t. And basing an assessment on vendor-provided tommy-rot is never a good plan. If you are interested in Office 365 backups, make sure that you understand the technology, the limitations (including how to restore data into Office 365 in a usable manner), and the cost. And then make your call.

Exchange Native Data Protection is covered in Chapter 4 of the Office 365 for IT Pros eBook.

Outlook Mobile Connects with Microsoft Sync Technology or an Older Protocol

In my Petri.com article about the new architecture (aka, “Microsoft Sync Technology”) Microsoft is deploying to connect Outlook for iOS and Android devices to Exchange Online and Outlook.com, I mention a Microsoft FAQ on the topic. That FAQ includes some PowerShell code to help administrators know what protocol devices use to connect. The code is perfectly good, but being PowerShell, there are many ways to approach a problem and some to improve the solution. Here’s my attempt to do so.

The single-line command (always good) in the FAQ uses the Get-MobileDevice cmdlet to retrieve a list of devices that have connected to Exchange Online, extracts the devices running the iOS or Android client, and reports the protocol each device uses. All good, but the data would be more valuable if you knew who used the devices as well.

Mailboxes, Not Mobile Devices

My solution takes a user-centric approach to the question. The first step to know who is using Outlook for iOS or Android to connect to Exchange Online is to create a set of user mailboxes as they’re the only Exchange objects that can have mobile devices.

Next, we go through the list of mailboxes and use the Get-MobileDeviceStatistics cmdlet to examine details of mobile devices that have “partnerships” with each mailbox. We’re only interested in devices that report running Outlook for iOS or Android. If we find such a device, we grab the statistics like the O/S version running on the device and the date and time of the last successful synchronization. To know what architecture the device uses, we examine the ClientType property, which is “REST” if the device connects using the old architecture, or “Outlook” for the new.

[array]$Mbx = (Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select-Object Alias, DisplayName)
Write-Host "Processing" $Mbx.count "mailboxes"
$Report = @()
ForEach ($M in $Mbx) {
   Write-Host "Checking devices for" $M.DisplayName
   $Devices = (Get-MobileDeviceStatistics -Mailbox $M.Alias | ? {$_.DeviceModel -eq "Outlook for iOS and Android"})
   If ($Devices.Count -eq 0)
      { Write-Host $M.DisplayName "has no Outlook Mobile devices"}
   Else 
      { ForEach ($D in $Devices) {
        $ReportLine = [PSCustomObject]@{
           User     = $M.DisplayName
           Device   = $D.DeviceFriendlyName 
           OS       = $D.DeviceOS
           SyncType = $D.ClientType
           LastSync = $D.LastSuccessSync}
      $Report += $ReportLine }
  }
}

Examining Connection Details

To see what data our code generates, we examine the $Report variable.

$Report | Format-Table User, Device, SyncType, Lastsync, OS

User            Device          SyncType LastSync             OS
----            ------          -------- --------             --
Deirdre Smith   Outlook for iOS REST                          iOS 12.1
Deirdre Smith   Outlook for iOS REST     24 Aug 2018 17:30:53 iOS 11.4.1
Deirdre Smith   Outlook for iOS REST     4 Dec 2018 21:27:16  iOS 12.0
James Ryan      Outlook for iOS REST     10 Oct 2018 16:22:52 iOS 12.0
Tony Redmond    Outlook for iOS REST     1 Oct 2017 18:13:27  iOS 10.3.3
Tony Redmond    Outlook for iOS REST     4 Dec 2018 22:32:34  iOS 12.0

At the time of writing, clients in my tenant still use the REST protocol that’s soon to be replaced by the Outlook protocol. See the Petri.com article for details.

Of course, if we need to do some deeper analysis, we can output the information to a CSV file with another command. The CSV file can then be loaded into Excel or Power BI to slice and dice the data, generate graphs, and so on.

$Report | Export-CSV -NoTypeInformation c:\temp\OutlookMobileDevices

Easy!

For more information about Office 365 clients, read Chapter 10 of the Office 365 for IT Pros eBook, while Chapter 18 covers mobile devices.

The Need for a Nice Clean Mailbox

Note: Search-Mailbox is due for deprecation on July 1, 2020. See this post for more information.

Another question, this time from the Facebook Office 365 group:

“How can i delete a whole bunch of emails in a shared mailbox using the online mail browser? (instantly)“

It’s quite common to find that a clean-up is needed for shared mailboxes. It might be possible to do the job manually by selecting and removing the messages, or using OWA’s Cleanup mailbox option, but both options can take a long time to run and move items into the Deleted Items folder, where you might want to remove the items permanently.

Cleaning Options

The OWA options are user-driven and can be applied to any mailbox to which a user has access. The other available options are administrative actions. Let’s assume that you want to cleanup a mailbox with an Inbox folder of 100,000 items. This is well under the Exchange Online folder limit of 1 million items, but it’s still a bunch of data to process. Here are three obvious actions that can be taken:

1. Use the Search-Mailbox cmdlet to remove items from the mailbox. The upside is that Search-Mailbox can remove the items permanently; the downside is that Search-Mailbox only returns 10,000 items at a time, so it can only remove 10,000 items. Ten searches are needed to remove our 100,000 items.
2. Apply an Exchange mailbox retention policy to the Inbox folder to remove all items after they are “x” days old (let’s say 7). The upside is that the Managed Folder Assistant does its processing in the background and can remove items permanently. The downside is that the Managed Folder Assistant might not process the mailbox for another seven days (the workcycle used in Exchange Online), and you will have to wait for its completion to see the results of its work.
3. Create a new mailbox and switch it in to replace the old mailbox. The upside is that you get a clean mailbox immediately, which is what you want. The downside is that you might need to recover items from the old mailbox before it is discarded. As was pointed out to me, make sure that the new mailbox has the LegacyExchangeDN of the old mailbox as a proxy X.500 address so that messages sent to the mailbox using addresses stored in user autoaddress caches don’t NDR.

Other available methods include creating some Exchange Web Services (EWS) code to delete the items or run an Office 365 content search to find the items and then remove them. There are two things to remember about using a content search to remove items. First, the actions supported by content searches only include soft deletes. Second, a content search can only remove 10 items at a time.

The Best Choice

If you need a clean mailbox as quickly as possible, the new mailbox approach might be best. If you want to keep the existing mailbox only but need it cleaned up as quickly as possible, Search-Mailbox is probably best used (assuming that your account has the necessary permissions).

But overall, if you want to impose control on a mailbox that tends to swell in terms of messages, use retention policies to keep a cap on what’s stored. Because it can apply policies to specific folders, an Exchange mailbox retention policy is more precise than an Office 365 retention policy.

——————————————-

For more information about mailbox management, read Chapter 6 of the Office 365 for IT Pros eBook. Retention policies and the Managed Folder Assistant are covered in Chapter 19.

A New Way to Block Forwarding of Important Meeting Requests

Microsoft has started to roll out a new feature in Exchange Online, OWA, and Outlook 2016 (click to run) to stop people forwarding meetings when meeting organizers don’t want them to do so. You know the scenario: someone sets up an interesting meeting with a well-chosen list of attendees to figure out how to solve a problem and next thing you know, 50 people turn up to meet in an overcrowded room because some of the invited attendees decided to pass on the meeting notification to their colleagues.

By default, meetings can be forwarded, but now organizers have a new option in Outlook 2016 and OWA (see below) to disable forwarding of their meetings.

When an attendee opens the meeting request, the client disables the forward option.

Of course, an attendee could create their own meeting request and cut and paste the meeting details into that request and send it to whomever they like, but that’s probably too much work. This fix cuts out casual forwarding, and that’s what it is intended to do.

Supported Clients

The new feature is now available in OWA, Outlook 2016 (click to run version 1808 – I see it in client build 10730.20102). Microsoft says that it is coming to Outlook for Mac soon. It is not available in Outlook 2016 MSI clients. Only users with Exchange Online mailboxes can blocking the forwarding of meetings.

Many Unsupported Clients

Obviously, there’s lots of unsupported clients in use today. An unsupported client doesn’t have the user interface to disable meeting forwarding or to stop someone forwarding a meeting that the organizer has blocked. It therefore follows that people who receive blocked meetings might try to forward them.

To make the block more effective, Microsoft has included a check in the code that submits messages to the Exchange transport service to validate that someone has the right to forward a meeting request. To have that right, the submitter must be the meeting organizer or a delegate of the meeting organizer. Users assigned editor access to the organizer’s calendar can also forward meetings, but only if they are granted that right under the new calendar sharing model. Those with editor rights granted under the old model can’t forward meetings.

If the submitter has the right to forward a meeting, transport accepts and processes the message. If they don’t, transport politely declines the message and issues a non-delivery notification.

This block is built into Exchange 2016 (latest cumulative update), Exchange 2019, and Exchange Online, so anyone with a mailbox connected to one of those servers respects blocks set on meeting forwarding. If someone using an older Exchange server or a non-Exchange server receives a meeting request, they can anything they want with it because the block isn’t available.

The formal Microsoft support article is available online. We cover calendar sharing in Chapter 6 of Office 365 for IT Pros. And if you’re at Microsoft Ignite, check out session BRK3146 to discover all the new stuff that’s happening in Outlook calendaring.

The Curious MC146221 Update

Microsoft published update MC146221 in the Microsoft 365 Message Center on August 8, 2018. The text is a masterpiece of obfuscation. It announces a new feature, but really what is happening here is that Microsoft has fixed a bug in the Set-UnifiedGroup cmdlet so that you can remove proxy email addresses from a Microsoft 365 Group. Although the notice says that Microsoft is releasing a new cmdlet, it’s just a fix for a cmdlet that’s been around since the introduction of Microsoft 365 Groups in November 2014.

Reclaiming an Email Address

When Microsoft says that “it was not possible to reclaim email addresses of Groups,” it means that the Set-UnifiedGroup cmdlet didn’t work when you tried to remove a proxy address from the set in a group’s EmailAddresses attribute. The bug has now been fixed.

In the following example, we examine the set of addresses for a group and then remove one. When we check the EmailAddresses attribute again, the address we removed is gone, which is what we want. In Microsoft terms, the address is reclaimed because it can now be assigned to another mail-enabled object.

Get-UnifiedGroup -Identity BankingTeam | select -ExpandProperty emailaddresses
SMTP:BankTeam@office365itpros.com
smtp:BankingTeam@Office365itpros.com
smtp:BankingGroup@Office365itpros.com
smtp:CorporateBanking@office365itpros.com
SPO:SPO_d8f732ac-454e-4ba1-b596-c2c5effb911d@SPO_b662313f-14fc-43a2-9a7a-d2e27f4f3478

Set-UnifiedGroup -Identity BankingTeam -EmailAddresses @{Remove="BankingTeam@Office365itpros.com"}
Get-UnifiedGroup -Identity BankingTeam | select -ExpandProperty emailaddresses

SMTP:BankTeam@office365itpros.com
smtp:BankingGroup@Office365itpros.com
smtp:CorporateBanking@office365itpros.com

Note: Don’t try to update the SPO proxy address for groups. These addresses are used for internal links with SharePoint Online.

The same syntax can be used to add a new SMTP proxy address or MOERA address to a group. These commands create two new proxy addresses, the latter being a MOERA address.

Set-UnifiedGroup -Identity BankingTeam -EmailAddresses @{Add="Banking.Team.Winners@Office365itpros.com"}
Set-UnifiedGroup -Identity BankingTeam -EmailAddresses @{Add="Banking.Team.Winners@Office365itpros.onmicrosoft.com"}

To set a new primary address, run Set-UnifiedGroup -PrimarySmtpAddress and select one of the proxies already present for the group:

Set-UnifiedGroup -Identity BankingTeam -PrimarySmtpAddress Banking.Team.Winners@Office365itpros.com

Restrictions in SMTP Address Assignment

You can’t remove the primary SMTP address of a group without reassigning primary status to another address first. Also, you can’t remove the MOERA address from a group (unless another exists). MOERA stands for Microsoft Online Email Routing Address. It is an SMTP proxy address from the tenant’s service domain (the one that looks like office365itpros.onmicrosoft.com).

In the past, all Microsoft 365 groups only had MOERA addresses. This situation persisted until Microsoft introduced support for email address policies for groups, a capability which allows administrators to dictate that the email addresses assigned to new groups come from a selected domain. Even if email address policies are in force, Exchange Online makes sure that new groups receive a MOERA SMTP proxy address.

Administrators can only remove a MOERA address from a group if another MOERA address is present in the set of proxy addresses for the group. In other words, before attempting to remove a MOERA address from a group, assign another to take its place. If you don’t, Exchange Online signals the error:

“There should be atleast one MOERA in Email Addresses.”

And yes, there’s no space between at and least in the error message.

Be Careful

Before you rush out to reclaim addresses, remember why SMTP proxy addresses exist. If you remove an address from Object A and assign it to Object B, any email sent to that address will be delivered to Object B. This might not be what you want to happen. Keeping old proxy addresses in the set assigned to mail-enabled objects allows those objects to continue receiving email for old addresses after updates to the primary SMTP address or MOERA address.

Retaining old proxy addresses might not be so important for a Microsoft 365 group because most of the traffic to group mailboxes is typically internal, but it is for recipients which receive a higher volume of external email such as user and shared mailboxes.

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.

Search-Mailbox – Powerful but Limited

Note: Search-Mailbox is due for deprecation on July 1, 2020. See this post for more information.

Search-Mailbox is a very powerful cmdlet. It can search user mailboxes to find and remove content, or copy content to another mailbox, or both. The usual situation when Search-Mailbox is called into use is when someone, invariably an important person (in their minds, anyway), makes a mistake and sends email when they shouldn’t have and now wants every trace of the message eradicated. Search-Mailbox can do this, but only within the boundary of a single Office 365 tenant, and only in user and shared mailboxes.

Another common scenario is when some inappropriate or malicious content is circulating in email. If you can construct search criteria to find the bad content, Search-Mailbox can track it down and erase it, again from user and shared mailboxes.

No Group Mailboxes

Search-Mailbox can’t deal with group mailboxes, so it cannot erase content posted to the Inbox of Office 365 Groups nor can it remove Teams compliance records from the Team Chat folder. Removing compliance records might seem to be a bad thing, and normally it is, but if you do this to force Teams to synchronize the deletions back to its Azure data services and so remove the bad content from channel conversations, it could be a good thing. If, that is, appropriate authorizations are sought and granted to allow deletions to proceed.

The reason why Search-Mailbox is limited to user and shared mailboxes is that it was built many years ago to run inside an Exchange on-premises environment where the only objects it might have to process were user and shared mailboxes. Apart from making sure that it can understand queries expressed in KQL-syntax, Microsoft hasn’t done much to Search-Mailbox since Exchange 2010.

Dealing with Non-Mailbox Content

Search-Mailbox cannot process documents stored in SharePoint or OneDrive for Business libraries, or sways, plans, or forms, or any of the other non-Exchange content created by users and found inside Office 365.

If you need to run a search to find information across all the Office 365 workloads, you can use a content search, which covers Exchange (including public folders), SharePoint, OneDrive, and Teams. Once you’ve found the information, you can add a purge action to the search and have it remove items. But here’s the downside – content searches can only purge 10 items at a time and can only soft-delete information. In other words, the deletions can be reversed.

Hard Deletes

Probably with good reason, Microsoft has not yet allowed content searches to hard-delete items from the workloads it supports. Perhaps this is because the same kind of backups that exist on-premises don’t exist in the cloud, and if you made a mistake and permanently removed some information, Microsoft wouldn’t be able to retrieve that information. When backups don’t exist, soft-deletion and a nice period in a recycle bin seems like a good idea.

But Search-Mailbox does hard-delete items, which is what you want to do with malware or other objectionable material in mailboxes, so it’s a powerful tool that needs to be handled with care.

For more information about Search-Mailbox, see Chapter 6 of Office 365 for IT Pros. For more information about content searches, see Chapter 20.

A recent post by MVP Mark Vale describes how to use synchronization transformation rules in AADConnect to change the last name, first name format (for example, Smith, James) for display names to a more user-friendly first name last name format (our example becomes James Smith) for accounts as they synchronize to Azure Active Directory from an on-premises Active Directory. The lastname, firstname format is very popular in large-scale on-premises deployments where more control can be exercised over the displayname format. You don’t have the same degree of control in Office 365.

The Default Office 365 DisplayName

The idea behind transforming displaynames is driven by the fact that Office 365 uses first name last name as its default way to refer to users, including to form the default alphabetical avatar that appears when a photo isn’t available for a user account. Or, as shown in Figure 1, when an Office 365 app gets it wrong (in this case, the Admin Center) and forgets how to find the user photo.

If the last name, first name format is used for displaynames, my avatar shows up as RT. You can now see the problem. I would always know myself as TR, but never as RT.

Other apps, like Outlook Web App (Figure 2) are better at finding the user photo. It’s always best inside Office 365 when you populate user accounts with photos. And if you have photos for tenant users, you should have photos for guests too.

@Mentions Are a Big Influence

In any case, the idea is that it’s nicer and more user-friendly for people if they can refer to their peers by their first name in the @mentions used in apps like Teams and email. Certainly, it does seem better to say something like “Perhaps @James Smith can help” instead of “Perhaps @Smith, James can help.” Or even, if you work in an organization that has a very large GAL and needs to differentiate people who share a common name, “Perhaps @Smith, James (Operations Dept x1514) can help.”

Thinking and Testing Required

Changing the displayname format is not something to do lightly. You might think that it’s a simple matter of throwing off the shackles of on-premises directory organization, but it could have consequences such as creating problems for user documentation or the help desk, or even confusing users as they try to find other people in the GAL after they move to Office 365.

Remember that a change made to Azure Active Directory (which is what you do if you change a synchronization rule) affects everywhere in Office 365 where a user displayname appears. You can’t have a situation where the GAL is ordered by the traditional last name and @mentions are auto-magically transformed into user-friendly first names. Some thinking, planning, and testing is needed before you take the plunge. This is especially so in situations where the organization includes large numbers of people who share last names. Consider how a change will affect people in different countries instead of assuming that everything will go well because the new format works for your name.

Easing the Way to the Cloud

Overall, if you can make the transition from the old displayname format to the default used in Office 365, you’ll probably ease the transition from on-premises to Office 365. It’s something worth thinking about.

For more information about setting up and running AADConnect to link an on-premises Exchange organization with Azure Active Directory, see Chapter 3 in Office 365 for IT Pros.

Removing Users from Office 365

Microsoft issued a new wizard to delete Office 365 accounts last week. It has the normal quota of cute graphics and some glitches to boot, but the wizard gets the job done in terms of converting a user mailbox into a shared mailbox and reassigning access to their OneDrive for Business account.

This article was published on Petri.com August 7, 2018.

For more information about how to delete users from Office 365, see Chapter 6 in the main book.