Focus on Improving Email Security Continues with Inbound DANE with DNSSEC

To their credit, over the past few years, Microsoft has steadily increased the security of Exchange Online email services. Some of the measures taken, such as restricting the versions of on-premises servers that can send messages to Exchange Online via an inbound connector, didn’t get good press when announced or when the restriction came into effect. I haven’t heard much about the issue recently and guess that those running hybrid organizations have bought into the need to keep their on-premises Exchange servers updated.

Other initiatives to enhance the security of email, like support for MTA-STS and DANE with DNSSEC for outbound email, were less controversial. Some tenant administrators probably didn’t pay much attention to these advances because they use default settings for email security and are happy to let Microsoft manage those defaults. But making sure that SMTP-based email transmission is as secure as possible is a major concern for many large organizations (and some small tenants too).

The Licensing Conundrum for Inbound DANE with DNSSEC

Which brings us to June 3, 2024, and Microsoft’s announcement of the preview of DANE with DNSSEC support for inbound email. On the surface, there was nothing remarkable about the announcement. Microsoft has been open about their intention to implement DANE with DNSSEC for Exchange Online since April 2020 and adding support for inbound email complements the existing support for outbound mail. Then people noticed that support for the new capability (when generally available) required tenants to have Microsoft 365 E5 licenses. This came as a complete surprise and led to widespread criticism.

Requiring Microsoft 365 E5 licenses might have kept bookkeepers happy, but it wasn’t the right thing to do. Inbound support for DANE with DNSSEC adds to fundamental email security. It’s not like upgrading from Exchange Online Protection to Microsoft Defender for Office 365 to gain some extra features to help an organization deal with inbound spam.

The good news is that the Microsoft 365 messaging team took the criticism on board and withdrew the preview software. After taking six weeks or so to contemplate their next steps, on July 17, Microsoft announced that the public preview for inbound support for DANE with DNSSEC doesn’t require any high-end licenses (message center notification MC711018, Microsoft 365 roadmap item 63213). The updated documentation for the feature contains no mention about licensing requirements, so plain old Exchange Online does just fine.

The Implementation Timeline

The preview is now available. Some tenants might need to wait until July 19 before the Enable-DnssecForVerifiedDomain cmdlet becomes available. You will need to install V3.5.1 of the Exchange Online management module to see the cmdlet. Here’s a handy script to update Microsoft 365 PowerShell modules.

The remaining timeline goes like this:

• August 2024: An Inbound DANE with DNSSEC and MTA-STS report is available in the Exchange admin center.
• October 2024: General Availability of Inbound DANE with DNSSEC.
• By the end of 2024: Microsoft begins to deploy inbound DANE with DNSSEC for all Outlook domains. These are the Microsoft consumer email services like Hotmail.com, Outlook.com, and their country-level domains. Microsoft says that they have already updated several domains.
• Newly created Microsoft 365 tenants will have DNS records created for them in the DNSSEC-enabled messaging infrastructure under the *.mx.microsoft root. See this article for more information about the changes planned for DNS records.
• February 2025: Mandatory Outbound DANE with DNSSEC set per-tenant/per-remote domain.

Towards a More Secure Messaging World

It’s easy to see how DANE with DNSSEC will become the norm for all Exchange Online domains in the future. The transition should be smooth for most, but any tenant that uses a third-party email hygiene system or connector needs to check that all elements of their mail transport infrastructure can accommodate inbound DANE with DNSSEC.

Microsoft nearly made a big mistake by insisting on high-end licenses for a fundamental piece of messaging security. They made the right call by retreating from that position. Let’s hope that the trend continues to improve and enhance the messaging security for Exchange Online.

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

SMTP AUTH Client Connections Deprecated in 2025 Together with Introduction of a New External Recipient Rate Limit

The Exchange development team has clearly been busy lately. On April 15, 2024, they announced two major changes:

• The deprecation of basic authentication for client submission (SMTP AUTH) in September 2025.
• The imposition of a new external recipient rate limit (ERR limit) from January 1, 2025.

Microsoft says that both announcements are part of the work to protect Exchange Online.

SMTP AUTH and Basic Authentication

The announcement about the demise of SMTP AUTH is not unexpected. For the past several years, Microsoft has steadily removed basic authentication (sending plain text credentials over a network connection) for email connectivity protocols. SMTP AUTH was left untouched by the previous initiative because this protocol is used by apps and devices to submit email for processing by Exchange Online (hence the client submission moniker). For instance, multifunction devices like printer/scanners can submit messages to inform users when their jobs are complete. Apps often submit email to transmit the results of processing to users. This includes the use of the PowerShell Send-MailMessage cmdlet.

The route forward is for developers to replace basic authentication with OAuth. It’s a perfectly acceptable resolution if developers are available to fix the problem. I suspect that organizations will discover that many apps and devices are unable to transmit messages when Microsoft imposes the block to close off basic authentication for SMTP connections in September 2025. And in some cases, it might not be possible to get an update to allow multifunction devices to continue to send email.

To help, Microsoft says that they will update the SMTP AUTH Clients Submission Report in the Exchange admin center to indicate the protocol used to submit messages. They plan to follow up with message center notifications to tenants that continue to use SMTP AUTH in January 2025 to say that they must make changes. In August 2025, a final countdown notice will be issued to tell tenants still using SMTP AUTH that the block is about to descend.

The plan seems good, but human nature has the potential to get in the way. It’s well known that many tenant administrators are not as diligent (or curious) as they should be in reading message center notifications and reacting where action is necessary. The previous project to remove basic authentication from email connection protocols ran into this problem and it’s possible that Microsoft will need to delay the final depreciation. Nevertheless, the die is cast and people should realize that SMTP AUTH is on the way out, and soon.

The HVE Alternative

Microsoft positions the new High Volume Email (HVE) feature as an alternative for customers who cannot move to OAuth authenticated SMTP connections. Announced in preview on April 1, 2024, HVE will allow apps and devices to connect to a different SMTP endpoint with basic authentication and send messages. Azure Communication Services is another alternative.

The downside of both suggestions is that using these services will cost where sending email using SMTP AUTH is free. Microsoft will point to the need to secure and protect Exchange Online and their long-held position that Exchange Online is not intended for bulk email as justification for diverting customers to HVE and Azure Communication Services. It’s a defensible position in some respects, but at the end of the day, it depends on how much the transition and ongoing operations cost.

Clamping Down on External Email

Speaking of HVE, it’s also associated with the introduction of an external recipient rate (ERR) limit. Today, the Exchange Online recipient rate limit controls the number of individual recipients for outgoing messages that can be on messages sent from a mailbox. The current rate is 10,000 recipients daily. When computing the number of recipients in a day, a distribution list or Microsoft 365 group counts as a single recipient.

The recipient rate limit has been in place for years. What’s different is the amount of email generated by spammers who sign up for Microsoft 365 tenants and use low-cost licenses to create and send email. The spammers can transfer licenses from mailbox to mailbox to send more email or send from shared mailboxes, which don’t need licenses unless they have an archive or need a 100 GB quota.

Spam doesn’t stay inside a tenant. It goes to external recipients. Today, the recipient rate limit allows a single mailbox to send to 10,000 individual recipients (or a lot more if distribution lists are used). Imposing the ERR at 2,000 messages (for new tenants from 1 January 2025 followed by existing tenants from July 2025) is a way to make Exchange Online less attractive to spammers. Microsoft’s announcement doesn’t cover whether this rate applies to email sent across a connector to Exchange on-premises servers in a hybrid environment. Other scenarios remain to be parsed out over the coming months.

However, I think the ERR is a short-term sticking plaster. I cannot believe that the world’s largest software company cannot implement a spam check in the transport pipeline to detect and block outbound spam – or at least, severely throttle outbound email that seems to be spam. You’d hope that a Copilot for Spam could detect and suppress spamming but given the ongoing problems Exchange Online Protection has in detecting some obvious malware that reaches user inbox, perhaps this is hoping for too much.

An Ongoing Battle

What’s for sure is that Microsoft continues to apply a squeeze on behaviors considered to conflict with the terms of service for Exchange Online or the real need to keep email secure for the over 400 million paid Office 365 seats. I don’t think we can quibble too much with initiatives to make email work better, even if some doubts exist about quite how the steps Microsoft is taking now.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

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.

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

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

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

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

Block to Stop Offboarding Auto-Expanding Archives to Exchange Server

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

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

Important Points About Auto-Expanding Archives

Other important facts about auto-expanding archives include:

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

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

Enable-Mailbox -Identity Terry.Hegarty -AutoExpandingArchive 

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

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

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

Not Many Organizations Use Auto-Expanding Archives

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

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

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

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

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

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

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.

October 1 Marks the Start

On May 3, Microsoft published its May update describing progress toward their goal of removing basic authentication for seven email connection protocols starting in October 2022. With 150 days to go, Microsoft wants tenants to make sure that they’re prepared for the big turnoff.

Update (September 1): Microsoft is granting tenants the ability to get a three-month extension before retiring basic authentication. See this article for more detail. January 1, 2023 is the new drop-dead date.

By now, there should be no need to rehearse the logic behind the move. Basic authentication for email is a major vector for the compromise of user accounts. Attackers use techniques like password sprays to penetrate accounts using the flimsy protection afforded by basic authentication and proceed to wreak havoc. Business email compromise (BEC) leading to financial loss is only one of the joys available following account penetrations.

Five Big Points to Understand

Among the nuggets in Microsoft’s post, I noted five important points:

• They have already disabled basic authentication in millions of tenants that were not using the affected protocols. “Millions” is the keyword here. It demonstrates the scale and scope of this effort and the size of Exchange Online.
• Disabling of basic authentication for Exchange Web Services (EWS), Remote PowerShell, POP3, IMAP4, MAPI over RPC, Exchange ActiveSync, and the Exchange Offline Address Book (OAB) commences on October 1. Remember the scale of Exchange Online? It will take time for Microsoft to work through all the Office 365 data center regions to turn off the protocols for millions of tenants. They anticipate completion at the end of 2022, but protocol disablement could come to your tenant at any time after October 1, so you need to be prepared.
• No one gets to vote when Microsoft blocks basic authentication for their tenant. Selection is random. It just happens.
• SMTP AUTH is an exception and support of basic authentication for this protocol continues for now. But that’s no reason to ignore the bright lights signaling that Microsoft is likely to disable basic authentication for SMTP AUTH soon. Microsoft isn’t saying when they will proceed, but you should start to upgrade scripts and devices which send email using SMTP AUTH connections to Exchange Online as soon as possible.
• Apple devices running recent operating systems that use Exchange ActiveSync to connect the native Apple Mail app to Exchange Online mailboxes can use modern authentication. However, the configuration of the connection to Exchange must specify modern authentication. If a new device copies an existing configuration from an old device (for example, when someone updates an old iPhone to the latest model), the configuration might specify basic authentication. These devices won’t be able to connect to Exchange Online after Microsoft blocks basic authentication. Read this article for more information and consider auditing Apple device connections to identify the devices still using basic authentication.

Use Authentication Policies to Block Protocols

Another important point is that authentication policies are available to block basic authentication for selected protocols now. You can be proactive and block protocols like POP3 and IMAP4 that attackers love using to compromise accounts. It’s a good step to take to stop people using old and vulnerable clients.

A tenant administrator might be lulled into a false sense of security because they’ve deployed Azure AD conditional access policies to protect user accounts, or because they’ve disabled protocols like POP3 and IMAP4 for mailboxes through the Set-CasMailbox cmdlet. These are good steps to take, but they only kick on after an account successfully authenticates – and that might be too late. Blocking protocols with authentication policies stops attackers from authenticating (and knowing that they have valid credentials), meaning that attempted attacks come to a crashing halt.

Time to Get Going

When this post appears, it will be 147 days until 1 October. Three days have slipped away since Microsoft posted its blog. If you’ve had other things on your plate and haven’t progressed the preparation for the big basic authentication turn-off, it’s time to get going.

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

Update Exchange Online Organization Configuration by April 17

Last August, I reported that Microsoft intended to introduce plus addressing by default for Exchange Online for all tenants. Exchange Online plus addressing is enabled for new tenants already. At the time, Microsoft’s target date to switch on plus addressing for all tenants was January 2022, but like many other Microsoft 365 features, the pace of development to create tenant-ready features can slow. This is especially true when customers affected by the change make their feelings known to Microsoft.

When released in preview in September 2020, tenants could opt-in to enable plus addressing early by updating the organization configuration. Microsoft is now making another setting available to allow tenants to opt-out of Exchange Online plus addressing before Microsoft starts to roll-out the change to make plus addressing available by default in mid-April 2022. The roll-out is scheduled to complete by mid-May.

Why You Wouldn’t Want to Use Plus Addressing

The usual reason why organizations don’t want to use Exchange Online plus addressing is that they’ve configured a bunch of mail-enabled objects with proxy addresses which contain the plus character. This was the only way that Exchange Online supported plus addressing in the past and it might be the case that organizations have deployed these addresses to support business processes.

The new method introduced for Exchange Online plus addressing removes the need to create and assign proxy addresses (which can only be done by administrators). Instead, end users can create their own plus addresses using clients which support the feature, like OWA and Outlook desktop. So far, I can’t see how to create a plus address using Outlook mobile. It’s also unlikely that non-Microsoft clients will support the feature in the short term.

Opt-Out for Plus Addressing

Announced in message center notification MC343788 on March 16, Microsoft says that if an organization wants to opt-out of plus addressing, they can do so by logging into a PowerShell session with the Exchange Online management module and running the command:

Set-OrganizationConfig -DisablePlusAddressInRecipients $True

Checking my tenant, I discovered that DisablePlusAddressInRecipients is set to False, which implies that Microsoft has already populated the setting to tenants. If you want to opt-out, you need to update it to True before April 17. In other words, a 30-day countdown clock has started for organizations to decide if they wish to use Exchange Online plus addressing before Microsoft switches on the feature.

When Microsoft deploys the plus addressing update to tenants, it will remove the old AllowPlusAddressInRecipients organization setting used to control the preview and respect the DisablePlusAddressInRecipients setting. If you find at that point that some proxy addresses exist which contain the plus character, you can disable plus addressing by updating the setting to True.

The Mail Flow settings section of the Exchange admin center (EAC) already includes a setting to enable plus addressing for an organization (Figure 1). Turning off plus addressing in the EAC doesn’t affect the DisablePlusAddressInRecipients setting. No doubt it will in the future. At least, that would be the sensible option.

Check for Proxy Addresses

My January article includes some PowerShell code to check for the existence of proxy addresses with plus characters. You can use the script to help decide if you need to set DisablePlusAddressInRecipients to True. Otherwise, stay calm and wait for the deployment of Exchange Online plus addressing to start!

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

It’s All About the Substrate

I must be slowing down. At least, that’s the thought which ran through my mind as I tried to make sense of Microsoft’s post about SharePoint Online proxy addresses and Exchange Online mailboxes. Specifically, I couldn’t understand this sentence “To ingest SharePoint Online content into a mailbox, we establish SharePoint Online routing information to the mailbox.” This sounds awfully like the way site mailboxes worked, but thankfully those abominations are long gone. And then I realized that the text wasn’t as clear or precise as it could have been, despite discussing an interesting aspect of the Microsoft 365 ecosystem. Here’s what I think Microsoft meant to say.

The Microsoft Substrate and Digital Twins

As anyone who’s listened to Microsoft Fellow Jeffrey Snover talk about the Microsoft 365 substrate knows, the substrate plays a key role in making Microsoft 365 shared services work. The substrate is what captures compliance records for Teams, Planner, and Yammer. It handles the ingestion of audit records generated by multiple workloads. And the substrate creates “digital twins” of SharePoint Online and OneDrive for Business documents and lists. A digital twin is not necessarily a full copy of an item; it’s enough to allow shared processes to operate against the data. If access is required to the complete data, a link redirects to the owning workload.

The substrate does this work because assembling digital twins gathered from across Microsoft 365 workloads into one place makes it much easier for shared services like compliance processing or search to operate. Instead of a service needing to communicate with multiple repositories, it needs to deal with one. And the physical representation of that repository is a special form of Exchange Online mailboxes.

SharePoint Online Proxy Addresses

Which brings me back to the subject of the blog point: the SPO (SharePoint Online) proxy addresses stamped on user mailboxes. If you examine a mailbox, you see the proxy addresses assigned to the mailbox. For example, four proxy addresses exist for this mailbox:

DisplayName    : Steve Gippy (Operations)
EmailAddresses : {SPO:SPO_20876de2-3b1c-44ce-8773-34499caaa16c@SPO_a662313f-14fc-43a2-9a7a-d2e27f4f3478, 
SIP:steve.gippy@office365itpros.com, 
SMTP:Steve.Gippy@office365itpros.com, 
smtp:Steve.Gippy@office365itpros.onmicrosoft.com}

One is the primary SMTP address used for email routing (the one with capitalized SMTP), another is a secondary SMTP address belonging to the service domain for the tenant. Then there’s the SIP address used by Teams for calls and meetings. And finally, there’s SPO, the SharePoint Online proxy address, which means nothing to anyone because this address is created and maintained by background Microsoft 365 processes. The address includes a unique identifier for the user and the tenant identifier.

As the post says, administrators should leave the SPO addresses alone as “several internal cloud processes rely on them” not to mention that “Admins should never modify the SharePoint Online proxy address as it is an internal Microsoft service concept.” In other words, keep your greasy hands away from SPO proxy addresses. If you don’t, things break, and you won’t be able to fix them. In fact, you probably won’t know what broke and where it broke.

Without the SharePoint Online proxy address in place, the link between Exchange Online and SharePoint Online is broken, and the substrate can’t ingest digital twins from SharePoint Online into Exchange Online. In other words, the SharePoint Online proxy address stamped on user mailboxes is a connection back to SharePoint Online (and OneDrive for Business).

Hard and Soft Deletes

Now the opening of the post makes sense. It discusses why administrators see mailbox objects they believe are permanently removed (hard deleted) persist in a recoverable (soft deleted) state. After all, if you run the Remove-Mailbox cmdlet and use the PermanentlyDelete switch to tell Exchange Online to erase all trace of a mailbox, you’d like to think that the service would do your bidding.

But because Exchange Online is the foundation for the Microsoft 365 substrate, it has more to do than simply blow away a mailbox. In particular, because the search results generated by Microsoft search depend on mailbox content, some adjustment is necessary to reflect a mailbox deletion. That’s why Exchange Online signals SharePoint Online so that background processing can adjust the search results shown to users. While this processing proceeds, it’s possible to see erroneous results featuring a deleted user, but eventually processing completes and search is 100% accurate again.

Exchange Online keeps the mailbox in a soft-deleted state until the deleted mailbox retention period expires (183 days). By then, background processes have adjusted indexes and SharePoint Online is content. Exchange Online can then tidy up by hard-deleting the mailbox, unless of course it’s under the control of a retention hold (litigation hold or otherwise), in which case the mailbox is inactive and kept until all retention holds expire.

Life is More Complicated in the Cloud

All of this proves that cloud objects lead a more complicated existence than on-premises objects. The Microsoft 365 substrate connects objects together in a way that simply doesn’t exist on-premises, so when you remove an object, it might just have an effect elsewhere that must be dealt with. Which is why some mailboxes that you might want to hard delete have to stay soft-deleted until background processes can adjust connections.

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.

Groundhog Day for Send from Proxy Addresses

Microsoft’s January 25 announcement of a public preview for the send from email alias feature certainly confused many people, including me, because the feature first appeared last year. I wrote about the topic for Practical365.com on April 22, 2021 and the news was subsequently covered elsewhere.

Microsoft released message center notification MC252942 on April to confirm that OWA would support sending from a proxy address, with roll-out expected in early May. The feature is also covered in Microsoft 365 roadmap item 59437. According to 59437, sending from email aliases reached general availability in August 2021, only it didn’t. Or maybe it did, in a certain way.

It’s odd that Microsoft should rerelease a previously released feature a long time after it first appeared in tenants, but there is a certain logic behind the story. Here’s my take on the situation.

A Send from Email Proxies Primer

In a nutshell, if you want users to be able to send email from proxy addresses (email aliases), you update the Exchange Online organization configuration:

Set-OrganizationConfig -SendFromAliasEnabled $True

The setting applies to the complete tenant. There’s no way to restrict the ability to send email from aliases to certain mailboxes.

An Exchange Online mailbox can have multiple proxy addresses. Exchange could always deliver email to a mailbox based on any of its proxy addresses. After updating the Exchange Online configuration, users can send email using any of the proxy addresses assigned to their mailbox. The exact mechanism differs from client to client. For instance, in OWA, you must select the proxy addresses that you want to use in OWA settings (Figure 1) to populate a list of available addresses for the From field in the message compose screen.

Sending from email proxies is rated as a preview feature, so changes might happen before Microsoft regards send from email alias as a generally available feature. This is a cloud-only feature that Microsoft doesn’t intend bringing to Exchange Server.

Client Support

The original announcement covered OWA and no other client. This is understandable because client GUI must change to allow users to select a proxy address before sending a message. However, OWA didn’t get full support for send email from aliases until October 2021. Work was going on to upgrade Outlook desktop too, as evident in the beta release notes for Outlook for Windows issued on July 30, which cover a bug fix for tenants where the SendFromAliasEnabled configuration setting is True.

Microsoft’s new text says that OWA and Outlook for iOS and Android support send email from aliases, with plans to support Outlook desktop users by Q2 2022. The obvious conclusion is that it’s taken Microsoft longer than anticipated to update all the Outlook clients. Pulling together feature updates across multiple clients underlines the value of the One Outlook project, which is intended to allow much greater code sharing across Outlook clients, like the way the Room Finder works.

