Copilot Usage Reports Weak on Detail

Announced in message center notification MC877369 (29 August 2024, Microsoft 365 roadmap item 396562), the Microsoft Graph beta usage reports API now includes support for Copilot for Microsoft 365 tenant usage data. All tenants that use Copilot for Microsoft 365 should now have access to the usage data.

Microsoft says that the availability of this information will “facilitate the creation of customized reporting and analytics,” but the fact is that the data exposed by the API is bare-bones. On the upside, the data matches what’s available in the report section of the Microsoft 365 admin center (Figure 1).

• Tenant-level summary of Copilot-enabled (licensed) users and active users.
• Adoption trend (tenant summary) over time.
• Last activity date for Copilot interaction in different apps for each user.

Accounts accessing the Graph data must have a Copilot for Microsoft 365 license.

User Count Summary

The user count summary report returns a count of the user accounts licensed for Copilot for Microsoft 365 (enabled users) and a count of the users with an active interaction with Copilot in each app during the reporting period (7, 30, 90, or 180 days). Unsurprisingly, when someone is enabled for Copilot in one app, they’re usually enabled for all:

• Teams
• Outlook (classic, new Outlook for Windows, OWA).
• Excel.
• PowerPoint.
• Copilot Graph-grounded chat (aka Copilot Chat).
• OneNote.
• Loop.

$Uri = "https://graph.microsoft.com/beta/reports/getMicrosoft365CopilotUserCountSummary(period='D90')"
$Data = Invoke-GraphRequest -Uri $Uri -Method Get
$Data.value.adoptionByProduct

Name                           Value
----                           -----
loopEnabledUsers               100
reportPeriod                   90
oneNoteActiveUsers             3
wordEnabledUsers               100
powerPointEnabledUsers         100
microsoftTeamsActiveUsers      97
oneNoteEnabledUsers            100
excelActiveUsers               43
loopActiveUsers                2
copilotChatEnabledUsers        100
outlookEnabledUsers            100
anyAppEnabledUsers             100
anyAppActiveUsers              97
microsoftTeamsEnabledUsers     100
excelEnabledUsers              100
wordActiveUsers                61
powerPointActiveUsers          12
copilotChatActiveUsers         73
outlookActiveUsers             18

User Activity Detail

This report is the most interesting because it details the last activity date for Copilot interaction by users with each of the various Copilot-enabled apps. In addition, the last activity date for any Copilot interaction with any of the supported apps is published (lastActivityDate). An array (value) holds a separate usage report for each Copilot-enabled account.

The user principal name and display name is obfuscated if the tenant data privacy control is enabled. In the following extract, we see that the user has never used Copilot for Loop and OneNote and hasn’t used Copilot with PowerPoint since April 11, 2024:

$Uri = https://graph.microsoft.com/beta/reports/getMicrosoft365CopilotUsageUserDetail(period='D90')
$Data = Invoke-GraphRequest -Uri $Uri -Method Get
$Data.value[0]

Name                           Value
----                           -----
copilotActivityUserDetailsByP… {System.Collections.Hashtable}
microsoftTeamsCopilotLastActi… 2024-09-05
outlookCopilotLastActivityDate 2024-08-29
lastActivityDate               2024-09-05
reportRefreshDate              2024-09-08
excelCopilotLastActivityDate   2024-09-05
loopCopilotLastActivityDate
oneNoteCopilotLastActivityDate
copilotChatLastActivityDate    2024-09-05
powerPointCopilotLastActivity… 2024-04-11
userPrincipalName              Tony.Redmond@office365itpros.com
displayName                    Tony Redmond
wordCopilotLastActivityDate    2024-09-05

Adoption Trend over Time

This report returns an array called adoptionByDate with entries for each day during the reporting period (7, 30, 90, or 180 days). The purpose of the report is to track progress in Copilot adoption over time and to note if any specific action had an effect. For instance, you might run an education campaign to teach users how to generate effective results using Copilot in Excel. Over the weeks following the campaign, you’d expect to see the number of users who use Copilot in Excel to grow.

$Uri = "https://graph.microsoft.com/beta/reports/getMicrosoft365CopilotUserCountTrend(period='D90')"
$Data = Invoke-GraphRequest -Uri $Uri -Method Get
$Data.Value.copilotActivityUserDetailsByPeriod

reportDate                     2024-06-17
excelEnabledUsers              100
wordActiveUsers                51
powerPointActiveUsers          11
copilotChatActiveUsers         66
outlookActiveUsers             15
loopEnabledUsers               100
oneNoteActiveUsers             1
wordEnabledUsers               100
powerPointEnabledUsers         100
microsoftTeamsActiveUsers      86
oneNoteEnabledUsers            1
excelActiveUsers               21
loopActiveUsers                1
copilotChatEnabledUsers        100
outlookEnabledUsers            100
anyAppEnabledUsers             100
anyAppActiveUsers              86
microsoftTeamsEnabledUsers     100

Track Copilot Activity Using Audit Records instead of Copilot Usage Reports

Although it’s nice to have Copilot usage reports included in the Graph API, the information exposed isn’t very informative in terms of how people use Copilot. The data tells you that someone used Copilot in an app during a day. At least, they clicked a Copilot button. The information doesn’t reveal any more insight than that. Any enterprise who invests large sums of money in expensive Copilot for Microsoft 365 licenses will find a dearth of detail here in terms of understanding whether the investment is justified. In many cases, you will be better off analyzing the audit records captured for Copilot interactions to figure out what’s really going on.

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.

Adding Detailed License Assignment Reporting

The Microsoft 365 licensing report script is possibly the most popular PowerShell project I’ve published. Given the amount of money that organizations can lay out on Microsoft 365 licenses, I guess people like keeping an eye on where the pennies get spent.

Over the past few months, I’ve responded to several requests for enhancements, such as highlighting license costs for disabled accounts, adding support for a cost center analysis, and so on. More requests keep on coming in, the latest being the desire to be able to report license costs per company within a tenant that supports several operating companies.

Previously, I’d been asked to include a line-by-line (or rather license-by-license) report per user. At the time, I didn’t see much point in doing this, but further reflection made me think that it would be good to output a list of individual license assignments that administrators could slice and dice to meet their needs.

Detailed License Assignment Report

V1.94 of the Microsoft 365 licensing report script does just that. Each license assignment, direct or via group-based licensing, is captured in an array called $DetailedLicenseReport. The report script creates the array automatically. To illustrate how the information can be used, if the $DetailedCompanyAnalyis variable is $true (the variable is set to $true in the script), the report script generates a detailed report about license assignments for each company found in the tenant (Figure 1). Each license is listed along with its assignees and the monthly cost of the licenses.

Obviously, creating such a report depends on accurate values in the company property of user accounts. If you didn’t want to report by company, it would be easy to change the code to create a detailed report of license assignments by department or cost center.

Removing Expired Licenses

The new version of the Microsoft 365 Licensing Report script also addresses expired licenses. When a subscription for a license comes to an end, it’s possible that some accounts have assignments for expired licenses. Eventually, Microsoft 365 removes the expired subscription and the expired licenses, but until this happens it’s possible that the report would include detailed of expired licenses, which is not what anyone would want.

I discovered this possibility when my tenant replaced some Office 365 E5 licenses with Office 365 with Office 365 E5 EEA (No Teams) licenses. This is one of the licenses created without a Teams service plan in an attempt to satisfy anti-competition concerns of the European Union. Microsoft subsequently decided to decouple Teams from all Office 365 and Microsoft 365 products, and new customers can no longer buy licenses that include Teams.

In any case, my tenant has some of the Office 365 E5 EEA (No Teams) licenses and separate Microsoft Teams EEA licenses, but some of the licenses from the older Office 365 E5 subscription still turned up on the report. This doesn’t happen anymore because the script now checks licenses against current subscriptions to remove any trace of expired subscriptions.

Downloading and Using the Microsoft 365 Licensing Report Script

V1.94 of the Microsoft 365 licensing report script is available from GitHub. If you haven’t used the script before, I encourage you to read the original article that launched me on this path and another article describing how the script learns about the costs of individual licenses. Things will become much clearer when you understand the basics of Microsoft 365 licensing, SKUs, products, service plans, and how to generate the CSV files used by the script.

Remember, this is all done with PowerShell and some calls to the Microsoft Graph to find information about the licenses assigned to users. No black magic is used. A script that’s over 700 lines long might seem intimidating, but many of the lines are blank or comments. Like any other PowerShell script, have fun amending the code to meet your needs!

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 (and write scripts like the Microsoft 365 Licensing report).

No Detail Available About How Hide Inactive Channels Feature Works

In July 2024, I discussed the initial deployment of the Teams feature to automatically hide inactive channels. Time moves on and the inactive channels are being hidden worldwide because the feature is now generally available in commercial Microsoft 365 tenants. GCC tenants should have it soon and GCC High and DOD tenants by the end of October 2024.

Two common comments about the feature have surfaced in the Microsoft Technical Community. The first is that the measurement of how Microsoft defines an inactive channel is opaque. In their original announcement, Microsoft says that the decision to hide a channel is because a user hasn’t “interacted with [the channel] over the past 45 days.” No further explanation is available what constitutes an interaction. Based on unscientific testing, it seems that opening the channel to read messages is sufficient rather than the more emphatic interaction of posting new topics, replying to messages, or responding with a reaction.

Hide Inactive Channels and the Lack of a Tenant-Level Control

The second issue is the lack of tenant control over the feature. Teams hides channels whether tenant administrators) like it or not. A user-level setting exists in the general section Teams settings app (Figure 1), but there’s nothing available in a Teams policy or a tenant-level property to disable hiding inactive channels. I don’t see anything in a Graph API that might disable hiding inactive channels either.

Users have the option to run the hide channel process interactively (the Hide now button).

Hide Inactive Channels and Notification Suppression

Hiding inactive channels has a side effect that users might not expect. Message center notification MC793969 (last updated 31 May 2024) covers the suppression of some notifications from hidden channels. When Teams hides a channel, it also suppresses notifications in the user activity feed for team and channel mentions, reactions, replies, and apps. The only notifications that now appear are where the user is tagged or personally mentioned.

This is a similar change to the one in MC793965 (17 May 2024) where Teams suppresses notifications for muted chats while allowing notifications for personal mentions.

The changes in MC793969 and MC793965 are both generally available. I think a fair case can be made that suppressing notifications from muted chats is perfectly acceptable because the user makes an explicit choice to mute a chat, presumably with good reason. It would be strange to want to see notifications for activities in a chat after muting it.

But muting notifications for hidden channels is a different case when some channels are hidden by users and some through an automatic process that people don’t understand well. Missing some newly-hidden channels in the channel list is easy and won’t do too much damage as it’s easy to find and unhide a channel if necessary. But it might be different if someone depends on notifications to keep track of what’s happening in a channel.

Some Tuning Required

Hiding inactive channels and suppressing notifications are part of a general Microsoft effort to make Teams a more manageable application from a user perspective. Being faced with a channel list that extends over hundreds of items can be very off-putting, as can seeing a flood of notifications in an activity feed. Removing unwanted clamor from the activity feed is a good idea. It might be even better if users had some control over whether they wanted to continue to receive notifications from channels that Teams automatically hides.

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

Continuous Access Evaluation Revokes Access Immediately

The announcement in message center notification MC884015 (5 Sept 2024) that the Microsoft 365 admin center (Figure 1) will implement continuous access evaluation (CAE) in September 2024 is very welcome. Microsoft implemented CAE for Exchange Online, SharePoint Online, and Teams in January 2022.

Implementing CAE means that the Microsoft 365 admin center can respond to critical events that occur such as user account password changes or if a connection originates from an unexpected IP address. If an administrator account is unfortunate enough to be compromised, CAE will ensure that the credentials used to access the admin center will expire immediately after the password is changed for the account or access is revoked for the account.

Speed is Key

Speed is of the essence when it comes to responding to attacks and making sure that credentials are invalidated and forcing reauthentication as soon as possible is helpful. CAE replaces older methods like waiting for an access token to expire. The problem with waiting for access tokens to age out is that unauthorized access could persist for up to an hour after the compromise occurs.

Of course, it’s even better to stop compromise by making sure that administrator accounts are protected by strong multifactor authentication such as the Microsoft administrator app or passkeys. Even though we’ve known that this is true for years, the percentage of Microsoft 365 accounts protected by multifactor authentication is still disappointing (38% in February 2024). In that context, being able to revoke access to critical administrative tools like the Microsoft 365 admin center is important.

Other Microsoft 365 Administrative Portals

The Microsoft 365 Admin Center is a headline administrative portal and it’s important that Microsoft protects it with CAE. However, this step shouldn’t be seen as bulletproof protection for a tenant because it is not. There’s no news about support for CAE in other important administrative portals like the Purview compliance portal and the Defender portal.

Although it would be good for CAE to be supported in all Microsoft 365 admin centers, the fact remains that this might not be enough to stop an attacker. As noted above, speed is key after an attacker penetrates a tenant. Waiting for a GUI slows down an attacker, who can use automated scripting using PowerShell and Graph API requests to perform actions like the creation of new accounts and permissioned apps. Firing off some scripts to infect a tenant thoroughly is a lot more efficient than using an admin center. This underlines the need to stop attackers getting into a tenant. CAE is a kind of plaster that will heal some of the damage, but it can’t stop attackers wreaking havoc if they manage to compromise an account holding administrative roles.

Continuous Access Evaluation is a Good Thing

Don’t get me wrong. I strongly endorse the implementation of Continuous Access Evaluation across the administrative landscape of Microsoft 365 tenants. Anything that slows or obstructs attackers is a good thing. Everything that complicates the process of compromise is valued.

The sad thing is that 38% figure for accounts protected by multifactor authentication reported above. Taking Microsoft’s reported figure of 400 million paid Office 365 seats, that means only 152 million accounts use multifactor authentication and almost 250 million do not. That’s just too many lucrative targets for the bad guys to go after. We need to do better.

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.

New Purview eDiscovery Due “by end of 2024”

eDiscovery is probably not where most Microsoft 365 tenant administrators spend a lot of time. Running eDiscovery cases is quite a specialized task. Often, large enterprises have dedicated compliance teams to handle finding, refining, analyzing, and understanding the material unearthed during eDiscovery together with liaison with outside legal and other expertise.

Starting with Exchange 2010, Microsoft recognized that eDiscovery was a necessity. SharePoint Server had its own eDiscovery center, and these elements moved into Office 365. In concert with their own work, Microsoft bought Equivio, a specialized eDiscovery company, in January 2015 to acquire the technology that became the eDiscovery premium solution.

Over the last few years, Microsoft has steadily added to the feature set of the eDiscovery premium solution while leaving the eDiscovery standard and content search solutions relatively unchanged. The last makeover that content search received was in 2021, and it wasn’t very successful. I thought it was slow and unwieldy. Things have improved since, but content searches have never been a great example of snappy performance and functionality, even if some good changes arrived, like the KQL query editor in 2022. (Microsoft has now renamed the keyword-based query lanuage to be KeyQL to differentiate it from the Kusto Query Language used with products like Sentinel).

Time marches on, and Microsoft has decided to revamp eDiscovery. In an August 12, 2024,announcement, Microsoft laid out its plans for the next generation of eDiscovery. The software is available in preview, but only in the new Microsoft Purview portal.

The new portal handles both Purview compliance and data governance solutions. Microsoft plans to retire the current Purview compliance portal by the end of 2024 (Figure 1). Whether that date is achieved is quite another matter. As reported below, there’s work to be done to perfect the new portal before retirement is possible.

Big Changes in the New Purview eDiscovery

Apart from a refreshed UI, the big changes include:

Rationalization of eDiscovery into a single UI. Today, Purview includes content searches, eDiscovery standard, and eDiscovery premium, each with their own UI and quirks. In the new portal, a single eDiscovery solution covers everything, with licensing dictating the functionality revealed to users. If you have an E5 license, you get premium eDiscovery with all its bells and whistles. If you have E3, you’ll get standard eDiscovery.

Better data source management: Microsoft 365 data sources span many different types of information. In the past, eDiscovery managers picked individual mailboxes, sites, and OneDrive accounts to search. A new data source picker integrates all sources

Support for sensitivity labels and sensitive information types within queries: The query builder supports looking for documents and messages that contain sensitive information types (SITs, as used by DLP and other Purview solutions) or protected by sensitivity labels. Overall, the query builder is much better than before (Figure 2).

The output of queries is handled differently too. Statistics are presented after a query runs (Figure 3), and the ability to test a sample set to determine if the query finds the kind of items that you’re looking for still exists.

Exporting query results doesn’t require downloading an app. Everything is taken care of by a component called the Process manager that coordinates the retrieval of information from the various sources where the query found hits. Everything is included in a compressed file that includes individual SharePoint files, PSTs for messages found in Exchange mailboxes, and a folder called “LooseFile” that appears to include Copilot for Microsoft 365 chats and meeting recaps.

Not Everything Works in the New Purview eDiscovery

Like any preview, not everything is available in the software available online. For instance, I could not create a query based on sensitivity labels. More frustratingly, I could find no trace of content searches in the new interface, despite Microsoft’s assertion that “users still have access to all existing Content Searches and both Standard and Premium eDiscovery cases on the unified eDiscovery case list page in the Microsoft Purview portal.” Eventually and after originally posting this article, a case called Content Searches appeared at the bottom of the case list. Navigating to the bottom of a case list (which could be very long) isn’t a great way to find content searches and it seems unnecessarily complicated. Perhaps a dedicated button to open content searches would work better?

Many administrators have created content searches in the past to look for data. For instance, you might want to export selective data from an inactive mailbox. In the new eDiscovery, content searches are created as standard eDiscovery cases, a change that Microsoft says improves security control by allowing the addition or removal of users from the case. Given that I have 100+ content searches in one case, I think that the new arrangement overcomplicates matters (how can I impose granular security on any one of the content searches if they’re all lumped together into one case?). It’s an example of how the folks developing the eDiscovery solution have never considered how tenant administrators use content searches in practice.

Interestingly, Microsoft says that the purge action for compliance searches can now remove 100 items at a time from an Exchange mailbox. They mention Teams in the same sentence, but what this really means is that the purge can remove compliance records for Teams from the mailbox that later synchronize with Teams clients to remove the actual messages.

Much More to Discover

Leaving aside the obvious pun, there is lots more to investigate in the new eDiscovery. If you are an eDiscovery professional, you’ll be interested in understanding how investigations work and whether Copilot (Security and Microsoft 365) can help, especially with large review sets. If you’re a tenant administrator, you should make sure that you understand how content searches and exports work. Microsoft has an interactive guide to help, but more importantly, we will update the eDiscovery chapter in the Office 365 for IT Pros eBook once the new software is generally available.

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

And Why You Might Need to Change Account to Attend a Teams Meeting

Earlier this week I discussed a change made in how Teams copies text from messages that reduces user irritation. Let me balance the books by explaining a different aspect of Teams that continues to vex me.

I’m waiting to be accepted into a Teams meeting and wondering why I’m forced to wait in the lobby. I know that the organization wants people to use their guest accounts when attending meetings because of concerns about data leakage, so it’s annoying to have to twiddle my thumbs in the virtual lobby as the minutes tick by. And then the answer strikes: I’m attempting to join the meeting using my account rather than a guest account. After exiting, I rejoin after selecting my guest identity and enter the meeting without pausing in the lobby.

The UI to Change User Accounts

All of this happens because of what seems to be a major (to me) UI flaw in Teams. Figure 1 is the screen that appears when attempting to join a Teams meeting in a host tenant. By default, the user account from the home tenant is selected. If other accounts are available, the Change option appears to allow the user to select a different account. Teams knows if you have a guest account for the host tenant because it is listed under Accounts and Orgs in Teams settings.

You can switch to the account by selecting it from the list (Figure 2).

Because the meeting is limited to tenant and guest accounts, a connection request using the guest account sails through without meeting any lobby restrictions.

I can appreciate what the Teams UI designers were trying to do when they placed the Change button on the dialog. It makes sense to offer users the choice to switch accounts. The problem is that the option is just a tad too subtle and that leads to it being overlooked. I know I am not the only one in this situation because it has happened to a bunch of people who might know better.

Managing Access to Confidential Calls

MVPs are members of the Microsoft Most Valuable Professional program. Part of the benefits of being an MVP are product briefings about new features or plans that Microsoft has to improve their software, including Teams. All such briefings are under a strict Non-Disclosure Agreement (NDA) and people are required to join meetings using the guest account created for them by Microsoft. The restriction is enforced by the lobby setting for meetings to allow tenant accounts and guests to bypass the lobby. It is a reasonable restriction because Microsoft needs to know who they’re talking to, and a guest account is a good indication that an external person has been vetted for access to a tenant.

I commonly attend several product briefings each week. And on a regular basis, I fail to switch to my guest account before attempting to join calls. The result is that I spend time waiting in the lobby thinking that it would be nice if someone started the call soon before I realize what’s going on or a presenter recognizes my name in the lobby and lets me in. I’ve been known to become distracted while waiting to be admitted from the lobby and miss the entire call.

Automatic Switching Would Help

Teams knows what the meeting setting is for lobby bypass. It knows if the person joining a call can bypass the lobby with one or more accounts. It would be terrific if Teams could apply some intelligence to the situation and prompt the user to change if their current account can’t bypass the lobby. I might make more calls then.

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.

Automatic Document Summary in a Bulleted List

Last week, I referenced the update for Word where Copilot for Microsoft 365 generates an automatic summary for documents. This is covered in message center notification MC871010 (Microsoft 365 roadmap item 399921). Automatic summaries are included in Copilot for Microsoft 365 and Microsoft Copilot Pro (the version that doesn’t ground prompts using Graph data).

As soon as I published the article where I referred to the feature, it turned up in Word. Figure 1 shows the automatic summary generated for a document (in this case, the source of an article).

The summary is the same output as the bulleted list Copilot will generate if you open the Copilot pane and ask Copilot to summarize this doc. Clicking the Ask a question button opens the Copilot pane with the summary prepopulated ready for the user to delve deeper into the summary.

The summary is only available after a document is saved and closed. The next time someone opens the document, the summary pane appears at the top of the document and Copilot generates the summary. The pane remains at the top of the document and doesn’t appear on every page. If Copilot thinks it necessary (for instance, if more text is added to a document), it displays a Check for new summary button to prompt the user to ask Copilot to regenerate the summary.

Apart from removing the Copilot license from an account (in which case the summaries don’t appear), there doesn’t seem to be a way to disable the feature. You can collapse the summary, but it’s still there and can be expanded at any time.

Summarizing Large Word Documents

When Microsoft launched Copilot support for Word, several restrictions existed. For instance, Word couldn’t ground user prompts against internet content. More importantly, summarization could only handle relatively small documents. The guidance was that Word could handle documents with up to 15,000 words but would struggle thereafter.

This sounds a lot, and it’s probably enough to handle a large percentage of the documents generated within office environments. However, summaries really come into their own when they extract information from large documents commonly found in contracts and plans. The restriction, resulting from the size of the prompt that could be sent to the LLM, proved to be a big issue.

Microsoft responded in in August 2024 with an announcement that Word could now summarize documents of up to 80,000 words. In their text, Microsoft says that the new limit is four times greater than the previous limit. The new limit is rolling out for desktop, mobile, and browser versions of Word. For Windows, the increased limit is available in Version 2310 (Build 16919.20000) or later.

Processing Even Larger Word Documents

Eighty thousand words sounds a lot. At an average of 650 words per page, that’s 123 pages filled with text. I wanted to see how Copilot summaries coped with larger documents.

According to this source, the maximum size of a text-only Word document is 32 MB. With other elements included, the theoretical size extends to 512 MB. I don’t have documents quite that big, but I do have the source document for the Office 365 for IT Pros eBook. At 1,242 pages and 679,800 characters, including many figures, tables, cross-references, and so on, the file size is 29.4 MB.

Copilot attempted to generate a summary for Office 365 for IT Pros but failed. This wasn’t surprising because the file is so much larger than the maximum supported.

The current size of the Automating Microsoft 365 with PowerShell eBook file is 1.72 MB and spans 113,600 words in 255 pages. That’s much closer to the documented limit, and Copilot was able to generate a summary (Figure 2).

Although the bulleted list contains information extracted from the file, it doesn’t reflect the true content of the document because Copilot was unable to send the entire file to the LLM for processing. The bulleted list comes from the first two of four chapters and completely ignores the chapters dealing with the Graph API and Microsoft Graph PowerShell SDK.

Summaries For Standard Documents

Microsoft hasn’t published any documentation that I can find for Copilot’s automatic document summary feature. When it appears, perhaps the documentation will describe how to disable the feature for those who don’t want it. If not, we’ll just have to cope with automatic summaries. At least they will work for regular Word documents of less than 80,000 words.

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.

Who Thought that Including Metadata in Teams Pasted Text Was a Good Idea?

In an example of finally listening to user feedback, Microsoft announced in MC878422 (30 August 2024) that Teams no longer includes metadata in messages copied from chats or channel conversations. The change is effective now and means that instead of having Teams insert a timestamp and the name of the person who created the text, only the text is pasted. This is exactly the way the feature should have worked since day zero. Quite why anyone thought it was a good idea to insert additional information into copied text is one of the great mysteries of Teams development.

MC878422 notes: “Many users have voiced frustrations over copying messages in Teams, particularly the inclusion of metadata like names and timestamps. Customer feedback has been clear, signaling that this feature was adding more noise than value to user workflow.”

Copying Metadata is An Old Lync Feature

It seems likely that inserting the timestamp and author name is an idea that came to Teams from Lync Server 2013 and Skype for Business. A support article from the time describes how to change the default setting of copying message, name, and time to copying just the message. Nearly eight years after Teams entered preview in November 2016, the opportunity to update a setting as in Lync Server 2013 never appeared. The net result is that Teams users had to manually remove the unwanted metadata from copied text after pasting it into another app. Thankfully, the change “helps maintain focus and reduces unnecessary noise.”

I’ve no idea about how many of the 320 million monthly active Teams users found this aspect of the product annoying, but it’s been high up on my list along with in-product advertising and a constant stream of irritating pop-up messages.

Mic Pending is a Feature You Probably Never Knew Exists

In a more positive note, Juan Rivera, Corporate Vice President @ Microsoft. Teams Calling, Meetings & Devices Engineering posted on LinkedIn about a feature called Mic Pending state, which apparently is now rolled out to all tenants.

I have never thought much about the process required to implement the mute/unmute button in a call, but apparently Microsoft has done the work to make sure that when users hit the mic button (Figure 1), the action occurs immediately. If something gets in the way to prevent mute/unmute happening, Teams displays a “pending” icon if it notices that the action has taken more than 100 milliseconds.

The issue being addressed is to make sure that people have confidence that Teams will mute their microphone immediately they press the button and unmute the microphone in a similarly effective manner. It seems like some folks have been caught by a delay in muting. The button displayed in a Teams meeting showed that the microphone was off when it was still live. You can see how this could end up with something being heard or captured on a Teams recording that people would have preferred not to have been captured. Calling your boss a flaming idiot over an open microphone that you thought was muted is possibly not a good thing to do.

According to the post, Microsoft believe that Teams delivers 99.99+% reliability for the mute/unmute toggle, which should mean that the status for the microphone shown on screen can be trusted. Of course, the paranoid amongst us will always give a microphone two or three seconds before we consider it to be truly off.

Two Good Changes

The one thing about Teams is that it’s always changing. People like the Office 365 for IT Pros writing team have no shortage of topics to cover when it comes to Teams. Thankfully, the two topics covered here are both positive, even if mic pending hasn’t come to our attention before.

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.

The Graph SDK’s ToJsonString Method Proves Its Worth

One of the frustrations about using the internet is when you find some code that seems useful, copy the code to try it out in your tenant, and discover that some formatting issue prevents the code from running. Many reasons cause this to happen. Sometimes it’s as simple as an error when copying code into a web editor, and sometimes errors creep in after copying the code, perhaps when formatting it for display. I guess fixing the problems is an opportunity to learn what the code really does.

Answers created by generative AI solutions like ChatGPT, Copilot for Microsoft 365, and GitHub Copilot compound the problem by faithfully reproducing errors in its responses. This is no fault of the technology, which works by creating answers from what’s gone before. If published code includes a formatting error, generative AI is unlikely to find and fix the problem.

Dealing with JSON Payloads

All of which brings me to a variation on the problem. The documentation for Graph APIs used to create or update objects usually include an example of a JSON-formatted payload containing the parameter values for the request. The Graph API interpret the JSON content in the payload to extract the parameters to run a request. By comparison, Microsoft Graph PowerShell SDK cmdlets use hash tables and arrays to pass parameters. The hash tables and arrays mimic the elements of the JSON structure used by the underlying Graph APIs.

Composing a JSON payload is no challenge If you can write perfect JSON. Like any other rules for programming or formatting, it takes time to become fluent with JSON, and who can afford that time when other work exists to be done? Here’s a way to make things easier.

Every object generated by a Graph SDK cmdlet has a ToJsonString method to create a JSON-formatted version of the object. For example:

$User = Get-MgUser -UserId Kim.Akers@office365itpros.com
$UserJson = $User.ToJsonString()

$UserJson
{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users/$entity",
  "id": "d36b323a-32c3-4ca5-a4a5-2f7b4fbef31c",
  "businessPhones": [ "+1 713 633-5141" ],
  "displayName": "Kim Akers (She/Her)",
  "givenName": "Kim",
  "jobTitle": "VP Marketing",
  "mail": "Kim.Akers@office365itpros.com",
  "mobilePhone": "+1 761 504-0011",
  "officeLocation": "NYC",
  "preferredLanguage": "en-US",
  "surname": "Akers",
  "userPrincipalName": Kim.Akers@office365itpros.com
}

The advantages of using the ToJsonString method instead of PowerShell’s ConvertTo-JSON cmdlet is that the method doesn’t output properties with empty values. This makes the resulting output easier to review and manage. For instance, the JSON content shown above is a lot easier to use as a template for adding new user accounts than the equivalent generated by ConvertTo-JSON.

Transferring a Conditional Access Policy Using ToJsonString

The output generated by ToJsonString becomes very interesting when you want to move objects between tenants. For example, let’s assume that you use a test tenant to create and fine tune a conditional access policy. The next piece of work is to transfer the conditional access policy from the test tenant to the production environment. Here’s how I make the transfer:

• Run the Get-MgIdentityConditionalAccessPolicy cmdlet to find the target policy and export its settings to JSON. Then save the JSON content in a text file.

$Policy = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId '1d4063cb-5ebf-4676-bfca-3775d7160b65'
$PolicyJson = $Policy.toJsonString()
$PolicyJson > PolicyExport.txt

• Edit the text file to replace any tenant-specific items with equivalent values for the target tenant. For instance, conditional access policies usually include an exclusion for break glass accounts, which are listed in the policy using the account identifiers. In this case, you need to replace the account identifiers for the source tenant in the exported text file with the account identifiers for the break glass account for the target tenant.
• Disconnect from the source tenant.
• Connect to the target tenant with the Policy.ReadWrite.ConditionalAccess scope.
• Create a variable ($Body in this example) containing the conditional policy settings.
• Run the Invoke-MgGraph-Request cmdlet to import the policy definition into the target tenant.

$Uri = "https://graph.microsoft.com/v1.0/identity/conditionalAccess/policies"
Invoke-MgGraphRequest -uri $uri -method Post -Body $Body

The Other Way

Another way to create a conditional access policy with PowerShell is to run the New-MgIdentityConditionalAccessPolicy cmdlet, which takes a hash table as its payload. It’s easy to translate the JSON into the format used for parameter values stored in the hash table, but it’s even easier to run Invoke-MgGraphRequest and pass the edited version of the JSON exported from the source tenant. Why make things hard for yourself?

This tip is just one of the hundreds included the Automating Microsoft 365 with PowerShell eBook (available separately, as part of the Office 365 for IT Pros (2025 edition) bundle, or as a paperback from Amazon.com).

Monthly Update #111 for Office 365 for IT Pros eBook

The Office 365 for IT Pros eBook team is delighted to announce that files are available for download for the September 2024 update of:

• Office 365 for IT Pros (2025 edition) in PDF and EPUB formats.
• Automating Microsoft 365 with PowerShell in PDF and EPUB formats.

Automating Microsoft 365 with PowerShell is available as part of the Office 365 for IT Pros bundle and as a separate product.

Subscribers can download the updates files using the link in the receipt emailed to them after their original purchase or from the library in their Gumroad.com account. We no longer make a Kindle version of the Office 365 for IT Pros eBook available through Amazon. It proved too difficult to release updates to readers through the convoluted Amazon process. The Automating Microsoft 365 with PowerShell book is available through Amazon in Kindle and paperback versions. The paperback is our first attempt at delivering a printed book and the response has been interesting. I guess some folk still like to have text on paper as a reference.

See our change log for information about the changes in the September 2024 update and our FAQ for details about how to download updates.

Changes in the Ecosystem

To ensure that the book content is updated and remains current, we spend a lot of time tracking change within the Microsoft 365 ecosystem. Three issues that are causing people some concerns are:

• Microsoft plans to require accounts that connect to Azure administrative portals, like the Azure portal, Entra admin center, and Intune admin center or use the Azure PowerShell module and Cl, to use multifactor authentication. The requirement swings into force on October 15. In many respects, this is an excellent idea because the only accounts that access these sites are by definition administrators and all administrator accounts should be protected. But people assume that Microsoft will force all accounts to use MFA and that’s just not correct. More information is available here.
• This month Microsoft plans to update Exchange Online with a revised SMTP AUTH Clients submission report to help organizations understand if apps and devices are using SMTP AUTH with basic authentication to submit messages to Exchange. The plan is to remove basic authentication for SMTP AUTH in September 2025, and the signs are that some organizations will struggle with this deadline as they do not know how to upgrade hardware (devices like multifunction printers) or apps to support OAuth. Follow the discussion online and if you have concerns, voice them there. Ian McDonald from the Exchange development group is responding to queries as they arise.
• The new Outlook for Windows is generally available, and Microsoft is renaming the older Win32 version to be Outlook (classic). The rename process for the application is starting around now. Microsoft still plans to support Outlook classic until 2029 at the earliest so there’s no cause for immediate concern. The new Outlook is not ready to take over from Outlook classic yet and won’t be for several years. But it is the case that new functionality will increasingly be only available in the new Outlook (and likely OWA), and that’s something to take into consideration as Microsoft 365 tenants plan their client strategy for the coming years.

Other stuff is happening too – and all the time- but these are three of the big issues I hear discussed on an ongoing basis.

Discounted Subscriptions

We have traditionally allowed subscribers of prior editions to continue their subscriptions to cover new edition at discounted rates. The cheapest way to upgrade is always within three weeks of the release of a new edition. After that, we start to gradually reduce the discount. Our discount period finished today and there are no longer general discounts available for previous subscribers. Instead, we’re reaching out to people who have supported us over several editions to offer targeted discounts. We think this is a fairer approach to reward people who have helped us and to control the misuse of discount codes.

We know of about 70 cases where people who have never subscribed before having taken out subscriptions to the 2025 edition using codes that we made available to previous subscribers. Sometimes this happens because people pass their subscription to co-workers and sometimes it’s because people just like to share. In any case, our ability to offer discounted subscriptions is compromised when codes are misused, so we’re going to be a little more restrictive about how we issue discounts. I don’t think anyone’s doing anything particularly horrible here, but we’d like to take care of the folks who support us before anyone else gets the chance to use a discount.

On to Update #112

There’s no rest for the wicked and the Office 365 for IT Pros team is already working (or so they tell me) on update #112, which we anticipate releasing on October 1. No doubt lots will happen between this and then to add to the rich tapestry of life and the joys (!!!) of coping with constant change inside the Microsoft 365 ecosystem.

Copilot Catch Up Fails to Impress

On August 28. 2024, Microsoft posted a revision to message center notification MC799636 (Microsoft 365 roadmap item 388746) to announce their decision to completely roll back their deployment of the new “catch up” feature for Copilot for Microsoft 365 and Teams.  The roll back operation will start on September 2. Previously, the feature was supposed to reach general availability in early August 2024.

According to Microsoft, the deployment had reached 50% of users. These are eligible accounts with Copilot for Microsoft 365 licenses. Given that many large enterprises have committed to Copilot for Microsoft 365, the number of affected users might be in the low several million range.

The Black Box of Card Determination

The blurb for the Copilot catch up feature says that it “helps users [to] take action on important updates.” In other words, Copilot had found something it deemed of interest to the signed-in user and brought the item to their attention in a series of cards that rotated through a carousel. In my case, the feature only turned up a couple of days ago. Figure 1 shows what I see. The three cards cover a Word document (chapter 2 for the Office 365 for IT Pros eBook), a calendar invitation, and a Loop workspace.

Like many elements of artificial intelligence, the process to determine what cards to display is a black box. Looking at the cards chosen by Copilot, I can see the logic of selecting the Word document because it’s a reminder that its content has changed, and I need to review the updates. The meeting is probably there because it happens later today. To help me prepare, Copilot found an email sent about a Teams service outage which frankly is of zero relevance to the meeting. The sole connection is that the word Teams appears in the subject for both the meeting invitation and email. The selection reminds me of “I must find something” instead of “I must find something useful.” I can’t account for why Copilot chose the Loop workspace because nothing has happened in it for months. Perhaps Copilot Catch Up wanted to be diverse in its choice of application sources.

I don’t think I shall miss the carousel. It seems like a modern take on the many ways that Office apps suggest documents to users or the way that the now-deprecated Delve highlights documents to users. The Viva Insights for email feature available in Outlook clients is another example of how Microsoft seeks to extract value from user data to highlight “things to do.”

Automatic Document Summaries by Copilot for Microsoft 365

The list key points link on the card for the Word document (Figure 2) appears to do what I expect to see when Microsoft deploys message center notification MC871010 (Microsoft 365 roadmap item 399921), scheduled for late August. This update promises that Copilot “will generate a summary in the window at the top of the Word document.”

MC866152 (23 August 2024) also covers the same ground for Microsoft Copilot (the version that doesn’t use the Graph).

I have some problems with the idea of generating automatic summaries because I fear it might slow down the opening of large documents based on the current performance in the Copilot chat app. It seems like a terrific demo feature that works well for 2-page documents. I can’t imagine how it will cope with the 1,300 pages of the Office 365 for IT Pros eBook source file. MC866452 says that the summary window can be collapsed to hide it. There’s no detail about what I really want to do, which is to disable automatic summaries for all Word documents.

Copilot Can’t do Everything

Figuring out what features will really be interesting and useful is an aspect of software engineering that is often very difficult. Sometimes I think Microsoft tries too hard, tries to be too clever, or utterly fails to understand how people outside Microsoft work. Applying artificial intelligence to as many aspects of Microsoft 365 as possible is madness, even if it keeps senior management happy.

The truth is that not every idea discussed around a conference table in Redmond or virtually in a Teams call is valuable. Sometimes it takes exposure in the harsh light of reality to figure out what works and what doesn’t. The demise of Copilot catch up is a reminder to us all that just because a new feature appears, its value needs to be assessed in terms of how it contributes to the success of the business.

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.

Critical Need to Update Scripts Using PnP PowerShell Before September 9 2024

On August 21, 2024, the Pattern and Practices (PnP) team announced a major change for the PnP PowerShell module. To improve security by encouraging the use apps configured with only the permissions needed to process data within the tenant, the PnP PowerShell module is moving away from the multi-tenant Entra app (the PnP Management Shell, application identifier 31359c7f-bd7e-475c-86db-fdb8c937548e) used up to this point to require tenants to register a unique tenant-specific app for PnP.

Reading between the lines, the fear is that attackers will target the current PnP multi-tenant app and attempt to use it to compromise tenants. The multi-tenant app holds many Graph API permissions (Figure 1) together with a mixture of permissions for Entra ID, SharePoint Online, and the Office 365 service management API. Being able to gain control over such an app would be a rich prize for an attacker.

Swapping out one type of Entra app for another might sound innocuous, but it means that the sign-in command for PnP in every script must be updated. The PnP team will remove the current multi-tenant app on September 9, 2024, so any script that isn’t updated will promptly fail because it cannot authenticate. That’s quite a change.

The Usefulness of PnP PowerShell

I don’t use PnP PowerShell very often because I prefer to use Graph APIs or the Microsoft Graph PowerShell SDK whenever possible. However, sometimes PnP just works better or can perform a task that isn’t possible with the Graph. For instance, creating and populating Microsoft Lists is possible with the Graph, but it’s easier with PnP. SharePoint’s support for Graph APIs is weak and PnP is generally a better option for SharePoint Online automation, such as updating site property bags with custom properties (required to allow adaptive scopes to identify SharePoint Online sites). Finally, I use PnP to create files in SharePoint Online document libraries generated as the output from Azure Automation runbooks.

Creating a PnP Tenant Application

The first thing to do is to download the latest version of the PnP PowerShell module (which only runs on PowerShell 7) from the PowerShell Gallery. The maintainers update the module regularly. I used version 2.9.0 for this article.

The easiest way to create a tenant-specific application for PnP PowerShell is to run the Register-PnPEntraIDApp cmdlet:

Register-PnPEntraIDApp -ApplicationName "PnP PowerShell App" -Tenant office365itpros.onmicrosoft.com -Interactive

Make sure that you sign in with an account that has global administrator access. The cmdlet creates an Entra ID app and populates the app with some default properties, including a default set of Graph API permissions and a self-signed certificate for authentication. It doesn’t matter what name you give the app because authentication will use the unique application identifier (client id) Entra ID creates for the new app. The user who runs the cmdlet must be able to consent for the permissions requested for the app (Figure 2).

The Graph permissions allow read-write access to users, groups, and sites. Other permissions will be necessary to use PnP PowerShell with other workloads, such as Teams. Consent for these permissions is granted in the same way as for any other Entra ID app. Don’t rush to grant consent for other permissions until the need is evident and justified.

Using the Tenant App to Connect to PnP PowerShell

PnP PowerShell supports several ways to authenticate, including in Azure Automation runbooks. Most of the examples found on the internet show how to connect using the multi-tenant application. To make sure that scripts continue to work after September 9, every script that uses PnP PowerShell must be reviewed to ensure that its code works with the tenant-specific application. For instance, a simple interactive connection looks like this:

Connect-PnPOnline -Url https://office365itpros.sharepoint.com -ClientId cb5f363f-fbc0-46cb-bcfd-0933584a8c57 -Interactive

The value passed in the ClientId parameter is the application identifier for the PnP PowerShell application.

Azure Automation requires a little finesse. In many situations, it’s sufficient to use a managed identity. However, if a runbook needs to add content to a SharePoint site, like uploading a document, an account belonging to a site member must be used for authentication. This example uses credentials stored as a resource in the automation account executing the runbook.

$SiteURL = "https://office365itpros.sharepoint.com/sites/Office365Adoption"
# Insert the credential you want to use here... it should be the username and password for a site member
$SiteMemberCredential = Get-AutomationPSCredential -Name "ChannelMemberCredential"
$SiteMemberCredential
# Connect to the SharePoint Online site with PnP
$PnpConnection = Connect-PnPOnline $SiteURL -Credentials $SiteMemberCredential -ReturnConnection -ClientId cb5f363f-fbc0-46cb-bcfd-0933584a8c57

[array]$DocumentLibraries = Get-PnPList -Connection $PnpConnection | Where-Object {$_.BaseType -eq "DocumentLibrary"}
 
# Display the name, Default URL and Number of Items for each library
$DocumentLibraries | Select Title, DefaultViewURL, ItemCount

Ready, Steady, Go…

September 9 is not too far away, so the work to review, update, and test PnP PowerShell scripts needs to start very soon (if not yesterday). Announcing a change like this 19 days before it happens seems odd and isn’t in line with the general practice where Microsoft gives at least a month’s notice for a major change. I imagine that some folks coming back from their vacations have an unpleasant surprise lurking in their inboxes…

Ability to Restore Deleted Groups Depends on Graph APIs

Yesterday, I covered a gap that exists between the Purview development group and the Exchange Online development group when it comes to applying scoped roles to audit log searches. Today, a blog post by ex-MVP Tony Murray-Smith reminds me about another functionality gap that exists in the area of groups. The problem described occurred when a user deleted a security group by mistake only to discover that the Entra admin center doesn’t support a method to restore deleted groups of this type.

In fact, Microsoft 365 groups are the only type of group that Entra supports for restoration via its admin center. There’s no way to restore a deleted distribution list, dynamic distribution list, security group, or mail-enabled security group. Apart from dynamic distribution lists, these objects are recognized by Entra ID and accessible through the Groups API. However, the only group objects supported by the List Deleted Items and Restore Deleted Items (directory objects) APIs remain Microsoft 365 groups. And if a Graph API isn’t available to support restoration, the administrative portals cannot create functionality from thin air.

This situation has persisted since the introduction of cmdlets to restore deleted Microsoft 365 groups in 2017 followed by a GUI option in the Exchange admin center, Microsoft 365 admin center, and Entra admin center. Microsoft subsequently removed the option to restore deleted groups from the new EAC, so the current GUI-based options to restore deleted Microsoft 365 groups are in the Entra admin center and Microsoft 365 admin center. And if you want to use PowerShell, there’s the Restore-MgDirectoryDeletedItem cmdlet.

The Gap Between the Exchange DS and Entra ID

The question is why Entra ID only supports the restoration of Microsoft 365 groups. I think the answer lies in two parts. First, the desire within Microsoft to make its brand-new cloud-only Office 365 groups (now Microsoft 365 groups) the “best group for everything” following their launch at the Ignite conference in May 2015.

The infrastructure to fully support Microsoft 365 groups took time to develop, and building the capability to reconnect all the different resources that a group might use made the process more complicated for Microsoft 365 groups. Being able to restore SharePoint Online, Teams, the group mailbox, and so on was a big undertaking that Microsoft quickly discovered needed to be tackled after the launch of Office 365 groups, especially after some early customers discovered that they couldn’t be restored. The functionality duly arrived in 2017. The campaign to make Microsoft 365 groups do everything is far less intense now than it was some years ago, but its legacy is evident sometimes.

The EXODS Objects

The second issue is heritage. Distribution lists and mail-enabled security groups originated in Exchange Server. Exchange Online still has its own directory (EXODS) to store details for mail-enabled objects. Synchronization and dual-write update operations keep Entra ID and EXODS aligned so that updates performed in one directory synchronize immediately to the other. The Graph APIs support distribution lists and security groups, including mail-enabled security groups, but Entra ID and the Graph APIs ignore dynamic distribution lists and can’t update settings for distribution lists and mail-enabled security groups because these objects are homed within Exchange Online.

Good reasons exist for why the differentiation exists. Dynamic distribution lists require Exchange Online to resolve their membership because the membership supports objects like mail-enabled public folders that don’t exist in Entra ID. Dynamic distribution lists also support nested lists. Regular distribution lists and their mail-enabled security group variants have many settings that aren’t supported in Entra ID, like message approval.

As far as I can remember, it has never been possible to restore deleted distribution lists (and some of the online answers are very misleading, like this example). Once an administrator removes a distribution list, it’s gone. The only thing that can be done is to recreate the distribution list from scratch. That might be possible if someone knows the membership and the list settings, but that might not be the case.

Some Work Necessary in This Area

Microsoft should do some work to make it possible to restore all forms of deleted groups. That work will need contributions from teams responsible for Entra ID, the Graph API, and Exchange Online. Mistakes do happen and administrators remove important distribution lists or mail-enabled security groups when they shouldn’t. Being told that it’s necessary to recreate an object from scratch is a royal pain, and it’s something that shouldn’t still be a problem in 2024. Customers assume that if they can restore one type of deleted group, they should be able to restore any type of deleted group.

Then again, other pains exist around distribution list management, like the Microsoft’s failure to produce a utility to move distribution lists from on-premises servers to the cloud. Tim McMichael’s DLConversionV2 solution is the best available. He’ll be discussing distribution list management at TEC 2024 in Dallas in October. Maybe I should ask Tim about restoring groups that aren’t Microsoft 365 groups.

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

Purview and Exchange Online Disagree about Scoped Audit Log Searches

Like many Purview solutions, audit log searches support scoping using Entra administrative units. In other words, an account holding the Audit Manager Purview role scoped for a specific administrative unit is only able to find audit records linked to the administrative unit. An account can be scoped to manage a single or multiple administrative units. Alternatively, the scope assigned to an account can be “Organization,” meaning that the role applies to all audit events created in the tenant. Figure 1 shows that two accounts hold organization scopes for the Audit Manager role while another is scoped for a single administrative unit.

Administrative unit support for Purview scoped audit log searches has been available since November 2023.

Audit Records and Administrative Units

Each audit record is tagged with the user account or service principal responsible for the logged action. If a user account belongs to an administrative unit, the audit event captures the identifier of the administrative unit in an array called AssociatedAdminUnits in the audit payload. If the account belongs to multiple administrative units, the audit record captures the identifiers of all the administrative units. Capturing administrative unit details in audit records is what makes scoping possible.

For example, this code fetches the audit payload from an audit record and converts it from JSON before looping through the administrative unit identifiers to return the display name for each administrative unit:

$AuditData = $Records[0].Auditdata | ConvertFrom-JSON

ForEach ($AU in $Auditdata.AssociatedAdminUnits) {
  $AUName = Get-MgDirectoryAdministrativeUnit -AdministrativeUnitId $AU.toString() | Select-Object -ExpandProperty DisplayName
  Write-Host ("Found administrative unit {0} ({1})" -f $AUName, $AU)
}

Found administrative unit Ireland (112f5e71-b430-4c83-945b-8b665c14ff25)

Limiting Audit Log Searches with Administrative Units

When a user with a scoped Audit Manager role signs into the Purview Compliance portal to run an audit log search, they can select one or multiple of the administrative units they are scoped to manage for the search (Figure 2).

Purview audit log searches only return audit records matching the selected administrative units. It’s easy to validate that this is so by checking that audit records returned by the search have the identifiers for the selected administrative unit(s) in their properties (Figure 3).

Inconsistent Scoping

Administrative unit scoping works for audit log searches performed through the Purview compliance portal and with the AuditLog Query Graph API. However, despite almost a year lapsing since the introduction of scoping for audit log searches, the Purview scopes don’t work for searches performed using the Search-UnifiedAuditLog cmdlet.

This is an odd situation. Despite Microsoft’s sometimes unexplained messing with the Search-UnifiedAuditLog cmdlet, it remains a very significant and popular way to run audit log searches. However, the Search-UnifiedAuditLog cmdlet is part of the Exchange Online Management PowerShell module. The Exchange Online cmdlets use Exchange Role Based Access Control (RBAC) to limit their functionality and apply scoping and non-administrator accounts must be enabled to use the Exchange Online Management PowerShell module.

The requirements to use the Search-UnifiedAuditLog cmdlet are obviously very different to those needed to run Purview audit log searches. The mechanisms used also differ. Search-UnifiedAuditLog are synchronous, and the results are usually available much quicker than Purview searches (unless you use the high completeness option). Both Purview searches and those run using the Graph AuditLog Query API submit background jobs to find audit records. Depending on the number of records found by a search, audit results aren’t usually available for at least 10 minutes and can take far longer.

It’s odd that Microsoft allows a situation to persist where the scoping mechanisms used by Exchange Online and Purview are unsynchronized. The likely explanation is that two different engineering teams are involved who haven’t yet figured out how to implement common scoping behavior. It seems like this is a problem that should be well within the capability of the world’s largest software company, but logic doesn’t always hold true when different teams have different priorities in large organizations.

The net outcome is that inconsistent scoping for audit log searches creates the potential for inadvertent PII disclosure in customer tenants. It also means that managing scoped access to data is more difficult than it should be. Both are unacceptable when it comes to access to audit data. Let’s hope that Microsoft fixes this issue soon.

Keep up to date with developments like those affecting scoped audit log searches by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Identify Problematic Shared Mailboxes using Sign-in Logs

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

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

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

No Need Exists to Sign Into Shared Mailboxes

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

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

Microsoft documentation says:

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

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

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

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

Checking for Illegal Shared Mailboxes

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

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

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

Other Checks

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

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

But Advanced Collaboration Analytics Remains a Teams Premium Feature

According to message center notification MC862237 (14 August 2024), Microsoft plans to update the External domain activity report that’s available through the Reports section and the Collaboration activity dashboard in the Teams admin center. This report is designed to allow tenant administrators to know which domains users communicate with and which users are communicating externally. It’s good knowledge to have because it allows an organization to more accurately configure external access for Teams.

Default Open Access for Collaboration

The default state of external access for Teams allows federated communications with any other Microsoft 365 tenant that runs Teams. According to the last Microsoft numbers, Teams has 320 million monthly active users out of 400 million Office 365 “paid seats,” so allowing open external access essentially means that a tenant allows users to communicate with any other Microsoft 365 tenant.

Given the current state of cyberthreat, maintaining open communications of this nature is an unreachable state of utopia. The GIFShell exploit in 2012 proved the basics of how an attacker might compromise a target account using federated Teams chat. Tenants should configure an external access allow list composed of other domains that they’re willing to communicate with. It’s just too easy for attackers to spin up a tenant, add a Teams license, and start to probe (Teams began to block federated collaboration with trial tenants from July 29, 2024).

The New External Domain Activity Report has More Detail

Microsoft plans to roll out the updated report in September 2024. The update can’t come soon enough because the current report is devoid of detail. Only users with Teams Premium licenses appear, which accounts for the rather sparse content from my tenant (Figure 1).

Microsoft says that the new report will include:

• Total chat messages exchanged between each external domain and your tenant.
• Number of chat messages sent by each external domain to your tenant.
• The list of users from your tenant that communicate with each external domain.
• For each user, the number of chat messages sent between each external domain and the user, and the number of messages sent by that user to the external domain.

Nice as the new report will be, it’s regrettable that this kind of information is restricted to Teams Premium. According to the latest Microsoft results, Teams Premium represents about 3 million users, or less than 1 percent of the installed base. At $10 per user per month (a $7 introductory price is available until December 31, 2024), Microsoft obviously wants to drive that percentage higher. However, this kind of fundamental information is important for tenant security and should be available to all.

Including the report in Advanced Collaboration Analytics grants the report a status it simply doesn’t have. Other items shown in the collaboration activity dashboard (Figure 2), like noting the domains in the external access allow list that haven’t been used in the last 60 days, are much more worthy of the designation.

Like other reports generated from Graph usage data, the cards in the collaboration activity dashboard that include user or team names respect the privacy control setting. Unlike the Microsoft 365 admin center, which obfuscates private data if the privacy control is set, the Teams admin center simply doesn’t display data.

DIY Analytics

If you don’t want to pay for Teams Premium but would like to generate some of the same analyses that Microsoft include in Advanced Collaboration Analytics, it’s possible to do so with PowerShell or Graph API requests. As an example, this article describes how to create an external access allow list by analyzing federated chat messages using the Microsoft Graph PowerShell SDK. Once the basic data is generated, it can be sliced and diced in different ways.

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.

Understand Why Unlicensed OneDrive Accounts Exist

At the end of July, I reported Microsoft’s plan to charge for unlicensed OneDrive for Business accounts. The idea is simple. Ninety days after a OneDrive for Business account enters an unlicensed state, SharePoint Online will move the account into Microsoft 365 Archive. The tenant must then decide what to do with the accounts with the options being to manage the accounts or leave accounts to rot in the archive. Unlicensed accounts arise when an account no longer has access to a service plan for OneDrive (see the product names and service plans reference). Usually, an account enters the unlicensed state for OneDrive when an administrator deletes an account or removes a license like Office 365 E3 or E5 from the account.

Managing accounts requires the tenant to link Microsoft 365 Archive to an Azure subscription to pay for ongoing storage and restore operations. Storage costs $0.05 per month per gigabyte while retrieval costs $0.60 per gigabyte. Restored accounts remain accessible for 30 days. During this time, someone has to review the material in the account and move it to another repository, such as a different OneDrive for Business account or a SharePoint Online site. Once the 30-day period lapses, SharePoint Online archives the account again.

The OneDrive Report

So good, so far. Archiving old OneDrive accounts that clutter up storage is a good idea. It stops artificial intelligence tools like Copilot for Microsoft 365 using the content held in the obsolete accounts in its response to users and helps to better manage information belonging to ex-employees.

When Microsoft issued MC836942 on July 26, they said that by August 16, 2024, SharePoint administrators would be able to access a new report detailing unlicensed OneDrive for Business accounts. The OneDrive report should now be available through the Reports section of the SharePoint admin center in all tenants (Figure 1).

Note the warning that if accounts are left in Microsoft 365 Archive for more than 180 days after becoming unlicensed and the tenant does not take out an Azure subscription to pay for the Microsoft 365 Archive storage costs, SharePoint Online can delete the accounts. No documentation is currently available to cover this point, but it seems reasonable that Microsoft should remove old and unwanted OneDrive accounts if the owning tenant is unwilling to pay the storage costs to keep them in the archive.

Four Categories of Unlicensed OneDrive Accounts

Unlicensed OneDrive accounts fall into four categories:

• Retention period: The owning account is unlicensed but SharePoint Online has retained the OneDrive account because the retention period configured in the SharePoint admin center has not expired.
• Retention policy: A Microsoft 365 retention policy or retention labels prevent the deletion of an unlicensed OneDrive account. It is quite common for tenants to apply a blanket retention policy to all SharePoint Online sites and OneDrive accounts to retain information for multiple years. If this happens, the unlicensed OneDrive accounts cannot be removed until the retention period defined by the policy lapses.
• Active user with no license: The account that owns the OneDrive account is still active (is not deleted), but no longer has access to a service plan for OneDrive.
• Duplicate accounts: The account that owns the OneDrive account has several OneDrive accounts. This used to happen more often several years ago when account provisioning was not as good as it is now. I have not seen a duplicate account created in the recent past.

Figure 1 shows that my tenant has 34 unlicensed OneDrive accounts held by a retention policy. This is expected because I use a broad retention policy to govern removal of material from SharePoint Online and OneDrive for Business. Currently, you cannot see details of the accounts within each of the four categories on-screen. Instead, you must download the CSV file containing the details. In their documentation, Microsoft promises that an interactive UI will be available from January 2025, saying that “You can select a username to view the details.” Presumably, this means that the various sections in the on-screen report will expand to show usernames, and you can then expand a username to see its details, such as those available in the CSV file (Figure 2).

Time to Review Unlicensed OneDrive Account Information

Now that information about unlicensed OneDrive accounts is available in the SharePoint admin center, tenant administrators should check the report and review its content to determine if anything unexpected is present. I don’t imagine that anything strange will turn up, but you never know. Following the review, administrators might decide to adjust retention periods and policies to allow the removal of OneDrive accounts belonging to deleted Entra ID accounts or prepare for long-term storage in Microsoft 365 Archive.

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.

Decision to Rationalize License Management Not Popular

I think it’s fair to say that Microsoft’s decision to rationalize license management in the Microsoft 365 admin center has not met with universal approval. Among the complaints made are that license management in the Microsoft 365 admin center is slow, unwieldy, and lacks functionality when compared to the Entra admin center.

Some of the reaction is due to change. People don’t like change when they perceive it to be for no good reason. The argument advanced by Microsoft is that it makes more sense to collect all license management into a single console. Given that the majority of license management involves Microsoft 365 solutions, the Microsoft 365 admin center seems like the best place. What’s unsaid is that rationalization delivers reduced engineering, documentation, and support costs for Microsoft, none of which benefits the consumer. There’s no prospect of a reduction in Microsoft 365 license monthly fees due to a fall in Microsoft development costs.

Potential for Benefit

Even though I sympathize with those who dislike the change, the potential for benefit exists if Microsoft exploits the new focus on license management through the Microsoft 365 admin center to drive feature improvements. Hopefully, performance improves too. There’s nothing more annoying than waiting several seconds for a screen to display data when you know that better response is possible. The Entra admin center proves that greater alacrity can be achieved, as anyone who has worked with the Graph APIs for license management knows that the APIs are not slow.

The nature of cloud services is that customers don’t get to vote about the details of service delivery. Microsoft provides license management functionality. How they deliver that functionality and how quickly the UI responds is entirely up to the service provider.

Change in User and License Management Roles

Which brings me to message center notification MC810926 (last updated 15 August 2024) covering the enablement of the user administrator and license administrator roles to be able to process self-service license requests through the Microsoft 365 admin center. Previously, only those holding the global administrator role could process self-service license requests but the deployment of the change to enable the other roles should be complete worldwide by the end of August.

Microsoft says that the change brings consistency with the Azure portals (Azure, Entra, and Intune) where user and license administrators can already approve (or deny) requests. Of course, the fact that license management is rationalizing in the Microsoft 365 admin center has nothing to do with the change.

Of course, before anyone can process requests, administrators must enable products like Visio and Power BI Premium for self-service. As discussed in this article, many tenants use the infamous MsCommerce PowerShell module to manage the set of products permitted for self-purchase (or to disable all products). Microsoft 365 Copilot is the latest product (id CCFQ7TTC0MM8RS) to join the set.

According to message center notification MC853238 (6 August 2024), Microsoft plans to introduce a GUI (Figure 1) to allow tenant administrators to control self-service purchases and trials for individual products. Not having to use the dreaded MsCommerce module is good enough reason to welcome this capability.

Some Signs that Change Will Deliver for Administrators

As noted earlier, some don’t like to embrace change. It’s up to Microsoft to demonstrate that the rationalization of license management into the Microsoft 365 admin center is a good idea. Making sure that the Microsoft 365 admin center offers the same capabilities as the Entra admin center is mandatory. Introducing new functionality like the GUI to manage self-service license purchases and informing administrators when users make self-service purchases are two examples of how rationalizing around a single admin center makes the change better for all.

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.

Look Out for Synchronized On-Premises Accounts Holding Administrative Role Assignments

An August 2 post by SpecterOps highlights the dangers for hybrid Microsoft 365 organizations of synchronizing on-premises accounts to Entra ID that hold administrative roles. This is a long-running story. Following the SolarWinds debacle, Microsoft explicitly recommended in December 2020 that “synchronized objects hold no privileges beyond a user in Microsoft 365, either directly or via inclusion in trusted roles or groups.”

Even with all the warnings, it seems that some organizations never received the memo or continue to allow synchronized accounts to hold Entra administrative roles. That’s a great pity, just like the failure to enable strong multifactor authentication to protect user accounts.

This brings me to the question of how to scan for accounts synchronized from on-premises that hold Entra ID administrative roles. As always, it’s great to build off community ideas. In this case, Nathan McNulty tweeted some Microsoft Graph PowerShell SDK code to find accounts holding administrative roles. Nathan doesn’t seem to have published anything in his GitHub repository, so my version is available from the Office 365 for IT Pros repository.

Previous Script to Report Administrative Roles

I’ve been down the road of reporting privileged role assignments before when I wrote a script in 2023 to look for assignments for the Global administrator and Exchange administrator roles. The information about role assignments is then used to disable PowerShell for all accounts except the holders of the two roles. The 2023 script used cmdlets from the now-retired AzureADPreview module, so I updated the code to use cmdlets from the Microsoft Graph PowerShell SDK instead.

Processing Steps to Find and Report Administrative Roles

The script to report administrative roles handles both Privileged Identity Management (PIM) and non-PIM assignments and does the following:

• Administrative role assignments can be scoped to the entire directory or specific administrative units. The assignments stores GUIDs for administrative units. To make sure that the report can include the display name for administrative units, the script loads details of administrative units into a hash table. As the script processes each assignment, it looks the administrative unit to find its display name.
• Runs the Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule cmdlet to retrieve the set of PIM active assignments. These are role assignments that are currently in use.
• Parses each assignment to find it if is to a user, group, or service principal. If a group, expand the set of group members. Add what’s found to a PowerShell list.
• Runs the Get-MgBetaRoleManagementDirectoryRoleEligibilitySchedule cmdlet to find the set of eligible assignments. Parse what’s found and add to the PowerShell list.
• If the script can’t find any PIM assignments, the likelihood is that the tenant doesn’t use PIM, so the script finds the set of members assigned to each directory role and report that.
• Outputs details of the assignments via the Out-GridView cmdlet plus either a CSV file or Excel worksheet (Figure 1), depending on whether the ImportExcel module is available.
• Finally, the script lists any on-premises users found with administrative roles.

Feel Free to Improve the Code

No doubt some improvements can be made to the code to make administrative role assignments easier to understand. The point is that the script is relatively simple PowerShell that should be easy to work with and update. It is best to make the changes direct in GitHub so that everyone benefits from your inspiration.

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

October 15 Date for First Round of Azure MFA Requirement Enforcement

Microsoft’s decision to enforce multifactor authentication (MFA) for access to Azure properties certainly caused a great deal of kerfuffle. The original May 14, 2024 announcement didn’t help itself by proclaiming that “Microsoft will require MFA for all Azure users,” an assertion that led people to believe that any sign-in to Azure AD (Entra ID) would require MFA. At the time, I thought the idea is sound but the communication was woeful.

Roll forward to June 27, 2024, and a follow-up post to the Core Infrastructure and Security blog in the Microsoft Technical Community attempted to clear the confusion. Given the number of questions since, the signs are that people are still unsure what’s happening. Let me try to unravel the situation.

First, not everyone is affected by the change. MFA is only enforced for access to some Azure cloud properties. According to message center notification MC862873, Microsoft will require MFA for access to the Entra admin center, Azure portal, and Intune admin center (including services like Windows 365 Cloud PC) on or after October 15, 2024. Although I am not certain, Windows 365 Cloud PC seems like the only place where non-administrators might be affected by the MFA requirement.

Phase 2 of the implementation in early 2025 will see the requirement spread to the Azure CLI, Azure PowerShell, and infrastructure as code (IaC) tools. The good news is that only administrator accounts typically use these sites. Normal users are unaffected by the change. And anyway, administrator accounts should be protected by MFA. If they are not, the tenant has other problems.

Second, Microsoft 365 tenants that use Security Defaults already mandate MFA for connections to administrator portals.

Third, tenants that don’t use Security Defaults and have conditional access policies in place to control connections instead probably have a policy to require MFA for connections to administrative sites. Microsoft even publishes a policy template to make it easy for tenants to enable this control.

Workload identities, such as the managed identities used with Azure Automation, are unaffected. However, if Azure Automation runbooks include user identities (username and password credentials) for authentication, they might not work after Microsoft deploys the requirement for MFA access to Azure. For instance, if a runbook uses the Azure PowerShell module, it must use a managed identity or service principal (app) to connect.

Break glass accounts are affected too. If ever needed, these accounts are likely going to access Azure administrative sites and use Azure administrative tools, so the new guidance is to modify the previous practice of using a long and complicated password and add the protection for the accounts with a strong MFA authentication method like FIDO2 or certificates.

Postponing the Azure MFA Requirement

Microsoft says that they will allow a grace period to tenants who need some extra time. Organizations that use non-Microsoft MFA solutions might be in this category (support for external MFA providers is in preview). If in doubt, use the link in the message center notification post to request a postponement (Figure 1).

More information is available in the Microsoft planning document covering the new requirement.

Microsoft’s Script to Reveal Access to Azure Administrative Tools

In their post, Microsoft says that the Export-MsIdAzureMfaReport cmdlet from the MSIdentityTools PowerShell module as a way to uncover accounts likely to be affected by the change. The cmdlet “exports the list of users that have signed into the Azure portal, Azure CLI, or Azure PowerShell over the last 30 days by querying the sign-in logs,” so it’s a useful way to get an insight into who might be affected by the MFA requirement. I ran the cmdlet for my tenant and found that I need to act for an account used for utility background jobs (Figure 2).

The data used by the cmdlet is available to administrators to create their own version. For instance, the script covered in this article explains how to combine data from several sources to create a picture of MFA usage within a tenant.

No Need to Panic – the Azure MFA Requirement is a Good Thing

The bottom line is that there’s no need to panic unless you have a bunch of background jobs that use user credentials for authentication or forget to update your break glass accounts. Normal users will make unperturbed progress through the change. This is predominantly a good update to force administrators who haven’t yet understood the absolute need to protect their accounts with MFA to change their behavior. After all, why leave an open door ready for the bad guys to kick in?

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.

Updates Rolling Out in September 2024

On August 15, 2024, Microsoft announced updates for Microsoft Copilot slated “to bring enterprise data protection to more organizations.” Given the profusion of Copilots in the Microsoft ecosystem, it’s important to realize that this is not Copilot for Microsoft 365. Instead, Microsoft Copilot is the free version-for-customers that doesn’t use LLMs trained on Microsoft Graph data.

The big change is that those who sign into the Microsoft Copilot web app with an Entra ID account can take advantage of Enterprise Data Protection (EDP). Microsoft says that EDP brings the following benefits:

• We secure your data: We help protect your data with encryption, at rest and in transit, rigorous physical security controls, and data isolation between tenants.  
• Your data is private: We won’t use your data except as you instruct. Our commitments to privacy include support for GDPR, ISO/IEC 27018 and the Data Protection Addendum.
• Your access controls and policies apply to Copilot: Prompts and responses are logged, retained, and available for audit, eDiscovery, and advanced Microsoft Purview capabilities. The specific controls will vary depending on the underlying subscription plan. 
• You are protected against AI security risks: We help safeguard against AI-focused risks such as harmful content and prompt injections.   
• Your data isn’t used to train foundation models: Prompts and responses are not used to train foundation models.  

Copilot Security Weaknesses Reported at Black Hat Don’t Apply Here

The assertion about protecting Copilot against AI security risks is especially interesting in light of the discussions at the Black Hat U.S.A. 2024 conference where a presentation covered a number of weaknesses security researchers say exist in Copilot for Microsoft 365. The techniques explored during the presentation focused on exploiting information accessed by Copilot through Graph API requests, which Microsoft Copilot doesn’t use. The exploits include a Remote Code Execution (RCE) where an email sent to a user apparently influenced the results displayed by the Copilot for Microsoft 365 chat app to entice the user to send a payment to an incorrect bank account.

The researchers say that the RCE involved an email sent from a Google account to a user with Microsoft 365 E5 and Copilot) licenses. Although the presentation material is online, I have been unable to replicate the issue. It’s entirely possible that this is due to my incompetence. It might also reflect the fact that Microsoft 365 is so configurable that it’s difficult to replicate the exact circumstances in which such a RCE might be possible.

Microsoft stayed silent on whether the changes made for Microsoft Copilot will close the gaps described at Black Hat. It’s inevitable that people will assume that a weakness in one Copilot afflicts all Copilots. The possibility exists that some of the issues highlighted do afflict Microsoft Copilot, but the purported RCE does not because it’s dependent on Copilot being able to read data from an email when responding to a user prompt that involves a spreadsheet stored in a SharePoint Online site. These resources are just not available to Microsoft Copilot. Despite the focus on Microsoft Copilot in this announcement, it would have been nice if Microsoft has seized the opportunity to say something about the issues raised at Black Hat to reassure customers who use Copilot for Microsoft 365.

Pinning Microsoft Copilot

Available now is a new setting in the Microsoft 365 admin center to pin Microsoft Copilot to app navigation bars. This happens automatically already for Copilot for Microsoft 365 and is now being extended to cover Microsoft Copilot from mid-September 2024 in apps like Teams, OWA, and the new Outlook. Microsoft recommends (of course) that tenants configure the setting to pin Copilot (Figure 1) so that apps pick up the setting when the necessary updates roll out.

For more information about these and other updates announced by Microsoft, including a refreshed user interface for Microsoft Copilot, see their FAQ.

More News to Come?

It’s easy to become confused with the plethora of Copilots produced by Microsoft. In this case, security for the version that doesn’t interrogate the Microsoft Graph to generate answers for users is being upgraded. Given the issues raised at the Black Hat conference, it would be nice to hear that the Microsoft 365 version will receive enhanced security too. I suspect we’ll be hearing from Microsoft on that topic very soon.

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.

Admin Settings API to Control Usage Reports Data Gets an Update

If you don’t follow the sometimes-anarchic world of the Microsoft Graph, message center notification MC859853 (13 August 2024) might have passed you by without comment. However, given the importance of reporting usage data to understand the activity level within tenants, this is a significant change.

The option to anonymize user information like display names in usage reports generated from the Microsoft Graph has existed since 2020. The control for the option is under Reports in the Org Settings section of the Microsoft 365 admin center and its purpose is to protect the privacy of users. The control affects all access to usage data via the Graph, including reports generated using PowerShell, such as the Teams and Groups Activity Report. In fact, if you choose to obfuscate user data, reports lose much of their value and can make it impossible to derive comparisons between different forms of usage data. For instance, the script to analyze use of different Microsoft 365 workloads by individual accounts to determine who could best use Copilot for Microsoft 365 licenses depends on being able to match user principal names.

Programmatic Access to Set the Privacy Control for Usage Reports Data

It’s useful for programs and scripts to be able to turn the privacy control off to fetch usage data and back on again when finished. Until now, programmatic access to control the privacy setting for usage reports existed in the beta adminReportSettings Graph API. What’s changed is that the API is now generally available and therefore available through the V1.0 Graph endpoint. In the past, a script might have done something like this to check if the privacy setting was on or off:

$Uri = "https://graph.microsoft.com/beta/admin/reportSettings"
$Data = Invoke-MgGraphRequest -Method Get -Uri $Uri
Write-Host ("The current report privacy setting is {0}" -f $Data.displayConcealedNames)
The current report privacy setting is False

Now that the API is generally available and fully supported, the URI is https://graph.microsoft.com/V1.0/admin/reportSettings. For instance, to update the privacy setting to set it on, you’d do:

$Uri = "https://graph.microsoft.com/V1.0/admin/reportSettings"
$Settings = @{}
$Settings.Add("displayConcealedNames","true")
Invoke-MgGraphRequest -Uri $Uri -Method Patch -Body $Settings

The Microsoft Graph PowerShell SDK has just had a refresh to V2.22 but the SDK cmdlets haven’t yet caught up with the change and remain using the beta endpoint. This means that you should use Get-MgBetaAdminReportSetting to fetch values and Update-MgBetaAdminReportSetting to switch the control from on to off or vice versa.

To update the privacy control, the signed-in account must hold the global administrator role and the app used must have consent for the ReportSettings.Read.All permission.

Backup Restore Module in V2.22 of the Microsoft Graph PowerShell SDK

One of the notable things about V2.22 of the Microsoft Graph PowerShell SDK is the appearance of a new beta module for Microsoft 365 Backup (backup and restore operations). To list the commands in the module, run Get-Command:

Get-Command -Module Microsoft.graph.beta.backuprestore

Use of the cmdlets requires consent for the BackupRestore-Control.Read.All permission (Figure 1).

Despite having the permission and an active Microsoft 365 Backup schedule in place for SharePoint Online, OneDrive for Business, and Exchange Online, all attempts to use the cmdlets met with an internal error. Oh well, Microsoft 365 backup is only just generally available, and this is a beta module. Things are expected to go wrong. It’s just another opportunity for improvement within the Microsoft 365 ecosystem.

Graph Keeps On Growing

Being able to control usage report data privacy and Microsoft 365 Backup through Graph APIs are two examples of how people might not have considered using the Graph to automate common administrative scenarios. It’s proof of the growing influence of the Graph, and underlines why Microsoft 365 tenant administrators need to become Graph literate.

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.

AuditLog Query API Cmdlets Now Available in the Microsoft Graph PowerShell SDK

In April 2024, I wrote about the new AuditLog Query Graph API. At the time, the API exhibited the normal rough edges found in any beta API, but I managed to use it to retrieve records from the Microsoft 365 unified audit log.

Roll forward some months and cmdlets are available for the AuditLog Query Graph API in the beta version of the Microsoft Graph PowerShell SDK (I used version 2.21 to test). Microsoft uses a process called AutoRest to automatically generate SDK cmdlets from Graph API metadata and cmdlets usually turn up a month or so after an API appears. The relevant cmdlets are:

• New-MgBetaSecurityAuditLogQuery: create and submit an audit log query. Purview processes audit log queries in the background, just like the way audit searches work in the Purview compliance portal.
• Get-MgBetaSecurityAuditLogQuery: check the processing status of an audit log query. Because background jobs handle the queries, they take much longer to complete than searches performed with the Search-UnifiedAuditLog cmdlet do. One job took 35 minutes to complete when Search-UnifiedAuditLog required three minutes.
• Get-MgBetaSecurityAuditLogQueryRecord: retrieve the audit records found by the query.

Running a query is a matter of constructing a hash table containing the parameters such as the start and end time and the operations to search for, checking for completion of the job, and downloading the results. You can check out the test script I used from GitHub.

The Too Many Retries Problem

Two oddities occurred during testing. First, “Too many retries performed” errors appeared when running the New-MgBetaSecurityAuditLogQuery cmdlet. A search against the SDK issues revealed that I wasn’t the only one to encounter the problem. Adding the Set-MgRequestContext cmdlet to the script seems to have solved the problem. At least, it hasn’t reappeared.

According to its documentation, the Set-MgRequestContext cmdlet “Sets request context for Microsoft Graph invocations.” This is a delightfully obscure description that means little to most people. The important point is that you can increase the retry delay (in seconds) and maximum retries to get around then “too many retries problem” that seems to afflict some Graph APIs (those dealing with devices and Intune seem to be most affected). The default for these values are 3 (retries) and 3 (seconds delay). The maximums are 10 (retries) and 180 (delay seconds). For example:

Set-MgRequestContext -MaxRetry 10 -RetryDelay 15

Some trial and error is likely required to determine the optimum values for a script.

The Incorrect Audit Record Counts

The second issue was a complete disconnect between the number of audit records returned by the audit log query (10,878) and Search-UnifiedAuditLog (10,879), and the number reported by the Purview compliance portal (2,538).

The compliance portal loads pages of 150 audit records at a time. If you scroll to the bottom of the list, it loads the next page, and so on. If you’re persistent, it’s possible to advance page by page until the full set of retrieved records is exhausted (Figure 2).

I don’t know why the Purview compliance portal shows an incorrect count of audit records found by a search. The reason might be that the actual number of audit records found by a search is not returned by the API. Instead, you must fetch the records to find out how many are found.

Microsoft might be relying on the fact that audit searches are often quite precise (for instance, focusing on Copilot interactions for a single user). These searches don’t return thousands of records. If only 100 audit records are found, it’s easy for the portal to display an accurate count.

AuditLog Query API Still Needs Work

It’s nice to see the AuditLog Query API appear in SDK cmdlets. However, the API is still in beta status and the audit records it returns are less complete than those found by the Search-UnifiedAuditLog cmdlet. I guess everything needs time to mature.

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

HVE and ECS Compete for Different Customers of Microsoft Cloud Email Services

I need to apologize to some of the subscribers to the Office 365 for IT Pros eBook. Over the last few weeks, I’ve been using you as the targets for emails sent using Exchange Online High-Volume Email (HVE) and the Azure Email Communication Service (ECS).

Both solutions focus on sending large quantities of email. HVE is more internal-focused but can handle external messages. HVE is part of Exchange Online and intended to help customers move off on-premises servers to handle traffic generated by multi-functional devices and applications. ECS is a standalone offering that can handle large volumes of external email such as newsletters, subject to thresholds set by Microsoft. According to Microsoft, ECS is very popular and handles large amounts of messages daily.

HVE is in preview and is free to use today. When it’s generally available, HVE will likely cost for some traffic. ECS is already a pay-as-you-go service that must be funded by an Azure subscription.

Seeking Test Email Targets for Microsoft Cloud Email Services

When setting out to test the effectiveness of emailing solutions, you need large numbers of target recipients. Little is to be learned by sending a couple of messages to a few internal recipients. To run a better trial, I decided to use HVE and ECS to send reminder messages to subscribers of the 2024 edition of the Office 365 for IT Pros eBook to ask if they wanted to take advantage of an offer to extend their subscription. Sending email to ask people to buy something or take out a subscription seemed like a pretty good scenario to test the useability of HVE and ECS.

Comparing HVE and ECS

Overall, HVE is easier to use. Less setup is required, and the PowerShell used to generate and submit messages is based on the old (deprecated) Send-MailMessage cmdlet. No shortage of articles can be found on the internet to tell you how to use Send-MailMessage. Because of the need to provide an email service for apps and devices, HVE uses a restricted form of basic authentication with the SMTP AUTH protocol. Support for modern authentication is coming, but using basic authentication for internal messages will make the switchover to HVE much easier.

HVE reporting (Figure 1) is basic. More comprehensive reporting is built into ECS. In both cases, feedback from sent messages is minimal, so figuring out what happened to messages is tough. ECS can tell you the number of messages it failed to send but HVE is silent on this point. However, HVE is in preview and Microsoft says that they will deliver better reporting when the solution is generally available.

The ECS setup is more complicated if you’re unaccustomed to dealing with Azure resources and billing. ECS uses an Entra ID app for authentication and to prove that an app (like a PowerShell script) has the right to submit messages to the service. Creating and submitting messages to ECS is similar to using Graph-based cmdlets like Send-MgUserMail. Some differences exist because a different API is used, but the basics of building a hash table of message parts and converting it to JSON before sending won’t be unfamiliar.

Throttling and thresholds were the biggest issue I encountered with both ECS and HVE. It took a little while to find where limits applied in practice and to investigate ways around them. Microsoft has a documented process for applying for higher limits for ECS but my ability to navigate the process failed and I never managed to achieve a higher threshold. Microsoft is careful with HVE while it is in preview and some limitations (like the 2,000 external recipients per tenant daily) are hardcoded and won’t change until the software reaches general availability.

Testing of both Microsoft Cloud Email Services Proves Valuable

As always, the opportunity to conduct realistic tests over a sustained period proved invaluable in gaining an understanding about how HVE and ECS work. In my case, sending thousands of reminder messages to Office 365 for IT Pros subscribers certainly taught me a lot. You can read more about my experiences in articles covering HVE and ECS in-depth. Other articles about HVE and ECS are available on the internet, but most are content to send just a few test messages and then declare success. That’s no way to exercise a high volume email system.

If you’re interested in one of these services, my advice is to spin up both and test using a sample of messages that your organization needs to send. Exchange Online tenants will, I think, select HVE, but I can see why ECS has its attractions especially if the focus is on sending large quantities of email to external recipients. Beauty is in the eye of the mail sender.

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

When Someone Exits the Organization, They Might Leave Active Teams Online Meetings Behind

Last week, I discussed the issue of handling the information contained in Teams chats participated in by an ex-employee. Another common problem that emerges when someone leaves is how to handle meetings organized by the leaver. For instance, I received a note to ask:

“We have an important Teams meeting. The organizer of that meeting has left. There are co-organizers, so the meeting chat and recordings can be retained. One problem is that the “missed activity emails” from Teams are sent in the name of the original organizer. Is it possible to change these to be sent by a co-organizer or change the meeting’s “owner” (which would hopefully change the sender of these mails). The issue is bothersome because some of the recipients of these mails are senior leadership, and they ask why the messages come from an ex-employee.”

I’m assuming that this refers to a personal meeting. In other words, someone created a recurring meeting in their calendar (Outlook or Teams) and invited a bunch of people to attend rather than creating a channel meeting.

Creating a Teams Online Meeting

When someone creates an online Teams meeting, two things happen. First, an online meeting is created for participants to come together and share audio and video feeds. This object is controlled by Teams and is an instance of the onlineMeeting Graph resource. Second, the join link for the online meeting are written back into the calendar properties for the event so that they can be included in the meeting invitation and shared with participants. Figure 1 shows the join link for a Teams meeting as viewed in an Outlook calendar event.

The Teams online meeting object now takes precedence in terms of running meetings. The calendar event in participant mailboxes allows users to know when a meeting is scheduled and have Outlook issue reminder. However, the options used to control the online meeting such as allowing reactions, chat, the URL to join the meeting, and whether to record the meeting automatically are properties of the online meeting object. The meeting object shares its participant list with the Outlook calendar and has relationships with the recording, transcript, and attendance report.

No Way to Change a Teams Online Meeting Organizer

Coming back to the original question, can anything be done to transfer the organizer role for meetings to another user after the original organizer leaves the organization? The answer is no. The creation of an online Teams meeting sets the organizer in stone and no change is possible thereafter. The Update onlineMeeting Graph API explicitly prohibits changing the meeting organizer, saying “the organizer of the meeting cannot be modified after the meeting is created.”

Removing the calendar events from the ex-employee’s calendar has no effect on the online spaces and their settings. It just deletes the events from the calendar.

Three Ways to Tackle the Problem

If a meeting organizer cannot be changed, how should organizations handle the problem created when someone leaves an organization with active Teams meetings in place? Only three answers seem possible.

1. Leave the active online meetings in place. While meetings are active, they can be managed by co-organizers. Eventually the meetings will expire to mitigate the issue.
2. Create a replacement meeting with the same time slot, settings, and participants. The new meeting (potentially created by a utility account) becomes the active event. If the original organizer’s mailbox is still available, someone can be granted permission to access the mailbox and cancel (delete) the original meeting. Before cancelling the meeting, make sure that any required artifacts like transcripts and recordings are secure. Otherwise, the original online meeting can be left in place and participants can either delete their instance of the event from their calendar or leave it intact.
3. Use a dedicated utility account to create important company events. A utility account is a regular user account (not a shared mailbox) dedicated to event management. The account is licensed for Exchange Online and Teams. Nominated individuals can be granted access to the account to create and manage meetings. The advantage of this approach is that it doesn’t matter if someone leaves the organization because the meetings belong to the organization rather than an individual. Defining what an important event is and figuring out how users can apply for the creation of an online meeting is something for individual organizations to determine. The person who requests such a meeting should be made a co-organizer to allow them to handle the day-to-day management of the event, like adding or removing participants.

The second option is the right course if you’re handling the problem of dealing with active meetings organized by ex-employees and are forced to act. However, before creating replacement events, consider implementing the idea of using a utility account to manage important company events. Asking someone else to create a replacement event will certainly work, but what happens when that person decides to leave?

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

License Assignments Cease in Entra Admin Center from September 1, 2024

Microsoft hasn’t announced the change formally yet, but a notice posted in the Entra admin center and associated documentation proclaims that from September 1, 2024, administrators won’t be able to assign any form of license to user accounts or groups through the Licenses page of the Entra admin center (Figure 1). In addition, it will no longer be possible to assign or update licenses by editing user account properties in the Entra admin center. Instead, administrators must make license assignments through the Microsoft 365 admin center.

Following the switchover, it will still be possible for administrators to view license assignments in the Entra admin centre. Only license assignments and updates for current assignments are blocked.

According to Microsoft documentation, the change will “streamline the license management process within the Microsoft ecosystem.” A case can certainly be argued that it’s better to centralize license management in one place, even for Entra P1 and P2 premium licenses. Given that Microsoft 365 consumes most licenses, it is logical to focus licensing activity on the Microsoft 365 admin center.

PowerShell Remains Unaffected

The change only affects the GUI in the Entra admin center. Licenses can still be assigned to users and groups via the Microsoft Graph PowerShell SDK or Graph API requests. Any tools written based on the SDK or Graph requests such as the Microsoft 365 Licensing Report remain unaffected.

Microsoft 365 Admin Center Updates

License management has been present in the Microsoft 365 admin center for a while. Group-based license management is a relatively new addition (Figure 2) and supports the same feature set as the Entra admin center.

One nagging doubt that I have about the move is that the Microsoft 365 admin center is invariably slower at dealing with anything to do with licensing than the Entra admin center is. Perhaps folks who work on the Microsoft 365 admin center need some help about efficient license management techniques from their Entra colleagues. Another is that the Microsoft 365 admin center doesn’t support administrative units in the same way as the Entra admin center does (albeit requiring Entra P1 licenses). Hopefully, administrative unit support will appear in the Microsoft 365 admin center soon.

Overall, I don’t think making the Microsoft 365 admin center the fulcrum for license assignments will discomfort anyone except people who write about license assignments. Proving the value of ePublishing, we’ll document this change in the September 2024 update of the Office 365 for IT Pros eBook (2025 edition).

Self-Service Purchases Get a GUI

A change that might have more impact is the one announced in message center notification MC853238 (6 August 2024). For years, tenant administrators have complained about the way Microsoft opened up self-service purchases to users and the need to use the awful MSCommerce PowerShell module to disable the ability for users to buy licenses.

MC853238 says that in mid-September 2024, the Microsoft 365 admin center will have a new Self-service trials and purchases option under Org Settings (Figure 3) to enable or disable self-service license purchases previously only manageable through PowerShell.

Administrators can choose to:

• Allow self-service trials and purchases: Users are allowed to apply for trial licenses and buy self-service licenses.
• Allow trials only. Even after a successful trial, the user cannot purchase a license.
• Do not allow purchases: Users cannot purchase self-service licenses.

It’s surprising that Microsoft has taken so long to introduce the GUI to manage self-service purchases, but at least it’s happening now.

Friday Happiness

These changes are good examples of the kind of updates that flow through Microsoft 365 on an ongoing basis. Neither are earthshattering. They won’t cause processes to stop working unless you really depend on the Entra admin center for license assignments. Even if you do, the switch to the Microsoft 365 admin center is easy. Everyone should ignore some of the breathless hype around these changes and have a nice weekend, which is what I plan to do.

Filtering Blocked or Unblocked Apps

After writing about the Teams Application-Centric Management (ACM) model that replaces app permission policies for Teams apps, I received this question:

One shortcoming of this new model is that it isn’t clear/easy to see what apps you’ve approved or blocked in the manage apps section. You can sort by App status which gets you part of the way there, but it would be really nice if you could filter by app status, do you know if that will be forthcoming?

As I don’t work for Microsoft, I have no idea what the Teams development group is working on to make app status a filterable field in the Teams admin center. Certainly, introducing a filter that can highlight blocked or approved apps seems like a good idea. With over 2,500 apps to manage (Figure 1), any change that helps administrators to focus is appreciated.

When a tenant switches to ACM, the Available to property controls whether an app is blocked or available. The “No one” permission shown in Figure 1 is the same as an app blocked status used by app permission policies. In any case, ACM doesn’t matter because a filter isn’t available for the Available to property either.

Filtering Apps with PowerShell

Given that Teams boasts a comprehensive PowerShell module in addition to Teams cmdlets in the Microsoft Graph PowerShell SDK, there surely must be a way to retrieve apps from the Teams app catalog to report app details using whatever filter is required? Alas, this doesn’t seem to be possible because the cmdlets (and the underlying Graph API requests) return details of the apps known within a tenant. There doesn’t appear to be a cmdlet to return all 2,500-plus apps, even if these are listed in the Teams admin center.

For example, the Get-TeamsApp cmdlet from the Teams PowerShell module returns app information from the tenant app store:

[array]$Apps = Get-TeamsApp

In my tenant, the cmdlet returned 67 apps, including some duplicates such as the Activity app:

Id                                                       DisplayName
--                                                       -----------
69a8054f-7aeb-4e25-a0c5-1837c1a22446                     Activity
14d6962d-6eeb-4f48-8890-de55454bb136                     Activity

Teams is an app built from apps and some of the apps have been redesigned over time, so it’s unsurprising to find multiple entries for some apps. As we’ll see later, this is exactly what happens. The apps have different versions.

The Graph PowerShell SDK Alternative

According to the documentation for the List apps request, the Get-MgAppCatalogTeamApp cmdlet (from the Graph {PowerShell SDK) lists apps from the Microsoft Teams app catalog. This includes apps from the Microsoft Teams store and apps from your organization’s app catalog (the tenant app catalog). Running the cmdlet produced 68 apps.

The Queues (preview) and Dataverse Chat Sync apps are not reported by Get-TeamsApp. The queues app is a new Teams Premium feature for customer call management described in message center notification MC814579 (Microsoft 365 roadmap item 379980). Following its deprecation, the Viva Topics app is now considered as specific to the tenant rather than a Microsoft app included in the app catalog:

Get-MgAppCatalogTeamApp -Filter "distributionMethod eq 'organization'"

Id                                   DisplayName DistributionMethod ExternalId
--                                   ----------- ------------------ ----------
8905c282-649c-44fc-8795-70ec764137c0 Viva Topics organization       f7df4001-86d8-4235-af76-2e7e97f1eaca

The SDK cmdlet returns more information about apps. However, it doesn’t reveal any details about app permissions (ACM) or a blocked/unblocked status. Instead, the details are limited to descriptions and information about when an app was last modified (which isn’t populated for most apps). Here’s a quick script to extract and report some details about apps:

Connect-MgGraph -NoWelcome -Scopes AppCatalog.Read.All
$Report = [System.Collections.Generic.List[Object]]::new()
[array]$TeamsApps = Get-MgAppCatalogTeamApp -ExpandProperty AppDefinitions | Sort-Object DisplayName

ForEach ($App in $TeamsApps) {
    $ReportLine = [PSCustomObject] @{ 
        DisplayName     = $App.DisplayName
        Version         = $App.AppDefinitions.Version
        Id              = $App.id
        Description     = $App.AppDefinitions.Description
        LastModified    = $App.AppDefinitions.LastModifiedDateTime
    }
    $Report.Add($ReportLine)
}
$Report | Out-GridView -Title 'Teams App Details'

Figure 2 shows the output. As you can see, the two entries for the Activity app have differet version numbers and descriptions:

More Information Needed about Teams Apps

Maybe I am missing something fundamental, but I came up blank after spending a couple of days poking around to see if I can find better information. What’s for sure is that better programmatic access to the full Teams app catalog would be appreciated along with better filtering capabilities in the Teams admin center. Is that too much to ask?

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.

Teams Chat Messages Can Hold Lots of Important Content

Recently, I have written about the choice between shared mailboxes and inactive mailboxes to preserve email content and some of the PII issues that can arise when users gain access to the OneDrive for Business accounts belonging to other people. Both scenarios are related to dealing with the information accumulated in Microsoft 365 by people who leave the organization for one reason or another.

Mailboxes and OneDrive for Business accounts hold information created by their owners for many workloads, like Loop components, Teams meeting recordings, and whiteboards. But one thing they don’t hold is the user’s Teams chat messages. Given the widespread use of Teams by 320 million Microsoft 365 users, a fair chance exists that some important business information exists in chats participated in by ex-employees. Neither the Microsoft 365 admin center nor the Teams admin center includes an option to preserve chats during the account removal process. The question therefore is how to access chats to recover any information required by the business.

Cosmos DB, Compliance Records, and Exchange Mailboxes

Teams chat messages are “owned” by all the participants in a chat. In other words, the departure of one participant from a chat does not remove the chat messages from the Teams messaging database stored in Azure Cosmos DB. Deletion of messages only occurs after the last participant leaves the chat.

When an administrator removes an ex-employee’s account, Teams notes the fact and removes any chat messages the user had sole access to such as messages in the Chat with Self or chats where all other participants have left (shown as ‘Just me’ in the chats list). Removal isn’t immediate and doesn’t happen until Entra ID permanently removes the user account after the 30-day grace period allowed for recovery.

If a Teams retention policy is in force, it doesn’t affect the items stored in Cosmos DB. Instead, retention processing works against the compliance records captured by the Microsoft 365 substrate for Teams chats and stored in the hidden TeamsMessagesData folder in the user’s mailbox. Compliance records are captured in the user’s mailbox for every interaction in a chat, including those from other participants in the conversation. Compliance messages are also captured for channel conversations and are stored in the TeamsMessageData folder of the group mailbox used by the team.

People commonly mistake the storage of compliance messages to mean that Teams stores its messages in Exchange Online mailboxes. This is incorrect. The compliance items held in Exchange Online are incomplete copies of the “real” messages captured to allow Purview compliance solutions to process Teams content. For example, Communication Compliance policies examine compliance records to find violations of organizational policies.

Using Compliance Records

If the account comes within the scope of a Teams retention policy, Purview retains the compliance records stored in the Exchange Online mailbox until the hold lapses. While the hold exists, it’s possible to run a content search against the mailbox to find compliance records. This then creates the possibility of running content searches against the user’s mailbox to:

• Look for references to keywords that might identify important corporate information. For instance, references to project code names.
• Find all Teams chat messages in the mailbox and export the data to a PST for examination by the compliance team or an external expert. The PST could remain under the control of the compliance team after the hold lapses on a “just in case” basis.

To export the compliance records for Teams chat messages, create a new content search. Limit the search to just the target user’s mailbox and use the kind:MicrosoftTeams keyword. Figure 1 shows the sample review for a search of compliance records stored in my mailbox.

I’ve used Teams since its preview in November 2016. As shown in Figure 1, compliance records dating back to at least September 2018 are in the mailbox. According to the search statistics, the search found 24,103 items. Fewer items would be present if a retention policy to govern Teams chat messages (and Copilot for Microsoft 365 interactions) was active.

Although a content search will find and export all the compliance records for Teams chat messages, the difficulty is that a separate compliance record exists for each message in a thread. Chats can be very busy with many interjections occurring over a short period. The result is that finding relevant records of any importance can take a lot of effort. Purview advanced eDiscovery can assemble Teams threads if searching for specific keywords and that can be helpful to understand the context and flow of a conversation.

The Focus on OneDrive Overlooks Teams

It takes time before organizations realize the need to preserve different information. In one way, Microsoft has made it easy to retain the information associated with ex-employees by using OneDrive for Business as the de facto standard for personal information storage within Microsoft 365. Between OneDrive for Business and Exchange Online, it seemed like all the information that could possibly be wanted was accessible. Even though Teams compliance records are in Exchange Online, I suspect that the compliance data for chats are overlooked when accounts are deleted. I could be wrong, but I might be right.

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.

Teams Meeting Transcripts Deserve Protection

A bunch of changes have been rolling out for Teams meetings to tighten control over the artifacts generated during calls. The catalyst for the updates appears to be the recent change to store Teams meeting transcripts in OneDrive for Business. Meeting transcripts are critical artifacts in many ways because they are used as the basis for intelligent recaps, Copilot for Microsoft 365 queries, and closed captioning. Because transcripts can capture confidential information in participant contributions during calls, it’s sensible for organizations to protect this data appropriately. Let’s discuss the recent changes.

Controlling Access to Teams Meeting Transcripts and Recordings

First, MC795083 (22 May 2024) reports that meeting organizers can dictate who gets access to meeting recordings, transcript, and the AI recap (which is generated from the transcript). The setting to control access is now part of meeting options (Figure 1). Meeting participants not granted access still see the artifacts listed in meeting chat but won’t be able to open or download the files.

Associated with this change is message center notification MC781595 (last updated 13 June 2024, Microsoft 365 roadmap item 332800). As described, you might assume that Microsoft is introducing a new policy to allow tenant administrators to restrict permissions to download meeting transcript files. In fact, it’s an extension of the existing SharePoint Online block file download policy. Blocking downloads of Teams meeting recordings has existed since March 2023. Now that transcripts and full recordings are stored in MP4 files that look the same, the block download policy for Teams meeting recordings apply to the transcript-only files too. The downside is that the block file download policy requires SharePoint advanced management licenses.

Change to Participant Agreement Policy Setting

Teams meetings can be either transcribed or recorded. In both cases, Teams generates an MP4 file that’s stored in the meeting organizer’s OneDrive for Business account. The difference between transcription only and full recording is that the MP4 file for full recording contains a video stream and transcript while transcript files only contain the captions that collectively form the meeting transcript.

In any case, message center notification MC794819 (21 May 2024) reports that the participant agreement setting (aka explicit consent) in Teams meeting policies (Figure 2) now covers processing of all types of user generated content, including transcript only MP4 files and the analysis of a meeting generated by Copilot for Microsoft 365 from the meeting chat and transcript.

When the policy setting is enabled for a meeting where recording or transcription is used, participants must indicate their consent to be recorded by unmuting their microphone, enabling their camera, or sharing their screen (any of the 3 actions will do). If the participant fails to heed the warning (Figure 3) and give consent, they can participate in the call in view-only mode.

No Enriched Audit Records for Teams Meetings

One update that I see no sign of is the change announced in MC791598 (last updated 22 May 2024) to “enrich” audit records for Teams meetings with consent data. This information is available in attendance reports, which capture actions to turn unmute microphones or turn on cameras (both meaning a user gives consent). However, I see no trace of any ‘Added information about meeting participants” audit records despite the promise that worldwide deployment would complete in mid-June 2024 and the description in Microsoft documentation.

Taking Care of Generated Notes

Teams meeting transcripts can be a tremendously valuable tool, especially when generative AI uses transcripts to produce recaps of meetings for those who can’t attend an event or those who need a little help to remember commitments made during calls. Although the captured text isn’t guaranteed 100% accurate (and won’t be more than 95% in my experience), it’s still better than most attempts to capture what happens during meetings in handwritten notes. The downside is the need to protect transcripts. The changes described here help.

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

Removal of Microsoft 365 Admin Center Option to Send Password in Email

In a change that surprises only because it took so long to be made, message center notification MC837081 (29 July 2024) announces that administrators will lose the option to send user passwords inemail after August 30, 2024. Although the detail in the post is hazy, I assume that this change refers to the email the sign-info info to me option after changing a user account password in the Microsoft 365 admin center (Figure 1).

Sending Passwords in Email is a Terrible Idea

The option to send a changed password by email has always existed in Office 365/Microsoft 365, possibly because it’s difficult to remember system-generated passwords. Sending email to the administrator to remind them about the password is possibly a lesser evil than writing down a system-generated password.

Users should always be forced to change their password when they first sign in after an administrative process changes their password. Even if a secure system-generated password is used, it’s unlikely that the user will remember it and they’ll either write the password down on a sticky note or request another password change. It’s better to let the user use the self-service password reset (SSPR) feature to choose their own password, providing it meets password complexity requirements.

An argument can be made that passwords don’t matter all that much anymore. This might be true if strong multifactor authentication (like the authenticator app or passkeys) protected every Microsoft 365 account and we had reached the stage where passwordless operation was possible everywhere, but there’s more work to be done before Microsoft 365 gets to that point.

Overall, sending password information in unencrypted email is a terribly bad idea that encourages people to treat passwords with less respect than they should. Purview Data Loss Prevention (DLP) includes sensitive data types for Azure AD (Entra ID) user credentials, User login credentials, and All credential types to help organizations block emails and Teams messages containing usernames and passwords.

The Print Option

Microsoft’s suggested replacement is to use “the new Print option in the Microsoft admin center to save the user account details and share them in a secure manner with your users.” I don’t see any trace of a new Print option in the Microsoft 365 admin center and the advice in the documentation is to use the print to PDF feature (CTRL/P). This works, even if it creates too many pages in the output PDF, and the method has the advantage that the PDF can be protected by a sensitivity label. I imagine that in most cases the PDF will be sent as an email attachment to someone like the user’s manager instead of being printed off and carried by an administrator direct to the user.

How best to get a new password to a user in a secure manner is a good discussion for tenant administrators to have. Given that many users work from home, it seems like making a phone call to communicate the new password is the most practical method. That is, if you can reach the user. Another idea I have heard include using Azure Key Vault to store updated credentials that a user can access through an Azure function.

Moving On

I doubt that many will mourn the passing of the option to send a user’s password to administrators via email. It’s a legacy artifact from a simpler time when passwords weren’t treated with as much respect as they deserve. It’s time to move on toward a future where user passwords are less important than they are now.

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

But No New Numbers for Office 365 and Teams Users in Microsoft FY24 Q4 Results

As has become the norm, Microsoft delivered another solid set of quarterly results (FY24 Q4) on July 30. 2024. The headline number was the $36.8 billion for Microsoft Cloud, a 21% growth year-over-year equating to an extra $6.5 billion earned in FY24 Q4 compared to the same quarter the previous year. The annualized run rate for Microsoft Cloud is now $147.2 billion. The gross margin for Microsoft Cloud decreased two points to 69% but Microsoft expects it to go back up in the current quarter.

Also following its norm, Microsoft successfully obscured the numbers for segments like Teams (no updated number provided, so the official number remains at 320 million monthly active users claimed in October 2023). Teams Premium now has 3 million users, or less than 1% of the total Teams installed base. Microsoft said that the seat growth was up 400% year-over-year, proving once again that impressive growth figures are always possible from a low base.

Office 365 Numbers and Growth

Amy Hood said that Office 365 commercial seats grew 7% year-over-year, but this isn’t helpful without a base number to compare it against. The last we heard was the “over 400 million paid seats” cited in January 2024 or the 382 million number given in April 2023. Possibly the unwillingness to share precise numbers is to disguise a slowdown in new user acquisition over the last year or so. Office 365 Commercial revenue increased 13% (14% in constant currency). The same level of growth is expected to continue in Q1.

More impressively, Enterprise Mobility and Security now has 281 million paid seats. That’s an increase of 13 million over two quarters. Another number is that Power Platform now has 48 million monthly active users. I assume most of these people are Office 365 users. If so, has Power Platform really reached 12% of the Office 365 base? I guess it’s possible and Microsoft is certainly doing all that it can to encourage more use, such as retiring the Office 365 connectors in favor of workflows.

GitHub Everywhere

The Transcript of the call with market analysts illustrates Microsoft’s intention to discuss Copilot and AI at every opportunity and the continued fascination in the market about whether the huge investment in datacenter capacity will ever generate a return. CFO Amy Hood said that Microsoft spent $19 billion on capital expenditure during the quarter, almost all of it related to Cloud and AI. The spend breaks down roughly 50/50 between infrastructure and servers. In a response to a later question, Satya Nadella said that “the kit” for a datacenter represented about 60% of the total spend. Either way, Microsoft is spending heavily to support Cloud and AI.

Microsoft reported that the number of customers using Copilot for Microsoft 365 grew 60% quarter over quarter. Microsoft also said that the number of customers with over 10,000 Copilot for Microsoft 365 seats doubled quarter over quarter. However, in neither case did they give a firm number, preferring instead to mention some marquee names, such as the decision by EY to deploy Copilot for Microsoft 365 to 150,000 seats.

Given the huge marketing effort by Microsoft to push Copilot for Microsoft 365, it’s unsurprising to see substantial customer interest in the product. Everyone is curious about how generative AI can help people do their job smarter and better, so many tests are ongoing. One thing I hear time after time is the difficulty of measuring saved time or better outcomes, plus how to assess if people use saved time in a productive manner. After all, being able to save five minutes to draft and send an email isn’t much good if the time saved is devoted to non-essential tasks.

Satya Nadella said that GitHub Copilot used by more than 77,000 organizations (up 180% year over year). GitHub Copilot now represents 40% of GitHub Revenue. By itself, GitHub Copilot is larger in revenue terms than the entire GitHub was when Microsoft bought it. I don’t think this is surprising. I use GitHub Copilot with Microsoft 365 PowerShell every day and consider it to be an absolute bargain for what it delivers. Even though it is capable of creating some odd code, GitHub Copilot is a great example of how AI can be very effective when given limited goals.

New Fiscal Year, Continued Growth

It seems clear that the Microsoft Cloud will continue to grow revenue during Microsoft’s 2025 fiscal year. The growth probably won’t come from vast quantities of new Office 365 users. Instead, it will come from convincing customers to upgrade to more expensive licenses (like Office 365 E3 to E5), premium licenses, and AI.

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.

Monthly Update #110 Available for Download

The Office 365 for IT Pros eBook team is delighted to announce that the first monthly update (#110) is available for the Office 365 for IT Pros (2025 edition) eBook. Subscribers can download the files for the update using their Gumroad account or the link in the receipt they received via email. For more information about how to download updates, please see our FAQ. The update covers both the Office 365 for IT Pros and Automating Microsoft 365 with PowerShell books.

Change Log

Many of the changes made in update #110 are minor in nature because they’re grammatical or formatting updates found after the initial publication of Office 365 for IT Pros (2025 edition) in July. Alongside the fixes, we have included a bunch of information about new functionality and changes Microsoft is making within the ecosystem, like the retirement of Office Connectors in Teams. See our change log for more information.

Reviews

It’s great to see so many nice reviews for Office 365 for IT Pros (2025 Edition). If you’d like to add a review for the book, please do so by following the Gumroad guidelines.

Kindle Versions and Paperbacks

We decided not to publish Office 365 for IT Pros (2025 edition) as a Kindle eBook. However, we do publish Automating Microsoft 365 with PowerShell in both Kindle and paperback formats. Publishing a paperwork edition means that every hyperlink in the eBook version must be converted into a footnote. When writing an eBook, you don’t think about the number of hyperlinks because you know that readers can access the hyperlinks in both the PDF and EPUB formats. As it turns out, the 250-page PowerShell book includes 199 hyperlinks.

The reaction to the paperback version of Automating Microsoft 365 with PowerShell has been very interesting. People seem to really like it, so we’ll persist with the venture. Of course, you can’t update printed content, so people who buy copies of the paperback get whatever content is available at that time. We will update the printed content whenever we update the Kindle eBook, so multiple versions of the text will be in use.

Creating a print version of the main book is still beyond our means. The main challenge is that the book spans too many pages for online book publishers to handle. I guess we could split the book in half and publish two separate printed books, but that seems like a whole heap of work for an uncertain reward. Right now, I prefer to dedicate whatever time is available to making sure that the content of Office 365 for IT Pros is as up-to-date and accurate as possible.

Upgrading Office 365 for IT Pros Subscriptions

Every year, we offer subscribers the chance to extend their subscriptions to cover the new edition of Office 365 for IT Pros. The discounted price to extend subscriptions escalated over time as follows:

• Update before July 21 for $16.95.
• Update before August 5 for $19.95.
• Update after August 5 for $29.95.

The intention of the escalating cost to renew subscriptions is to reward people who have supported us over the years by renewing immediately each time a new edition appears.

People extend their subscriptions by using a special URL that we provide to subscribers. This year, I’ve noticed a bunch of people who used the special URL to take out a subscription who never subscribed before. When I asked how they obtained the code, I was told that they received the URL from a coworker or friend who thought that they’d like to benefit from the reduced price.

Although I appreciate the friendly gesture, this isn’t how the scheme is supposed to work. If you receive a special URL from us, it’s for your use only. Sharing the URL with others deprives us of revenue and undermines our ability to make discounted subscriptions available.

We haven’t yet decided what to do about those who used a discount code they weren’t entitled to. We could cancel the subscription and remove their access to book files. However, that’s a pretty hard-line attitude to take when people might have been unaware that they were abusing a subscription. So for now we’ll simply ask our loyal subscribers not to share URLs for discounts with others.

If you subscribed to Office 365 for IT Pros (2024 edition), please use the code we sent via email to extend your subscription by August 5. $19.95 isn’t a lot for the Office 365 for IT Pros and Automating Microsoft 365 with PowerShell eBooks, is it?

Teams ACM Makes It Easier to Manage Access to Teams Apps

Over the years, I have become accustomed to using app permission policies to control access to Teams apps. Now a new sheriff is in town and App-centric management (ACM) is the replacement for app permissions policies.

ACM means that apps store a permission list to say who can use the app. The permission can be:

• Everyone: The app is available to anyone in the organization, including guests.
• Specific users or groups: The app is available only to selected users (including guests) and groups. The groups can be Microsoft 365 groups, security groups, dynamic groups, and distribution lists.
• No one: The app is blocked to everyone in the organization.

Microsoft says that ACM simplifies the app management process because administrators no longer need to edit (or create) an app permission policy and assign the policy to users to allow the users to install apps. Instead, an administrator select the target app in the Teams admin center (Figure 1) and edit the availability for the app to whatever permission should apply.

Getting to Teams ACM

Moving from app permission policies to ACM is a one-time, non-reversable migration run by invoking a wizard in the Teams admin center. You can pause the migration at any time but will eventually have to let it run to completion (Figure 2). During this process, the wizard checks the app permission policies currently defined in the tenant and updates the apps specified in the policies with equivalent ACM permissions to allow users to continue to access the same set of apps.

The time required for the migration depends on the number of app permission policies in the tenant and the number of ACM assignments the wizard must make. The tenant completed in just a few minutes in my tenant, but I suspect that it might take much longer in a large tenant.

Once the migration completes, you cannot access app permission policies through the Teams admin center, but you can with cmdlets from the Teams PowerShell module. For example:

Get-CsTeamsAppPermissionPolicy -Identity 'Global'

The apps defined in the policy are listed in the DefaultCatalogApps and GlobalCatalogApps property. To check the permissions assigned by the migration, select any app and use its identifier to find the app name.

Get-TeamsApp -Id 44263ed4-f1ac-4e96-93aa-d24dd50459ea

ExternalId Id                                   DisplayName      DistributionMethod
---------- --                                   -----------      ------------------
           44263ed4-f1ac-4e96-93aa-d24dd50459ea Channel calendar store

Now go to the Teams admin center and check the availability of the app (Figure 3).

The transition to ACM is simple and should not cause any problems for tenants. The best thing about the changeover is that it removes one policy from the set required to manage user accounts and that can’t be a bad thing.

Better Permission Visibility for Teams Apps

Teams Apps use Graph permissions to access user and organizational data. The app developer requests consent for the permissions, which then need an administrator to grant consent.

Details of permissions are available in app properties. However, the presentation of their details has been a tad obscure in the past. Microsoft introduced a change earlier this year (MC713370) to do a better job of highlighting the permissions and the data that the permissions allow access to. For instance, the Teams channel calendar app can use the permissions shown in Figure 4. The text is deliberately geared for humans to understand.

Figure 4 covers an app that has been granted consent. Figure 5 shows the increased level of detail available to an administrator before they grant consent to an app.

Of course, to fully comprehend what data the app is asking to be allowed access, administrators still need to understand Graph permissions and the differences between delegated and app permissions. But at least the information is there and presented in a way that makes it easy to look up a permission to check it out.

Small But Important Changes for Teams App Management

With over 2,500 apps available in the Teams app store, it’s important that every detail of managing apps is as simple and precise as possible. Changes like the changeover to ACM and better presentation of Graph permissions might seem small in the overall scheme, but they really make a difference, and that’s what counts.

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

Microsoft 365 Archive Takes On Unlicensed OneDrive Sites

What are we to make of the announcement in message center notification MC836942 (26 July 2024) that Microsoft plans to charge for storing unlicensed OneDrive for Business sites through Microsoft 365 Archive?

Slipped into the newsfeed late on a Friday afternoon (the recommended way to share bad news), Microsoft’s announcement is both unexpected and entirely predictable. It’s unexpected because Microsoft hadn’t communicated their intention of doing this during high-profile conference keynotes (perhaps because of the bad news element). It’s predictable because Microsoft hadn’t the tool to handle unlicensed OneDrive sites until Microsoft 365 Archive (Figure 1) came along. Archiving unlicensed sites makes a ton of sense.

An unlicensed OneDrive site can exist for several reasons. The most common is that the site comes within the scope of a retention policy (or items within the site have retention labels). In this situation, OneDrive must retain the sites even after the retention period configured for deleted OneDrive accounts (by default 30 days) elapses. It’s also possible that the owner’s account no longer has a OneDrive license.

The simplest reading for this story is that Microsoft wants organizations to clean up (remove) unlicensed OneDrive sites. It could also be a step to help organizations manage the removal of OneDrive sites belonging to ex-employees better. These reasons are valid, but as often the case with Microsoft, some other influences might also contribute to the decision.

Helping Copilot for Microsoft 365

Copilot for Microsoft 365 might be another factor in this story. By their very nature, unlicensed OneDrive sites are unmanaged and prone to contain obsolete and unwanted information. Keeping the obsolete sites online and available for Copilot to access increases the chances that Copilot will reuse some of the material contained in the sites in its responses to user prompts. That’s obviously a bad thing.

As I noted on May 20, archiving obsolete material can help organizations deal with the digital debris found in obsolete SharePoint Online sites. The same applies to obsolete OneDrive sites.

Payment for Archived OneDrive Sites

Like SharePoint Online sites managed by Microsoft 365 Archive, Microsoft will charge to archive unlicensed OneDrive sites. The charge is minimal ($0.05/GB per month) with a $0.60/GB fee to reactivate an archived site. Like other Microsoft 365 Archive operations, payments must be made through an Azure subscription.

The interesting thing is that reactivation lasts 30 days after which the site becomes archived again. It seems like this is a strong hint for someone to use the time to extract any required information from the reactivated OneDrive site before removing the account.

One thing that’s unclear is what happens if you don’t set up an Azure subscription. From the text, it seems like OneDrive will automatically move the unlicensed sites into Microsoft 365 Archive and the sites will remain there in an inaccessible (can’t be reactivated) state until the organization creates an Azure subscription and links the subscription to Microsoft 365 Archive. However, even when an Azure subscription is not present, archived sites remain indexed and available to Purview compliance solutions like eDiscovery, so administrators can still run content searches to find and export content from the archived sites.

I don’t think archiving unlicensed OneDrive sites will be a huge revenue generator for Microsoft. But what it might do is bring Microsoft 365 Archive to the attention of organizations that have not used it before who might then start to use the product to archive obsolete SharePoint Online sites. The big attraction here is that moving SharePoint Online sites to Microsoft 365 Archive frees up expensive SharePoint storage.

Next Steps

To help tenant administrators understand how many unlicensed OneDrive sites are present, Microsoft plans to introduce a new report for OneDrive in the SharePoint Online admin center. The new report should be available in all tenants worldwide by August 16, 2024. The report notes why OneDrive accounts are unlicensed. Tenant administrators can’t do much about sites required for retention, but they can remove the other sites.

January 27, 2025, marks the point when Microsoft moves unlicensed OneDrive sites into Microsoft 365 Archive and Azure subscriptions are required to reactivate sites. The six-month period before automatic archiving of OneDrive sites in an unlicensed state for 90 days begins should be enough time to discuss and decide how to accommodate this new aspect of OneDrive management.

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.

Find Manager for Entra ID Accounts is Easy at the Individual Level

Following Friday’s discussion about needing to update the script to create the Managers and Direct Reports report, I was asked what’s the best way to find managers assigned to Entra ID user accounts (Figure 1).

It is simple to find and report the manager for an individual user account with PowerShell. For instance, to find Sean Landy’s manager, run the Get-MgUserManager cmdlet. The return value is the object identifier for the manager’s account, so to find details of the manager, we must fetch it from the data stored in the additionalProperties property.

Get-MgUserManager -UserId Sean.Landy@office365itpros.com | Select-Object -ExpandProperty additionalproperties

Key               Value
---               -----
@odata.context    https://graph.microsoft.com/v1.0/$metadata#directoryObjects/$entity
@odata.type       #microsoft.graph.user
businessPhones    {+353 1 8816644}
displayName       James Ryan
givenName         James
jobTitle          Chief Story Teller
mail              James.Ryan@office365itpros.com

The Manager property is in the set available to Get-MgUser, but it must be fetched to be available for processing. The property is a reference to another account, so it must be resolved by using the ExpandProperty parameter. Again, the manager’s display name is retrieved from the additionalProperties property.

$UserData = Get-MgUser -UserId Sean.Landy@office365itpros.com -Property displayname, manager -ExpandProperty Manager

$UserData | Format-Table @{n='Employee'; e={$_.displayname}}, @{n='Manager'; e={$data.manager.additionalproperties['displayName']}}

Employee   Manager
--------   -------
Sean Landy James Ryan

Find the Managers for Multiple Users

Challenges emerge when dealing with multiple user accounts. For example, it’s common to retrieve the set of licensed user accounts in a tenant with a complex query that checks for the presence of at least one license. However, adding the ExpandProperty parameter to this command stops it working:

[array]$users = Get-MgUser -Filter "userType eq 'Member' and assignedLicenses/`$count ne 0" -ConsistencyLevel eventual -CountVariable UsersFound -All -PageSize 999 -Property Id, userPrincipalName, displayName, Manager, Department, JobTitle, EmployeeId -ExpandProperty Manager

The error is not terribly helpful:

Expect simple name=value query, but observe property 'assignedLicenses' of complex type 'AssignedLicense'.

Removing the ExpandProperty parameter from the command makes it work, but the Manager property is not populated.

Any filter to find user accounts that needs to populate the Manager property is restricted to a simple query. Here’s an example of a query to find all member accounts and populate the Manager property. A client-side filter then reduces the set to accounts with an assigned manager:

[array]$EmployeesWithManager = Get-MgUser -All -PageSize 999 -Property Id, DisplayName, JobTitle, Department, City, Country, Manager -ExpandProperty Manager -Filter "UserType eq 'Member'"| Where-Object {$_.Manager.id -ne $null}

$EmployeesWithManager | Format-Table id, displayname, @{Name='Manager';expression={$_.Manager.additionalProperties.displayName}} -Wrap

Id                                   DisplayName                             Manager
--                                   -----------                             -------
a3eeaea5-409f-4b89-b039-1bb68276e97d Ben Owens                               James Ryan
d446f6d7-5728-44f8-9eac-71adb354fc89 James Abrahams                          Kim Akers 
cad05ccf-a359-4ac7-89e0-1e33bf37579e James Ryan                              René Artois

The results generated by this code are acceptable because a user account with an assigned manager is probably one used by a human. The account probably has licenses too. Obviously, any account that hasn’t got an assigned manager will be left out of the report.

Looking for User Accounts without Managers

Things get a little more difficult if we reverse the client-side filter and look for member accounts that don’t have an assigned manager:

[array]$EmployeesWithoutManager = Get-MgUser -All -PageSize 999 -Property Id, DisplayName, JobTitle, Department, City, Country, Manager, UserPrincipalName -ExpandProperty Manager -Filter "UserType eq 'Member'"| Where-Object {$_.Manager.id -eq $null}

In addition to user accounts lacking managers, the set of resulting accounts will include utility accounts created by Exchange Online, including:

• Room and equipment accounts.
• Shared mailbox accounts.
• Accounts used for Microsoft Bookings.
• Accounts synchronized from other tenants in a multi-tenant organization (MTO).
• Accounts created for submission of messages to the Exchange Online High Volume Email (HVE) solution.
• Accounts created for Teams meeting rooms.
• Service accounts created by the tenant for background processing and other reasons.

In a medium to large tenant, there might be thousands of these kinds of accounts cluttering up the view. To remove the utility accounts, create an array containing the object identifiers of the owning accounts:

[array]$CheckList = Get-ExoMailbox -RecipientTypeDetails RoomMailbox, EquipmentMailbox, SharedMailbox, SchedulingMailbox -ResultSize Unlimited | Select-Object -ExpandProperty ExternalDirectoryObjectId

If the tenant uses HVE, add the account identifiers for the HVE accounts to the array.

Get-MailUser -LOBAppAccount | ForEach { $Checklist += $_.ExternalDirectoryObjectId }

Now filter the account list to find those that don’t appear in the list of utility mailboxes:

$EmployeesWithoutManager = $EmployeesWithoutManager | Where-Object {($_.Id -notin $Checklist)}

If the tenant is part of a multi-tenant organization, this filter removes the accounts synchronized from the other tenants:

$EmployeesWithOutManager = $EmployeesWithoutManager | Where-Object {$_.UserPrincipalName -notlike "*#EXT#@*"}

Eventually, you’ll end up with hopefully a very small list of employees without assigned managers and can take the necessary action to rectify the situation.

Entra ID Should Mark Utility Accounts

The problem of dealing with utility accounts that end up in Entra ID with the same status as “human” user accounts is growing. Applications create new member accounts without thinking about the consequences. No problem is apparent because no licenses are consumed, but the steps needed to cleanse the set of accounts returned by Entra ID with cmdlets like Get-MgUser are another trap waiting for the unwary administrator. Microsoft really should do better in this area, like creating a new “utility” value for the UserType property. Would that be so bad?

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.

Counting Fetched Objects is a Hard Computer Problem

All software has its own foibles, something clearly evident in the Microsoft Graph PowerShell SDK. You become accustomed to the little oddities and workaround known issues and all is well. But when the underlying foundation of software causes problems, it can cause a different level of confusion.

Take the question posed by MVP Aleksandar Nikolić on Twitter about how many accounts a Get-MgUser command will return (Figure 1).

The answer is 4 even though the command explicitly requests the return of the top 3 matching objects. Why does this happen? It’s all about Graph pagination and the way it’s implemented in Microsoft Graph PowerShell SDK cmdlets.

Pagination and Page Size

To understand what occurs, run the command with the debug switch to see the actual Graph requests posted by Get-MgUser. The first request is against the Users endpoint and requests the top 2 matching objects.

https://graph.microsoft.com/v1.0/users?$top=2

Note that the Graph request only includes a $top query parameter. This sets the page size of the query and matches the PageSize parameter in the Get-MgUser command. The Top parameter used with Get-MgUser has no significance for the Graph query because it’s purely used to tell PowerShell how many objects to show when the command completes. The use of Top in different contexts is confusing, but few people look behind the scenes to see how the cake is made.

The Graph request respects the page size and fetches 2 objects. However, we asked for 3 objects so some more work is needed to fetch the outstanding item. Microsoft’s Graph documentation says “When more than one query request is required to retrieve all the results, Microsoft Graph returns an @odata.nextLink property in the response that contains a URL to the next page of results.” The skiptoken or nextlink lets the command know that further data remains to be fetched, so it continues to fetch the next page with a request that includes the skiptoken:

https://graph.microsoft.com/v1.0/users?$top=2&$skiptoken=RFNwdAIAAQAAAFI6NWUyZWI1YWIub2ZmaWNlMzY1aXRwcm9zLmNvbV9lbWVhLnRlYW1zLm1zI0VYVCNAUmVkbW9uZEFzc29jaWF0ZXMub25taWNyb3NvZnQuY29tKVVzZXJfYmNmYTZlY2ItY2M1Yi00MzU3LTkwOWMtMWUwZTQ1MDg2NGUzuQAAAAAAAAAAAAA

The follow up request fetches the remaining page containing 2 more objects and completes processing. The person running the command sees 4 objects from the two pages. In effect, the Get-MgUser cmdlet ignores the instruction passes in the Top parameter to only show 3 objects.

The same processing happens with different combinations of page size and objects requested, and it’s the same for other cmdlets too. For instance, the command:

Get-MgGroup-Top 7 -PageSize 3

Returns 9 group objects because 3 page fetches are necessary. It seems odd, and it’s odder still that running Get-MgGroup -Top 7 without specifying a page size will return exactly what we asked for (7 objects), while using a larger page size returns all the objects that can be packed into the page:

Get-MgUser -Top 3 -PageSize 8 | Format-Table Id, DisplayName

Id                                   DisplayName
--                                   -----------
44c0ca9c-d18c-4466-9492-c60c3eb78423 12 Knocksinna (Gmail)
bcfa6ecb-cc5b-4357-909c-1e0e450864e3 Email Channel for Exchange GOMs
da1288d5-e63c-4118-af62-3280823e04e1 GOM Email List for Teams
de67dc4a-4a51-4d86-9ee5-a3400d2c12ff Guest member - Project Condor
3e5a8c92-b9b6-4a45-a174-84ee97e5693f Arthur Smith
63699f2f-a46a-4e99-a068-47a773f9af11 Annie Jopes
7a611306-17d0-4ea0-922e-2924616d54d8 Andy David 
d8afc094-9c9b-4f32-86ee-fadd63b112b2 Aaron Jakes

Frustrating Paging and Display

The typical page size for a Graph request is 100 objects (but this can differ across resources), so it’s unusual to use the Top parameter to request a limited set of objects that’s larger than the default page size. Usually, I bump the page size up to 999 (the maximum) to reduce the number of requests made to fetch large quantities of user or group objects. Using a large page size can significantly affect the performance of queries retrieving large numbers of objects.

The conclusion is that changing the default page size for a Microsoft Graph PowerShell SDK cmdlet overrides the Top parameter. This kind of thing is commonly known as a bug and it’s very frustrating. The Graph requests work perfectly but then something gets in the way of restricting the output to the required number of objects.

Selecting Properties to Use

The same kind of problem arises when Microsoft changes the way Graph requests respond. For instance, this week I was asked why a script I included in an article about reporting Entra ID Managers and their Direct Reports didn’t work. The article dates from April 2023, so neither the text nor the script code is ancient.

Sometime in the intervening period, Microsoft made a change that affected the set of default properties returned by the Get-MgUser cmdlet (probably in the transition to V2.0 of the Microsoft Graph PowerShell SDK). The result meant that some of the properties returned when the script was written are not returned today. The fix is simple: use the Property parameter to specify the properties you expect to use in the script:

[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" -ConsistencyLevel eventual -CountVariable Records -All -PageSize 999 -Property Id, displayName, userprincipalName, department, city, country

I believe Microsoft made the change to reduce the strain on Graph resources. It’s annoying to be forced to update scripts because of external factors, especially when cmdlets appear to run smoothly and generate unexpected output.

More Handcrafting Required for the Microsoft Graph PowerShell SDK

The issues discussed here make me think that Microsoft should dedicate more engineering resources to perfecting the Microsoft Graph PowerShell SDK instead of creating a new Entra PowerShell module that duplicates Microsoft Graph PowerShell SDK cmdlets. The statement’s been made that the Entra cmdlets are better because they’re “handcrafted,” which I understand means that humans write the code for cmdlets. T

It’s nice that the Entra module gets such attention, but it would be nicer if the Graph PowerShell SDK received more human handcrafting and love to make it more predictable and understandable. Even Entra ID would benefit from that work.

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.

Pondering the Right Way to Delete OneDrive for Business Accounts

The July 22 article about choosing between shared and inactive mailboxes to preserve ex-employee content created a lot of discussion. I guess the possibility of exposing PII data inadvertently through access to mailboxes converted to shared mailboxes hadn’t been considered by many. In any case, this is a real concern because no organization wants to open itself up to potential lawsuits.

As I chatted with people, it became clear that some tenants don’t have an automated account preservation process. It might be acceptable in a small organization to rely on the account deletion wizard in the Microsoft 365 admin center (Figure 1) because it takes care of the essentials, like offering the option to convert the deleted user’s mailbox into a shared mailbox and giving another user access to their OneDrive for Business account.

The Other Bits Surrounding Microsoft 365 Account Deletion

Deleting a user account through the Microsoft 365 admin center is a swift and certain way to stop access. However, sometimes a little more subtly is needed. For instance, you might want to:

• Add the user to a special retention policy so that their mailbox becomes inactive rather than being made shared.
• Force sign-outs from the account by revoking access. Instead of immediately deleting an account, I usually revoke access, disable the account, and change its password. All are continual access evaluation (CAE) events monitored by Entra ID that cause a user to loose access to apps.
• Issue wipe commands to mobile devices. The process depends on the devices in use and the management software with the aim to remove corporate data from the devices. For instance, if you use Exchange Online mobile device management, Outlook clients support a Wipe Only command, meaning that only mailbox data is covered. Other clients use the Account Only Remote Wipe Device command to do the same thing. Don’t use a Wipe Only command with something like the Apple iOS mail client, as this will wipe all device data.

All these steps are very scriptable. The basics of revoking access from an account are covered in this article and you can find an example account removal script in GitHub to use as the basis for development to cover the requirements of your organization.

The OneDrive for Business Account Deletion Issue

Dealing with OneDrive for Business accounts owned by deleted users pose two issues. First, OneDrive for Business is the designated repository for personal information, so the likelihood of PII data being present is very high. Microsoft has done as much as possible to force applications to save files in OneDrive for Business. The upshot is that files containing personal information are now more likely to be in the cloud than on a local hard drive.

Second, the sheer volume of files stored in OneDrive for Business grows steadily. Office documents, PDFs, Loop components shared in Teams and OneDrive, Teams meeting records, Whiteboards, Stream videos, and even PowerShell modules can end up in a person’s OneDrive for Business account. Parsing out what’s there and what needs to be recovered for future use by the business is a difficult task.

Organizations can configure automatic access delegation, which means that a user’s manager is automatically made a site administrator of the user’s OneDrive for Business account when a user is deleted. A secondary owner can also be defined in case a manager is not defined for the account (Figure 2).

I don’t think I have changed the settings shown in Figure 2 for years. Nominating the Global tenant administrator account as a secondary owner is not a great idea. It’s better to use a designated account with no administrative roles to act as the backstop for access to the OneDrive for Business accounts owned by deleted users.

Two other questions arise here. First, it’s important to keep manager information updated and accurate to have any chance that access delegation will work. Some form of automated processing is likely required on a periodic basis to ensure that user accounts are linked to the correct managers. Second, even if the right person is known, will 30 days be enough to review and extract all the relevant information from the OneDrive for Business account?

Thirty days is the default, and you can set a tenant-wide retention period of up to 10 years through the settings section of the SharePoint admin center (Figure 3).

The Time Conundrum

Thirty days is too short to allow a stressed manager the time to conduct a full review of what could be gigabytes of data created by multiple applications. Ten years is obviously too long to keep the OneDrive for Business account for a deleted user in place. Somewhere in the middle might suit, but the organization still depends on the manager to perform a full review of the account contents before the retention period ends.

The trick is to have enough time use the 30-day default retention period for a quick review of contents and then store the OneDrive for Business account somewhere safe from where information can be retrieved if necessary. I already mentioned adding the user’s mailbox to a special retention policy before deletion to force Exchange Online to make it into an inactive mailbox. I also add the OneDrive for Business account to the same retention policy. The retention period is six months, which is enough to allow information recovery by running an eDiscovery content search against the account and exporting the results. Yes, it’s a pain to ask the compliance team to run a search, but this approach avoids problems with PII because the organization can demonstrate controlled access to the data and the retention period can be as long as required.

This issue is not going to get any easier. Microsoft designed the current OneDrive for Business retention and deletion implementation years ago (just look at the old-style UI in Figure 2). OneDrive for Business was simple then. It’s not now. The basic idea about keeping an account around for a period after the deletion of its user’s account is fine. It’s determining what’s in the account and what needs to be kept that’s the most difficult task, even with a nice print-out of the account’s files.

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.

Controlling Stream Video Versions Designed to Consume Less Disk Storage

Microsoft 365 message center notification MC797116 (30 May 2024, Microsoft 365 Roadmap item 395380) addresses the question of storage consumption in SharePoint Online and OneDrive for Business for videos managed by Stream. The issue is simple. Any time a video owner updates the non-video content, Stream creates a brand-new version of the video that consumes the same amount of storage as the original.

Many reasons exist to change something for a video, like editing the metadata (title, description (Figure 1), or chapters), editing the transcript to correct flaws in the automatic text generated by the transcription bot, adding callouts through the interactivity feature, and so on.

Many Stream Video Versions

Behind the scenes, SharePoint Online or OneDrive for Business treat changes to non-video content in the same way as they handle changes made to Word documents or Excel spreadsheets and create new versions. The impact on storage is obvious if you look at the version history for a video. Figure 2 shows the version history for a 402 MB video that consumes 5,226 MB for the 13 versions stored by OneDrive.

Usually, this method of storing versions doesn’t affect OneDrive for Business accounts. Given that most videos are likely Teams meeting records, few videos are updated, and the version count remains small. In addition. The large storage quotas assigned to OneDrive for Business accounts accommodate a few extra versions without a problem.

The issue is more obvious in SharePoint Online where the tenant-wide storage quota comes under pressure from user demand for document storage, retention processing, and versioning. Buying additional SharePoint Online storage is expensive, and few tenants want to go down that route.

Microsoft announced intelligent versioning for SharePoint Online in July 2023, but according to Microsoft 365 roadmap item 145802, the rollout won’t happen until August 2024. Good things take time to get right.

The Change in the Creation of Stream Video Versions

The change Microsoft is introducing to Stream starting mid-July 2024 with the intention to complete worldwide deployment by late August 2024 is to stop generating new versions of videos for changes that do not affect video content. This is a reasonable approach, and it will prevent the kind of video version sprawl seen in the past (as obvious in Figure 2).

The downside is that metadata changes made to Stream videos are irrecoverable. If you restore a version of a video, you get the metadata available at that time. Any subsequent changes made to video metadata are ignored.

These actions no longer create a new version:

• Editing the title or description from within the Stream browser client.
• Adding or editing chapters, transcripts, captions, or interactivity (callouts or forms).
• Toggling media settings (show/hide about video, chapters, interactivity, comments, analytics, etc.).
• Adding audio tracks.

Any change that affects the video content, like trimming some seconds from the start or end of a video, will force Stream to generate a new version of the video. Once the change reaches your tenant, it goes into effect and cannot be reverted to the previous behavior. The change has no effect on existing videos and will not remove any versions that are already being stored. Microsoft says that if you want to remove extraneous versions, you’ll need to wait for SharePoint Intelligent versioning to appear in your tenant and use that to clean up unwanted video versions stored in SharePoint sites.

Storage is Not a Pressing Problem for OneDrive

At this point, I am unsure if the same approach can be taken to clean up video versions in OneDrive for Business accounts. However, given that storage is much less of an issue in OneDrive than it is in SharePoint Online, and that Teams meeting recordings age out over time, this is probably not a big problem. If you’re worried about OneDrive, run the OneDrive for Business account storage and quota report and see if any account needs attention. I bet hardly any will.

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.

Different Forms of Cost Centers

On June 20, I announced version 1.9 of the Microsoft 365 Licensing Report. A month later, version 1.92 is available for download from GitHub. This version adds support for reporting licensing costs by cost center. Here’s how it works.

Ever since Exchange Server added a set of 15 custom attributes to mailboxes, organizations have used the attributes to hold all kinds of information. Cost center numbers come in different formats. In Digital Equipment Corporation, the numbers (or rather, designation) were values like 8ZW and 9HPE. In Compaq and HP, the values were more like 1001910. In any case, organizations often store cost center values in custom attributes to allow a more precise assignment of costs than is possible using standard Entra ID account properties like city, department, and country.

For cost center reporting to work, it’s obvious that accurate cost center numbers must be present in Exchange mailbox properties. Sometimes cost centers are added when users join an organization and receive a mailbox and are never updated afterwards. In other instances, organizations have synchronization mechanisms in place to ensure that if a change is made to an employee’s cost center (usually in a HR database), that change also happens for mailbox properties.

It might also be possible to implement cost center reporting based on managers (if managers manage cost centers). To do this, the script would have to find all the managers and assume that any direct reports are in the same cost center as the manager. I discounted this method and chose the simpler approach of using cost centers stored in a custom attribute, but it wouldn’t be difficult to code because Entra ID links stores details of the manager for each user account. Storing a manager for an account is not mandatory, so the same problem of data accuracy and availability might be present.

Microsoft 365 Licensing Report Script Changes to Support Cost Centers

The script supports cost center reporting through a variable called $CostCenterAttribute, which holds the name of the custom attribute to use. The name stored in the variable is the Entra ID property name rather than the Exchange name, so it’s a value like extensionAttribute1. If $CostCenterAttribute is not defined, the report doesn’t attempt to generate any information about licensing cost per cost center.

Exchange Online synchronizes the values of the mailbox custom attributes to the Entra ID user accounts of the mailbox owners. The custom attributes are stored in a property called OnPremisesExtensionAttributes. The Get-MgUser command to fetch user account details is amended to include OnPremisesExtensionAttributes in the set of retrieved properties. A set of cost centers found in user accounts is derived from the information retrieved by Get-MgUser.

When scanning user accounts for license information, the script extracts the cost center for each account and stores it along with other licensing data in a PowerShell list. This allows the report to later loop through the set of cost centers found in user accounts and calculate the licensing spend for each cost center, much like the licensing spend analysis done for departments and countries.

Reporting Licensing Spend by Cost Center

The script then outputs the cost center licensing spend analysis along with the other spending data in the summary part of the report (Figure 1).

Custom Attributes Open Up Lots of Opportunity

In this instance, the Microsoft 365 licensing report uses a custom attribute to store a cost center value. It is easy to see how custom attributes could be used for other analysis. For example, if a custom attribute held details of major projects, you could report the licensing spend for each project. All of this is basic PowerShell, so feel free to experiment!

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

User Privacy a Major Concern When People Access Ex-Employee Mailboxes

The mailboxes of ex-employees can hold valuable information that an organization needs to retain for either business or compliance reasons. Two options are available:

• Convert the mailbox into a shared mailbox. This option is available in the Exchange admin center (EAC).
• Use a retention hold to make the mailbox an inactive mailbox after deleting the user account.

Each method offers different advantages and disadvantages. I discussed this topic a couple of years ago. At the time, I concluded that a shared mailbox might be the better default option. Now I am not so sure for the reasons explained below.

The Shared Mailbox Option

Converting a mailbox into a shared mailbox is a popular option. The user account which owns the mailbox must be licensed before EAC reveals the option, so it’s an action that must happen before removing the user account. If the shared mailbox holds more than 50 GB of content or has an archive mailbox, it must be assigned an Exchange Online license. Plan 1 covers the archive mailbox while Plan 2 extends the mailbox quota from 50 GB to 100 GB.

Conversion only changes the mailbox type. Everything else remains the same, including the account user principal name and password. Ideally, these properties should be updated to reflect the new mailbox status. In addition, you should remove any unrequired licenses from the account and disable it to prevent people from signing into the account.

People can still access the shared mailbox even when its account is disabled if they are granted Exchange Online permissions to open the mailbox. Easy access to a shared mailbox that once belonged to an ex-employee is a major advantage, but as we’ll discuss later, this is a double-edged sword.

The Inactive Mailbox Option

Following the deletion of an Entra ID account, Exchange Online checks for the presence of any retention holds on the mailbox. A hold on mailbox content could originate from an eDiscovery case, a retention policy, or retention labels. In all cases, the presence of the hold means that the mailbox cannot be removed until the retention period set for the hold lapses. Several holds could exist on the mailbox, and when this happens, Exchange Online must retain the mailbox until the last hold expires, at which time Exchange Online permanently removes the mailbox. Inactive mailboxes do not require any form of license.

To retain the mailbox, Exchange Online makes it inactive. An inactive mailbox is a form of soft-deleted mailbox. Unlike a shared mailbox, an inactive mailbox is invisible for normal operations. If the need exists to access the mailbox online, it can be recovered (create a new mailbox) or restored (merge into an existing mailbox). Alternatively, if only some content is required from an inactive mailbox, compliance administrators can run a content search against the mailbox to find and export the content.

An advantage of using inactive mailboxes over shared mailboxes is that Microsoft 365 performs the remaining steps in the account clean-up procedure such as removing the user’s OneDrive account (preventing future problems with managing unlicensed OneDrive accounts). Also, when an account is deleted, it is removed from membership of distribution groups, teams, security groups, and Microsoft 365 groups. Shared mailboxes keep their memberships.

The Privacy Issue

In an era when personal privacy is more important than ever before, converting the mailbox belonging to an ex-employee to a shared mailbox creates some concerns. For instance, people often store non-business information in email, so how do you handle personally identifiable information (PII) found in the mailbox? Information like bank account numbers, passport numbers, and so on could be present. Once access is granted to the mailbox to allow other employees to harvest business information that data becomes available to anyone with access to the mailbox.

In places like the European Union and California, ex-employees are entitled to ask for information relating to them to be extracted from systems like Microsoft 365 and provided to them in a portable form. Responding to GDPR Data Subject Requests for information held in Microsoft 365 can take a lot of time and effort. Microsoft Priva is a solution to help respond to and manage data subject requests. Nice as it is to have software available to manage data subject requests, it’s a lot better to avoid heightening the risk that ex-employees will make data subject requests, which they might do if they know that their mailbox is open for access by other people.

Because of the risk of inadvertent disclosure of PII, I prefer not to transform user mailboxes into shared mailboxes. It is a more prudent approach to retain the mailboxes of ex-employees as inactive mailboxes for a limited period (say six months). If necessary, content can be extracted from inactive mailboxes by compliance administrators. This process can be tightly controlled to ensure that an obvious and well-documented business need exists to extract the data.

Think About Using Shared Mailboxes

Old habits die hard. I think the default tendency to use shared mailboxes is an old habit inherited from on-premises servers where inactive mailboxes don’t exist. Often what works for on-premises organizations is not the most efficient method in the cloud.

It might still be the case that converting a user mailbox into a shared mailbox is the right action for your organization. But before you make that decision, take the time to consider how you deal with ex-employee mailboxes and make sure that the organization is protected from the consequences of inadvertent disclosure of PII.

PS. A similar PII issue can surface in the OneDrive for Business accounts of deleted users. See this article for details.

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

Disabling Self-Service Purchases of Microsoft 365 Licenses

I dislike the mechanism which allows users to purchase licenses like Teams Premium without tenant administrator oversight or knowledge. I strongly believe that license management is a core competence of tenant administrators and that allowing users to purchase their own licenses is a guaranteed way to waste money on underused or unwanted licenses. Self-service licenses operate under the radar and can’t be detected by normal license reporting, even by the redoubtable Microsoft 365 tenant licensing report.

Starting with Power BI Pro and Premium licenses in 2019, Microsoft has gradually built out a set of 25 self-service purchases, including Windows 365, Python on Excel, Visio, and Dynamics 365. Users buy licenses using credit cards and can assign licenses to other users in the same tenant.

Naturally, I advise all tenants to disable this capability by using the odd MsCommerce PowerShell module. These commands are enough to do the job and produce the result shown in Figure 1.

Import-Module MsCommerce
Connect-MsCommerce
Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | ForEach {Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductId -Enabled $False }

Self-Service Sign Up Might Work for Some

I grudgingly admit that self-service purchases (or self-service sign-up as Microsoft refers to the capability) can work for some environments. Microsoft 365 serves many different kinds of organizations and some like to offload optional license management onto their users.

Organizations that permit self-service purchases will be delighted by the news in message center notification MC818889 (18 July 2024) that the Microsoft 365 admin center will soon post notifications (Figure 2) when users make self-service purchases. Notifications are due to start appearing in late July 2024 and should be available in all tenants by the end of August 2024 and will be seen by accounts holding the Global administrator and billing administrator roles. Notifications are turned on by default.

Microsoft says that the change is significant because:

• Awareness: Keeping you informed is crucial. With these notifications, you will stay updated on all activities in the tenant(s) you manage.
• Actionable Insights: We aim to empower you to take necessary steps. Whether it is managing subscriptions or ensuring security and compliance for vetted products, these insights will help align with your processes

One might ask why it’s taken Microsoft five years to realize that keeping tenant administrators informed is crucial, but that’s another day’s work. The point is that notifications will now happen, and that’s a welcome development.

Handling Self-Purchase Notifications

When administrators see notifications about self-service purchases, they can:

• Ignore the notification (the pretend it didn’t happen tactic).
• Realize that self-service purchases shouldn’t be happening and run the PowerShell command shown above to disable self-service purchases.
• Take over the licenses purchased by self-service sign ups.
• Cancel the self-service licenses

Taking over licenses (to cancel or absorb the licenses in the general set managed for the tenant) requires some work from administers. I’ve never done this because I have never allowed self-service purchases, but the process is covered in the self-service purchases FAQ.

Self-Service Notifications Can be Easily Overlooked

Receiving notifications when users take the plunge and buy a license for something like Power BI Premium is not enough to make me think that self-service licensing is a good idea. However, I acknowledge that it is a good step forward and will ease the administrative load in organizations where self-service purchases are allowed.

A nagging doubt that I have is that notifications are easily overlooked or dismissed without thinking, especially when people hurry to complete another task. A weekly digest of self-service purchases would round out the notification process. I guess that I shall wait another five years for that idea to arrive.

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.

Focus on Improving Email Security Continues with Inbound DANE with DNSSEC

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

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

The Licensing Conundrum for Inbound DANE with DNSSEC

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

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

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

The Implementation Timeline

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

The remaining timeline goes like this:

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

Towards a More Secure Messaging World

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

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

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

Rename General Channel with a “Meaningful Name”

Message Center notification MC814583 (July 16, 2024, Microsoft 365 roadmap item 395931) announces that team owners can soon rename the General channel (or the local language version of General when Teams isn’t run in English). For years, Microsoft resisted this request because the General channel is (in effect) the heart of a team. A team must have at least one channel and General is the default channel created in every team.

In the early days of Teams, it seemed like the General channel had a protected status where only team owners could post messages to the channel. The idea was to reserve the General channel for important announcements and the like and offload discussions to other channels dedicated to different topics. There’s value in this idea but perhaps not as much as people thought. It takes a certain discipline to always use the General channel for announcements.

Now Microsoft says that team owners can rename the General channel and give it a “meaningful name” to reflect the core role the channel has within a team. Renaming the General channel updates the channel’s display name, which can be up to 50 characters long. Some restrictions on characters that can be in the name do exist, but just like any other channel name, you can include emojis if you like (Figure 1). This must surely count as a meaningful name.

The warning shown in Figure 1 that once a team owner renames the General channel to some other name, they can’t reverse the process and use the General name again. “General” is a reserved name that can’t be assigned to any channel except when a team is created. I guess Microsoft could have created some extra code to track renames for General channels to allow channels to become General again, but it’s easier to say that the word General can never be used for a channel name.

Availability of Rename General Channel

The new feature is available in the Teams 2.1 desktop and browser clients. Microsoft plans to roll out the update to targeted release tenants in early August 2024. General Availability for commercial tenants will follow in mid-August 2024. GCC, GCC-High, and DOD tenants should get the update in September 2024.

Programmatic Ability to Rename General Channel

Current versions of the Graph Update Channel API block renames of the General channel (“General channel cannot be patched”), so the Update-MgTeamChannel cmdlet from the Microsoft Graph PowerShell SDK doesn’t work either. When the restrictions are lifted, you should be able to run a command like this to rename the General channel:

Update-MgTeamChannel -ChannelId '19:L2cxcx_ObbZSwEuRcwo1jEjIGZoxhAR-Fchi-PSujiM1@thread.tacv2' -DisplayName 'Everyone is a Winner' -TeamId $TeamId

A Small But Important Change in the Evolution of Channels

As I noted earlier this year, Microsoft is emphasizing better use of channels in an attempt to reduce the number of inactive or underused teams. With a team now capable of supporting a mixture of 1,000 regular, shared, and private channels, there’s certainly lots of potential to explore in maximizing the use of channels. Perhaps being able to rename the General channel will make it less of a special place than it’s been in past and make it into what the General channel is becoming: just another regular channel in a team.

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.

Keeping an Eye on Who’s Updating Sensitivity Label Policies

A reader remarked that there doesn’t appear to be a way to monitor changes made to Microsoft Purview sensitivity label policies or retention label policies. Given that retention policies and labels dictate how long content remains within a tenant and sensitivity labels and policies dictate who can access content, this seems like an oversight. The expectation expressed was that the Purview compliance portal should show who last updated both policies and labels instead of just the last modified date (Figure 1) together with who created the policy.

Displaying the last modified date for labels and policies is easy because Purview updates the objects each time an administrator makes an amendment. Showing who created a policy is mildly interested, but knowing who last changed a policy is more interesting, especially for organizations that want to exert tight control over who manages labels and policies. However, the only place Purview captures details changes is in the audit records for updates.

I don’t know why Microsoft doesn’t stamp label and label policy objects with details of the account used to make changes. It’s probably because of two factors. First, the presence of properties like WhenCreated and WhenChanged is common for PowerShell objects, but I can’t recall ever seeing a property to note the account that last updated an object like a mailbox, site, or group. Second, the audit log is designed to capture much more information about object updates than just who made the change.

A case can be argued that there’s no point in recording who changed an object in its properties when that information is available in the audit log. On the other hand, finding and retrieving the information about who last changed a label or label policy from the audit log is not going to be a fast operation, which is probably why it’s not done.

Searching the Audit Log

Extracting information from the audit log is a well-worn trail at this point and the basic mechanics are well understood.

• Identify the operations you want to find audit events for.
• Search the audit log for those operations (like Set-LabelPolicy to update a sensitivity label policy).
• Analyze and report the data.

Script to Find and Analyze Audit Events for Changes to Labels and Label Policies

To demonstrate the technique for updates applied to sensitivity labels and label policies and retention labels and label policies, I wrote a PowerShell script (downloadable from GitHub). The script:

• Connects to Exchange Online, the compliance endpoint, and the Microsoft Graph PowerShell SDK.
• Retrieves information about sensitivity labels and creates a hash table to resolve label GUIDs found in audit records to display names.
• Runs the Search-UnifiedAuditLog cmdlet to look for Set-LabelPolicy, Set-Label, Set-RetentionCompliancePolicy, and Set-RetentionComplianceRule events. The first two deal with sensitivity labels and policies. The second deals with retention policies and policy rules.
• There’s also an “Update label” event that seems to capture updates to sensitivity labels. Unlike the other events, these actions are performed by a service principal called Microsoft Exchange Online Protection. Some events are logged in what seems to be a background process that updates all the labels in the tenant at one time. Other Update label events occur immediately following a Set-Label event. One interpretation is that the Set-Label event follows an update to a label made in the Purview compliance portal. A subsequent Update label event then occurs if the sensitivity label applies encryption, and the update is for the Microsoft Information Protection template for the label.
• After finding the audit records, analyze the audit payload in each to extract the relevant information and capture the data in a PowerShell list. The audit payload differs across audit events, so interpretation can be a mixture of knowledge and inspired guesswork (here’s an example of analyzing audit events generated when users assign sensitivity labels to files).

The results are shown in Figure 2.

Demonstrating a Principle

The script is intended to illustrate the principle of using audit events to track changes to labels and label policies and improvements to the code are possible. For instance, only one service principal ever seems to turn up in the audit events (75367c9a-9a5b-41be-840f-ee9ee448c1f5, Microsoft Exchange Online Protection). If this is the case, then a hardcoded check is sufficient to resolve the GUID to a display name and no connection is needed to the Microsoft Graph PowerShell SDK. For now, the call to the Get-MgServicePrincipal cmdlet remains to handle the situation where other service principals update labels.

Knowing who changed a sensitivity label policy is an example of how tools like PowerShell fill in gaps left in Microsoft 365. Another example is monitoring changes made to container management labels assigned to groups and teams. Both demonstrate why mastering PowerShell is a good skill for tenant administrators to gain. Apart from filling in some gaps, you’ll also learn a lot more about how Microsoft 365 works, and that’s a good thing.

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.

Updating Old Code to Use the Microsoft Graph PowerShell SDK

The Teams and Groups Activity Report is a reasonably popular script which attempts to measure whether teams and groups are in active use based on criteria like the number of messages sent in a team. Processes like this are important because it’s all too easy for a Microsoft 365 tenant to fall into a state of digital rot where unused teams and groups mask where useful work is done.

But like many scripts, the code has evolved over years (since 2016 in this case). The current version uses many Graph API calls and some Exchange Online cmdlets to fetch and analyze statistics. Microsoft recently released the Entra PowerShell module, which is built on top of the Microsoft Graph PowerShell SDK. I think this is a mistake because there are many issues that Microsoft should address in the PowerShell SDK. Dividing their engineering resources and focus across two modules seems like a recipe for inadequacy instead of excellence.

To prove the usefulness of the Microsoft Graph PowerShell SDK, it seemed like a good idea to rewrite the Teams and Groups activity report and replace Graph API requests with PowerShell SDK cmdlets wherever possible. The new Entra PowerShell module is incapable of the task because it deals exclusively with Entra objects, and the script needs to access elements like usage reports to determine if a group or team is active.

Microsoft Graph PowerShell SDK Advantages

By converting to the Microsoft Graph PowerShell SDK, I wanted to take advantages of two specific features offered by the SDK cmdlets. First, you don’t need to worry about pagination. Second, you don’t need to deal with access token acquisition and renewal. Many SDK cmdlets like Get-MgGroup have an All parameter, which instructs a cmdlet to perform automatic pagination to fetch all available items. Token acquisition and renewal is handled automatically for Graph SDK interactive or app-only sessions.

The old version of the script handles pagination and token renewal, but scripts require code to handle these tasks. Extra code means extra places where things can go wrong, and that’s always a concern.

The value passed to the PageSize parameter is another important factor for performance. Cranking its value up to 999 (or whatever the maximum supported value is for a resource like groups) reduces the number of Graph requests required to fetch data, a factor that can be very important when dealing with thousands of groups and teams.

Upgrading Script Code

Like all PowerShell scripts that use Graph API requests, the previous version uses an Entra ID application (or rather, the application’s service principal) to hold the Graph permissions used by the script.

The same technique can be used with the Microsoft Graph PowerShell SDK. In fact, it’s the right way to confine apps to the limited set of permissions necessary to do whatever processing they perform. Using an Entra ID registered app to connect to the Graph means that application permissions are used rather than delegated permissions and therefore the script has access to all data consented through permissions rather than just the data available to the signed-in account, which is the case with an interactive Graph session.

Here’s the code to connect a Graph session in app-only mode. The code specifies the tenant identifier, application identifier, and a certificate thumbprint. After connection, the script can use any permission consented to for the application.

$TenantId = "a662313f-14fc-43a2-9a7a-d2e27f4f3478"
$AppId = "a28e1143-88e3-492b-bf82-24c4a47ada63"
$CertificateThumbprint = "F79286DB88C21491110109A0222348FACF694CBD"
# Connect to the Microsoft Graph
Connect-MgGraph -NoWelcome -AppId $AppId -CertificateThumbprint $CertificateThumbprint -TenantId $TenantId

In the case of the script, the application must hold consent for the Group.Read.All, Reports.Read.All, User.Read.All, GroupMember.Read.All, Sites.Read.All, Organization.Read.All, and Teams.ReadBasic.All application permissions.

Some Hiccups

Like all coding projects, some hiccups occurred.

First, the cmdlets to fetch usage report data don’t seem to be capable of saving the data to a PSObject. Instead, the data must be saved to a temporary CSV file and then imported into an array. Also in this area, the annoying bug that prevents SharePoint usage data returning site URLs persists. It’s only been present since September 2023!

Second, the Get-MgSite cmdlet returned a 423 “site locked” error for some sites when retrieving site information. As it turned out, the sites were archived by Microsoft 365 Archive. Unfortunately, the Get-MgSite cmdlet doesn’t have an IsArchived property to filter against.

Third, it’s always better for performance to have the Graph return sorted information instead of fetching data and then sorting it with the Sort-Object cmdlet. When fetching groups, the original script used Sort-Object to sort the objects by display name. I converted this code to:

[array]$Groups = Get-MgGroup -Filter "groupTypes/any(a:a eq 'unified')" -PageSize 999 -All `
-Property id, displayname, visibility, assignedlabels, description, createdDateTime, renewedDateTime, drive -Sort "displayname DESC"

Get-MgGroup_List: Sorting not supported for current query.

The command didn’t work and the error isn’t as helpful as it could be. The reason for the failure is that adding a sort converts the query from a standard to an advanced query, which means that you need to add the ConsistencyLevel and CountVar parameters. Here’s a working version of the command:

[array]$Groups = Get-MgGroup -Filter "groupTypes/any(a:a eq 'unified')" -PageSize 999 -All `
-Property id, displayname, visibility, assignedlabels, description, createdDateTime, renewedDateTime, drive -Sort "displayname DESC" -ConsistencyLevel eventual -CountVar GroupCount

Oddly, the Get-MgTeam cmdlet doesn’t support the ConsistencyLevel parameter so you cannot sort a list of teams except by sorting the objects fetched by Get-MgTeam with the Sort-Object cmdlet.

A Successful Conversion

I am happy with the migration. There are about 10% fewer lines of code in the Graph SDK version of the script, and everything works as expected. Or so I think. If you want to see the converted script, you can download it from GitHub.

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

Choice Remains Between Outlook Mobile and Exchange ActiveSync Clients

One of the most common questions I am asked concerns mobile email clients. Should Microsoft 365 tenants deploy and use Outlook Mobile or select a client based on the Exchange ActiveSync (EAS) API created by companies like Apple and Samsung instead? I’ve written about this topic before but it’s worth summarizing the current state of the art, so here goes.

OWA for Devices

Ten years ago, Microsoft jettisoned its focus on OWA as the premium client for mobile email connectivity. Trumpeted with some vigor at the 2014 Microsoft Exchange Conference in Austin, OWA for Devices, as the client was known, leveraged the engineering investment to create a high-quality browser-based client. Essentially, OWA for Devices was a wrapper around the full client to allow it to run using the native browser found in all mobile devices.

The OWA for Devices plan allowed Microsoft to bring a wide range of features to mobile devices that couldn’t be built on top of the EAS protocol. It’s worth remembering that Microsoft created EAS to compete with IMAP4 and POP3, so the feature set enabled through the EAS API is limited to basic email and calendaring.

The Acompli Effect

Technical difficulties, poor performance, and the feeling that Microsoft was trying to squeeze a heavyweight client designed for PC browsers into a mobile pot were the fault lines in the OWA for Devices strategy. If you can’t build technology, plan B is often to buy technology, and that led to the Acompli acquisition in late 2014.

Acompli’s signature feature was the focused inbox, or the ability to filter the most important messages into a separate Inbox (actually just a filtered view of Inbox contents). No mobile API supported the processing required to understand what messages were most important to a mailbox’s owner and filter those messages as new mail arrived in the mailbox. Acompli built the necessary infrastructure to copy mailbox contents from Exchange to build an online cache located in Amazon Web Services (AWS) to enable advanced email processing. The Acompli client connected to the processed cache and presented the filtered Inbox view to the user.

Acompli became Outlook Mobile for iOS and Android. The focused inbox became a feature loved or hated by hundreds of millions of users, and Microsoft replaced AWS with equivalent storage and processing based on Azure. Outlook Mobile still fetches cached mailbox content from Azure (now with a customizable synchronization period).

The new Outlook for Windows client exploits the same mechanism to deliver advanced functionality to users who connect to email servers via POP3 and IMAP4. These now-antique connection protocols don’t support many features used by modern email clients, so if the interim processing wasn’t done, the new Outlook for Windows would be restricted to a basic feature set. This simple but salient fact is ignored by those who protest when they discover that Microsoft synchronizes mailbox content to Azure for processing.

Outlook Mobile Continues to Lead

Coming back to the original question, I continue to recommend that organizations focus their mobile email client strategy on Outlook Mobile whenever possible. It’s a solid client for both iOS and Android that easily outpaces EAS-based clients in areas like email features and information protection. The client feature set continues to evolve, with the latest initiative being a new contact editor (MC746321, last updated 5 July 2024, Microsoft 365 roadmap item 384869). Apart from more reliable synchronization of contacts with Exchange Online, the new contact editor (Figure 1) supports enforcement of Intune policies such as preventing copy and pasting data in the editor. Outlook Mobile is better integrated into Intune device management too. In summary, from a corporate IT perspective, Outlook Mobile ticks many boxes. Its advantage over EAS clients in this area is unlikely to diminish.

But life isn’t always simple and corporate IT doesn’t always get to implement their choice. The era of BYOD means that an incredible number of devices connect to Microsoft 365, and it can be hard to move people from a native email client. Old habits die hard. However, I see an increased uptake in Outlook Mobile usage, possibly because features like sensitivity labels have rolled out in more tenants. My view is anecdotal and based on a limited set of data, but it seems like that’s the way things are going ten years after Microsoft choose Acompli as their new mobile email client.

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.

Microsoft Will Remove-SPOExternalUser Between July 29 and August 9

Message center notification MC806103 (27 June 2024) reports the deprecation of the Remove-SPOExternalUser cmdlet from the SharePoint Online management PowerShell module. Microsoft suggests that administrators replace the cmdlet with the Remove-AzureADUser cmdlet, which is a perfectly reasonable strategy if only the cmdlet isn’t part of the retired and soon-to-be deprecated AzureAD module.

Between July 29. 2024 and August 9, 2024, Microsoft will disable the Remove-SPOExternalUser cmdlet. When the block arrives in a tenant, attempts to run the cmdlet will be greeted with:

“To streamline scope and permissions for external users, enhance access management, and strengthen our security posture, this cmdlet has been deprecated. Alternatively, please use the Remove-AzureADUser cmdlet in Microsoft Entra ID for user management.”

Microsoft 365 is so Large that No One Understands Everything

MC806103 is a classic example of Microsoft being such a large organization that no one knows what’s happening across the board, or even what’s happening within Microsoft 365. In this case, the SharePoint Online people want to deprecate the Remove-SPOExternalUser cmdlet. That’s a good idea because the cmdlet has low usage (I don’t think I have ever used it) and doesn’t really make sense inside the Microsoft 365 ecosystem where external access for applications like SharePoint Online is now governed using guest accounts. It makes perfect sense to remove overlapping or conflicting features and replace them with what you’d consider a component that’s closer to the core.

Entra ID is the directory of record for Microsoft 365. Individual workloads like SharePoint Online have their own directory, but everything flows back to Entra ID. Replacing the SharePoint Online cmdlet with an Entra ID cmdlet is the right thing to do. The problem is that the program manager in charge of making the transition obviously doesn’t know that the Entra ID team has been trying to deprecate the AzureAD and AzureADPreview modules since 2020. For the last few years, Microsoft has conducted an ongoing campaign to move tenants off these modules to use the Microsoft Graph PowerShell SDK.

What makes this laughable is that Microsoft launched the Entra PowerShell module in preview on June 27 in the hope that a dedicated Entra module (built on top of the Microsoft Graph PowerShell SDK) would help the remaining customers who have scripts that use the AzureAD and AzureADPreview modules to move to a modern platform. Obviously, whoever wrote MC806103 had no idea that this development was in train.

The Right Way to Replace Remove-ExternalSPOUser

The Get-SPOExternalUser cmdlet reports the external users registered for a SharePoint Online tenant. The last time I discussed its use, I observed that the Get-SPOExternalUser cmdlet is an odd cmdlet in some ways, but it does generate a list of external users from the SharePoint directory.

An external user record looks like:

RunspaceId    : 9630573b-c675-4697-a029-72d535e48613
Email         : charu.someone@microsoft.com
DisplayName   : Charu Someone
UniqueId      : 100320009C9C6789
AcceptedAs    : charsomeone@microsoft.com
WhenCreated   : 20/02/2020 19:45:02
InvitedBy     :
LoginName     :
IsCrossTenant : False

Remove-SPOExternalUser works like this:

Remove-SPOExternalUser -UniqueIDs ($User).UniqueId -Confirm:$false
Successfully removed the following external users
100320009C9C6789

The cmdlet removes the external user entry from SharePoint Online. It also removes the matching guest account, if one exists, from Entra ID. In my tenant there are quite a few lingering external accounts that don’t have matching Entra ID guest accounts. These accounts are just another form of digital debris that needs to be cleaned up.

The right way to remove an external account is to use the Remove-MgUser cmdlet from the Microsoft Graph PowerShell SDK:

$User = Get-MgUser -filter "mail eq 'andrew@proton.me"
Remove-MgUser -UserId $User.Id

Or, if you decide to use the preview Entra module:

$User = Get-EntraUser -SearchString 'AdamP@contoso.com'
Remove-EntraUser -ObjectId $User.Id

Either cmdlet has a much longer future ahead of it than the Remove-AzureADUser cmdlet has. In both cases, SharePoint Online synchronizes with Entra ID and removes the matching external user record.

It’s Just Hard to Keep Up

I don’t blame the individual program manager responsible for MC806103. It’s hard to keep up with everything that goes on within Microsoft 365 and all too easy to assume that a solution that works (for now) is the right long-term recommendation. Perhaps Microsoft needs a clearing house to cross-check dependencies outside the control of an individual development group before they publish information to customers?

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.

Teams Joins SharePoint Online and Microsoft 365 Groups in Connector Retirement

On June 11, I wrote about the retirement of Office Connectors for Microsoft 365 Groups and SharePoint Online and speculated that support for Connectors in Teams wouldn’t last. Well, Microsoft published message center notification MC808160 on 3 July 2024 to announce the retirement of Office Connectors from Teams starting on August 15, 2024. It looks as if the retirement involves some work for Microsoft to do because it’s not due to complete until January 1, 2025.

A note in the Microsoft Developer Blog explains more about why Microsoft is retiring Connectors from Teams. The timeline is:

• Microsoft will block the creation of new connectors on August 15.
• Existing connectors will stop working on October 1, 2024.

Microsoft says that when users with active connectors post to Teams, the connector will include a notice about the impending retirement at the bottom of the message posted to the target channel.

The Future is Workflows

Microsoft says that the Workflows app (Power Automate) is the replacement and where they plan to invest future development resources, It’s hard to argue against the consolidation of “citizen development” around a single platform. Moving from Connectors to workflows is straightforward for “standard” connectors like RSS (Figure 1) or if a replacement template is available in the workflows catalog.

Things get more interesting if you’ve built PowerShell scripts to generate payloads to inject into Teams channels via the incoming webhook connector. The development of the necessary code for a relatively simple example of reporting Microsoft 365 service health in an adaptive card took more hours than I anticipated. One issue that I still haven’t solved is how to run a workflow using a service account or service principal. The implementation in Teams appears to be tied to user accounts for authentication. This is fine when a user is active within the tenant but not so good when people leave.

The Problem with Connectors

The problem with Microsoft retiring Office Connectors for Teams is that tenant administrators have no way of knowing what connectors are installed where. There’s no report in the Teams admin center, so we must resort to PowerShell. Looking through the Graph documentation, we find the List apps in team API, or its Microsoft Graph PowerShell SDK equivalent cmdlet, Get-MgTeamInstalledApp.

The API returns all the apps installed in a team, including the apps preinstalled by Microsoft and those used for connectors (above everything else, Teams is an app composed of apps). However, it’s easy to come up with a list of connector apps and use that list to filter what comes back from Teams.

For instance, I defined an array with entries for SharePoint News, RSS, the incoming webhook, and “Happy Communities” (a customized name for Viva Communities). If you think that another Office connector is in use, add its name to the array.

[array]$TargetApps = "SharePoint News", "RSS", "Incoming Webhook", "Happy Communities"

After populating the array, it’s easy to fetch a list of teams and run through each team to determine if any of these apps are present:

ForEach ($Team in $Teams) {
    $TeamName = $Team.DisplayName
    Write-Host "Analyzing team: $TeamName"
    $Apps = Get-MgTeamInstalledApp -TeamId $Team.id -ExpandProperty TeamsAppDefinition
    If ($Apps) {
        ForEach ($App in $Apps) {
            If ($App.TeamsAppDefinition.DisplayName -in $TargetApps) {
                $Report.Add([PSCustomObject]@{
                    TeamName = $TeamName
                    AppName = $App.TeamsAppDefinition.DisplayName
                    Description = $App.TeamsAppDefinition.ShortDescription
                    AppVersion = $App.TeamsAppDefinition.Version
                    AppState = $App.TeamsAppDefinition.PublishingState
                    AppId = $App.TeamsAppDefinition.Id
                })
            }
        }
    }
}

Hey Presto! The script generates a list of teams and connectors to check (Figure 2). You can see that the connectors are associated with teams rather than individual channels, so some manual checking of each team is necessary to find which connector is targeted by the connectors.

You can download the full script from GitHub.

More Help Needed from Microsoft

I don’t mind the retirement of Office Connectors for Teams. Once Microsoft started along the path with SharePoint Online and Microsoft 365 Groups, it was always highly unlikely that Office Connectors would remain a Teams-only option. What I do mind is the lack of preparation and assistance that Microsoft gives to customers who might have been using connectors for years. It wouldn’t have taken much for Microsoft to create a list of connectors in teams as described above.

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

Set a Delay for Microsoft Content Services to Evaluate Email Content

I was asked about a Microsoft Technical Community post from July 2023 titled Oversharing Pop-up in Outlook– Customize experience via GPO settings. Some folks couldn’t get the pop-up windows to work with the newly branded Outlook (classic), so I decided to take a look.

Outlook DLP Policy Tips and Pop-Up Windows

When a tenant has configured Data Loss Prevention (DLP) policies to prevent sharing of sensitive data, Outlook and OWA evaluate message content and display policy tips if configured in DLP rules. Figure 1 shows how Outlook displays a policy tip after detecting some credit card information in a message.

Outlook sends email content to Microsoft content services for processing by DLP policies. If a violation is found and a policy tip is configured, Outlook displays the policy tip. It’s possible to use a sensitivity label to block access to content services for Microsoft Office apps. Although the intended use case for assigning such a label to an email is to stop Copilot for Microsoft 365 processing message content, the label also stops DLP policy tips. Blocking a visual indicator isn’t optimal, but a backstop exists in that the transport service can block messages when it processes the checks defined in DLP policies.

The Problem Being Solved with Outlook DLP Policy Tips

The problem that the pop-up messages attempt to solve is that it’s possible to insert sensitive data into a message and send it before Outlook has the time to send the content to Microsoft content services, which means that the user never sees the policy tip. The solution that I tested involved configuring the specify wait time to evaluate sensitivity content setting in a Cloud Policy configuration in the Microsoft 365 apps admin center (Figure 2).

Enabling the setting and specifying a period (in seconds) instructs Outlook (classic) to pause for the specified period before sending a message. Allowing 15 seconds or so should be enough for Outlook to transmit the email to Microsoft content services and receive a response. During this process, users see a message to tell them that the organization requires email to have a sensitive content check before transmission (Figure 3).

Depending on the DLP rule conditions, a violation discovered by the content check causes Outlook to display the policy tip with or without the message being blocked. If allowed by the DLP rule, the sender can override the block and continue to send the email. Figure 4 shows a DLP rule configured with a policy tip and the ability for a sender to override the block.

When content services detect a policy violation, Outlook displays the policy tip and the dialog to allow the user to override the policy (Figure 5).

DLP captures DLPRuleUndo audit records when users override a policy when sharing sensitive documents from SharePoint Online and OneDrive for Business. Exceptions cited by email senders are included in the audit data payload for the records. The same records are not captured when people override a DLP block with Outlook. I have flagged this issue to Microsoft and await their response.

Outlook DLP Policy Tips Good if You Can Handle the Sending Delay

Outlook pop-ups for sensitive data checks close a gap that might stop someone from sending a message containing sensitive content only to have DLP reject the message when it goes through the Exchange transport service. Closing any gap is goodness, as is the additional education people see when they see that messages are checked. The downside is that users might dislike the delay all outgoing messages experience to allow content services to process their content, plus the lack of audit records. If you can live with these issues, then pop-up warnings for Outlook might be a policy to experiment with a small target group before making it live for everyone.

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

Customizable Outlook Mobile Synchronization Between 1 and 90 Days

A change so good that Microsoft announced it twice in MC696167 (7 December 2023, last updated 24 May 2024) and MC798682 (last updated 14 June 2024) tells us that Outlook Mobile users can customize the synchronization window for their device. Both are associated with Microsoft 365 roadmap item189809. According to MC798682, the rollout started in early June and was expected to finish by late June 2024. I didn’t see the update until July 2.

The synchronization window defines the period for downloading email and attachments to a device and enables offline access to mailbox contents. MC798682 says that the period extends between one and 30 days, but as you can see in Figure 1, the iOS client offers the ability to synchronize data for up to 90 days. Microsoft says that they will expand the size of the synchronization window from 90 days after they confirm that everything works well in production.

The now-renamed Outlook classic client has had a customizable synchronization period since the introduction of “drizzle mode synchronization” in Outlook 2013, but this is the first time that the iOS and Android clients get similar control.

Synchronization Basics

Synchronization happens between Outlook mobile and the cached copies of user mailboxes stored in Azure. Being able to set a minimum one-day window might seem strange, but it addresses the need some organizations have to restrict the amount of corporate data stored on a device. If messages outside the window are needed, Outlook mobile can fetch them from the server if a network link exists. It just takes a little longer than if the messages are cached locally.

Previously, Outlook mobile synchronized 500 items per folder by default with the ability to download up to 1,000 items per folder if necessary. Outlook periodically trims the data cached on the device to keep the items under the configured limit. With the introduction of the new synchronization window., Microsoft is limiting download to a maximum of 2,000 messages. Restricting the number of messages downloaded to the local cache makes sure that the Outlook mobile client can function without problems, especially on low-end devices. Microsoft says that they’ll increase the maximum for synchronized items and the size of the synchronization window in future versions of Outlook mobile.

Configuring the Synchronization Window

To configure the synchronization window, select the Settings option in the client. In the General section, select accounts and then the account for which you want to configure the synchronization window. Go to the Data storage setting and configure Sync settings with the number of days for the synchronization window (Figure 1).

You can also toggle the Include attachments option on or off to control if Outlook mobile should automatically download message attachments received during the synchronization window (Figure 2).

Through Intune controls, administrators can set a default synchronization window for devices and stop users changing that window. The keys for the two settings are:

• com.microsoft.outlook.Settings.DaysToSync.
• com.microsoft.outlook.Settings.DaysToSync.UserChangeAllowed.

The maximum value settable through Intune for the synchronization window is 90 days, which is the same as seen in the client.

Outlook Monarch Gets Synchronization Too

The first support for offline access in the new Outlook for Windows (aka Monarch) was also due to begin its rollout in late June 2024 (MC798674, Microsoft 365 roadmap item 178030) covering mail, calendar, and contacts. Only a limited set of actions are covered, including the important ability to read and send email. So far, I haven’t seen the update or heard of others receiving it, but worldwide deployment isn’t scheduled to finish before late July 2024.

This is an important step forward for the Monarch client, which is already generally available to consumer users (and not without some controversy due to the way that Monarch synchronizes mailbox data from Azure). Microsoft knows that Monarch isn’t ready for prime-time exposure to corporate users yet because features like offline working haven’t been available until now. There’s still a bunch of work to do here before Microsoft can retire Outlook classic in 2029.

Everyone Wins with a Customizable Outlook Mobile Synchronization Window

Synchronization is not rocket science at this point. Adding a customizable synchronization window to Outlook mobile makes sense. It allows Microsoft to address some customer concerns about having too much corporate data on a phone while those who would like to carry around their entire mailbox might be able to do so in future. Everyone wins.

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.

Stop Annoying In-Product Messages Promoting Events and What’s New Updates

Just as Microsoft settled into the normal stupor surrounding the July 4 holiday, the Teams development group issued message center notification MC808161 (3 July 2024) to announce a new policy setting to disable some in-product messages displayed in Teams clients. The new setting is something that should have been in place when Microsoft started to push in-product messages to promote events like the Microsoft 365 conference (Figure 1) in April 2023, but it’s better later than never.

A Really Bad Idea

I hated in-product messages the first time I saw them. To me, Microsoft has no right to communicate with users belonging to my tenant and no right to advise users what training events they might like to attend. It’s one thing to pump ads to consumers of a free service and quite another to do the same (which is what in-product messages are) to people who pay a monthly license fee.

Advertising conferences chosen simply because events align with Microsoft marketing priorities is simply an abuse of Microsoft’s position as a cloud service provider and adds weight to the argument that Microsoft should be restrained by government intervention. Some will wonder if the latest European Union investigation into anti-competitive behavior around Teams prompted Microsoft to act. I don’t think so because controls over in-product messages were discussed by Microsoft last year in response to complaints from many MVPs.

Squashing In-Product Messages

Applying the policy block for in-product messages can only be done using PowerShell. The instructions to control in-product messages mention the New-CsTeamsUpdateManagementPolicy cmdlet from the Microsoft Teams PowerShell module (I used version 6.3). This implies that you need to create a new policy. You don’t. There should be an existing policy in place that can be updated.

Looking at the DisabledInProductMessages parameter with PowerShell, it seems to be an array. The documentation implies that the parameter takes a string value and that only a single type of in-product message can be disabled. In short, you must choose either:

• 91382d07-8b89-444c-bbcb-cfe43133af33: What’s New Messages
• edf2633e-9827-44de-b34c-8b8b9717e84c: Conferences

However, the Set–CsTeamsUpdateManagementPolicy cmdlet is quite happy to accept an array containing both values. Here’s what I ran to update the default update management policy with both values:

[array]$DisabledMessages = "edf2633e-9827-44de-b34c-8b8b9717e84c", "91382d07-8b89-444c-bbcb-cfe43133af33"
Set-CsTeamsUpdateManagementPolicy -Identity Global -DisabledInProductMessages $DisabledMessages
Get-CsTeamsUpdateManagementPolicy -Identity Global
Identity                  : Global
DisabledInProductMessages : {edf2633e-9827-44de-b34c-8b8b9717e84c, 91382d07-8b89-444c-bbcb-cfe43133af33}

PowerShell documentation has been known to be incorrect in the past, and it seems like this is the way the cmdlet is designed to work. In any case, my tenant is configured as shown above and I look forward to peace from annoying ad placements about both conferences and what’s new messages.

Only for Teams

The policy settings only cover Teams clients. Other products take their own course, as evident in the example of the Power Platform admin center and the two ads placed for the Power Platform community conference (Figure 2).

Let’s hope that the Power BI and any other development group that’s tempted to abuse their customers follow the lead set by Teams and provide tenants with a method to eradicate in-product messages.

Getting in the Way of Work

In-product messages get in the way of useful work. People are distracted by whatever message is being relayed. That’s a direct impact on the effectiveness and efficiency of customer organizations inflicted by Microsoft without invitation or permission.

A better way to promote conferences is to use the Microsoft 365 message center and allow tenant administrators to decide what information to pass on within their organization. This approach might not get messages in front of as many “eyeballs,” but it does offer the advantage of not making people unhappy when they see blatant advertising that doesn’t add a jot of value.

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.

Support for Sharing Links Expiration Added for Company-wide and Specific People Links

The change announced in message center notification MC799277 (6 June 2024) to make expiration dates available for all types of sharing links should now have reached targeted release tenants. General availability will follow soon afterwards.

Until now, SharePoint Online and OneDrive for Business have supported expiration dates for anyone sharing links. Microsoft was correct to start with these links because they are transferable. In other words, anyone in possession of the link can access the file or folder pointed to by the link.

Although anyone links are revocable and therefore can be annulled if a link becomes too widely available, making them the first sharing link to support expiration was a good thing. Even with expiration dates, many organizations prohibit anyone links because they consider these links to be too dangerous. Users forget to set expiration dates, the links circulate in email and can easily escape outside the organization, and so on.

Company-wide and Specific People Sharing Links

Company-wide (aka people in your organization) and specific people links deliver tighter control over sharing because SharePoint Online validates the account that attempts to redeem and use a link to make sure that they meet the sharing criteria. For example, if you’re not signed into a tenant account, SharePoint Online won’t allow you to use a company-wide link.

Specific people links are usable with people inside and outside an organization. External people must have a guest account in the tenant to authenticate, either an account created to access other resources like Teams (or most recently, Microsoft Loop), or an account created during the process of gaining access to the shared content. During this process, depending on the conditional access policies active in the tenant, an external person might be asked to configure multi-factor authentication to protect their account.

All of this sounds good, and it means that specific people links are usually a safe way to share externally, especially if coupled with a sensitivity label with encryption to stop any inadvertent leakage of confidential information.

Sharing Links Expiration for All

Using a sharing link that SharePoint Online imposes controls over who can use the link can sometimes do with a little extra help and that’s where the expiration controls come in. You can now set a date (Figure 1) for company-wide and specific people sharing links to expire.

When a link expires, it can no longer be used to access the shared content. The owner of the content must then reshare the content if they wish.

It seems like Microsoft has some loose ends to clean up before you could consider this feature to be complete. For instance, although SharePoint Online shows the expiration date after copying a link (Figure 2), the Manage access dialog for an item doesn’t display expiration dates. This might be due to an incomplete software deployment and the missing bits for an updated Manage access dialog might be still on the way.

More importantly, the SharePoint Online admin center has a setting for Anyone links to set a maximum expiration length in days (Figure 3). However, similar controls aren’t yet available for company-wide and specific people links. That seems like an oversight.

Being picky, I could also point out that setting an expiration period for a sharing link does not affect the SharingSet audit record generated when SharePoint Online or OneDrive for Business configure a sharing link. This is a pity. Microsoft needs to improve the information captured in audit records for sharing events to make them more administrator friendly. For instance, a value like “EventData    : <PermissionsGranted>Contribute</PermissionsGranted><MembersCanShareApplied>False</MembersCanShareApplied>” is meaningful to a computer but less so to a human. If you’re interested in learning how to interpret audit records for sharing events, try this script from GitHub.

Sharing Links Expiration for All Link Types is a Good Change

Even though I think Microsoft has some things to work on to complete the feature, I like that SharePoint Online supports expiration dates for all types of sharing links. It’s a good change and one that should be popular with users, even if administrators can’t find out the kind of usage the feature gets because of the lack of detail in audit records. According to MC799277, Microsoft is due to refresh the documentation, but that hasn’t happened yet. More bits lost in transit!

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.

Prevent Inactive Channels from Cluttering User Views

In another step in Microsoft’s overhaul of Teams channels, message center notification MC804771 (24 June 2024, Microsoft 365 roadmap item 325780) announces the implementation of a new housekeeping function to clean up user channel lists by hiding unactive channels (Figure 1).

The change will only be effective in commercial and government tenants. Education tenants won’t have their channels cleaned up. The update to the Teams 2.1 client for Windows, MacOS, and browsers will appear in mid-July for targeted release tenants and reach general availability for commercial tenants in mid-August 2024 with worldwide deployment scheduled to complete by mid-September. GCC, GCC High, and DoD tenants will see the update about a month later.

Channel clean up happens for both member and guest user accounts.

The Chaos of Inactive Channels

Tenants are well aware of the problem of digital rot caused by too many teams. Each team can now have up to 1,000 channels, and Microsoft is keen for customers to create channels rather than teams to reduce the amount of digital debris in their tenants. A shared or private channel can often replace a team, especially as both come with a dedicated SharePoint Online site to store documents.

It would be nice if those who created channels always maintained those channels, but this doesn’t happen in the real world. Like teams, channels can be created only become inactive or uninteresting to users quickly. It might be that the channel isn’t needed, that people discuss the topic created for the channel in a group chat instead, or that the topic simply isn’t worth a separate channel. For whatever reason, people lose interest and inactive channels find their way into user channel lists.

To solve the problem, Teams will automatically detect and hide inactive channels that users have not interacted with recently. Microsoft hasn’t said what period is used of inactivity Teams uses to make the determination or what interaction means. Based on experience with the preview version of the feature, interaction seems to mean open a channel to view conversations. Microsoft says that 45 days is the point used to decide if a user is active in a channel. It seems like Teams checks for inactive channels every couple of weeks.

When Teams detects inactive channels, it offers the chance for the user to review the set and make the call to unhide some of the channels (Figure 2).

It’s a good idea to review the set of inactive channels selected by Teams because useful channels that are temporarily inactive will appear in the list.

Settings for Channel Cleanup

The Teams Settings app includes the ability for users to opt out of automatic channel cleanup as well as an option to initiate the cleanup process on demand (Figure 3).

If you opt to clean up now, Teams checks the current channel list and displays any that it believes to be inactive.

The important thing to remember is that a hidden channel is still available to a user and can be unhidden at any time by viewing the set of channels for a team and unhiding any that they want to see.

Inform Users About Channel Clean Up

Automatic clean up processes are usually a good idea and hiding inactive channels is an example of one that’s worthwhile. However, like anything else that affects users, some explanation is necessary for people to understand why and what is happening. No one wants a bunch of help desk calls asking where a favorite (but inactive) channel has gone.

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.

Why Some People Can’t Use Shared Files with Copilot for Microsoft 365

After reading the article about the new sensitivity label advanced setting to block access for Microsoft content services to confidential Office documents, a reader asked why some users can use some documents shared using company-wide links with Copilot for Microsoft 365 while others cannot. The situation seemed a little strange because it happened for documents shared with everyone in the organization. The problem couldn’t be due to a sensitivity label because the capability only just rolled out and is limited to the Office applications.

The answer is in Microsoft’s documentation for secure file sharing, which says: “Creating a People in your organization link will not make the associated file or folder appear in search results, be accessible via Copilot, or grant access to everyone within the organization. Simply creating this link does not provide organizational-wide access to the content. For individuals to access the file or folder, they must possess the link and it needs to be activated through redemption.”

In other words, sharing a file with everyone in your organization is only the first step in the process of making information available to Copilot for Microsoft 365. A company sharing link that arrives in your inbox or is shared through a Teams chat is dormant until you redeem it by using the link. At that time, SharePoint Online checks that your account belongs to the organization to conform your access to the file. If confirmed, the file joins the set of “shared with you” information, which makes it available to Copilot for Microsoft 365.

Testing Company-wide Sharing Links with Copilot

A simple test proves the point. Create a file that contains some information that’s unlikely to exist elsewhere within the company. In my case, I created a Word document about a fictional digital SLR camera called the Bunsen BX7. Now share the file with a company-wide link (Figure 1).

After signing into another account, open Copilot for Microsoft 365 chat and attempt to find some information about the topic in the file. Copilot should return nothing because a Bing search of the internet and a Microsoft search of company resources available to the account turn up no mention of the topic. But if you now go and use the link to open the file, Copilot can find the information and use it in its responses.

Figure 2 shows a Copilot for Microsoft 365 chat session. The first prompt about the Bunsen BX7 turns up nothing and Copilot responds with some generic text about digital cameras. The second prompt is after redemption of the company-wide sharing link. Copilot is able to find the document and use the information in its response. You can see that the shared document is listed as a source for the response.

The Desirability of Company-wide Links

The mystery of why some people can use shared documents with Copilot for Microsoft 365 is solved, but thoughts now turn to whether organizations should restrict the use of company-wide links for sensitive documents. The value of these links is that they allow anyone in the organization to access content. The downside is that it’s too easy to create and use company-wide links, which then creates the temptation for people to use these links to share confidential files wider than the organization wants the information to be known.

To guide users away from company-wide links to create sharing links for specific people instead, you can modify the SharePoint tenant configuration to make direct links the default option. Even better you can update individual site settings to disable company-wide links (anyone links are also disabled). For example, the first command sets direct links as the tenant default; the second disables company-wide links for a specific site.

Set-SPOTenant -DefaultSharingLinkType Direct

$Site = "https://office365itpros.sharepoint.com/sites/BlogsAndProjects"
Set-SPOSite -Identity $Site -DisableCompanyWideSharingLinks Disabled

If your organization uses sensitivity labels, you could also consider applying a label that restricts access to a small group of users. That way, even if someone sends a document outside the organization as an email attachment, external recipients won’t be able to open it.

The Challenge of Managing Information in an AI World

The advent of AI assistants creates new information governance challenges for Microsoft 365 tenants. Slowly but surely mechanisms are being developed to help organizations cope and manage the potential for information leakage and misuse. Some Microsoft solutions are no more than sticking plasters to allow customers to progress their Copilot deployments, but overall, the situation seems to be improving. Let’s hope that the trend continues and the current AI hype lives up to its promise.

Eleventh Edition of the Most Comprehensive Book About Office 365 and the Microsoft 365 Ecosystem

After some late nights finishing up the book content before building the PDF and EPUB files, the Office 365 for IT Pros team is happy to announce the publication of Office 365 for IT Pros 2025 edition. This is the eleventh book in a series going back to May 2015 and is the 109th monthly update issued in that time. The new book is now online on Gumroad.com.

We have emailed an upgrade code to subscribers of the 2024 Edition to allow them to upgrade for $16.95 (the same price as last year). We also sent a code to people who subscribed during June 2024 to allow them to claim a free upgrade. This is in line with our normal policy of offering anyone who subscribes in the last month of an edition the chance to automatically extend their subscription to cover the next edition.

A New PowerShell Book

Office 365 for IT Pros (2025 Edition) does not have a companion volume. We made the decision to discontinue the companion volume because the information it contains is now quite old. Please keep the 2024 companion volume if you wish to retain access to its content.

This year, we launched a new 240-page four chapter book called Automating Microsoft 365 with PowerShell. We have strong PowerShell content in the 2024 edition. Given all the changes in Microsoft 365 PowerShell modules and growing usage of Microsoft Graph APIs, it seemed like a good idea to create a book focusing on this area. There are still hundreds of PowerShell examples in the main book where they are used to explain how to accomplish specific tasks. The PowerShell book allows us to dedicate more in-depth coverage to this critical area, especially about using PowerShell with Microsoft Graph APIs and the Microsoft Graph PowerShell SDK.

The Office 365 for IT Pros (2025 edition) subscription includes Automating Microsoft 365 with PowerShell in both PDF and EPUB formats. Like our other content, we will update the PowerShell eBook monthly.

In addition to including the new eBook in the Office 365 for IT Pros subscription, we sell Automating Microsoft 365 with PowerShell separately. People who don’t want to buy the full Office 365 for IT Pros subscription can purchase a copy of the PowerShell book from Gumroad.com or as a paperback version available from Amazon.com. This is the first time that we have produced a print book since the original edition of Office 365 for Exchange Professionals appeared at the Ignite conference in May 2015. At that time, Microsoft paid for 500 print copies, all of which were distributed at the conference. Anecdotal evidence since is that some of our readers have printed the PDF version to have a hard copy. The size of the main book (now about 1,220 pages) means that online print services can’t handle it, but splitting off a section to create a separate book allows opens up the possibility of print copies again.

In the future, we might split off other books, such as ones covering Teams or compliance, and make them available in the same way. That decision depends on how people like the PowerShell book.

Why New Editions Appear on July 1

Some ask why we choose to introduce new editions on July 1. We’ve done this since 2016 to align with Microsoft’s fiscal year. That might sound strange, but it’s an undeniable fact that many Microsoft engineering groups aim to ship new functionality before the close of their fiscal year. There’s a rush within Microsoft to finish new software and make it available to customers before June 30. Afterwards a relative lull sets in as many Microsoft engineers take vacation. In a strange kind of way, this helps us to frame a new edition in a way that wouldn’t be possible at the end of the calendar year.

CoreView is Our New Sponsor

After a terrific year’s support from CodeTwo Software, including some excellent t-shirts made by Szymon Szczesniak and his team, CoreView is the sponsor for Office 365 for IT Pros (2025 Edition). We like having an alignment with our sponsors and believe that this exists with CoreView, who are deeply involved with Microsoft 365 management and automation. We look forward to a great year working with the CoreView team.

Seven Books in One

We like to think that Office 365 for IT Pros is seven books in one:

• Exchange Online.
• Entra ID.
• SharePoint Online.
• Teams.
• Purview Compliance.
• Information Protection.
• Automation (Power Automate and PowerShell).

Office 365 for IT Pros (2025 Edition) strengthens our claim. The two books covered by the subscription contain a huge amount of knowledge. Our work isn’t perfect, but it’s our honest and best effort to communicate our experience of working with Exchange Online, Entra ID, SharePoint Online, Teams, OneDrive for Business, Planner, Stream, Purview, Power Automate, and associated technologies. The rate of change across these products means that the advantage of publishing an eBook is more evident now than ever before. In the 24 hours before publication, we updated five chapters of the Office 365 for IT Pros (2025 Edition) eBook and one chapter for the Automating Microsoft 365 with PowerShell eBook.

Stay tuned for our email announcing when the new book is released and available. Thank you for your support for the Office 365 for IT Pros project. We hope that you like the books as much as we enjoyed working on them. And stay tuned to what we publish here. You never know when we might say something valuable!

Shared Tab for Files and Hyperlinks Replaces Files

Message center notification MC800850 (11 June 2024, Microsoft 365 roadmap item 396169) is about another tweak Microsoft is making to the user interface of the new Teams client. On the surface, renaming the Files tab in Chat to be Shared is an innocuous change, but the update goes deeper.

The update is for the Teams Windows and Mac desktop clients and the browser client, and the new software will roll out to targeted tenants in early July 2024. General availability will follow soon afterward, and full worldwide deployment should be complete by the end of July. As with any date, don’t declare success until you see the change appear in your tenant.

The Shared Tab

The Files tab is a shortcut to allow users to see and access the files shared in a chat. It is a default tab for Chat and cannot be removed by users. The Files tab served its purpose, but the simple fact is that other objects, notably hyperlinks, are also commonly shared in chats. The new Shared tab exposes both files and hyperlinks in what Microsoft calls “a new, richer format” (code for a slightly nicer listing layout). The tab is available in one-to-one and group chats with tenant members and guests. It is not available in federated chats (with people in other tenants).

Figure 1 shows the new Shared tab in use in a chat between myself and Vasil Michev, who’s a guest in my tenant. We share many hyperlinks in the chat, including Graph API URIs, which are probably less exciting than links to documents or websites.

When a chat participant opens the Shared tab, Teams fetches the most recent items. It seems like Teams tries to find files and hyperlinks shared in the last two months, but you can scroll back to find older files. During testing, I could find files and hyperlinks back as far as December 2020, which seems reasonable. This might or might not have been the first time I shared something in the chat, but 42 months later I can’t remember!

No Change in Channels

Microsoft is not changing the Files tab for channels. This tab serves a completely different purpose because it lists the files in the channel’s SharePoint Online folder. The focus for the Files channels tab is to maintain feature parity with the SharePoint browser interface. Teams has steadily improved this position over the years and the two are pretty close now.

Future Updates for the Shared Tab

Microsoft says that they will enable image previews for hyperlinks and a keyword search facility in the Shared tab “soon after the rollout.” The keyword search seems to be available now (Figure 2), so perhaps plans changed after the message center notification was written.

Microsoft also discusses the next version of the Shared tab that includes support for media links (images, videos, GIFs, etc.). No dates are given for “soon” or the next version.

Change Doesn’t Please Everyone

Sometimes people complain when Microsoft introduces features that don’t seem to be as important from a business or technology perspective. Certainly, I received plenty of feedback on that point after writing about custom emojis. I don’t think custom emojis are very important to Teams, but others obviously do.

The thing to remember is that the Teams development group serves a very large installed base of over 320 million monthly active users. The base spans very large enterprise tenants like Accenture and Microsoft. It also includes a mix of small businesses, educational, and government tenants. All have their own demands and priorities. This change will please some and annoy others. It’s just the nature of software development.

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.

Block for Federated Communications Imposed on July 29, 2024

In a development reported in message center notification MC805200 (25 June 2024), Microsoft is moving to block a potential attack vector that might be exploited by malicious actors who attempt to launch phishing or abuse attacks against Teams by blocking federated chat from trial tenants. I say “potential” because although demonstrations of how such an attack might happen in the GIFShell and JumpSec exploits, I am unaware of any successful attack.

In any case, an easy fix for phishing attempts from any unknown tenant already exists by not amending the tenant’s external access configuration to restrict federation to a curated tenant list. I advise every tenant to do this because there’s really no need to allow open access to your tenant unless you want to invite unwanted communications. It’s easy to use PowerShell to update the allowed tenant list automatically based on conditions like guest user accounts created within the tenant or even existing federated chats found for user accounts.

But applying an allow list to external federation goes against the philosophy of open federation for chat espoused by Microsoft. I think this kind of thinking is wrong in the current threat climate. All it does is open customers to exploits, which then means that Microsoft is forced to introduce controls.

In this case, Microsoft is introducing a new tenant-wide control for the federation configuration to block external access with trial-only tenants. The new control is called ExternalAccessWithTrialTenants and is set to Blocked by default.

Blocked means that users from trial tenants are unable to search for people or create federated chats with users in your tenant and Teams will remove any users from trial tenants from existing chats. Users from trial tenants will be unable to participate in Teams calls hosted by your tenant, unless those calls permit anonymous join. Likewise, users from your tenant will be unable to connect with users belonging to trial tenants.

If you follow my advice and limit federated communications to an allow list of selected domains, the ExternalAccessWithTrialTenants has no effect because the allow list takes precedence. Trial-only tenants are only permitted if added to the allow list.

Deployment Starts Now

Microsoft says that the deployment of the new setting is complete worldwide, so you should be able to see it by running the Get-CsTenantFederationConfiguration cmdlet from the latest version of the Microsoft Teams PowerShell module:

Get-CsTenantFederationConfiguration | Format-List ExternalAccessWithTrialTenants

ExternalAccessWithTrialTenants: Blocked

Microsoft plans to implement the block on July 29, 2024. If you take no action, federated chat with trial tenants will cease. After that time, if you really want to open your tenant to communications with trial tenants, you can run the Set-CsTenantFederationConfiguration cmdlet to update ExternalAccessWithTrialTenants to Allowed. Don’t make this change.

Trial Tenants

Trial tenants are often used by attackers to secure a foothold within Microsoft 365 that they can use to probe other tenants, including by reaching out to people that they know about (probably through harvesting of email addresses) for a federated chat. In this context, a trial tenant is deemed to be one with a Teams service plan with trial subscriptions. Once a tenant purchases a license that includes a Teams service plan (like Office 365 E3), the tenant is no longer deemed to be a trial. Potential attackers don’t have to spend a lot of money to avoid being detected as trial tenants.

The block applies to Skype for Business on-premises users. That’s because the tenant external access configuration applies to Skype for Business as well as Teams in other Microsoft 365 organizations (Figure 1).

Exceptions

With the block in places, it will still be possible to add users from trial tenants to shared channels or as guest members of teams. You can block these points of entry by using an Entra ID B2B Collaboration policy to limit collaboration with named tenants.

Open Collaboration is Not Always Great

Flaws in technology have a nasty habit of being exposed. Open federation is a nice concept and in a perfect world where everyone behaved, it would be the right approach. It’s like Microsoft’s attitude to Microsoft 365 groups where everyone can create new groups. The fallacy of that approach and the problems it creates for tenant administration were pointed out in explicit terms to Microsoft in 2015. They persisted and created the problem of team rot and digital debris that afflicts so many tenants today. Then Copilot for Microsoft 365 comes along and exposes how easy it is for AI to consume confidential material. Microsoft responds with Restricted SharePoint Search, a terrible solution to a predictable problem of their making.

Plans hatched in Redmond don’t always work out as expected…

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.

Many Mailbox Settings Missing from Outlook Settings API

One of the curious things about the Graph APIs is the incomplete Outlook settings API. It’s a well-known fact that Microsoft has not done a good job of supporting Exchange management operations through the Graph API. Perhaps understandably because of its long-term history with Exchange, PowerShell is the current focal point for Exchange Management automation

Perhaps the Outlook settings API is the starting point for what will become a full-fledged implementation to manage all aspects of mailbox settings. Given the scheduled retirement of Exchange Web Services (EWS) from October 2026. If so, an API covering all aspects of mailbox configuration would be a welcome development. PowerShell is great, but a Graph API is more flexible because of its support. With that thought in mind, let’s review what the current API can do.

Different Clients, Different Settings

Outlook classic (Win32) and OWA (or the new Outlook for Windows) use different client settings. Some crossover exists, such as roaming signatures, but the different history for the clients means that settings are divided into those stored in the system registry (Outlook classic) and those held in user mailboxes (OWA).

Exchange Online supports cmdlets like Get-MailboxCalendarConfiguration to manage mailbox settings, but the Outlook settings API only deals with a limited subset of the settings exposed through the OWA client (Figure 1).

Properties Returned by the Outlook Settings API

The properties returned by the Outlook Settings API are:

• Auto-replies (automaticRepliesSetting).
• Date format (dateFormat).
• Delegate message delivery options (delegateMeetingMessageDeliveryOptions).
• Locale (localeInfo).
• Time format (timeFormat).
• Time zone (timezone).
• Working hours (workingHours)
• User purpose or mailbox type (userPurpose).

The Get-MgUserMailboxSettings cmdlet returns all the properties supported by the Outlook Settings API. Here’s how to fetch the settings for the currently signed-in user:

Connect-MgGraph -Scopes MailboxSettings.ReadWrite
$User = Get-MgUser -UserId (Get-MgContext).Account
[Array]$Settings = Get-MgUserMailboxSetting -UserId $User.Id

$Settings | Format-Table

ArchiveFolder                         : AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNAAuAAAAAAB_7ILpFNx8TrktaK8VYWerAQA3tTkMTDKYRI6zB9VW59QNAABnZQYBAAA=
AutomaticRepliesSetting               : Microsoft.Graph.PowerShell.Models.MicrosoftGraphAutomaticRepliesSetting
DateFormat                            : d MMM yyyy
DelegateMeetingMessageDeliveryOptions : sendToDelegateAndPrincipal
Language                              : Microsoft.Graph.PowerShell.Models.MicrosoftGraphLocaleInfo
TimeFormat                            : HH:mm
TimeZone                              : GMT Standard Time
UserPurpose                           : user
WorkingHours                          : Microsoft.Graph.PowerShell.Models.MicrosoftGraphWorkingHours

To reveal full details of a setting shown with a Graph object type rather than a value, pipe the property to the Format-List cmdlet:

$Settings.Language | Format-List

DisplayName          : English (Ireland)
Locale               : en-IE
AdditionalProperties : {}

As a practical example of using the API, here’s how to configure auto-replies. The example configures a simple HTML auto-reply message for both external and internal senders to be sent during a scheduled period extending from now to 30 days in the future. Details of the different values available to configure the autoreply settings are available online. This code uses some simple hash tables to hold the parameters (for those who care, I find this technique easier and less probe to error than composing a request body in JSON, especially when nesting values).

to error than composing a request body in JSON).
[array]$Settings = Get-MgUserMailboxSetting -UserId $User.Id
$Timezone = $Settings.TimeZone

$Start = Get-Date (Get-Date).AddHours(-2)-format s
$End = Get-Date (Get-Date).AddDays(+30) -format s

$StartDateTime = @{}
$StartDateTime.Add("dateTime", $Start)
$StartDateTime.Add("timezone", $TimeZone)

$EndDateTime = @{}
$EndDateTime.Add("dateTime", $End)
$EndDateTime.Add("timezone", $TimeZone)

$Parameters = @{}
$Parameters.Add("Status", "scheduled")
$Parameters.Add("externalAudience","all")
$Parameters.Add("internalreplymessage",$HtmlMessage)
$Parameters.Add("externalreplymessage",$HtmlMessage)
$Parameters.Add("scheduledEndDateTime",$EndDateTime)
$Parameters.Add("scheduledStartDateTime",$StartDateTime)

$AutoRepliesSetting = @{}
$AutoRepliesSetting.Add("automaticRepliesSetting", $Parameters)
Update-MgUserMailboxSetting -UserId $User.id -BodyParameter $AutoRepliesSetting

The effect of the update to mailbox settings is shown in Figure 2.

OWA and Outlook classic share most auto-reply settings. Three settings specific to OWA are shown under the scheduled period, like “block my calendar for this period.” These settings are not available in Outlook classic and unsupported by the Outlook settings API. Auto-reply settings can be set using the Exchange Online Set-MailboxAutoReplyConfiguration cmdlet, as in this example of configuring auto-replies for shared mailboxes to respond to incoming customer queries over a holiday period.

The Archive Folder

I’m not quite sure why the settings include the mailbox folder identifier for the Archive folder. The Archive folder is one of Outlook’s default mailbox folders and has nothing to do with the online archive. The folder identifier might be present to tell Outlook the target folder when executing the move to archive action.

In any case, an API exists to translate folder identifiers between different formats. The value is stored as a “RestID,” which is the default used by the Graph. Here’s how to translate the identifier to the MAPI format, which is what you’d see when browsing mailbox contents with the MFCMAPI utility.

[array]$SourceIds = $Settings.ArchiveFolder
$Body = @{}
$Body.Add("sourceIdType", "RestId")
$Body.Add("inputIds", $SourceIds)
$Body.Add("targetIdType", "entryid")

$R = Invoke-MgTranslateUserExchangeId -UserId Rene.Artois@office365itpros.com -BodyParameter $Body
Write-Host ("REST format identifier is {0}" -f $R.SourceId)
Write-Host ("MAPI format identifier is {0}" -f $R.TargetId)
REST format identifier is AAMkAGU2MDhlMDhjLTdlZGMtNDMwNC05M2Y4LTIyNzNiYzI5N2VlNwAuAAAAAAC8kIa3heviTIMxxfhY7u2KAQB7Y5w0HV7-Rou7AD9UAhLGAAAAAAE9AAA=
MAPI format identifier is AAAAALyQhreF6-JMgzHF-Fju7YoBAHtjnDQdXv9Gi7sAP1QCEsYAAAAAAT0AAA2

To see more of the gory details about item and folder identifier formats, see Vasil’s blog.

Good in Parts

The Outlook settings API is like a curate’s egg: good in parts. It seems like something Microsoft started on some time ago (look at the 2016 dates used in the update examples) and then forgot. If so, that’s a pity. It would be nice to have full Graph coverage of all Microsoft 365 workload. We’re still waiting and looks like we’ll have to wait for a while yet.

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.

Revealing Full Details of Authentication Methods and Why This Might Be a Privacy Issue

Soon after releasing V1.2 of the Tenant Passwords and MFA Report (to add details about per-user MFA states), I was asked if it was possible to add more information for authentication methods, like the phone number used for SMS responses. My response was that I had covered the topic of reporting the details of authentication methods in a previous article and it was simply a matter of using the code from that article, updating it slightly to deal with the device-based passkeys recently introduced for Entra ID.

Not everyone likes cracking open a PowerShell script to insert code that they didn’t write. I don’t like messing with other peoples’ code either and will usually write my own version when necessary. In any case, I found some time and upgraded the script to include the expanded details, available in V1.3 of the script in GitHub.

Reporting Authentication Methods

Figure 1 shows the information about authentication methods registered for a user account in V1.2 of the report. The information given use the names from the MethodsRegistered property returned by the Get-MgBetaReportAuthenticationMethodUserRegistrationDetail cmdlet from the Microsoft Graph PowerShell SDK.

The problem is that the names aren’t very user-friendly. If you’re used to working with authentication methods, you probably recognize the values and understand what they mean. If not, this information might be useless.

More detail about the methods is available by running the Get-MgUserAuthenticationMethod cmdlet. Even so, some manipulation is necessary to generate human-friendly output. I’d done most of the work before, so it was easy to generate more information for each method. For instance, in Figure 2 you can see the mobile phone number used for SMS challenges and the version of the Authenticator app used for push notifications.

Because the script captures details in a PowerShell list, it’s also possible to query the list to find information like who uses a YubiKey FIDO2 key with a command like:

$Report | Where-Object {$_.'Authentication Methods' -like "*Yubikey*"}

The Privacy Issue

All was going well when I realized that the information generated about authentication methods might include some PII data, like the mobile phone number used for SMS responses. In most instances, I don’t think this will be a problem because details like mobile phone numbers are often included in the properties of Entra ID user accounts. The email addresses used to recover passwords via the Self-Service Password Reset (SSPR) feature are often personal accounts, so they might be more of an issue.

However, the regulations covering access to PII differs from country to country and it’s a good idea to cover all bases. The script now has a PrivacyFlag parameter. It’s a switch parameter, so the value is false by default. If set to true by including the parameter when running the script or by setting the flag explicitly, the script generates the names of the authentication methods without any details.

$PrivacyFlag = $true

On to The Next Version

I am sure that many other good ideas about how to add value to a report like this exist within the community. If you do, suggest the change through the Office 365 for IT Pros GitHub repository (for this script or any of our other scripts). Many people create a fork of our repository and work on updates that way. Whatever’s easier for you…

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

Microsoft Clears the Deck to Permit the New Outlook for Windows to Move to GA

Message center notification MC803006 (last updated 20 June 2024) is an indication that Microsoft is getting close to announcing the General Availability (GA) for the new Outlook for Windows (aka the “Monarch” client). In March, Microsoft indicated that they were approaching GA. This step takes them a tad closer.

MC803006 says that Microsoft will formally rename the Outlook (Win32) app to be Outlook (classic) from July 2024 “to differentiate it from the new Outlook for Windows.” The change is active in Office version 2407 or later.

The classic moniker has been in use for months. The difference is that Microsoft is changing the app name, icons, and listing in the Start menu. Normal users who haven’t been aware of Microsoft’s determination to deliver a new Outlook for Windows will see the name change, and this could prompt questions.

Outlook (Classic) Still Retains Support Until 2029

Microsoft emphasizes that the name change does not affect the status of Outlook (classic) or their previous commitment to support the product until at least 2029. They also point out that they’ve started to use the new naming convention in support documentation.

I’m sure that those who pay attention to naming conventions will distinguish the importance of the change. Regular users will probably still be confused how a slightly better OWA that still isn’t nearly as functional as Outlook (classic) is now the lead Outlook for Windows. However, users can safely ignore naming games because the reason for the change is to allow Microsoft to proceed make the new Outlook for Windows generally available for customers who want to use the client (Figure 1).

Anyone who uses OWA, for instance, will find the new Outlook for Windows to be a better client, especially when Microsoft delivers some of the promised features needed to close the gap with Outlook (classic), like offline mode and support for PST files. Microsoft has an adoption site to document its reasons why organizations should embrace the new Outlook for Windows. Like most similar sites, it includes a mixture of valuable information mixed in with propaganda.

Offline Capabilities for the New Outlook for Windows

According to MC798674 (4 June 2024), support for what Microsoft terms “the first set of offline capabilities” for the new Outlook for Windows is coming in late June 2024 when mail, calendar events, and contacts will be saved on local devices and available for offline working. Users will be able to create, send, and save emails and perform management actions like moving or deleting items. Offline access is not available as of today, but there’s still some time left in June.

Teams 2.1 Loses Its New Label

Meanwhile, MC803890 (21 June 2024) reminds tenant administrators about another forthcoming app rename. This time the new Teams (2.1) client loses its “new” label because the Teams classic client reaches the end of support on July 1, 2024. It’s one way of showing that Teams 2.1 is now the only game in town, unless you’re a VDI or government cloud customer as the Teams classic client continues in support for these environments.

Reaching the end of support doesn’t mean that the Teams classic client stops working. However, anyone running the client will be nagged through dismissible in-app messages to remind them that their software is unsupported.

Starting on October 23, 2024, the Teams classic app will cease working on Windows 7/8 and MacOS Sierra (10.12) desktops. Users of these platforms will have to use the Teams browser client. Starting on July 1, 2025, the Teams classic client reaches the end of the road for everyone and will be formally consigned to the great byte wastebasket for obsolete software products.

Lots of change to deal with!

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.

Running the Set-PlannerUserPolicy Cmdlet Has an Unexpected Effect

Although Planner supports a Graph API, the API focuses on management of plans, tasks, buckets, categories, and other objects used in the application rather than plan settings like notifications or backgrounds. It’s good at reporting plans and tasks or populating tasks in a plan, but the API also doesn’t include any support for tenant-wide application settings. In most cases, these gaps don’t matter. The Planner UI has the necessary elements to deal with notification and background settings, neither of which are likely changed all that often. But tenant-wide settings are a dirty secret of Planner. Let me explain why.

The Planner Tenant Admin PowerShell Module

In 2018, Microsoft produced the Planner Tenant Admin PowerShell module. With such a name, you’d expect this module to manage important settings for Planner. That is, until you read the instructions about how to use the module, which document the odd method chosen by the Planner development group distribute and install the software.

Even the Microsoft Commerce team, who probably have the reputation for the worst PowerShell module in Microsoft 365, manage to publish their module through the PowerShell Gallery. But Planner forces tenant administrators to download a ZIP file, “unblock” two files, and manually load the module. The experience is enough to turn off many administrators from interacting with Planner PowerShell.

But buried in this unusual module is the ability to block users from being able to delete tasks created by other people. Remember that most plans are associated with Microsoft 365 Groups. The membership model for groups allows members to have the same level of access to group resources, including tasks in a plan. Anyone can delete tasks in a plan, and that’s not good when Planner doesn’t support a recycle bin or another recovery mechanism.

What the Set-PlannerUserPolicy Cmdlet Does

The Set-PlannerUserPolicy cmdlet from the Planner Tenant Admin PowerShell module allows tenant administrators to block users from deleting tasks created by other people. It’s the type of function that you’d imagine should be in plan settings where a block might apply to plan members. Or it might be a setting associated with a sensitivity label that applied to all plans in groups assigned the label. Alternatively, a setting in the Microsoft 365 admin center could impose a tenant-wide block.

In any case, none of those implementations are available. Instead, tenant administrators must run the Set-PlannerUserPolicy cmdlet to block individual users with a command like:

Set-PlannerUserPolicy -UserAadIdOrPrincipalName Kim.Akers@office365itpros.com -BlockDeleteTasksNotCreatedBySelf $True

The Downside of the Set-PlannerUserPolicy Cmdlet

The point of this story is that assigning the policy to a user account also blocks the ability of the account to delete plans, even if the account is a group owner. This important fact is not mentioned in any Microsoft documentation.

I discovered the problem when investigating how to delete a plan using PowerShell. It seemed a simple process. The Remove-MgPlannerPlan cmdlet from the Microsoft Graph PowerShell SDK requires the planner identifier and its “etag” to delete a plan. This example deletes the second plan in a set returned by the Get-MgPlannerPlan cmdlet:

[array]$Plans = Get-MgPlannerPlan -GroupId $GroupId
$Plan = $Plans[1]
$Tag = $Plan.additionalProperties.'@odata.etag' 
Remove-MgPlannerPlan -PlannerPlanId $Plan.Id -IfMatch $Tag

The same problem occurred when running the equivalent Graph API request:

$Headers = @{}
$Headers.Add("If-Match", $plan.additionalproperties['@odata.etag'])
$Uri = ("https://graph.microsoft.com/v1.0/planner/plans/{0}" -f $Plan.Id)
Invoke-MgGraphRequest -uri $Uri -Method Delete -Headers $Headers

In both cases, the error was 403 forbidden with explanatory text like:

{"error":{"code":"","message":"You do not have the required permissions to access this item, or the item may not exist.","innerError":{"date":"2024-06-13T17:10:10","request-id":"d5bf922c-ea9b-48c6-9629-d9749ab7ec51","client-request-id":"6a533cf8-4396-4743-acf1-a40c32dd11bc"}}}

Even more bafflingly, the Planner browser client refused to let me delete a plan too. At least, the client accepted the request but then failed with a very odd error (Figure 1). After dismissing the error, my access to the undeleted plan continued without an issue.

A Mystery Solved

Fortunately, I have some contacts inside Microsoft that were able to check why my attempts to delete plans failed and report back that the deletion policy set on my account blocked the removal of both tasks created by other users and plans. The first block was expected, the second was not. I’m glad that the mystery is solved but underimpressed that Microsoft does not document this behavior. They might now…

The moral of the story is not to run PowerShell cmdlets unless you know what their effect would be. I wish someone told me that a long time ago.

Highlighting License Costs for Disabled and Inactive Users with Color

The Microsoft 365 Licensing report is one of the more popular scripts I’ve written. The last set of updates added analysis of licensing costs by department and country. I maintain a list of things that people have asked me to add to the script. Last week, I wanted to take a break from the work to prepare the new edition of the Office 365 for IT Pros eBook, so I fired up Visual Studio Code and got to work.

On my to-list were the following:

• Highlight disabled counts better and report the cost of licenses assigned to disabled accounts.
• Highlight the cost of licenses assigned to user accounts that haven’t signed in for 90 days or more.
• Add Excel worksheet output using the ImportExcel module.
• Categorize the license spend for individual user accounts to be under, average, or high based on the average cost for the tenant.
• Use color to highlight important points in the HTML report (Figure 1). I’m color blind, so the colors I selected to highlight different values might not be to your taste. If so, feel free to select different colors and modify the script by inserting the hex code values of those colors into the style sheet for the report.
• Fix some small bugs. There’s always a couple to clean up.

Summarizing Licensing Costs

Figure 2 shows the updated summary of costs generated at the end of the HTML report. The cost analyses by country and department were in the last update, but I fixed a bug where the report didn’t deal as well as it should do when no licenses are assigned to accounts without a department or country.

The new information is in the section for inactive user accounts and disabled user accounts. Each category lists the set of user accounts that match the criteria together with the total cost of licenses assigned. I used 90 days since the last sign-in to decide if an account is inactive. It’s easy to modify the script to use a higher or lower value, depending on how long it takes before your organization considers an account to be inactive.

Generating an Excel Worksheet for the Licensing Data

Many PowerShell scripts generate CSV files for their output. It’s natural that this should be the case. The Export-CSV cmdlet is part of base PowerShell, and the CSV file format is easy to work with and the data is easy to import back into a PowerShell array.

Some of the CSV files end up as Excel worksheets. It’s easy to do this by opening the CSV file with Excel and saving the file as a worksheet. The ImportExcel module supports the generation of worksheet in many different styles with data inserted into a table ready to be analyzed (Figure 3).

The script checks if the ImportExcel module is available. If it is, the script generates an Excel worksheet. If not, the licensing data is exported to a CSV file.

Important Note and How to Get the Script

If you haven’t run the script before, make sure to read these Practical365.com articles to understand how the script works, how to generate the two (SKU and service plan) CSV files used by the script, and how to add cost data for Microsoft 365 subscriptions. Basically, some up-front work is necessary to prepare reference data for the script to use in its analysis. The code can extract details of user accounts and their assigned licenses from Entra ID, but turning GUIDs into human-friendly product names requires some help. The cost of Microsoft 365 subscriptions differs from country to country too.

You can download V1.9 of the script from GitHub.

Microsoft 365 tenants can have large quantities of licenses to manage. This script might help as written, or inspire you to create your own version tailored to the needs of your organization

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.

Confused Communication Masks a Simple Message About Retirement of Legacy Outlook Clients

Microsoft’s ability to communicate a clear and concise message about software retirements was demonstrated once again by the publication of message center notification MC801980 on June 14, 2024. Titled “Legacy Outlook clients retirement plan,” the post stated:

“Starting in mid-July, for organizations that use vanity domains and their users are on the following version of clients they will experience functionality diminishing:

• Outlook for iOS versions prior to 4.2411.
• Outlook for Android versions before 4.2342.
• Outlook for Mac versions older than 16.73.
• Windows Mail and Calendar applications.”

Copilot for Word required several attempts to rewrite the introduction into comprehensible English. In a nutshell, Microsoft is encouraging people using legacy Outlook clients to upgrade to a more modern version. The suggested versions are:

• Windows Mail and Calendar: the new Outlook for Windows (aka Monarch). Microsoft says that millions of consumer users have already made this switch. Support for these apps terminates at the end of 2024.
• Outlook for Mac: The current version is 16.86.
• Outlook for Android and Outlook for iOS; Build V4.2422.0 is the latest.

MC801980 announces the retirement of OWA light. The news about retirements of legacy Outlook clients caused some fuss and bother. In reality, the announcement is directed more at consumer users than Microsoft 365 organizations, but there is some detail to note.

Upgrade to a Modern Browser Now (Please)

From mid-August 2024, Microsoft will insist that people using OWA or Outlook.com use a recent version of their favorite browser. Internet Explorer is listed, but that doesn’t concern Microsoft 365 users because support for IE terminated on August 17, 2021. Most Microsoft 365 users will have a recent version of a browser on their workstation, so the advice to upgrade from Chrome or Edge version 79 (I’m running Edge version 125.0.2535.92 on my PC) indicates that there must be many Outlook.com users with old software.

The Demise of OWA Light

Microsoft announced some of the news (like the retirement of OWA light) in a technical community post on June 11, 2024. OWA light goes back to the earliest days of browser support for Exchange Server and is still available in Exchange Online (Figure 1). At one time, OWA light was important for low-end devices, but the need has declined over the years and its loss shouldn’t be of huge concern.

Some people use OWA light for accessibility reasons. Microsoft says that the latest version of OWA contains accessibility options, so the need to support a separate client no longer exists. For Exchange Online, Microsoft will remove the IsOptimizedForAccessibility parameter for the Set-CASMailbox cmdlet. Once a tenant is refreshed with the change (from mid-August to late October), mailboxes configured to use OWA Light will see an error page. Losing OWA Light might turn out to be the biggest impact on Microsoft 365 tenants signaled in MC801980.

In the technical community post, Microsoft also announced the termination of basic authentication support for Outlook consumer accounts on September 16, 2024. Taking the two communications together, a consistent message emerges that Microsoft wants its consumer base to move to modern software if users want to connect to its cloud services. It’s exactly what happened in the enterprise space, so this development is no surprise. Modern clients all support modern authentication, so that’s a good reason to upgrade.

Retirements of Legacy Outlook Clients Begin in mid-July 2024

Overall, there’s really nothing more in MC801980 than a call for people to replace old software with newer software. There’s no reason to panic and no need for people to upgrade their Outlook classic clients. The new Outlook for Windows has still not reached general availability. Even when it does, Microsoft says that Outlook classic will remain supported until 2029.

Microsoft will begin the retirement process for the older clients in mid-July 2024 and expect to complete the roll-out by late September 2024. No guarantee can be made about when a block will descend on consumer users or a specific Microsoft 365 tenant, so the call to action is clear: check your software and upgrade as necessary blocks start to descend in mid-July.

Stay updated with developments like client requirements 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.

Set Calendar Permission to Allow Organization Users to See Limited Details

In September 2021, I wrote about how to set the calendar permission for mailboxes to allow users within the organization to view event titles and locations. In the article, I discuss how to use the Set-MailboxFolderPermission cmdlet to update the access rights assigned to the “default user” from availability only to limited details. The permission assigned to the default user is the one used if a more specific permission is unavailable. By allowing more access to a user calendar for the default user, it means that anyone in the organization can see more information from that user’s calendar. In OWA and the new Outlook for Windows (Monarch) client, the sharing permission is called “can view titles and locations” (Figure 1).

Can view titles and locations means that users who check someone else’s calendar to see event subjects and locations. The default shows only that slots in a calendar are blocked or free.

Calendar Permissions and the Graph

Time passes on and today an alternative solution is available in the form of the Graph calendar permission resource and its methods, plus the associated Microsoft Graph PowerShell SDK cmdlets like Get-MgUserCalendarPermission and Update- MgUserCalendarPermission.

The Get-MailboxFolderPermission and Set-MailboxFolderPermission cmdlets have never been quick, so the question is whether the Graph-based cmdlets are faster at checking and setting calendar permissions.

Testing Performance

I decided to test by writing two scripts. Both scripts fetch user and room mailboxes which use the limited availability permission and update the mailboxes to allow access to limited details.

Both scripts use the Get-ExoMailbox cmdlet to fetch mailbox details. There isn’t a good Graph-based method to fetch mailbox-enabled accounts. Get-MgUser can apply a filter to fetch licensed accounts, but that set won’t include room mailboxes. Get-MgUser can fetch all member accounts, but this set will probably include a bunch of accounts that don’t have mailboxes. In addition, because the script loads the Exchange Online management module to use Get-ExoMailbox, it can also use Set-Mailbox to update a custom attribute with an indicator after processing a mailbox.

Maintaining an indicator in a custom attribute is important because the Get-ExoMailbox command can filter out mailboxes that have the permission set. For instance, if you run the script monthly, it will only process mailboxes created since the last run.

Here’s the Exchange Online script. The Set-MailboxFolderPermission cmdlet requires passing the name of the calendar folder, so there’s some code to figure out the value in different languages.

# Exchange Online version 
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, RoomMailbox -Filter {CustomAttribute10 -ne "OpenCalendar"} -ResultSize Unlimited -Properties Languages | Sort-Object DisplayName
Write-Host ("{0} mailboxes found" -f $Mbx.Count)
[int]$Updates = 0
ForEach ($M in $Mbx) {
  # Figure out the name of the Calendar folder in the user's preferred language
  [array]$Languages = $M.Languages
  Switch ($Languages[0]) {
      "en-US" { $CalendarName = "Calendar" }
      "fr-FR" { $CalendarName = "Calendrier" }
      "de-DE" { $CalendarName = "Kalender" }
      "es-ES" { $CalendarName = "Calendario" }
      "it-IT" { $CalendarName = "Calendario" }
      "nl-NL" { $CalendarName = "Agenda" }   
      Default { $CalendarName = "Calendar" }
  }
  # Build the path to the Calendar folder
  $CalendarFolder = ("{0}:\{1}" -f $M.UserPrincipalName, $CalendarName)
  [array]$Data = Get-MailboxFolderPermission -Identity $CalendarFolder | Where-Object {$_.User.usertype.value -eq "Default"} | Select-Object -ExpandProperty AccessRights
  If ([string]$Data -ne "LimitedDetails") {
      Write-Host ("Setting LimitedDetails permission for {0}" -f $M.displayName) -ForegroundColor Yellow
      Set-MailboxFolderPermission -Identity $CalendarFolder -User Default -AccessRights LimitedDetails
      Set-Mailbox -Identity $M.UserPrincipalName -CustomAttribute10 "OpenCalendar"
      $Updates++
  } Else {
      # for some reason the custom attribute is not set to reflect the calendar permission, so update it
      Write-Host "Setting custom attribute for" $M.UserPrincipalName
      Set-Mailbox -Identity $M.UserPrincipalName -CustomAttribute10 "OpenCalendar"
  }
}
Write-Host ("Calendar permission updated for {0} mailboxes" -f $Updates)

Here’s the version using a mixture of Exchange Online and Microsoft Graph PowerShell SDK cmdlet. This code doesn’t need to know anything about language values for folder names because the Graph uses different identifiers.

# Graph version
[int]$Updates = 0
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, RoomMailbox -Filter {CustomAttribute10 -ne "OpenCalendar"} -ResultSize Unlimited -Properties Languages | Sort-Object DisplayName
Write-Host ("{0} mailboxes found" -f $Mbx.Count)
ForEach ($M in $Mbx){
    [array]$CalendarPermissions = Get-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId
  If ($CalendarPermissions) {  
     $OrgDefault = $null
     [array]$OrgDefault = $CalendarPermissions | Where-Object {$_.EmailAddress.Name -eq "My Organization"}  
     If ($Permission -notin $OrgDefault.Role) {
        Write-Host ("Setting Limited Read permission for {1}" -f $M.DisplayName) -ForegroundColor Yellow
        Try {
           Update-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId `
             -Role "LimitedRead" -CalendarPermissionId $OrgDefault.id | Out-Null
           $Updates++
        } Catch {
            Write-Host ("Failed to update calendar permission for {0}" -f $M.DisplayName) -ForegroundColor Red
        }
        Set-Mailbox -Identity $M.ExternalDirectoryObjectId -CustomAttribute10 "OpenCalendar"
        } Else {
          Write-Host ("{0} already has the Limited Read permission" -f $M.DisplayName)
        }
  } 
}
Write-Host ("Calendar permission updated for {0} mailboxes" -f $Updates)

Here’s the version using a mixture of Exchange Online and Microsoft Graph PowerShell SDK cmdlet. This code doesn’t need to know anything about language values for folder names because the Graph uses different identifiers. I can’t account for why Microsoft decided to call the permission LimitedDetails in Exchange and LimitedRead in the Graph. The different roles available for the Graph are documented online.

# Graph version
[int]$Updates = 0
[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox, RoomMailbox -Filter {CustomAttribute10 -ne "OpenCalendar"} -ResultSize Unlimited -Properties Languages | Sort-Object DisplayName
Write-Host ("{0} mailboxes found" -f $Mbx.Count)
ForEach ($M in $Mbx){
    [array]$CalendarPermissions = Get-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId
  If ($CalendarPermissions) {  
     $OrgDefault = $null
     [array]$OrgDefault = $CalendarPermissions | Where-Object {$_.EmailAddress.Name -eq "My Organization"}  
    If ("LimitedRead" -notin $OrgDefault.Role) {
       Write-Host ("Setting Limited Read permission for {0}" -f $M.DisplayName) -ForegroundColor Yellow
       Try {
          Update-MgUserCalendarPermission -UserId $M.ExternalDirectoryObjectId `
            -Role "LimitedRead" -CalendarPermissionId $OrgDefault.id | Out-Null
          $Updates++
       } Catch {
           Write-Host ("Failed to update calendar permission for {0}" -f $M.DisplayName) -ForegroundColor Red
       }
       Set-Mailbox -Identity $M.ExternalDirectoryObjectId -CustomAttribute10 "OpenCalendar"
       } Else {
         Write-Host ("{0} already has the Limited Read permission" -f $M.DisplayName)
       }
  } 
}
Write-Host ("Calendar permission updated for {0} mailboxes" -f $Updates)

The Measure-Command cmdlet generated the test results, which showed that the Exchange script required 2.84 seconds per mailbox to run. The Graph version was nearly a second faster per mailbox (1.96 seconds). Your mileage might vary.

No Need to Change Unless You Must

Using the Graph SDK cmdlets saves almost a second per mailbox. That doesn’t mean that you should update scripts to rip out and replace the Set-MailboxFolderPermission cmdlet. While it’s important to use code that runs quickly, this kind of script is not something you’re going to run daily. It’s more likely to run on a scheduled basis, such as an Azure Automation runbook, and you won’t notice the extra time.

Besides, the most important contribution to performance in this example is reducing the number of mailboxes to process by maintaining the indicator and using the indicator to filter mailboxes. One cmdlet might be faster than another, but it’s how you use cmdlets in a script that dictates overall performance.

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.

Replacing the Incoming Webhook Connector with the Teams Post to Channel Workflow

Last week, I discussed the looming end in sight for Office 365 connectors following their retirement from SharePoint Online and Microsoft 365 Groups. Connectors are still supported to bring information into Teams channels and the incoming webhook connector is a popular choice to create posts in channels from different network sources. For instance, this article describes how to post a notification about a report about expiring Microsoft 365 groups while this article discusses how to post information about service degradation for Office 365 workloads.

Both articles show how to use PowerShell to format the information sent for posting to a channel through the incoming webhook connector. I wanted to do the same thing with Power Automate workflows, specifically with the workflow called Post to a channel when a webhook request is received, which seems very close in concept to the incoming webhook connector: both publish a public URL for information to be sent to, and both demand that the information is formatted in a certain way.

The problem I ran into is a dearth of knowledge about how to construct the request body with PowerShell to send to the workflow. I knew that an adaptive card is used, but the example in Microsoft’s documentation wasn’t a great starting point. But persistence pays and the examples of formatting cards for Teams are better, and the adaptive card designer helped to debug various elements. In the end, I had a solution, and here’s how it works.

Create the Workflow

Channels have a workflows option in their overflow […] menu. Go to the channel you want to use as the target for the notifications and select Workflows (Figure 1).

Select Post to a channel when a webhook request is received from the screen listing available workflow templates (Figure 2).

The workflow needs an account to authenticate connections and post to the channel (this is different to the incoming webhook connector, which doesn’t need to authenticate using an account). The account must be a member of the host team. If, like me, the organization uses a utility account for this kind of operation, you’ll need to add the account to the team or select one of the existing team members. Figure 3 shows that the utility account is selected and validated (green tick). If you want to use a different account, click the […] menu and choose another account to connect.

After collecting all the necessary information, the dialog displays the name of the target team and channel. You can choose a different team or channel at this point. Once the correct target is chosen, click Add workflow. Power Automate proceeds to create the workflow and responds with the workflow URI (Figure 4).

Copy the URL and keep it safe because it is needed to tell Power Automate where to post payloads. When a payload arrives, Power Automate parses its content and if it’s OK, posts the content to the target channel.

If you forget to copy the URI, you can find it by opening the Workflows app, selecting the workflow, and copying it from the When a Teams webhook request is received step (Figure 5). To avoid potential confusion if multiple workflows of the same type are in use, I suggest that you take the opportunity to rename the workflow to make its purpose obvious.

Posting Requests to the Workflow

It’s at this point that we do some PowerShell magic to create the request sent to the workflow URI. To create a realistic example, I decided to use the Get Service Health Graph API to retrieve the current health status for critical services running in the tenant, like Exchange Online, SharePoint Online, Teams, and so on.

The request is an adaptive card, which is composed of elements like text blocks, images, and fact set. I settled on a simple design composed of an image, a heading (text block), and a fact set. A fact has a name and a value. In this case, the name is a service (like “OneDrive for Business”) and the value is the current service health status (like “service degraded”).

I created a prototype adaptive card with indicators where to add the header and facts. Creating the facts is a matter of retrieving the service health status, filtering the data to extract the status for critical services, adding a graphic indicator for each depending on the health status. After generating the data, it was then a matter of formatting it in JSON to meet the requirements of the adaptive card schema and inserting the facts and header into the right places in the prototype adaptive card. The final step is to submit the request using the Invoke-MgGraphRequest cmdlet. Figure 6 shows the result.

You can download the script from GitHub.

Normal Migration Woes

I am no Power Automate expert and profess no insight into how Power Automate works behind the scenes. I approached this exercise from the perspective of a tenant administrator who needs to replace the incoming webhook connector with a workflow. Persistence, some experience with PowerShell, knowledge of how to navigate Microsoft documentation, and trial and error got me a result in a few hours.

Overall, the transition was harder than I expected, but that might be due to lack of knowledge. It’s always difficult to do things when you suffer from that problem. I’ll chalk the experience down to normal migration woes.

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

Per-User MFA State Available for User Accounts Through the Graph

On June 10, 2024, the Microsoft Graph changelog included some interesting additions to the beta version of the authentication resource type to make the settings for per-user MFA retrievable for user accounts. Until now, it’s been possible to see this information through the Entra admin center but not to fetch it programmatically.

The addition of the per-user MFA state is interesting because Microsoft is doing its level best to eliminate per-user MFA from Entra ID. Today, Office 365 E3 and above licenses include the ability to use per-user MFA when connecting to Office 365 services. Per-user Entra ID MFA covers all connections processed by the Microsoft identity service.

Microsoft’s long-term plan for enforcement of multifactor authentication is to use conditional access policies. They’ve put enormous effort over the past few years to build out the capabilities of these policies. The latest update was the ability to block connections using the device code authentication flow, something that all tenants should consider unless a solid business need exists to support device code authentication.

Moving Away from Per-User MFA

To make the transition easier for tenants, some Microsoft-managed conditional access policies are available to organizations with Entra ID P1 or P2 licenses, including one to assist the migration of per-user MFA. A potential issue for those with Office 365 MFA is that moving to conditional access policies requires Entra ID P1 licenses. This isn’t a problem if the organization has purchased Entra ID P1 for other reasons, like self-service password reset, but it is a hurdle to overcome for others. Security defaults is another option for tenants who don’t want to use conditional access policies, especially in the small to medium-sized sectors.

Knowing who still uses per-user MFA is invaluable information for anyone planning to migrate. It’s possible to get details about per-user MFA through the Users section of the Entra admin center, but the user interface is antiquated and unwieldy and the list includes both member and guest accounts (Figure 1).

Being able to extract the information via the Graph allows us to do something like this to find licensed member accounts, check each account for its per-user MFA state, and report the findings. The new capability is in beta for now with no indication of when the V1.0 (production) will support it. Reading the per-user MFA state requires consent to use the Policy.ReadWrite.AuthenticationMethod application permission.

Connect-MgGraph -Scope Policy.ReadWrite.AuthenticationMethod, User.Read.All -NoWelcome

# Get licensed users
[array]$Users = Get-MgUser -Filter "assignedLicenses/`$count ne 0 and userType eq 'Member'" 
-ConsistencyLevel eventual -CountVariable UsersFound -All -PageSize 999
    
If ($Users) {
    Write-Host ("{0} users found" -f $Users.Count)
} Else {
    Write-Host "No users found"
    Break
}

$Report = [System.Collections.Generic.List[Object]]::new()
Foreach ($User in $Users){
  $Uri = ("https://graph.microsoft.com/beta/users/{0}/authentication/requirements" -f $user.id)
  $Data = Invoke-MgGraphRequest -Uri $Uri -Method Get
  $ReportLine = [PSCustomObject][ordered]@{
    User                = $User.UserPrincipalName
    Name                = $User.displayName
    "MFA State"         = $Data.PerUserMfaState
  }
  $Report.Add($ReportLine)
}

$Report | Export-CSV -Path "C:\Temp\MFAState.csv" -NoTypeInformation -Encoding utf8

Accounts can be in one of three states for per-user MFA: disabled, enabled, or enforced. To update the per-user MFA state for an account, use the Patch method:

$Body= @{}
$Body.Add("perUserMFAState", "enabled")

$Uri = ("https://graph.microsoft.com/beta/users/{0}/authentication/requirements" -f $user.id)
Invoke-MgGraphRequest -Uri $Uri -Method Patch -Body $Body

Enhancing the User Passwords and MFA Report

Being able to generate a quick report of per-user MFA states is nice; integrating that data with other sources to create a comprehensive view of account password and MFA properties is even better. In January, I wrote about the inability to query the Graph to find which accounts use MFA. This is because when you use conditional access policies, MFA is the outcome of an assessment against policy for inbound connections rather than a fixed property of user accounts (like per-user MFA). The script I described in the article therefore uses information from several sources, including Entra ID sign-in logs, to report registration of MFA methods, and password change information. The report shows the last time when accounts successfully used MFA to connect, which is the acid test to know if an account uses MFA or not. User registration of MFA methods is one step along the path; using those methods when connecting to Entra ID is what we want to see.

Now that per-user MFA state information is available, I have updated the script (available from GitHub) to include that data. The HTML report generated by the script highlights accounts enabled or enforced for per-user MFA (Figure 2).

The end of the report includes a summary of the findings (Figure 3), including the number of accounts in the enabled or enforced per-user MFA states and the display names of the users in those categories.

The report also generates a CSV file for you to slice and dice the data as you wish.

Nice Addition to Entra ID Data

Being able to report per-user MFA states is a nice addition to the data available to Entra ID administrators. Whether it will convince organizations currently using per-user MFA to move to conditional access policies remains to be seen.

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.

An Overlooked Feature to Block Downloads for Channel Meeting Recordings

Given the size of Microsoft 365 and the fact that you might not use some app features very often, a good likelihood exists that you’ve never heard of some features. Or you might have forgotten that a feature exists. I experienced this feeling during the review of the Managing Videos chapter for the Office 365 for IT Pros eBook (2025 edition) when Vasil Michev, our technical editor, pointed out that the chapter didn’t mention the ChannelRecordingDownload setting for the Teams meeting policy.

This oversight on our part is inexcusable. The setting has existed for quite a while. It’s mentioned in message center notification MC222640, updated August 2, 2021, and our sole excuse is that this update occurred with a bunch of other changes intended to facilitate the migration of Stream classic to Stream on SharePoint. We’ll address the deficit here.

Updating Meeting Policies to Block Download Access for Channel Meeting Recordings

By default, the value of the ChannelRecordingDownload setting in Teams meeting policies is “Allow.” This means that the SharePoint app (app@sharepoint) saves recordings of channel meetings in the Recordings folder for the channel. For instance, recordings for meetings hosted in the General channel end up in General\Recordings while recordings for meeting in a shared channel end up in the Recordings folder. Private channels don’t have a mailbox and don’t support channel meetings. All channel members have access to the MP4 files created for recordings, including the ability to download the files.

Updating the ChannelRecordingDownload setting to block access to channel meeting recordings is not supported by the Teams admin center Instead, use the Set-CsTeamsMeetingPolicy cmdlet from the Teams PowerShell module to update Teams meeting policies. For example:

Set-CsTeamsMeetingPolicy -Identity "Allow Meeting Recording" –ChannelRecordingDownload Block

You might also need to run the Grant-CsTeamsMeetingPolicy cmdlet to assign the updated policy to the set of accounts that you want to block from downloading.

Grant-CsTeamsMeetingPolicy -PolicyName "Allow Meeting Recording" -Identity Ken.Bowers@office365itpros.com

Where Channel Meeting Recordings Go

After updating the meeting policy, SharePoint applies different rules to the storage of and access to channel meeting recordings. Remember that a channel meeting doesn’t really have an owner or organizer. The person who creates a channel meeting acts as the organizer in that they manage invitations and other meeting settings. However, they do not own the recording in the same way as they would for a personal meeting.

When saving channel meeting recording in SharePoint Online, the SharePoint app checks the meeting policy assigned to the organizer and finds that the policy blocks downloads for channel meeting recordings. Instead of saving the MP4 file in the Recordings folder, it saves the file in the Recordings\ViewOnly folder and alters permissions on the file so that only channel owners can download the recording. Everyone else, including the meeting organizer (unless they are also a channel owner) are limited to online view-only access (Figure 1).

The Microsoft documentation offers sparse information on this point and a quick internet search didn’t turn up much else. I guess everyone else missed this change.

The Can View Only Permission

In other related news, an associated change described in message center notification MC699712 (19 December 2023) might also have escaped your attention. This is the update for the share link settings for Stream videos stored in OneDrive for Business and SharePoint Online.

The change introduced the “Can view, but not download” option to the permission drop down (Figure 2) to make it easier for people to share videos that they didn’t want downloaded. It was possible to block downloads for video files beforehand, but it required additional steps to block downloads.

channel member creates a sharing link for a video file in the \ViewOnly folder, they’re restricted to sending a sharing request to the channel owners to request access. This occurs even when sharing with other channel members, even though those channel members already have access.

The Joy of Finding an Overlooked Setting

I’m not particularly worried about the downloading of my videos that other users have access to through Stream. However, I can understand that this might be a concern for others, and it’s good that Microsoft 365 includes controls to limit access in a reasonably painless manner, even if I have totally overlooked the settings for years.

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

Splatting Helps the Readability of PowerShell Code

Splatting is a way to define and use values for parameters dent to PowerShell cmdlets and functions. Instead of specifying a value for each parameter when running a cmdlet, you create a hash table and add the parameters and their values to the hash table. Then you specify the hash table when running the cmdlet. The idea is to avoid long command lines that might or might not be broken up with backticks. Long command lines can sometimes be difficult to scan to understand exactly what the intent of a command is.

Those who endorse splatting say that it’s easy to forget a parameter or a backtick when composing long command lines. In addition, the parameters and values passed in long command lines can be harder to read than a nicely formatted hash table.

Using a development tool like Visual Studio Code will help to make sure that commands are properly formed. After that, using splatting to pass parameters is down to personal choice. And if you pay for a GitHub Copilot license, you’ll discover that Copilot does an excellent job of filling parameter values.

Example of Splatting

Here’s an example of how splatting works. The Set-User command updates many properties of a user account. Note the use of backticks to break the command over several lines:

Set-User -Identity Ben.James -Office 'Dublin Center' -City 'Dublin' `
-CountryOrRegion 'Ireland' -Department 'Sales and Marketing' `
 -DisplayName 'Ben James (Sales)' -Initials 'BJ' -Title 'Senior Lead Manager' ` 
-StateOrProvince 'Leinster' -StreetAddress '1, Liffey Walk' -PostalCode 'D01YYX1' `
-Confirm:$False

Splatting allows you to do this instead:

$Parameters = @{}
$Parameters.Add("Office", "Galway")
$Parameters.Add("Department", "Business Development")
$Parameters.Add("DisplayName", "Ben James (BusDev)")
$Parameters.Add("StateOrProvince", "Connacht")
$Parameters.Add("PostalCode", "GY1H1842")
$Parameters.Add("StreetAddress", "Kennedy Center")
$Parameters.Add("City", "Galway")
$Parameters.Add('Title', "Senior Development Manager")
$Parameters.Add("Identity", "Ben.James@office365itpros.com")
$Parameters.Add("Confirm", $false)

Set-User @Parameters

Adding or changing a parameter is a matter of updating the hash table.

An advantage of using splatting is that it is easy to update objects with common parameters. For instance, to update another user who shares the same office and location values, we can do this:

Set-User -Identity Jane.Sixsmith@office365itpros.com -DisplayName 'Jane Sixsmith' 
-Title 'Promotions Manager' @parameters

PowerShell applies the values for the parameters in the hash table except where a parameter value is explicitly passed.

Microsoft Graph PowerShell SDK Cmdlets And Splatting

In script examples used by articles on this site, we spell out parameters because of personal preference. In addition, the cmdlets in the Microsoft Graph PowerShell SDK can use a construct like splatting when updating or creating objects, meaning that splatting is less of an issue. Because the SDK cmdlets are based on Graph APIs, cmdlets that implement POST and PATCH requests require commands to pass a request body in the Body parameter.

Here’s an example of using the Update-MgUser cmdlet to update a set of properties for a user account with a request body created as a hash table:

$UserId = (Get-MgUser -UserId 'Michelle.duBois@office365itpros.com').id
$Body = @{}
$Body.Add("Office", "Galway")
$Body.Add("Department", "Business Development")
$Body.Add("DisplayName", "Ben James (BusDev)")
$Body.Add("State", "Connacht")
$Body.Add("PostalCode", "GY1H1842")
$Body.Add("StreetAddress", "Kennedy Center")
$Body.Add("City", "Galway")
$Body.Add('JobTitle', "Senior Development Manager")

Update-MgUser -UserId $UserId -BodyParameter $Body

The same hash table can be used with splatting:

Update-MgUser -UserId $UserId @Body

Even complex Graph SDK commands can be converted to splatting. Take the example of using the Get-MgUser cmdlet shown in Figure 1. This is an advanced Graph query because it’s checking the service plans held in (a multivalued property) assigned to user accounts to find accounts with a specific plan. As written, the command is spread over three lines using backticks.

Graph SDK cmdlets like Get-MgUser are based on GET Graph queries so there’s no need to pass a request body. However, the cmdlet parameters can be put into a hash table and passed to cmdlets. Here’s an example using an advanced query with Get-MgUser:

[guid]$SPOPlanId = "5dbe027f-2339-4123-9542-606e4d348a72"
$Body = @{}
$Body.Add("Filter", "assignedPlans/any(s:s/serviceplanid eq $SPOPlanId and capabilityStatus eq 'Enabled')")
$Body.Add("ConsistencyLevel", "eventual")
$Body.Add("Countvariable", "Test")
$Body.Add("Pagesize", "999")
$Body.Add("Property", "Id, displayName, userprincipalName, assignedLicenses, assignedPlans, department, country")
$Body.Add("Sort", "DisplayName")
$Body.Add("All", $true)

[array]$Users = Get-MgUser @Body

Note that switch parameters (like -All in this example) that don’t take a value when run in a command need $true as the value for their entry in the hash table.

Splatting is A Personal Choice

One of the nice things about PowerShell is the variety of styles supported for writing code. Some favor dense masses of commands including some pretty hard-to-understand pipelined code. Some eschew functions and others like to lay out commands with plenty of white space in between. Splatting does a job of defining and passing parameters. It’s up to you to decide how to use it.

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

Support for Office 365 Connectors Ceasing for Microsoft 365 Groups and SharePoint Online

Message center notification MC798683 (4 June 2024) announces the retirement of Microsoft 365 Groups connectors, a form of what are called Office 365 connectors. The retirement process commences on August 5, 2024, and finishes on September 5, 2024. After that time, connectors will no longer be supported within Outlook (Win32), OWA, and the new Outlook for Windows (aka Monarch).

Connectors take notifications from online data sources and post messages into a target destination. In this case, the target is the Inbox in the mailbox of the Microsoft 365 group configured with the connector. These connectors are used with Outlook groups rather than Teams. You can’t configure a connector for the other folders in a group mailbox, and you can’t configure a connector for any other type of mailbox.

Messages delivered through an Office 365 connector are limited to 28 KB and aren’t intended to be complete articles. Instead, they let users know that something has happened, give them a short snippet about the event, and provide a link to follow for more complete information. Using a connector to post messages from an RSS feed is one of the most common uses, but third-party companies like Asana and Trello have created connectors to bring snippets about information from their services to Outlook and other Microsoft 365 targets.

Microsoft recommends that organizations replace group connectors with the Power Automate app, which has its own set of connectors for different data sources, including the ability to create a cloud flow to post messages to the group mailbox. Some of the Power Automate Connectors (like Salesforce and Jira) require a Power Automate premium license.

Connectors and SharePoint Online

A further blow for Office 365 Connectors comes in message center notification MC793656 (16 May 2024), which announces the retirement of connectors from SharePoint Online webparts. Microsoft says that this is due to “limited usage.” Based on anecdotal evidence and personal experience, I can’t recall ever seeing an Office 365 connector configured with a SharePoint Online webpart.

In any case, from June 15, 2024, site owners are unable to add connectors to SharePoint Online. On August 1, 2024, they’ll be unable to update or manage existing connectors and the connectors will stop receiving inbound notifications.

Teams, Office 365 Connectors, and Workflows

Teams still supports Office 365 connectors, which are configured on a per-channel basis because the target for new notifications are channel conversations. Each notification creates a new conversation.

MC798683 points out that Teams channels also support workflows created using the workflows app (“powered by” Power Automate), and workflows recently turned up in the […] menu for Teams chats (MC683929, last updated 24 May 2024).

I shall have to pay more attention to workflows in the future. I know that the basic stuff works very well (like bringing an RSS feed into a channel). I’m more interested in finding out how to replace the incoming webhook connector, which is used in many ways to bring information from applications into Teams.

So far, my experiments with the Post to a channel when a webhook request is received workflow have not been successful. This seems to work in the same way (publish a URL to post messages to) and it’s easy to find the URL, but more difficult to get the workflow to run. I eventually managed and published my experience about posting an adaptive card to Teams.

Moving to a Single Answer for No-Code Automation

All of this seems to be part of a cunning plan to turn Microsoft 365 users into citizen developers by popularizing the use of Power Automate and the Microsoft Power Platform (Figure 1) for no-code automation wherever possible. According to Microsoft (January 2024), Power Automate has 33 million monthly active users in 350,000 organizations. My assumption is that PowerShell and the Graph are the answer for code-based automation.

It’s hard to argue against rationalization and it does make sense to settle on a single no-code automation platform for Microsoft 365, something that wasn’t viable when Office 365 Connectors appeared around 2016. As always, don’t be surprised when change happens inside Microsoft 365. Just be prepared to cope with the change.

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.

SharePoint Online Storage, OneDrive for Business, and SharePoint Embedded

Given the vast numbers of files created in SharePoint Online daily (Jeff Teper cited 2.3 billion in December 2023), it must be the case that the storage quotas assigned to tenants are being consumed at an alarming rate. However, I suspect that a large proportion of the files end up in OneDrive for Business and don’t impact storage so much.

These thoughts came to mind when I perused the OneDrive files report for my account to discover just how many applications now store their data in OneDrive for Business. Microsoft has truly made OneDrive for Business the personal storage system for Microsoft 365 holding anything from Office documents to Teams meeting recordings and transcripts to Whiteboards.

But coming back to storage, I often hear confusion in how Microsoft charges for SharePoint storage. Let’s review the current situation.

Three Major Storage Partitions

SharePoint Online covers three major storage partitions:

• SharePoint Online sites.
• SharePoint Embedded applications, like Loop and Designer.
• OneDrive for Business accounts.

The SharePoint Online storage quota assigned to a tenant (1 TB plus 10 GB per licensed user) covers only the first category. The storage consumed by SharePoint sites is well understood because it’s highlighted in the SharePoint admin center and is easy to report with PowerShell. A Graph usage API is also available for SharePoint Online, but currently suffers from a longstanding data issue that prevents site URLs from being shown.

Understanding the storage consumption of SharePoint Embedded applications is less clear. These applications use file storage containers (like document libraries). First-party applications like Loop charge their storage against the tenant storage quota for SharePoint Online. If the applications support SharePoint Online PowerShell or another API to report storage, it’s possible to generate a report about the storage consumed by an app.

Third-party apps built on top of SharePoint Embedded are billed separately through an Azure subscription using a pay-as-you-go metered model. Charges are accrued for API calls and the storage consumed.

OneDrive for Business Storage

The OneDrive service description says that “the default storage space for each user’s OneDrive is 1 TB. Depending on your plan and the number of licensed users, you can increase this storage up to 5 TB.” The default storage assigned to OneDrive for Business accounts is defined through the Settings section in the SharePoint Online admin center (Figure 1).

In a Microsoft 365 enterprise tenant, the storage for OneDrive can be increased to more than 5 TB. The documentation states: “Before requesting an increase you need at least five licenses that include OneDrive Plan 2, you must assign at least one license to a user, and a single user must have already filled 90% of their 5 TB storage.”

The problem here is that Microsoft stopped offering OneDrive Plan 2 in August 2023, apparently to stop offering the “unlimited storage capacity” that was once available for licenses like Office 365 E3 and E5. No official notice was given, and the plan slipped away. Office 365 and Microsoft 365 licenses no longer include a OneDrive service plan.

In any case, if you want to keep an eye on OneDrive storage consumption, it’s easy to generate a report with PowerShell.

Microsoft 365 Archive

Microsoft 365 Archive is a solution that moves SharePoint Online sites from “hot” storage (immediate access) to “cold” storage. The idea is that organizations can keep data online in a form that’s available for eDiscovery but not for user access. Archiving sites also helps to remove information from consumption by AI solutions like Copilot for Microsoft 365 to stop the results generated by AI being affected by old and possibly obsolete information.

Organizations pay for the storage consumed by archived sites through an Azure subscription. The cost per GB is much less than having to pay for regular SharePoint storage and Microsoft doesn’t charge for archive storage if the tenant has regular storage available. If the tenant runs out of regular storage, Microsoft 365 archive switches to its pay-as-you-go model.

Retention Storage

Microsoft 365 Retention Policies and Retention Labels can dictate how long content stored in SharePoint Online (including OneDrive for Business and SharePoint Embedded) is kept before it can be deleted. If files coming within the scope of retention are deleted by users, SharePoint Online keeps them in the site’s preservation hold library. Depending on the settings of retention policies and labels, it’s possible that preservation hold libraries can consume a large amount of storage (Figure 2).

Retained content can be easy to overlook. Microsoft plans to introduce intelligent versioning (originally planned for November 2023), which should help.

Summarizing SharePoint Online Storage

In summary, traditional SharePoint site storage is only one of the ways that tenant storage quota can be consumed. OneDrive for Business stores more data than ever before, but Microsoft has renounced unlimited storage. New applications and retention can consume storage unexpectedly, and Microsoft 365 Archive can help by moving data to cheaper cold storage. What could be easier to understand?

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.

Change in Audit Records for Teams Meeting Recordings Since 2021

Three years ago, I wrote about how to use audit records to track the creation of Teams meeting recordings. The idea was to find the audit records created when a Teams meeting recording was uploaded to OneDrive for Business or SharePoint Online.

Time marches on and old blogs rot, as do old PowerShell scripts. Three years ago, Microsoft hadn’t completed the transition from Stream classic to Stream on SharePoint. The migration finished recently and Microsoft has moved to standardize how Teams meeting recordings and transcripts are stored in OneDrive for Business. Of course, OneDrive only holds recordings for personal meetings. Recordings for channel meetings, including Meet Now in the channel, end up in the SharePoint Online site belonging to the host team.

Closing a Compliance Gap

While some might think that I spend endless hours examining audit records, this is a fallacy. I check on an as required basis, which means that I didn’t notice that my script wasn’t working quite so well because the format of the audit records changed. One important change is that the user noted in all the audit records is app@sharepoint, the ubiquitous SharePoint utility account. No trace exists in the audit records about the user who recorded the meeting, as had happened before.

From a compliance perspective, this is a big deal. Audit records exist to track the actions taken by individuals and system processes, and in this case, it seems important to know who initiated a recording.

Unfortunately, there’s nothing in the audit record to indicate who initiated the recording of a channel message, so we’re left with the SharePoint app. Recordings for personal meetings used to end up in the OneDrive account of the user who started the recording (the organizer or a presenter). Some time ago, Microsoft changed this to a more logical arrangement where recordings always go into the meeting organizer’s OneDrive account. The URL of a OneDrive account contains the site URL, like:

https://office365itpros-my.sharepoint.com/personal/jane_ryan_office365itpros_com

Figuring Out the OneDrive Site Owner

It’s easy for a human to read the URL and know that the OneDrive account belongs to Jane.Ryan@office365itpros.com. With time, I could parse the URL to extract the email address, but I went for a simpler (faster) approach. I used the Get-SPOSite cmdlet from the SharePoint Online PowerShell module to fetch the set of OneDrive accounts in the tenant and created a hash table from the site URL and site owner. It’s fast to check the hash table with the site URL taken from an audit record to return the user principal name of the site owner:

$User = $OneDriveHashTable[$AuditData.SiteURL]
If ($null -eq $User) {
   $User = "SharePoint app"
}

Changes in Search-UnifiedAuditLog Too!

Another influence on the output was the change made by Microsoft in summer 2023 to how the Search-UnifiedAuditLog cmdlet works. Microsoft have denied to me that they did anything, but the evidence shows that:

• The SessionCommand parameter must now be set to ReturnLargeSet to force the cmdlet to return more than 120 records.
• Many more duplicate records are returned than before. This necessitates sorting by the unique audit event identifier to remove the duplicates.
• Search-UnifiedAuditLog returns unsorted data. If a sorted set is important to you, make sure that you sort the audit records by creation date.

$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [datetime]} -Descending

Of course, you can try to run high completeness searches with Search-UnifiedAuditLog, but I have not had good luck with this preview feature.

Figure 1 shows the output from the updated script, which is available from GitHub. Normal service is resumed.

A Reminder to Check Audit Log Analysis Scripts

It would be nice if a script lasted a little longer, but the ongoing change within Microsoft 365 means that PowerShell developers need to keep a wary eye on updates that might affect production scripts. In this instance, the confluence of the Stream migration and the change to the Search-UnifiedAuditLog cmdlet made a mess of a perfectly good script. I guess life is like that sometimes. Maybe now is a good time to check your scripts that use the Search-UnifiedAuditLog cmdlet.

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.

Extract and Report Delegated Permission Assignments with the Microsoft Graph PowerShell SDK

When discussing permissions used to retrieve data with Graph API requests (including cmdlets from the Microsoft Graph PowerShell SDK), most of the time we refer to application permissions rather than delegate permissions. The reason is simple: when automating operations with PowerShell, tenant administrators usually process data drawn from multiple sources, like all user mailboxes or all groups. This level of processing requires application permissions.

Delegated permissions (also called scopes) allow apps to access information on behalf of the signed in user. Anything that user can access, the app can too. Usually, the user is the owner of a resource (like their mailbox), but they can gain access to information through an RBAC role, such as Teams administrator.

Delegated permissions are granted by a specific resource (like a Graph API) and represent the operations that an app can perform for the user. For instance, the Mail.Read scope allows an app to read messages in the user’s mailbox. The grant of consent for a delegated permission usually happens when a user signs into an app and the app discovers that consent for the required permission is not granted. At this point, Entra ID displays the consent prompt window to allow the user to give consent for the app to use the permission and proceed.

Reporting Permissions

Application permissions assigned to apps can be checked by examining the app role assignments for service principals. It’s a good idea to inventory app permissions periodically to ensure that apps don’t have high-profile permissions without good reason.

To report delegated permissions, we need to check delegated permission grants (otherwise called OAuth2 permission grants). These are delegated permissions granted for a client application to access an API on behalf of a signed-in user. The Microsoft Graph PowerShell SDK cmdlet used for this purpose is Get-MgOauth2PermissionGrant. The Directory.Read.All permission is required to read details of delegated permissions and user accounts.

Interpreting a Delegated Permission for Users

After connecting, run the Get-MgUser cmdlet to create an array of user accounts to query. Usually, I apply a filter to find licensed accounts. Once you have a set of accounts, it’s a matter of looping through the set to find the delegated permissions for each account:

[array]$Permissions = Get-MgUserOauth2PermissionGrant -UserId $User.Id -All

An individual permission assignment looks like this:

$Permission | Format-List

ClientId             : 5482d706-b547-4b9d-b159-b91a5776e0e9
ConsentType          : Principal
Id                   : BteCVEe1nUuxWbkaV3bg6YnEoxRs7QVAltG-nFdw96NYzfTvuBuZSJTeeV9la0oY
PrincipalId          : eff4cd58-1bb8-4899-94de-795f656b4a18
ResourceId           : 14a3c489-ed6c-4005-96d1-be9c5770f7a3
Scope                :  openid profile User.ReadWrite User.ReadBasic.All Sites.ReadWrite.All Contacts.ReadWrite People.Read Notes.ReadWrite.All Tasks.ReadWrite Mail.ReadWrite Files.ReadWrite.All Calendars.ReadWrite Group.Read.All Group.ReadWrite.All Directory.AccessAsUser.All Directory.ReadWrite.All User.ReadWrite.All IdentityRiskEvent.Read.All Reports.Read.All AuditLog.Read.All User.Read SecurityEvents.ReadWrite.All offline_access TeamSettings.Read.All TeamSettings.ReadWrite.All Mail.ReadBasic Chat.Read Chat.ReadBasic Analytics.Read
AdditionalProperties : {}

• The client identifier points to the service principal for the client app. In this case, it is the Graph Explorer.
• The principal identifier points to the identifier for the user account. Because we’re listing delegated permissions by user, the consent type for the permission is always Principal, meaning that the app is limited to impersonating the specific user. If the consent type is AllPrincipals, meaning that the app can use the consent to impersonate all users, the principal identifier would be empty.
• The resource identifier points to the service principal for the resource. In this example, the resource identifier points to “Microsoft Graph” (the Graph API). The set of permissions (Scope) confirm this because they are Graph permissions. As you can see, the Graph Explorer has consent for many permissions. This is a normal situation if developers use the Graph Explorer to test different Graph APIs.

Processing Delegated Permissions for AllPrincipals

After processing the delegated permission assignments for user accounts, we process those for all principals (any user). The set of assignments is found with:

[array]$AppGrants = Get-MgOauth2PermissionGrant -filter "consentType eq 'AllPrincipals'" -All

Steps in the Script

The steps in the script are as follows:

• Find the set of user accounts.
• For each account, check if any delegated permissions exist.
• For each permission, check the client app and resource.
• Find the set of delegated permissions for all principals.
• Do much the same as for individual assignments.
• Report what’s been found.

Figure 1 shows the output generated.

You can download the full script from GitHub.

Interpreting the Results

It’s inevitable that delegated permissions will accumulate over time. Looking at the results from my tenant, I see evidence of the iOS account migration to modern authentication from 2021, apps from conference organizers like Sessionize and Community Days, the app used to register for the Microsoft Technical Community, and so on. All these assignments are understandable. The question is whether the assignments are needed any longer and if not, should they be removed. That’s up to you…

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.

Which to Choose for PowerShell Development?

I’m sometimes asked why people should bother using the Microsoft Graph PowerShell SDK to develop PowerShell scripts. The arguments against the SDK are that it’s buggy, doesn’t have great documentation, and adds an extra layer on top of Graph API requests. I can’t deny that the SDK has had recent quality problems that shook developer confidence.

I cannot advance a case that Microsoft’s documentation for the Graph PowerShell SDK cmdlets is good because it’s not. Some improvements have been made over the last year, but the examples given (copied mostly from the Graph documentation) are too simple, if they exist at all. There’s also the small fact that the Graph PowerShell SDK cmdlets share some foibles that make them less useful than they should be.

Given the problems, why continue to persist with the Graph PowerShell SDK? I guess the reason is that the SDK cmdlets are easier to work with for anyone who’s used to PowerShell development. For instance, the Graph SDK automatically performs housekeeping operations like retrieving an access token, renewing the token (only needed for long-running scripts), and pagination. None of these operations are complex. Once mastered, the same code can be copied into scripts to take care of these points.

Call me mad, I therefore persist in writing scripts using Graph PowerShell SDK cmdlets. However, times exist when it’s necessary to use a Graph API request, including when:

• Microsoft’s AutoRest process has not processed a new API to create a cmdlet.
• The data returned by a cmdlet is not as complete as the underlying Graph API request. This shouldn’t happen, but it does.
• It’s necessary to retrieve properties that a cmdlet doesn’t support.

Let’s look at examples of the last two points.

Fetching Attendee Data with Microsoft Graph PowerShell SDK Cmdlets and API Requests

I’ve used the List CalendarView API in situations like reporting usage statistics for room mailboxes. Here’s an example of retrieving calendar events between two dates.

$Uri = ("https://graph.microsoft.com/V1.0/users/{0}/calendar/calendarView?startDateTime={1}&endDateTime={2}" -f $Organizer.Id, $StartDateSearch, $EndDateSearch)

The resulting URI fed to the Invoke-MgGraphRequest cmdlet looks like this:

$Uri
https://graph.microsoft.com/V1.0/users/4adf6057-95da-430a-8757-6a58c85e13d4/calendar/calendarView?startDateTime=2024-03-28T12:56:37&endDateTime=2024-05-29T12:56:37

$Items = Invoke-MgGraphRequest -Method Get -Uri $Uri | Select-Object -ExpandProperty Value

You might ask why I use Invoke-MgGraphRequest (a cmdlet from the Microsoft Graph PowerShell SDK) rather than the general-purpose Invoke-RestMethod cmdlet. It’s because I start scripts off with the Graph PowerShell SDK and only go to standard Graph API requests when necessary.

In any case, the attendees of a meeting are returned like this:

attendees                      {System.Collections.Hashtable, System.Collections.Hashtable, System.Collections.Hashtable, System.Collections.Hashtable}

The attendee data are available in individual hash tables and are easy to access:

$Items[0].attendees

Name                           Value
----                           -----
emailAddress                   {[address, Sean.Landy@office365itpros.com], [name, Sean Landy]}
status                         {[response, none], [time, 01/01/0001 00:00:00]}
type                           required
emailAddress                   {[address, Lotte.Vetler@office365itpros.com], [name, Lotte Vetler (Paris)]}
status                         {[response, none], [time, 01/01/0001 00:00:00]}

Get-MgUserCalendarView is the equivalent cmdlet in the Microsoft Graph PowerShell SDK. This command does the same job as the List CalendarView API request above.

[array]$CalendarItems = Get-MgUserCalendarView -UserId $Organizer.id -Startdatetime $StartDateSearch -Enddatetime $EndDateSearch -All

Attendees                     : {Microsoft.Graph.PowerShell.Models.MicrosoftGraphAttendee, Microsoft.Graph.PowerShell.Models.MicrosoftGraphAttendee}

$calendarItems[0].Attendees

Type
----
required
required

The attendee data is incomplete. No information is available about the attendees’ email addresses and display names. That’s why my scripts use the API rather than the cmdlet.

How the Microsoft Graph PowerShell SDK Cmdlets Return Data

When you run a Graph PowerShell SDK cmdlet, the returned data ends up in an array, which is convenient for further PowerShell processing. You’ll note that I use the -All parameter to fetch all available objects.

$AllUsers = Get-MgUser -All

$AllUsers.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

Things are a little more complicated with Graph API requests. We get an array back, but the array contains a hashtable. The actual data that we might want to process is in the record with the Value key. We also see an @odata.nextlink to use to fetch the next page of available data:

$Uri = "https://graph.microsoft.com/v1.0/users"
$Data = Invoke-MgGraphRequest -Method Get -Uri $Uri
$Data.GetType()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     Object[]                                 System.Array

$Data

Name                           Value
----                           -----
@odata.context                 https://graph.microsoft.com/v1.0/$metadata#users
value                          {44c0ca9c-d18c-4466-9492-c60c3eb78423, bcfa6ecb-cc5b-4357-909c-1e0e450864e3, da1288d5-e63c-4118-af62-3280823e04e1, de67dc4a-4a51-4d86-…
@odata.nextLink                https://graph.microsoft.com/v1.0/users?$skiptoken=RFNwdAIAAQAAABc6Z3NjYWxlc0BkYXRhcnVtYmxlLmNvbSlVc2VyX2UwNjIzZjE0LTUzM2QtNDhmYS1hODRl…

In most cases, I simply create an array of the data and then go ahead and process the information as normal for an array:

[array]$Data = $Data.Value

The Invoke-MgGraphRequest cmdlet supports output to a PowerShell object.

$Data = Invoke-MgGraphRequest -Method Get -Uri $Uri -OutputType PsObject

The output data is the same but it’s in the form of an array rather than a hash table:

$Data | Format-List

@odata.context  : https://graph.microsoft.com/v1.0/$metadata#users
@odata.nextLink : https://graph.microsoft.com/v1.0/users?$skiptoken=RFNwdAIAAQAAABc6Z3NjYWxlc0BkYXRhcnVtYmxlLmNvbSlVc2VyX2UwNjIzZjE0LTUzM2QtNDhmYS1hODRlLTljOTg0MDhkNDgxYbkAAAAAAAAAAAAA
value           : {@{businessPhones=System.Object[]; displayName=12 Knocksinna (Gmail); givenName=12; jobTitle=; mail=12knocksinna@gmail.com; mobilePhone=;
officeLocation=; preferredLanguage=; surname=Knocksinna; userPrincipalName=12knocksinna_gmail.com#EXT#@RedmondAssociates.onmicrosoft.com;
id=44c0ca9c-d18c-4466-9492-c60c3eb78423}, @{businessPhones=System.Object[]; displayName=Email Channel for Exchange GOMs; givenName=Teams;
jobTitle=; mail=5e2eb5ab.office365itpros.com@emea.teams.ms; mobilePhone=; officeLocation=; preferredLanguage=; surname=Email Channel for GOM List;

Once again, the data to process is in the Value record.

I usually don’t bother outputting to a PowerShell object, perhaps because I’m used to dealing with the hash table.

Mix and Match

The important thing to remember is that a PowerShell script can mix and match Graph API requests and Graph PowerShell cmdlets. My usual approach is to start with cmdlets and only use Graph requests when absolutely necessary. I know others will disagree with this approach, but it’s one that works for me.

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.

Users Can Add Teams Custom Emojis for Everyone to Share

Borrowing a tad from Slack (which has had the ability to upload custom emojis for years), message center notification MC795750 (updated 31 May 2024, Microsoft 365 roadmap item 80659) announces that Teams users will soon be able to add custom emojis and reactions by uploading image (PNG) or GIF files. Once uploaded, custom emojis are accessible to everyone in the tenant, which can support a maximum of 5,000 custom emojis.

Microsoft plans to make the feature available to targeted release tenants in late June 2024. General availability will follow in early July 2024 with GCC High and DoD tenants getting custom emojis in August 2024.

Custom Emojis On By Default

The ability to upload custom emojis is controlled by the CreateCustomEmojis setting in Teams messaging policies. Microsoft plans to ship the feature enabled, meaning that the setting should be True in all messaging policies. There will also be a setting in the Teams admin cenrer to disable or enable custom emojis tenant-wide.

Here’s how to use the Get-CsTeamsMessagingPolicy cmdlet from the MicrosoftTeams PowerShell module to check the values for the CreateCustomEmojis (create and upload new emojis) and DeleteCustomEmojis (delete custom emojis) settings.

Get-CsTeamsMessagingPolicy | Format-Table identity, *emojis*

Identity                                    CreateCustomEmojis DeleteCustomEmojis
--------                                    ------------------ ------------------
Global                                                   False              False
Tag:Advanced                                              True              False
Tag:Advanced Users                                        True              False
Tag:Restricted - No Chat                                  True              False

You need the latest version of the MicrosoftTeams module to manage custom emojis.

To turn custom emojis off, run the Set-CsTeamsMessagingPolicy cmdlet to update messaging policies. In this example, custom emojis are disabled for any account assigned the Advanced messaging policy.

Set-CsTeamsMessagingPolicy -Identity Advanced -CreateCustomEmojis $false -DeleteCustomEmojis $false

Teams admin center receives an update in June (Figure 1) to allow administrators to manage the emoji settings in messaging policies without using PowerShell. Global and Teams administrators can delete custom emojis no matter what the messaging policy assigned to their account dictates.

Adding a Custom Emoji

To add a custom emoji, open the emoji and reactions menu and select the custom category (to the far right side of the other categories). If your account is allowed to add a custom emoji, you’ll see a plus sign. Click the plus sign to select the file for the new emoji. Only PNG and GIF files are supported. I took a photo from a recent trip to Disney World featuring a certain mouse and edited it to isolate the mouse character. I then saved the file as a PNG. Microsoft doesn’t say if the file should be under a certain size, but I took no chances and made sure that it was less than a megabyte. I uploaded the file and Teams invited me to name the emoji (Figure 2). You can see in the preview how the emoji will look in different situations.

Guest accounts cannot add a custom emoji. However, they can use the custom emojis created by tenant members. Seeing the custom emojis in a host tenant gives an interesting insight into the culture of that organization (Figure 3).

Deleting a Custom Emoji

Once uploaded, custom emojis become available to all users and show up in the custom section. Users granted the ability to remove custom emojis can select and delete emojis from the same place (Figure 4).

Microsoft says that it can take up to 24 hours for a deleted emoji to disappear.

Prepare for Some Interesting Teams Custom Emojis

On May 31, 2024, Microsoft updated MC795750 to say that the custom emojis feature will not come to organizations with education licenses. I think this is a reasonable decision. There’s no doubt that teachers have better things to do than keep an eye out for inapproptiate emojis appearing in chats and channels.

In the corporate world, based on experience with Slack, it’s probable that organizations will see a surprising array of custom emojis appear after users discover that this capability exists (and they will, and fast). Some custom emojis will be marvelously witty; others will be scandalous and offensive. With up to five thousand custom emojis per tenant, there’s lots of room to experiment with all sorts of images. Let the games commence.

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.

Notify When Available Tracks the Availability of Other Users

Usually, the Teams developers can be criticized for informing customers about new features a long time in advance of actual availability. In a change to normal practice, Microsoft published message center notification MC797120 about the Notify when available feature for the new Teams client on May 30 and observed that they had been rolling out the feature to targeted release tenants since mid-May. General release tenants should see the feature showing up any date now because worldwide general deployment is scheduled to complete in early June.

Possibly the reason why Microsoft went ahead and released Notify when available feature without any warning is that this functionality exists in the old Teams client but not in the new 2.1 client (see “Features that are changing in the new Teams”). Users had complained about the loss of the feature (here’s an example of one of many questions on the topic from the Microsoft Answers forum). Releasing Notify when available removes one more thing off the “Make Teams 2.1 complete” list. I hope Microsoft moves on to restore the save messages option soon.

What Notify When Available Does

Notify when available is a mechanism to tell Teams that you’re interested in knowing when the presence status for another user changes to available. The kind of scenario that this feature is useful in is when you know that someone is going to be heavily committed to other tasks during a day, but you need to speak to them for a moment.

Taking out a subscription on their presence status makes Teams aware that you want to know when the person changes their presence to available. When that happens, Teams sends a notification that the person is now available and it’s up to you to reach out and contact them.

Using Notify When Available

The easiest way to know when someone is available is to find the person you want to communicate with in your chat list (not in a popped-out chat window). Perhaps they’re available now, in which case you can connect, or it will be like the situation shown in Figure 1 where Sean Landy is busy. To create the subscription, select Notify when available from the […] menu.

Once a subscription is in place, you’ll continue to receive a notification (Figure 2) each time the user changes their presence status to available.

Because Teams monitors the presence status for the account, the change to “Available” is detected immediately, and the notification arrives soon afterward. Changes in presence to other states like Busy, Appear offline, etc. do not generate a notification.

Disabling Notifications

Although it’s possible to leave a subscription in place permanently and continue to receive notifications when someone is available, most people only need to be notified once or twice. To remove a subscription, open the […] menu for the user and select Turn off notifications.

To view all subscriptions currently active, go to the People section in Notifications settings in the Teams Settings app (Figure 2). You can now turn off whichever subscription you’re no longer interested in contacting or add subscriptions for some new people.

To stop receiving notifications, you can turn them off in your app settings (#2 above).

For the record, here’s the Microsoft support article for the Notify when available feature.

Transitions are Hard

There’s no doubt that transitions are hard, especially for client software that’s packed full of features accumulated over years. In that light, Microsoft has done a reasonable job of replaced the original Teams client with Teams 2.1. Certainly, they’re in a place that the new Outlook for Windows developers would like to be, a larger installed base transitioned and most people happy. I wonder will the situation be the same when Microsoft eventually retires Outlook classic in 2029?

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.

Monthly Update #108 Released to Subscribers

The team is happy to release the final update for the Office 365 for IT Pros 2024 edition. Monthly update #108 is the eleventh and last update for this edition as we will release the Office 365 for IT Pros 2025 Edition on July 1, if all our plans proceed as we hope.

Subscribers should download the latest files from their Gumroad.com account or use the link in the receipt they received after the original purchase. More information about obtaining updated files is available in our FAQ. We’ve updated the Kindle book files on Amazon.com too. Unfortunately, purchasers of the Kindle book must contain Amazon support to gain access to the updated files.

A Massive Source of Knowledge

The updated book contains a mixture of new information, changes, and deletions as we keep pace with the ongoing flood of changes for Microsoft 365 applications delivered by Microsoft. To give some idea about the effect on the book of tracking change, the July 2023 release spanned 1,352 pages (693,609 words). The current update spans 1,429 pages (733,864 words).

Since we released Office 365 for IT Pros 2024 edition, we’ve added 67 pages (net) with 40,255 words. Behind those raw statistics are a bunch of changes (which might not affect page or word count) and deletions (which create space for new material). A glance at our change log gives an insight into where the changes occurred. If anyone doubts the usefulness of a book that’s constantly updated to cater for ongoing change in a technology, they only need to look at our change log.

The New Version

A new version gives the writing team the chance to review the book end to end. We’re currently in the middle of a comprehensive technical edit process to improve material, identify outdated content that’s lingering and occupying space, address areas that need additional explanation, and even update screenshots to match current user interfaces. Microsoft developers appear to be fascinated by user interface tweaks. They change one or two words on a screen and don’t say anything, so we only find out about the need for a figure update if someone tells us or we notice the change.

The tasks listed above are the norm for us. The 2025 edition is the eleventh in a series going back to 2015. This time around, we plan to make some more fundamental changes.

No More Companion Volume after the 2024 Edition

First, we’re dropping the companion volume. This book was intended to be the place where we could move old content so that people who still needed the information could find it. However, the companion volume has become increasingly decrepit, and we doubt if many still use it. Another factor to consider is the improvement in Microsoft documentation over the years, meaning that those who need information about something like Microsoft Forms or Sway can find it online.

A New PowerShell Book

Second, as obvious from the numbers cited above, the main book is too big. We’ve thought about this a lot and concluded that the best way forward is to split off standalone books covering selected topics. At the end, we might end up with a group of six books under the Office 365 for IT Pros banner. For now, we will start with PowerShell and have created a standalone 200-page book called “Automating Microsoft 365 with PowerShell.” We plan to sell this book on its own as well as bundling it with Office 365 for IT Pros.

The main book still includes many PowerShell examples where they fit in context. However, the in-depth discussions about PowerShell, the Microsoft Graph PowerShell SDK, and using Graph API requests from PowerShell have a new home. The PowerShell book includes about 40% more content than the equivalent chapter in the 2024 edition.

It’s too early to say yet what the next standalone book will be. It could cover Groups and Teams, or maybe Compliance. We’re still noodling on that topic.

What is clear is that Office 365 for IT Pros subscribers will receive both the main book and any standalone books we create. You won’t lose access to any information. In fact, you’ll have even more information at your fingertips.

Subscribing to Office 365 for IT Pros 2025 Edition

We still have one more month to run before Office 365 for IT Pros 2025 Edition is available. We understand that people are unwilling to subscribe to a book that will soon be replaced. Our offer is that anyone who subscribes to Office 365 for IT Pros 2024 edition in June 2024 will receive a free upgrade to the 2025 edition when it is available.

As to our current subscribers, we thank you for your support. Without your backing we could not afford to spend the time we do to keep the book updated. After we publish the 2025 edition, you’ll be able to upgrade your subscription for a heavily discounted price. It’s our way of saying thank you.

Copilot Audit Records Now Include Resources Used in Responses

In April 2024, I wrote about the appearance of audit events to capture details when Microsoft 365 applications call Copilot to process a user request (prompt). These events have an operation type of CopilotInteraction.

Since then, Microsoft announced progress in capturing records when people use Copilot in the Stream player to query video transcripts (MC720180, last updated 22 May 2024). It’s like MC720180 (also updated on 22 May 2024), which describes using Copilot to interact with meetings. In both cases, the important point is that the audit events generated for Copilot interactions capture details of resources accessed by Copilot when responding to user prompts (previously the AccessedResources property in the AuditData payload was empty).

Linked to the Change in Transcript Storage Location

Because Copilot depends on meeting transcripts to answer queries, meeting interactions are only possible when meetings are recorded with a transcript. As discussed last week, Teams is standardizing on OneDrive for Business storage for the MP4 files generated for meeting recordings and transcripts. Like many situations in Microsoft 365, developments reported in one message center notification are linked to what’s described in another, seemingly unconnected, update.

The change should be effective in most places now as Microsoft aims to complete worldwide deployment in early June 2024.

Updated Script to Handle Copilot Audit Records

To test the effectiveness of the change, I updated the script I wrote for the previous article (downloadable from GitHub) to support audit records generated by the Stream player and to pay more attention to the data recorded in the associated resources property. Figure 1 shows the output of the script as viewed through the Out-GridView cmdlet.

Please check out the updated script and let me know if it’s helpful or could be improved.

Copilot in Outlook Classic

Speaking of Copilot, for a long time Microsoft communicated the message that Copilot experiences would only be available in the new Outlook client (aka Monarch). This was no more than a thinly-disguised ploy to drive adoption for Monarch, which still isn’t close to ready for consumption by corporate users.

In any case, message center notification MC794816 (21 May 2025, Microsoft 365 roadmap item 388753) reports the availability of the Copilot for Microsoft 365 chat experience for Outlook classic (Win32). This feature joins “Summarize,” the Copilot option that extracts the major points from an email thread (my second favorite Copilot feature after meeting summarization), and the option to have Copilot draft or revise message drafts. Microsoft will roll out Copilot for Microsoft 365 chat to Outlook classic in the current channel in June 2024.

Before anyone gets too excited, let me say that Copilot for Microsoft 365 chat in Outlook is the same application as accessed as a web application and in Teams. The only difference is that Copilot has an icon in the Outlook application bar and runs in the Outlook window (Figure 2). In other words, if you’re used to Copilot chat elsewhere, you’ll find no difficulty using it in Outlook, providing you have the necessary Copilot for Microsoft 365 license.

As you can see from Figure 2, chats generated in other instances of the client are available in Outlook.

Change, Change, and More Change

Change is ongoing within Microsoft 365. Some changes are dependent on other changes, such as Copilot audit records capturing associated resources for the Stream player. Others are the delivery of incremental functionality within an application. The trick is to keep an eye on what’s happening and to recognize what kind of change each message center notification represents. That’s sometimes hard to do based on the way Microsoft describes a change. Oh well, into every life a little rain must fall…

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.

Teams Meeting Audit Events for Meeting and Participant Details

Last week’s news that Microsoft has started to make a set of premium audit events available to customers with Purview Audit (standard) licenses was welcome. The idea is that customers can use significant audit events like MailItemsAccessed and Send in forensic investigations of user activity that are often necessary when account compromise is suspected. Previously, Purview audit only generated these events for accounts with Purview Audit (Premium) licenses.

Teams Meetings Audit Events

Along with the Exchange events, Microsoft is making an additional fifteen Teams audit events available to Purview Audit standard customers. Among the set are audit events to capture details of meetings and meeting participants. The MeetingDetail event captures information such as the start and end time for a meeting, the URL to join the meeting, and the modalities used in a meeting such as audio and video. The MeetingParticipant event captures details of user participation in a meeting including their join and leave times and is like the information recorded in the attendance report.

I wrote about the Teams meeting audit events after their introduction in 2021 and explained how to generate a report from the audit records (I have since updated the script to use the Microsoft Graph PowerShell SDK to resolve user identifiers instead of the Azure AD module). The same script works today, and you can get it using the link in the original article.

In passing, MC772556 (updated 17 May 2024, Microsoft 365 roadmap item 381953) announces that Microsoft plans to shorten the URL created for Teams meetings to introduce a simplified syntax and make the links easier to share. Old URLs will continue to work after the introduction of the new version, now scheduled for August 2024.

A Delay in Audit Event Generation

In my 2021 article, I noted that Teams meeting audit events are generated some time after a meeting concludes. Workloads usually generate audit events soon after an action like a file modification or group creation completes. Teams meeting audit events appear in the audit log several hours after a meeting finishes. The same continues today. It’s possible that the delay occurs because a meeting can last past its scheduled time and can restart after an initial event concludes. The delay might exist to allow Teams to be sure that meetings are over before it generates the audit events.

Some Data Missing from Teams Meeting Audit Events

In addition, the meeting detail event doesn’t include some important properties about the scheduled event. For instance, the meeting subject isn’t captured (Figure 1), nor is the scheduled start and end times. Instead, the event records the actual start and end times of a meeting. Not capturing the meeting subject might be for privacy reasons.

Looking at the meeting participant detail events, we see the duration (in seconds) of the connection by individual participants to a meeting, details of the device used, and the meeting type (scheduled or ad hoc). But it seems like the audit events don’t capture details of guest users who join meetings when signed into teams in their host tenants.

On the other hand, Teams meeting audit events do capture the participation of people from other tenants who don’t have guest accounts in your tenant (federated participants). The upshot is that the participation information for some meetings is incomplete. It’s fine if you only ever want to report on the activity of internal users, but the big picture misses some important data.

Real Forensic Information

My conclusion is that if it’s necessary to report full details about Teams meetings, including attendance reports, you must use the Get OnlineMeeting Graph API. This is how the Teams clients fetch information about meetings.

Some complications exist. First, you need an Entra ID app registration to hold the application permissions necessary to read calendar events from user mailboxes and the meeting details. Second, unlike using other Graph application permissions to access data from all accounts in a tenant, Teams uses application access policies to protect online event information. An application access policy grants access to an app to online event information for specific accounts. Another complication is the formatting of the meeting identifiers used to access online events.

Once you have all the necessary access, reporting Teams meetings is a matter of finding online events in user calendars and retrieving the information for each event. I’ll write about how to create the definitive report about Teams online meetings when I finish up the script.

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.

Calendar Notifications Appear in Teams Activity Feed

Introduced by MC704955 (last updated 2 April 2024, Microsoft 365 roadmap item 314355), after several weeks, I have come to the conclusion that I hate the calendar notifications that now arrive in the Teams activity feed. According to the deployment schedule, almost all tenants should have the feature by now.

Calendar notifications arrive for

• Meeting invitations (including channel meetings where the organizer sends personal invitations).
• Meeting updates, including cancellations.
• Meeting forwards (that the user organized).

Calendar events pop up as unread notifications in the activity feed, cluttering the feed that’s already heavily trafficked by @mentions, replies, invocations to renew expiring teams, and the like. In fact, I get two sets of notifications because Outlook notifies me about new invitations and updates too. At least, Outlook would if I had not configured its calendar long ago to accept invitations automatically.

Suppressing Calendar Notifications in Teams

The good news is that you can suppress calendar notifications in Teams too. If you hover over the timestamp for a calendar notification (like 16:22 in Figure 1), an ellipsis menu appears. Select the “turn off calendar” option and the activity feed becomes a more pleasant place again.

This experience reminds me once again of the value of paying attention to the notification settings in the Teams client. As obvious from this 2021 post, it’s an ongoing battle because new sources of notifications (like the calendar) appear over time.

“Turn off calendar” disables most calendar notifications in the settings app (Figure 2). It doesn’t disable notifications for when people forward meetings that you organize. You can turn that setting off too if you like.

Reduced Filters in the Activity Feed

After sorting out calendar notifications, let’s turn our attention to message center notification MC793967 (17 May 2024), a candidate for the worst written message center post of the year. This feature, rolling out to general availability soon, removes much of the filtering capability for the activity feed. Microsoft explains that they’re doing this “To solve for discoverability and ease of usage of @Mentions in activity” (whatever that means) by introducing two “selectable pills” (normal people call these “buttons”) to filter for @mention and unread notifications (Figure 3).

The other filters previously available are retired. These include replies, reactions, apps, and voicemail, all of which seem pretty useful. No doubt Microsoft’s wonderous telemetry will prove otherwise.

To replace the retired filters, Microsoft says “we recommend the utilization of upfront mentions pill, which address the bullseye of filtering needs in Activity feed.” I have no idea what this mangled attempt at an English sentence means. Surely Copilot could have rewritten the text for clarity and conciseness? You could interpret the words to mean that Microsoft believes that @mentions are the most important notifications for users (probably true) with unread a close second. Hence the two filter options.

It’s also worth noting that a secondary filter option exists. Press CTRL+Shift+F (Windows) or click the funnel icon and you can input some words to filter the current list of notifications. For instance, if the selected filter is for unread notifications and you input “Paul” as a filter, the activity feed shows you unread notifications from users with Paul in their display name and notifications with Paul in their text.

Cleaning up Teams

All of this is part of Microsoft’s efforts to clean up what had become a cluttered Teams client. They want the Teams 2.1 client to be easy to use with the most important elements highlighted to users. I’ve no problem with that aspiration, but it would be good if communication was better.

Keep up to date with developments in Teams by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Make Sure that Mailbox Audit Configurations Capture Important Events

Following Microsoft’s announcement about the availability of the promised additional audit events for Purview Audit (standard) customers, some folks got in touch to ask if I had a script to report current mailbox audit configurations. As it happens, I didn’t, but cracking open Visual Studio Code and GitHub Copilot soon put that right.

How Not to Find Accounts with Purview Audit (Advanced) Licenses

My original plan was to find and report mailboxes owned by licensed user accounts. I wanted to know which accounts use Purview Audit standard and which use the advanced variant. This is more difficult than it seems because, as far as I can tell, there’s no Purview Audit standard service plan. At least, I can’t find one on the Microsoft page listing all the license and service plan identifiers.

There is a service plan called M365_ADVANCED_AUDITING (2f442157-a11c-46b9-ae5b-6e39ff4e5849), which seemed like a good candidate for Purview Audit (advanced). However, if you use the Get-MgUser cmdlet from the Microsoft Graph PowerShell SDK to find accounts with this service plan identifier in the assignedPlans property (see below), the service plan name returned for the identifier is “exchange.”

[guid]$PurviewAuditAdvancedPlanId = "f6de4823-28fa-440b-b886-4783fa86ddba"

[array]$Users = Get-MgUser -filter "assignedPlans/any(x:x/serviceplanid eq $PurviewAuditAdvancedPlanId)" -ConsistencyLevel eventual -CountVariable Test -Property Id, displayName, userprincipalName, assignedLicenses, assignedPlans

The service plan identifier appears in accounts that don’t have Office 365 E5 or Microsoft 365 E5 licenses, which are the products that include Purview Audit (advanced). This is because the service plan identifier has a disabled status in those accounts. To solve that problem, amend the filter to check for enabled service plans:

[array]$Users = Get-MgUser -filter "assignedPlans/any(x:x/serviceplanid eq $PurviewAuditAdvancedPlanId and capabilityStatus eq 'Enabled')" -ConsistencyLevel eventual -CountVariable Test -Property Id, displayName, userprincipalName, assignedLicenses, assignedPlans

But then I found that the resulting set of accounts only included those with Microsoft 365 E5 licenses. No trace existed of the Office 365 E5 accounts, even though Microsoft includes the Office 365 E5 license in the set with access to Purview Audit (advanced) in this useful comparison chart.

Microsoft documentation assures me that there is an app for Purview Audit (advanced). Usually, an app equates to a service plan. When I checked the Microsoft 365 admin center as directed, the app shows up under the moniker Microsoft 365 advanced auditing (Figure 1).

Disabling and enabling the app in the Microsoft 365 admin center disables and enables the 2f442157-a11c-46b9-ae5b-6e39ff4e5849 service plan behind the scenes. After all that, we know that a service plan called exchange controls an app called Microsoft 365 advanced auditing (aka the Microsoft Purview Audit (advanced) product) that only shows up in accounts with Microsoft 365 E5 licenses. It’s all very confusing, so I lost interest at this point.

Back to Scripting Mailbox Audit Configurations

After wasting too much time discovering the mess of service plans, product names, and SKUs, I went back to scripting and wrote some straightforward code to:

• Connect to Exchange Online.
• Run Get-ExoMailbox to find user and shared mailboxes.
• Define some critical audit events to check for in the owner and delegate audit sets.
• Check each mailbox to see if it uses the default audit configuration (maintained by Microsoft). Report the audit set defined in the configuration.
• Check that the critical audit events are present in the owner and delegate audit sets and flag any critical audit events (like MailItemsAccessed) found missing.
• Report what’s been found.
• If the ImportExcel PowerShell module is available, generate an Excel worksheet containing the results (Figure 2). If not, generate a CSV file.

You can download the full script from GitHub.

A Note About Enabling Audit with Set-Mailbox

The script checks if auditing is enabled for a mailbox, and if it is, the script runs Set-Mailbox to set AuditEnabled to true. Microsoft documentation says that if mailbox auditing is turned on by default for an organization, mailbox auditing ignores the AuditEnabled mailbox property.

But their May 20 announcement about the new audit events says that “Every standard user mailbox should have AuditEnabled set to true to ensure all audit records are uploaded to Purview Audit” and “Please note that this Set-Mailbox command must be run for every Standard license user regardless of its current value to correctly enable their mailbox to upload the new standard logs to Purview Audit.” Microsoft documentation is confusing on this point. I think the situation is that Microsoft manages mailbox auditing for accounts with Purview Audit advanced licenses while manual intervention is needed for mailboxes with Purview Audit standard, Whatever the reason, it’s always better to be safe than sorry when dealing with audit events, the script runs Set-Mailbox. You can certainly eliminate this section of the script to speed things up if you want to.

Feel free to improve and embellish the script to meet your needs. In the meantime, I need a headache tablet to recover from the trials of audit licensing.

Stay updated with developments like new events for mailbox audit configurations 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.

Teams Meeting Transcripts Exclusively Stored in OneDrive for Business

Microsoft is making a bunch of changes to the handling of Teams meeting transcripts. The most important change is the standardization on OneDrive for Business as the storage location for transcript information, described in message center notification MC726122 (last updated 1 May 2024, Microsoft 365 roadmap item 365720). Targeted release tenants will see the change in early June 2024 and Microsoft hopes to achieve worldwide general availability by late August 2024.

In 2021, Teams was the first application to move workload to the Stream on SharePoint platform. Stream was in the middle of a transition from the old Azure-based application to Stream on SharePoint, and customers still had the option to use either platform. During the transition, Stream stopped creating transcripts automatically for newly uploaded videos. Seeking stability and to support indexing of transcripts, Teams stored the transcript information in the meeting organizer’s Exchange Online mailbox.

Now, Stream on SharePoint is the only option for video storage and automatic transcript generation is performed, so meeting recordings end up with transcripts stored in Exchange Online and Stream. Microsoft is rationalizing the situation by eliminating the copy stored in Exchange Online. This step makes perfect sense because it is consistent with the way that Stream handles transcripts for other videos.

How Teams Meeting Transcripts are Generated

Microsoft is beginning by implementing the change for Teams meeting recordings that only have a transcript (no audio or video content is captured). This happens when a meeting organizer enables a transcript without recording. In the past, Teams wrote the transcript into Exchange Online. When the change is effective, Teams creates an MP4 file in the Recording folder of the meeting organizer’s OneDrive for Business account. To create the file, the normal bot that joins meetings to listen to the audio feed from participants to create the transcript, generates the transcript as normal and then removes the audio track, leaving the MP4 file with just the VTT-formatted captions that compose the transcript.

Figure 1 shows a OneDrive for Business account with two meeting recordings. The first contains only a transcript. The second is a regular recording. Note the “meeting transcript” suffix used for the first and “meeting recording” for the second.

Teams will still write a copy of the transcript for transcript-only recordings into Exchange Online. The situation is different for Teams meeting recordings with audio. The transcript for these recordings is stored in the MP4 file. A copy is also stored in Exchange Online. In other cases, Microsoft emphasizes that Teams will only use the transcript stored in OneDrive for Business.

Phase Out of Exchange Storage for Teams Meeting Transcripts

Eventually, Teams will cease writing a copy into Exchange Online so that the only transcript data is that stored in OneDrive for Business. Microsoft says, “At the same time, meeting transcripts will stop saving in Exchange Online altogether and all transcript storage will be standardized on OneDrive only.” I’m unsure what is meant by “at the same time.”

As you’d expect, standardization on a single location makes it easier to delete transcripts either by the meeting organizer or by retention policies (both the recording and transcript can be removed at the same time).

More Help Coming to Manage Consent and Access

Meeting transcripts are more important now than ever before. Apart from providing captions during playback of meeting recordings, the Teams Premium intelligent recap facility uses transcripts to generate meeting notes and action items. They’re also used by Copilot for Microsoft 365 to allow users to ask questions about meeting proceedings.

To protect the privacy of people and make sure that transcripts are only generated for meetings where everyone consents to recordings, Microsoft has several changes in the pipeline to better manage consent and access, including:

• MC781595: Policy to control the download of Teams meeting recordings. Requires SharePoint-Syntex advanced management licenses.
• MC791598: Consent given by users for recording is captured in the audit logs (requirement for consent must be enabled in the Teams meeting policy)
• MC794819: Explicit consent for all forms of recording.
• MC764456: Explicit consent to transcribe a meeting.
• MC795083: Policy to manage access to meeting transcripts, recordings, AI-generated recap, and Copilot features.

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

New Features Show up in Stream Browser Client

The migration period for Stream classic to Stream on SharePoint finished on April 15, 2024. Given that Stream no longer has a management client because everything’s handled by SharePoint Online and OneDrive for Business, it’s possible that Stream slipped down the list of tenant administrator priorities once the migration finished. Development continues on the Stream browser client (but Microsoft plans to retire the Stream mobile client on 1 July 2024), and three recent advances deserve some attention.

Copilot for Stream

Message center notification MC765809 (2 April 2024, Microsoft 365 roadmap item 188616) announces the arrival of Copilot for Stream. This only matters if a tenant has Copilot for Microsoft 365, but I think its arrival underscores the importance of transcripts.

Most people are familiar with Teams recording transcripts and know that the transcript is basis for Copilot party tricks like extracting a list of action items or summarizing what happens during a meeting. At one time, Microsoft stopped creating transcripts for videos uploaded to Stream, possibly because the transcripts complicated the migration process. However, this point passed and Microsoft resumed the generation of transcripts following the upload of video files in mid-2023. If a video doesn’t have a transcript, it’s easy to generate one.

Once a transcript is available, Copilot for Stream can use it to do much the same thing as it does for Teams meeting recordings:

• Summarize what happens during the video.
• Create a list of action items.
• Ask questions about who said what.
• Ask if specific topics are discussed in a video.

Figure 1 shows Copilot for Stream after generating a list of actions from a video (which happens to be a Teams meeting recording featuring the awesome talent of the Office 365 for IT Pros eBook author team).

Video Trimming

The old Stream client could trim content from the start and end of videos. However, this meant regenerating video files, and that took some time. Today, Stream uses a different approach. Instead of removing parts of a video from the start, end, or middle, Stream hides content based on time codes. For example, you can tell Stream to hide the first fifteen seconds of a Teams meeting recording to avoid viewers having to watch the Teams recording introduction screen. Trimming a video in this manner avoids the need to regenerate an edited video without the trimmed sections. When the time comes to play the video, Stream simply ignores the trimmed sections.

Hidden content is always available to video owners and others with full access. The trimmed sections are viewable if someone downloads and plays a copy of the video. In addition, trimming doesn’t affect the transcript and although Stream doesn’t display the parts of the transcript for trimmed section, the full text is available for eDiscovery and for Copilot to process. For these reasons, if you want a video where it is impossible for viewers to access removed content, use a tool like Clipchamp to regenerate a new version of the video after removing the parts you don’t want people to see. Stream should then produce a transcript for the new video that reflects the edited content.

Video Interactivity

The interactivity feature of the Stream player supports the addition of elements at specific time codes within a video. You can add:

1. Forms. Insert a link to a Microsoft form (created beforehand) for display to viewers starting at a timecode. A form can conduct a survey, poll viewers, or quiz the viewers about the content of the video.
2. Callouts. Add a text or hyperlink callout to display to viewers between two timecodes. This function can be used to highlight important points in a video with a couple of lines of text. The callout editor is rudimentary and supports the selection of a limited range of colors. You can insert multiple callouts in a video.

The ability to add forms to a video is covered in MC688632 (3 April 2024, Microsoft 365 roadmap 180796), while callouts are covered in MC688631 (last updated 4 April 2024, Microsoft 365 roadmap item 180795)

During my testing, I discovered that adding a callout to a video often caused Stream to become unresponsive to a point where I had to kill the page. Do not attempt to add a callout (or form) when playing a video! Make sure that it’s stopped, else a high chance of something going wrong happens. Maybe I’m just unfortunate or the problem was with the Edge browser. In any case, Figure 2 shows what a callout (with text and a hyperlink) added to a video looks like.

As noted above, Stream displays a callout for a defined period. This could be the complete video or just specific sections.

Keep an Eye on Stream

I confess it had been a while since I took a detailed look at the Stream client to acquaint myself with recent developments and new features. As is the norm within a Microsoft 365 tenant, other things had demanded attention and stole time, or maybe it was just that I now expect the Stream client to work without me having to think too much about what’s going on. In any case, the new features are welcome, even if you don’t have Copilot.

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.

Check Mailbox Audit Configurations to Make Sure that New Audit Events are Ingested into Audit Log

Last October, I wrote about Microsoft’s glacial progress in making important audit events used for forensic investigations available to customers with Purview Audit standard licenses. This followed a July 19 statement where Microsoft agreed to expose the audit events to audit log searches run by Purview Audit standard customers and to extend the retention period for audit events from 90 to 180 days. Nothing seems to move quickly in the world of auditing. Perhaps they need a Copilot to help?

The good news is that a May 20 post in the Microsoft technical community post says that the long-anticipated delivery of 19 new audit events are coming in public preview. Once the update reaches your tenant (looks like June 2024 according to the Microsoft 365 roadmap), you should see these events turn up for accounts with Purview Audit standard licenses in the results of audit log searches run through the Purview portal, the Search-UnifiedAuditLog cmdlet, or the AuditLogQuery Graph API.

Searching for the New Audit Events

Here’s an example of using the Search-UnifiedAuditLog cmdlet to search the audit log for some of the new events. Note that I use the SessionCommand parameter to make sure that all results are returned (necessary after an unannounced and unexplained change made by Microsoft last year). Sorting the results by identity removes duplicates:

[array]$Records = Search-UnifiedAuditLog -Operations MailItemsAccessed, Send, messageSent -StartDate (Get-Date).AddDays(-10) -EndDate (Get-Date).AddDays(-1) -ResultSize 5000 -Formatted -SessionCommand ReturnLargeSet
$Records = $Records | Sort-Object Identity -Unique

$Records | Group Operations -Noelement | select name, count

Name              Count
----              -----
MailItemsAccessed  1792
MessageSent          61
Send                 49

You could get the same results by running a high completeness search, but you’d wait much longer for the output (if the search doesn’t hit an internal server error as in Figure 1). In Microsoft’s defense, high completeness searches are a preview feature.

The Question of Exchange Mailbox Logging

What’s interesting from Microsoft’s announcement is that the Send and MailItemsAccessed events are added automatically to the set of events captured for mailboxes UNLESS you’ve updated the audit configuration for a mailbox. In other words, Microsoft doesn’t attempt to update custom mailbox audit configurations.

I guess I understand the logic. If administrators changed mailbox audit configurations, they presumably do so for good reason and Microsoft doesn’t want to mess with that configuration. On the other hand, an arguable case exists that these events are so important that they should be added to the audit configuration for all mailboxes.

Updating the Mailbox Audit Configuration for New Audit Events

Microsoft suggests two options: revert mailboxes to the default audit configuration or update mailbox audit configurations to add the new events. I suggest that the latter is the better option. Here’s some code I used to update mailboxes in my tenant. The script uses the Get-MgUser cmdlet from the Microsoft Graph PowerShell SDK to find accounts with Office 365 E3 licenses (including Purview Audit standard).

For each mailbox, the script:

• Checks to see if the default audit set for owner actions is present. If it is, we don’t need to update the audit configuration because Microsoft will add the new events to the default set.
• Checks the audit configuration for owner actions to see if the set includes MailItemsAccessed. If not, update the configuration for the owner and delegate sets.
• Checks the audit configuration for owner actions to see if the set includes the Send action. If not, update the owner set.
• Runs Set-Mailbox to enable the updated audit configuration. I have no idea why Microsoft insists that this needs to be done manually for Purview Audit standard. It isn’t required for mailboxes with Purview Audit (Premium) licenses.

Connect-MgGraph -NoWelcome -Scopes User.Read.All
Connect-ExchangeOnline
[array]$Users = Get-MgUser -filter "assignedLicenses/any(s:s/skuId eq 6fd2c87f-b296-42f0-b197-1e91e994b900)" -All | Sort-Object DisplayName
[int]$Updates = 0
ForEach ($User in $Users) {
    # See if the mailbox uses the default audit set
    Write-Host ("Checking mailbox audit configuration for {0}" -f $User.displayName)
    [array]$DefaultAuditSet = (Get-Mailbox -Identity $User.UserPrincipalName).DefaultAuditSet
    If ("Owner" -notin $DefaultAuditSet) {
        # There's a non-default owner audit configuration, so let's update the custom set
        [array]$AuditConfiguration = (Get-Mailbox -Identity $User.userPrincipalName).AuditOwner
        If ("MailItemsAccessed" -notIn $AuditConfiguration) {
            Write-Host ("Updating mailbox audit configuration for {0}" -f $User.displayName) -ForegroundColor Yellow
            Set-Mailbox -Identity $User.UserPrincipalName -AuditOwner @{Add="MailItemsAccessed"} -AuditDelegate @{Add="MailItemsAccessed"} -ErrorAction SilentlyContinue
            $Updates++
        }
        If ("Send" -notIn $AuditConfiguration) {
            Set-Mailbox -Identity $User.UserPrincipalName -AuditOwner @{Add="Send"} -ErrorAction SilentlyContinue
        }
        # Make sure that the new audit configuration is enabled
        Set-Mailbox -Identity $User.UserPrincipalName -AuditEnabled $true -WarningAction SilentlyContinue
    }
}
Write-Host ("All done. {0} of {1} mailboxes updated" -f $Updates, $Users.Count)

New Audit Events are A Step Forward

It’s good that Microsoft has finally deployed the new audit events. It’s not so good that tenant administrators need to intervene to ensure that mailbox audit configurations are correctly set up. Further details are available in Microsoft’s documentation.

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

Use Loop Workspaces to Organize Recurring Meeting Notes and Documents

Microsoft is keen to demonstrate the value of integration across the Microsoft 365 suite. They also take every opportunity to hype new products to drive usage and adoption. Both elements are present in message center notification MC792605 (13 May 2024), which tells us that organizers of recurring Teams meetings will be prompted to create a Loop workspace to hold the information used by the meeting. The prompt is in the meeting chat (Figure 1).

The idea is that the Loop workspace serves as a durable container for content worked on over a series of meetings. If the meeting organizer chooses to create the workspace, the meeting participants receive invitations to join the workspace and the organizer can add files shared in the meeting, As meetings in the series progress, Teams will automatically add files, whiteboards, loop components, and so on that are shared in the meeting chat to the workspace.

Deployment Timeline

Deployment to targeted release tenants is ongoing now. General availability is due soon thereafter. Initially, the feature is limited to recurring meetings with between three and 50 participants. Microsoft says that they will increase the limit for meeting participants in the future and add support for modern groups (Microsoft 365 groups). I’m not quite sure what that last statement means, unless it’s saying that Loop will support sharing with the membership of a Microsoft 365 group.

Loop Licensing Could be an Issue

On the surface, using a Loop workspace to manage the files shared by participants of a recurring meeting sounds like an excellent idea. However, there are two issues that need consideration.

First, Microsoft doesn’t restrict the creation of Loop workspaces through licensing today, but they will restrict creation to accounts holding Microsoft 365 licenses after July 1, 2024. Users who share Loop workspaces can still access workspace content after that date, but they cannot create new workspaces or add or remove users to workspaces. This limits the usefulness of the feature to meeting organizers with the required licenses.

The Loop workspaces report PowerShell script described in this article includes details of licenses assigned to workspace owners. You can use the report to figure out if some licensing adjustments are necessary. While you’re considering the licenses assigned to Loop workspace owners, consider reviewing the full set of licenses (and their costs) assigned to users across the tenant using the Microsoft 365 tenant licensing report script.

Waiting for Guest Support Through Loop External Access

The second issue is that many Teams meetings involve guest users. I participate in recurring meetings in three other Microsoft 365 tenants, but until Loop supports external access to workspaces, guest accounts cannot access the information stored in workspaces created to support recurring meetings. Microsoft has promised that external access for Loop is coming, but there’s no sign that the initial support announced in MC736437 (for tenants without sensitivity labels) due to arrive in April is available yet. Some recent tweets from Microsoft imply that external access is about to arrive, but we’ll have to wait for it.

Tenants that use sensitivity labels won’t get support for external access to Loop workspaces until later. The tenants I participate in as a guest all use sensitivity labels, so I guess that I’ll just have to wait a little longer before those meetings can embrace Loop instead of standard OneDrive file sharing.

A Good Idea for Some

You might think that I believe using a Loop workspace to hold information for recurring meetings is not a useful feature. That’s not true. It’s a good feature if you have the necessary licenses and don’t need to share anything with guests (until that feature is released). Sometimes I think Microsoft operates on the basis that everyone has high-end licenses and only ever collaborates within a tenant. That isn’t the way the real world works, and that’s why I am slightly negative about this feature.

On another note, this kind of integration between Microsoft 365 products is the kind of thing that regulators like the European Union worry about because they create a barrier for competition by preventing the ability to use features if a customer chooses to use a different technology (such as replacing Teams with Slack). Innovation can sometimes be a double-edged sword.

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.

Microsoft Retiring Legacy Exchange Authentication Methods from October 2024: Are Tenants Ready?

Outlook integrated add-ins are a popular mechanism to extend client functionality to allow access to external data sources. No one knows exactly how many add-ins have been created or how many are in active use within Microsoft 365 tenants, but what we do know is that some tenants will get an unpleasant shock in October 2024 when Microsoft turns off legacy Exchange user identity tokens and callback tokens for Exchange Online tenants. Microsoft says that these legacy methods “no longer provide sufficient support for organizations’ response to threats against email data.”

Both are authentication methods originating from on-premises environments. Microsoft wants to remove as many legacy authentication methods as it can from Microsoft 365. This is part of Microsoft’s Secure Future Initiative, launched by Brad Smith in November 2023. Since then Microsoft has experienced the Midnight Blizzard attack and upped the ante in terms of withdrawing legacy authentication whenever possible, like the withdrawal of Application Impersonation for Exchange Web Services (EWS) announced in March 2024.

The replacement is a technology called Nested App Authentication (NAA), announced in preview on April 9, 2024 (Microsoft also posted to the Technical Community, but it was easy to miss). According to Microsoft, “NAA provides simpler authentication and top tier identity protection through APIs designed specifically for add-ins in Office hosts.”

The Impact on Outlook Add-in Developers

Microsoft’s developer blog makes it seem simple to adopt NAA, listing five steps:

• Register an Entra ID application for use with the add-in. The application will hold consent for the Graph permissions needed by the add-in.
• Update redirect URIs to support trusted brokers.
• Update the add-in’s MSAL.js configuration to allow native bridging.
• Add a fall-back authentication method.
• Test the add-in.

However, the simplicity of Microsoft’s approach understates the work they expect developers of Outlook add-ins will do:

• Review their Outlook integrated add-ins to identify where legacy authentication is used.
• Switch from Exchange user identity tokens and callback tokens to use NAA. The big advantage delivered by NAA is that it’s integrated with Entra ID and supports its advanced set of authentication capabilities.
• Use Graph APIs to access Exchange Online data instead of EWS and the Outlook REST API. Microsoft has already announced that they will block access for EWS to Exchange Online from October 2026.
• Test with multiple versions of Outlook. Microsoft is due to support the classic Outlook client until 2029.
• Contact customers who use the older versions of the add-ins.
• Deliver production-quality code to customers.

Even with help from something like GitHub Copilot, there’s a significant amount of work here. NAA is only just in preview, so a limited amount of practical experience exists of its use with add-ins. Perhaps Microsoft will reveal more information at the Build Conference next week.

Equipped with knowledge or not, the work must be done before Microsoft turns off the legacy authentication methods at a so far indeterminate date sometime in October 2024. The change only affects Exchange Online. Outlook add-ins can continue to use the legacy authentication methods to connect to Exchange on-premises servers. Of course, this creates a further complication for developers who create add-ins used hybrid environments because their code must be able to handle connections to on-premises and cloud servers.

Reviewing Personal Use of Outlook Add-ins

I don’t use many Outlook add-ins myself, and those that I do are produced by Microsoft (Figure 1). I assume that Microsoft will take care of these add-ins in due course.

A quick scan around the internet reveals the presence of many Outlook add-ins created by third parties (here’s an example). I’m not quite as sanguine that all the third party add-ins will have quite the same smooth upgrade. If you’re a tenant administrator, it’s a good idea to ask people what add-ins they use and start to build a list of add-ins in active use.

A Better Future

Everyone wants better security, and we currently suffer from the effects of using technology developed for use in on-premises environments in the more challenging world of cloud systems. Over the long terms, there’s no doubt that technologies like NAA and the Graph are the right way to go will help close holes that attackers could potentially exploit.

The big problem is lack of time. October 2024 will come very quickly and if tenants don’t know that they need to update Outlook add-ins, they’re going to get a hell of a shock when Microsoft disables the legacy authentication methods and add-ins cannot connect to Exchange Online. I’m not sure that every developer reads Microsoft’s developer blog diligently, so it’s entirely possible that some add-ins won’t receive the attention they need before the big turn-off. Allied to the inability to audit the use of Outlook add-ins within a tenant and all the components of a big mess are coming together. I hope that I’m wrong.

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

Teams Anti-Competitive Behavior and the Slack Complaint

A recent report in the Financial Times (behind a firewall, so here’s a summary that can be accessed without payment) says that the European Union is preparing to introduce new anti-trust charges against Microsoft due to anti-competitive practices around the way it bundles and sells Teams.

The origin goes back to a 2020 complaint filed by Slack against Microsoft where Slack accused Microsoft of “illegal and anti-competitive practice of abusing its market dominance to extinguish competition in breach of European Union competition law. Microsoft has illegally tied its Teams product into its market-dominant Office productivity suite, force installing it for millions, blocking its removal, and hiding the true cost to enterprise customers.”

European antitrust proceedings take their own time to develop. Eventually, in July 2023, the European Union decided to open an antitrust investigation based on the Slack complaint. Microsoft responded by unbundling Teams from Office 365 for new customer purchases within the European Economic Area (EEA). On April 1, 2024, Microsoft announced the unbundling of Teams from Office 365 worldwide. Like the EEA move, the decision only affects new customers, who must buy separate Teams Enterprise licenses ($5.25/month in the U.S.) if they wish to use Teams.

Microsoft’s move to unbundle Teams doesn’t appear to have assuaged the European Union. There’s an obvious reason why. According to Microsoft, Teams has 320 million monthly active users. Microsoft cited the number in their FY24 Q1 results in October 2023 and hasn’t updated it since (Jeff Teper repeated the figure at the recent Microsoft 365 conference). I imagine that even if growth is slowing, some increase has happened in the two quarters since.

The Competition Between Slack and Teams

When Slack filed its complaint, it competed fiercely with Teams. Then the Covid pandemic came along, and Microsoft poured resources into teleconferencing (in particular) to help people cope with working from home. The result was a massive growth in Teams usage, leaving Slack in its dust as Microsoft focused more on Zoom than its original competitor. Based on official Microsoft numbers, Teams is used by 80% of the 400 million Office 365 paid seats, so there’s not much room for a competitor to take share. According to DemandSage.com, Slack has 65 million monthly active users, or around 20% of the Teams number.

Unbundling Teams from Office 365 won’t create a more level playing field, especially in the lucrative market for enterprise customers. These organizations value the integration of Teams with other Office 365 workloads like SharePoint Online, OneDrive for Business, Exchange Online, and Planner. Many will consider using Teams with Copilot for Microsoft 365 or Teams Premium to gain advantage of the additional functionality enabled by those licenses.

It’s hard to see how Slack could create a cogent argument for a customer to use its technology instead of Teams alongside the rest of Office 365, especially as the monthly cost for Slack is higher than the Teams Enterprise License. The monthly cost of the Slack Business plan is almost equivalent to Teams Enterprise plus Teams Premium (Figure 1).

Given the choice between buying the market leader that’s integrated with the rest of Office 365 versus bringing in a third-party product that’s not integrated, what decision do you think a rational CIO will make?

No Ability to Move Away from Teams

Another problem is that the task of moving an organization from Teams to move to Slack or another platform is horrendously complicated. I’ve long said that Teams is the most difficult of any Office 365 workload to backup. It’s even harder to restore, and that task has not become easier over the years. Extracting chats and channel conversations might be possible, but then things become difficult with shared files stored in user OneDrive accounts like Loop components, Teams meeting recordings, compliance records, call logs, and so on.

There’s also the small matter of the thousands of apps developers have built for Teams and the data used by those apps. People who have done a tenant-to-tenant migration involving Teams know about the difficulties involved in migrating to the same platform. Moving to a different platform sets a whole new benchmark for problems when a workload that’s heavily integrated with a platform is involved.

Seeking a Remedy for Teams Anti-Competitive Behavior

According to the Financial Times, European Union officials are concerned that unbundling is insufficient to enable fair competition. I’m no expert in European anti-trust law, but if no technical remedy exists because the European Union discounts the unbundling of Teams, then the likely outcome (if charges are proven) appears to be a fine. The European Union can levy fines of up to 10% of a company’s worldwide revenues, so there’s lots of latitude to impose a very big fine.

One thing’s for sure. Microsoft and the European Union will go through a long, complicated, and difficult negotiation to establish if they can construct a remedy that satisfies all parties. It will be interesting to see how this situation evolves.

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.

Azure MFA Required for Connections from July 2024

Updated

Microsoft’s May 14 announcement that they will require multifactor authentication (MFA) for access to Azure services certainly kicked up a heap of questions. The sad fact is that Microsoft has a good message to communicate around increasing the security of connections to the Azure portal (and assumedly for Azure PowerShell sessions) but failed miserably to communicate that message.

After reading the announcement, my take is that Microsoft will deploy the requirement for MFA for connections to Azure services from July 2024 onward. Microsoft says that they will communicate with tenant administrators with details about what they plan to do and when they will do it, and that the deployment will be “gradual and methodical to minimize impact on your use cases.”

The Reasons to Use Multifactor Authentication

Excellent reasons exist to use MFA to protect connections. Anyone who uses basic authentication (username and password) for administrator accounts (or any user account) is playing with fire because their account is a prime target for compromise. Microsoft cites two different numbers (99.2% and 99.9%) for the ability of MFA to block attacks like password sprays (I’ve seen both figures cited elsewhere), but this slip of the pen doesn’t matter.

What does matter is that MFA offers better protection for account compromise, especially if you use strong authentication methods like the Microsoft Authenticator app, including the recently-added support for passkeys.

Another important point is that the Entra ID community is not doing a great job of deploying and using MFA. According to Microsoft VP for Identity Security Alex Weinert, MFA protected 38% of Entra ID accounts in February 2024. Perhaps the recent announcement of support for external authentication methods will help drive the percentage higher because organizations can leverage investments in MFA solutions that don’t come from Microsoft.

Communication Issues Around Azure MFA

Good as MFA undoubtedly is, Microsoft just didn’t get their point across.

First, Microsoft didn’t clarify which users will need to use MFA. Including the phrase “for all Azure users” in the announcement title made a major contribution to the confusion. My understanding is that MFA will be required to connect to the Azure portal, so that limits the set of affected users to people who sign into the Azure portal to work with subscriptions, resource groups, automation accounts, billing, and so on. In short, not your average Microsoft 365 user (who probably don’t know or want to know about the Azure portal).

Update: Microsoft posted a comment to the article saying that MFA applies to, “All users signing into Azure portal, CLI, PowerShell, or Terraform to administer Azure resources are within the scope of this enforcement.”

Second, Microsoft didn’t say how they will enforce MFA. The text points to the MFA setup wizard in the Microsoft 365 admin center (Figure 1), which focuses heavily on enforcing MFA through conditional access policies.

Conditional access policies work very well, but they require Entra ID P1 licenses. This is probably not an issue in enterprise tenants where Entra ID premium licenses cover many different features, but it could be a problem for small businesses. It’s the same issue around imposing extra cost that occurs in Microsoft’s campaign to move Office 365 per-user MFA to conditional access policies.

Perhaps Microsoft plans to use a mechanism like the way Security Defaults requires accounts with administrator roles to use MFA with the Authenticator app. In other words, no conditional access policies and no need for premium licenses. Of course, if organizations want to use conditional access policies to enforce MFA for inbound connections they can do so and fulfil the requirements of Azure. Microsoft says that no-opt is available except through an exception process that isn’t yet defined.

A long time ago when I started to write magazine articles, an editor told me not to assume that the reader understood the topic I wrote about and to answer questions in the text that I assumed people already knew the answers to. That good advice has stood the test of time. I often feel that Microsoft communicates in a way where they assume the target readership understands the full context of the topic being discussed. It would be nice if they wrote text that is a lot more specific and complete.

Rushing to Embrace Security

Microsoft’s Security Future initiative is a worthy venture, but it seems like Microsoft engineering groups are rushing to implement blocks to meet their schedule rather than understanding that announcing what could be a major change in mid-May for implementation in July (initially for the Azure portal) is not appreciated by customers. It’s not as if tenant administrators only need to concentrate on securing Azure better. Every engineering group in the Microsoft 365 ecosystem is tightening security and the cumulative workload created for tenant administrators is something that I don’t think individual program managers contemplate.

The net is that no one can argue against better security connections to Azure services if implemented in a measured and well-communicated manner. It seems like Microsoft’s May 14 announcement was a tad rushed and that’s a real pity.

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.

Slash Commands Designed to Speed Access to Common Functions

For many years, Teams clients have supported shorthand commands invoked with the slash (/) key in the command box at the top of the screen. The idea behind these commands is to speed access to essential features. Originally, the set of commands focused on setting the online status for a user. Over time, Microsoft added more commands to the set, including fast access to apps like GitHub.

Now, announced in message center notification MC785024 (24 April 2024, Microsoft 365 Roadmap 120469), Teams supports slash commands in the compose message box for both chats and channel conversations. The feature is supported in the desktop, browser, and mobile clients and is scheduled for release in mid-May. General availability is expected to complete deployment to all tenants by the end of June 2024.

Available Slash Commands

As the name implies, slash commands are invoked by entering a forward slash in the message compose box. This action causes Teams to list the available commands, which are different to the set available in the command box (the same commands to set a user’s status are available):

• Apps: Add an app.
• Available: Set your online status to Available.
• Away: Set your online status to Away.
• Brb: Set your online status to Be right Back.
• Busy: Set your online status to Busy.
• Code: Insert a code block.
• Dnd: Set your online status to Do not Disturb.
• Loop: Add a Loop paragraph component.
• Offline: Set your online status to Offline.
• Settings: Open the settings app.
• Shortcuts: Open a screen to show details of available keyboard shortcuts.

The slash command only works if it is the first element in a message. For instance, Figure 1 shows the slash commands revealed when composing a channel message. The command works because nothing precedes it in the message. If you insert a forward slash after the text, it has no effect, and you won’t see the commands.

Despite what’s stated in MC785024, there’s no way to mute a conversation using a slash command. Also, while the list of commands mentions inserting a Loop paragraph, the other components supported by Teams are available and can be selected after inserting the paragraph component (Figure 2). Only a single Loop component can be inserted into a message.

A code block can be inserted into a message along with a Loop component. This is the Teams code block which is a static component. If you want to share code, you’re better off inserting Loop and choosing its code component because people can then adjust the code as necessary.

No Administrative Control

There’s no administrative control available to enable or disable slash commands. They are part of the base Teams client user interface. Of course, if you don’t want people to use slash commands, don’t tell them that the facility exists. It’s unlikely that someone will find that slash commands exist through a process of inserting random characters in messages. Or maybe that’s not true.

Will People Use Slash Commands?

Nice as it is to have slash shortcut commands, I doubt this will make much difference to the average user. If people want to set their online status, they’ll probably continue to do this using the command box. There are options to insert a code block or Loop component into a message, and I don’t think that many add an app to a message. I’ve been known to be wrong before, and clearly Microsoft believes that the demand exists for this feature. Maybe the demand comes from internal Microsoft users. Who can say?

Folder Deletion with Items in Place Makes it Easier to Clean Out Old Material

In the past, SharePoint Online used to block deletion of files with retention labels. In late 2021, Microsoft decided to make the deletion behavior consistent across SharePoint Online and OneDrive for Business by allowing deletions to occur. Files with retention labels went into the site recycle bin and progressed into the preservation hold library until their retention period expired. After that point, a timer job finds and removes the expired files.

Another welcome change to SharePoint deletion behavior is now rolling out (MC791878, 11 May 2024, Microsoft 365 roadmap item 394689) and should be fully deployed worldwide around this time. The change allows users to delete folders in document libraries that aren’t empty in sites covered by a Purview retention policy.

Removing Old Material with Folder Deletion

This doesn’t sound important, but being able to delete folders without having first to open the folder and remove all the files stored there is the way things should have worked all along. A case can be argued that allowing people to delete folders without checking what’s stored in the folder could lead to inadvertent removal of information.

However, the case is undermined by the fact that the deleted folder (and its items) goes into the recycle bin from where it can be recovered. Even if the deleted folder passes through the normal SharePoint Online recycle bin cycle, administrators can still rescue the files from the site preservation hold library. When a deleted file is restored from the recycle bin, SharePoint Online recreates the folder in the original location if necessary.

The only problem I met testing deletions is when attempting to delete an empty folder and a non-empty folder together. For some bizarre reason, SharePoint Online used the old behavior and refused to remove the non-empty folder (Figure 1). SharePoint Online was quite happy to remove the same folder if processed individually.

Very importantly, after deleting a non-empty folder, OneDrive for Business will not attempt to synchronize the deleted folder back from its offline copy.

Checking Retention Status for SharePoint Sites

If a tenant uses multiple retention policies, it can be challenging to determine which policy governs an individual site or mailbox. To help, the Data lifecycle management section of the Purview compliance portal includes a policy lookup option. At first glance, the list of retention policies shown in Figure 2 seems overwhelming, but several different types of policy are present, including some to publish retention labels to the site and auto-label policies that use trainable classifiers to label files with certain characteristics.

Because multiple policies can have a specific site within their scope, it’s important to note the purpose of each policy in the description.

Why is it Important to have easier Folder Deletion?

Some people never delete any material from SharePoint Online. At least, they don’t until they’re forced to because the tenant storage quota is nearly exceeded, and they want to avoid purchasing some expensive additional storage. The problem here is that deleting non-empty folders in sites governed by retention policies won’t help with a storage quota issue because files retained in the preservation hold library count against the quota. In some cases, the preservation hold library can occupy 40% or more of the storage used by a site.

It’s wise to keep an eye on the storage consumed by sites and then investigate the sites where storage consumption seems excessive. I use a Graph-based PowerShell script to generate a report of individual files in a document library to help understand where storage is eaten up. Obviously, after identifying unwanted files and folders, being able to remove those files more easily is a good thing.

Another reason why it’s good to clean up document libraries is that it stops Artificial Intelligence tools like Copilot for Microsoft 365 using old, obsolete, and potentially inaccurate information. Removing digital debris is something I think we’re all going to become more serious about as the AI era unfolds.

Keep up to date with developments like the AI era for Microsoft 365 by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Follow Response Advances the State of the Calendar Art

It’s genuinely difficult to find innovation in calendaring. After so many years of so many people working on developing features to make user and shared calendars as productive as possible, it’s seldom that a new capability appears that makes people sit up and take notice. I think that the Follow option (MC786325, 26 April 2024, Microsoft 365 roadmap item 154557) is in that category, especially for those with heavily-scheduled calendars. The option rolled out to targeted release tenants in late April 2024. General availability is expected to start in mid-June 2024 and complete by the end of July 2024.

The Follow option is available when responding to meeting requests in OWA, the Monarch client, and Teams. The option is not currently available in Outlook classic (Windows or Mac) or Outlook mobile. If meeting organizers use Outlook classic, they see Follow responses as tentative. This problem will disappear after Microsoft upgrades Outlook classic to support Follow responses, as I hope they do soon.

Essentially, instead of accepting or declining a meeting, a meeting participant can indicate that they are interested in the meeting content and want to stay informed, even if they can’t attend in person or online.

Meeting Artefacts Core Underpinning for Follow Responses

Follow is a feature made possible by the preservation of meeting artefacts such as chat, transcribe, meeting recap, and shared files. It’s great that these elements capture what happened during a meeting and are available afterward for review, but until now the items have only been available to meeting participants. If you decline a meeting, you become a non-participant and have zero access.

You can’t respond to every calendar meeting request with Follow. It wouldn’t make sense to Follow a one-to-one meeting because you’re telling the other person that they can go ahead with the meeting but you’re not going to be there. In short, a meeting’s got to have enough participants to happen even if you’re absent.

Two big things happen if you respond to a meeting request with Follow (Figure 1). First, the meeting remains on your calendar. However, your availability is unaffected because a followed meeting does not block out time, meaning that it’s possible to accept another (more important) meeting. Second, you retain access to meeting artefacts.

Meeting Organizers Responsibilities

Obviously, if a meeting organizer receives some Follow responses (Figure 2), it’s a big hint for them to make sure that the meeting is recorded and transcribed. The text shown in the meeting response is part of the meeting body, so it appears in all versions of Outlook, even when a meeting organizer uses Outlook classic and sees a Follow response as tentative.

To remind the organizer what they should do to facilitate those following the meeting, Teams prompts the meeting organizer when they join the meeting to take action to record the proceedings (Figure 3).

I often use Copilot for Microsoft 365 to generate a summary of the key points and action items that I then edit to add emphasis (and correct some of Copilot’s little flaws) before circulating the information via email. Sure, this isn’t the same as making the data available through Teams, but some appreciate getting the quick summary via email.

A Real Improvement

Adding an onsite status for a meeting is another example of where Microsoft is developing the calendar app. It’s a worthy change, but it’s not of the same import as the Follow response. This feature is something to bring to the attention of people who make heavy use of their calendars.

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.

The Device Code Authentication Flow

In late February 2024, Microsoft introduced a preview setting for Entra ID conditional access policies to block authentication flows. Although the setting covers the device code and authentication transfer flows, my feeling is that Microsoft has the device code flow squarely in their sights, saying: “Device code flow is a high-risk authentication flow that might be used as part of a phishing attack or to access corporate resources on unmanaged devices.”

The device code authentication flow is defined in RFC8628. It exists in Entra ID to support devices that don’t have the ability to sign into Entra ID in a more orthodox manner, like a TV set. The mechanism works by allowing an app running on the device to post a request to the Entra login endpoint. The request includes the app identifier and the resource that the app wishes to access. The response is a direction to open a verification URL (normally https://microsoft.com/devicelogin) and input a 9-character code included in the response. If someone goes ahead and opens the page in a browser and inputs the code, the authentication request is successful and Entra ID issues an access token. The app polls for a successful outcome and proceeds if an access token becomes available.

The problem here is that attackers can exploit the flow by:

• Starting an app and requesting authentication.
• Asking the victim to open a browser and input the code. Obviously, some social engineering is in play here and the attacker probably prepared the victim to be ready to action a request.
• If the victim complies, the app is signed into the victim’s account and can use the permissions held by that account.

Detecting Device Code Authentication

It’s entirely possible that your tenant has never used device code authentication. A quick check is possible by checking the Entra ID sign-in logs as follows:

[array]$SignIns = Get-MgBetaAuditLogSignin -Filter "AuthenticationProtocol eq 'devicecode'"

$SignIns | Format-Table CreatedDateTime, ResourceDisplayName, UserDisplayName

CreatedDateTime     ResourceDisplayName UserDisplayName
---------------     ------------------- ---------------
01/05/2024 20:18:34 Microsoft Graph     Lotte Vetler
01/05/2024 20:15:51 Microsoft Graph     James Abrahams
27/04/2024 22:52:57 Microsoft Graph     Jane Sixsmith

The Entra ID sign-in logs are available for 30 days, so the data only covers that period. Nevertheless, it might be helpful in finding who uses the device code authentication flow and what resources they connect to.

Blocking the Device Code Authentication Flow

Returning to the original theme, support in conditional access policies for blocking selected authentication flows means that it’s easy to block device code authentications with a conditional access policy (follow the Microsoft instructions documented here).

Here’s an example of the policy in action. I attempt to start an interactive Microsoft Graph PowerShell SDK session by running the Connect-MgGraph cmdlet with the DeviceCode parameter. Entra ID responds with the instruction to open the browser and enter a code. But the authentication flow cannot complete because the block imposed by the conditional access policy and the attempt times out:

Connect-MgGraph -NoWelcome -DeviceCode
To sign in, use a web browser to open the page https://microsoft.com/devicelogin and enter the code FYK8NA4XS to authenticate.
Connect-MgGraph: Authentication timed out after 120 seconds due to inactivity. Please try again.

The browser interaction works, and the user is then prompted to sign-in to the requesting app. At this point, Entra ID checks the connection and the policy restrictions kick in. The user sees an error like that shown in Figure 1.

In passing, remember to consider securing interactive Microsoft Graph PowerShell SDK sessions to known users. Not everyone needs to run interactive PowerShell sessions to execute Graph requests.

Tightening Control over Inbound Connections

Microsoft continues to add new features to conditional access policies to examine different aspects of inbound connections. I can’t imagine that it will be long before blocking authentication flows becomes a generally available feature, but that’s no reason not to use the feature now to tighten security a tad. And remember, when you create a new conditional access policy, always add an exclusion for a breakglass account.

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.

Team Channel Collaboration Might be the Most Important Method in the Future

Among the blur of new features appearing in Teams and the transition to the new Teams 2.1 client is a small but important change in focus to the creation process for new teams and channels. The change to how people create teams is described in MC697434 (last updated on 19 January 2024, Microsoft 365 roadmap item 163364) and is now available everywhere.

Essentially, the change simplifies the flow of team creation by removing complexities such as creating teams from existing Microsoft 365 groups or templates to a separate screen that is only called when necessary. Everything is trimmed back to the basics of giving a name to a new team, describing its purpose, and setting its access type (private or public), with or without reference to a container management sensitivity label.

If you’re interested in managing the discoverability of private teams, container management labels are the way to go as label settings can control how users see private teams in the Join team experience.

All the other options that enrich but complicate the team creation process are now in a separate screen (Figure 1). Organizations that have invested heavily in developing team templates might dislike the change, but the advantage of simplifying of one of the most important processes in Teams cannot be denied.

Team Channel Collaboration Might be the Better Option

The initial screen shown to users who go to create a team includes the option to create a channel instead (Figure 2). The two options are presented alongside quite deliberately. In many instances, people create teams where they could create a channel. By showing the option to create a channel alongside a team, the hope is that those intending to create a team might stop and choose a channel instead.

A single team can now support up to 1,000 channels (including deleted channels). The channels can be any mixture of regular, shared, and private channels with the sole restriction being that there can be a maximum of 30 private channels in a team.

With so many channels available, there’s plenty of room for a new channel to host conversations about a topic. If extra privacy is needed, a private channel can support up to 250 members (all of whom must be team members). If the need is to share information more generally, a shared channel can handle the job within and outside the tenant. Once the topic is resolved or comes to a natural conclusion, the recently-introduced channel archive feature is available to preserve its contents.

The expansion to 1,000 channels was a significant signpost to the future. Creating too many teams is a recipe for wasteful consumption of resources, the accumulation of digital debris in disused teams and SharePoint sites, and the danger that users will lose sight of value in a mass of teams (not all of which are well named or well managed).

Some Hints for the Future

At the Microsoft 365 Community Conference in Orlando, Microsoft speakers gave some hints that channels receive a lot of current focus in their thinking about how to bring collaboration forward. All types of channels are owned by a team at present, but in the future, it might be possible to have a standalone channel that isn’t limited to the membership of a Microsoft 365 group and the resources available to that group.

Making such a change would challenge the way we think about Teams, especially the one-to-one association that currently exists between a team and a Microsoft 365 group. Challenges still exist in the current model, notably in areas like app support for shared channels where Planner is a much desired but still unavailable app. A new type of channel might be needed to break the mould. We’ll see in time.

Reduce the Number of Teams Created in Microsoft 365 Tenants

In the interim, it seems wise to avoid creating new teams unless they are absolutely necessary. Coach users to understand that they don’t need the full-fledged structured resources that come along with a team for what is often an expanded form of group chat. Instead, whenever possible, use channels in existing teams. Given what we know from the past, better use of channels will probably reduce the digital rot within tenants, and given the hints for the future, might prepare everyone for where Microsoft just might have earmarked as the way to develop the next generation of Teams.

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.

Make Your Tenant More Manageable by Tightening User Role Permissions

The ability of non-privileged user accounts to perform certain administrative tasks in an Entra ID tenant (Microsoft 365 tenant) is controlled by the user role permissions policy. This policy exists in every Entra ID tenant, and it comes with some default settings that are just plain silly for all but test tenants.

The settings I’m concerned about are found in the User settings page (Figure 1).

Apps, Tenants, and Security Groups

Three settings are up for debate. Should users be able to create registered apps, tenants, and security groups.

Only administrators should add registered apps to a tenant. Registered apps are enormously useful, especially the creation of an integrated Entra ID identity configuration that can authenticate against the Graph and other APIs. Attackers love apps too, and they like creating apps within compromised tenants and then assigning those apps the necessary permissions to exfiltrate data. The potential for app abuse is too high to allow “normal” users to create new apps might have made sense when attackers weren’t quite so interested in their use as an attack vector. The current threat horizon is such that it’s unwise to allow non-administrators to create new apps.

The same is true for tenants. What regular Microsoft 365 user sets out to create a new Entra ID tenant as part of their daily activities? The answer is none. Creating new tenants might be something that’s useful as part of a development project, but tenants created from the Entra admin center have no licenses and aren’t particularly useful. Developers are better off working against a Microsoft 365 development tenant. They’ll get 25 licenses to work with and the tenant will automatically renew if they work with Graph APIs. If someone can make a good case to create a new tenant, let them make it to a tenant administrator.

I’m less strict about restricting users from creating security groups. However, because security groups are used to control access to resources, it seems to make sense to restrict their creation too. And most Microsoft 365 tenants suffer from a surplus of groups caused by unrestricted creation of Teams. Why add to the debris accumulating in a tenant?

I suspect that Microsoft chose the default settings with the best intentions at a time when threat was less evident. It’s regrettable that the settings remain so permissive. My position is therefore that tenants should update the default settings and impose control over creation of apps, tenants, and security groups. Feel free to disagree.

Using PowerShell to Update User Role Permissions

It’s easy to correct the settings in the Entra admin center. To make sure that the settings are not changed, you could use an Azure Automation scheduled runbook to update the settings periodically. Changes to the authorization policy require consent for the Policy.ReadWrite.Authorization permission. Here’s the necessary Microsoft Graph PowerShell SDK code to disable the ability for users to:

• Create new Entra ID registered apps (AllowedToCreateApps)
• Create security groups (AllowedToCreateSecurityGroups)
• Create new tenants (AllowedToCreateTenants)

Connect-MgGraph –NoWelcome -Scopes Policy.ReadWrite.Authorization
# Create hash table for body
$BodyParameters = @{}
# Create hash table to hold role permissions for tenant users
$RolePermissions = @{}
$RolePermissions.Add("AllowedToCreateTenants", $false)
$RolePermissions.Add("AllowedToCreateApps", $false)
$RolePermissions.Add("AllowedToCreateSecurityGroups", $false)
# Add the role permissions to the body
$BodyParameters.Add("DefaultUserRolePermissions", $RolePermissions)
# Update default authorization policy
Update-MgPolicyAuthorizationPolicy -BodyParameter $BodyParameters 
# Check the results
Get-MgPolicyAuthorizationPolicy | Select-Object -ExpandProperty DefaultUserRolePermissions | Format-List Allowed*

AllowedToCreateApps                      : False
AllowedToCreateSecurityGroups            : False
AllowedToCreateTenants                   : False
AllowedToReadBitlockerKeysForOwnedDevice : True
AllowedToReadOtherUsers                  : True

For a detailed description of the user role permissions, see this page. Note the admonition not to change the allowedToReadOtherUsers to false. Doing so will have “unfortunate effects.”

Take Control Over Your Tenant

The temptation exists not to change default settings in an administrative portal unless the obvious need exists. That’s a reasonable position to take, but the simple fact is that the three default settings discussed here are outdated and illogical. Take control of your tenant and make sure to disable these capabilities. There’s no point in allowing people create objects unless there’s good reason to do so.

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.

Advancing MFA with Entra ID Authentication Backed by Nine ISVs

Earlier this year, Microsoft reported that the percentage of Entra ID accounts using multifactor authentication had reached 38%. That figure isn’t very impressive, but at least it represents a twelve-point increase since 2022. I guess some haven’t yet read the memo explaining that multifactor authentication is still the best way to avoid account compromise (something Microsoft discovered for themselves with the Midnight Blizzard affair).

To be fair to Microsoft, they continue to push the boundaries to make multifactor authentication easier and more secure to use, notably in the recent announcement of preview support for device-bound passkeys in the Authenticator app. However, I’m not sure that phishing-resident passkeys will be the thing that forces the decision in many companies. Just getting people to use normal challenge-response with the Authenticator app would be a great step forward.

Leveraging Third-Party Authentication Solutions

Which brings me to the May 2 announcement about Entra ID’s support for external authentication methods. This public preview demonstrates how to integrate and use third-party multifactor authentication solutions with Entra ID by defining the solutions as valid authentication methods, just like the out-of-the-box methods like SMS (which shouldn’t be used now) and the Authenticator app (Figure 1). The preview is due for availability in mid-May. This initiative replaces the previous custom control solution, which never left preview.

Entra ID is quite capable of handling multifactor authentication and many Microsoft 365 tenants have bought fully into the Entra ID stack and have no need for third-party enhancements. But equally so, it’s common to find that large organizations select a multifactor authentication solution for use across multiple platforms, multiple applications, and multiple clients. In these scenarios, it makes sense for Entra ID to be able to hand off a connection to a third-party solution to perform the multifactor challenge and response before returning a response for Entra ID to verify and accept.

Microsoft points out that the integration between Entra ID and the third-party authenticators uses industry standards and are managed in the same way as native Entra ID authentication methods. Entra ID handles multifactor authentication through conditional access policies, which dictate when connections must satisfy multifactor authentication. Conditional access policies can insist on a certain strength of authentication (like phishing-proof), but it’s usually sufficient for a connection to satisfy an authentication method to proceed.

Because Entra ID and third-party authentication methods indicate if a connection satisfies a multifactor challenge, it means that Entra solutions like Privileged Identity Management (PIM) respond to authentication in the same way. The result is that companies can leverage their investment in third-party authentication solutions alongside Entra ID, which is the best of both worlds.

Nine ISVs to Support Entra ID Authentication

Microsoft’s announcement details support for nine third-party authentication solutions including:

• Cisco Duo
• Entrust Identity
• HYPR Authenticate
• Ping Identity
• RSA
• Silverfort advanced MFA
• Symantec VIP
• Thales STA
• TrustBuilder MFA

It’s a good lineup and more solutions are likely to be added. Microsoft documentation is available for ISVs to know how to connect their solutions to Entra ID by defining an authentication method.

Increasing the MFA Percentage

I’m looking forward to seeing how many Microsoft 365 tenants integrate third-party authentication solutions with Entra ID. The logic behind leveraging what’s already deployed is inescapable. All that’s needed now is implementation, where it makes sense (of course).

One more comment. Adding authentication methods to Entra ID expands the capability to handle inbound connections more thoroughly. It does nothing to manage the number of accounts configured with authentication methods, the conditional policies to enforce multifactor authentication, or the reporting of who uses multifactor authentication. In other words, a shiny new authentication method is nice, but it does nothing to drive that MFA percentage higher. That takes more effort, persistence, and (often) executive buy in.

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

Teams Video Messages Can Use Blurring or Images as a Background Effect for Clips Recorded on iOS client

Teams introduced the ability to send one-minute-long video messages in chat in September 2022. The process uses Stream components to record the clip (and trim to the required length) before posting. Everything works, but the increasing use of mobile devices means that people want to be able to communicate on the go using any device, which brings us to message center notification MC718553 (last updated 27 March 2024, Microsoft 365 roadmap item 380852).

MC718553 announces the ability to record video clips on Apple iOS devices with limited background effects. Unlike Teams background effects used by the desktop and browser clients, the iOS client uses images stored in the device’s photo library. Before they record a video clip, users can choose to paint their background with an image or two types (light and heavy) blur. The one-minute limit for clip length remains in force.

Microsoft expects to complete roll-out of the new feature by May 2024 to commercial, GCC, GCC High, and DoD tenants.

Requirements for Teams Video Messages

I’m no video expert and I seldom use videos in chat. It seems easier to write down what I need to say and move on. However, I recognize that the world is changing, and many find it easier and more productive to express themselves in a quick video. The world’s big enough to accommodate all sorts, which brings us back to how to make a video clip.

You can only send a video message if the AllowVideoMessages setting in the Teams messaging policy governing your account is true. If not, you’re limited to sending photos from mobile devices. Administrators can check in the Teams Admin Center (Figure 1) or by running the Get-CsTeamsMessagingPolicy cmdlet:

Get-CsTeamsMessagingPolicy | Format-Table identity, allowvideomessages

Identity       AllowVideoMessages
--------       ------------------
Global                       True
Tag:Default                  True
Tag:EduFaculty               True
Tag:EduStudent               True

You can post Teams video messages to chats and channel conversations. At this point, I think this is the only way to post a video message to a channel conversation.

Making One-Minute Clips

The magic begins when a user selects the Teams camera next to the message compose box when replying to a chat or channel conversation. The right-hand icon exposes options to select an image or one of the two types of blurs. You can change the image during filming if you’re quick and dexterous enough to do this kind of thing without making a complete mess of the video.

Eventually, the right background image is combined with the right position for the message sender (Figure 2), and everything is ready to record the video clip. Click on the canvas (where the background image and your face are combined) to reveal the video controls and click the record button to start. Keep talking until the minute’s up or you run out of words to say. If the length of the clip exceeds a minute, you’ll need to trim it to get under the maximum length. Send the message and Teams adds it to the target chat or conversation.

Figure 3 shows the result of a video clip sent from an iPhone playing in a channel conversation. I was able to post to standard, private, and shared channels. Unlike chats, where Teams stores the video files in its own store, clips sent to channels end up as MP4 files in the SharePoint folder for the channel. Clips posted to channel conversations use the Stream player for playback.

Like the previous iteration of video messages, the […] menu allows chat participants and channel members to download either the transcript or the video.

Compliance Still an Issue for Teams Video Messages

When Microsoft introduced video messages, I pointed out that the compliance records captured for these messages didn’t include any metadata that might be useful to eDiscovery investigators. It is entirely possible to send video clips that convey threatening or abusive content, plan illegal operations, or reveal sensitive or confidential information, all of which is ignored by communications compliance policies and data loss prevention policies, and invisible to eDiscovery searches.

I pointed this issue out to Microsoft in 2022 and suggested that some form of transcription might help. That suggestion appears to have fallen on deaf ears. I’m used to being ignored.

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.

Odd Replacement Cmdlets appear in Microsoft Graph PowerShell SDK V2.17 and Azure Automation Issues in V2.18

Updated 15 May 2024

Last week was odd for me. I headed to Orlando for the M365 Community Conference on Sunday and arrived at the Dolphin hotel feeling somewhat odd. A few hours later, I was flat on my back unable to move with a combination of a horrible cough and the effects of a norovirus. Enough to say that it wasn’t pretty.

The conference swung into full action on Tuesday, and I spoke (between coughs) about the Microsoft Graph PowerShell SDK. I think it’s fair to say that I have a love-hate relationship with the software. I like the access to all sorts of Microsoft 365 data enabled through the SDK cmdlets, but I dislike some of its foibles.

I also hate when Microsoft makes changes that seem to be firmly in the category of shooting itself in the foot, like the spurious output generated for cmdlets introduced in V2.13.1 and worsened in V2.14. Stuff like this shouldn’t get through basic testing.

Update: Microsoft has released V2.19 of the SDK to fix the reported problems. They describe the affected cmdlets in a May 15 blog.

The Case of the DirectoryObjectByRefs Cmdlets

Which brings me to a problem that seems to have surfaced in V2.17. Until this time, the Remove-MgGroupMemberByRef cmdlet worked to remove a member from a group by passing the user account identifier for the member and the group identifier. With V2.17, the following happens:

Remove-MgGroupMemberByRef -DirectoryObjectId $UserId -GroupId $GroupId
Remove-MgGroupMemberByRef: A parameter cannot be found that matches parameter name 'DirectoryObjectId'

The same happens with the Remove-MgGroupOwnerByRef cmdlet to remove a group member (but not if the action would leave the group ownerless).

Microsoft’s response is documented here and it is a calamity. Not only does it appear that other cmdlets are involved (like Remove-MgApplicationOwnerByRef – I have asked Microsoft for a definitive list), but the fix is terrible. No experienced PowerShell person would think that it is a good idea to fix a problem in a cmdlet by introducing a brand-new cmdlet, but that’s what Microsoft did by including cmdlets like Remove-MgGroupMemberDirectoryObjectByRef and Remove-MgGroupOwnerDirectoryObjectByRef in V2.17.

The SDK developers might be pleased that V2.17 contains functional cmdlets to remove group members and owners, but anyone who wrote scripts prior to V2.17 based on the old cmdlets is left high and dry.

I hadn’t noticed the problem because I haven’t run the affected cmdlets for a while. But Ryan Mitchell of Northwestern University had, and he brought the matter to my attention after the session at the Microsoft 365 Community Conference. Suffice to say that the necessary protests have been made in the right quarters. I had the opportunity in Orlando to chat with some senior members of the Graph development team who acknowledged that this is not the way that cmdlet problems should be addressed and that overall Graph SDK quality must be improved. Specifically for the group cmdlets, Microsoft is investigating how the situation developed. It could be that this is a side effect of the famous AutoRest process that generates SDK cmdlets from Graph APIs. We’ll see in time.

Update May 9: Microsoft has published V2.19 of the SDK to address the problem with cmdlet renaming. They’ve introduced aliases to make sure that scripts continue to work with the old cmdlets.

Microsoft Graph PowerShell SDK V2.18 and Azure Automation

Microsoft released V2.18 of the Microsoft Graph PowerShell SDK last week. After installing the new module and running some tests, everything checked out and I duly tweeted that the new module was available.

But problems lurked for Azure Automation runbooks configured for PowerShell 5.1 because people noted that they couldn’t use the Groups module after connecting with a user-provided access token obtained using the Get-AzAccessToken cmdlet. Everything works with PowerShell 7, but not with the earlier release. It seems like a clash occurs between the version of the Azure identity assembly loaded by the AzAccounts module. In any case, Microsoft is investigating (here are the full details) and the advice is to stay with V2.17 if you use Azure Automation until Azure updates their assembly.

Time for a Checkup

It’s disappointing to see issues like these continue to appear in new versions of the Microsoft Graph PowerShell SDK. Basic testing and some knowledge about how people use PowerShell in practice should have caught these issues. Their existence lessens faith in the SDK. After all, who wants to chase new bugs in a module that’s refreshed monthly?

Chapter 23 of the Office 365 for IT Pros eBook referenced examples of the cmdlets affected by the V2.17 issue. We’ve issued update 107.1 with amended text. The nature of an eBook means that it’s much easier to address problems in text than with printed books and we do try and fix known issues as quickly as we can. For everyone else who uses the Microsoft Graph PowerShell SDK for group management or Azure Automation, it’s time to check that everything’s working as expected.

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.

Stream Mobile App Cut from July 1, 2024

Microsoft’s announcement in message center notification MC789607 (2 May) that they plan to retire the Stream mobile client for iOS (Figure 1) and Android on July 1, 2024, is not unexpected. It follows the completion of the long-running migration from the Stream Classic platform to Stream on SharePoint on April 15, 2024.

The (sparse) documentation for the change says that Microsoft is retiring the Stream mobile client as they “continuously strive to improve and unify our services.” More likely it’s simple rationalization. How many mobile apps does Microsoft need to upload and view videos stored in Microsoft 365. And because the focus of video storage is now OneDrive for Business and SharePoint Online, the OneDrive app was never going to be rationalized, even if its mission to handle all file types means that it pays less attention to video than a dedicated video app. The same is true for the Microsoft 365 mobile app, the other alternative nominated by Microsoft.

Microsoft says that their future investment will be in the OneDrive and Microsoft 365 mobile apps. Presumably this refers to investments to improve support for video files rather than just generally.

Block Download Policy

In MC789607 Microsoft calls out a potential change in behavior that users might encounter. The Stream mobile app doesn’t support the SharePoint Online block download policy, which is designed to block downloads of sensitive material from sites. The OneDrive and Microsoft 365 apps do apply the policy, meaning that users are forced to watch videos online if files are stored in sites protected by the block download policy.

I’m not sure that this will be a big concern for many customers because the block download policy is designed to protect sensitive sites that probably don’t hold many videos. I might be wrong, and there’s certainly a case for protecting videos about new products and other confidential material, but in the general course, I think the majority of the 400 mil users won’t notice any difference in viewing videos.

Usage of the Stream App

A note in the announcement says:

“If you would like more information about how many users in your organization are using the Stream mobile apps, please email us at streammobileapp@microsoft.com.”

If you think this seems a tad odd, you’d be right. It’s very strange to send email to a Microsoft development group to ask them to provide information about the usage of an app within a tenant. I bet that the folks lined up to process these emails really appreciate the chance to extract statistics for tenants.

What this statement underlines is the lack of usage data published for Stream in the Microsoft 365 admin center or available through the Graph Reports API. Stream is not alone in this respect. Despite having a usage dashboard in the Microsoft 365 admin center, Copilot for Microsoft 365 is a notable absence in the list supported by the API.

Retiring the Steam Mobile App is a Bump in the Road

Overall, I suspect that the retirement of the Stream mobile app will be a bump in the road: unnoticed by most but a pain for those who hit it. Rationalization occurs all the time and given the size of Microsoft 365 and the number of workloads it spans, it’s likely that good candidates exist for future rationalization. Expect similar stories to emerge in the future.

Thanks to Microsoft for announcing a change like that just after we shipped the May 2024 update for the Office 365 for IT Pros eBook. The only good thing about changes like this is that they show the value of a book that’s constantly updated to stay up-to-date with what happens inside Microsoft 365.

Removing the Share to Teams Outlook Add-in

I’ve never had more than a passing relationship with Microsoft 365 integrated apps (Figure 1). The most I have done is deploy some Outlook add-ins to Exchange Online mailboxes like the Message Header Analyzer.

All of which meant that I probably wasn’t the best person to ask how to remove the Share to Teams Outlook add-in for selected mailboxes. The Share to Teams add-in allows an Outlook user to post a message from Outlook to a one-to-one or group chat or to create a new conversation in a team channel (Figure 2).

Essentially, the add-on signs into Teams for the user and posts the message using a Graph API request. The add-on only works for the user’s home tenant. You can’t use it to post as a guest member to a host tenant. I quite like the add-in but admit that I don’t use it very often. At this point, Share to Teams seems like something that Microsoft had to develop to help people move from email-centric work habits to the chat-based nature of Teams.

Whether Share to Teams helped very much is an open question, but its existence was probably enough to reassure people that it is possible to send information to and from between Outlook and Teams, which has an equivalent Share to Outlook feature to transmit messages in the opposite direction.

Exchange Online App Management Cmdlets

Some research revealed that PowerShell offers a viable solution. The Exchange Online management module contains cmdlets to create, list, remove, and disable apps. For instance, the Get-App cmdlet reveals details of the installed apps for a mailbox:

Get-App -Mailbox lotte.vetler | Format-Table AppId, DisplayName, ProviderName

AppId                                DisplayName             ProviderName
-----                                -----------             ------------
131a8b55-bd40-4fec-b2e6-d68bf5929976 Translator              Microsoft
afde34e6-58a4-4122-8a52-ef402180a878 Polls                   Microsoft Corporation
545d8236-721a-468f-85d8-254eca7cb0da Share to Teams          Microsoft
6b47614e-0125-454b-9f76-bd5aef85ac7b Send to OneNote         Microsoft Corporation
fe93bfe1-7947-460a-a5e0-7a5906b51360 Viva Insights           Microsoft
62916641-fc48-44ae-a2a3-163811f1c945 Message Header Analyzer Stephen Griffin
6046742c-3aee-485e-a4ac-92ab7199db2e Report Message          Microsoft Corporation
c61bb978-adb2-4344-abe9-d599aa75704f EmailTranslator V1.1    Avishkaram
f60b8ac7-c3e3-4e42-8dad-e4e1fea59ff7 Action Items            Microsoft
7a774f0c-7a6f-11e0-85ad-07fb4824019b Bing Maps               Microsoft
a216ceed-7791-4635-a752-5a4ac0a5eb93 My Templates            Microsoft
bc13b9d0-5ba2-446a-956b-c583bdc94d5e Suggested Meetings      Microsoft
d39dee0e-fdc3-4015-af8d-94d4d49294b3 Unsubscribe             Microsoft

The AppId identifier is important because it’s the required value to pass to tell the cmdlet which app to manage.

Scripting Disabling an App

The first task is to identify the set of mailboxes to process. I don’t know why the desire existed to remove the Share to Teams add-in. Perhaps it’s because a division within the company has decided that their users should not use the add-in. Maybe some senior manager took a dislike to the add-in. Or maybe it’s the result of a decision to separate Outlook and Teams communications. For whatever reason, it’s still important to find mailboxes to process. You can do this with the Get-ExoMailbox cmdlet.

Once the targets are identified, it’s a matter of looping through the mailboxes to use the Disable-App cmdlet to turn off the add-in for each mailbox. This code fetches a set of mailboxes based on a value in a custom attribute and checks each to extract the set of enabled apps. If that set includes the Share to Teams app, the Disable-App cmdlet turns Share to Teams off.

$TargetAppId = "545d8236-721a-468f-85d8-254eca7cb0da"  # Id for the Share to Teams app
$TargetAppName = "Share to Teams"
[int]$RemovedApps = 0
[array]$Mbx = Get-ExoMailbox -Filter {CustomAttribute9 -eq 'NoApp'} -RecipientTypeDetails UserMailbox
ForEach ($M in $Mbx) {
    Write-Host ("Checking mailbox {0} for the {1} app" -f $M.displayName, $TargetAppName)
    [array]$InstalledApps = Get-App -Mailbox $M.Alias | `
         Where-Object {$_.Enabled -eq $true} | Select-Object -ExpandProperty AppId
    If ($InstalledApps -contains $TargetAppId) {
        Write-Host ("Disabling app for {0}" -f $M.displayName) -ForegroundColor Yellow
        Disable-App -Identity $TargetAppId -Mailbox $M.Alias -Confirm:$False 
        $RemovedApps++
    } Else {
        Write-Host ("App {0} not installed for {1}" -f $TargetAppName, $M.displayName)
    }
}
Write-Host ("Removed {0} instances of the {1} app from {2} scanned mailboxes" -f $RemovedApps, $TargetAppName, $Mbx.count)

Disabling Outlook Add-ins Isn’t Immediate

It usually takes several hours before Outlook picks up the newly disabled status for the add-in. The app data is cached within the service and refreshed periodically. That refresh must happen before clients can detect the change. There’s nothing you can do to accelerate the process, so consume some of your favorite beverage and chill out.

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

Monthly Update #107 Available for Download

The Office 365 for IT Pros writing team is proud (once again) to announce the latest monthly update for the Office 365 for IT Pros (2024 edition). This is monthly update #107. Subscribers who purchased through Gumroad.com should use the link in the receipt sent for the original purchase or fetch the updated files from their Gumroad account. The link always downloads the latest files. If you bought through Amazon.com, you’ll have to ask Amazon support for help to get the update. Sorry, but that’s how Kindle publishing works. See our FAQ for more information about how to download updates.

The change history for the update is posted to our change log. Be aware that the change log is a guide to the areas of the book where our authors have been active instead of a detailed list of every change made. Too many changes occur to note every detail.

The Accrual of Digital Debris

As the era of AI unfolds, one thing that’s becoming very apparent is the impact of digital debris that accrues inside Microsoft 365 repositories. Copilot for Microsoft 365 uses Graph requests to find item available to the signed-in user when it generates responses to customer requests. Copilot cannot assess the accuracy of information stored in a document nor cannot correct what it finds. All Copilot works with is words and the words it outputs might be incorrect or misleading based on what found in the data retrieved from SharePoint Online, Exchange Online, OneDrive for Business, and Teams.

People generally aren’t very good at clearing out old items from their mailboxes, OneDrive account, or sites that they access. It’s easier to leave the task until some event happens, like a shared mailbox running out of quota. Retention policies help with basic storage maintenance by removing items based on date. However, retention policies are a blunt instrument that can remove good content along with bad. Users can control retention processing by assigning retention labels that set specific retention periods for the assigned items. I used to be very good at this and assigned retention labels assiduously. Now I find that I depend on default retention labels assigned at the document library label or by a retention policy.

The upshot is that Microsoft 365 tenants accumulate digital debris over time. Apart from an overconsumption of storage (and potential an increase in costs for products like Microsoft 365 backup), the debris didn’t matter. With artificial intelligence reasoning over everything it finds, the debris matters a lot more.

I don’t think a good answer exists for the problem exists at present. Asking users to download the contents of a document library to Excel might expose what’s in the document library better than browsing through the SharePoint GUI, but someone’s still got to assess and decide if items should be deleted or kept. It’s quite a conundrum.

Entra ID Apps

Another topic that’s receiving attention is over-permissioned Entra ID apps. This problem was coming for a while. You could argue that the root cause is the ease in which users can create registered Entra ID apps and the lack of management around those apps once created. Both assertions are true. Attackers have been exploiting the gaps around Entra ID apps for years, notably in the recent Midnight Blizzard attack against Microsoft. Once a malicious app with high level of permissions becomes active in a tenant, it can do terrible damage and exfiltrate large quantities of data without anyone noticing.

Like many things in life, there are some simple things you can do to protect your tenant. For example:

• Don’t allow non-admin users to create registered apps. They don’t need to. And if they do, they can explain the reason why to an administrator. Block this option in the Entra admin center.
• Monitor high-priority permissions assigned to apps and query why the permissions are needed. Events about permission assignment is captured in the audit log. Use a scheduled process to report unexpected assignments.

The steps don’t need sophisticated tooling. The data is there. It only needs to be fetched (with PowerShell) and analyzed by people who understand the tenant. Chapter 23 includes details about the Microsoft Graph PowerShell SDK. It’s now a fundamental tool for tenant administrators because of its ability to access data from all parts of Microsoft 365.

Upward and Onward for the Office 365 for IT Pros eBook

The process to build monthly update #108 has already started. This will be the last update for Office 365 for IT Pros (2024 edition). We plan to move to the 2025 edition on July 1, 2025. Hopefully, you’ll join us along the way.

Exerting Control Over Individual Copilot for Microsoft 365 Components

No doubt inspired by the article explaining how to remove individual features (service plans) from Microsoft 365 licenses, a reader asked if it is possible to control where Copilot for Microsoft 365 functionality surfaces in different apps. There’s no GUI in the Microsoft 365 admin center to disable bits of Copilot for a tenant. You can disable apps belonging to the Copilot license for a user account (Figure 1), but the question is what apps are bundled with Copilot for Microsoft 365 and what happens if administrators disable the apps for users.

The Copilot for Microsoft 365 Service Plans

Looking into the details of the Copilot for Microsoft 365 license with the Microsoft Graph PowerShell SDK, we discover that the product (SKU) identifier is 639dec6b-bb19-468b-871c-c5c441c4b0cb and that the license covers eight service plans. As you’ll recall, a service plan governs functionality within a license that can be enabled or disabled. The Microsoft 365 admin center refers to service plans as apps when displaying the license information for a user.

Here’s how to find the license detail with PowerShell:

Connect-MgGraph -Scopes Directory.Read.All -NoWelcome
$CopilotSKU = Get-MgSubscribedSku | Where-Object SkuPartNumber -match "Microsoft_365_Copilot"
$CopilotSku.ServicePlans | Format-Table ServicePlanName, ServicePlanId

ServicePlanName                    ServicePlanId
---------------                    -------------
COPILOT_STUDIO_IN_COPILOT_FOR_M365 fe6c28b3-d468-44ea-bbd0-a10a5167435c
M365_COPILOT_SHAREPOINT            0aedf20c-091d-420b-aadf-30c042609612
GRAPH_CONNECTORS_COPILOT           82d30987-df9b-4486-b146-198b21d164c7
M365_COPILOT_CONNECTORS            89f1c4c8-0878-40f7-804d-869c9128ab5d
M365_COPILOT_APPS                  a62f8878-de10-42f3-b68f-6149a25ceb97
M365_COPILOT_TEAMS                 b95945de-b3bd-46db-8437-f2beb6ea2347
M365_COPILOT_BUSINESS_CHAT         3f30311c-6b1e-48a4-ab79-725b469da960
M365_COPILOT_INTELLIGENT_SEARCH    931e4a88-a67f-48b5-814f-16a5f1e6028d

Table 1 summarizes the service plans included in the Copilot for Microsoft 365 license.

What the Copilot for Microsoft 365 Service Plans Do

The Copilot service plans split into those governing user-facing features and background or administrative functionality.

User functionality:

• Microsoft Copilot with Graph-grounded chat
• Microsoft 365 Copilot in Microsoft Teams (app, summarization of chats and meeting discussions, ability to rewrite/adjust messages before posting to chats or channel conversations)
• Microsoft 365 Copilot in Productivity Apps (Word, Excel, PowerPoint, Outlook (Win32 and Monarch), Loop, OneNote)

Teams and the productivity apps support Copilot in the desktop, browser, and mobile platforms.

Background and administrative functionality:

• Graph connectors bring static information from external sources into the Graph to make the data available to Copilot.
• Semantic index. Although the semantic index isn’t necessary to allow Copilot for Microsoft 365, it helps to ground prompts sent to the LLMs with additional context and therefore contributes to more accurate answers.
• Power Platform Connectors. Controls access to Copilot plugins and Power Platform connectors.
• Microsoft 365 Copilot in SharePoint (use Copilot to help create sites). Microsoft announced this functionality in May 2023, but it doesn’t seem to be available yet. Perhaps all will be revealed at the M365 Conference next week.
• Copilot Studio. A low-code tool for creating and maintaining custom Copilots (Figure 2).

Turning Off Bits of Copilot

Getting back to the original question, control is available over the chat app, Copilot in Teams, and the generalized bucket of productivity apps. For example, you cannot turn off Copilot for Word and Excel and have it available in PowerPoint and Outlook. The productivity apps are either enabled or disabled for Copilot. Granular control isn’t available.

Copilot for Office depends on the Microsoft 365 enterprise apps (subscription version of Office). Using another version, like Office 2024 (preview available now) isn’t possible because these apps don’t include the necessary UI and code to communicate with Copilot.

The answer to the question is that you can turn bits of Copilot for Microsoft 365 off. For instance, not everyone needs access to Copilot Studio. I’m not sure that I would disable any of the other service plans for background and administrative activity because you don’t know if the action might affect how the user-facing apps work. Disabling a user app certainly works and the license change will be effective within fifteen minutes for browser-based apps (Figure 3) and a few hours for desktop apps, depending on when the app refreshes its license information.

But if an organization is paying $360/year for Copilot for Microsoft 365 licenses, surely the imperative is to extract maximum value for the investment instead of restricting what people can use? But if you do decide to disable service plans from the Copilot for Microsoft 365 license, the script will happily do the job for you.

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.