Identify Problematic Shared Mailboxes using Sign-in Logs

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

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

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

No Need Exists to Sign Into Shared Mailboxes

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

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

Microsoft documentation says:

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

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

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

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

Checking for Illegal Shared Mailboxes

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

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

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

Other Checks

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

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

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

Updated 24-Oct-2023

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

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

Exchange Historical Message Traces

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

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

Submit a Historical Message Trace and Wait

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

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

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

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

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

Processing Historical Message Trace Results

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

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

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

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

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

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

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

Creating a report from the discovered items is simple:

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

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

Getting the Job Done

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

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

Shared Mailbox License Only Needed Under Three Specific Conditions

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

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

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

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

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

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

Finding Shared Mailboxes that Need Licenses

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

The steps seem easy enough:

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

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

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

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

Analyzing the Outcome

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

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

Shared Mailboxes Don’t Need Much Attention

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

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

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.

Deploying Technology to 100-plus Million Users

After the note about the launch of shared mailbox and dark mode support for Outlook mobile appeared, several people commented that they had the latest client but couldn’t access the shared mailbox feature. This prompted me to have a conversation with Microsoft to find out how they deploy new features to what is now a very large (100+ million as of May 2019) installed base.

Outlook Mobile has both consumer and commercial (Office 365) users. Some features, like dark mode, are available to both sets while others, like shared mailboxes, are only available to commercial customers. The deployment mechanism needs to take account of these factors.

Random Selection During Roll-Out

When Microsoft releases a new Outlook mobile feature, they select a random percentage of the worldwide installed base as the initial roll-out target. For features like dark mode intended for use by any Outlook mobile user, the random selection is formed of individual commercial and consumer users. Commercial-targeted features like shared mailboxes begin deployment to a random selection of Office 365 tenants. If the selection is user-based, selected users can access the new feature immediately while others in the same tenant must wait until the roll-out reaches them. If the select is tenant-based, everyone in the selected tenants can access the new feature once the tenant is enabled.

Eventually the roll-out reaches 100% and everyone who has the latest version of the Outlook mobile app (iOS or Android) can access the new feature. The exact timing from start to finish of a roll-out varies across features and depends on factors such as bug reports or problems detected in the telemetry Microsoft gathers from Outlook clients.

No Control for Office 365 Tenants

Office 365 tenant administrators can’t influence the selection of their tenant or users within their tenant to receive new Outlook mobile features early. There’s no equivalent of the Targeted Release capability that exists for Office 365 features. There’s also no way for a tenant administrator to know who in the tenant might have been randomly selected to receive early access to a new feature. One way of looking at this is to say that random selection is fair to everyone; another is to say that Microsoft should give tenants some control over how new client technology is deployed to their users. On balance, it seems to me that Microsoft should provide some way to control deployment of commercial features, perhaps as a setting available through the Office 365 Admin Center.

There’s also no way to disable one or more Outlook Mobile features on a selective user-by-user basis. This might be useful for commercial features where some tenants don’t want people to use certain capabilities (like shared mailboxes) on mobile devices.

Testflight Makes a Difference

Those who sign up for the Outlook Insiders program and use the Testflight version of Outlook for iOS are not restricted by the random selection process and can use new features as Microsoft deploys them to Testflight. This can lead to an interesting situation where a tenant account can access a new feature through Testflight while another account in the same tenant can’t when using the production version of Outlook for iOS.

Need to know more about Outlook Mobile and other Office 365 clients? The Office 365 for IT Pros eBook covers this topic in some detail!

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.

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.

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.