However, I think the delay is more likely due at the server level rather than clients. Exchange has processed email for a very long time; the origins of the code base for the SMTP-based transport service came from Exchange 2000, and although the Exchange Online code base is dramatically different because of new capabilities like support for DANE and DNSSEC and the introduction of a legacy SMTP endpoint, it’s always possible that assumptions existed in code that messages used only the primary SMTP address.

Engineers needed to find every path messages could take through the code to assess if all scenarios support sending from email proxies. If not, they needed to apply a fix. The complexity of the Exchange Online transport service is illustrated by the set of known issues described in Microsoft’s post. I assume that Microsoft will address some if not all these issues when send from email aliases reaches general availability.

My theory is that experience of using the original implementation unearthed several knotty bugs. It has taken Microsoft time to upgrade code in both servers and clients to reach the point where they’re confident that everything works as it should.

All’s Well That Ends Well

I don’t think the Microsoft announcement communicated the situation as clearly as they could have. Acknowledging the previous release would have clarified the matter. However, the fact remains that send from email aliases is a very useful and welcome feature to have, even in its preview state.

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

Important Microsoft 365 Workloads Respond to Critical Azure AD Events

Microsoft made a critical announcement on January 10 when they revealed that the base Office 365 workloads support continual access evaluation (CAE) for specific Azure AD events. What’s more, Microsoft has enabled this capability for all Microsoft 365 tenants.

Exchange Online, SharePoint Online, and Teams can now accept signals from Azure AD when an administrator:

• Deletes or disables an Azure AD user account.
• Changes or resets the password for a user account.
• Explicitly revokes all refresh tokens for a user account.
• Enables multi-factor authentication for a user account.

The top three actions correspond to highlighted options available at the top of the user account management card in the Microsoft 365 admin center (Figure 1). Multifactor enablement is at the bottom of the card.

In addition, Exchange Online can respond when Azure AD Identity Protection detects that higher risk of compromise exists for a user account.

Administrators can see details of sign-ins which use continuous access evaluation by applying a filter of (Is CAE Token = Yes) in the Azure AD admin portal. Figure 2 shows details of a CAE-enabled session.

Browsing the Azure AD sign-in log is enlightening in terms of understanding the degree of application support for CAE. Although currently limited to applications like OWA and the SharePoint Online browser interface, you’d anticipate that Microsoft will increase coverage over time.

Enlightened Applications

Continuous access evaluation means that the “enlightened” applications learn about changes in user accounts in almost real-time. For instance, if an administrator deletes a user account, the applications remove access immediately instead of waiting for the access token granted as the result of the last successful authentication by the account to expire.

Microsoft says that the use of continuous access evaluation means that “authentication session lifespan now depends on session integrity rather than on a predefined duration.” For example, if an event like a password change occurs to affect the integrity of a browser session where a user is connected to SharePoint Online, instead of waiting for the access token to expire, SharePoint Online will immediately demand that the user re-establishes session integrity by proving their credentials are still valid.

The effect is that users affected by these critical events must either reauthenticate (for instance, using a new password), or lose access to email, documents, calendar, and Teams. This makes it much easier to manage the possibility of data loss in cases like account compromise or the departure of disgruntled employees.

A benefit of continuous access evaluation is that in the case of outages, extended session lifetimes enabled by removing the dependency on the access token as the sole control over accounts mean that people can continue working without needing to revert to Azure AD (see this note about Microsoft’s Azure AD backup service).

Conditional Access Policy Support

While response to critical Azure AD events is available for all Microsoft 365 tenants, those with Azure AD Premium licenses can include continuous access evaluation in the criteria used by conditional access policies to decide to grant or deny user access to applications based on conditions like network location.

Zero Trust in Action

Microsoft talks about the Zero Trust model a lot. An action like enabling continuous access evaluation for critical events in all Microsoft 365 tenants is a practical and useful example of the Zero Trust initiative. Even if you don’t use conditional access policies (something I think all tenants should consider to improve their security posture), the fact that the base Microsoft 365 workloads now respond to critical Azure AD events almost in real time is a very welcome advance.

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. We cover continuous access evaluation in the chapter on Microsoft 365 identities.

Two Kinds of DLP

As you might be aware, two types of Data Loss Prevention rules are available for Exchange Online:

• Exchange Online Transport Rules (ETRs): Because all email must travel through the transport system, it made sense for Microsoft to use transport rules to implement DLP in Exchange 2010. ETRs are available for Exchange Server and Exchange Online.
• Microsoft 365 DLP: Otherwise known as unified DLP, this is the preferred approach for DLP within Microsoft 365 tenants, notably because this version is under active development.

When Microsoft first launched unified DLP in 2016, its Exchange capabilities were weaker than ETRs. This, plus a desire to have the same rules active within both on-premises and cloud sides of hybrid environments, made some customers reluctant to embrace unified DLP. Microsoft steadily closed the gap with ETRs over time and reached functional equivalence in 2020. For most organizations, unified DLP is the right answer when looking for a solution to block inadvertent sharing of confidential or sensitive information from SharePoint Online, OneDrive for Business, and Exchange Online. DLP also supports Teams messaging, but unlike the basic workloads, DLP for Teams requires Office 365 E5 or Microsoft 365 equivalent licenses.

Tweaking Continues

Some tweaking of unified DLP processing continues to improve its capabilities and performance. MC306117 (December 17) is an example. The change announced in this message center notification tells tenants that starting January 20, 2022 (presumably – the notice says 2021, but that seems like a year-end error), when DLP evaluates sender-based conditions for email, it will use header sender addresses instead of envelope sender addresses. This makes unified DLP work the same way as ETRs.

Sender Addresses

The change is sensible because most people consider envelope sender addresses when they think about rules they might want to apply. In the world of SMTP, messages have two parts:

• Envelope: Used by mail servers to route messages. The format of envelopes is defined in RFC5321, and the sender information is in the Mail From field. When email reaches its destination, the server discards the envelope and saves the Mail From address in the Return-Path message header.
• Message: Defined in RFC5322, SMTP messages have a bunch of headers and a body. Email clients display the From message header as the message sender.

There is no requirement that the Mail From address in the envelope matches the From address in the message. In fact, it’s very common that the two differ. Take the example of a company which uses a marketing platform like HubSpot to send email to mailing lists. The Mail From address in the envelope will be for a HubSpot server while the From address in the message will be whatever the company wants the message recipient to see.

Checking Who Sent Email

I don’t use my Exchange Online email address to sign up for email communications with many companies, so the number of messages of this type which arrive are limited. However, I found a message from Quest Software to illustrate the point (Figure 1). The sender information in the envelope is revealed by using Outlook’s Message Header Analyzer add-in. You can see that the Return-Path header is different to the sender information shown by the client.

In this instance, the change for DLP processing on January 20 means that DLP will evaluate sender address conditions against Quest@quest.com instead of QuestInc@innovation.quest.com. The change will happen automatically.

Microsoft says that organizations wishing to continue evaluating sender addresses based on envelope data will have the option to change the tenant DLP configuration (they don’t say how). They also say that organizations can configure DLP policy rules using the SenderAddressLocation parameter. This isn’t available yet, but if the same approach is used as for ETRs, the syntax will be:

# Update DLP rule to use both header and envelope sender info for evaluations
Set-DlpComplianceRule -Identity "Rule name" -SenderAddress Header Envelope HeaderOrEnvelope

The values are:

• Header: Use the From message header (new default from January 20).
• Envelope: Use sender information contained in the Mail From value in the message envelope (current default).
• HeaderOrEnvelope: Use both.

Overall, the change makes sense and shouldn’t affect too many organizations, but it’s something to test if your company uses Microsoft 365 DLP policies to process Exchange Online content.

Update Intended to Make Dynamic Groups More Reliable

Update March 8: Microsoft published MC340293 to announce the feature. It’s odd that they do so some months after people saw the functionality work in their tenants. Microsoft says that they will begin the general roll-out the feature in April 2022.

A LinkedIn post discusses Modern Dynamic Distribution Groups (also known as dynamic distribution lists) and says that Microsoft is going to roll out this upgrade for these very useful objects in January with worldwide completion due in March. The fundamental change is to move away from on-demand resolution of group queries to resolve and store group membership daily.

The reasons cited to make the change are to Reduce mail delivery latency by removing the need to resolve the queries against the Exchange directory each time someone addresses the group. Because they cover a limited set of well-known conditions, it’s usually easy for Exchange to resolve precanned filters to find a set of mail recipients. However, custom filters can be reasonably complex and their resolution can slow the ability of the Exchange transport service to route messages. Microsoft believes that making the change to pre-resolved recipient lists will also Improve service reliability.

According to Microsoft, they released details of the change in message center notification MC289967 in early November. I never saw this notification and no trace of it exists in my tenant. However, everything seems to be working as reported in my targeted release tenant. Microsoft says that full roll out will start in early January and should be available everywhere in March 2022.

Less Dynamic but Still Valid

Of course, creating recipient lists for dynamic distribution groups makes them less dynamic and depends on an assumption that group membership doesn’t change often. In most cases, the assumption is true: organizations do not update directory attributes every few days and the membership of dynamic groups probably doesn’t vary all that often.

A side effect of the change is that when administrators create new dynamic distribution groups or update the filters of existing groups, it can take up to two hours before Exchange Online calculates the membership of the new group and makes it available for use. This is different to previous behavior when Exchange could use a new or updated filter immediately it was updated in the directory. The new Exchange Admin Center already flags the need to wait to administrators (Figure 1). True to its word, when I created a new dynamic distribution group, it was available almost exactly two hours later.

To see when Exchange Online last computed the membership of dynamic distribution lists, run the Get-DynamicDistributionGroup cmdlet and examine the CalculatedMembershipUpdateTime property. The results shown below were obtained at 15:00 on 10 December 2021 at, so membership was approximately 18 hours old at that point.

Get-DynamicDistributionGroup | Format-Table DisplayName, CalculatedMembershipUpdateTime

DisplayName                              CalculatedMembershipUpdateTime
-----------                              ------------------------------
Company-DDG                              09/12/2021 20:50:06
Dublin users                             09/12/2021 20:50:06
Office 365 Gurus                         09/12/2021 20:50:06

Moving away from on-demand membership resolution means that Exchange Online now uses the same approach to calculating dynamic group membership as Azure AD uses for its dynamic groups. No great issues have been reported by organizations struggling to deal with Azure AD group memberships, so there’s no reason to believe that problems will surface with Exchange Online.

New Get-DynamicDistributionGroupMember Cmdlet

Because Exchange Online now calculates the membership of dynamic distribution groups daily, the membership of these groups is available without having to run the Get-Recipient cmdlet to resolve the group query. For example, instead of fetching the recipient filter from the group and using it as an input to the Get-Recipient cmdlet like this:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity Architects).RecipientFilter

Name           RecipientType
----           -------------
Ben.James      UserMailbox
Brian Weakliam UserMailbox
James.Joyce    UserMailbox
Marc Vilas     UserMailbox
TRedmond       UserMailbox
Vasil.Michev   UserMailbox

You can use the Get-DynamicDistributionGroupMember cmdlet instead:

Get-DynamicDistributionGroupMember -Identity Architects

Name           RecipientType
----           -------------
TRedmond       UserMailbox
Marc Vilas     UserMailbox
Vasil.Michev   UserMailbox
Brian Weakliam UserMailbox
Ben.James      UserMailbox
James.Joyce    UserMailbox

Although they’re not returned in the same order, the two cmdlets produce the same set of mail-enabled recipients.

The Get-DynamicDistributionGroupMember cmdlet is available in the Exchange Online management module (and based on Microsoft documentation, the cmdlet has been around since mid-August 2021, even if no one noticed). However, no email client yet supports the ability to:

• Expand the membership of a dynamic group and insert each member as a separate recipient in the header of a message.
• View the membership of a dynamic group through the address book.

As of November 2022, no Outlook client supports these features.

Trivia note: The Microsoft Exchange PowerShell Cookbook, published in 2015, includes a function called Get-DynamicDistributionGroupMember which uses Get-Recipient to resolve a recipient filter against the directory.

Not Much Impact

Only Microsoft can say if the change to precalculated membership speeds message delivery and increases the robustness of the Exchange Online transport service. It’s easy to see how performance will improve, but you’d assume that Exchange had mastered the resolution of membership queries by now (dynamic groups first appeared in Exchange 2003). In any case, the change won’t make any difference to end users. Some might notice if Microsoft updates Outlook to support membership expansion of dynamic groups, but others will never see a difference.

Keep up to date with developments like new PowerShell cmdlets 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.

Discovering Some Nuggets from Microsoft’s Coverage

It’s been a busy week for anyone following the Microsoft 365 ecosystem as Microsoft released a slew of blog posts and announcements to support keynotes and other sessions at the Microsoft Ignite Fall event. You could spend hours reading about new features and functionality and wonder when the code will appear in your Office 365 tenant and if any additional licenses are necessary.

This post captures notes about several features available now that I noticed as I perused Microsoft’s coverage. By themselves, each is not enough to warrant a separate post, but they’re interesting all the same. These changes are examples of the stuff we track to maintain the content of the Office 365 for IT Pros eBook. All our chapter authors have been busy this week.

SharePoint Online and OneDrive for Business

Sharing links show who you’ve shared a document with. This feature was announced in June but seems to have taken its time to roll out. The idea is simple. When you send a new sharing link, SharePoint Online and OneDrive for Business tell you who the document is already shared with (Figure 1), including a thumbnail of each person (if available in Azure AD). You can hover over a thumbnail to see who the person is. The number of active sharing links also appears. It’s a small but useful change.

Easy to overlook, the SharePoint Online admin center now displays connected channel sites when a site used by Teams creates private channels (Figure 2). If you can’t remember which sites have private channel sites, connect to SharePoint Online PowerShell and run:

Get-SPOSite -Limit All -Template TeamChannel#0 | ? {$_.TeamsChannelType -eq "PrivateChannel"}

If you click the channel sites link, the admin center displays details of those sites. Teams manages the settings for these sites, but it’s nice to be able to have easy access to the information. Shared channels, which are delayed until early 2022, also use channel sites.

OneDrive for Business supports Known Folder Move (KMF) and Files on Demand on MacOS, which is nice if you’ve invested in a brand-new M1-powered Mac.

If your tenant uses sensitivity labels and has SharePoint Syntex, you can apply sensitivity labels to protect the document understanding models. The application of a label in this manner flows through to protect individual documents identified by models. It’s another way of automatically applying labels to sensitive content.

Sensitivity label control over sharing capabilities of SharePoint Online sites is now generally available. In addition, co-authoring and autosave of protected documents is generally available in the Microsoft 365 apps for enterprise (Word, Excel, and PowerPoint). We use protected documents heavily to store chapter files for the Office 365 for IT Pros eBook, so this is a welcome advance.

Exchange Online

Microsoft Scheduler can now dynamically adjust the scheduling of recurring meetings. This is message center notification MC295855 (November 2) and it’s a great idea. Static recurring meetings are all too often cancelled or rescheduled because someone is sick or otherwise unavailable. After a recurring meeting finishes, Scheduler looks for the best time slot for the next instance and books that time.

Everyone’s probably familiar with the Exchange Online campaign to remove basic authentication for email connection protocols (that October 2022 date is getting nearer!). PowerShell is on the list of protocols to be blocked for basic authentication, but the Exchange Online management PowerShell module still uses basic authentication to communicate with WinRM on a local workstation. Work is under way to remove the need to use WinRM. Microsoft has released a preview version (2.0.6-3preview) of the module to demonstrate how they will remove the dependency by using a REST API in the background. Exchange Online has many cmdlets, not all of which have been converted to use the new mechanism, but you can test the preview now.

On the downside, Microsoft didn’t say anything at Ignite about the next version of on-premises Exchange. This is strange given the September 2020 announcement said the next version of Exchange Server would be available in the second half of 2021.

Microsoft 365

Microsoft says that Visio web app is rolling out to Microsoft 365 commercial tenants (all tenants with Office 365 enterprise plans). The rollout goes through to the end of January 2022, so keep an eye on the app launcher to see when Visio web app (aka Visio in Microsoft 365) shows up in your tenant.

Microsoft Cloud App Security (MCAS) is now Microsoft Defender for Cloud Apps (surely MDCA?). The app governance add-on is now generally available. It’s a good way to chase down apps registered in Azure AD that are over-permissioned or not being used. If you don’t have MDCA or don’t want to pay for the add-on, use our DIY audit method for Azure AD apps.

Access to the knowledge available in topic cards created by Viva Topics has been restricted to some lesser-used applications up to now. Things will change when topic cards appear in OWA and Teams. Apparently, this will happen soon and should be a game changer for the organizations who have invested in the work needed to harvest organizational knowledge through Viva Topics.

Teams

Microsoft prioritized Teams at Ignite as the center of a new way to work (see my practical365.com article), so there were lots of Teams-related developments discussed, most of which can be left until they appear in a tenant near you. One snippet in a blog post about improving meeting quality is that noise suppression in Teams meetings will be available for iOS soon. Microsoft claims that they saw a “31% decline in comments about background noise distractions” after the launch of noise suppression. This sounds like a good thing, but a single statistic provided without any further context or detail is worthless. We don’t know the sample size, whether the clients were Windows or Mac. What kind of meetings, and what is meant by “comments” (good, bad, or indifferent). Like many Microsoft statistics, there’s plenty of room for fudging an issue.

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’s happening.

Some Manual Intervention Might Still be Required

Message center notification MC291056 (updated October 19) covering a simplified configuration for Domain Keys Identified Mail (DKIM) in Microsoft 365 Defender for Office 365 was a good reminder to check that all the domain names registered for my tenant were in good health.

DKIM uses a private key to include an encrypted signature in a domain’s outbound email. The public key for the domain is published in its DNS records. Receiving domains use the public key to decode the signature in messages to confirm that email comes from the domain it appears to be from rather than a spoof attempt. You can choose to use either 1024-bit or 2048-bit DKIM keys.

Microsoft configures DKIM for the tenant service domain automatically (the onmicrosoft.com domain assigned to each tenant). If a tenant has one or more custom domains, as most Office 365 tenants do, administrators should configure DKIM for each domain used for email (accepted domains).

All outbound email sent from Exchange Online is signed with DKIM. Exchange Online uses the service domain name if DKIM is not configured for a custom domain (like Office365itpros.com). It’s better for email authentication if the domain used for DKIM matches the domain sending email. Hence the logic behind the need to check that all your custom domains are configured.

Check Your Domains

The first place to check is the Domains section of Settings in the Microsoft 365 admin center. I look there to make sure that Microsoft 365 considers each of the registered domains to be healthy. This has nothing to do with DKIM because Microsoft 365 doesn’t take DKIM into account when it checks a domain. However, it’s good to make sure that Microsoft 365 doesn’t consider any of the domains to have problems with their basic set of DNS records. Interestingly, I noted that the details available for a domain now include the set of Groups and Teams which use the domain for their primary SMTP address (Figure 1).

Although this information is easy to find elsewhere, it’s good to have it here in case you want to remove a domain and need to reassign SMTP addresses to keep email flowing. In passing, the Apps section lists Azure AD registered apps which use the domain as a required URL.

A New DKIM Page

MC291056 notes the introduction of a new DKIM configuration page in the Microsoft 365 Security Center. The page lists the accepted domains for the tenant and allows administrators to select individual domains to enable or disable DKIM (Figure 2).

Everything was in order except for the tonyredmond.email domain. The domain works for email, but DKIM wasn’t enabled because the CNAME records for the domain weren’t published in DNS. This status is also viewable in PowerShell by running the Get-DkimSigningConfig cmdlet to check the domains:

Get-DkimSigningConfig  | ? {$_.Enabled -ne $True } | Format-Table Domain, Enabled, Status, LastChecked

Domain                            Enabled Status        LastChecked
------                            ------- ------        ------------
tonyredmond.email                   False CnameMissing  20/01/2016 18:58:29

Microsoft’s documentation explains what needs to be done. Because GoDaddy is the domain manager, I had to create the CNAME records in DNS for the DKIM signatures for the domain. You can get the values for the CNAME records using the Get-DkimSigningConfig cmdlet:

Get-DkimSigningConfig -Identity tonyredmond.email | Select -ExpandProperty Selector1CNAME
selector1-tonyredmond-email._domainkey.xxxxxx.onmicrosoft.com
Get-DkimSigningConfig -Identity tonyredmond.email | Select -ExpandProperty Selector2CNAME
Selector2-tonyredmond-email._domainkey.xxxxxx.onmicrosoft.com

A quick visit to GoDaddy’s Domain Manager and the two records were inserted (Figure 3).

After adding the records to DNS, it will take a little time to propagate the new data to Microsoft 365. An hour is usually enough. After Microsoft 365 knows about the CNAME records for DKIM for the domain, you can enable DKIM by moving Sign messages for this domain with DKIM signatures from Disabled to Enabled (Figure 4).

Of course, you can enable the domain using PowerShell.

Set-DkimSigningConfig -Identity tonyredmond.email -Enabled $True

Key Rotation

When a domain is enabled for DKIM, you can also configure it for key rotation. The documentation for the Rotate-DkimSigningConfig cmdlet says that you don’t need to do this because Microsoft 365 rotates private and public keys automatically to reduce the chance of an attacker compromising the keys used to sign messages. This assertion might cover the service domain, but I don’t see any problem in going ahead and rotating DKIM keys for all custom domains used to send email. Happy signing!

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

Client-Side Completion for a Server Feature Delivered in April 2021

Exchange Online delivered support for sending email from proxy addresses (mailbox aliases) in April 2021. At least, the server-side part of the equation was happy to process messages sent using proxy addresses. It can take a little time for clients to catch up. A proxy address is an SMTP address assigned to a mailbox. Usually, people use the primary SMTP address for all outgoing messages (and the primary address is often the same as their Microsoft 365 sign-in address, or user principal name, so it’s easily remembered). Secondary proxy addresses are used in situations like:

• Mergers and acquisitions: Email addresses like the ones used at an acquired company.
• Life events: Email addresses with previous versions of someone’s name (like a married surname).
• Organizational addresses: Email addresses with functional titles, such as a departmental manager.

Exchange Online can deliver email addressed to any proxy address to the mailbox.

Supposed to Happen in May

MC252942 (published April 27) announced that OWA would support sending from proxy addresses in early May. Well, that didn’t happen, which was surprising because OWA is usually at the forefront of delivering new features for Exchange Online. Being able to develop and publish new functionality more quickly than Outlook desktop can is one of the reasons why OWA is core to Microsoft’s One Outlook initiative.

Microsoft 365 roadmap item 59437 describes the feature as “rolling out” starting in August. I haven’t seen the new setting appear until this week, so it’s possible that its deployment is still in progress.

OWA Option to Select Proxies

It was possible to send email previously with OWA using a proxy address by typing the proxy address in the From field in the new message screen. However, people often don’t know what proxy addresses are available to them, so while OWA could send messages from proxies, it wasn’t as easy as it could be. This has now been addressed with the arrival a new setting in OWA options to allow users to choose the set of proxy addresses they would like to use (Figure 1).

The address at the top of the list is the primary SMTP address for the mailbox. In my case, it appeared twice (a bug). A user can’t unselect their primary SMTP address as it remains the default for sending. If they want to use a different primary address, they’ll have to ask an administrator to update their account. It’s good practice to make the previous primary address a secondary proxy to ensure that Exchange Online can deliver responses or new messages sent to that address.

It’s wise to check the Always show From option in OWA settings as this will make it easier to select one of the chosen proxies.

Sending From a Proxy

Once you’ve selected the set of proxy addresses that you’d like to use (and made sure that the From field is exposed), it’s easy to select a proxy to use because OWA shows the available set in a drop-down list (exposed by clicking the From button) in the compose message screen. The list (Figure 2) includes:

• The primary SMTP address for the mailbox (the default).
• The proxy addresses selected in OWA options.
• Other addresses previously used to send email. Typically, these are addresses for other user and shared mailboxes where the user has Send As or Send on Behalf of permission.
• The option to add another email address (for instance, for a mailbox you’ve just been given the permission to send from).

Select the proxy to use and compose the message as normal. When Exchange Online sends the message, it populates the From and Return-Path values in the message header (Figure 3).

Small Changes Make a Difference

There’s nothing earthshattering in this update. The Exchange transport system has always been able to deliver email addressed to any valid proxy address assigned to a mailbox. The heavy lifting occurred in April when Exchange Server updated transport to allow it to accept messages sent from proxy addresses. It’s nice that OWA is making it easier for people to use the feature.

Keep up to date 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.

Odd Title for Notification, but Real Value in Update

What does “Exchange online auto-expanding archive–Automatic archive of mailbox items in Purges, Versions and Discovery Holds folders” mean? That’s exactly what I thought when I read message center notification MC288630 (1 October). It’s a classic example of how poor editing can mask the value in a message. Here’s what’s happening.

The Recoverable Items structure is composed of several sub-folders, each with a distinct task. A set of sub-folders within Recoverable Items are used for retention processing:

• Purges: Stores items removed from the Deletions folder.
• Versions: Stores the original versions of edited items.
• DiscoveryHolds: Contains hard-deleted items.
• SubstrateHolds: Contains the original versions of items managed by the Microsoft 365 substrate (for example, compliance items for Teams messages).

If a mailbox doesn’t come within the scope of a litigation or in-place (retention) hold, you won’t see items in these folders. You will see items in the Deletions folder because this is where items removed from the Deleted Items folder go until Exchange Online removes them permanently. Items stay in Deletions for the deleted items retention period defined for a mailbox (usually 14 days but can be changed to a maximum of 30 days). During this period, users can recover items from Deletions using Outlook’s Recover Deleted Items option. For more information on how these folders are used, see this Microsoft article.

Cluttering Up Recoverable Items

The point of retention policies is to keep information for as long as it is needed. Although Microsoft allocates a 100 GB storage quota to store data in Recoverable Items when a mailbox is subject to retention, it’s not uncommon to find that some mailboxes accumulate information quickly and occupy the quota. The change described in MC288630 and being rolled out in mid-October aims to take advantage of archive mailboxes by moving information from the Purges, Versions, and DiscoveryHolds sub-folders to the archive mailbox one day after their generation.

In effect, this is the same processing as would occur if you were able to assign a 1-day move to archive Exchange retention tag to these folders. The Managed Folder Assistant looks at the contents of the folders when it processes a mailbox and, if the mailbox has an archive, applies the one-day move to archive rule. The same processing occurs for both normal and auto-expanding archives.

The net effect is that the space occupied by the items in these folders in primary mailboxes is reduced dramatically and administrators won’t have to step in as often as happens now to remove data from Recoverable Items. The items moved into the archive remain indexed and discoverable and have the same value for retention processing.

Ignoring Existing Policies

MC288630 says that “existing archiving policies created by customers for these folders will be ignored” once the change is effective. In other words, if you have an Exchange retention policy with a folder tag for the Recoverable Items folder which takes another action (for instance, for move to the archive after 90 days), the Managed Folder Assistant will now ignore the folder tag when it processes the Purges, Versions, and Discovery Holds sub-folders. However, the folder tag (or a default move to archive tag) will apply to items in the Deletions sub-folder.

Users will remain blissfully unaware of the change. They can’t access the three sub-folders in either primary or archive mailboxes. This is simply a matter of moving data around to a new location to make the overall functioning of the Recoverable Items structure in primary mailboxes more effective. It’s a good change.

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’s happening.

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.

Stopping a Flood of Email to Mailboxes

Microsoft began the process of clamping down on high-volume mailboxes earlier this year. The process is still rolling out as Microsoft gradually imposes the limit (which was always documented but not enforced). Mailboxes which receive more than 3,600 messages in an hour are blocked from receiving further messages for an hour and senders receive a non-delivery notification with code 5.2.122. This limit applies to messages received from any source, including people in the same tenant, and is designed to stop Exchange Online mailboxes filling up because of problems with automated mailers, like those used by applications to notify people about the progress of jobs.

Clamping Down on Individual Senders

In message center notification MC272450 posted July 23, Microsoft says that they will introduce a further restriction in September 2021. Like the previous restriction, the reason specified is to block single-sender mail storms and deter DoS attacks. The big difference is that the focus moves from messages coming from all sources to messages coming from a specific external source. To do this, Exchange Online tracks sender-recipient pairs (SRPs). As messages arrive in a mailbox, Exchange Online notes the sender and builds a table of SRPs. If a single sender sends more than 33% of the overall threshold (1,200 of 3,600), Exchange Online stops accepting messages from that sender to the mailbox for an hour. The mailbox continues to receive messages from other senders.

The exception is that the limit does not apply to messages sent from an Exchange Online mailbox in the same tenant. The limit does apply to:

• Messages from Exchange on-premises mailboxes in the same tenant.
• Exchange Online messages from other Office 365 tenants.
• Messages from any other email system.

Blocked senders will receive non-delivery notifications with a 5.2.121 code. The mailbox owner will get a message to tell them that their mailbox has stopped receiving messages from the sender for an hour (the countdown starts once Exchange Online detects the problem). and administrators will be able to see the affected mailboxes in the Mailbox exceeding receiving limits report (aka Hot Recipients) in the Reports (Mail Flow) section of the Exchange admin center (Figure 1).

Microsoft suggests that Exchange administrators ask the mailbox owners why they receive so much email from the blocked sender.

Time to Review Email Generation by Applications

Microsoft says that this change will stop a malicious user blocking email flow to a mailbox. In other words, an attacker can’t try to stop someone receiving legitimate email by generating a flood of email to their mailbox. They also note that only a small percentage of mailboxes hut the SRP limit currently. My feeling is that the origins of most email likely to be blocked by the SRP limit come from applications generating frequent notifications and other updates. The tightening of the overall limit and the introduction of the new SRP limit is a good wake-up call for organizations to review the rate of email generation by applications and remove messages which are not strictly necessary.

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’s happening.

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.

Now Circulating to an Inbox Near You

The value of enabling the first-time safety tip and external tagging of email is evident in a new phishing attempt that’s now circulating. The attack purports to be email delivering a document relating to an invoice payment (Figure 1). The message is tagged as external and the first-time safety tip is obvious. The attacker uses a classic technique of attempting to lure the recipient into clicking a link to download a document. Naturally, this brings the user to a place they don’t want to visit and shouldn’t go.

The email comes from an Office 365 tenant (easystreetdotnet.onmicrosoft.com), which I assume has been either hijacked or set up by the attacker. Because it’s valid email and comes from an Office 365 tenant, the email passes anti-spam and anti-malware checks and therefore reaches user inboxes.

The View completed document link in the message brings users to b24-r98mpq.bitrix24.site (an unlikely site address for legitimate documents).

Report Phishing Messages

I used the Reporting Phishing add-in for Outlook to send a copy of the message to Microsoft for their security analysts to review and action. In the meantime, keep an eye out for similar messages which might arrive in your tenant and consider:

• Installing the external tagging and first-time safety tip features in Exchange Online.
• Deploying the Report Phishing add-in to users.

Available for Activation Now

After a delay to allow for the deployment of the required cmdlets, tenants can now activate Exchange Online’s external email tagging feature to mark external email (MC243047 – Microsoft 365 roadmap item 70595). The tags appear in OWA, Outlook Mobile, Outlook for Mac, and should eventually show up in Outlook desktop. External email tagging is part of Microsoft’s strategy to make email secure by default along with other features like blocking automatic mail forwarding.

External email tagging means that messages received from any domain except those registered for the tenant are marked by Exchange as “external” when they pass through the transport service on their way to user mailboxes. Figure 1 shows External tags displayed for a set of messages in my Inbox with details obscured to protect the guilty. In addition to the tag, when a message is read, the user is offered the chance to block the sender. The external tag is not displayed for messages received from external senders and forwarded by a tenant user. Protected (encrypted) messages are not affected as the tag doesn’t affect message content.

Flagging external senders with a form of mail tip and offering to block them seems a tad robust. After all, email is all about communication and even if spammers are active, I expect a minimum of spam to get past Exchange Online Protection and Microsoft 365 Defender for Office 365 (aka Advanced Threat Protection). The implementation appears to make blocking senders the norm rather than the exception, which I don’t like.

Adding Well-known Functionality

Tagging adds a feature to Exchange Online that organizations have been building for years with transport (mail flow) rules (here’s an example). Obviously, Microsoft believes that highlighting external email is something which should be available out-of-the-box. I agree. It’s just curious that it’s taken the developers 25 years to get around to implementing the features. Then again, important stuff like enabling reactions to email (MC239090 – delayed on March 2 to “evaluate feedback” like “this is a waste of time”) has got in the way.

Activating External Email Tagging

External tagging is disabled by default. This is an unusual situation for a new feature as Microsoft invariably assumes that people want to use whatever new wheeze they have dreamed up and therefore enables new features. In this instance, you’ll have to run the Set-ExternalInOutlook cmdlet to get things moving.

Leaving aside the not-very-good cmdlet name (Set-ExternalEmailTagging would have been more obvious), the process is very simple:

• Connect to the Exchange Online Management endpoint (or use remote PowerShell if you must).
• Run Set-ExternalInOutlook to enable external tagging. You can decide if certain domains or individual email addresses are excluded from tagging. I’m not sure when I would use individual addresses, unless you wanted to be sure that email received from someone’s (like an executive’s) personal email address was not considered external. The more I think about that idea, the less I like it.

For my tenant, I ran:

Set-ExternalInOutlook -AllowList "quest.com", "microsoft.com" -Enabled $True

This command means that tagging is applied to any external email except the two domains defined in the allowed list. After a moment, I decided to add another domain. Doing it this way avoids overwriting the domains already excluded:

Set-ExternalInOutlook -AllowList  @{Add="Practical365.com"}

Note: Some tenants are reporting that they see failures when running Set-ExternalInOutlook to add just one domain to the allow list. While Microsoft debugs the problem, the quick workaround is to always add at least two domains to the list.

The Get-ExternalInOutlook cmdlet reports the tagging configuration:

Get-ExternalInOutlook

Identity   : s662313f-14fc-43a2-9a7a-d2e27f4f3478
Enabled    : True
AllowList  : {quest.com, microsoft.com, Practical365.com}

The identity reported is the GUID for the tenant. It’s the same as reported by Get-MgOrganization, which is my normal go-to cmdlet to find this information. You can also find the tenant identifier in the overview section of the Entra ID admin center.

After that, it’s a matter of waiting for Exchange Online to acknowledge the configuration update and enable tagging. Microsoft says that activation should happen within 24-48 hours. The exact waiting period depends on many factors, including service load, but in my case, Exchange Online started to tag messages within a few hours.

If you enable external tagging and want to see the tags show up, make sure that your account is enabled in the Microsoft 365 admin center for targeted release. Users on targeted release see new updates for several weeks before other users do.

Tagging Threads

Interestingly, OWA highlights a thread as external if any message in the thread comes from an external domain that’s not on the excluded list. For example, I have a bunch of messages from microsoft.com addresses which are excluded from tagging. But once someone from an external address (like dell.com, for instance), joins the conference, OWA applies the external tag.

Although tagging is supposed to show up in Outlook mobile, I haven’t seen it yet despite updating to the latest TestFlight build (4.2110.0). No doubt external tags will appear in time. I just have to be patient.

Update April 22: Glen Scales explains how to use the Microsoft Graph API and EWS to work with external tags in this blog post.

To learn lots more about Exchange Online and Office 365 in general, subscribe to the Office 365 for IT Pros eBook! We probe and test new features so you don’t have to do as much work to understand and deploy them in production.

Lack of APIs and Integration of Data Across Apps Creates Challenges

Updated: February 24, 2022

I’m bemused by the solutions people proposed when asked about Teams backup. It’s reasonable to consider backing up any IT service and given the recent growth in Teams usage I have seen several requests from people looking to understand what they can do to secure Teams data. The reasons why you might want to backup a cloud service include:

• Securing critical data against loss caused by an external attack (including ransomware and other malware).
• Stopping rogue administrators removing or altering information.
• Moving copies of data to external repositories to ensure people can work if the cloud service is unavailable for an extended period.

These are classic reasons long cited in the on-premises world. However, in the cloud, things are different because you typically don’t have the same level of access to data that you enjoy on-premises.

No Microsoft Backups for Office 365 Data

Apart from SharePoint Online, Microsoft doesn’t backup its Office 365 services. Microsoft relies on its technology (like native data protection for Exchange Online) to protect data, so if you want a backup, you must use a third-party service. There are many services available and generally there are no problems backing up or restoring mailbox and document data. Backup products for Exchange Online and SharePoint Online have roots in on-premises technology and the methods to move data in and out of mailboxes and sites are well understood. APIs, albeit never designed for cloud backups, are available, and everything works. Well, everything works until sensitivity labels and encrypted content are introduced into the mix, but that’s another discussion.

Teams is a Cloud App

Teams is a different matter. Unlike Exchange and SharePoint, Teams is a product of the cloud. It does not exist on-premises and no one ever developed backup interfaces for Teams. But more importantly, Teams is built on top of multiple Office 365 and Azure services. The data in these services is interconnected and dependent. Restoring a mailbox is simple compared to the reconstruction of a team, complete with all its channels, tabs, conversations, meetings, and so on.

Claims of Teams Backup Vendors

Some vendors claim their products cover Teams backup. Most ISVs base their claim to cover Teams on copying the Teams compliance records stored in group and personal mailboxes in Exchange Online. Although it is possible to copy Teams compliance records like any other Exchange mailbox data, this is not a backup. It doesn’t even come close for two reasons:

1. Teams compliance records are designed to capture communications for eDiscovery and compliance use. They are not the actual data and the compliance records are not true copies of the original because they lack certain elements of Teams messages, such as reactions.
2. No API exists to restore Teams compliance messages into a Teams channel conversation or personal chat. You could read the compliance records and use Graph API calls to write new messages into channel conversations and chats, but this is not a true restore because the newly-written items would be dated differently to the original and lack all the data not copied to compliance records.

Any backup vendor who insists that they deliver Teams coverage through Exchange Online exhibits a woeful ignorance of Teams technology. If a vendor doesn’t understand the strengths and weaknesses of their product, you shouldn’t use them.

This issue is addressed in the Teams Export Graph API, but that API has challenges of its own, notably the cost/consumption models that Microsoft wants to use to charge for API use. In July 2022, Microsoft announced that they will restrict the use of Exchange Web Services to access Teams message data stored in Exchange Online (the compliance records) from September 30, 2022. This is part of a process to force ISVs and customers to use the Teams Export API. If it improves the quality of backups, I think this will be a positive step.

The commentary about Teams backup found on vendor sites often lacks technical depth and understanding, such as the discussion from which I took Figure 1. I’m not sure if the various vendors cited agree on the assessment of their capabilities! To be fair to the author and the vendors, capabilities change over time and it’s wise to check what the current status is when discussing the problem of backing up Teams with ISVs.

Teams Backup Fails to Deal with all Teams Data

Both approaches fail to take the wide spectrum of Teams interconnected data into account. Backing up one piece of information secures that data, but that data might be useless if other connected data is not copied and available.

Table 1 lists some of the connected data used by Teams. It’s not a definitive list and other data might be needed (like OneNote) to create a comprehensive backup of Teams in an Microsoft 365 tenant. The purpose of the list is to illustrate the wide array of user and system data consumed by Teams. If you want to backup Teams, you need to understand what data is used with Teams in your tenant. Once you know that, you can figure out how to solve the backup problem.

In some cases, a workaround might compensate for the lack of a backup API. For instance, you could download every video from Stream and copy the video to a backup site. You could use the Graph API to copy Plans, and so on.

The problem with workarounds is that they often lack automation and the ability to scale. How many videos does a tenant store in Stream? How many are generated daily? How many plans are created and how many tasks are added, changed, or removed daily? And whiteboards?

Restore an Even Bigger Issue

Vendors of Teams backup solutions want to sell products. Their access to your data is limited by the available APIs, so no great mystery exists as to why a comprehensive backup for Teams is so difficult to achieve. And once you have some backup data, consider that restoring Teams is even more problematic.

For more information about Office 365 backups, read Chapter 4 of the Office 365 for IT Pros eBook. Our approach can be summarized as “understand what you need to backup and why before you commit to an external backup service.”

Works for Teams or Skype for Business Online Meetings

Office 365 Notification MC213856 published on May 20 tells us that users will soon be able to configure an organizational setting to instruct OWA, Outlook for Mac, and Outlook mobile clients to make any new meeting created into an online event. Given the current need to work from home, this change reflects the transition of many meetings from in-person events to online.

The feature only works when an account is connected to an Office 365 tenant with Teams or Skype for Business Online configured for online meetings. Unsurprisingly, it doesn’t work with other online meeting providers like Zoom and GoToMeeting. Outlook Mobile can be configured to support third-party online meeting providers.

Three roadmap items are covered by the announcement: 63383 (OWA), 63625 (Outlook for iOS), and 63628 (Outlook for Android). MC230567 published on December 16 says that Outlook for Windows will introduce the feature in early 2021.

Making Online Meetings

Today, users must take an explicit action to create an online meeting. For example, in OWA, they set a slider to mark the meeting as a Teams or Skype for Business event. When this happens, the client retrieves a URI from the online provider pointing to the online “space” used for the meeting and inserts the URI into the meeting request. Other properties of the meeting request are updated to allow participants to join the meeting online.

Microsoft will release a client update for OWA at the end of May with Outlook mobile clients being updated over the June-July period. When available, the updates allow users to control whether they want to make every meeting an online event. In the meantime, some PowerShell settings are already available to control the feature at a tenant and mailbox level.

Tenant Online Meeting Setting

The Set-OrganizationConfig cmdlet manages the Exchange Online tenant configuration. The OnlineMeetingsByDefaultEnabled setting is False, meaning that online meetings are not the default. Updating the setting to True makes online meetings the default, and clients that support the setting will use it unless it is overridden by a mailbox-specific setting.

Set-OrganizationConfig –OnlineMeetingsByDefaultEnabled $True

Mailbox Online Meeting Setting

To override the organization setting on a mailbox level, run the Set-MailboxCalendarConfiguration cmdlet. The mailbox setting has the same name, but it’s Null by default, meaning that the organization setting takes precedence. You can set the value to $True to force the use of online meetings or $False to make “normal” (non-online) meetings be the default. Here’s a typical example of updating the calendar configuration for a mailbox.

Set-MailboxCalendarConfiguration -OnlineMeetingsByDefaultEnabled $True -Identity Kim.Akers

Actions

If you do nothing, the organization setting will be False, and clients will work as they do today unless and until users update their calendar settings. The need to update the organization setting depends on the type of company, its meeting culture, and the prevalence of online meetings (using Teams and Skype for Business).

If you use another online meeting provider, leave the organization setting alone and don’t tell users about the calendar settings. On the other hand, if you’re deep into Teams or Skype for Business, maybe the right idea is to switch to online meetings by default. It all depends on how people work in your company.

Stay updated with developments inside Office 365 by subscribing to the Office 365 for IT Pros eBook.

Important to Apply Updates for PowerShell Modules

Some important changes are available in recent refreshes for the Exchange Online and SharePoint Online PowerShell modules. In general, it’s good practice to download and use the latest available module to take advantage of bug fixes and new functionality. The problem is knowing when these updates are available as few of us have the time to check.

