Solves the Problem of Migrating Data Protected by Sensitivity Labels

I’ve worked as an advisor with Quest for several years, but I had no indication that they would launch a product to migrate content protected by sensitivity labels from one Microsoft 365 tenant to another. That capability is now available in Quest On Demand Migration.

The tenant migration issue has existed since Microsoft introduced Azure Information Protection labels (now sensitivity labels) in 2016. The problem doesn’t arise with labels that simply mark content as being of a certain nature. It comes into play when sensitivity labels apply rights-management based encryption where usage rights define the level of access granted to individual users for protected files or messages.

The popularity of sensitivity labels has increased over time as more tenants come to understand the value of protecting their most sensitive content using the labeling features built into the Office apps. It’s true that labeling only extends to Office documents and PDFs, but that set covers most files created within Microsoft 365 tenants.

The advent of Microsoft 365 Copilot and its ability to find and use files stored in SharePoint Online and OneDrive for Business means that sensitivity labels are even more important. By themselves, sensitivity labels won’t stop apps like BizChat finding sensitive documents, but they can stop Copilot reusing content from those documents in its responses. The DLP policy for Microsoft 365 Copilot imposes a better block by stopping Copilot finding documents assigned specific sensitivity labels.

The growth in protected content creates a problem for tenant-to-tenant migration projects. Many products are available to move Exchange mailboxes and SharePoint files between tenants. However, migration products usually assume that the data they move is unprotected and that users will be able to access the content once it reaches the target tenant. That assumption doesn’t hold true when sensitivity labels protect email and files. The challenge is to move protected items from the source tenant in such a way that protection is maintained and respected by the target tenant.

Methods to Remove Sensitivity Labels from Files

Until now, the guidance for source tenants is to remove protection from content before migration to the target tenant. There are a couple of ways of doing this, starting off by assigning an account super-user privilege to allow them to remove sensitivity labels from files. Finding and processing protected files is an intensely manual process that’s prone to error. It will take a long time to prepare, move, and check any reasonable collection of labelled files, like the 5,188 items with the Public label as reported by the Purview Data Explorer (Figure 1).

The SharePoint Online PowerShell module includes the Unlock-SPOSensitivityLabelEncryptedFile cmdlet. Administrators can use the cmdlet to remove protection from files in SharePoint sites and OneDrive for Business accounts. It is possible to script the removal of labels from files, but the automation journey breaks down when the files reach the target tenant and need to be relabeled.

SharePoint also supports the assignSensitivityLabel Graph API, which can remove or assign labels to files. However, assignSensitivityLabel is a metered API, meaning that each time the API is run, Microsoft charges $0.00185 (USD) paid for through an Azure subscription. That doesn’t seem like a big fee until the need exists to process tens of thousands of documents to remove labels in the source tenant and reapply labels in the target tenant.

No Solution for Protected Exchange Messages

Note that Exchange Online is missing from the discussion. That’s because all the methods described so far don’t handle email. I don’t know how clients like Outlook and OWA apply sensitivity labels to messages (it’s likely done using APIs from the Microsoft Information Protection SDK), but no cmdlets or Graph APIs are available to remove labels from messages or apply sensitivity labels in bulk to a set of messages migrated in mailboxes moved from one tenant to another.

Migrating Protected Content Between Tenants

All of which means that Quest’s claim to migrate protected content from Exchange Online, SharePoint Online, and OneDrive for Business is very interesting. It’s the first ISV migration offering that I know of which offers such a capability.

Reading the announcement and the accompanying Quest Knowledge Base article gives some insight into how the On Demand product handles protected items. A discovery process (like running the Get-Label cmdlet) finds the set of sensitivity labels in the source tenant. The labels from the source tenant are mapped to labels in the target in some form of table. Normal migration processing moves the data, and some form of post-migration task then updates the labels from the source tenant to matching labels for the target. Quest doesn’t describe what magic is used to make sure that protected content works when it reaches the target tenant, but the knowledge base article mentions the Microsoft Information Protection SDK, so it’s likely that On Demand uses MIP SDK API calls to read and update sensitivity labels for the migrated items.

User-Defined Permissions and Keys

Although creating the capability to move protected content between tenants is a great step forward for migration projects, there are always edge cases to consider. Sensitivity labels with user-defined permissions are an example. These labels are challenging because the permissions vary from item to item. SharePoint Online only recently gained support for sensitivity labels with user-defined permissions, and it’s interesting that Quest claim support for user-defined permissions out of the box.

