Outlook Users Never Realized the Desperate Need for Colored Folder Icons

The announcement in message center notification MC993229 (31 January, 2025), Microsoft 365 roadmap item 472921) that the new Outlook (or as it’s referred to in the announcement, “the new Microsoft Outlook for Windows desktop” and OWA are allowing users to personalize folder icon colors is in the category of “why” features. Apparently, the idea is to make it easier for people “to visually differentiate and personalize folders.” The feature is available in targeted release tenants and will be generally available worldwide during March 2025.

I don’t want to pour cold water on innovation, but the thought did go through my mind that the Outlook classic desktop client has survived and prospered since 1997 without different colored folder icons. The same is true for OWA, introduced around the same time, and seemingly unaffected by monocolor folder icons.

Using Outlook Colored Folder Icons

But now we have colored folder icons and the world is a better place. At least, it might be if you’re not color blind (like me) and have difficulties differentiating between nuanced shades. In the spirit of adventure, I resolved to bring a dash of color into my email life and set out to update some folders.

The first thing to note is that you can leave Outlook alone and it will use automatic colors. In other words, Outlook chooses how to present the folder icon. I’m not quite sure what color is used, but it’s functional and never caused me a moment’s worry until now, mostly because I never thought about choosing a new color for folder icons.

In Figure 1, the Archive folder is selected, and its folder icon is colored silver, one of the options in the folder icon palette. Some of the other folders have new colors too. Whether this makes those folders more recognizable or visually differentiated is in the eyes of the beholder.

To reveal the option to choose a new color for a folder icon, click the […] folder menu alongside its name. To produce the screen shot shown in Figure 1, I selected the folder menu for the Sent Items folder. As you can see, Sent Items still uses the automatic default chosen by Outlook. To update the folder icon color, choose one of the available selection like cranberry, light teal, or lime (note to self, who would have thought that I would ever write about applying lime as a color to any Outlook component?).

In any case, it all works, and you can spend a few minutes colorizing your folder icons.

Filers versus Pilers

I don’t know what impetus pushed the Outlook team to introduce colored folder icons at this point in the product’s development. It seems like many users eschew the use of folders apart from the default set because they depend on search to find items of interest when necessary. Piling items into a small set of folders is a habit encouraged by reliable search, something that took Outlook a long time to acquire.

I’m a filer in that I use folders to organize information. I’m not as diligent about filing as I once was in the days when search worked intermittently. Smaller mailbox quotas meant that it was sometimes necessary to clear out lots of items to make space for new email. Large mailbox quotas and retention processing have largely taken care of the need to delete items from mailboxes manually. I guess we need to fill the time once spent removing unwanted debris from mailboxes with other activities, like choosing colors for folder icons.

But Seriously

Some will criticize the Outlook developers for spending valuable engineering time implementing features like folder icon colors. If Microsoft is really serious about convincing the curmudgeons who use Outlook classic to move to the new client before support ceases for Outlook classic in 2029, shouldn’t they be solving the major pain points that stop people switching? Of course, Microsoft should deliver solutions like solid PST support (due imminently according to MC966639), but assigning a bunch of extra engineers to work on the pain points might not create solutions any faster. Which is why the engineers need to be kept occupied by pushing forward the frontiers of information technology with colored folder icons.

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.

Outlook Newsletters App for Outlook and OWA

Message center notifications MC1009916 (19 February 2025, Microsoft 365 roadmap item 328282) describes the new Outlook Newsletters solution, designed to create and send high-quality internal newsletters. The app is rolling out now in preview to targeted tenants. Standard tenants are likely to see Outlook Newsletters before the end of March 2025. General availability is scheduled for August 2025.

Outlook Newsletters is an app constructed from components drawn from the Microsoft 365 software toolbox like SharePoint Embedded, Microsoft Designer, Outlook reactions, comments, and so on. It’s a good example of how to combine available components with new code to create new apps.

Enabling Outlook Newsletters

Outlook Newsletters is an opt-in solution, meaning that it must be enabled before it appears in the menu bar for the new Outlook for Windows or OWA. Enablement is through settings in the OWA mailbox policies applied to mailboxes. Three policy settings are available (the administrator documentation is sparse and likely to be overhauled before general release):

• OutlookNewslettersAccessLevel: defines the access level a mailbox has to Outlook Newsletters. To create and send newsletters, this setting must be ReadWrite. Users with ReadOnly access can open the Newsletters app but can’t create or send newsletters. The default is no value, which equates to NoAccess.
• OutlookNewslettersReactions: Set to DefaultOn to make it the default that newsletters allow recipients to react in the same way as they react to normal Outlook email. Reactions can only be posted by internal recipients.
• OutlookNewslettersShowMore: Set to DefaultOn to make it the default for newsletters to display other newsletters at the bottom of a message. The idea is that recipients might find newsletters to subscribe to.

For example, this command allows any mailbox with the scope of the OWAFullAccess policy to have read write access to the Newsletters app with the other features enabled by default.

Set-OwaMailboxPolicy -Identity OWAFullAccess -OutlookNewslettersReactions DefaultOn -OutlookNewslettersAccessLevel ReadWrite -OutlookNewslettersShowMore DefaultOn

After updating the mailbox policy, it will take between 15 and 30 minutes before the Newsletters app becomes available to users in the Outlook menu bar. Alternatively, users can open the app using the direct link.

Quick Tour of Outlook Newsletters

The user documentation for Outlook Newsletters is available online and doesn’t need to be repeated here. Instead, I’ll describe how I created and sent a newsletter in just a few minutes.

After opening the app, you can choose to create a newsletter or group page. A group page is recommended when a newsletter has multiple contributors and multiple newsletters will be created with common branding, so that’s what I created (Figure 1). I added a heading and some common settings shared by all the newsletters associated with the group page.

Next, create a newsletter by selecting one of the out-of-the-box templates or a blank template. I used the basic template, which seemed like a good starting point to create a newsletter to circulate details of blog posts published over the last month.

Creating the content of a newsletter is a matter of editing the elements contained in sections. A template contains prepopulated sections to make the task easier, but you can add or remove elements as you like to create the desired effect. In my case, I extracted snippets and links for blog posts and combined them with images to highlight each article. Suitable images can be uploaded or generated using Microsoft Designer.

Draft newsletters and comments are stored in SharePoint Embedded containers and are visible through the SharePoint admin center (Figure 3) and PowerShell. Unhappily, an application name isn’t registered for the containers used by Outlook Newsletters. No doubt this is a detail that Microsoft will clean up before GA.

When the newsletter is complete, it’s ready for sending. This process involves creating a HTML format body part and combining it with message properties like the message title and recipients (Figure 4) before sending the message from the author’s mailbox, much like you’d do with Graph APIs.

Only known recipients can receive newsletters. A known recipient is an emailable object known to Exchange Online, including distribution lists, Microsoft 365 groups, individual mailboxes, mail user objects for guest accounts, and mail contacts.

You can enter an SMTP address, but Outlook drops these addresses if they don’t match with a known recipient when it sends the message. The golden rule is that to send a newsletter to an external address, the address must belong to a known recipient. This isn’t a big deal because it’s easy to create a mail contact for an external recipient, even for something like the email address for a team channel.

When sent, copies of the newsletter are normal messages in recipient mailboxes. After it is sent, the newsletter remains available for editing in the Newsletters app. If you make some changes and send another version, everyone in the recipient list receives a new copy.

Lots to Like

There’s lots to like about the Outlook newsletters app. The output generated looks well, basic analytics are included, newsletters support subscribe and unsubscribe options, messages can be sent from one mailbox with replies going back to a different mailbox, and so on. It’s definitely an app that people who send internal communications can find value.

Although it’s possible to send newsletters externally, restrictions like the new tenant-wide external recipient limit in Exchange Online constrain sending high volume communications, even if you add all the external email address as mail contacts. Used properly for internal communications, Outlook newsletters have the potential to be very successful.

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.

Subscribers Can Download Files for Monthly Update #117 Now

The Office 365 for IT Pros author team is delighted to announce the availability of the March 2025 update for the Office 365 for IT Pros (2025 edition) eBook. This is monthly update #117. Readers can check the update number of the book on the inside front cover. Details of the update are available in our change log.

This update also includes update #9 for the Automating Microsoft 365 with PowerShell book, the most complete and comprehensive coverage of using PowerShell to create solutions based on Microsoft 365 data. Despite the recent quality problems for the Microsoft Graph PowerShell SDK, we still have strong faith in the usefulness of the PowerShell SDK and the ability it gives tenant administrators to access and use data across a wide range of workloads.

Subscribers can download the updated files from their Gumroad account or by using the download link in the receipt they received by email following their original purchase. The link in the receipt always accesses the latest files. See our FAQ for more information about how to download updates.

The Demise of Skype

The flux within the Microsoft ecosystem was dramatically illustrated by last Friday’s announcement that Microsoft will close down the Skype service on May 5, 2025. While the only impact on Microsoft 365 tenants will be the retirement of Skype interoperability with Teams (MC1019985, 28 February 2025), the demise of Skype is a sign of the ruthlessness that can happen when large corporations seek savings to invest elsewhere. Anything that doesn’t generate a good return is likely to be canned, which is what happened with Viva Goals late last year.

On a personal level, I don’t think I shall miss Skype too much. The app is installed on my PC and phone, but I don’t think I have made a Skype call in a year or more. Microsoft wants people to move to Teams personal (aka Teams for free), which I also have. However, I don’t use Teams personal for calling either because of the ubiquity of WhatsApp and the easy availability of low-cost data eSIMs around the world.

Some have pointed to the $8.5 billion price paid for Skype in 2011 and wondered if Microsoft got value for the purchase. I think that they did. The challenges of scaling up Teams to deal with the demand for online meetings when the pandemic happened were huge, and the experience of running the Skype backend was invaluable (according to Rish Tandon, who ran Teams engineering at the time). It can be argued that the pandemic made Teams and propelled its development to a point where it now supports 320 million monthly active users (the latest figure from October 2023). Without the success of Teams, would the Microsoft cloud now be at an annualized run rate of $163.6 billion? In that light, the investment in Skype seems like a rounding error.

Microsoft 365 Security for IT Pros

We are often asked about updates for the Microsoft 365 Security for IT Pros eBook. The facts are that we have nothing to do with this book. After sharing some of our processes and procedures to help the author team get up and running for the original edition in 2020, we have had no interaction with the book since. The latest edition appeared in 2023 and it seems like some difficulties have occurred in keeping the material updated.

We understand the book update challenge very well because publishing a monthly update takes a lot of time and effort. Muscle memory makes the task a little easier after 117 updates, but it’s still not as easy as some might think.

On to Update #118

Heading into March, we have started work on update #118. This will be the ninth update for Office 365 for IT Pros (2025 Edition), so it’s time to start thinking about the next edition. We typically publish a new edition on July 1 each year and I don’t anticipate any change to that cadence. But the writing team will get together at the Microsoft HQ in late March for the annual MVP summit and I am sure we’ll have a chat about the next version then. Stay tuned!

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology. The Office 365 book package includes the Automating Microsoft 365 with PowerShell eBook.

Opens Access to UDP-Protected Files to Search, eDiscovery, and DLP – but not Copilot

Originally announced in preview in an August 1, 2023 technical community post, message center notification MC1013467 (21 February 2025) contains the good news that SharePoint Online will deploy support for sensitivity labels with user-defined permissions (UDP) in mid-March 2025. The reason why this development is important is that SharePoint Online support for UDP enables support for these files in content searches, Purview eDiscovery, and Purview Data Loss Prevention (DLP).

Configuring Permissions for Sensitivity Labels

Most sensitivity labels that protect files with rights-management based encryption use permissions configured by administrators. Permissions are formed by a set of usage rights that dictate what level of access an authenticated user has to a file. The same permissions apply to all files that receive a label with preconfigured access.

User-defined permissions allow file owners to assign different permissions for different files. To allow this to happen, administrators must configure a sensitivity label to support UDP (Figure 1).

After the label is published to make it available to users, they can assign the label and configure permissions for files (Figure 2). UDP labels are visible in Office web applications but can only be set by Office desktop applications.

Clicking more options reveals additional controls for a user to assign to protect a file, including an expiration date (which doesn’t pick up the date format configured for the workstation) for the permissions, a contact email address to request additional permissions, and whether a user must be online to validate their permission before they can open a file. The last option, to access content programmatically, allows Word and Excel to run code within a protected document.

Support for Microsoft Search

The initial SharePoint support for UDP-protected files previewed in August 2023 was limited. The big issue remained that files with UDP labels stored in SharePoint Online or OneDrive for Business couldn’t be indexed by Microsoft Search because Search had no way to gain access to file content (metadata for UDP-protected files is always indexed). This is important because Microsoft Search is an essential component for other services such as eDiscovery. In a nutshell, no indexing meant that UDP-protected files were invisible outside SharePoint Online.

The news announced in MC1013467 addresses the problem, but in a very focused manner. Although the number of UDP-protected files stored in SharePoint Online is likely a very small percentage of the billions of new files created daily, there’s no way that a trawl across all sites to find and process UDP-protected files could work in a practical sense.

To solve the problem, SharePoint Online processes newly-created UDP-protected files from mid-March 2025 to make their content accessible to Microsoft Search. Once indexed by Search, the file content is available to other Microsoft 365 workloads like eDiscovery. During the indexing process, SharePoint interprets the permissions assigned to a file by the author to ensure that those with relevant permissions can engage in co-authoring. In addition, SharePoint Online and the Office apps need permission to access the file before the autosave feature can work. It takes a little time to process a new file after it is uploaded to SharePoint Online. Microsoft reckons on ten minutes, but I have experienced longer delays before features like autosave work.

Older files stored in sites remain inaccessible to SharePoint Online until the next time they are edited. At this point, SharePoint processes the file content to make it searchable. Over time, the idea is that the number of inaccessible UDP-protected files will gradually decrease, and the problem will go away. Once a file is processed by Search, it becomes available to content searches, eDiscovery, and DLP.

Even when UDP-protected files are processed by Microsoft Search, MC1013467 says that “files with labels configured for user-defined permissions will continue to not be available for Microsoft 365 Copilot processing.” In other words, although Search can find UDP-protected files, Copilot still does not have the necessary permissions to load content from those files to use when generating responses to user prompts.

No Big Change for Users in the Immediate Future

From a user perspective, the update for how SharePoint Online processes UDP-protected files won’t mean dramatic change in the immediate future. UDP sensitivity labels might become more popular and widespread, but that’s a process that needs time because it must be factored in the organization’s information protection policy, which is probably currently based on preconfigured permissions. Administrators will need time to absorb the news and figure out how and if UDP-protected files bring value to the business before they create and publish UPD labels.

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.

Graph SDK V2.26 Issues Make the Software Unusable

The Microsoft Graph PowerShell SDK is becoming increasingly popular. With over 3.5 million downloads of the previous version, a new release was bound to be a major event., especially after a three-month delay since Microsoft released V2.25 on November 21, 2024 (the SDK usually follows a monthly release cadence). V2.26 duly arrived five days ago.

Alas, you should avoid and not install V2.26. The release is buggy, exhibits little evidence of being tested before launch, and creates huge operational problems for Azure Automation-based runbooks.

The Cracks Appear

I installed V2.26 soon after it appeared in the PowerShell Gallery. I have a large number of PowerShell scripts and runbooks based on the Microsoft Graph PowerShell SDK and it didn’t take long before cracks appeared. For example, HTML messages generated by the Send-MgUserMail cmdlet didn’t display property in multiple email clients, including Outlook classic, the new Outlook, OWA, and Proton (Figure 1).

Another issue was that the Send-MgUserMail cmdlet failed to process attachments. The script I published last week to show how to add and send multiple attachments with Outlook messages failed spectacularly. Many production scripts use Send-MgUserMail to generate and send HTML formatted messages, so this issue was a big problem for a new release.

To be fair to Microsoft, they quickly fixed the two Send-MgUserMail issues. However, these weren’t the only problems. For instance, the New-MgGroupMember cmdlet failed because of an “invalid URL format” generated by an odd value appended to the request URI created for the POST request to add a new group member.

As is my norm, I reported the issues as I encountered problems (anyone who finds a problem with the Microsoft Graph PowerShell SDK, can report the issue online). After a couple of hours, it was evident that V2.26 was in bad shape and practically unusable.

The Big Issue

Discovering several Priority 1 issues in a short period is bad enough; finding that V2.26 had dropped support for .NET6 and .NET7 without warning delivered the coup de grace. This news is a bullet point in the Microsoft Graph PowerShell SDK release notes, which is nice if you read that information and understand the full consequences of the removal. Microsoft delivered no context for the change and no commentary as to what might be the effect.

Issue #3151 was the first report that came in to advise that Azure Automation runbooks had stopped working with V2.26. As you might recall, before Microsoft Graph PowerShell SDK cmdlets can be used with Azure Automation, the modules containing the cmdlets must be loaded as resources into the automation account. You can then create runbooks based on a specific PowerShell version and use the cmdlets in those runbooks.

Azure Automation supports runbooks based on PowerShell V5.1, V7.1. and V7.2. Sometimes a module only supports V5.1 (the SharePoint Online management module is an example), but usually it’s recommended to use PowerShell 7. The problem introduced with the new version of the SDK is that PowerShell V7.1 and V7.2 don’t use .NET 8. Because the SDK dropped support for .NET6 (which reached end of support in November 2024) and .NET7 (which reached end of support in May 2024), Azure Automation and the Microsoft Graph PowerShell SDK are now at odds with each other.

To demonstrate, I created a new automation account and loaded the Microsoft.Graph.Authentication module into the account (Figure 2). This module is the foundation of the Microsoft Graph PowerShell SDK because all other modules have a dependency on it. Note that the runtime version is PowerShell 7.2.

Next, I created a very simple runbook to sign into the Graph using a managed identity (Figure 3). The only processing performed by the runbook is to sign in and report the authentication context.

When I ran the runbook, it failed because the runbook couldn’t load an assembly it needed to run the Connect-MgGraph cmdlet. This isn’t surprising because PowerShell 7.2 is looking for a file that it doesn’t support or isn’t available.

Stay with V2.25

You won’t have a problem if automation accounts keep on using V2.25. You will have problems if you upgrade automation accounts to use the V2.26 modules or create new automation accounts and load the V2.26 modules (which is what Azure Automation offers) as account resources. Some workarounds have been suggested, such as using the Azure Runtime Environment, but that’s a preview feature and I don’t recommend using it in production. You’re safer by leaving the V2.25 modules in place and not attempting to upgrade.

A Big Mess

It’s obvious that V2.26 of the Microsoft Graph PowerShell SDK is a big mess. It’s not the only fiasco in SDK history as previous problems were experienced in V2.14 and V2.17/V2.18 in 2024. It’s obvious that Microsoft didn’t test this release thoroughly before pushing it out the door. It’s also clear that Microsoft failed to appreciate or communicate the impact of removing support for .NET6 and .NET7 on Azure Automation. I don’t recall seeing a support article that clearly outlines how V2.26 affects Azure Automation that might convince customers to pause upgrading to V2.26.

Although the two .NET releases are retired, PowerShell in Azure Automation hasn’t moved on to support PowerShell V7.5. Perhaps that’s because the Azure Automation development team know that dropping support for PowerShell V7.1 and V7.2 might break many production runbooks. Still, that’s an internal issue for Microsoft to work out between the development groups. Customers shouldn’t have to experience the downside of the lack of coordination and planning that obviously exists within the world’s largest software company.

If you’re one of the 150,000 who downloaded V2.26 SDK, it’s time to bin it and revert to V2.25. At least that version works.

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.

Microsoft Clamps Down on EWSEnabled Tenant Setting to Enable Exchange Web Services

Exchange Web Services (EWS) is scheduled for retirement on October 1, 2026. Although October 2026 is still 19 months away, retiring an API that was heavily used at one time requires time and patience to expunge every trace of the API. Microsoft has already removed EWS from clients like Outlook for Mac and is working through the steps to remove EWS from its other applications.

Independent software developers have received clear directions that they should replace EWS with the Microsoft Graph. The acknowledged gaps in functionality that currently exist in the Microsoft Graph are being closed, with the latest example being the introduction of the Exchange mailbox import-export API (see MVP Glen Scales’ commentary on the new API).

Now Microsoft is preparing for the final removal by clamping down on the organization setting which controls whether EWS is enabled or disabled within a tenant. In a February 20, 2025 post, Microsoft says that the organization-level EWSEnabled flag will play a more significant role than it has done in the past. The change is being made to make it easier for Microsoft to disable EWS across Microsoft 365.

Enabling EWS for a Mailbox

In the past, it was sufficient for administrators to set the EWSEnabled flag for a mailbox to $true to allow the mailbox to use EWS in apps and clients. This condition existed because the mailbox setting has precedence over the setting in the Exchange Online organization configuration and, by default, the organization setting is null.

Get-OrganizationConfig | Select-Object EWSEnabled

EwsConfig
---------

The only time administrators set the organization-level EWSEnabled setting is if they wanted to block EWS throughout the tenant. Usually, this need didn’t arise because it was sufficient to set EWSEnabled to $true on the mailboxes that needed access to EWS. For instance, because EWSEnabled is $true for the James Ryan mailbox, that mailbox can use EWS even though the organization setting is null.

Get-CasMailbox -Identity James.Ryan | Select-Object EWSEnabled

EwsEnabled
----------
      True

The Big Change

What’s changing is that Exchange Online will only permit a mailbox to use EWS if both the organization and mailbox settings are $true. The old situation where the default null value at the organization level is sufficient to allow access is no longer in force. Tenants that want to use EWS to the bitter end must now explicitly enable EWS in the Exchange Online organization configuration:

Set-OrganizationConfig -EWSEnabled $true

You can see where Microsoft is going. By forcing the relatively small number of tenants to explicitly allow EWS by updating the organization configuration, Microsoft is preparing for the big turn-off when they will update the organization configuration to set EWSEnabled to $False and block any further changes to the setting. It’s an elegant and effective way of making sure that the turnoff happens on October 1, 2026.

Problems might arise for tenants that have the organization configuration set to $false already and still have a small number of mailboxes enabled for EWS. The precedence enjoyed by the mailbox setting allows these mailboxes to access EWS, but once Microsoft removes the precedence, those mailboxes will lose the ability to use EWS.

The solution is to update the organizational setting back to $true. It might seem counterintuitive to allow EWS for the tenant, but the existing access setting for mailboxes will then kick in and only those mailboxes enabled for EWS can continue making EWS API requests.

Check Mailboxes Enabled for EWS

Given that we’re on the final glidepath to the retirement of EWS, it’s a good idea to validate that the set of mailboxes enabled for EWS declines over time. That way you’ll know if the dependency on EWS within the organization is reducing and understand why some mailboxes continue to need EWS. To help, I put together an Azure automation runbook that looks for EWS-enabled mailboxes and emails the details using Exchange High Volume Email (HVE). The email (Figure 1) serves as a nagging reminder for tenant administrators to minimize the set of mailboxes enabled for EWS. Using Azure Automation means that it’s easy to schedule the job to run weekly (or whatever period makes sense) as the clock ticks down to October 1, 2026.

You can download the code from the Office 365 for IT Pros GitHub repository. See this article for more details about running Exchange Online PowerShell in Azure Automation, and this article about using HVE in Azure Automation.

I chose HVE rather than using the Send-MgUserMail cmdlet from the Microsoft Graph PowerShell SDK because there’s an odd bug that stops the latest version of Exchange Online PowerShell module working in version 7.2 runbooks. My Graph setup is based on PowerShell 7, so mixing and matching Exchange Online and the Graph SDK doesn’t work as smoothly as it should for now. Microsoft is aware of the issue. I believe it will be fixed in the next release.

You don’t need to use Azure Automation as a standard script will do the job too. It just seems to make sense to me to have Azure Automation run the job without human intervention. After all, I might forget to check…

When You Want to Add Attachments to Email

Many examples exist to show how to send a single attachment with an email using the Send-MgUserMail cmdlet from the Microsoft Graph PowerShell SDK. Microsoft’s documentation covers how to send a single attachment but is mute on how to process a batch of attachments. This is understandable because the need to send multiple attachments for a single message from PowerShell isn’t probably of huge importance when it comes to programmatically creating and sending email.

With that thought in mind, I set out to create some sample code to illustrate the principle behind adding multiple attachments to a message sent with the Send-MgUserMail cmdlet.

An Array of Attachments

The essential points to remember are:

• To include one or more attachments in a message, the attachment key must be present in the hash table that describes the message. The associated value is an array of attachments.
• Each attachment is represented by a hash table in the attachments array.
• The hash table for an attachment describes its odata type, file name, content type, and the base64-encoded content for the file.

Thus, the hash table for an attachment looks like this:

$AttachmentDetails = @{
        "@odata.type" = "#microsoft.graph.fileAttachment"
        Name = $File
        ContentType = $ContentType
        ContentBytes = $ConvertedContent
}

Adding Multiple Attachments

The first step is to find some files to attach. This code looks for files in a specified folder and checks the total file size to make sure that adding all the files as attachments won’t exceed 140 MB. The documented maximum message size for Exchange Online is 150 MB, but there’s always some overhead incurred from encoding, the message body, message properties, and so on.

$AttachmentsFolder = "c:TempAttachments"
[array]$InputAttachments = Get-ChildItem -Path $AttachmentsFolder
If (!($InputAttachments)) {
    Write-Host "No attachments found in $AttachmentsFolder"
    Break
}   
$FileSizeThreshold = 146800640 # 140 MB in bytes
$TotalFileSize = ($InputAttachments | Measure-Object -Sum Length).Sum
$FoundSizeMB = [math]::Round($TotalFileSize / 1MB, 2)
If ($TotalFileSize -gt $FileSizeThreshold) {
    Write-Host ("Total size of attachments is {1} MB. Maximum size for an Outlook message is 140 MB. Please remove some attachments and try again." -f $TotalFileSize, $FoundSizeMB)
    Break
}

To prevent problems, the code won’t process the attachments if their total size is more than 140 MB and will report an error like this:

Total size of attachments is 182.14 MB. Maximum size for an Outlook message is 140 MB. Please remove some attachments and try again.

This avoids the problem when an attempt is made to send a message with oversized attachments, the Send-MgUserMail cmdlet will report:

Error sending message: [ErrorMessageSizeExceeded] : The message exceeds the maximum supported size., Cannot save changes made to an item to store.

The failure could occur because the mailbox that’s sending the message isn’t capable of handling such a large email. By default, Exchange Online enterprise mailboxes can send messages of up to 150 MB and receive messages of up to 125 MB (why the two values are different is debatable). To change these values for a mailbox, run the Set-Mailbox cmdlet:

Set-Mailbox -Identity Jane.Smith@office365itpros.com -MaxReceiveSize 150MB -MaxSendSize 150MB

Populating the Attachments Array

To populate the attachments array, the code creates a base64-encoded form of the file content and attempts to figure out the most appropriate content type. This is an optional property and Microsoft 365 can decide which format is best if you omit the property.

$FullFileName = $AttachmentsFolder + "" + $File
$ConvertedContent = [Convert]::ToBase64String([IO.File]::ReadAllBytes($FullFileName))
$FileExtension = [System.IO.Path]::GetExtension($FullFileName) 
Switch ($FileExtension) {
    ".pdf" {
        $ContentType = "application/pdf"
    }
    ".docx" {
        $ContentType = "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
    }
    ".xlsx" {
        $ContentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
    }   
    ".pptx" {
        $ContentType = "application/vnd.openxmlformats-officedocument.presentationml.presentation"
    }   
    ".jpg" {
        $ContentType = "image/jpeg"
    }   
      ".png" {
       $ContentType = "image/png"
    }   
       default {
       $ContentType = "application/octet-stream"
    }
}

After processing an attachment, the code creates the hash table referred to earlier and adds it to the attachment array:

$MsgAttachments += $AttachmentDetails

The attachment array then becomes part of the message structure:

$Message = @{}
$Message.Add('subject', $MsgSubject)
$Message.Add('toRecipients', $MsgTo)
$Message.Add('body', $MsgBody)
$Message.Add('attachments', $MsgAttachments)

The final step is to call Send-MgUserMail to send the message. If everything works, it will arrive at its destination complete with a set of attachments (Figure 1).

Get the Structure Right and Everything Flows

Dealing with attachments through the Microsoft Graph PowerShell SDK is straightforward once you understand the structures used and how they are populated. It would be nice if the SDK cmdlet documentation covered this kind of thing better, but they don’t, so here we are.

You can download the script I used from the Office 365 for IT Pros GitHub repository. This article describes another example of using the Send-MgUserMail cmdlet.

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.

Audit-Based Alerts Retired from March 25, 2025

Publish bad news on Friday is the advice for anyone who wants the news to create less of a fuss. Publishing the news late on Friday before a holiday the following Monday (U.S. Presidents’ Day) might do an even better job of suppressing criticism. Some will consider the announcement in Message center notification MC1006620 (15 February 2025) that “Purview will retire the event alerts capability within the Purview Audit solution on March 24, 2025” to be bad news. It all depends on whether you use alerts based on audit events to learn when something happens in a tenant.

Activity Alerts

Microsoft introduced activity alerts and alert policies soon after the introduction of the unified audit log in July 2015. The idea is simple. The audit log holds some extraordinarily valuable information about what happens in a tenant, but a busy tenant can generate hundreds of thousands of audit events daily. Human administrators don’t have the time to keep on checking if events of interest (for whatever reason) show up in the audit log. Computers are very good at checking data, and activity alerts are predefined checks against new audit events as workloads ingest data into the audit log. If an event of interest is found, Purview sends email to administrators to tell them about the event (Figure 1).

Better Tools to Analyze Audit Events Exist

Although useful (and still used), a case can be made that activity alerts have passed their sell-by-date. The unified audit log holds an increasing amount of data generated by workloads from Entra ID to SharePoint Online to Teams to Purview. Better tools exist to allow tenant administrators to monitor events of interest, including connecting Office 365 data to Microsoft Sentinel where the data can be analyzed along with information gleaned from other sources. Many organizations run background jobs to extract audit events from the unified audit log for ingestion into an external SIEM. There’s even a Splunk add-on to extract audit data for Microsoft 365. And if you want to involve AI, there’s Security Copilot to consider.

And if off-the-shelf software isn’t available, PowerShell can be used to extract and analyze audit events using either the Search-UnifiedAuditLog cmdlet or the AuditLogQuery Graph API. The signs are that Microsoft wants customers to use asynchronous Graph-based audit searches because these searches absorb fewer resources. Removing the monitoring of new audit events to be able to generate audit alerts seems to be another attempt to restrict the resources consumed by audit activity.

Using either the cmdlet or Graph query, the same kind of processing to find and email alerts for audit events of interest is easily done using a combination of PowerShell and scheduled Azure Automation jobs.

Confusion with DLP Alerts

Data Loss Prevention (DLP) policies can also signal alerts when policy rules detect violations. MC1006620 confuses the issue slightly by reassuring tenants that DLP alerts are unaffected by the retirement of audit-based activity alerts.

Further confusion comes about in the assertion that customers who want to retain audit-based activity policies should recreate them using DLP policies. Outside of scenarios like unusual file downloads, I’m not sure if this is even possible for some of the activities audit-based alert policies highlight. Microsoft says that they will invest their development resources on the alerts functionality within DLP, which is fine even if it might not cover everything that might be exposed in an audit event.

In any case, as noted above, a range of options exist to monitor audit events and signal alerts if something of interest is discovered.

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

Custom Columns are One Part of the Mystery of SharePoint Search

Understanding how SharePoint Online search works is one of the learning curves faced by many Microsoft 365 tenant administrators. Because search is so important to SharePoint, this topic is well-covered ground for people who worked with SharePoint Server (on-premises). The magic that melds managed properties, crawled properties, mapping, custom cpolumns, indexes, and so on into search doesn’t hold any mysteries.

Things are different for those who come to SharePoint because of its core role within Microsoft 365. SharePoint Online is not the center of an ecosystem like SharePoint Server is. Like Exchange Online delivers email services, the cloud version of SharePoint takes on a completely different role as the provider of document management services to other workloads, like Teams. The different role doesn’t make search any less important. People still want to find files quickly and easily but competing demands from across Microsoft 365 mean that administrators sometimes pay less attention to the finer details of search. After all, search just works in the cloud…

Generally, SharePoint search does just work. Sometimes complexities do exist, like finding out how to find files with a specific sensitivity label. Although users mightn’t want to look for labelled files, administrators might need this knowledge to find labelled files in eDiscovery searches, and that’s why some knowledge about how search works is a good skill to acquire, even for non-SharePoint people. In my case, it helped me to maximize the advantage of creating a custom column for a site.

Creating a Custom Column

SharePoint Online is basically a big Azure SQL application based on a database holding many lists (tables). The lists hold data in items with the information for each item stored in columns (fields). SharePoint allows site administrators to define new custom columns at a site or library level. I use this feature to track the topic areas for articles I publish on different sites.

In general, defining custom columns at site level is recommended because the custom columns can then be used in any library. Figure 1 shows the properties of a custom site column called RAInfo.

After creating the site custom column, use the Add from existing site columns option in Library settings to add the column to a document library. Once the column is added to a library, it can be added to the view that exposes file metadata and edited there (or updated programmatically using a Graph API or SDK cmdlet).

Remaining in library settings, go to Indexed columns and add the new custom column as an index. SharePoint libraries support up to 20 indices.

Using Custom Columns

One of the nice things about custom columns is that SharePoint supports their use in filters. In Figure 2 we see that the filter picker shows the values entered for files in the RAInfo custom column. Selecting the desired values for the RAInfo column helps SharePoint to find and display files that meet the filter criteria. Of course, filtering only works if users remember to enter the necessary information for files.

Users can also input a custom column value (for instance, “RA001”) into the search box to search the library for matching files. Because the custom column is part of the document metadata, SharePoint search can use it to find files.

Making Custom Columns More Searchable

The search against document metadata finds matches against any property containing the value. A further step is required to allow searches against the custom column be more specific.

When you create a custom site column, SharePoint Online creates a managed property named using the form CustomColumnName + “OWSText.” In this case, the managed property is called “RAInfoOWSText.” SharePoint also creates a crawled property with the name OWS_Q_TEXT_CustomColumnName, or OWS_Q_TEXT_RAInfo in our case. The crawled property is what SharePoint search extracts from a site.

To allow search to use the managed property, it’s critical to map the managed property to the crawled property and wait for indexing to complete. Once indexing is complete, you can input RAInfoOWSText:RA001 into the search box. This command instructs SharePoint to search against the RAInfoOWSText managed property.

Not everyone will appreciate working with what seems to be odd column names. To solve the problem, go to Site Information, then View all site settings, and select the Search schema. You can now create an alias for the custom column, hopefully giving the column a name that makes more sense to regular users. In Figure 3, I’ve assigned RAInfo as the alias for the RAInforOWSText managed property.

Adding an alias to disguise some of the complexities of SharePoint search is a small but useful step to take. Now users can input search terms like RAInfo:RA003 (Figure 4) into the search box instead of RAInfoOWSText:RA003 and find the same information.

Take Your Time

One thing that you’ll discover when tweaking SharePoint search is that it takes hours and sometimes days for changes to become active in a site. Users need to populate values in the custom column and search needs to index those values, including respecting the changes that you might have made like adding an alias for a managed property. You can force the issue somewhat by requesting a reindex of the document library (in library advanced settings), but SharePoint Online can’t be rushed too much.

Take your time and everything will work in the end. At least, it did for me.

Enforcing Strong MFA Through Protected Actions Might Block Bad Actors

A January 25, 2025 blog about how attackers leverage the User.DeleteRestore.All Graph permission attracted my attention. The idea advanced is that if attackers can wreak havoc if they can secure the User.DeleteRestore.All permission. There’s no doubt that this assertion is correct. Attackers being able to permanently remove soft-deleted user accounts from the Entra ID recycle bin is enough to give any tenant administrator a severe headache.

Protected actions might offer some protection against attacker destruction. When I first covered this capability in May 2023, it was early days for the feature. Essentially, a protected action is associated with a conditional access policy through an authentication context so that any attempt to perform the protected access invokes the conditions set in the policy. For instance, the condition could be that the user must authenticate themselves with a strong phishing-resistant authentication method like a FIDO2 key or passkey.

The idea here is that the attacker might not be able to satisfy the authentication challenge with the required strong method and is therefore blocked from performing the protected action. That theory falls down if the attacker has gained sufficient control over the tenant to update conditional access policies (unless you block update access to conditional access policies with a protected action).

Creating a CA Policy for Protected Actions

Microsoft’s documentation for adding a protected action is straightforward. To add a protected action to guard against unexpected removal of soft-deleted user accounts, create a conditional access policy for Entra ID to invoke when a connection attempts to us an authentication context (basically, when something happens – like accessing a sensitive SharePoint Online site). The CA policy (Figure 1) is very simple and associates an authentication context with strong authentication. You could add other policy requirements to grant access to make it harder for attackers. For instance, require the use of a compliant device.

The magic comes when you link the authentication context with one or more permissions. The set of supported permissions for protected actions has grown over time and includes microsoft.directory/deletedItems/delete, the permission to permanently delete objects from Entra ID. Deleted user accounts normally remain in a soft-deleted state in the Entra ID recycle bin for 30 days following deletion. Soft-deleted means that the accounts are recoverable. However, if the account is removed from the recycle bin, it is hard-deleted and irrecoverable.

To link the authentication context, go to the Roles & admins section under Identity in the Entra admin center and select Protected actions. Find the authentication context to link, select the permission, and save (Figure 2).

You can’t link a protected action to multiple authentication contexts. If you make a mistake and link the protected action to the wrong authentication context, you must remove the protected action and add it to the correct authentication context.

Testing the Protected Action

To test the effectiveness of the protected action, you need an account that holds an administrative role that would normally allow the holder to permanently remove soft-deleted user accounts that doesn’t meet the requirements of the CA policy. I used an account holding the Global administrator role that used SMS to satisfy an MFA challenge. Entra ID doesn’t consider SMS to be an authentication strength that meets the criteria of passwordless MFA, so any attempt by this global administrator to remove a soft-deleted account fails (Figure 3).

The block also works if an attempt is made to remove an account using the Graph Permanently delete an item API or the Remove-MgDirectoryDeletedItem cmdlet from the Microsoft Graph PowerShell SDK.

Get-MgDirectoryDeletedItemAsUser | Format-Table Id, displayname

Id                                   DisplayName
--                                   -----------
63699f2f-a46a-4e99-a068-47a773f9af11 Annie Colonna
f13e62ff-b43c-44e7-a821-48db196b84d9 Cathy Lin
889bad5f-d7f7-4731-bf07-af2894f345b2 Joanne Crispa

Remove-MgDirectoryDeletedItem -DirectoryObjectId f13e62ff-b43c-44e7-a821-48db196b84d9

Remove-MgDirectoryDeletedItem_Delete: Operation requires conditional access and client does not support it. Client must be configured to support conditional access claims challenges to proceed.

Insisting on Stringent Conditions is Sometimes Good

Any organization that has deployed conditional access policies should consider using protected actions. The necessary policies are easy to implement, and it makes sense to insist on stringent conditions before destructive actions like permanent removal of user accounts are possible.

The only issue I encountered during testing was that Entra ID didn’t respect the disabling of the CA policy used for protected actions. No matter what, the policy remained in force until I removed the protected action. It’s possible that the underlying cause was a timing issue generated by multiple changes to settings over a short period and that everything would have worked more smoothly if I was more patient. In any case, the issue shouldn’t be a problem in practical terms because it’s highly unlikely that anyone will disable and enable a CA policy to turn protected actions off and on several times in quick succession, but it’s definitely something that the developers should investigate.

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.