The latest versions of these modules are:

• Exchange Online PowerShell V2: 0.4578.0.
• SharePoint Online: 16.0.19927.0.

Exchange Online PowerShell V2 is the module containing the new-REST based cmdlets (like Get-ExoMailbox). The module also includes access to the older Remote PowerShell cmdlets (like Get-Mailbox). You should be using this module whenever possible, especially when needing to deal with large sets of mailboxes or mailbox-associated objects.

Over time, as Microsoft removes the ability to connect to PowerShell with basic authentication (along with ActiveSync, IMAP4, POP3, and SMTP), the V2 module will become the only way to access Exchange Online with PowerShell.

Updates in Exchange Online PowerShell

Notable updates in the current Exchange Online PowerShell V2 module are:

• Support to allow tenants to enable and disable Cortana Daily briefing emails (the Get-UserBriefingConfig and Set-UserBriefingConfig cmdlets). This feature is in preview.
• A new Disconnect-ExchangeOnline cmdlet to break the link between Exchange Online and PowerShell. This cmdlet removes the access token from the workstation’s cache and is intended for use in situations where a long-running session connects and disconnects from Exchange Online periodically

The Connect-IPPSSession Cmdlet and the Compliance Center Cmdlets

Version 0.4368.1 introduced the Connect-IPPSSession cmdlet as a way to connect to the Compliance Center endpoint. There’s no logic behind the name, which some speculate means Information Protection PowerShell (IPPS). The cmdlet has been around for a while and now joins the Exchange Online management module.

For the moment, I don’t recommend that you use the Connect-IPPSSession cmdlet. Although it does load the Compliance Center cmdlets into a session, it does so by removing any previous session connected to Exchange Online, which means that you end up in a situation where you can’t use the two sets of cmdlets in the same session. This problem has been around since 2017 and Microsoft didn’t fix it when the cmdlet transitioned to the Exchange Online management module.

The older approach supports the use of both sets of cmdlets, even if cmdlets with the same names exist in the two sets using the AllowClobber parameter to import the cmdlets with Import-PSSession. A great example of how this is done is in Michel de Rooij’s mega-script to connect to Office 365 services with PowerShell. You can also use a prefix to identify the cmdlets from the different sets.

Issues Installing Update for SharePoint Online PowerShell

Version 16.0.19927.0 of the SharePoint Online PowerShell module supports some new functionality with Conditional Access policies. Normally, updating this module is a matter of downloading the latest version from Microsoft’s site and installing it on a workstation.

In this case, my PC had version 16.0.19418.12000 installed and after the update, I was puzzled that PowerShell continued to load that version. I blamed a bad download, so I downloaded and installed the new module again. Version 19418.12000 persisted. And persisted.

Even a cycle of removing the module, rebooting the PC, and installing the new module refused to dislodge 19418.12000. Eventually, I discovered that the files for this version were in C:\Program Files\WindowsPowerShell\Modules\Microsoft.Online.SharePoint.PowerShell while those for 16.0.19927.0 were installed into C:\Program Files\SharePoint Online Management Shell. After I deleted the older files, PowerShell picked up the new version.

This is obviously not the way that things should work. Microsoft is investigating… In the meantime, I’m chalking these problems down to yet another event along my rich voyage among PowerShell modules, just like the issue I had with OneDrive’s known folders and the Active Directory module.

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.

Time Running Out for Old Email Connection Protocols

I’ve heard some people doubting that Microsoft will remove basic authentication from seven Exchange Online mailbox connection protocols. The argument advanced is that customers won’t allow this to happen because removing Exchange Online basic auth connections will be too disruptive. That is, unless they’ve experienced the unique joy of being the victim of an Exchange password spray attack.

Update: The big switch-off date is now October 1, 2022. On that day, Microsoft will begin the final process of disabling Exchange Online basic auth in Microsoft 365 tenants that still use basic auth for email connections.

Update (September 1): Microsoft is granting tenants the ability to get a three-month extension before retiring basic authentication. See this article for more detail. January 1, 2023 is the new drop-dead date.

Disruption will certainly happen if you’re running obsolete clients like Outlook 2010 which don’t support modern authentication. Or if you use POP3 and IMAP4 to connect to fetch messages and the developers of your email client don’t pick up the new OAuth-compliant versions of these protocols. The biggest issue here is likely to be with devices that use these protocols to connect to Exchange to fetch messages as I have no idea how the device manufacturers will approach the upgrade. Other issues exist with applications built with Exchange Web Services where programmers don’t quite know how to move forward (this blog by MVP Ingo Geganwarth might help). Or if you have an old mobile email client which likes to use basic auth with ActiveSync.

Finally, there’s PowerShell… We’ll have to switch to modules which support modern authentication, like the Exchange Online Management module, and upgrade scripts to make sure that authentication still works, especially for scheduled scripts which run without human intervention.

There’s work to be done. Lots of work, but the final goal of eliminating insecure authentication methods from Microsoft 365 is worthwhile. Those who doubt this statement might consider a recent case study by the Microsoft Detection and Response Team (DART), the people who help companies when malicious actors have penetrated networks to create persistent threat.

A Case Study of a Compromised Office 365 Tenant

The case study explains that attackers obtained the password of the Office 365 administrator via a password spray attack. Multi-factor authentication (MFA) was not enabled on this account. Microsoft says that 99.9% of account compromise attacks are blocked with MFA. Attacks like password sprays, which rely on basic authentication, run into a stone wall when an account uses MFA, which is why MFA should be used by as many Office 365 accounts as possible.

Once the attackers penetrated the administrator account, all of the Microsoft 365 tenant was theirs to exploit. They used content searches to find “interesting” information in mailboxes and extracted and moved the information out of the company in preparation for something like a business email compromise attack. Poor auditing of actions like content searches and non-owner access to mailboxes enabled the attack to succeed. Eventually DART cleaned things up and concluded that

• MFA should have been used to prevent the attack succeeding on the administrator account.
• Conditional Access Policies would have helped prevent unauthorized access.
• Auditing should be part of regular operations.
• The only safe option is disallowing legacy authentication altogether. Blocking basic authentication for email is a great step forward in removing legacy authentication.

Hard Data for Account Compromises

Further insight (if needed), comes from an interesting session given at the RSA Conference 2020 called Breaking Password Dependencies: Challenges in the Final Mile at Microsoft featuring Alex Weinert (Director of Identity Security at Microsoft) and Lee Walker (Principal Architect, Microsoft IT). During this session, Microsoft said that about 1.2 million of their cloud accounts were compromised in January 2020. This is only 0.5% of the total user base, but it still points to the level of attack. In effect, an Office 365 tenant with 10,000 accounts can expect to have 50 compromised accounts every month, unless they use MFA, conditional access policies, and block legacy authentication. Although MFA alone blocks 99.9% of the compromises, but only 11% of enterprise users used MFA in January 2020.

Password Spray and Replay Attacks

Microsoft revealed that 480K of the accounts were compromised by password spray accounts (Figure 1), and 99% of password spray accounts use Exchange Online basic auth with IMAP4 and SMTP.

A similar number of accounts were compromised by password replay attacks. People often use the same password for personal and work accounts, so if a password becomes known to attackers because a service is compromised, they might try to reuse that password to attack other accounts belonging to the user. Again, legacy protocols play a big role here, especially the combination of IMAP4 and SMTP. The protocols due to be disabled for basic auth on October 13, 2020 are highlighted in Figure 2. Microsoft says that a 67% reduction in compromises happens for tenants who disable legacy authentication. You can’t eliminate the possibility of attack, but you can make the task of the attacker much harder.

The Need to Eliminate Legacy Email Client Protocols

Looking at the account compromise rate by protocol, you clearly see the need to remove Exchange Online basic auth for email connection (Figure 3). This graph underlines why Microsoft is driving for the October 13, 2020 date (now October 2022).

The session also includes a lot of interesting and useful information about Microsoft’s experience of blocking legacy authentication within their own infrastructure. If you’re involved in the plan to prepare your tenant for the changes coming in October, it’s worth listening to how Microsoft worked through dealing with applications that depended on basic auth during their rollout.

Time to Get Going

It’s possible that Microsoft will come under customer pressure to extend the cut-off date for Exchange Online basic auth connections. I hope they resist. Hard evidence exists that eliminating basic authentication helps enormously to increase resistance against attack. Why would anyone want to remain vulnerable?

Update April 30: Microsoft has announced support for OAuth connections with IMAP4 and SMTP AUTH. POP3 coming soon.

For more reasoned commentary about all things related to Office 365, subscribe to the Office 365 for IT Pros eBook and learn how to keep your tenant secure.

Last November, just as everyone was getting ready for the opening of the Microsoft Ignite conference in Orlando, Microsoft dropped a bomb on the Exchange community by updating the service description for online archiving to set a 1 TB limit for archive mailboxes. At the time, Microsoft said

“The unlimited archiving feature in Office 365 (called auto-expanding archiving) provides up to 1 TB of storage in archive mailboxes in Exchange Online.”

Calling something “unlimited” while specifying a limit was pretty silly, but the lack of communication was the biggest issue. No formal announcement was made, probably because those responsible for the decision realized the howls of derision that might have erupted from the community. Not to mention the hard questions that Microsoft representatives might have had to handle at Ignite sessions.

Conversations and Communication

In any case, several hard conversations occurred at Ignite, notably between the Office 365 MVPs and the Exchange development group. It was pointed out that making a major reversal in strategy by imposing an arbitrary limit and saying nothing about it wasn’t a good way to build customer confidence. A terabyte is a lot of information, especially in a mailbox, but setting limits without explaining why this is a good thing or how many mailboxes are affected undermines Microsoft’s message to customers that their data is best when kept in the cloud. Preferably Microsoft’s cloud.

The Business of Archiving

On the other hand, as I noted at the time, Exchange Online is part of the Office 365 business, and offering to store as much information as tenants care to import into archive mailboxes is probably not a good thing on either a technical or business level. From the technology perspective, you could imagine that a single massive archive mailbox might fill a complete mailbox database, which could create some problems in dealing with such a beast.

The economics of making huge amounts of storage available for tenants to fill with archive data is also uncertain, even at the price that Microsoft pays to purchase and operate storage in its Office 365 datacenters. In short, a case can be argued to set a limit for the automatic expansion of archive mailboxes.

A Reasonable Limit

Setting that limit at twenty 50 GB “chunks” chained together to form a 1 TB archive mailbox is reasonable. There are archive mailboxes larger than this, but not many. And once a limit is set and publicized, tenants will know what they have to work with and can stay within the limit.

A New Communications Failure

Microsoft failed to communicate with Office 365 tenants in November. And now, without saying anything to customers (again), they’ve retreated from their previous position in a new version of the service description that says:

“The unlimited archiving feature in Office 365 (called auto-expanding archiving) provides additional storage space in archive mailboxes. Each Exchange Online Archiving subscriber initially receives 100 GB of storage in the archive mailbox. When auto-expanding archiving is turned on, additional storage space is automatically added when the 100 GB storage capacity is reached.”

No mention of a 1 TB limit is visible. Nothing much changes because the previously announced limit was not implemented in software. It was an aspiration that such a limit should be in place, but no code was ever written to impose the limit or issue warnings as archive mailboxes grew, perhaps when an archive mailbox added the 20^th chunk to its set. No administrative interface was created either to allow tenant administrators to see the state of large archive mailboxes or receive warnings through any of the multiple admin portals where archive mailboxes show up in Office 365. And PowerShell, the key to Exchange administration, was not updated either. In short, November’s update was a paper exercise.

A Real Limit for Archive Mailboxes is Coming

However, I suspect that the writing is on the wall for ever-expanding archives. We will hear about this topic again after Microsoft has worked through the ins and outs of the decision and created a proper communications and implementation plan. Tenants will be told, administrators will be given the tools to manage large archive mailboxes, and the limit will be enforced. Maybe not immediately by software updates, but it will happen.

I hope the folks behind this decision understand the errors they made before the announcement appeared in November. It would be sad if they repeated the error in the future and imposed a (real) limit without warning. We can but hope.

More information about the management of Exchange Online archive mailboxes is available in Chapter 5 of the Office 365 for IT Pros eBook. Given communication like in this example, you need a strong independent source for news about Office 365.

Testing the Performance of the Exchange REST Cmdlets

Yesterday I delivered a rapid-fire 20-minute session at the Microsoft Ignite 2019 conference to report my experience of working with the new REST-based PowerShell cmdlets for Exchange Online. You can download the new cmdlets from the PowerShell gallery (the same module loads the older Remote PowerShell cmdlets and the REST-based cmdlets). You can listen to the recording online (voice and slides only, thankfully).

A more reflective article about using the cmdlets in scripts is available on Petri.com. This post has a link to a copy of the deck (below) and the code examples I used to test the new cmdlets. Hopefully the scripts are a useful starting point for your exploration of the new cmdlets.

Testing Scripts

I use the Measure-Command cmdlet to test the raw performance of the old (Remote PowerShell) and new (REST) cmdlets. Measure-Command takes a chunk of code and reports how long it took to execute the code. With a little bit of formatting, you get some nice data (Figure 1).

Here’s a basic example to run the Get-Mailbox cmdlet to fetch all user mailboxes ten times.

# Performance test for Get-Mailbox
Write-Host "Running Remote PowerShell Test..."
$TotalSeconds = 0; $TotalMbx = 0
For ($i=0; $i -lt 10 ) {
 $i++
 Write-Host "Processing run" $i
 $RPSResult = Measure-Command { $MbxRPS = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox | Select DisplayName, ProhibitSendReceiveQuota, WhenCreated,  WhenChanged }
 $MbxSec = [math]::round(($MbxRPS.Count/$RPSResult.TotalSeconds),2)
 $Result = "RPS took " + $RPSResult.TotalSeconds + " seconds (" + $MbxRPS.count + ") mailboxes: averaging " + $MbxSec + " mailboxes/second"
 Write-Host $Result
 $TotalSeconds = $TotalSeconds + $RPSResult.TotalSeconds
 $TotalMbx = $TotalMbx + $MbxRPS.Count }
Write-Host ""
Write-Host "Remote PowerShell Results"
Write-Host "-------------------------"
Write-Host "Total runs:      " $i
Write-Host "Total mailboxes: " $TotalMbx
Write-Host "Total seconds:   " $TotalSeconds
Write-Host "Avg Mbx/Sec:     " ([math]::round(($TotalMbx/$TotalSeconds),2))

Get-ExoMailbox is the equivalent REST cmdlet. Here’s what I used to test its performance:

# Performance test for Exchange REST cmdlet Get-ExoMailbox
# REST cmdlets return DisplayName in minimum property set and ProhibitSendReceiveQuota in the Quota set
Write-Host "Running RESTful Test..."
$TotalSeconds = 0; $TotalMbx = 0
For ($i=0; $i -lt 10 ) {
 $i++
 Write-Host "Processing run" $i
 $RESTResult = Measure-Command { $Mbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox -PropertySets Quota -Properties WhenCreated, WhenChanged } 
 $MbxSec = [math]::round(($Mbx.Count/$RESTResult.TotalSeconds),2)
 $Result = "REST took " + $RESTResult.TotalSeconds + " seconds (" + $Mbx.count + ") mailboxes: averaging " + $MbxSec + " mailboxes/second"
 $TotalSeconds = $TotalSeconds + $RESTResult.TotalSeconds
 $TotalMbx = $TotalMbx + $Mbx.Count
 Write-Host $Result }
Write-Host ""
Write-Host "RESTful Cmdlets Results"
Write-Host "-----------------------"
Write-Host "Total runs:      " $i
Write-Host "Total mailboxes: " $TotalMbx
Write-Host "Total seconds:   " $TotalSeconds
Write-Host "Avg Mbx/Sec:     " ([math]::round(($TotalMbx/$TotalSeconds),2))

Testing Mailbox Statistics with the Exchange REST Cmdlet

Just fetching a bunch of mailboxes isn’t very exciting, even with a new cmdlet. The next test is to call Get-MailboxStatistics to return the number of items and the quota used for each mailbox. The example below shows how I tested using Get-ExoMailbox to fetch the mailboxes and Get-ExoMailboxStatistics to return the statistics. In the call to Get-ExoMailbox, you see that we request the return of the StatisticsSeed property set. The REST cmdlets don’t return all properties by default. You must tell them what properties you want to be returned for each object. This reduces the amount of processing needed for each object and makes the cmdlet more efficient.

Another big point to note is the use the GUID of the mailbox owner as the identity for Get-ExoMailboxStatistics. Unlike the older cmdlets, the REST cmdlets allow you only to pass a user principal name or GUID as the identity. Azure AD cmdlets use the same GUID, so I use it here.

# Use Exchange REST Cmdlet to test mailbox statistics
$Iterations = Read-Host "Enter number of iterations" 
$Mailboxes = Read-Host "Enter number of mailboxes to test"
If ($Mailboxes -gt 4999) {$Mailboxes = "Unlimited"}
Write-Host "Running RESTful Test..."
$TotalSeconds = 0; $TotalMbx = 0
For ($i=0; $i -lt $iterations ) {
 $i++
# Write-Host "Processing run" $i
 $RESTResult = Measure-Command {$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -PropertySet StatisticsSeed -ResultSize $Mailboxes; ForEach ($M in $Mbx) 
    { $X = Get-ExoMailboxStatistics -Identity $M.ExternalDirectoryObjectId ; 
      Write-Host "Run" $i (Get-Date -format g) $X.DisplayName "has" $X.ItemCount "items with size" $X.TotalItemSize }} 
 $MbxSec = [math]::round(($Mbx.Count/$RESTResult.TotalSeconds),2)
 $Result = "REST took " + $RESTResult.TotalSeconds + " seconds (" + $Mbx.count + ") mailboxes: averaging " + $MbxSec + " mailboxes/second"
 $TotalSeconds = $TotalSeconds + $RESTResult.TotalSeconds
 $TotalMbx = $TotalMbx + $Mbx.Count
 Write-Host $Result }
Write-Host ""
Write-Host "RESTful Cmdlets Results"
Write-Host "-----------------------"
Write-Host "Total runs:      " $i
Write-Host "Total mailboxes: " $TotalMbx
Write-Host "Total seconds:   " $TotalSeconds
Write-Host "Avg Mbx/Sec:     " ([math]::round(($TotalMbx/$TotalSeconds),2))

Piping is Best

The previous example uses a ForEach loop to process each mailbox. This works and it’s a technique that’s extensively used in scripts that process Exchange information. However, you can get even better performance if you pipe data from one REST cmdlet to another because multithreading then kicks in. Here’s an example.

# Optimized Pipeline Version for Exchange REST cmdlets test
# RESTful Cmdlets Version
[int]$Iterations = Read-Host "Enter number of iterations" 
[int]$Mailboxes = Read-Host "Enter number of mailboxes to test"
If ($Mailboxes -gt 4999) {$Mailboxes = "Unlimited"}
Write-Host "Running RESTful Test..."
$TotalSeconds = 0; $TotalMbx = 0
For ($i=0; $i -lt $iterations; ) {
    $i++
    Write-Host "Processing run" $i
    $RESTResult = Measure-Command {
      $Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -PropertySet StatisticsSeed -ResultSize $Mailboxes;
     # Write-Host "Run" $i (Get-Date -format g) 
      $Mbx | Get-EXOMailboxStatistics | ForEach-Object {
        Write-Host "Run" $i (Get-Date -format g) $_.DisplayName "has" $_.ItemCount "items with size" $_.TotalItemSize   }
    }                                                                            
$MbxSec = [math]::round(($Mbx.Count/$RESTResult.TotalSeconds),2)
$Result = "REST took " + $RESTResult.TotalSeconds + " seconds (" + $Mbx.count + ") mailboxes: averaging " + $MbxSec + " mailboxes/second"
$TotalSeconds = $TotalSeconds + $RESTResult.TotalSeconds
$TotalMbx = $TotalMbx + $Mbx.Count
Write-Host $Result }
Write-Host ""
Write-Host "RESTful Cmdlets Results"
Write-Host "-----------------------"
Write-Host "Total runs:      " $i
Write-Host "Total mailboxes: " $TotalMbx
Write-Host "Total seconds:   " $TotalSeconds
Write-Host "Avg Mbx/Sec:     " ([math]::round(($TotalMbx/$TotalSeconds),2))

Although piping is undoubtedly faster, in a practical sense it’s often not possible to put everything you might want to do to process mailbox data through the pipe, which is why many scripts use ForEach loops. However, if you can convert your code to a piped version, you will get much better performance, which is something to consider.

Looking for more information about writing PowerShell for Exchange Online and the other parts of Office 365? The Office 365 for IT Pros eBook includes tons of examples, all written with tender loving care.

New 1 TB limit for Exchange Online Bottomless Archives

Microsoft announced a “a truly bottomless archive” for Exchange Online in June 2015. At the time, Microsoft said that “the unlimited archive storage…” was available to “our Office 365 Enterprise E3 and E4 (now E5) plans.” The roll-out of the technology had some challenges, but stabilized at the end of 2016. I haven’t been aware of any great problems since and tenants now have some pretty large multi-terabyte archive mailboxes.

It turns out that unlimited isn’t unlimited after all. Microsoft recently updated the Exchange Online Archiving Service Description to say “The unlimited archiving feature in Office 365 (called auto-expanding archiving) provides up to 1 TB of storage in archive mailboxes in Exchange Online.” The same limit is documented in Exchange Online limits, which says “Each user initially receives 100 GB of storage in the archive mailbox. When auto-expanding archiving is turned on, additional storage is automatically added when the 100 GB storage capacity is reached. Office 365 provides up to 1 TB of additional storage in an archive mailbox.” The limit is enforced by restricting the number of auxiliary archives to 20. The bottom has well and truly been reached!