Quest doesn’t mention sensitivity labels with double-key encryption (DKE), nor do they explain if On Demand supports migration of sensitivity labels with encryption based on customer keys rather than Microsoft-managed keys (sometimes called bring-your-own-key or BYOK). There’s a bunch of complexity involved in moving key management between tenants and it would be surprising if Quest supported BYOK. Thankfully, most customers use Microsoft-managed keys with sensitivity labels because it simplifies operations.

Let the Competition Begin

Overall, it’s great that an ISV has taken on and solved the challenge of moving protected content between tenants. The nature of competition is that once a migration vendor introduces a new capability, their competitors respond. We might see even more interesting developments in this space over the coming months.

Microsoft Layoffs Remind Microsoft 365 Tenants About the Need to Preserve Ex-Employee Data

This week’s news that Microsoft is trimming 3% of its global workforce brought shock to those affected by the elimination of their position. My LinkedIn feed has been flooded by updates from people who discovered that they’re in a position that they never anticipated, some of whom have been with Microsoft for many years. I’ve been involved in many downsizing actions at Digital Equipment Corporation, Compaq, and HP, and it’s never easy for managers and employees alike. I wish all those affected the best of luck in finding new positions.

The hope of Microsoft management is probably that the layoffs will result in a leaner, more agile organization, the only goodness for the Microsoft 365 community that comes from the episode is that it’s a great reminder for tenant administrators to review the process used to secure ex-employee information following a termination.

Changes in Microsoft 365 Make It More Complex to Preserve Ex-Employee Data

Ten years ago, the task was relatively simple because fewer types of information needed to be secured. Today, new applications and more integration between applications means that the task is more complex.

The basics remain:

• Terminating access to resources by revoking access tokens, disabling accounts, and changing account passwords.
• Physically securing devices (workstations and mobile devices) or remote wipes to remove corporate content.
• Preserving application information such as mailboxes and OneDrive for Business accounts.

Deleting a user account via the Microsoft 365 admin center (Figure 1) takes care of the basics. To do a more comprehensive job, it’s best to script all the steps with PowerShell.

I recommend using inactive mailboxes to retain mailbox content rather than making a regular user mailbox into a shared mailbox, but advantages exist for both approaches. Happily, not much has recently changed with mailbox retention. The situation is completely different with OneDrive for Business in terms of the app reliance on OneDrive and how Microsoft deals with unlicensed OneDrive accounts.

The Key Role Played by OneDrive for Business

OneDrive for Business has become the de facto storage destination for many Microsoft apps, storing files as diverse as Loop components, Teams meeting recordings, and whiteboards. Microsoft’s enthusiasm knows no boundaries when it comes to storing files in OneDrive for Business. Even PowerShell module installations end up in OneDrive for Business if you’re not careful.

Message center notification MC1053121 (last updated 23 April 2025) describes how users who don’t use the Known Folder Move (KFM) feature to redirect common folders like Documents from local disks to OneDrive will be more aggressively “encouraged” to back up files in OneDrive for Business. This change is rolling out to general availability and should be active worldwide by mid-June 2025. If you don’t like users seeing this kind of prompting, consider the new Restrict KFM from Office policy for the Office apps (see MC1053121 for details).

Because OneDrive for Business accounts owned by ex-employees are so important from a retention perspective, it’s important to ensure an alternative site administrator (usually the ex-employee’s manager) is assigned to these accounts so that any useful information in the account is retained. Moving shared objects like Loop components or files shared in Teams chats from the account will break sharing. Eventually, the organization can remove the OneDrive account. If the account remains online, Microsoft will archive the now-unlicensed OneDrive account. Deleting or archiving the account will also break sharing!

The challenges of dealing with OneDrive accounts owned by ex-employees is one of the reasons why it is important to coach users to store corporate information in SharePoint Online instead of keeping files in OneDrive for Business. Unfortunately, that advice is often observed more in theory than practice.

The New Challenge Posed by Flows and Agents

Power Platform flows are often tied to a user account. If the account goes away or is disabled, the flow will stop working. That shouldn’t be a problem if the process performed by the flow is personal to the now-departed employee. On the other hand, if the flow does something that others depend on, that process is now broken and needs to be fixed.

The same applies to agents. It all depends on what an agent does and who uses it. Personal agents will stop running when an account is no longer available to authenticate and that shouldn’t be a problem. But we’re at the early stages of understanding the development, deployment, and management of agents within Microsoft 365 tenants, and care must be taken to ensure that any agents created and maintained by ex-employees remain functional when needed or are disabled and removed if not. This doesn’t happen automatically when an administrator disables or deletes a user account.

Other Issues Requiring Attention

Apart from personal data, there are other issues that might need attention to preserve ex-employee data, including the ownership of:

• Microsoft 365 groups, security groups, and distribution lists.
• Loop workspaces and the associated SharePoint Embedded container.
• Entra ID apps.
• Recurring meetings.
• Phone numbers for use with the Teams Phone system.

The point is that the Microsoft 365 ecosystem continues to evolve. This means that processes and procedures used to manage access to Microsoft 365 resources must evolve in step. This week’s Microsoft layoffs are a regrettable reminder of that fact.

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.

Maybe a Microsoft 365 Retention Policy is Better than an eDiscovery Hold

Last month, I wrote about how to replace Exchange Online litigation holds, which only preserve mailbox content, with holds applied by Purview eDiscovery cases. The advantage gained by this exercise is that eDiscovery holds can also secure the OneDrive for Business accounts owned by specific users, including those who leave the company.

My idea works, but it’s unnatural. eDiscovery cases are designed to secure information required by eDiscovery investigations, not to preserve information for indeterminate periods. Retention policies are the designated Microsoft 365 mechanism to retain information. Still, I enjoyed probing how to use eDiscovery case holds, and the good news is that much of the code written to prove the principle can be repurposed for retention policies.

Using a Retention Policy

A Microsoft 365 retention policy can cover many different types of data. In terms of mailbox data, a Microsoft 365 retention policy isn’t as granular as Exchange (“legacy”) retention tags, nor does a Microsoft 365 retention policy support the move to archive action to move items from a primary mailbox into its associated archive mailbox. For these reasons, Microsoft hasn’t deprecated Exchange retention policies and tags.

The question of granularity doesn’t arise with litigation holds because a litigation hold retains everything in the primary and archive mailbox. We can therefore replace litigation holds with a retention policy to hold everything indefinitely, and that policy will place a hold on everything in the mailboxes and OneDrive accounts that are added as locations to the policy.

Dealing with the 1,000-Location Limit

The only real limitation that exists is the maximum number of locations supported for Exchange mailboxes and OneDrive accounts. A retention policy that uses static locations can add up to 1,000 locations for each type. It’s unlikely that a tenant will have more than 1,000 mailboxes on litigation hold, but if this is the case, the choice is to either split the locations across multiple retention policies or use an adaptive scope to identify the mailboxes. A retention policy based on an adaptive scope isn’t subject to the 1,000-location limit.

The easiest way to mark mailboxes to be found by an adaptive scope is to set a value in one of the fifteen custom properties available for mailboxes. Each of the mailboxes (accounts) covered by an adaptive scope requires an Office 365 E5, Microsoft 365 E5, or Microsoft E5 Compliance license.

Creating the Retention Policy and Rule

A retention policy consists of two parts. The policy defines the set of target locations, like Exchange mailboxes, OneDrive accounts, SharePoint Online “classic” sites, and Microsoft 365 groups. Figure 1 shows the target locations for a “standard” retention policy. Specific retention policies can be created for Teams channel messages, Teams chat and Copilot interactions, and Viva Engage (Yammer) community messages.

The policy rule defines the retention settings, or what the policy does to the items found in the target locations. In this instance, the rule is very simple because the idea is to mimic what a litigation hold often does, which is to apply an unlimited hold. Litigation holds do accommodate a limited duration hold, and it would be possible to recreate this kind of hold with a retention policy, but here we’re just proving the principle, so it’s enough to show how to create the retention policy and a rule to hold continue indefinitely. Here’s the code:

Write-Host "Creating Microsoft 365 retention policy to replace litigation holds..." -ForegroundColor Yellow
$NewPolicy = New-RetentionCompliancePolicy -Name "Litigation Hold Retention Policy" -ExchangeLocation $MailboxesToHold -OneDriveLocation $OneDriveToHold  `
    	-Comment ("Retention policy to replace litigation holds created by Switch-LitigationHoldsforRetentionPolicies.PS1 script on {0}" -f (Get-Date).ToString("dd-MMM-yyyy")) `