Users who already have archives that exceed the 1 TB threshold won’t lose data. However, they won’t be able to expand their archive by adding any more auxiliary mailboxes. At least, they won’t when Microsoft moves from a paper-based limitation to imposing a block in code.

Update August 1 2021: Microsoft’s current stance is that unlimited archiving is still supported with no mention of a 1 TB limit. However, they make the point that the growth rate of the archive should not exceed 1 GB/day to exclude activities such as migration from legacy on-premises archive solutions.

All Quiet on the Microsoft Front

Microsoft didn’t announce the change. A notification wasn’t posted in the Office 365 admin center, no press release was issued, and the information released for the Microsoft Ignite conference in Orlando this week is curiously mute on the point. The only conclusion is that Microsoft is embarrassed at having to retreat from a commitment made to customers in 2015 and emphasized multiple times since.

Why has this happened? I don’t know what circumstances convinced Microsoft to terminate unlimited archive storage. I suspect that it might be associated to the way that some migration tools use archive mailboxes as targets to import data from third-party systems like Enterprise Vault. Often there’s no problem as the migration moves information belonging to users from the legacy repository to their archive mailboxes, but issues do occur when the migration moves information for multiple users (for instance, data for ex-employees) to a single archive mailbox.

Migration to Archive Mailboxes

Microsoft makes their view clear about how people should use auto-expanding mailboxes: “Auto-expanding archive is only supported for mailboxes used for individual users (or shared mailboxes) with a growth rate that doesn’t exceed 1 GB per day. Using journaling, transport rules, or auto-forwarding rules to copy messages to an archive mailbox is not permitted. Microsoft reserves the right to deny unlimited archiving in instances where a user’s archive mailbox is used to store archive data for other users.”

In other words, they don’t want tenants to import more than 1 GB of day into an archive mailbox (most migration products will move more than this amount daily) and they don’t want tenants to set up archive mailboxes that act as repositories for legacy data (shared by multiple users). In a nutshell, Microsoft views auto-expanding archives as a personal user-centric feature. For these reasons, if you’re involved in a migration project to move data to Exchange Online, ask your migration vendor how they handle the provision and population of target mailboxes.

Exchange Online is a Business

Microsoft is sensitive to what they see as unexpected or unanticipated use of cloud resources. Office 365 is a business that now serves 200 million monthly active users. It’s a major driver for Microsoft’s cloud revenues. But it costs to install and manage the 200,000 Exchange Online servers and storage is a major part of the cost envelope.

Enterprise users are assigned generous 100 GB limits along with another 100 GB for recoverable items plus the archive. Although Microsoft uses cheap JBOD for most of its Exchange Online storage, when you think about the amount of storage needed to accommodate truly bottomless archives, you can understand why Microsoft might act if signs exist that storage is consumed in unusual ways. After all, they cut unlimited storage for OneDrive in 2015. At the time it was reported that some were using OneDrive to store massive movie collections consuming over 75 TB.

Failure to Communicate

A solid business case might exist to limit auto-expanding archives, but that’s not the point. The problem here is that Microsoft utterly failed to communicate that they no longer support bottomless archives and why the strategy needed to change.

One TB is a reasonable archive storage limit for most Office 365 tenants and shouldn’t cause enormous problems in practice, but architects and administrators must know details of technical limitations to incorporate into their plans. Sneaking in changes like this without notification will erode customer faith in the way Microsoft manages Office 365 and that’s not a good thing.

You sometimes need eyes in the back of your head to learn about everything that happens inside Office 365. That’s why we update the Office 365 for IT Pros eBook every month. Shouldn’t you be a subscriber?

Valuable Learning Tool No Longer Functional

We all know that Office 365 is in a state of perpetual change, but you’d imagine that a component that has worked perfectly well since its introduction in the Exchange 2013 on-premises server would remain stable. Alas, that’s not true and someone has broken PowerShell command logging for the Exchange Admin Center (EAC).

Exchange 2007 was the first major Microsoft server to support PowerShell. Because PowerShell was so new, the developers were taking a risk with both their implementation as the basis for all Exchange management interfaces and in how customers took to the new shell. To bridge the knowledge gap, Microsoft introduced the command logging feature in the Exchange Management Center (EMC). Command logging reported the PowerShell commands executed by EMC options. The value in the command log was obvious: administrators could learn PowerShell by reviewing the command run by Exchange to get work done. Administrators could also copy and reuse the commands in their own scripts. Command logging proved to be a tremendously valuable learning tool to kickstart PowerShell for Exchange.

Upgrades to Exchange Online

Over the years, the Exchange administration centers evolved. The browser-based EAC (in the guise of the ECP) arrived in Exchange 2010 and became the prime administrative interface in Exchange 2013. Aside from a little hiccup in Exchange 2013 (fixed in SP1), EAC included command logging in both on-premises and cloud variants and the logging feature continued its popularity within the Exchange administrator community. In the context of Exchange Online, command logging helped administrators understand the differences in the set of PowerShell cmdlets available in the cloud and how these cmdlets are used.

Exchange Online Command Logging Broken

Something changed recently. I don’t know when because I seldom use command logging anymore: after 13 years or so working with PowerShell, I have now reached the “dangerous” stage. Some would say “dangerously inept,” but that’s not important right now. I only look at the command log when I need an example of syntax for a cmdlet that I am unfamiliar with.

In any case, the option to view the command log is still available in EAC. Gio to the ? (question mark) menu and you’ll see Show Command Logging (Figure 1).

Clicking the link displays the command log. A perfectly empty command log, bereft of any useful information (Figure 2). To add insult to injury, the Learn more link is perfectly useless too.

Update (July 11): Microsoft says that they have found and fixed the problem that caused command logging fail. The fix is now rolling out across Office 365.

Command Logging is Not Auditing

To be clear, the command logging in EAC is not the same as the audit records captured in the Office 365 Audit log for administrative operations performed against Exchange Online. EAC command logging shows you the exact PowerShell commands (syntax, parameters, and values) used by Exchange to get work done. That’s why the command log is so helpful to understand and learn PowerShell. Audit logging captures records of activities in a normalized format across all Office 365 workloads. You will know that a PowerShell cmdlet was run, but will find it hard to cut and paste the cmdlet and its parameters for reuse. Also, it’s much harder to associate what you see in the audit log with what you just did in EAC because records only show up in the audit log 15 minutes or so after an action is performed. EAC command logging shows you what you just did.

A Small But Important Bug

In the overall scheme of Office 365, this is a small bug. But it’s hard to understand how something that has worked so long has suddenly experienced a problem. Obviously one of the moving parts in the landscape of Exchange Online or Office 365 caused commands to fail to show up in the log. Let’s hope that Microsoft fixes the problem soon to restore this valuable learning tool.

Need more information about Exchange Online and the rest of Office 365? Look no further than the Office 365 for IT Pros eBook. The command logging feature is so old that we don’t cover it in the book, but we do cover almost everything else.

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.

Communicate by Email with Teams Channels

Teams supports the ability of users to send email to a channel by publishing special Teams channel email addresses. (The option to generate email addresses is controlled by the Email integration org-wide setting). The addresses used by Teams channels point to hidden mailboxes in a part of Microsoft 365 managed by Microsoft and invisible to the rest of the world, which accounts for the odd email addresses in the teams.ms domain. To retrieve an email address for a channel, use the Get email address option in the […] menu (Figure 1).

You can then paste the email address into a message to send it to the channel. Teams uses a connector to pick up the new message and bring it into the channel, and all is well. A fuller explanation of how Microsoft 365 and Teams process inbound messages and deliver them to the target channel is available here.

However, because the email addresses are a little weird, it’s unlikely that people will remember them. If you think that people will want to email a specific channel regularly, you might like to create an Exchange mail contact to make it easier for them.

Creating a Mail Contact for a Teams Channel

Mail contacts show up in the Exchange Global Address List (GAL), so once an contact exists, it’s easy for users to add them as a message recipient.

• Go to the Exchange Admin Center (EAC) and select Contacts under Recipients.
• Click Add [+] Mail Contact.
• Fill in the details for the new contact. Copy the email address for the channel into the external email address field. It’s a good idea to give the contact a display name that clearly indicates its purpose. In Figure 2, I’ve added a “(Teams)” suffix.

After saving the contact, the object is available in the GAL and can be used to address messages. Outlook clients will take a day or so to pick up the new mail contact in their copy of the Offline Address Book (OAB). However, before the contact appears in the OAB, Outlook users can always consult the GAL to find the new address (Figure 3).

Users Can Delete Teams Channel Email Addresses

The only problem is that users can remove the address for a Teams channel, which invalidates the mail contact. Teams is happy to generate a new email address for the channel if requested (it won’t reuse an address), so you’ll have to update the mail contact with the new address if this happens.

Using Teams Channel Email Addresses Elsewhere

Much the same technique works if you want to add a Teams channel email address as a member of a distribution list. It is, after all, a valid email address, and in most respects, can be used in the same way as any other email address.

For more information about Mail Contacts, read the Exchange Online chapter of the Office 365 for IT Pros eBook. Teams is covered in two chapters – one for the basics and architecture, and the other covers managing a Teams deployment. Together, the two chapters span over 150 pages of invaluable material…

Exchange Online Address Book Policies

Exchange Address Book Policies (ABPs) lets organizations sub-divide the directory into multiple segments (represented by an ABP), each of which has a Global Address List (GAL), Offline Address Book (OAB), and other address lists. An ABP might be used to define users within a subsidiary company, or those who work in a certain country, or to divide students and teachers, and so on. Once an ABP is assigned to their mailbox, the user can only “see” other users who come within the scope of the ABP.

ABPs don’t create a watertight block against communication. A user limited by an ABP sees the other users defined by the ABP when they view the GAL or OAB, but they can always send email to people outside the ABP by addressing messages using SMTP addresses.

Using ABPs with Teams

Teams is an application built on top of many other parts of Office 365. As such, it shouldn’t come as a huge surprise that Teams uses Exchange ABPs to limit the ability of users to communicate with others within the same organization. There’s a lot of sense in this approach because if you have gone to the bother of defining ABPs for Exchange, you can reuse the same ABPs with Teams.

To enable ABPs for use with Teams, go to the org-wide settings section of the Teams Admin Center, select Teams settings, and scroll to the bottom of the list to move the Search by name slider to On (Figure 1). Then Save the updated settings. It will take some time for clients to become aware of the update and adjust their behavior.

When an ABP is in place, users won’t be able to use chat to communicate with users outside the scope of their assigned ABP. Also, users won’t be able to add people outside their assigned ABP as members of a team.

Discovery is Affected

What’s not known as well is that users cannot search or discover teams when ABPs are in use within a tenant. Normally, when you select the Join or create a team option, Teams displays a set of public and private teams that you might want to join. The list of suggestions is calculated by the Microsoft Graph based on signals from your activity (to know what you do) and the people you communicate with. For instance, if you chat regularly with five or six other people who are all members of a certain team, it’s likely that you might find that team interesting and so Teams will add it to its suggestions (Figure 2).

However, when ABPs are in effect, Teams can’t come up with suggestions because it cannot filter the set of teams returned by the Graph using the scope applied to the user. At least, that’s my understanding of the issue. Because Teams can’t apply the scope, it simply ignores the suggestions and doesn’t suggest anything, meaning that the user nothing except the offer to join a team through a code (Figure 3).

Because Teams has no suggestions to make, it also removes the /Join command (to show a list of suggested teams to join) from the set you can type into the command box.

ABPs are designed for email and not for Teams, so it’s inevitable that applying ABPs to Teams would have some unusual consequences like this. You learn something new every day.

Need more information about how Teams works? Well, the best place we know of is Chapter 13 of the Office 365 for IT Pros eBook. The number of changes in Teams means that Chapter 13 is one of the chapters we update most frequently.

Outlook Can Schedule Meetings to End Early, But Will Users Respond?

Poor, badly-organized meetings suck the lifeblood out of an organization. You know the type I mean: attended by too many people, most of whom spend the entire meeting processing email or answering Teams conversations, no or unspecific agenda items, no drive to achieve consensus and decision, and so on. It doesn’t matter if these meetings are in-person or electronic, they’re still a horrible waste of time.

Which brings me to an option introduced in Outlook for Windows click-to-run build 1902 onward (I’m currently using build 1903 from the monthly channel (targeted) – you might have a different version). In Calendar settings, you can opt for meetings and appointments to end a few minutes earlier than the traditional 30- or 60-minute finish. The idea is that you can finish up one meeting and be in good time for your next appointment.

Office 365 for IT Pros author Brian Reid gets very excited about the feature in his blog and explains how to apply registry settings to enable the feature for everyone, or perhaps only the people you want to confuse.

You can also deploy the new calendar settings to clients via the Office administrative template files (ADMX/ADML) for Office 365 ProPlus.

Ståle’s LifeHacks

Apart from saying “awesome” a lot, Office 365 for IT Pros author Ståle Hansen, is very enthusiastic about LifeHacks, which is apparently a way to use OneNote to do most wondrous things to organize your life better. Perhaps ending meetings and appointments five or ten minutes earlier qualifies as a lifehack, but I rather think not.

The sad fact is that software might schedule meetings to occur at certain times and to last a set period, but humans often ignore the best intentions expressed in a meeting notice. People turn up late, barge in without excuse, disrupt the flow of the conversation with inane or inarticulate comments, and generally conspire (inadvertently) to run bad meetings. Outlook’s new option will give you the satisfaction of organizing your calendar better, but it will do nothing to make meetings go smoother.

If you’d like to see the Northern Lights, you can meet Ståle and myself (and lots of other good speakers) at the Experts Live event in Oslo, Norway on May 29. I’m going to hear Ståle say awesome some more while he’s going to tolerate me talking about Office 365 governance. It’ll be awesome. And if you can’t make the conference, read the Office 365 for IT Pros eBook from beginning to end. It’s only 550,000 words… especially Chapter 10, which covers Office 365 clients.

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.

Sometimes an old Dog has New Tricks

In an Office 365 world where the publicity seems to be perpetually absorbed by Teams, it’s nice when an old program suddenly turns up and does something different. Outlook, first released 22 years old, is the old dog, and background moves is its new trick.

Background moves means that when you move items between folders, Outlook doesn’t display a blocking modal screen to display progress of the moves (“moved 100 of 1000 items…”). Progress is interesting, but while the move happens, Outlook won’t let you do anything else. This might have been OK in 1997; it’s not acceptable for modern software in 2019.

Folder Filing is an Old Habit

To be honest, I don’t use Outlook often to move hundreds of items between folders. I might have in the past when it was more common for people to organize their mailboxes into a set of carefully-planned folders. Or when I needed to move items out of my primary mailbox to a PST because of a restrictive mailbox quota (my first Exchange mailbox quota in 1995 was 25 MB). Today I don’t bother much with folders and most email stays in the Inbox and Sent Items folders until it’s moved to my archive mailbox.

Outlook’s Asynchronous Background Moves

My lack of attention to folders meant that I didn’t notice Outlook’s new trick until one of my MVP colleagues pointed it out. Using Outlook ProPlus (build 11601.20144 – version 1904 or later), if you select a batch of messages and move them to another folder, Outlook performs a background move and lets you get on with other work while it completes the move. All you see is a progress bar at the bottom of the main Outlook window. This works for clients configured in both cached and online mode.

If multiple moves are in progress, you’ll see something like this:

The most valuable thing about this feature is that it makes it feasible to move large numbers of items from the primary to the archive mailbox. In the past, this was a real pain, especially when Outlook is configured in cached mode. Now – well, it just works.

The change is only available in Outlook ProPlus (click-to-run) and isn’t available in Outlook 2016 or Outlook 2019. This might change in the future.

Surprising But Welcome

It’s surprising that a vintage program like Outlook should gain such a fundamental improvement at this point in its lifecycle. After all, Microsoft dedicated enormous effort to making Outlook a better network client in the Outlook 2003 release, which introduced the ability to synchronize the entire mailbox and a batch of networking smarts using multiple threads. That all seems so long ago now, back when connecting to Exchange invariably involved some odd whistling noises over a telephone connection.

In any case, it’s nice that Outlook now finally addresses an issue that some people have complained about for a long time (not enough people, obviously).

For more information about Exchange Online clients, including Outlook, read Chapter 10 of the Office 365 for IT Pros eBook.

Exchange Online Promises Forensic Coverage of Mailbox Accesses

In January, we reported Microsoft’s announcement that a new mailbox audit record called MailItemsAccessed in the set of actions that can be captured for mailbox activity. At the time, they said “The new action will 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.” According to Microsoft, the data gathered gives
“comprehensive forensic coverage of mailbox accesses.”

Sometimes things don’t go quite to plan in the cloud, and Office 365 Admin Center notification MC176515 published on 26 March 2019 contained the blunt message that “We have rolled back the feature, at this time, and so the MailItemsAccessed action will no longer be available.” The additional information link in the notification leads to a discussion about how to manage mailbox auditing for Exchange Online that doesn’t mention MailItemsAccessed at all and the title of the notification could be clearer, meaning that administrators could easily miss it.

All-in-all, given that the new audit record opened the possibility of comprehensive forensic coverage of mailbox accesses, Microsoft’s terse statement deserved some interrogation.

Microsoft’s Explanation

I reached out to Greg Taylor, Marketing Director for Exchange, who told me that: “There were technical challenges that during the process of rolling out of MailItemsAccessed to the different regions. Keeping in mind the necessity of complete accuracy and availability of data, we decided to roll the changes back, make the fixes and re-initiate the rollout. We will begin the rollout again soon, and will be sharing more details with respect to the rollout plan and availability.”

Reading between the lines, we can say that:

• Bugs were discovered. Speculating what might have happened, perhaps not all accesses to messages were captured in audit records , or the audit records were not correctly ingested from Exchange Online into the Office 365 audit log (something that has happened before).
• Microsoft detected the problem and because it involves data (loss?), they decided to pull the code that generates the new audit record.
• They’re working on the fixes and will restart the rollout when the new code is available. No timeline is available for when this might be.

Audit Records are Important

I think everyone will agree that audit records are important. Office 365 must generate audit records when expected, the audit records must contain the correct data, be immutable, and discoverable. The problem found by Microsoft with the MailItemsAccessed audit record might belong in either or both of the first two buckets, so it’s good that they have taken the action to find and fix the problem.

Now, if only someone could teach the people who write the Office 365 notifications how to use clear, concise, and informative language, we’d all be in a happier place.

We cover mailbox auditing and the Office 365 audit log in Chapter 21 of the Office 365 for IT Pros eBook. The advent of the MailItemsAccessed audit record is covered there. We’ll add a caveat now and remove it after Microsoft restarts its deployment. It’s what we do in the ePublishing world!

Little Things (Like MailTips) in Exchange Cause Irritation

Sometimes Office 365 drives me up the wall. It’s usually when little things don’t work like they should rather than problems with big pieces of functionality. The different ways that Exchange Online and clients handle MailTips is a current irritant.

Usually I don’t think too much about MailTips. They’ve been part of the product since Exchange 2010 and usually don’t cause any fuss or bother. Recently, Microsoft introduced a new tip in Outlook Mobile to warn users when they add a recipient to a message who’s outside the tenant. It’s a good idea that isn’t dependent on the transition to the new connection protocol for Outlook mobile, unlike many of the new mobile features Microsoft hopes to deliver in the future.

But curiously, Outlook for iOS shows different warnings depending on how the MailTips settings in Exchange Online’s organization configuration are set. On the left, we see the warning shown when the setting to disable MailTips is set, on the right, the different warning that appears when the setting is enabled.

The external recipient warning is the only one of the MailTips supported by Exchange Online displayed by Outlook Mobile.

Organization MailTips Configuration

The controls to turn MailTips on or off are in the organization configuration and can be set by running the Set-OrganizationConfig cmdlet. In this case, the settings of interest are:

• MailTipsAllTipsEnabled: Enable or disable Mail Tips. The default is True.
• MailTipsExternalRecipientsTipsEnabled: Enable or disable the tip that a message is going to an external addressee. The default is True.

Although I can’t think of any good reason to disable the warning for external recipients, it doesn’t seem right for Outlook Mobile to ignore a perfectly good setting. After all, if a setting can be set to False, then the clients that are supposed to respond to the setting should do so. The reason might lie in the fact that Outlook Mobile supports a setting to control the display of the external recipient tip in its application configuration policy. That is, if you use Intune.

Another setting (MailTipsLargeAudienceThreshold) allows an organization to set a threshold for a large recipient list (25 is the default) to warn someone when they’re about to send a message to a large group. The original idea was to warn people when they addressed messages to large distribution lists. And another (MailTipsMailboxSourcedTipsEnabled) controls whether warnings appear when people are out of the office or their mailbox quota is exceeded.

Outlook’s MailTips Settings

Possibly for historic reasons (because these settings go back to Outlook 2010), Outlook has its own controls for MailTips. Go to Options, Mail, and find the MailTips section. You can choose to never see MailTips or the selection of MailTips you want Outlook to display.

Neither OWA nor Outlook Mobile offer the same degree of control over the display of MailTips.

Differences in OWA

OWA doesn’t offer the same control over MailTips as Outlook does. Apart from this, the only issue I have with OWA is that the “new” version of OWA doesn’t display a warning if a message exceeds the 25 “large audience” threshold. Given that we’re in the middle of a transition between client versions, this is probably an oversight that Microsoft will address before they switch everyone to the new version.

Commonality Across Outlook Family

I’ve no doubt that some will be unaffected or won’t care about the variation in treatment of MailTips that exists across the Outlook clients. The fact that Outlook has its own set of controls doesn’t bother me, but I am irritated that the clients don’t all handle MailTips in the same way. It seems that Microsoft could do a better job of smoothing the differences across the different clients.

Note that it can take some time before changed settings in a tenant’s Exchange Online organization configuration become effective. OWA usually picks up changes first followed by Outlook and Outlook Mobile.

We try not to show irritation in the Office 365 for IT Pros eBook. That’s why we have this blog – to share some of the feelings that we otherwise hide.

Vulnerabilities in Exchange, Why People Need to Upgrade, and SharePoint Storage

Last week, Microsoft held the annual MVP Summit at their Redmond HQ. Paul Robichaux and I took the chance to sit down with Greg Taylor, Director of Marketing for Exchange, and Brent Alinger, who has the onerous responsibility for shipping the on-premises versions of Exchange, to tape episode 14 of our Office 365 Exposed podcast. The tape is available online or via iTunes.

This episode was taped in building 27 on the Redmond campus, home of the “Microsoft Garage“. We cover the following topics:

Fixing the Recent Exchange Vulnerability

With Brent in the room, it was a chance to discuss some of the issues surrounding the recent attack on Exchange that forced Microsoft to make some architectural changes to the product in its relationship with Active Directory and the nature of EWS push notifications. Attacks happen all the time, but this one developed over a period combining a number of techniques. The discussion was a great insight into how Microsoft reacts to threat.

Exchange 2010 and The Need to Upgrade

One of the reasons why people who still run Exchange 2010 need to upgrade soon is that they’ll lose support for security fixes in early 2020. In our chat with Greg Taylor, we debate whether these companies should move to a newer version of Exchange on-premises or embrace the cloud and run Exchange Online. Greg feels that Exchange 2016 is a good choice. See if you agree.

Teams Announcements at Enterprise Connect

Moving back to the cloud, we discussed the set of Teams announcements Microsoft made at the Enterprise Connect show last week. Anything from the advent of shared (private) channels to whiteboard to new devices was fair game for us. We also chatted about the success of Teams now that 500,000 organizations use the app.

Storage and the Base Office 365 Workloads

In the last section of the podcast, we discussed how the two base Office 365 workloads (Exchange and SharePoint) handle the effect of retention policies. In a nutshell, Exchange provides storage in individual mailboxes (the recoverable items structure) to hold retained items and doesn’t charge this storage against a user’s regular mailbox quota. SharePoint takes a different approach and assigns a storage quota to the tenant as a whole and it’s up to the tenant to decide how to use that quota. The deployment of retention policies to SharePoint comes with a consequence for storage usage, so tune in to hear more.

Next Podcast

Paul and I are separated by the Atlantic, which makes it a little difficult to organize these podcasts. One of these days we will figure out how to use technology to make the task easier. Until then, stay tuned for the next podcast.

Podcasts are great, but they are a point in time view of a subject. A book that updates its content is another way to keep informed about what’s happening, and that’s what we do with Office 365 for IT Pros.

Luring the Unwary into Clicking an Attachment

The growing popularity of cloud services makes it common to receive documents for eSignatures from services like DocuSign or Adobe Sign. Attackers note trends like this and try to exploit the tendency of humans to accept things on face value, which is the basis of this phishing attempt.

The attack is relatively crude as the signs that the message is false are pretty obvious. First, no respectable eSigning service would send messages from a public email service like bluewin.ch (run by SwissCom in Switzerland). Second, the email address to the left of the domain is obfuscated. (In this case, the address is microsoftexchange3297e09615bc6ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109eerror329e71ec88ae4615bbc36ab6ce41109e@bluewin.ch).

Seeing an address like this is suspicious because there’s no reason for a legitimate service to disguise their email address in customer communications. For example, DocuSign uses dse@docusign.net for its notifications). Further examination of the message header with the useful Message Header Analyzer (MHA) add-on for Outlook didn’t reveal anything to make me believe that the message was valid.

Examining the Link

The next thing is to look at its payload. The user is asked to click a link to see a PDF document. The reader is conned into believing that the link will take them to OneDrive (using a blurry graphic), but it really leads to digitaloceanspaces.com. There’s no need to go any further to prove that this message is a phishing attempt because no valid communication would signal that it comes from OneDrive and go to a developer site.

Reporting Phishing Messages

If you receive a message like this, you can report it to Microsoft with Outlook or OWA. Microsoft analyzes reported messages to understand the techniques used by attackers to bypass anti-malware checks such as Exchange Online Protection. The intelligence gathered is used to improve the checks.

Given the volume of spam and malware (53.49% of total email volume in September 2018), some phishing messages will always get through. Here are two other examples of recent phishing attempts: “Encrypted file from OneDrive” and “Retrieve pending messages for domain.”

Office 365 includes good out-of-the-box protection, but admins need to understand how to use Exchange Online Protection and users need some help to understand how to detect any bad stuff that arrives in their inboxes.

The array of anti-malware checks and tools available in Exchange Online Protection and Advanced Threat Protection for Office 365 are described in Chapter 17 of the Office 365 for IT Pros eBook. Because I read Chapter 17, I knew what to look for in the bad message.

Something’s Always Changing inside Office 365

The Office 365 for IT Pros writing team does our very best to track the ongoing changes within the service so that we can analyze and report on important updates in the book. Given the volume of change, not all of which shows up in the Office 365 Roadmap or publicly announced by Microsoft, it’s a task that keeps us busy. This week was no exception. Here are some interesting things that happened.

Microsoft Responses to Dutch Complaints about Office

In November 2018, a Data Protection Impact Assessment (DPIA) report for the Dutch Government slammed Microsoft because of the volume and type of data gathered by Office 2016 and the Office Online Apps. Microsoft uses the data to track how people use their technology and identify problems, but in the era of GDPR you’ve got to be careful about consent, ownership, and control of data.

Politico.eu reports that Microsoft has committed to update the Office desktop products by the end of April 2019. What’s missing is any discussion about changes for the Office Online Apps, specifically SharePoint Online, or the other information gathered by Office 365 in places like the audit log (see my Petri.com article for details). I feel there’s more to come here.

Yammer Feels Pressure from Teams

The news that Yammer had lost out to Workplace by Facebook in GSK was known last November. To balance the ledger, Microsoft has large multinationals like Shell and public bodies like the Belgian Police to talk about how they use Yammer. On the surface, it’s OK to lose some customers if you’re gaining others.

But the fact that Teams now supports teams with up to 5,000 members puts pressure on Yammer from an internal source. Microsoft marketing uses an inner-outer loop analogy to position Teams and Yammer and worked quite well when the largest team maxed out at 2,500 members. Doubling the limit makes Teams a bigger danger to Yammer because it cuts the number of companies who need to deploy Yammer to support large-scale conversations.

Things aren’t all rosy for Teams. A 5,000-member conversation could be bedlam and the management tools mightn’t be quite ready to support such large groups. On the upside for Teams, it is better integrated into Office 365 than Yammer is, especially in terms of compliance and eDiscovery. It’s also true that the market growth is in Teams, so where this all leaves Yammer, even if its new management delivers what was promised at Ignite 2018, is anyone’s guess.

Exchange Fixes a Privilege Elevation Vulnerability

On Patch Tuesday this week, Microsoft issued updates for Exchange 2010, 2013, 2016, and 2019 to address a privilege elevation vulnerability. Unusually, Microsoft changed the internal architecture to address problems in Exchange Web Services (EWS) push notifications and its connection to Active Directory.

It’s interesting that although many reports were published about the original problem and the dire consequences that might ensue should an attack penetrate your Exchange server, relatively few sites followed up with coverage about the fixes. This proves that bad news is always easier to sell than good. It’s also worth noting that no evidence exists that the techniques exploited by the vulnerability were ever used to attack Exchange outside test conditions.

The EWS fix has been in production in Exchange Online for some time and no problems have been noted with clients that consume push notifications (to learn about new mail, for instance). It’s a nice example of how Office 365 validates fixes at massive scale before code is delivered to on-premises customers. On the other hand, it can be argued that the vulnerability is yet another reminder why it’s easier to run email in the cloud…

Charting Microsoft 365 E3 and E5

Microsoft employee Aaron Dunnage did the community a favor by publishing some graphics to illustrate the component parts of the Microsoft 365 E3 and E5 plans. Only licensing specialists find the details of the licenses and add-ons you might need for different Office 365 features, so it’s nice to have a graphic overview. A reduced-size version is shown below. To get the real thing, go to Aaron’s Github repository.

With so much changing that affects how Office 365 works, don’t you think you need to learn from a book that’s always being updated? Subscribe to Office 365 for IT Pros today!

Azure Active Directory and Office 365

In December 2015, I wrote an article asking if Azure Active Directory was becoming the Achilles Heel of Office 365. The article followed a significant Exchange Online outage in Western Europe, similar in some ways to the events of January 24-25. Users couldn’t connect to their mailboxes and those who could experienced some latency or slowness issues.

Unhappy Run of Events

Azure Active Directory has been having an unhappy run of outages recently, notably in September 2018 when a lightning strike in Texas caused issues for many services and in November 2018 when a problem with the Multi-Factor Authentication service made it unavailable in multiple Office 365 regions. Another authentication outage flowing from Azure Active Directory problems happened on January 29. It’s an unfortunate run of problems that underlines the truth that if you can’t authenticate, you can’t connect, and you can’t work.

Things don’t seem to have changed much since 2015, but in fact had you asked the question in August 2018 when calm had existed for several months, you might have received a different answer. Clouds change quickly and can turn on you…

What Happened in an Incident

Following the January 24-25 problems, Microsoft issued a Post Incident Report (PIR) to explain what happened in two separate but conjoined incidents (EX172564 and EX172491). The first is about a failure in capacity that affected approximately 1% of the users served by the Office 365 EMEA datacenter region and could not connect to their mailboxes. The other fault affected approximately 10% of the users, but not as seriously.

The figures are from the PIR. After years of monitoring Office 365, Microsoft’s telemetry is well developed, and I am inclined to accept their data. Based on the flow of reports about outages that flowed in, you might have thought that much more than 1% of users were affected. This reflects the natural inclination of people who are affected to protest while the majority who aren’t affected stay silent (they’re working).

The root cause is stated to be a Windows Server component that handles User Datagram Protocol (UDP) transactions caused a kernel lock to be held for an extended period and resulted in Domain Controllers to crash. The resulting load caused problems for the remaining domain controllers because the pool of available controllers couldn’t handle the load on the system.

Future Changes

All systems can experience problems if available capacity is reduced below the level of user demand. The PIR says that Microsoft is conducting an architectural review to understand if they need to deploy extra scalability and resiliency options. They’re also looking at the way the automated recovery worked inside Office 365 when a situation like this happens so the processes work better in the future.

I guess what happened is a unique condition that Microsoft had not designed for. What’s bad about this situation is that the weakness of Azure Active Directory to handle spikes in load caused when capacity drops continues to be a concern. Given the essential nature of Azure Active Directory to the Office 365 ecosystem, it seems like Microsoft could do more to manage spikes when things go wrong.

What Went Right

On the upside, the segmentation of resources inside Office 365 limited the effect of the problem. Inside of all European users being affected, only those users whose accounts were in the forests served by the failed domain controllers had a problem. If your account was in another forest (like mine), you didn’t have a problem. This is an example of how not putting all your eggs in the proverbial basket really is a good idea.

Another positive is the speed at which the engineers responded to the outage, read the telemetry, understood the problem, and responded with fixes. Sure, we’d all like DevOps to be even faster, but this looks as if the model worked.

It’s obvious that the telemetry and data available for debugging problems is much broader and deeper than it is inside most on-premises deployments. But that’s how it should be as otherwise managing the 175,000-plus mailbox servers inside Exchange Online would be nigh-on impossible.

Not Doom and Gloom

I’m sure that the folks who sell products to help Office 365 tenant cope with cloud failures will seize on these outages to drive home their point that Office 365 is fallible. And they’re right. All cloud services are fallible. Anything can happen from the client workstation to the internet connection to DNS to a failure inside Microsoft.

In fact, failures happen all the time. But in most cases, the segmentation of Office 365 into regions, datacenters, and even Database Availability Groups lessen the potential of a failure to spread. The MFA outage in November is a notable example of where a single point of failure caused problems across multiple regions.

Hope for the Future

Azure Active Directory has had a bad run. Let’s hope that stability is restored and the next few months are quiet. In the interim, DownDetector.com is a good place to check if you think problems are brewing, and if you use Twitter, follow the Microsoft 365 status account to get live updates. And of course, we’ll keep an eye on things here!

For more information about how to cope with Office 365 outages, read Chapter 4 of the Office 365 for IT Pros eBook.

Using Search-Mailbox with Variable Search Queries

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

A reader query asked how to run the Search-Mailbox cmdlet against a set of mailboxes when you need to execute a different search against each mailbox. It’s easy to run a search against multiple mailboxes with the same search query, but things get complicated when you try to change the query each time. The Search-Mailbox cmdlet is a powerful way to search and remove items from multiple mailboxes, but many people seemed to encounter problems when using a variable with searches (see the comments on this post).

Invoking Script Blocks

The Invoke-Command cmdlet gives us a solution. This example reads in a set of mailboxes to process from a CSV file with two columns holding the alias for each mailbox and the search query to use. The code builds a search query from a word or phrase found in the subject (enclosed in double quotes to allow spaces to be included) and a start and end date (if included in the input file). This information is used to create a variable holding the complete search command.

After the search query is prepared, we call Invoke-Command to process the Search-Mailbox command including the variable in a script block.

$Users = import-csv "C:\temp\people.csv"
CLS
ForEach ($i in $Users) {
   $Search = 'Subject: "' + $i.Subject + '"'
   If ($i.StartDate -ne $Null -and $i.EndDate -ne $Null) {
      $Search = $Search + ' Received:"' + $i.Startdate + '..'+ $i.Enddate + '"'}
   $Command = { Search-Mailbox -Identity $i.Name -SearchQuery $Search -TargetFolder Search -TargetMailbox CServices -LogLevel Full }
   Write-Host "Searching" $i.Name "using query" $Search
   Invoke-Command -ScriptBlock $Command 
} #End ForEach

The search query can obviously be much more complex than a simple text phrase. The key thing is to build the query up with whatever values are needed before sending it to Invoke-Command. Obviously you can end up with a complex script with many if then else blocks to test for different conditions, but it shouldn’t take too much time to create.

Removing Content

To remove the found content, simply add the DeleteContent switch to the command. Be careful because it is terrifically easy to make a mistake with a search query and end up removing far more information than you expect.

Tested Online

I’ve tested the code above with Exchange Online. I did not test it with an on-premises server. However, the Search-Mailbox cmdlet hasn’t changed all that much since Exchange 2010, so the code should work for on-premises organizations.

For more information about using the Search-Mailbox cmdlet, read Chapter 6 of the Office 365 for IT Pros eBook.

Email Encryption is Good, but Only Under Tenant Control

In January 2019, Microsoft revealed a plan to create a transport (mail flow) rule in Office 365 tenants to encrypt email containing sensitive data. For many reasons, not least that it’s not a good idea to interfere with the business logic a tenant chooses to apply to outbound email, Microsoft pulled back on the idea. On January 25, after a period of mature reflection, Microsoft decided to publish details of how to create the transport rule and leave it to tenants to decide if they want to use it. Those instructions are now online. This post explores the commands included in Microsoft’s instructions.

PowerShell Commands to Create Rule

The instructions use two PowerShell commands. The first runs the Set-IRMConfiguration cmdlet to update the rights management configuration for Exchange Online in the tenant. The command sets the DecryptAttachmentForEncryptOnly switch to $True to give recipients of messages protected with the default Encrypt-Only template full rights over any attachments. The default value of this setting is $False, which means that attachments remain encrypted.

Unfortunately, the command published in the article is incorrect as it uses DecryptAttachmentsForEncryptOnly instead of
DecryptAttachmentForEncryptOnly.The correct command is:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Microsoft’s New Transport Rule

The next command runs the New-TransportRule cmdlet to create the transport rule. The rule applies the Encrypt-Only template to protect any messages that include the following Office 365 sensitive data types:

• ABA Routing Number.
• Credit Card Number.
• Drug Enforcement Agency (DEA) Number.
• U.S. or UK Passport Number.
• U.S. Bank Account Number.
• U.S. Individual Taxpayer Identification Number (ITIN).
• U.S. Social Security Number (SSN).

The Encrypt-Only template is used because it is available to every Office 365 commercial tenant and any Outlook.com user. Any other recipient can go to the Office 365 Message Encryption portal to decrypt the content.

Checking the Rule

The sensitive data types are very U.S.-centric and might need to be adjusted for your tenant to include data types that are more commonly used in your organization. I imagine that Microsoft chose the set for the rule because they are well-known and prove the potential value of the rule rather than deciding that these types make sense for every Office 365 tenant. Remember that you can create your own custom data type and use it if needed.

Unhappily, the PowerShell gods conspired against this command as well because it also has an error. The command as given by Microsoft is:

New-TransportRule -Name "Encrypt outbound sensitive emails (out of box rule)" -SentToScope  NotInOrganization  -ApplyRightsProtectionTemplate "Encrypt" -MessageContainsDataClassifications @(@{Name="ABA Routing Number"; minCount="1"},@{Name="Credit Card Number"; minCount="1"},@{Name="Drug Enforcement Agency (DEA) Number"; minCount="1"},@{Name="U.S. / U.K. Passport Number"; minCount="1"},@{Name="U.S. Bank Account Number"; minCount="1"},@{Name="U.S. Individual Taxpayer Identification Number (ITIN)"; minCount="1"},@{Name="U.S. Social Security Number (SSN)"; minCount="1"}) -SenderNotificationType "NotifyOnly"

The problem is the last parameter where SenderNotificationType should be NotifySender. Change the command and replace the last parameter with NotifySender = “NotifyOnly” and PowerShell will happily create the new rule.

Adjusting for Your Office 365 Tenant

Before running New-TransportRule, remember to adjust the command to include the sensitive data types that you want to check for and any other changes deemed appropriate for your tenant. For instance, you might not want to encrypt email to every other domain and decide that protection should only be applied to specific domains.

If you don’t want to work with transport rules through PowerShell, you can run Microsoft’s command and then edit the transport rule through the Exchange Admin Center GUI. As you can see below, it is often easier to adjust settings through a GUI. In this case I limit the domains that receive protected email. If you choose to limit the rule to selected domains, you must also remove the notification to the sender as this setting conflicts with a domain list (for no apparent reason)

It is important to check that the new rule does not conflict with any other rule that already exists. For instance, you might discover that another rule does something else to messages sent to the selected domains and then exits rules processing, so messages will never be encrypted.

The old advice to never trust and always check code downloaded from the internet holds true, even when you download code written by Microsoft.

We cover rights management and email encryption in Chapter 24 of the Office 365 for IT Pros eBook while transport rules are described in all their glory in Chapter 17.

Helping Teams be Compliant

The annual LegalTech conference took place in New York City this week. It’s the highlight of the year if you are interested in compliance technology, and it’s the reason why Microsoft made a number of announcements relating to compliance features in Office 365. Among these was a post about updates for records management, which is how we get to Teams compliance records.

The text referenced a report commissioned by Microsoft from Cohasset Associates (a company specializing in records management) to examine how Exchange Online and the Office 365 Security and Compliance Center meet the requirements of rules such as SEC 17a-4 and FINRA Rule 4511 about the storage and management of electronic records. This is a big deal for Office 365 because if the service can’t meet regulatory requirements, companies subject to those requirements can’t use Office 365.

The report is worth reading (download it here). Because a third-party wrote it, Microsoft had to answer their questions about how Exchange Online and Office 365 work and what changes are coming in the future. Among the topics covered is how the Office 365 substrate captures compliance records for Teams channel and personal conversations, and it’s here that some interesting facts are highlighted.

Teams Compliance Records and Regulation

The report plainly lays substantial weight on the value of Teams compliance records in terms of Microsoft’s ability to satisfy different regulations. However, it also notes several times that Teams compliance record do not include user responses (for example, when someone “likes” a message) – a fact first revealed in Chapter 13 of Office 365 for IT Pros. One thing we didn’t note is that the GIFs and other graphics are represented in compliance records by links which might change over time. The report notes that Microsoft plans to capture responses in compliance records later this year (July 2019).

[November 12: Microsoft still hasn’t addressed the problem of capturing reactions in Teams compliance records. The problem is proving somewhat more difficult than they anticipated.]

Another topic discussed in the report is the way that Teams compliance records capture individual messages instead of the transcript format used to record conversations by Skype for Business. Although the complete conversation is captured, it is in the form of individual items that must be fitted together to reconstruct the flow of the conversation. Apparently, Microsoft is going to deliver a way to reform conversations from compliance records around the same time as they capture responses. This should also appear around July 2019.

[November 12: Office 365 Advanced eDiscovery is getting the ability to present Teams compliance records “in context,” which is similar to seeing a transcript. Printing off a transcript for an investigator is still not possible.]

Teams Compliance Records are for Compliance – Not Backup

Many people make the mistake that Teams compliance records are exact copies of the messages and graphics stored in the Teams Azure services. Of course, as obvious from the shortcomings noted in the Cohasset report, this is inaccurate. Which then makes it strange when backup companies claim that they support Teams because they can copy the compliance records from Exchange Online. They can certainly copy the compliance data, but can they restore conversations in a channel or personal chat? That’s the key question, and it’s not one that can be answered until Microsoft delivers a suitable API to stream data out of the Teams chats and graphics data stores in a form that can be backed up and restored.

Druva Cites Office 365 for IT Pros

Speaking of backups, the Office 365 for IT Pros team was delighted when W. Curtis Preston, Chief Technologist of backup vendor Druva, used text from Chapter 4 to support his contention that Office 365 tenants need backups. The purpose of the book is to lay out information about how Office 365 works so that tenant administrators can make better decisions. In the case of backups, we can only comment about the current state of backup technology and the capabilities available to process data from Office 365.