If ($NewPolicy) {
    Write-Host ("Retention policy {0} created" -f $NewPolicy.Name) -ForegroundColor Green
    $NewPolicyRule = New-RetentionComplianceRule -Name LitigationHoldRule -Policy "Litigation Hold Retention Policy" -RetentionDuration unlimited `
        -Comment "Created by Switch-LitigationHoldsforRetentionPolicies.PS1 script" 
    If ($NewPolicyRule) {
        Write-Host ("Retention rule {0} created" -f $NewPolicyRule.Name) -ForegroundColor Green
    } Else {
        Write-Host "Failed to create retention rule" -ForegroundColor Red
        Break
    }
} Else {
    Write-Host "Failed to create retention policy" -ForegroundColor Red
    Break
}

If you want to create a more complicated retention rule, it’s probably best to do so via the Purview compliance portal GUI. You can download the script I used from GitHub.

After applying a retention policy, it can take a few days before the policy becomes fully effective. I’d wait a week and then remove the litigation holds from the mailboxes.

Dump Litigation Holds Now

I don’t hesitate to recommend phasing litigation holds out in favor of retention policies. At this point, litigation holds are a dead-end street that Microsoft is putting little or no effort into. By comparison, Microsoft 365 retention policies are more functional and under active development, which makes them a better long-term bet for meeting the retention needs of Microsoft 365 tenants.

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.

Can Attackers Use Copilot for Microsoft 365 to Help Find Information?

An article by a UK-based security penetration test company titled “Exploiting Copilot AI for SharePoint” drew my attention to see what weaknesses testing had found. I was disappointed. Although the article makes some good points, it doesn’t tell reveal anything new about the potential issues that can arise due to poor protection of information stored in SharePoint Online sites. Let’s discuss the points raised in the article.

A Compromised Account

Copilot for Microsoft 365 always works as a signed in user. Before an attacker can use Copilot for Microsoft 365, they must be able to sign into a licensed user’s account. In other words, that account is compromised. That’s bad for a tenant because any compromise can lead to data loss or other damage, and it’s probably indicative of other problems that attackers can exploit without going near Copilot.

Organizations should protect themselves with strong multifactor authentication (MFA). That message seems to be slowly getting through, and you’d imagine that any tenant willing to invest in Copilot is also willing to protect themselves by insisting that all accounts are protected by MFA.

Seeking Sensitive Information

The authors make a good point that people often store sensitive information in SharePoint Online. Attackers like to search for information about passwords, private keys, and sensitive documents. Copilot undoubtedly makes it much easier for attackers to search, but I don’t think that the default site agents create any vulnerability because these agents are constrained to searching within the sites they belong to.

Custom agents might be more problematic, but that depends on the information accessed by the agents. It also depends on the penetrated user being able to run the custom agents. The big thing to remember here is that Copilot can only access data available to the account being used. Custom agents in the hands of an attacker can’t automagically get to some hidden data. Anyway, organizations should monitor the creation of agents and have some method to approve the use of those agents.

Accessing Password Data

The penetration team reported that they had found an interesting file (an encrypted spreadsheet) that appeared to contain passwords that SharePoint blocked access to because “all methods of opening the file in the browser had been restricted.” This sounds like SharePoint’s block download policy was in operation for the site. However, Copilot was able to fetch and display the passwords stored in the file.

It’s likely that the spreadsheet was “encrypted” using the default Excel protection applied when a user adds a password to a spreadsheet. However, the encryption is no match for Microsoft Search, which can index the information in the file, and that’s what Copilot for Microsoft 365 Chat was able to display (Figure 1).

Excel’s encryption is very poor protection in the era of AI. Sensitivity labels should be used to secure access to sensitive information, specifically labels that do not allow Copilot to extract and display information from files found by searching against Microsoft Search. Even better, use the DLP policy for Microsoft 365 Copilot to completely hide sensitive files against Copilot so that not even the file metadata is indexed.

Alternatively, use Restricted Content Discovery (RCD) to hide complete sites so that casual browsing by attackers (or anyone else looking for “interesting” information). Apart from RCD, Microsoft makes other SharePoint Advanced Management (SAM) features available to Microsoft 365 Copilot tenants. There’s no excuse for failing to use the access control and reporting features to secure sensitive sites.

Copilot for Microsoft 365 is a Superb Seeker

Copilot for Microsoft 365 is superb at finding information stored in SharePoint Online and OneDrive for Business. With good prompting, an attacker with access to a compromised account can retrieve data faster than ever before, and unlike previous methods of trawling through SharePoint files, Copilot access doesn’t leave breadcrumbs like entries in the last files accessed list.

Copilot access can be constrained by making sure that suitable permissions are in place for documents, deploying the DLP policy for Microsoft 365 Copilot, and limiting access to confidential sites through Restricted Content Discovery. The DLP policy and RCD are recent Copilot control mechanisms that I don’t think the authors of the penetration test report considered (even though they refer to blocking agents with RCD). But available mechanisms are worthless unless implemented, and the real value of reports like this is to prompt administrators to use available tools, including MFA to reduce the likelihood of a compromised account.

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.

Finding Exchange Mailbox Audit Data Isn’t So Easy Anymore

From an engineering perspective, Microsoft’s decision to decommission the Search-MailboxAuditLog and New-MailboxAuditLogSearch cmdlets makes a ton of sense. Microsoft 365 apps consume shared services, and the unified audit service ingests the data used by these Exchange Online cmdlets. Why incur the engineering and support expense to keep the old on-premises cmdlets going?

Microsoft posted the news on January 14, 2025, and stopped writing audit log data to mailboxes on March 1, 2025. The cmdlets will disappear at the end of 2025. You might have missed this information because Microsoft posted to the security blog instead of the Exchange EHLO blog, where all the other Exchange-related news appears. Perhaps this is because audit data is related to Microsoft Purview and the topic therefore is in the security space. However, losing cmdlets that might be used in Exchange-related administrative processes is a big deal deserving better awareness.

In 2016, Exchange mailbox audit data was one of the first sources of audit events for the unified audit log. Ever since, mailbox audit data has flowed into the unified audit log and can be found by audit log searches, so what’s the problem?

Searching the Unified Audit Log for Exchange Mailbox Audit Data

Searches of the unified audit log can be performed synchronously using the Search-UnifiedAuditLog cmdlet or asynchronously through the Audit section of the Purview compliance portal or by submitting a job through the Graph AuditLogQuery API. Audit log searches can find mailbox data among the many other forms of workload data ingested on an ongoing basis, and searches can go back 180 days (audit standard) or 365 days (audit premium). It all sounds good.

But people build processes around PowerShell cmdlets, and when a cmdlet disappears, those processes must be redeveloped. In this instance, any script that uses the deprecated cmdlets must be altered, probably to use the Search-UnifiedAuditLog cmdlet. And let’s face it, even its biggest fans (and I’m probably in that category) wouldn’t consider Search-UnifiedAuditLog to be an easy cmdlet to use, and Microsoft has tinkered with the way the cmdlet functions over the years. Thankfully, they’ve retreated from the idea of making high completeness (very slow) searches the norm.

The parameters for audit log searches can be complex to construct, duplicate audit records can be retrieved, and there’s always the need to unpack the JSON structure contained in the AuditData property to find out what actually happened for the auditable event.

Those accustomed to interacting with the AuditData property know that every workload decides what information to include in audit events and how that data is formatted. Extracting properties from AuditData usually isn’t hard, but it’s tiresome to see how many variations Microsoft engineers can come up with when inserting data into audit events.

Apart from the issue of interpreting audit events, there’s also the simple fact that it’s easier to extract audit data for the actions of a single user from their mailbox. Finding the relevant information about mailbox events from the unified audit log is more complicated.

Find Exchange Mailbox Audit Data for a Single Mailbox

The easiest way to find audit records for a specific mailbox with the Search-UnifiedAuditLog cmdlet is to pass the user principal name for the mailbox owner (or, to search multiple mailboxes, a set of user principal names) in the UserIds parameter. Here’s an example that finds the audit records for a mailbox and reduces the set to those belonging to Exchange actions:

$RecordType = "ExchangeAdmin","ExchangeItem","ExchangeItemAggregated","ExchangeItemGroup","ExchangeSearch"
[array]$Records = Search-UnifiedAuditLog -Userids ‘kim.akers@office365itpros.com' -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

Searching based on user principal names finds audit records for actions performed by that user. If you want to find audit records for actions performed by a mailbox delegate, use a free text search for the object identifier of the mailbox owner’s account. The free text search finds references to the mailbox owner in the AuditData property and includes those records in the set returned. Here’s an example of using an account identifier in a free text search. It’s important that the identifier is cast as a string as otherwise the search will fail because it will attempt to use a GUID where the cmdlet expects a string:

[array]$Records = Search-UnifiedAuditLog -Freetext ((Get-ExoMailbox -Identity Tony.Redmond).ExternalDirectoryObjectId -as [string]) -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

The Bottom Line

You might not have been aware of the change to the old cmdlets. They still work (for now), but mailbox audit data generated since March 1, 2025, cannot be retrieved using the cmdlets. In any case, it’s a good idea to check scripts to find any instances where the old cmdlets are used. The bad news is that those scripts must be redeveloped. Good luck!

Ignite Announcement About SAM for Copilot Customers Misinterpreted by Many

At the Ignite 2024 conference, Microsoft announced that “Microsoft 365 Copilot will now include built-in content governance controls and insights provided by SharePoint Advanced Management.” At the time, and still broadly believed, the assumption was that Microsoft would provide customers with Microsoft 365 Copilot licenses with SharePoint Advanced Management (SAM) licenses. Maybe even a single SAM license would be sufficient to license SAM technology alongside Copilot. That’s not the case.

If you’ve been waiting for a SAM license to appear in your tenant, you’ll be disappointed and won’t see SAM listed in the set of tenant subscriptions. Don’t be swayed by the banner in the SharePoint Online admin center to announce that your SharePoint Advanced Management subscription is enabled (Figure 1). It’s not. Access to SAM features is granted through a check enabled in code for the presence of Copilot. The necessary update is now broadly available to customers.

SAM Features for Microsoft 365 Copilot Customers

The facts are laid out in the SAM documentation. Customers with eligible Copilot licenses can use some, but not all, SAM functionality without a SAM license. Here’s the list:

• Site Lifecycle Policy
  • Inactive SharePoint sites policy
  • Site Ownership Policy
• Data Access Governance (DAG) Insights
  • “Everyone Except External Users” (EEEU) insights
  • Sharing Links and Sensitivity Labels
  • PowerShell: Permission state report for SharePoint and OneDrive Sites, and Files
  • Sharing links report
• Site Access Review
• Restricted Content Discovery (RCD – enabled via PowerShell)
• Restricted Access Control (RAC) for SharePoint and OneDrive for Business.
• Recent Admin Actions and Change History
• Block Download Policy
  • SharePoint and OneDrive sites
  • Teams recordings

There’s some good stuff here, particularly Restricted Content Discovery (RCD), the Site Lifecycle Policy to manage inactive sites, and the Block download policy. Every tenant with Microsoft 365 Copilot should consider enabling RCD to block Copilot access to sites containing sensitive Office and PDF files and sites containing old and obsolete material (the digital rot or debris that clutters up so many tenants).

The problem with Copilot reusing sensitive material in its responses is obvious. The issue with Copilot reusing old, obsolete, and potentially misleading content in its responses is equally problematic, especially if human checks don’t catch errors in responses. Copilot doesn’t know when a Word document written ten years ago is outdated and inaccurate. All Copilot sees is words that can be processed and reused.

When SAM is Needed

All of which brings me to a point where a SAM license is required. In my case, I wanted to test the extend SharePoint protections with a default sensitivity label feature. The idea here is to make sure that unlabeled files receive protection when downloaded by applying a sensitivity label with equivalent rights to those enjoyed by site users. Defining a default sensitivity label for a document library already requires an Office 365 E5 license or equivalent. Why this slight extension wanders into the need to have SAM is another example of bizarre Microsoft licensing.

The documentation notes that Copilot can’t currently open files with sensitivity labels applied in this manner. This means that Copilot cannot extract the protected content to use in its responses because it doesn’t have the right to do so. However, Copilot can search the metadata of labeled files and show that metadata to those who perform searches. Restricted Content Discovery is the right way to block Copilot access to files.

Anyway, without a SAM license, I can’t test. Do I want to pay Microsoft for a license for the privilege of testing their software? I don’t think so.

Copilot in Word for iOS

In closing, I attempted to use a new feature in Word for iOS (and Android) to dictate some notes for this article for Copilot to reason over and produce a draft. The feature is covered in MC1060866 (23 April 2025) and deployment has begun, which is why I guess I could use it. The dictation part worked, even if some of my words were misunderstood (Figure 2). But any attempt to have Copilot do some magic failed utterly. I guess that AI can’t help me…

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.

Teams Can Have a General Channel Just Like Before

In July 2024, Microsoft announced that team owners would be able to rename the General channel (or local language value) of teams. The idea was that “General” is just too general in nature and that it would be better if team owners could assign a more meaningful name to the first channel created in a team. Once

Now Microsoft has reversed course a tad. Message center notification MC1048628 (updated 9 April 2025) says that team owners can choose General as the name for the first channel. The new channel creation UI even has a button to set the channel name to “General” (Figure 1). The change is already effective in targeted release tenants and will roll out worldwide in mid-May 2025.

The big thing about using General as the default channel name is that the General channel is always listed first in the channels for a team. If you use a different name for the first channel, Teams orders the channel list alphabetically. You can see the effect of renaming the General channel in Figure 2.

Channel Creation Made Easier

MC1053645 (11 April 2025, Microsoft 365 roadmap item 479744) describes another channel-related change that will roll out to targeted release tenants in early May. The option to create a new channel is now present in the New Items menu (Figure 2).

Recent conference appearances by the Teams development group have emphasized that users should create channels rather than new teams. With 1,000 channels available in a team, there’s lots of room to avoid creating new teams with the attendant overhead that comes with a team. The more teams in a tenant, the higher the likelihood for digital debris. That wasn’t such a problem years ago, but digital debris can influence the accuracy and usefulness of AI-generated content, so it’s a real issue now.

No More Code Snippets

In other Teams news related to channels, MC1055554 (15 April 2025) announces the retirement of the code snippets feature in chat and channel conversations starting May 30, 2025. Microsoft is replacing code snippets with code blocks. Type /code in the editor or click on the code block icon in the menu bar to insert a new block, and then select the type of code so that the block displays the code appropriately (Figure 4).

Microsoft believes that code blocks are faster and more efficient. Line numbers aren’t current available in code blocks but will be soon, and code blocks will also be viewable on mobile clients.

You might ask what’s driving the change. I think it’s a matter of Teams dropping an older component that doesn’t probably get much use for a shared component that’s under active development. Microsoft says that the change will allow users to “create, edit, and share code directly in the compose box without needing a title.” That’s true when someone composes a message, but if you want channel or chat members to be able to edit code in a code block, considering using the Loop paragraph component and format it as code (Figure 5).

Posting a Loop component to a channel allows team members to edit the content, so it’s possible to have real-time collaboration to discuss code issues and potential solutions. Loop components posted in this manner are stored in the channel folder in the document library of the SharePoint Online site belonging to the team.

Adieu Classic Teams

Another change that’s coming up is that the classic Teams client will be unavailable after July 1, 2025 (MC1059667, 21 April 2025). Microsoft will block attempted access to Teams with the classic client after that date. It really is time to embrace the new (well, slightly used) Teams client.

Learn about using Teams and the rest of Microsoft 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.

Moving Exchange Online Away from Unauthenticated Connections with Reject Send

If your tenant still has devices that send email to Exchange Online, you should pay attention to the April 28 announcement about more control over the Direct Send feature. This step is part of the overall campaign to improve the security of Exchange Online that’s included initiatives like removing support for Exchange Web Services (EWS) and only accepting inbound mail from supported versions of Exchange Server in hybrid configurations.

Direct Send is a method for devices or applications to unauthenticated send email to Exchange Online recipients using an external mail server using an accepted domain for a Microsoft 365 tenant. No mailbox is required, so Direct Send is a relatively painless way to set up an email connection to internal recipients (Exchange Online rejects messages sent to external recipients).

Authenticated Connections Preferred

Because authenticated connections are used, Microsoft would prefer customers to use client SMTP submission (SMTP AUTH) or SMTP relay instead of Direct Send. The announcement says that Reject Send is a new option to disable Direct Send by default. If they don’t need to use Direct Send, tenants should use Reject Send to block Direct Send because it’s a method that could be exploited by spammers.

SMTP AUTH is next on the list for upgrade as it will lose the ability to connect with Basic authentication in September 2025. Devices and apps that use basic auth today, for instance to send email using the PowerShell Send-MailMessage cmdlet, must be upgraded to use OAuth connections or they will lose the ability to send messages via Exchange Online. Authenticating SMTP connections via OAuth is not a matter of changing out cmdlets, so if a tenant hasn’t started that work to make sure that apps and devices continue working after the September deadline, they’re behind the curve and need to accelerate.

The Reject Send Feature

Direct Send email is anonymous (messages don’t come in via a connector). In the past, this didn’t matter so much because the messages came from devices or apps controlled by you and submitted using a domain owned by the organization. Reject Send works by updating the Exchange organization configuration to instruct the transport service to reject any unauthenticated messages submitted by Direct Send.

Reject Send is currently an opt-in feature, so the RejectDirectSend setting in the organization configuration is set to false. To enable Reject Send, connect to Exchange Online PowerShell as an administrator and run the Set-OrganizationConfig cmdlet:

Set-OrganizationConfig -RejectDirectSend $True

Exchange Online organizational settings need time to percolate to all the mailbox servers used by a tenant, so it could take up to 30 minutes before the update is effective across a tenant. Once the block is effective, messages submitted via Direct Send will then a 550 5.7.68 error. Of course, unless someone is checking devices for errors in mail transmission or notices that expected messages don’t arrive, those errors might remain undetected.

Microsoft says that they plan to enable Reject Send by default for new tenants. The logic here is impeccable. If you’ve never used the feature, don’t get the habit. Reject Send is a preview feature to allow customers to test. An issue with forwarding and Sender Rewriting Scheme (SRS) is documented in the announcement, and Microsoft does not provide a date for general availability.

Before Reject Send can reach general availability, Microsoft must deliver the promised “optics” (a report) to give administrators insight into the level of Direct Send traffic within a tenant. Assuming that the report turns up soon and unless big problems are uncovered during the preview, I’d expect Reject Send to be fully available by the end of 2025.

Connectors Required

It’s possible that some existing mail will be affected by enabling Reject Send. If so, that email must be authenticated by routing across a partner mail flow connector.

SMTP AUTH is the Immediate Priority

There’s not much else to say about Reject Send. If you have a test tenant that mimics the operational environment (complete with apps and devices), you should enable Reject Send and see what happens. You could do the same for the production tenant, but only when prepared to track problems with devices and apps. A better idea might be to wait for the promised report to understand the level of Direct Send traffic within the organization.

Given the looming deadline for SMTP AUTH to lose support for basic authentication, this is likely to remain the immediate priority for upgrade. September isn’t that far away, especially when the prime vacation period is in the middle.

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

Over 300 Pages of Microsoft 365 PowerShell Goodness to Read

The Office 365 for IT Pros writing team are pleased to announce the availability of update 11 for the Automating Microsoft 365 with PowerShell eBook. The eBook is part of the Office 365 for IT Pros (2025 edition) bundle and is also available separately (PDF and EPUB formats) or from Amazon in Kindle and paperback formats. The current version is dated 24 April 2025 and has the version number 11.1.

We typically release an updated version of Automating Microsoft 365 with PowerShell several days before the release of the monthly update of the Office 365 for IT Pros eBook. This approach makes it easier for us to manage the updates for the “big book.” We anticipate that monthly update #119 for Office 365 for IT Pros will be available on May 1.

Subscribers to the Office 365 for IT Pros bundle or to the Automating Microsoft 365 with PowerShell eBook can download the latest files by using the link in the receipt sent to them from Gumroad.com after their original purchase. See our FAQ for more details about how to download updated book files.

New Microsoft Graph PowerShell SDK Version

Microsoft released V2.27 of the Microsoft Graph PowerShell SDK on April 20. This is an important update because it had to address the many woes inflicted on customers with the buggy V2.26 and V2.26.1 releases. Azure Automation runbooks remain an issue (stay with V2.25 if you want to use PowerShell V7.1 or V7.2 runbooks) that will be addressed when Microsoft ships support for PowerShell V7.4 for Azure Automation on June 15, 2025. Two issues must be cleaned up: a clash between the SDK and Exchange Online PowerShell and support for .NET 8. In the interim, V2.27 runs fine with V5.1 runbooks.

License Assignment Bug

After several days of intensive work with V2.27 in interactive and app-only modes, I haven’t noticed any of the obvious flaws that affected its predecessors. Some early cmdlet oddities were cleared up by rebooting my PC. These were likely due to some lingering older components hanging on in memory. Following the reboot, all is well. Then I heard about problems with the Set-MgUserLicense cmdlet (issue #3286) where new licenses cannot be assigned to accounts. It seems like the cmdlet has problems parsing the information passed in the AddLicenses parameter. However, passing the license data in a body parameter works:

$LicenseData = @{
	addLicenses = @(	
	@{
	     disabledPlans = @()
	     skuId = "f30db892-07e9-47e9-837c-80727f46fd3d"
	 }
      )
      removeLicenses = @()
}

Set-MgUserLicense -Userid $User.id -BodyParameter $LicenseData

Speaking of bugs, if you encounter a problem with V2.27, please report details of the issue and steps to reproduce the problem via the GitHub repro for the SDK. Reporting an issue doesn’t take long and it is really helpful to have issues documented. Microsoft engineering monitors the open issues list and does their best to respond to problems that might affect many customers (like the license issue described above). If you don’t report problems, don’t complain when an SDK cmdlet doesn’t work the way you expect it to.

On to The Next Update

The Automating Microsoft 365 with PowerShell eBook is now well over 300 pages. That’s quite a change from the first version published in July 2024. There’s lots to cover in the next update, including a look at the newly-introduced Graph API usage report API. The API is still in beta and only covers certain parts of Graph usage such as Exchange Online and Teams messaging. The output lacks refinement and doesn’t throw any detailed light into how the Graph APIs are used within a Microsoft 365 tenant. Going forward, that situation is likely to change. It will be interesting to see the usage data generated by Microsoft and how that data is used.

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.