Old-Style Backups No Longer Viable

Four years ago, it was good enough to cover Exchange Online and SharePoint Online. Today it is not. The way that applications are more integrated than ever before and the inter-dependencies which exist between workloads mean that the old-style workload-specific thinking about backups is no longer viable. It’s also true that anything written about Office 365 before 2018 can be discarded when it comes to backups because of the new features introduced by Microsoft such as Files Restore for OneDrive for Business (and soon for SharePoint Online) and the change in work practice like the movement of communications from email to Teams. You absolutely need to understand what you can do to protect against threat using out of the box features before concluding that added protection is necessary.

The question of whether an Office 365 tenant should invest in third-party backup is a business decision that is highly influenced by industry focus, data sovereignty, applicable regulations, willingness to accept risk, and funding. In short, it’s down to the tenant to make the decision. All we can do in a book like Office 365 for IT Pros is set out questions that you should debate with backup vendors before making a decision to use backups. The decision usually comes down to risk versus cost. If you understand the risk of running without backups and know how to use the features built into Office 365 to mitigate your exposure, then you might be able to forego the extra cost and complexity of paying for a cloud backup service. It’s your call.

And to be fair to some backup vendors who don’t peddle FUD to convince customers that they need their products to resist horrible failures, I do see a willingness to discuss the issues and understand the current shortcomings. It’s good to talk.

For more about Teams compliance records, see Chapter 13 of the Office 365 for IT Pros eBook. And if you want to know about our views on backups for Office 365, that’s all explained in Chapter 4.

The Dangers of What You Read on the Internet

We live in a time when more information than ever before is available for us to read, most of it on the internet. It’s fantastic that so much information is available but the downside is that a lot is simply rubbish. A good example is the number of blogs with outdated or misleading content.

Technology companies often post what seems to be technical content in an attempt to attract people to their sites. Search engines don’t include a bovine-emitted brown smelly material detector yet. They can’t tell the difference between useful content and bad material that should never have been published.

It’s good that technology companies seek to inform potential customers about how their products work, but there’s a big difference between a good marketing blog post and a bad marketing blog post. Good posts are information-rich and don’t seek to force their products down the throats of the reader. Bad posts position their product as the solution that you’ve been waiting for and explain why.

A Solid Security Post

Here’s an example to show what I mean. The Fox IT post explaining why people who want to resist phishing attacks shouldn’t depend on digitally signed email as evidence that the sender is who they say they are is an interesting read. I feel better about the competence of the company because I learned something from the post. As such, if I need to engage a cyber-security company, Fox IT might be a candidate.

A Bad Marketing Post

CloudAlly delivers an example of what I consider to be a bad marketing piece when it writes about Microsoft Cloud Backup and Data Recovery. Fair disclosure: I have written many times about why I don’t think most Office 365 tenants need to pay extra for a third-party backup solution, and I’ve had some good debate with vendors in the space, like Spanning.

Any article that runs words together like “Microsoft Office 365 Exchange” is suspect from the start because this looks as if the author is looking for a good SEO score by combining words that people might search for. And remember, the article is supposed to be about Microsoft Cloud Backup, not just Exchange Online (which it is). Office 365 is not covered as there’s no mention of how to backup and restore Office 365 Groups, Teams, Planner, Yammer, SharePoint Online, OneDrive for Business or anything else that might in the Microsoft Cloud. In short, the title and the content don’t match up.

Another problem is that the author doesn’t understand that Exchange Online takes no backups at all and uses Native Data Protection instead. The article says that Exchange Online “only backs up information to a certain point and after that point, it becomes unrecoverable.” This is total rubbish. But then again, Native Data Protection has only existed since Exchange 2010 so maybe CloudAlly haven’t heard about it yet.

Fear Tactics 101

Content in its ignorance, CloudAlly then trots out the same old fear tactics that all backup vendors use to justify their products. You need to take backups (preferably with our technology) because you can permanently lose data because of:

• malicious activity by hackers
• disgruntled employees
• corruption through third party app synchronization gone awry
• employee error

Unfortunately, because Microsoft Office 365 Exchange is not set up for daily cloud backups, that means these unexpected data losses may be irreversible.

I have often challenged backup vendors to provide evidence of how often any of these situations happen. Few respond. Hackers do attack and ransomware attacks can seek to harm data (but the recent point-in-time restore feature in SharePoint and OneDrive for Business helps). I haven’t experienced a hacker compromise of mailboxes though. Maybe some do penetrate mailboxes and happily go and delete stuff, but Exchange Online keeps deleted items for 30 days, so I assume that someone would restore the lost information before then?

“Corruption through 3rd party app synchronization gone awry” is new to me. I’d like to know what CloudAlly is thinking about here. Has ActiveSync gone nuts for someone?

Evidence Please!

Editors (and our own pride as writers) make sure that those of us who write for sites like Petri.com cite evidence for statements we make. Good posts do likewise (look at the detail in the Fox IT post). Bad ones like CloudAlly’s treatise on backup combine FUD, unsubstantiated factoids, and marketing assertions in a bid to look authoritative. Sadly there are too many of these kind of posts floating around, which is why people need to keep their BS radar turned up high.

Our views on managing Exchange Online mailboxes are in Chapter 6 of the Office 365 for IT Pros eBook. Then again, we also cover SharePoint Online, OneDrive for Business, Office 365 Groups, Teams, Planner, and Yammer. Maybe some companies should read the book before they write posts about Office 365?

Where Did that Service Domain Come From?

In early January, some Exchange Online administrators noticed that the tenant service domain was listed in front of the output from several PowerShell cmdlets. For example, if you ran the Get-RetentionPolicy cmdlet to return the set of mailbox retention policies know to Exchange Online, you’d see something like this:

Get-RetentionPolicy     

Name                 RetentionPolicyTagLinks   
----                 -----------------------   
Default MRM Policy   {office365itpros.onmicrosoft.com\Never Delete...} 

The service domain also showed up in mailbox properties when viewed through the Exchange Admin Center (EAC).

A Quick Reverse

When Microsoft was asked why the cmdlets included the service domain, it emerged that this was an unexpected side-effect of a change made to solve a problem. Microsoft later reversed the change and the cmdlets ceased outputting the service domain on January 7.

Everyone can appreciate that code changes are sometimes necessary to fix problems. What’s not so good is the obvious lack of testing and control that allowed the update to be introduced into Exchange Online without understanding what effect this might have. For instance, although PowerShell scripts continued running and were unaffected by the change, it’s possible that changing the output of a cmdlet could wreak havoc on a tenant’s operational processes.

Likewise, when a cmdlet starts to behave differently after years of stability, it causes heartburn for administrators and help desk staff who don’t know why this might be the case. And of course, documentation based on the earlier behavior needs to be updated.

Even Well-Intended Changes Need Testing

I’m sure that the change was valid and did what it was supposed to do. However, allowing a change to proceed into a service that has hundreds of millions of users without full testing is just unacceptable. Let’s hope that this was a minor blip in Microsoft’s quality control and change management systems.

This is the kind of change that the Office 365 for IT Pros team keeps an eye on… and lets you know if we think it’s important. With over 1,400 pages of content between the main book and companion volume, there’s a heap of detail to master in Office 365.

Exchange Online Makes It Easier to Identify Problematic Sessions

Anything that helps Office 365 tenant administrators to track attempted or actual hacks is a good thing. Microsoft’s January 4 post telling us that Exchange Online mailbox and admin audit records now include a session identifier is an example of a small but useful change. I don’t need to repeat the description of what the change is as that ground has been well covered by the original post and the many duplicates that invariably appear to repeat the information given by Microsoft. But what hasn’t been explained is how to use the session identifier in a practical sense. Let’s try here.

Office 365 Audit Log

The first thing to know is that Exchange mailbox auditing must be enabled for any records to be captured. Auditing is enabled by default for Exchange Online, but it’s always wise to check. The second thing is that a tenant must also enable the ingestion of records from workloads into the Office 365 audit log. This is a one-time action.

Once enabled, audit data from Exchange flows into the audit log. Records show up roughly 15 minutes after an event happens. The delay is because of the need to gather data and pass the records through the normalization process to transform Exchange data into Office 365 audit data before ingestion into the log.

Audit records remain in the audit log for 90 days (for accounts with Office 365 E3 licenses) or 365 days (for those with Office 365 E5 licenses). Once the retention period elapses, Office 365 removes the audit records from the log. If you want to keep audit data for longer, you need to invest in a third-party product such as Quadrotech’s Radar for Security and Audit.

Looking for Audit Records

You can use the Audit log search functionality in the Microsoft 365 Compliance Center to look for Exchange activity, and then examine details of the records. As shown below, the session identifier is among the properties revealed when you click the More information link when viewing an audit record.

Understanding AuditData

Many of the interesting properties captured in an Office 365 audit record, including the session identifier, are held in a JSON-formatted property called AuditData. It’s difficult to track all the actions that occur within a specific session using the SCC interface and the better approach is to use the Search-UnifiedAuditLog cmdlet to find relevant records and examine what they hold.

However, because the session identifier is tucked away within the AuditData property, we must convert the JSON data before we can look at the session identifier. The Search-UnifiedAuditLog cmdlet includes a SessionId parameter, but it has no relevance here as it does not filter records based on the Exchange session identifier.

Extracting and Reporting Audit Events

The process to start tracing the events belonging to a session are therefore:

1. Find the audit records for the relevant period and filter them to extract the events generated by Exchange.
2. Extract the information held in the AuditData property for each record.
3. Report what we find.

This PowerShell code is based on an example found in the reporting and auditing chapter in the Office 365 for IT Pros eBook. You’ll notice that some of the MailboxLogin records have no session identifiers. This is because these are PowerShell sessions that use basic authentication to connect rather than sessions generated by Exchange clients like OWA or Outlook. Only sessions that use modern authentication have their session identifiers recorded.

[array]$Records = (Search-UnifiedAuditLog -StartDate 4-Jan-2019 -EndDate 5-Jan-2019 -ResultSize 1000 | ? {$_.RecordType -like "*Exchange*"})
If ($Records.Count -eq 0) {
   Write-Host "No Exchange audit records found." }
 Else {
   Write-Host "Processing" $Records.Count "Exchange audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $ReportLine = [PSCustomObject]@{
           TimeStamp   = $AuditData.CreationTime
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Status      = $AuditData.ResultStatus
           SessionId   = $AuditData.SessionId
           Mailbox     = $AuditData.MailboxOwnerUPN }
      $Report += $ReportLine
  }}
$Report | Sort SessionId, TimeStamp | Format-Table Timestamp, User, Action, Status, SessionId -AutoSize

TimeStamp           User                                Action       Status    SessionId
---------           ----                                ------       ------    ---------
2019-01-04T09:18:02 Administrator@office365itpros.com   MailboxLogin Succeeded
2019-01-04T18:12:46 Administrator@office365itpros.com   MailboxLogin Succeeded
2019-01-04T18:39:51 Tony.Redmond@office365itpros.com    MailboxLogin Succeeded 1229a1b9-61fc-46f4-960a-84323c91cfc2
2019-01-04T18:49:48 Kim.Akers@office365itpros.com       MailboxLogin Succeeded 1f6d382a-a2d2-4875-a6d1-264120f4392e
2019-01-04T18:51:35 James.Ryan@office365itpros.com      MailboxLogin Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:51:55 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:34 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:35 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:54:47 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:37 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T19:00:15 James.Ryan@office365itpros.com      SendAs       Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T15:36:51 Tony.Redmond@office365itpros.com    MailboxLogin Succeeded 85808ea9-a43d-4221-9338-584c4717f740

Our code works, but it outputs events from all the Exchange sessions in the chosen period. We can improve things a tad by filtering out anything but the records belonging to the session we need to examine. It’s easy to do this by adding a prompt to allow the user to input a session identifier (if they’re smart, they will cut and paste this from a record displayed by the compliance center).

$Session = (Read-Host "What session id to look for")

And now we adjust the code to process the records so that we only output those for the chosen identifier.

If ($Records.Count -eq 0) {
   Write-Host "No Exchange audit records found." }
 Else {
   Write-Host "Processing" $Records.Count "Exchange audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      If ($AuditData.SessionId -eq $Session) {
         $ReportLine = [PSCustomObject]@{
           TimeStamp   = $AuditData.CreationTime
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Status      = $AuditData.ResultStatus
           SessionId   = $AuditData.SessionId
           Mailbox     = $AuditData.MailboxOwnerUPN }
        $Report += $ReportLine}
  }}

The output now includes only the records for the chosen session, sorted in time order:

TimeStamp           User                                Action       Status    SessionId
---------           ----                                ------       ------    ---------
2019-01-04T18:51:35 James.Ryan@office365itpros.com      MailboxLogin Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:51:55 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:34 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:35 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:54:47 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:37 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T19:00:15 James.Ryan@office365itpros.com      SendAs       Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91

It’s pretty clear from the audit log that someone logged into the James Ryan account performed a series of hard deletes (permanent removal of mailbox items) in quick succession followed by a mail send. Now we know what happened, we can look at the individual audit records to discover which items were removed from the mailbox. That takes a little more work, but it’s relatively easy because we have the relevant audit records that contain the information.

For more information about the Office 365 audit log and many practical examples of how to use it to generate reports about different tenant activities, see the reporting and auditing chapter in the Office 365 for IT Pros eBook.

A State of Constant Refresh

Part of what we do to keep the Office 365 for IT Pros eBook updated is to revisit text over time. Microsoft makes subtle changes in Office 365 all the time, and the possibility always exists that a change affects what we’ve written. And there’s always the opportunity to rewrite text to make it clearer or more concise, or simply to include new facts and insights that we have learned since, or to correct errors that crept into the text for one reason or another.

Refreshing Chapter 6

This week, I reviewed the section about sending email with PowerShell in Chapter 6. Apart from anything else, I want to upgrade the script to find obsolete Office 365 Groups and Teams to send email to prompt owners to do something if their group has fallen into disuse.

The Send-MailMessage cmdlet sends an email message using an SMTP connection to submit the message to a server. There are a ton of different posts available to read about sending email with PowerShell, but Microsoft has been rolling out some changes in SMTP client authenticated submission protocol recently, so it’s good to revisit the situation. One of those changes is very welcome in that Exchange Online now keeps copies of messages in the Sent Items folder of the sending mailbox, which removes the need to include the sender in the recipient list.

In an interesting article called “How to set up a multifunction device or application to send email using Office 365“, Microsoft describes three methods for sending email in Office 365:

• Client submission. This method is the traditional approach and uses an Exchange Online mailbox. Messages sent can be traced in the normal manner.
• Direct send via the tenant’s MX endpoint. This choice is best when you need appliances to send messages via Office 365, when you only need to send email (like notifications) within the tenant, and for bulk delivery. Messages sent this way cannot be traced because their progress is not logged.
• Connector relay. This method is best used when messages always originate from a fixed IP address.

For details about each method, see the article.

Client Submission Best for My Purposes

I tried the client submission and direct send before settling on client submission. Sending email via the MX endpoint is faster because you don’t need to authenticate and don’t use a mailbox. However, the lack of tracing is a big issue when dealing with email, and I also ran into some odd situations that I still quite don’t understand. For instance, messages seemed to be sent successfully, but they never turned up in the recipient’s mailbox. This happened intermittently and unpredictably, which is always bad.

Being Listed as a Spammer

Another issue to consider when sending email to the MX endpoint, especially you’re testing a script repeatedly, the danger exists that your activities seem awfully like what a spammer might do when viewing through the lens of the Office 365 anti-malware checks. I duly ran into this problem and was rewarded with:

Send-MailMessage : Mailbox unavailable. The server response was: 5.7.606 Access denied, banned sending IP [51.171.212.192]. To request removal from this list please visit https://sender.office.com/ and follow the directions. For more information please go to http://go.microsoft.com/fwlink/?LinkID=526655

The link brings you to a page containing instructions about how to delist a blocked address using the Office 365 Anti-spam IP delist portal. Basically, Office 365 saw the stream of messages generated over a short period from my IP address and concluded that I was up to no good.

The delisting process is straightforward. Head to the IP delist portal (see below) and:

• Insert the email address used as the SMTP from address to send messages with the Send-MailMessage cmdlet.
• Insert the IP address reported by PowerShell.
• Solve the Catcha puzzle and submit.

About 30 minutes later, you should be able to send email again from the IP address.

Submission Limits

If you choose to use the client submission method, another issue you might run into is that Exchange Online limits a user to sending 30 messages per minute. This limit is easily exceeded when you generate and send messages with PowerShell, so it is wise to build in a short 2 second delay after sending each message. Another limit that is less easily reached is that a mailbox can send messages to a maximum of 10,000 recipients per day.

In any case, I’ll return to this topic when I’m finished updating the scripts – and the section in Chapter 6.

We like PowerShell, so it’s liberally sprinkled throughout the chapters of Office 365 for IT Pros. Sometimes we make mistakes in our code, but that’s the joy of PowerShell – it’s easy (normally) to fix.

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.

Attacking G Suite

It’s no secret that Microsoft and Google don’t like each other very much, insofar as companies have emotional feelings about other organizations. Perhaps it would be fairer to say that the Office 365 development team at Microsoft view Google G Suite as their most important and feared competitor. As such, what happens inside G Suite affects how Microsoft plans for and develops Office 365.

As competitors, it’s reasonable to assume that Microsoft and Google will do whatever is legally, technically, and ethically possible to convince customers to move to their cloud platform.

A few years ago, I heard a lot about Google wins against Microsoft as the race developed to move on-premises mailboxes into the cloud. I don’t hear the same chatter any more. Google is strong in some sectors still, but the fact is that the investment Microsoft has poured  into Office 365 since 2013-4 to build out local datacenters, improve the functionality of the base Exchange and SharePoint workloads, and introduce new applications like Teams and Planner has made Office 365 the cloud leader with over 155 million monthly active users.

The obvious success of Teams versus its direct competitor (Slack) and in helping Office 365 compete with Google G Suite has tilted the balance further recently.

Price Stability for Office 365

Another factor (and probably thanks to Google) is that Microsoft has not increased prices for Office 365 plans recently with the mid-level Office 365 E3 staying at $20/user/month for quite a while. Although they are increasing prices elsewhere, Microsoft tactic with Office 365 seems to focus on driving increased revenue generated per user by trying to convince tenants to upgrade to E5 or buy feature add-ons to access new technology or features. On the other hand, sometimes they remove the need to buy add-ons, such in the case of Stream, where advanced features are now available to all Office 365 commercial customers, or sensitivity labels, which remove the need to buy Azure Information Protection plans. All in all, the stability of Office 365 pricing has been very welcome.

As the leader, Microsoft now wants to convince companies who moved to Google, perhaps from legacy Microsoft on-premises servers, to move back and that’s why the new effort exist to spin up enhanced migration tools for email, calendar, and contacts. According to the Microsoft 365 roadmap, the new tools should be available in the second quarter of 2019. You can read more about what’s happening in this Petri.com article.

Information about Office 365 in general, its commercial success in terms of user numbers and revenues, and the competition it faces from Google G Suite, can be found in Chapter 1 of the Office 365 for IT Pros eBook.

Poor Fit and Finish Within Office 365 at Times

Yesterday, we discussed Microsoft’s decision to withdraw their plan to send email to Office 365 end users after receiving strong feedback from customers. Today’s Petri.com article discusses the introduction of Privileged Access Management (PAM) for Office 365. In writing the article, I wondered if some of the effort expended by Microsoft on plans that customers have never asked for might not be better used to refine some of the obvious flaws in important systems like PAM.

It’s at times like this that I wonder just how well the fabled DevOps model really operates when it comes to creating solid software. Almost every day, I seem to run into something inside an Office 365 application that doesn’t work as well or as smoothly as it should. The fit and finish of Office 365 can be pretty bad at times – the infamous tendency of the Office 365 Admin Center to barf because of cookie problems is just one example of what I mean. It seems like the rush to deliver features is all-encompassing and the need deliver quality is of secondary consideration.

Although Microsoft must take the majority of the blame when the standard of their software slips, customers are also at fault because we accept the problems. Or at least we don’t protest as much or as often as we should.

The Future of PAM

Getting back to PAM, I like the idea of controlling elevated access very much and think it’s good that Microsoft is introducing some of the experience gained from their internal Office 365 operations into the product. What’s not so good are some of the flaws that are obvious, most of which I am sure Microsoft will move to eliminate now that they’ve been highlighted. More strategically, I wonder how the current Exchange-centric model can be brought forward to cover the rest of Office 365 when applications don’t have the rich RBAC control system that’s been developed for Exchange for nearly a decade.

I’m sure the developers have plans for progression and it will be interesting to see how PAM expands to deal with SharePoint Online, OneDrive for Business, Teams, Planner, Yammer, and anything else that comes long. We’ll see in time.

Searching for Mailbox Audit Records

The Office 365 audit log ingests mailbox audit records from Exchange Online. In the past, you might have used the Search-MailboxAuditLog cmdlet to look for audit records for a specific mailbox. For instance, here’s a command that looks for Exchange Send As audit events recorded when a delegate (to a shared mailbox or user mailbox) sends a message and impersonates the mailbox:

#
Search-MailboxAuditLog -Identity "Customer Compliants" -LogonTypes Delegate -StartDate "1-Oct-2018 12:00" -EndDate "3-Nov-2018 17:00" -ShowDetails | ? {$_.Operation -eq "SendAs"} | Select LogonUserDisplayName, LastAccessed

LogonUserDisplayName LastAccessed
-------------------- ------------
James Ryan           2 Nov 2018 12:13:35
James Ryan           2 Nov 2018 11:57:33

You can still use the Search-MailboxAuditLog cmdlet, but it might be more convenient to use the Office 365 audit log, if only because the audit log is a common place to go looking for events ingested from all the Office 365 workloads, which means that the same technique works for all workloads. The audit records are available for up to 90 days for E1/E3 users and 365 days for E5 users.

Searching the Office 365 Audit Log

Here’s how to use PowerShell to search the Office 365 audit log for information about delegates sending messages for another user with the Exchange Send As permission. The audit data property of each event is formatted in JSON, so we unpack it to find the values that we want to report. Each workload generates its own audit data payload, so some effort is necessary to figure out what the audit data contains for different events.

#
[array]$Records = (Search-UnifiedAuditLog -StartDate 1-Nov-2018 -EndDate 2-Nov-2018 -Operations "SendAs" -ResultSize 1000)
If ($Records.Count -eq 0) {
    Write-Host "No Send As records found." }
Else {
    Write-Host "Processing" $Records.Count "audit records..."
$Report = @()
ForEach ($Rec in $Records) {
$AuditData = ConvertFrom-Json $Rec.Auditdata
$ReportLine = [PSCustomObject]@{
    TimeStamp = $AuditData.CreationTime
    User      = $AuditData.UserId
    Action    = $AuditData.Operation
    Status    = $AuditData.ResultStatus
    SentBy    = $AuditData.MailboxOwnerUPN
    SendAs    = $AuditData.SendAsUserSmtp
    Item      = $AuditData.Item.Subject }
$Report += $ReportLine
}}
$Report | Select Timestamp, Action, User, SendAs

TimeStamp           Action User                           SendAs
---------           ------ ----                           ------
2018-11-02T12:13:28 SendAs James.Ryan@office365itpros.com Customer.Complaints@office365itpros.com
2018-11-02T11:57:29 SendAs James.Ryan@office365itpros.com Customer.Complaints@office365itpros.com

Mailbox events are available in the Office 365 audit between 15 and 30 minutes after they occur. The delay is due to the need for the ingestion process to run, find events in Exchange, and process them into Office 365 audit events before including them in the log.

Chapter 21 in the Office 365 for IT Pros eBook is the place to go to learn much more about using the Office 365 audit log. We have many more examples there.

No Method Available in Office 365

Rather curiously, Office 365 has never included an out-of-the-box method to migrate a distribution list from an on-premises Exchange organization to Exchange Online. When an on-premises organization is synchronized with Exchange Online in a hybrid deployment, the suggested method is to remove the distribution list from on-premises and recreate it as a brand-new object in the cloud. For anything but simple lists with just a few members, this is a tiresome process, but it reflects the fact that transferring a distribution list to the cloud can be quite complex. Among the reasons why this is so include:

• The owner(s) of the distribution list might not have their account(s) in the cloud. An on-premises user cannot manage a cloud-based distribution list.
• Objects for mail-enabled members of the distribution list might not exist in the cloud. For example, a mail contact in the on-premises environment might not be synchronized to the cloud.
• The distribution list might hold other distribution lists.
• The proxy addresses for the on-premises distribution list must be transferred to the new list.
• Some properties of distribution lists refer to other directory objects that must exist in the target environment before they can be used. For example, the property controlling the ability of users to send email on behalf of the list.

Scripting a Solution

It is possible to write a PowerShell script to concurrently connect to Exchange on-premises and Exchange Online and perform the processing to transfer a distribution list. The script must:

• Check that all the prerequisites are satisfied for the transfer to go ahead. For example, are all the members of the list known in the cloud.
• Create the target distribution list in Exchange Online.
• Read information about the source distribution list from Exchange on-premises and update the properties of the target distribution list.
• Assign a new proxy address to the source distribution list and transfer it to the target distribution list.
• Update the membership of the target distribution list with the membership of the source list.
• Hide the source distribution list from address lists so that the only list that is visible to users is the target. Eventually, if the transfer worked and no problems are found, the old list is removed.

Tim McMichael of Microsoft has shared an example of a migration script for distribution lists in GitHub (the documentation is here). Even though Tim’s a very nice guy and ultra-competent, as with any script, you should test it carefully and adapt where necessary to meet the needs of your deployment.

Migrating Dynamic Distribution Lists

Things aren’t quite so straightforward for dynamic distribution lists. These objects are supported by both Exchange Server and Exchange Online and both work by querying a directory to find recipients for a message. The big difference is the directory used. Exchange Server uses Active Directory while Exchange Online uses Azure Active Directory. In light of this fact, the easiest option is not to synchronize on-premises dynamic distribution lists to Azure AD and recreate new equivalent dynamic distribution lists in Exchange Online.

We cover distribution lists and how to manage these workhorses of Exchange in Chapter 7 of the Office 365 for IT Pros eBook.

Suppressing Password Spray Attacks

Updated: 1 October 2022

Microsoft’s October 17, 2018 announcement of a new method to disable basic authentication for connections to Exchange Online is very welcome. Why? Basic authentication means what it says – a basic mechanism to authenticate a connection to a service. Basic authentication is simple to use and simple to abuse, which is why attackers try to exploit its simplicity in exploits like password spraying attacks and business email compromise. An Exchange authentication policy is a simple and effective way to stop attackers because it blocks attempts to connect to Azure AD accounts before authentication occurs.

Exchange Online supports many different connection protocols from Exchange ActiveSync to POP3 to IMAP4 to MAPI. This is a good thing because it allows people to use their client of choice to connect to their mailbox. Unfortunately, the profusion of connection protocols creates a difficulty too because each must be secured to stop penetration by attackers.

Update: On October 1, 2022, Microsoft entered the final phase of its project to remove basic authentication connectivity for seven email protocols. Organizations that want to protect themselves from drive-by password spray attacks before Microsoft disables basic authentication by deploying an authentication policy to block the protocols most exploited by attackers like IMAP4, POP3, and SMTP. The great advantage of an authentication policy is that it blocks a connection before it gets to Azure AD authentication. Because the policy refuses connections over blocked protocols, attackers never get to test stolen or made-up credentials against a tenant.

Creating an Exchange Authentication Policy

The method now available introduces a new cmdlet set to create and manage protocol authentication policies. Running the New-AuthenticationPolicy cmdlet creates an authentication policy that disables basic authentication for all the protocols supported by Exchange Online. For example:

New-AuthenticationPolicy -Name "No Basic Auth"

RunspaceId : fd030e40-053a-404c-90f9-3cf9f2c2dcef
AllowBasicAuthActiveSync : False
AllowBasicAuthAutodiscover : False
AllowBasicAuthImap : False
AllowBasicAuthLogExport : True
AllowBasicAuthMapi : False
AllowBasicAuthOfflineAddressBook : False
AllowBasicAuthOutlookService : False
AllowBasicAuthPop : False
AllowBasicAuthReportingWebServices : False
AllowBasicAuthRest : False
AllowBasicAuthRpc : False
AllowBasicAuthSmtp : False
AllowBasicAuthWebServices : False
AllowBasicAuthPowershell : False
AdminDisplayName :
ExchangeVersion : 0.20 (15.0.0.0)

The only protocol enabled here is Log Export, which is probably not going to be used by an attacker.

If you don’t want to use PowerShell, you can also manage the default authentication policy through the Microsoft 365 admin center.

Modern Authentication Needed

Before you block basic authentication, you must enable modern authentication for your tenant and be sure that users have clients that support modern authentication, like Outlook 2016. Enabling a block on basic authentication will have an immediate effect on older clients if you’re not careful. See this support article for more details.

Changing Protocol Authentication Settings

If you want to change a setting to allow basic authentication for a protocol, run the Set-AuthenticationPolicy cmdlet. For example:

Set-AuthenticationPolicy -Identity "No Basic Auth" -AllowBasicAuthPop:$True

You can have multiple authentication policies in a tenant, each of which allows basic authentication for different protocols.

Assigning Policies to Users

After you’ve created the authentication policies you need, you assign them to user accounts to tell Exchange Online whether users can connect using basic authentication.

In my tenant, I decided to have a single policy applied to all user accounts and implement the policy immediately, which means that you also reset the baseline for user refresh tokens. This has to be done with PowerShell, so I used a command to find all user mailboxes and use the Set-User cmdlet to assign the authentication policy and reset the refresh token for the account to the current date and time. This will force Exchange to request clients using basic authentication for connections to reauthenticate using modern authentication.

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-User -AuthenticationPolicy "No Basic Auth" -STSRefreshTokensValidFrom $([System.DateTime]::UtcNow)

Checking Policies Are Applied to Accounts

To check that policies are in place as you intend, check the accounts by running the Get-User cmdlet. As shown below, you should see that each account is assigned the desired authentication policy and the refresh token is reset to the time when the Set-User cmdlet executed.

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Get-User | Format-Table
DisplayName, AuthenticationPolicy, Sts*

DisplayName   AuthenticationPolicy StsRefreshTokensValidFrom
-----------   -------------------- -------------------------
Deirdre Smith No Basic Auth        18 Oct 2018 14:30:42
Tony Redmond  No Basic Auth        18 Oct 2018 14:31:06
TempAdminAC   No Basic Auth        18 Oct 2018 14:31:11

Defining a Default Protocol Authentication Policy

New user accounts are assigned the default protocol authentication policy for the tenant. Unless you define a default protocol authentication policy in the organization configuration, the value assigned to new accounts is $Null, meaning that no policy is assigned. To change this, run the Set-OrganizationConfig cmdlet and define a new default:

Set-OrganizationConfig -DefaultAuthenticationPolicy "No Basic Auth"

You can check the value with the Get-OrganizationConfig cmdlet:

Get-OrganizationConfig | fl DefaultAuthenticationPolicy

DefaultAuthenticationPolicy : No Basic Auth

All Good So Far

The block on basic authentication has been in place in my tenant for a few days now and no problems have been seen so far. Apart from finding out whether people use obsolete clients to connect to mailboxes, the biggest issue you might face is that disabling basic authentication for PowerShell forces accounts to use multi-factor authentication when they connect to Exchange Online.

If a problem was encountered, it’s easily fixed by reversing course and either removing the authentication policy from the affected user accounts or allowing basic authentication for a specific protocol. To remove a policy, run Set-User again:

Set-User -Identity "John Smith" -AuthenticationPolicy $Null

No events are recorded in the Office 365 Audit Log to show that someone’s account was blocked for basic authentication. But this is a preview that’s designed to show customers what’s coming down the tracks and it’s likely that Microsoft will improve this aspect of the implementation when protocol authentication policies are generally available.

Limiting basic authentication for connections using a protocol policy only affects Exchange Online and has no influence over any other Office 365 workload.

Exchange Online is covered in Chapter 5 of the Office 365 for IT Pros eBook. Then again, Exchange is used by many Office 365 applications, so it turns up throughout the book.

A New Default for Room Mailbox Automatic Processing

Today, Microsoft published Office 365 Message Center update MC151582 to tell tenants that from November 15, 2018, new room mailboxes will be created with their AutoProcessing property set to AutoAccept. Previously, the default value for the property was AutoUpdate.

The documentation for the Set-CalendarProcessing cmdlet explains the values as:

• AutoUpdate: Only the Calendar Attendant processes meeting requests and responses. Meeting requests are tentative in the calendar until they’re approved by a delegate. Meeting organizers receive only decisions from delegates.
• AutoAccept: Both the Calendar Attendant and resource booking attendant are enabled on the mailbox. This means that the Calendar Attendant updates the calendar, and then the resource booking assistant accepts the meeting based upon the policies. Eligible meeting organizers receive the decision directly without human intervention (free = accept; busy = decline). [New Default]

A Little PowerShell Error

The Message Center update includes some PowerShell to help tenant administrators check the value assigned to existing room mailboxes. Unfortunately, there’s an error in the code as it omits a call to the Get-CalendarProcessing cmdlet. To see the values, you need to run this PowerShell code:

Get-Mailbox -RecipientTypeDetails @("Equipment","RoomMailbox") -ResultSize unlimited | Get-CalendarProcessing

Identity                  AutomateProcessing
--------                  ------------------
Room 104                  AutoUpdate
Room 101                  AutoAccept
Room 102                  AutoAccept
Room 103                  AutoAccept
Las Vegas Conference Room AutoAccept
San Francisco Room        AutoAccept
Nikon Room                AutoAccept
VCR Recorder              AutoUpdate

Updating Existing Room Mailboxes

If you want to update existing rooms to the new default, run this PowerShell code:

Get-Mailbox -RecipientTypeDetails @("Equipment","RoomMailbox") -ResultSize unlimited | Get-CalendarProcessing | Where-Object {$_.AutomateProcessing -eq "AutoUpdate"} | Set-CalendarProcessing -AutomateProcessing AutoAccept

And as the update says, make sure that any scripts you use to create new room mailboxes specify whatever value you want for this property. Room mailboxes created from the Microsoft 365 admin center have AutomateProcessing set to AutoUpdate.

The Office 365 for IT Pros eBook covers this kind of information in Chapter 5, which is where we get to grips with Exchange Online mailboxes.

Questions, Questions, Questions

Following the announcements about Exchange 2019 at Ignite, people are processing what they heard and seeking clarifications about some details. One of those questions is whether a free hybrid license will be available for Exchange 2019. The answer is no. You can certainly assign a license to an Exchange 2019 server and have it host the hybrid configuration wizard, but the free license is only available for earlier versions.

Volume Licensing for Exchange 2019

Microsoft made recent changes to the licensing of hybrid servers, but the hybrid license for Exchange 2019 is linked to the decision to only license Exchange 2019 through volume licensing. In other words, the only place you’ll be able to download Exchange 2019 software is from Microsoft’s volume licensing site. This includes future cumulative updates for Exchange 2019.

This change in direction is linked to Microsoft’s focus on Exchange 2019 as the mail server for large enterprises who don’t want to move to the cloud. Concentrating on volume licensing is certainly a way to serve large enterprises, but it might be less convenient for smaller organizations. Microsoft has been made aware of this concern and is considering how best to resolve the issue.

For more information about hybrid connectivity, read the Companion Volume for the Office 365 for IT Pros eBook. We bundle the Companion Volume with the main book if you buy the PDF/EPUB version, and it’s available separately for Kindle.

Brightening Label Names

Retention labels are a security and compliance feature. And like most things associated with security and compliance, the names given to labels are usually pretty boring. Names like Keep for Audit or Confidential or even Top Secret hardly stir the blood. The same is true for sensitivity labels, used to assign permissions to files and messages and to protect their content with encryption. For the remainder of this article, I’ll use label to refer to both retention and sensitivity labels.

To be fair, those charged with managing compliance for an Office 365 tenant might not want to excite users. But then again, they might want to add a touch of emphasis to a label, and you can do that with some special characters.

Getting Graphic

All characters you see have a code that tells the computer what to display on screen. Pressing keyboard keys inserts the codes for the most common characters into documents, programs, or anything else you might want to input into on a computer. But beyond the range of “normal” characters, we find special characters. To make the special characters appear on-screen, you must enter key combinations such as pressing the ALT key and then 26 on a numeric keypad to generate the right-arrow character → or ALT and 9781 to generate a snowman character  (here’s a good article to read on the topic).

Apart from the special characters, there’s the code to generate Unicode symbols, such as ALT+128274 needed for a lock  as well as a set of emojis (not that I ever recommend the use of an emoji in an Office 365 label).

Adding a Graphic to a Label Name

To add a special character to an Office 365 label, first create it in a Word document by inputting the necessary key combination. Then go to the Office 365 Security and Compliance Center and create a new label. Input the text part of the name and then cut and paste the symbol from the Word document to end up with something like Figure 1.

Complete the rest of the settings for the new label and save the label. Finally, add the label to a label policy and publish it to the Office 365 workloads.

Using the Graphic Label

After a short period, the label is available to SharePoint Online and OneDrive for Business (it takes longer to publish to Exchange because the Managed Folder Assistant must process mailboxes to make new labels available). As you can see in Figure 2, the label appears along with all the other published labels and can be applied to a document in the same way as any other label.

Exchange Retention Tags

Graphic symbols also work in Exchange retention tags. In Figure 3, we see two labels with graphics appear in OWA. The first (Locked Down) is created as an Office 365 label and published to Exchange, where it shows up as a personal tag. The second (Keep 10,000 days) is an Exchange personal retention tag.

PowerShell

The same technique works with other types of labels such as Azure Information Protection labels. As it should. The only issue I have run into is that the PowerShell console doesn’t like graphic symbols and treats them as non-printing characters. But you can cut and paste values containing graphic characters and use them with PowerShell. For example, to get details of the retention tag shown in Figure 3:

Get-RetentionPolicyTag -Identity "Keep 10,000 days "

Name Type Description
---- ---- -----------
Keep 10,000 days  Personal Managed Content Settings

What Will Microsoft Support Do?

I can’t see that any great harm is caused by using graphic symbols in labels. After all, the symbols are just character codes that computers can process and Office 365 is designed to be multilingual and cope with different character sets (like the way Teams deals with Hebrew and Arabic).

I haven’t tested the willingness of Microsoft Support to accept that symbols can be valid components of label names. It’s possible that some deep and dark flaw is lurking out there. And remember, once you give a name to an Office 365 label, you can’t change it because the label might have been applied to content. That small but very important point is likely the one that will stop people being more colorful with their labels.

To learn more about Office 365 labels, read Chapter 19 of the Office 365 for IT Pros eBook. Chapter 19 also explains how the Exchange Online Managed Folder Assistant works.

Updated 15 September 2021

Note: Formal support from Microsoft for the Search-Mailbox cmdlet ceased on July 1, 2020. See this post for more information. As of September 15, 2021, the cmdlet is still available.

In a previous post about the Search-Mailbox cmdlet, I discussed how the cmdlet is restricted to only processing Exchange user and shared mailboxes. Some questions came in about how easy is it to delete items from mailboxes with Search-Mailbox. The answer is that it’s terrifically easy.

Blowing Messages Away

For example, this command searches all user mailboxes to find messages with “Spam Email” in the message subject and deletes any matching items. The deleted items are irrecoverable.

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Search-Mailbox -SearchQuery {Subject: "Spam Email" Received:1-Apr-2018..1-Jul-2024} -DeleteContent

A much more comprehensive parameter-driven example is described in this article. The script used in the article can search based on message subject, body text, author, and date range, which is a more realistic example of the kind of thing that administrators need to do.

It’s easy to see how mistakes could be made and many items removed from user mailboxes in the twink of an eye. Well, Search-Mailbox doesn’t run so quickly, so maybe several twinks of the eye.

The Same Problem a Long Time Ago

Having a function that can wreak havoc on mailbox contents is not unique to Exchange. In the past, when I worked on Digital Equipment Corporation’s ALL-IN-1 Office system in the early 1990s, we had a problem with an internal system in Turin, Italy, when the administrator ran a script to do mailbox maintenance. He thought that any mail older than a year would be removed, but a mistake in syntax meant that every single message in every single mailbox was removed. No one realized until Monday morning when howls of pain erupted after people discovered what had happened to their mailboxes.

In those days, we could restore mailboxes (and the databases used to connect messages together) from large 1600 bpi magnetic tapes like those shown above. Today, if you run Search-Mailbox and use the DeleteContent switch to remove items from Exchange Online, you won’t have any type of backup to fall back on – unless you buy a third-party cloud backup service.

Be careful!

Read more about Search-Mailbox in Chapter 6 of Office 365 for IT Pros.

Encrypt Only

In March 2018, Microsoft introduced the ability for Office 365 users to use the Encrypt Only feature to encrypt email sent from Outlook 2016 and OWA. Part of Office 365 Message Encryption and included in the Office 365 E3 and E5 plans (also available as an add-on), the idea behind the Encrypt Only feature is to avoid the need for people to use S/MIME to protect their outbound email. Messages encrypted by Office 365 can be read by recipients in any email service.

Introducing DecryptAttachmentForEncryptOnly

On August 23, Microsoft updated the Information Rights Management (IRM) configuration for tenants with a new setting called DecryptAttachmentForEncryptOnly. The new setting controls if Exchange Online decrypts attachments of messages protected with Encrypt Only when opened by authenticated users.

The default is False, meaning that attachments remain protected when downloaded (Figure 1). In other words, the sender exerts control over the file.

Change the setting to True if you want recipients to be able to do whatever they want after they download attachments. To update, connect to Exchange Online with PowerShell and run the command:

Set-IRMConfiguration -DecryptAttachmentForEncryptOnly $True

Changes made to the IRM configuration are effective tenant-wide immediately.

No Online Edits for OWA

If you opt for unrestricted access, be aware that users cannot perform an online edit of an Office attachment protected by Encrypt Only with OWA. You’d expect that this would be the case, but OWA preserves encryption unless an attachment is downloaded. So if you click Preview for an Office attachment and then click Edit and reply, you’ll see:

The workaround is to download any attachment you want to edit as this forces Exchange Online to decrypt the file.

The DecryptAttachmentFromPortal Setting

The DecryptAttachmentFromPortal setting was introduced some time ago to allow recipients who don’t have an Azure Active Directory account (services such as Gmail, Yahoo!, and Yandex) to access encrypted message attachments. This setting is now deprecated in favor of DecryptAttachmentForEncryptOnly.

No Other IRM Templates Affected

The DecryptAttachmentForEncryptOnly setting only applies to attachments for messages sent using the Encrypt Only feature. They don’t apply to attachments protected with any other rights management template.

One Configuration

The new setting allows tenants to control how recipients interact with attachments protected by the Encrypt Only feature. It’s worth emphasizing that the IRM configuration applies tenant-wide and you cannot change a setting for one message, one sender, or a recipient. Once you change a setting, it applies for all messages.

For more information about protecting email and documents, see Chapter 24 of Office 365 for IT Pros.

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.