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).

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

But Will a Password Expiration Report be Obsolete Soon?

The advice not to force users to change passwords regularly comes from both Microsoft and independent security agencies. Forcing people to change passwords creates friction for people without delivering better security. The consensus is that better security is attained by moving away from passwords to protect accounts with stronger authentication methods like multifactor authentication or passkeys. Evidence of progress in this direction is Microsoft’s recent announcement of support in Entra ID for device-bound passkeys based on the Authenticator app.

The direction of travel seems clear, but progress is slow. The percentage of Entra ID connections using multifactor authentication reached 38% in early 2024. It takes time to change, which is why I still receive requests for how to create a report showing when Entra ID accounts last updated passwords and details of when the next password change is scheduled.

Setting the Password Expiration Policy

My tenant doesn’t force password changes. The password expiration policy for the tenant is set to never expire. This is easily done through the Org settings section of Microsoft 365 admin center (Figure 1).

The accounts in the tenant are not a great test case for reporting password changes. I’m more concerned about how to report the multifactor authentication status for accounts. With that thought in mind, let’s examine how to approach creating a report with PowerShell.

Steps to Create a Password Expiration Report

Generating a password expiration report is straightforward. In this discussion, I used the Microsoft Graph PowerShell SDK to create a script to:

• Connect to the Graph endpoint by running the Connect-MgGraph cmdlet. Three permissions are needed (If you wish, Directory.Read.All is a higher privileged permission that can be used instead of the first three permissions).
  • Domain.Read.All to read the domain information.
  • User.Read.All to read account information.
  • Organization.Read.All to read information about the tenant (fetch the display name).
  • AuditLog.Read.All to read the sign-in activity information for user accounts.

• Find the password expiration policy for the tenant. This can be done by using the Get-MgDomain cmdlet to fetch details of the default domain and retrieving the password validity period from it. If the value is 2147483647, the tenant does not expire passwords. Date calculations won’t work with 2147483647, so the script adjusts the value to 20000 to calculate a notional password expiration date.
• Find the set of licensed member accounts in the tenant. It’s important to use a server-side filter here to maximize performance. Running a command like Get-MgUser -All fetches all the known accounts in a tenant, but a client-side filter will be necessary to remove guest accounts and unlicensed member accounts such as those used for room and shared mailboxes. Master the art of filtering to make sure that scripts that work with Entra ID accounts perform well. I’ll cover filtering in some depth during my Microsoft Graph PowerShell SDK session at the M365 Conference in Orlando.
• For each account, retrieve details like the date and time of the last password change, the password profile for the account, and to compute a date when the password should be renewed. In tenants that don’t force password renewal, this date will be somewhere long after you retire.
• Generate a report.

A good case exists for using the beta version of the Get-MgUser cmdlet in the script. Apart from fetching a wider set of properties by default, the Get-MgBetaUser cmdlet returns an additional timestamp for the last successful interactive sign-in (which might be different than the last sign-in).

Figure 2 shows a sample password expiration report generated by the script. In this case, the tenant password expiration policy sets password to never expire, so the reported expiration dates are years into the future and no warnings about impending expiration appear in the status column.

You can download the script from GitHub. Remember, the code is intended to illustrate a principle. Use it as you see fit.

Onward to a Passwordless Future

I don’t think there is any doubt but that the time will come when passwords disappear, and we will use more phishing-resistant technologies to prove our identities and sign into applications. Until then, perhaps some will want to report password expiration, and now you have a script to do the job.

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. The PowerShell chapter includes hundreds of examples of using the Microsoft Graph PowerShell SDK.

A Community-Driven Security Configuration Analyzer for Entra ID Tenants

The irrepressible Merill Fernando, a product manager in the Microsoft Entra ID organization, came together with Security MVPs Faben Bader and Thomas Naunheim to create the Maester tool. Announced on April 10, Maester is labeled as a “Microsoft Security test automation framework” and installation instructions are available here. It is a great example of a community-driven project.

Maester is built using Pester and Microsoft Graph APIs. Basically, it runs a bunch of tests against an Entra ID tenant (usually a Microsoft 365 tenant) and measures tenant security configuration settings against the MITRE ATT&CK framework using the Entra ID Security Configuration Analyzer. The output is a report telling the administrator what tests passed and what failed. In my case, the first run of Maester said that my tenant failed 42 tests (Figure 1).

On the surface, failing 42 tests seems like a dreadful outcome and it did generate some concern. However, like anything else that measures something against benchmarks, you need to understand what’s being measured, why a configuration is in a certain state, and if the current settings are valid or should be adjusted.

Conditional Access Policies and Break Glass Accounts

If you use conditional access policies to check inbound connections, at least one break glass account should exist to prevent the possibility of policy misconfiguration locking everyone out (this happens – all the time). I’ve written a PowerShell script to check conditional access policies to make sure that they include exclusions for break glass accounts, adding the accounts to policies when necessary.

Unhappily, my script (which runs regularly as an Azure Automation scheduled job) only processes enabled (active) conditional access policies and ignores those that are in the report-only state. The lack of break glass accounts on some policies in report only mode caused Maester to be unhappy (Figure 2).

To make Maester happy, I adjusted the script to update all conditional access policies.

Another fail reported by Maester said that no conditional access policy existed to require multi-factor authentication for guest accounts. Obviously, something odd happened behind the scenes because that exact policy is in place since January 2022.

Use Your Knowledge to Put Tool Recommendations into Context

The point is that you should never accept a recommendation made by software unconditionally. Always be suspicious until the recommendation is proven, just like you should be suspicious of any text created by generative AI. Context is invaluable and tenant administrators know far more about their business and operations than any tool can aspire to learn.

An example is the use of Entra ID License Utilization Insights where Maester reported the same figures calculated by the Entra admin center to say that I have 5 Entra P1 licenses but 42 active B2B users that need these licenses because they use conditional access policies (to mandate MFA, see above). But my tenant is configured to use the monthly active user billing model for premium features and I pay for this usage every month through an Azure subscription. Microsoft has some work to do to get its insights sorted out, and anything built on top of their data will be flawed until the data is corrected.

Good Links to the Graph Explorer and Graph APIs

We’re discussing the V0.1 release of a community project here and some bugs are expected. To be more positive, I like the way that Maester includes links to the Graph Explorer when it’s possible to use the Explorer to patch configurations with a Graph request. An example is where the access granted to directory information for guest account is unrestricted. The recommendation is to restrict access to prevent guest accounts being able to enumerate directory information, which means that guest accounts should have a restricted access role (GUID 2af84b1e-32c8-42b7-82bc-daa82404023b instead of the default (10dae51f-b6af-4016-8d66-8c2a99b929b3).

It’s easy to fix this problem in the Entra admin center, but who can resist the chance to run a Graph request instead of clicking a button? The link provided opens the Graph Explorer with the request to list the authorization policy (Figure 3). This is a GET transaction so it only fetches the data to check, but for extra marks you can add a request body and PATCH the policy. A future version of Maester might do that work for you if the developers don’t think it too dangerous.

Support the Maester Tool!

It would be easy to keep nitpicking but that’s not the right thing to do. Community projects need to be cherished and supported. Things will improve in time as people find glitches to fix and knowledge grows. The important thing is that Maester is a new tool for Microsoft 365 tenant administrators to use to improve their knowledge of Entra ID security features that can make their tenant more secure and harder to compromise. That’s always a good thing, which is why I like Maester.

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.

New Version of the MSCommerce PowerShell Module Released

Microsoft’s drive to liberate the great downtrodden masses of Microsoft 365 users from the baleful oversight of tenant administrators continues and there are now 25 different licenses available for self-purchase. That’s all very well if you buy into the theory that it’s good for people to buy their own licenses for products like Python on Excel or Viva Learning. It’s less welcome in organizations that like to exert control over licenses to keep monthly charges within reasonable boundaries.

It’s a while since I looked at self-purchase licenses. The last time I checked was after Microsoft added Teams Premium licenses to the self-service roster. This time round, my interest was sparked by the release of V2.0 of the MSCommerce PowerShell module and its rapid replacement by a V2.2 release on April 1. That version was subsequently unlisted by Microsoft and is currently unavailable, despite the publication of message center notification MC767477 (3 April) saying that V2.2 contains vital security updates and should be used. According to MC767477, all prior versions of the module will cease to work on April 17, 2024. Let’s hope that Microsoft gets V2.2 back online before then.

Still Not an Interesting Module

In any case, when an update increases the major version number, you always hope that the developers have done something exciting to warrant the appearance of a new version. Regretfully, the MsCommerce PowerShell module is still not very interesting and it seems like the developers increased the major version number out of boredom rather than for any other good reason. The module requires Windows PowerShell (version 5) and doesn’t support PowerShell 7.*. The module cmdlets behave in their own way, but at least the module seems to be stable, which is not something that has always been the case in the past (and might have been the reason why the V2.0 module was replaced so quickly).

In any case, I used the Get-MSCommerceProductPolicies cmdlet to find out how many products are now available for self-purchase. The number is now 25. Proving that I haven’t been keeping an eye on things, 12 products were enabled for self-purchase in my tenant.

Turning Off Self-Purchase for Enabled Licenses

Disabling self-purchase for all eligible licenses is quickly done by finding the set of enabled products and updating their enabled status to False. After connecting to the Commerce endpoint with the Connect-MsCommerce cmdlet, (your account needs to hold either the global or billing administrator role), running this PowerShell command did the trick:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Where-Object {$_.PolicyValue -match 'Enabled'} | ForEach {Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductId -Enabled $False}

To check the status, run this command:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Sort-Object ProductName | Format-Table ProductName, PolicyValue

ProductName                                            PolicyValue
-----------                                            -----------
Dynamics 365 Marketing                                 Disabled
Dynamics 365 Marketing Additional Application          Disabled
Dynamics 365 Marketing Additional Non-Prod Application Disabled
Dynamics 365 Marketing Attach                          Disabled
Microsoft 365 F3                                       Disabled
Microsoft ClipChamp                                    Disabled
Microsoft Purview Discovery                            Disabled
Power Apps per user                                    Disabled
Power Automate per user                                Disabled
Power Automate Per User with Attended RPA Plan         Disabled
Power Automate RPA                                     Disabled
Power BI Premium per user                              Disabled
Power BI Pro                                           Disabled
Project Plan 1                                         Disabled
Project Plan 3                                         Disabled
Python On Excel                                        Disabled
Teams Exploratory                                      Disabled
Teams Premium                                          Disabled
Visio Plan 1                                           Disabled
Visio Plan 2                                           Disabled
Viva Goals                                             Disabled
Viva Learning                                          Disabled
Windows 365 Business                                   Disabled
Windows 365 Business with Windows Hybrid Benefit       Disabled
Windows 365 Enterprise                                 Disabled

Although it’s easy to disable all the self-service product licenses, it’s a pain to have to check periodically for newly enabled products and disable them. One potential solution seemed to be to create a runbook for Azure Automation to execute on a scheduled basis. Regretfully, it seems that the MsCommerce PowerShell module can’t cope with Azure Automation. At least, I can find no information about getting the module to work in a runbook apart from this GitHub thread lamenting the lack of support. As commented within the thread, it would be nice if MsCommerce supported a Graph API. Perhaps Microsoft doesn’t want to make it too easy for tenants to disable self-service purchases?

Back to a Manual Check

Until the module behaves like a mature PowerShell component, I have a monthly reminder to check the enabled state for self-service purchases in my tenant. Oh well, it could be worse. At least I know that a manual check will always work.

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.

Resolving Tenant Identifiers

Every Microsoft 365 tenant has a unique identifier (a GUID) that’s used within the Entra ID ecosystem to identify the tenant and its objects. This post is an update for a previous article published three years ago. Much has changed in the intervening period, including a renaming of Azure AD to be Entra ID and the introduction of new Graph APIs to resolve tenant identifiers in different ways.

The tenant identifier is used in many places, such as to identify the tenant to connect a Microsoft Graph PowerShell SDK to:

Connect-MgGraph -TenantId "72f988bf-86f1-41af-91ab-2d7cd011db47"

The identifier for your tenant is available in the Overview section of the Entra admin center (Figure 1). Usefully, you can copy the value from the admin center and keep it for other purposes.

To find the identifier for your tenant with PowerShell, run the Get-MgOrganization cmdlet after connecting to the Microsoft Graph PowerShell SDK.

Connect-MgGraph -Scopes Organization.Read.All -NoWelcome
Get-MgOrganization | Format-List Id, DisplayName

Id          : a662313f-14fc-43a2-9a7a-d2e27f4f3478
DisplayName : Office 365 for IT Pros

The responses for many Graph requests and PowerShell cmdlets return the GUID identifying the tenant. Usually, the tenant identifier points to your own tenant, and you’ll recognize it. Sometimes APIs return identifiers from other tenants. For instance, the Get-AssociatedTeam cmdlet from the Microsoft Teams module includes the identifier for external tenants that host shared channels that users have direct membership in. This is why it’s useful to resolve tenant identifiers programmatically.

Resolving a Tenant Identifier GUID

It’s useful to be able to resolve the GUID for a tenant identifier and find the display name. For example, few people will recognize 72f988bf-86f1-41af-91ab-2d7cd011db47, but most will understand “Microsoft.”

To resolve a tenant identifier, use the findTenantInformationByTenantId Graph API to look up the tenant information published on the internet. There doesn’t seem to be a cmdlet in the latest version of the Microsoft Graph PowerShell SDK, so it’s necessary to use the Invoke-MgGraphRequest cmdlet. This example takes a tenant identifier and calls the API to return the tenant information. The code then extracts the tenant display name from the information to use for reporting or other purposes.

$LookUpId = $TenantId.toString()
$Uri = ("https://graph.microsoft.com/V1.0/tenantRelationships/findTenantInformationByTenantId(tenantId='{0}')" -f $LookUpId)
$ExternalTenantData = Invoke-MgGraphRequest -Uri $Uri -Method Get
$ExternalTenantName = $ExternalTenantData.displayName
Write-Host ("The tenant with identifier {0} is {1}" -f $LookupId, $ExternalTenantName)

Resolving a Tenant Display Name to the Tenant Identifier

To do the reverse and find the tenant identifier for a Microsoft 365 tenant using its domain name, use the findTenantInformationByDomainName API. The code is similar to resolving a tenant name by identifier:

$Domain = Read-Host "What domain should I lookup"
$Uri = ("https://graph.microsoft.com/v1.0/tenantRelationships/findTenantInformationByDomainName(domainName='{0}')" -f $Domain) 
[array]$DomainData = Invoke-MgGraphRequest -Uri $Uri -Method Get -ErrorAction SilentlyContinue
If (!($DomainData)) {
    Write-Host ("Whoops - can't find a Microsoft 365 tenant for {0}" -f $Domain)
} Else {
    Write-Host ("The tenant id for {0} is {1}" -f $DomainData.displayName, $DomainData.tenantId)
}
What domain should I lookup: Microsoft.com
The tenant id for Microsoft is 72f988bf-86f1-41af-91ab-2d7cd011db47

Both examples use the tenantRelationships Graph API to lookup tenant information by identifier or name. To gain access, the calling app (such as the Microsoft Graph PowerShell SDK) must have consent for the CrossTenantInformation.ReadBasic.All Graph permission.

The Graph APIs are relatively recent. It’s also possible to use the federationProvider web API to read the published information about tenants from the internet. Because this API is not part of the Graph APIs, use the Invoke-RestMethod cmdlet instead of Invoke-MgGraphRequest. For example:

$Domain = Read-Host "What domain should I lookup"
$Uri = ("https://odc.officeapps.live.com/odc/v2.1/federationProvider?domain={0}" -f $domain)
$DomainId = Invoke-RestMethod -UseBasicParsing -Uri $Uri | Select-Object -ExpandProperty TenantId -ErrorAction SilentlyContinue

This is the approach used by websites like What is My Tenant Identifer (a ShareGate property – Figure 2).

Knowing Tenant Identifiers is a Good Thing

GUIDs are difficult to remember, and I don’t bother trying. When I think about the number of times I have had to find a tenant identifier over the years, the amount must be in the hundreds. Being able to find a tenant identifier without reverting to the Entra admin center is a good skill to have, especially if you want to use the information in a script.

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 Backup Costs Based on Per Gigabyte of Protect Content

In my last article about Microsoft 365 Backup, I explained that I liked the ease of use of the product but had problems restoring data to SharePoint Online sites and OneDrive for Business accounts. Here I want to discuss the cost of using Microsoft 365 Backup (preview).

Microsoft charges for backups on a pay as you go basis at a rate of $0.15/month per gigabyte of protected content. The costs are paid through an Azure subscription The documentation includes a calculator to help estimate how much it will likely cost to use Microsoft 365 backup. An essential part of that is to know the size of the sites, accounts, and mailboxes chosen for backup.

Getting Sizes for Protected Content

Storage usage information for workloads can be obtained using PowerShell cmdlets or the Graph usage reports API. Unhappily, some problems prevent easy access to storage usage data for SharePoint Online sites through the Graph. However, the data is available through the SharePoint Online management module (here’s an example script) or by checking the storage data reported in the SharePoint admin center.

The same problem doesn’t affect Graph usage data for Exchange Online or OneDrive for Business, so you could use that approach or cmdlets from the Exchange Online and SharePoint Online management modules. Here are examples of scripts to report Exchange mailbox sizes and OneDrive for Business account sizes.

Microsoft warns that “Mailboxes are the size of the user’s mailbox plus their online archives plus deleted items held for Backup.” The Exchange mailbox size calculation is therefore the size of user-accessible folders in the primary and archive mailboxes (if enabled) plus the size of the Recoverable Items folders in the primary and archive mailboxes.

Computing Microsoft 365 Backup Costs

In my tenant, the outcome for the locations selected for backup protection was:

• SharePoint Online 109 GB * $0.15 = $16.35
• OneDrive for Business 71 GB = $10.65
• Exchange Online: 20 GB = $3

Overall, the estimated Microsoft 365 backup costs for my tenant came to $30. Growth is expected to accommodate new information added to the target locations, so the actual cost over a year might go from $30 to $36 (20% growth).

Your mileage will vary depending on the growth experienced in the selected locations and how aggressive the tenant is in clearing out older data using retention policies. Archive mailboxes grow by holding information moved from the primary mailbox by Exchange mailbox retention policies. Archived data tends to remain for longer periods. For this reason, it’s not unusual to see archive mailboxes that are several times larger than primary mailboxes (up to the 1 TB limit for expandable archives).

In the first month, Microsoft 365 backup cost EUR 12.88 or $14.03 (Figure 1), or about half the expected cost. I assume that some startup processing takes place in the background that resulted in the lower outcome.

The invoice for the second month increased backup costs to EUR 25.18 or $27.42 (Figure 2), so it’s tracking closer to the expected level. Microsoft 365 Backup is processing more data. However, the extra data does not reflect a doubling of costs over the previous period. Overall, this points to some stabilization in the calculation of backup costs. I imagine that when Microsoft 365 Backup is generally available, the costs incurred for Azure subscriptions will be at the predicted levels very soon after commencement.

Driving Toward General Availability

Microsoft 365 Backup is certainly worth considering for tenant data protection. The big issue that traditional backup products point to is that the data remains in Microsoft datacenters and therefore breaks the classic backup principle of keeping a copy of the data in a separate location. While true, the counterargument is that given the petabytes of data created in Microsoft 365 tenants daily, it’s hard to move such a volume of data offsite to a remote backup and even harder to restore data in an acceptable time. Microsoft’s datacenters have a robust record of availability, and I don’t see a problem with the backup data being kept alongside the live data. After all, if the Microsoft 365 datacenters are unavailable, what is the restore target for the offsite copies of sites and mailboxes?

A compromise might be to combine traditional and Microsoft 365 Backup into a hybrid where the traditional backup satisfies the need to move data to a remote location while Microsoft 365 backup satisfies the requirement for fast restore. Given that several backup vendors are building support for the Microsoft backup API into their products, I imagine that we will see some interesting innovation in this space.

In the meantime, we await the general availability of Microsoft 365 Backup. In that version, I anticipate that Microsoft will address the problem with restoring sites under compliance holds. I hope that they add properties to show when sites and mailboxes are protected by Microsoft 365 Backup that’s available through PowerShell and a Graph API. Properties like last backup time, the technology used for backup (including ISV products), and the size of protected data would be nice. In fact, a Graph API for setting up and managing backups and restores would be even nicer.

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.

Microsoft 365 PowerShell Automates Management Operations Quickly, Easily, and Cheaply, No Matter What an MVP Says

My strong view that it’s often a bad idea for Microsoft MVPs to endorse ISV products (with or without payment) was reinforced by a recent article titled “6 Reasons Why Identity Admins Should Retire Scripting” written by Sander Berkouwer (described as an Extraordinary Identity Architect in his LinkedIn profile).

Update: The original article is no longer available on the ENow Software site. It seems like they pulled it soon after this article appeared.

Update 2 (March 12): ENow Software republished an amended article. It still contains inaccuracies and demonstrates a lack of knowledge and awareness about the role and function of the Microsoft Graph PowerShell SDK.

The article is a thinly disguised pitch for ENow Software’s App Governance Accelerator product. Basically, Berkouwer says that Entra ID administrators (who are often the same people as Microsoft 365 tenant administrators) should eschew PowerShell and leave management automation to ISVs. It’s a ridiculous position that is insulting to the many IT professionals who work with PowerShell daily.

I’m all for strong ISV participation in the market and have worked with ENow Software and other ISVs during my career. Because the cloud is a more closed environment, it’s more difficult for ISVs to find niches to exploit in the Microsoft 365 ecosystem than in on-premises environments. It’s natural for ISVs to respond by seizing every opportunity to publicize their products. In doing so, many ISVs seek the endorsement of “an expert,” like a Microsoft MVP. In my eyes, these endorsements are close to worthless.

How Microsoft 365 PowerShell Helps Administrators

The major theme developed by Berkouwer is to question whether writing PowerShell scripts is a good use of administrator time and lays out six “reasons to retire this practice.” My perspective is that understanding how to use PowerShell is a fundamental skill for Microsoft 365 administrators to acquire. You don’t have to be proficient, but PowerShell helps administrators to understand how Microsoft 365 works. This is especially true of using Graph APIs, including through the Microsoft Graph PowerShell SDK.

Here are the six reasons advanced for why administrators shouldn’t spend time writing scripts.

Microsoft renamed Azure AD: Including this as a reason to stop writing PowerShell scripts is simply silly and undermines the author’s credibility. Product rebranding happens. The important point is what a product does. Should we stop using the Microsoft Purview solutions simply because Microsoft decided to bring them all under the Purview brand? Or perhaps Yammer customers should have fled when Microsoft renamed it as Viva Engage?

Don’t trust random scripts you find on the internet… “written by everyone’s favorite Microsoft Most Valuable Professional.” This has been the advice given about PowerShell scripts since 2006. It is not a blinding insight into new knowledge. Great care is required with any code downloaded from the internet, including any of the 250-odd scripts available from the Office 365 for IT Pros GitHub repository.

Downloaded code, even written by a favorite MVP, should never be run before it is thoroughly checked and verified. But it’s also true that many scripts are written to demonstrate principles of how to do something instead of being fully worked-out solutions. Before people put PowerShell code into production, it must meet the needs and standards of the organization. For instance, developers might tweak a script to add functionality, improve error handling, or log transactions. Michel de Rooij addresses some of these challenges in his Practical365.com column.

Berkouwer’s assertion ignores the enormous value derived from how the community shares knowledge, especially at a time when tenants are upgrading scripts to use the Graph SDK. Without fully worked out examples, how could people learn? I learned from examples when PowerShell first appeared with Exchange Server 2007 in 2006. I still learn from examining PowerShell scripts written by others today. And many maintain the scripts shared through GitHub repositories.

The greater use of GitHub repositories and their inbuilt facilities to report and resolve issues helps people to share and maintain code. In addition, GitHub Copilot helps developers reuse PowerShell code that’s stored in GitHub to develop new solutions. The net is that it is easier than ever before to develop good PowerShell code to automate tenant operation.

Least Priviliged Principle. It’s true that the changeover from older modules like MSOL and AzureAD to the Graph SDK brings a mindset change. Instead of assuming that you can do anything once you connect to a module with an administrator account, some extra care and thought is needed to ensure that you use the right Graph permissions (delegated or application). Right permission means the lowest privileged permission capable of accessing the data a script works with. Yes, this is a change, but finding out what Graph permissions to use is not a difficult skill to master and I utterly fail to see why Berkouwer considers it to be such a big problem. If anything, adopting the least privileged principle drives better security practice, and that’s goodness.

The only constant in life is change. Yes, change is ongoing all the time across the Microsoft 365 ecosystem, but it is untrue that people can’t keep pace with that change. Microsoft publishes change notifications and although they’re not perfect and don’t include everything that changes (like Entra ID updates), a combination of the message center notifications (perhaps leveraging the synchronization of message center information to Planner) and RSS feeds to track important Microsoft blogs is all that’s needed.

There’s no evidence to suggest that ISVs are any better at tracking change within Microsoft 365. If anything, ISV development cycles, the need for testing, and customer desire for supportable products can hinder their ability to react quickly to changes made by Microsoft.

Maintaining and updating scripts. I’m unsure why the European Cyber Resilience Act is introduced into the discussion. It seems like some FUD thrown into the debate. PowerShell scripts are like any other code used in production. They must have a designated owner/maintainer and they should be checked as new knowledge becomes available, just like programs written using C# or .NET must be checked when Microsoft releases updates. ISVs have the same problems of code maintenance, so handing a task over to an ISV might resolve a tenant of some responsibility without being a magic bullet.

Zero trust. “When you run scripts for monitoring and security reporting purposes, they must provide instantaneous, useful information.“ Well, it would be nice if tenants always had instantaneous data to process but the singular fact is that tenants and ISVs share the same access via public APIs to information like usage reports, audit logs, license data, sign-in logs, workload settings, and so on. For instance, the data used to create a licensing report comes from Entra ID user accounts and a Microsoft web page. The data that the ENow App Governance Accelerator product comes from Entra ID and is easily accessed and reported using PowerShell (here’s an example).

ISVs and PowerShell Access the Same Microsoft 365 Data

ISVs don’t have magic back doors to different information that suddenly throws new light onto the inner functioning of Microsoft 365. ISVs might develop innovative ways of using information and use those methods to create new features, but that’s not the instantaneous, useful information that Berkouwer wants.

If Microsoft 365 tenants want to run PowerShell scripts to check what turns up in audit and other logs, a simple solution exists in the shape of Azure Automation runbooks executed on a schedule. It’s not hard to translate a regular PowerShell script to execute in Azure Automation and the support for managed identities in the major Microsoft 365 modules makes authentication for runbooks easy and highly secure. Here’s an example of using Azure Automation to create a daily risk report for Microsoft 365 tenants.

No Reason to Dump Microsoft 365 PowerShell

The solution is emphatically not to dump PowerShell scripts for an ISV product. Well-written PowerShell is as robust and secure as any ISV product. It’s worth noting here that Microsoft uses tons of PowerShell in its operations.

No single off-the-shelf product can cater for the different aspects of Microsoft 365 tenant management. ISV products have bugs, need to be supported, sometimes do a worse job than tenant-developed scripts, and no guarantee exists that the products will keep up with changes within Microsoft 365. Deploying ISV products also involves additional costs to pay for licenses and support.

On the other hand, ISV products are usually developed and maintained by very experienced professionals who are dedicated to that task (and don’t have to worry about day-to-day tenant management), so they have the time and space to think more deeply about what their product does.

ISVs Should Compete on their Merits, Not with False Arguments

I have the height of respect for Microsoft 365 ISVs and the products they create and support. Those of us who have worked in this space understand the challenges of running ISV operations and how difficult it is to succeed in a very competitive market. Product reviews do help, but only when the review focuses on explaining the strengths and weaknesses of a product after the reviewer spends a reasonable amount of time getting to understand the technology and how it fits into the ecosystem it works in.

Many ISV offerings work extremely well and do a good job of filling gaps left by Microsoft. I applaud the innovation I see in many ISV products and how they add real value to the Microsoft 365 ecosystem. ISVs do not need to be supported by artificial arguments, especially laughable advice to avoid using one of the most valuable tools available in tenant management toolboxes. If Sander would like some help understanding the usefulness of the Microsoft Graph PowerShell SDK, I’ll be delighted to help if he attends my session at the Microsoft 365 Conference in Orlando.

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 Evolution of Microsoft 365 Backup to its Current Preview Status

Paul Robichaux, a longstanding MVP and someone who knows much more than I do about backup technologies, wrote an interesting review of the public preview of Microsoft 365 Backup for Practical365.com. I don’t need to dive into the details of what Paul covered about the mechanisms used by Microsoft 365 Backup to protect SharePoint Online, OneDrive for Business, and Exchange Online data. Instead, I decided to focus on how restore operations work. I did this on the basis that it’s straightforward for a backup product to stream data from a repository to create a copy of one form or another. The trick is to be able to restore copied data to the right place at the right time in the right way.

For background, I’ve been tracking the progress of Microsoft 365 Backup for several years, including discussions with the Microsoft engineers who built the product. When Microsoft began to discuss the product in public, I concluded that it was something I needed to test and potentially use over the longer term to protect my tenant’s data.

Until now, I have largely eschewed backups for Microsoft 365 and relied on native data protection (for Exchange Online) and retention policies. I consider many of the arguments advanced by companies selling backup solutions to be firmly rooted in FUD, especially when it comes to Teams. Unsurprisingly, because Teams is the most difficult Microsoft 365 workload to backup (and even harder to restore), Microsoft hasn’t included it in its set of target workloads.

When Microsoft launched the preview of Microsoft 365 Backup, I configured backup policies for all workloads and opted to protect the most active (and probably) valuable sites, accounts, and mailboxes in the tenant, including the site holding the source files for the Office 365 for IT Pros eBook. Backups have progressed since early January. Apart from adding extra mailboxes and accounts to the backup policies, I haven’t had to do anything since the original configuration.

Restoring Microsoft 365 Data

The big selling point for Microsoft 365 Backup is that it makes it fast and easy to restore data. The data for backups is stored in the Microsoft Cloud and is almost instantly accessible, or so the story goes. Backup professionals don’t like all their eggs stored in one cloud basket and don’t consider Microsoft 365 Backup to be a true backup. However, having everything in the Microsoft cloud makes backup and restore operations much faster than if the data must transit the internet to storage in a backup vendor’s datacenter.

There’s no doubt that Microsoft created a simple and easy to use UI for backup. The downside is that there’s no log to help you understand what happened during a restore or more importantly, where problems might have been met. Before beginning, it’s wise to read the latest set of limitations documented by Microsoft. Apart from anything else, you might discover that you must do something before a restore is possible, such as removing in-place holds from Exchange mailboxes. The number of documented limitations is likely to decrease as Microsoft develops the product from its current preview statis to a point where Microsoft 365 Backup is generally available.

You can learn the details of restore operations from Microsoft’s documentation. Creating a restoration task follows much the same path for all workloads:

• Select the workload.
• Select the protected locations (site, account, or mailbox) to restore.
• Select the restore point (Figure 1).
• Confirm everything and launch the restoration task.
• Wait for the restoration task to complete.

My experience is that Exchange Online restores are quicker than SharePoint Online or OneDrive for Business. That’s likely due to the way Exchange uses an existing copy-on-write mechanism to tag items. In all tests, Exchange restored data within a few minutes. As a quick and simple test to ensure that the data was restored, I used PowerShell to note the contents of important folders before and after a restore.

For example, here are the folder statistics at the time that I wanted to restore to:

Get-EXOMailboxFolderStatistics -Identity "James.Ryan@office365itpros.com" | where-object {$_.ItemsInFolder -gt 0 -and $_.Name -in $Folders} | Format-Table Name, ItemsInFolder, FolderSize

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             0 0 B (0 bytes)
Inbox                  1038 248.5 MB (260,572,313 bytes)
Sent Items               19 794.1 KB (813,182 bytes)
Deletions                 6 3.689 MB (3,868,185 bytes)
Purges                    1 1.904 KB (1,950 bytes)

I then removed some items from the Inbox and emptied the Deleted Items folder. The increased number of items in the Deletions folder matches the number of items removed from the Inbox and those emptied from Deleted Items (5).

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             0 0 B (0 bytes)
Inbox                  1033 247 MB (258,973,507 bytes)
Sent Items               19 794.1 KB (813,182 bytes)
Deletions                11 5.214 MB (5,467,162 bytes)
Purges                    1 1.904 KB (1,950 bytes)

I then created a restore task using the restore point closest to the time when I first noted the folder contents. When the restore finishes, I checked the data reported by Exchange. We can see that it roughly matches what was there at the start. One item from Sent Items was deleted, so it’s in Deleted Items. This emphasizes that Exchange Online uses a roll forward mechanism for restore, meaning that items that aren’t affected (a refile to another folder doesn’t affect the item status, a deletion does) are left intact.

Name          ItemsInFolder FolderSize
----          ------------- ----------
Deleted Items             1 19.28 KB (19,745 bytes)
Inbox                  1038 248.5 MB (260,572,377 bytes)
Sent Items               18 774.9 KB (793,459 bytes)
Deletions                 6 3.689 MB (3,868,185 bytes)
Purges                    1 1.904 KB (1,950 bytes)

Naturally, this is an imperfect way to validate restore operations. A visual check of mailbox contents confirmed that everything that I expected to be there was in place. Exchange Online logs audit records for the New-MailboxEnhancedRestoreBatch and New-MigrationBatch operations when it starts a restoration task. The details of the audit event only tell you that a restore began for a user called “NT AUTHORITY\\SYSTEM (w3wp).” Some of the data logged in the events might be useful to a Microsoft support representative, but the information isn’t detailed enough to help a tenant administrator understand what happened.

Happy that I could restore mailboxes, I went ahead to try to restore data for a SharePoint site.

Restoring SharePoint Online

Both SharePoint Online and OneDrive for Business use a roll back process for restores. In other words, you decide what restore point to use, and Microsoft 365 Backup rolls back the site or account to have the content stored at that time. Restores can be to the same site or to a new site. If you restore to the same site, the possibility currently exists that people working in the site might have their work overwritten. Microsoft plans to lock sites against changes to avoid this issue in the future. Exchange uses a roll-forward process, meaning that unchanged items since the chosen restore point are unaffected and only changed or deleted items are brought back. In any case, my experience with SharePoint restores didn’t go so well.

I added a bunch of files to a site and then tried to roll back to a point beforehand. The idea was to replicate infection by malware when you need to restore a site to the last good backup before the malware arrived. SharePoint accepted the restore task and about fifty minutes later politely failed. Nothing happened to the restore destination and the detail available about what happened to cause the restoration task to fail was non-existent (Figure 2).

Many attempts to restore the site failed and the last restoration task failed after nearly three hours (the second task listed in Figure 3). SharePoint Online does not log any audit records for administrators to check nor is any other log available to consult to discover why the task failed. Despite rereading the documentation several times and checking all the settings, I could make no progress. Perhaps it’s just me, but I failed in my initial attempts to successfully restore SharePoint Online sites or OneDrive for Business accounts.

Without Microsoft 365 Backup generating a log file or revealing more details about failure symptoms it’s hard to diagnose what’s happening. I put the problem to Microsoft and learned that the problem is due to the holds applied by retention policies. This limitation is documented for OneDrive and mailboxes but not for sites. For now, the solution is to restore files to a new site. This works and restoring files to a different site allows them to be copied to the original site as necessary. However, it’s not quite the smooth recovery operation that I anticipated, even in a preview product.

My biggest concern is that the holds imposed by retention policies block restoration tasks. When things go wrong, administrators want to restore sites or accounts back to good health as quickly as possible. Speed, after all, is the promise extended by Microsoft 365 Backup. Altering settings for Microsoft 365 retention policies to remove holds on sites, including the potential need to adjust adaptive scopes, is not speedy. It can take days before changes are fully respected by SharePoint Online. How then are fast restores possible?

Remember It’s a Preview

Microsoft 365 Backup is a preview solution, but it’s a paid-for preview and I expected what appears to be a straightforward restore request to happen without trauma. After talking to Microsoft, I think they understand that problems exist that must be sorted out before the product reaches general availability. As noted above, these issues include speed of restore, faster detection of problems in restoration tasks, better error handling and logging, and much more elegant handling of sites under control of retention policies.

Microsoft 365 Licensing Report Details Costs Per User to Find Optimizations

Recently, I released an update to my Microsoft 365 Licensing Report PowerShell script to include the ability to assign costs to user accounts. The idea is to give administrators information about how much the cumulative annual license charges are for each account. Combining cost data with insight about account activity in a tenant (generated with the user activity report script or by reference to the individual workload usage reports in the Microsoft 365 admin center), administrators can figure out if users have the right licenses they need to work and no licenses are assigned to inactive accounts.

Managing the cost of Office 365 and Microsoft 365 licenses has always been important. As Microsoft puts more focus on driving revenue through high-priced add-ons such as Teams Premium ($120/year) and Copilot for Microsoft 365 ($360/year), it’s even more essential to keep close tabs on license assignments. There’s no point in assigning a Copilot license to someone who’s inactive or whose usage pattern indicates that they might not take advantage of the license. No one is rewarded for overspending on licenses.

Adding Cost by Department and Cost by Country to the Microsoft 365 Licensing Report

Almost immediately after releasing the updated script, calls came in to ask if it was possible to generate an analysis of licensing cost by country and by department. My initial response was “sure” and I set to figuring out the best way to implement the change.

Because the report script tracks license costs per user, the simple method is to:

• Find the sets of departments and countries in user accounts.
• For each department (or country), calculate the sum of license costs.
• Include the information in the report.

The same approach works to analyze license costs for any user account property fetched by the initial Get-MgUser command at the start of the script. If the set of regular account properties don’t work for your organization, you could use an Exchange custom attribute to store the required values. For instance, you could include a cost center number in a custom attribute. Here’s how to access Exchange custom attributes with Get-MgUser. You’ll need to extract the information from the custom attribute before you can use it in the script.

The Problems Caused by Inaccurate Directory Data

The obvious problem is that sometimes the properties of user accounts don’t include a department or country. Account properties should hold accurate properties, but unfortunately this sometimes doesn’t happen because administrators fail to add properties to accounts, or a synchronization process linking a HR system to Entra ID encounters problems, or something else conspires to erode directory accuracy. The point is that inaccurate or missing user account properties result in bad license accounting.

The first order of business is therefore to validate that the account properties that you want to use for license cost reporting exist and are correct. This article explains how to detect user accounts with missing properties. Making sure that properties are accurate requires an extra level of review. The value of the country property assigned to user accounts shouldn’t change frequently, but properties like department and office might.

Reporting Licensing Costs for Country and Department

After making sure that all the necessary user account properties are in place (and accurate), the code to generate cost analyses based on department and country worked like a dream. The script also required an update to insert the new data into the output report, including warnings for administrators when costs cannot be attribute to countries or departments because of missing account properties. Figure 1 shows the result.

The code changes are in version 1.6 of the report script, which you can download from GitHub. If you haven’t run the script before, make sure that you read the previous Practical365.com articles to understand how the script works and how to generate the two (SKU and service plan) CSV files used by the script.

Remember that this script is intended to demonstrate the principles of interacting with and interpreting Entra ID user account and license information with the Microsoft Graph PowerShell SDK. It’s not intended to be a bulletproof license cost management solution. Have fun with PowerShell!

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

Use the Microsoft Graph PowerShell SDK to Analyze Service Update Messages

In November 2020, I wrote an article about the number of Microsoft 365 message center posts about new features that ended up being delayed. At the time, 29.27% of message center posts needed to adjust their published date for feature availability. Being of a curious nature, I wondered if Microsoft is better at predicting when they can deliver software across the spectrum of Microsoft 365 applications.

The code I used in 2020 is now obsolete. Microsoft moved the service communication API from the old manage.office.com endpoint to the service communications Graph API and access to message center posts is through the service update message resource. Because the service communications API is a full-fledged Graph API, cmdlets in the Microsoft Graph PowerShell SDK are available to work with message center posts. For instance, the Get-MgServiceAnnouncementMessage cmdlet retrieves message center posts. This command shows how to retrieve posts for the last seven days:

$SevenDaysAgo = (Get-Date).AddDays(-7)
$CheckDate = (Get-Date($SevenDaysAgo) -format s) + "Z"  
[array]$MCPosts = Get-MgServiceAnnouncementMessage -filter "StartDateTime ge $CheckDate"

Adding the “Z” to the sortable date generated by the Get-Date cmdlet is important for the filter to work.

Updating the Code

The code written in 2020 uses a registered Entra ID app to obtain an access token and fetch the message center posts. Updating the script involved:

• Removing the code to obtain an access token and replacing it with a call to the Connect-MgGraph cmdlet specifying the ServiceMessage.Read.All scope (permission).
• Run the Get-MgServiceAnnouncement cmdlet with the All parameter to fetch all available message center posts.
• The data returned for message center posts using the service communications Graph API differs from that returned by the old API. Some adjustment was necessary in the script to update property names and the content returned for some properties.
• Addition of some code to calculate the percentage of delayed feature announcements. In 2020, this was done using Excel. The basic test for a delay is the presence of the string “(Updated)” in the title for a message center post. No attempt is made to compute the length of the delay because message center posts don’t contain a structured property with this information. Instead, information about delays is conveyed in the text. For example, “We will begin rolling out in mid-September 2023 (previously late August) and expect completion by mid-February 2024 (previously late January).”

Comparing Results

In 2020, the results looked like this:

 		Notifications	Updates		Percent updated
Teams		58		22		37.93%
SharePoint	37		14		37.84%
Exchange	30		9		30%
Yammer		10		4		44.44%
Intune		8		0		—-
Power Apps	5		0		—-

On February 5, 2024, the Get-MgServiceAnnouncement cmdlet fetched 552 message center posts for my tenant. This is a higher amount than in 2020 because the tenant subscriptions now include some Microsoft 365 E5 licenses covering more apps. The number of message center posts available in a tenant vary depending on the active subscriptions that exist within the tenant.

Figure 1 shows the results. Nearly a third of all message center posts are delayed. Teams remains the workload that issues most message center posts (83), but its performance in terms of avoiding delays has worsened from 38.93% to 57.24% This might be due to the transition from the classic Teams client to the new Teams client (due to be complete by the end of March), or it might be that the Teams product managers have real difficulty in predicting when software might be ready for deployment.

Some message center posts cover multiple workloads and it’s hard to know where the responsibility lies for a delay. The data is therefore indicative rather than definitive. To be sure about where delays lie, you’d need to examine the text of each message center post and extract and collate the details.

You can download the updated script from GitHub.

Easier to Work with Message Center Posts

Being able to work with service communication data through Microsoft Graph PowerShell SDK cmdlets makes the information more accessible than before. Some of the improvements introduced by Microsoft for message center posts since 2020 aren’t available. The relevance property appears to have disappeared from the Microsoft 365 admin center and the number of active users for a workload, which does show up in the message center, is missing from the properties returned by the SDK cmdlet. But the rest of the information you might want is available and ready to be sliced and diced as you want.

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.

Graph-based Service Communications API is now the Route to Service Health Data

In January 2021, I wrote about how to use the Office 365 Service Communications API to programmatically retrieve the service health information that’s available in the Microsoft 365 admin center (Figure 1).

At the time, the API used the manage.office.com endpoint. In December 2021, Microsoft deprecated the manage.office.com endpoint and introduced the Service Communications Graph API as the replacement. In this article, I explain how to use the API with Microsoft Graph PowerShell SDK cmdlets to retrieve service health information.

Retrieving Service Health Data

As shown in Figure 1, the active items Microsoft is working on are those that impact the service in some way, usually by removing the ability of users to do something. To find these items, run the Get-MgServiceAnnouncementIssue cmdlet and filter for items classified as advisory with a status of ‘serviceDegration’:

[array]$ServiceHealthItems = Get-MgServiceAnnouncementIssue -All `
    -Filter "classification eq 'Advisory' and status eq 'serviceDegradation'" | `
    Sort-Object {$_.LastModifiedDateTime -as [datetime]} -Descending

$ServiceHealthItems | Format-Table Id, Title, FeatureGroup, LastModifiedDateTime

If you don’t filter the service health items, the Get-MgServiceAnnouncementIssue cmdlet, including those where Microsoft resolved the issue (as with many SDK cmdlets, the All switch tells the cmdlet to fetch everything). This data reveals the areas where most issues occur. In my tenant, the 346 available issues broke down as follows:

$Data = Get-MgServiceAnnouncementIssue -All
$Data | Group-Object FeatureGroup -Noelement | Sort-Object Count -Descending | Format-Table Name, Count -AutoSize

Name                                    Count
----                                    -----
Teams Components                           80
Administration                             39
E-Mail and calendar access                 27
SharePoint Features                        25
Portal                                     23
Management and Provisioning                22
Microsoft Defender for Endpoint            21
Cloud App Security                         13
Viva Engage                                10

Another interesting grouping is by service:

$Data | Group-Object Service -Noelement | Sort-Object Count -Descending | Format-Table Name, Count -AutoSize

Name                                      Count
----                                      -----
Microsoft Teams                              80
Microsoft 365 suite                          64
Exchange Online                              60
Microsoft Defender XDR                       32
SharePoint Online                            30
Microsoft Defender for Cloud Apps            25
Microsoft Viva                               12
OneDrive for Business                         8

The start date for the oldest issue was March 1, 2023. The oldest last modified date for an issue was July 31, 2023. This suggests that Microsoft might keep about six months of service issue data online. Your mileage might vary.

Fetching Overall Service Health Data

Underneath the advisory items, the Microsoft 365 admin center displays an overview showing the health for individual services like Exchange Online, Teams, SharePoint Online, and so on. This information is accessible by running the Get-MgServiceAnnouncementHealthOverview cmdlet. In my tenant, this generates a list of 32 individual services, some of which (like Sway and Microsoft Managed Desktop), I’m not interested in. I therefore amend the output by filtering the services that I consider most important:

[array]$ImportantServices = "Exchange", "Teams", "SharePoint", "OrgLiveID", "Planner", "microsoftteams", "O365Client", "OneDriveForBusiness"
[array]$ImportantServiceStatus = Get-MgServiceAnnouncementHealthOverview | Where-Object {$_.Id -in $ImportantServices}
$ImportantServiceStatus | Sort-Object Service | Format-Table Service, Status -AutoSize

Service            Status
-------            ------
Exchange Online    serviceDegradation
Microsoft 365 apps serviceOperational
Microsoft Entra    serviceOperational
Microsoft Teams    serviceDegradation
Planner            serviceOperational
SharePoint Online  serviceDegradation

Using Service Health Data to Highlight Current Advisories

Many people will be perfectly happy to access service health information via the Microsoft 365 admin center. The advantage of using an API to retrieve the same information is that you can then use it in whatever way you think appropriate. As a working example to demonstrate what’s possible, I wrote a script that can run interactively or as an Azure Automation runbook using a managed identity.

The script retrieves the open service health advisories and creates an email with an HTML-format report containing the service data that is sent to nominated recipients (any mixture of mail-enabled objects, including individual mailboxes, distribution lists, and Microsoft 365 groups). The idea is to keep the recipients updated about progress with open issues that Microsoft is working on. Figure 2 shows an example email generated using the service advisories published in my tenant.

After it’s extracted, the report can be disseminated in other ways. For instance, you could publish it as a Teams channel message.

You can download the script from GitHub.

Disrupted Change

Changing the details of an API is always disruptive. It’s not just the new endpoint. It’s also the way that the API returns data. Everything must be checked and verified. At least now the Service Communications API is part of the Microsoft Graph. As such, the level of change should be minimal in the future and we have the added benefit of PowerShell cmdlets to work with.

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.

Exploit Graph Usage Data Instead of PowerShell Cmdlets

The first report generated by Exchange administrators as they learn PowerShell is often a list of mailboxes. The second is usually a list of mailboxes and their sizes. A modern version of the code used to generate such a report is shown below.

Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Sort-Object DisplayName | Get-ExoMailboxStatistics | Format-Table DisplayName, ItemCount, TotalItemSize -AutoSize

I call the code “modern” because it used the REST-based cmdlets introduced in 2019. Many examples persist across the internet that use the older Get-Mailbox and Get-MailboxStatistics cmdlets.

Instead of piping the results of Get-ExoMailbox to Get-ExoMailboxStatistics, a variation creates an array of mailboxes and loops through the array to generate statistics for each mailbox.

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
Write-Host ("Processing {0} mailboxes..." -f $Mbx.count)

$OutputReport = [System.Collections.Generic.List[Object]]::new()

ForEach ($M in $Mbx) {
  $MbxStats = Get-ExoMailboxStatistics -Identity $M.ExternalDirectoryObjectId -Properties LastUserActionTime
  $DaysSinceActivity = (New-TimeSpan $MbxStats.LastUserActionTime).Days
  $ReportLine = [PSCustomObject]@{
    UPN               = $M.UserPrincipalName
    Name              = $M.DisplayName
    Items             = $MbxStats.ItemCount
    Size              = $MbxStats.TotalItemSize.Value.toString().Split("(")[0]
    LastActivity      = $MbxStats.LastUserActionTime
    DaysSinceActivity = $DaysSinceActivity
   } 
   $OutputReport.Add($ReportLine)
 }
$OutputReport | Format-Table Name, UPN, Items, Size, LastActivity

In both cases, the Get-ExoMailboxStatistics cmdlet fetches information about the number of items in a mailbox, their size, and the last recorded user interaction. There’s nothing wrong with this approach. It works (as it has since 2007) and generates the requested information. The only downside is that it’s slow to run Get-ExoMailboxStatistics for each mailbox. You won’t notice the problem in small tenants where a script only needs to process a couple of hundred mailboxes, but the performance penalty mounts as the number of mailboxes increases.

Graph Usage Data and Microsoft 365 Admin Center Reports

Microsoft 365 administrators are probably familiar with the Reports section of the Microsoft 365 admin center. A set of usage reports are available to help organizations understand how active their users are in different workloads, including email (Figure 1).

The basis of the usage reports is the Graph Reports API, including the email activity reports and mailbox usage reports through Graph API requests and Microsoft Graph PowerShell SDK cmdlets. Here are examples of fetching email activity and mailbox usage data with the SDK cmdlets. The specified period is 180 days, which is the maximum:

Get-MgReportEmailActivityUserDetail -Period 'D180' -Outfile EmailActivity.CSV
[array]$EmailActivityData = Import-CSV EmailActivity.CSV
Get-MgReportMailboxUsageDetail -Period 'D180' -Outfile MailboxUsage.CSV
[array]$MailboxUsage = Import-CSV MailboxUsage.CSV

I cover how to use Graph API requests in the Microsoft 365 user activity report. This is a script that builds up a composite picture of user activity across different workloads, including Exchange Online, SharePoint Online, OneDrive for Business, and Teams. One difference between the Graph API requests and the SDK cmdlets is that the cmdlets download data to a CSV file that must then be imported into an array before it can be used. The raw API requests can fetch data and populate an array in a single call. It’s just another of the little foibles of the Graph SDK.

The combination of email activity and mailbox usage allows us to replace calls to Get-ExoMailboxStatistics (or Get-MailboxStatistics, if you insist on using the older cmdlet). The basic idea is that the script fetches the usage data (as above) and references the arrays that hold the data to fetch the information about item count, mailbox size, etc.

You can download a full script demonstrating how to use the Graph usage data for mailbox statistics from GitHub.

User Data Obfuscation

To preserve user privacy, organizations can choose to obfuscate the data returned by the Graph and replace user-identifiable data with MD5 hashes. We obviously need non-obfuscated user data, so the script checks if the privacy setting is in force. If this is true, the script switches the setting to allow the retrieval of user data for the report.

$ObfuscatedReset = $False
If ((Get-MgBetaAdminReportSetting).DisplayConcealedNames -eq $True) {
    $Parameters = @{ displayConcealedNames = $False }
    Update-MgBetaAdminReportSetting -BodyParameter $Parameters
    $ObfuscatedReset = $True
}

At the end of the script, the setting is switched back to privacy mode.

Faster but Slightly Outdated

My tests (based on the Measure-Command cmdlet) indicate that it’s much faster to retrieve and use the email usage data instead of running Get-ExoMailboxStatistics. At times, it was four times faster to process a set of mailboxes. Your mileage might vary, but I suspect that replacing cmdlets that need to interact with mailboxes with lookups against arrays will always be faster. Unfortunately the technique is not available for Exchange Server because the Graph doesn’t store usage data for on-premises servers.

One downside is that the Graph usage data is always at least two days behind the current time. However, I don’t think that this will make much practical difference because it’s unlikely that there will be much variation in mailbox size over a couple of days.

The point is that old techniques developed to answer questions in the earliest days of PowerShell might not necessarily still be the best way to do something. New sources of information and different ways of accessing and using that data might deliver a better and faster outcome. Always stay curious!

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.

Microsoft 365 Backup for SharePoint, OneDrive, and Exchange

A year ago, Microsoft announced their intention to enter the backup market with a product to backup Exchange Online and SharePoint Online data. Roll on to Ignite 2023, and Microsoft announced that a paid public preview will begin later this year (probably in December after the U.S. Thanksgiving holiday period.) I expect general availability will follow in 2024. According to the SharePoint Premium announcement, the Microsoft 365 Archive product is now available.

The ISV Backup Conundrum

Backup solutions for Microsoft 365 is a market with many third-party (ISV) offerings. Backing up SharePoint Online sites and OneDrive for Business accounts (documents) and Exchange Online mailboxes are well-known challenges that ISVs know inside out. Microsoft’s decision to retire Exchange Web Service (EWS) in October 2026 complicates matters because many ISVs use EWS to read mailbox data. The replacement Graph APIs are not available yet.

However, Microsoft has made the APIs underpinning Microsoft 365 Backup available to ISVs. Microsoft always tries to line up a bunch of ISVs to support product announcements. It’s a way of proving to customers that the initiative is worthwhile. In this case, it was noticeable that many of the heavy hitters in the Microsoft 365 backup space are cited: Veeam, AvePoint, CommVault, Veritas, Rubrik, and Cohesity. However, that list is not exhaustive and doesn’t include other well-respected ISV backup vendors, like Quest and Keepit.

Some ISVs might have decided to wait for the APIs to mature before switching product direction or have concluded that their current solutions work well enough for now. It might also be the case that customers prefer not to put all their backup eggs into the Microsoft basket and want to maintain separate copies outside the Microsoft datacenter boundary. This isn’t possible using the Microsoft backup APIs.

Pay for Backup with an Azure Subscription

No matter if you use the Microsoft 365 Backup product or an ISV solution based on the Microsoft 365 Backup API, you still must have an Azure subscription to pay for processing backup data. According to the pricing information released by Microsoft, your subscription is charged $0.15 per month for every gigabyte or partial gigabyte processed (protected) by the service. The same price applies to Exchange Online, SharePoint Online, and OneDrive for Business content.

The public preview of Microsoft 365 Backup is a paid preview. If you want to kick the tires to see how backup (and more importantly, restore) works as smoothly and quickly as Microsoft predicts, you need an Azure subscription with a credit card that’s linked to Syntex pay-as-you-go. Linking an Azure subscription isn’t a difficult process as it literally takes a few clicks through the Setup section of the Microsoft 365 admin center (Figure 1).

Before starting, consider creating a new resource group to handle backup operations in your Azure subscription. It will make tracking costs easier. I created the “Backup” resource group for this purpose so it’ll be ready to go when I start to use Microsoft 365 backup.

Microsoft 365 Backup Not Yet a Complete Solution

It’s worth pointing out that Microsoft is starting with the easiest data to backup and that the more complex elements of Microsoft 365 are not included, like Teams, Planner, and Loop. Teams remains the most difficult Microsoft 365 app to backup because of the number of connections it has with other parts of the ecosystem and the lack of API support. Planner has never had a backup API, but it’s possible to read and write Planner data with Graph APIs (here’s an example of reporting Planner tasks for all plans in a tenant). The Loop app (now generally available) uses Syntex repository services to store its data. Although Syntex repository services is based on SharePoint Online, its data doesn’t show up as SharePoint Online sites, so I don’t believe that it is covered by Microsoft 365 backup. Loop components used in Teams channels, chats, and Outlook are stored in SharePoint Online and OneDrive for Business and are therefore covered.

Microsoft will doubtless grapple with and solve some or all of these challenges in the future to create a backup solution that can process the data generated by a complete Microsoft 365 tenant. The approach of keeping data within the tenant (but hidden and inaccessible unless needed for restore) offers many advantages, not least being speed of backup and especially restore operations. But we need more knowledge about how Microsoft 365 backup works in production before arriving at a measured conclusion. The paid preview should answer many questions.

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.

Use SDK Cmdlets to Add Properties to the Microsoft 365 User Profile Card

The Microsoft 365 profile card displays information about users. The information show in a profile card comes from the user’s Entra ID account. By default, Microsoft 365 limits the properties shown by the profile card to the set that they consider to be most important. Organizations can customize the Contact tab of the  profile card to reveal some of the properties that are not shown by default. However, not every property of an Entra ID user account is available for the profile card. Some, like the employee hire date, are not supported.

In 2020, I wrote about how to customize the profile card. At that time, the profile card API was in beta. The production Graph endpoint now supports the profile card API, and it’s also supported by cmdlets in the Microsoft Graph PowerShell SDK. I used version 2.9 of the SDK for this article.

The Microsoft documentation for customizing the profile card is a little outdated. At the time of writing, it uses V1.0 of the SDK and is based on the beta API. Because the API is now in production, it follows that the latest SDK cmdlets use that API. In any case, the instructions contained in the documentation are a reasonable guide.

Customized User Profile Card Available to All

The most important point about customizing the profile card is that any change is exposed to all users. You cannot customize the profile card for a subset of the user population such as a targeted administrative unit. This fact creates difficulties in multinational organizations where local privacy regulations might prevent the display of certain information held in user account properties.

As already mentioned, only certain user account properties are available for customization. Basically, you can add six standard properties:

• UserPrincipalName.
• Fax.
• StreetAddress.
• PostalCode.
• StateOrProvince.
• Alias.

Of course, including these properties in the profile card is useless unless information is populated in the directory for all user accounts. That often doesn’t happen.

The the fifteen custom attributes inherited from Exchange Server (different to the custom security attributes that can be defined for Entra ID) are also supported. Many organizations use these attributes to store information about users such as personnel numbers, cost centers, employee type, employee job codes, seniority level, and even the date of last promotion. Dynamic distribution lists and dynamic Microsoft 365 groups.

Add an Attribute to the Profile Card

To add one of the six standard or fifteen custom attributes to the profile card, construct a payload in a PowerShell hash table. The table contains the property name and its display name (annotation). Then run the New-MgAdminPeopleProfileCardProperty cmdlet passing the hash table as the body parameter (the same as passing a request body to a Graph request). This command adds CustomAttribute15 and tells Microsoft 365 that the user profile card should refer to the property as the “Employee Type.”

Connect-MgGraph -Scopes "PeopleSettings.ReadWrite.All","PeopleSettings.Read.All" -NoWelcome

$AddPropertyDetails = @{
  directoryPropertyName = "CustomAttribute15"
  annotations = @(
    @{ displayName = "Employee Type" }
  )
}

$AddPropertyDetails

Name                           Value
----                           -----
directoryPropertyName          CustomAttribute15
annotations                    {Employee Type}

New-MgAdminPeopleProfileCardProperty -BodyParameter $AddPropertyDetails

Id DirectoryPropertyName
-- ---------------------
   CustomAttribute15

It takes at least 24 hours before the profile card picks up customized properties. When they do, they appear on the Contact tab of the profile card. Figure 1 shows three custom properties for cost center, preferred drink (a historic part of the Active Directory schema), and employee type. If a custom properties doesn’t contain any information for a user, it won’t appear on the profile card.

To check the set of attributes added to the profile card with PowerShell, run the Get-MgAdminPeopleProfileCardProperty cmdlet. This output tells us that the profile card is configured to display three optional properties and three custom properties:

Get-MgAdminPeopleProfileCardProperty

Id DirectoryPropertyName
-- ---------------------
   userPrincipalName
   customAttribute12
   StreetAddress
   Postalcode
   CustomAttribute9
   CustomAttribute15

If you make a mistake, you can remove a property from the profile card by running the Remove-MgAdminPeopleProfileCardProperty cmdlet. For example, this command removes the Drink attribute (stored in CustomAttribute9) from the profile card:

Remove-MgAdminPeopleProfileCardProperty -ProfileCardPropertyId CustomAttribute9

Note that the profile card property id parameter is case sensitive. You must pass the property name as returned by the Get–MgAdminPeopleProfileCardProperty cmdlet.

Adding a Translated Label for a Custom Profile Card Property

The documentation makes a big thing about defining a language-specific value for a custom property. This is done using the Update-MgAdminPeopleProfileCardProperty cmdlet. This example shows how to add a French language label for CustomAtrribute15:

$LocalizationHash = @{}
$LocalizationHash.Add("languagetag","fr-FR")
$LocalizationHash.Add("displayName","Type d’employé")

$UpdatePropertyDetails = @{
   annotations = @(
    @{
    displayName = "Cost Center"
   localizations = @( $LocalizationHash )
     }
    )
}
Update-MgAdminPeopleProfileCardProperty -ProfileCardPropertyId 'customAttribute15' -BodyParameter $UpdatePropertyDetails

This command works, but it only works for a single language. If you want to have labels for multiple languages, you’ll be sadly disappointed because Update-MgAdminPeopleProfileCardProperty (and its Graph API counterpart) overwrite the language configuration each time.

You could argue that this is disappointing for multinational organizations that want to have fully-translated interfaces for all languages in use. Being restricted to a single language alternative is a strange approach to localization, especially for a company that does so much to deliver local language translations for user interfaces. The counterargument is that the properties chosen for display in the profile cards are likely to be well understood by anyone in an organization.

Work Still to Do

Not much has changed in customizing the profile card since 2020. The API is now production rather than beta and the Graph SDK supports the action, but that’s it. Coverage for multiple local language labels would be nice but that’s still elusive.

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.

MFCMAPI Exposes Data Stored by Microsoft 365 Apps in Exchange Online Mailboxes

I regularly use the MFCMAPI program to help understand the contents stored in Exchange Online mailboxes. When I mention this, people often look at me as if I have two heads. They have questions like what magic exists in MFCMAPI and how do I use the magic? That discussion could probably take hours, but let’s see if I can deliver a primer on how to get and use the program.

MFCMAPI Origins and Current Status

MFCMAPI originated as a program written by Microsoft escalation engineers to help debug Outlook desktop. This 2014 article explains some of the background. However, MFCMAPI was available several years beforehand, perhaps starting in 2008 or thereabouts. Since then, it’s been used for a variety of purposes (including creating Outlook profiles) and exporting mailbox data. You can also move or rename folders. However, modifying mailbox data with a low-level utility is not a recommended course of action because you could do serious damage to the mailbox.

I don’t think I have ever created anything with MFCMAPI; my use has always been to poke around the innards of a mailbox to discover what apps store there. In an on-premises environment, a mailbox stores email and some mailbox settings. But in the cloud, Exchange Online mailboxes are used by apps for a variety of purposes such as storing compliance records and Teams attendance records, mostly so that the data is indexed and becomes accessible to Search and services like eDiscovery. User mailboxes are a very convenient place for Microsoft 365 apps to store information and that’s why the program is so useful for administrators who want to understand how apps store data.

Today, Microsoft maintains MFCMAPI through a GitHub project. Stephen Griffin, one of the original brains behind MFCMAPI, still works on the code. You can download the latest release from GitHub. For instance, the latest 64-bit version is available in MFCMAPI.x64.exe.23.0.23089.01.zip.

Using MFCMAPI

MFCMAPI is only able to access user mailboxes, which it does through an Outlook profile. Before launching the program, go to Outlook desktop and make sure that the Outlook profile does not enable cached Exchange mode. If it does, MFCMAPI is limited to accessing synchronized folders and many of the more interesting server-based folders are inaccessible.

Now launch MFCMAPI and choose Logon from the Session menu. MFCMAPI displays a prompt to select the Outlook profile to use and then signs into your account using the information in the profile and lists the message stores available to the profile (Figure 1). Because MFCMAPI uses Outlook profiles for sign-ins, you can’t use the program to open anything other than user or shared mailboxes. This is logical because when the program started, objects like group mailboxes didn’t exist.

Although MFCMAPI lists public folders, you’ll see an error if you try and access them with the program.

Accessing Folders

Select the default store (marked with True in the Default Store column). This is your primary mailbox and double click to open the store. MFCMAPI opens a separate window positioned at the Root Container in the store. This is the root of everything in the mailbox – both the folders visible to users (IPM folders) and those never revealed by clients (non-IPM folders).

Click on Root Container to reveal the set of folders underneath. In Figure 2 you can see some of the folders contained in the mailbox. Three are highlighted:

• Recoverable items: This is where Exchange Online stores deleted items that users can still recover plus copies of items purged or altered when within the scope of a retention policy.
• TeamsMessagesData: This is where Teams stores its compliance records captured for personal and group chats involving the mailbox owner.
• Top of Information Store: This is where the IPM folders are located and you can see a couple of default mailbox folders (Calendar and Archive) plus a user-created folder (Amazon).

As a simple example of what MFCMAPI can reveal, double-click on the TeamsMessagesData folder. The program opens another window to list the items in the folder (Figure 3). Remember, this is a non-IPM folder, so users don’t know of its existence.

The lower pane shows the MAPI properties of the item like its creation date. Message items can have hundreds of properties, many of which are only understood by the generating app. In this instance, the text of the message sent in a Teams chat is available in the PR_HTML property (Figure 4).

The important thing here is that the compliance record is stored as a mailbox item. It is a partial version of the actual Teams message posted in the chat that caused the substrate to create the compliance item. These items exist to allow Microsoft Search to index the content of the chat and eDiscovery searches to find them when necessary.

Enough for a Primer

I think that’s enough for a primer on this topic. There’s lots more that can be done with MFCMAPI, but it serves a useful purpose even if you just use the program to understand what’s in Exchange Online mailboxes. Explore your own mailbox to see what you can find hidden behind the scenes. It can be very revealing!

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.

Block Meeting Chats for Non-Trusted Tenants

In July 2023, Microsoft introduced a new meeting policy setting to control the ability of users to participate in meeting chats for meetings hosted in other non-trusted Microsoft 365 tenants. The change addresses a potential issue where people might reveal confidential information in a meeting chat that their home tenant knows nothing about. Of course, users can also reveal confidential information orally and that information can be captured in a meeting transcript that’s under the control of the host tenant, but that’s a more difficult problem to crack.

The update is covered in message center notification MC561186 (26 May 2023) and Microsoft 365 roadmap item 123975 and the setting should now be available in all tenants, including DOD and GCC-High.

Trusted and Non-Trusted Tenants

A trusted Microsoft 365 tenant is one which the external access settings for Teams allow users to connect to for chats and meetings. By default, Teams allows external access to all other Microsoft 365 organizations (Figure 1), meaning that all other tenants are trusted.

Last year, a proof of concept for an attack called GIFshell exposed a downside in the default setting where an attacker could set up a chat with an unsuspecting victim and transmit a modified GIF file containing malware. The easy answer to stopping this kind of attack is to change the external access setting to restrict incoming connections to an allow list of specified tenants.

The need for ongoing maintenance is the downside of using an allow list. In a follow-up article, I discussed how to use PowerShell to populate an allow list based on the home tenants for guest accounts. This helps, but creating an allow list from guest accounts is unlikely to discover every external tenant that users need to communicate with for business purposes. Some other arrangement is therefore necessary to allow users to request the addition of a domain to the allow list. The Teams Approvals app might be one way to handle the issue. Power Automate might be another.

Blocking Access to Meeting Chat in Non-Trusted External Tenants

The new control is in the Meeting engagement section of Meeting policies in the Teams admin center (Figure 2). By default, the setting is enabled, meaning that users can participate in chats in meetings hosted by any external Microsoft 365 tenant.

Updating the setting to Off blocks the Chat app in meetings hosted by untrusted external tenants.

You can also manage the setting through PowerShell. First, to see the value of the AllowExternalNonTrustedMeetingChat setting in the meeting policies defined for the tenant, run the Get-CsTeamsMeetingPolicy cmdlet:

Get-CsTeamsMeetingPolicy | Format-Table identity, AllowExternalNonTrustedMeetingChat

Identity                           AllowExternalNonTrustedMeetingChat
--------                           ----------------------------------
Global                                                           True
Tag:AllOn                                                        True
Tag:RestrictedAnonymousAccess                                    True

To block access to chat in external meetings, run the Set-CsTeamsMeetingPolicy cmdlet to update the value of AllowExternalNonTrustedMeetingChat for a meeting policy.

Set-CsTeamsMeetingPolicy -Identity Global -AllowExternalNonTrustedMeetingChat $False

An hour or so after updating the meeting policy, the accounts assigned the policy will lose access to chat in external meetings hosted by non-trusted tenants.

Keep External Access Open or Apply Restrictions

If you’re not worried about what people might chat about in external meetings, leave the setting alone and Teams will behave as before. This control is for organizations that have reason to want to stop people from chatting when participating in meetings hosted by non-trusted tenants. Of course, the question of deciding which tenants to trust comes into play here. That’s a difficult question to answer in a generic sense, and it’s definitely worthwhile for a Microsoft 365 tenant to consider if they want to operate external access on an open or closed basis.

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

Control Group Creation to Avoid Group Sprawl

Microsoft’s documentation covering the topic of “Manage who can create Microsoft 365 Groups” begins with: “By default, all users can create Microsoft 365 groups. This is the recommended approach because it allows users to start collaborating without requiring assistance from IT.”

I can’t say how strongly I disagree with this perspective. All it does is result in group sprawl, or more likely, teams sprawl. We learned the lesson with Exchange Server public folders in 1996 when users created new folders with abandon. Organizations are still clearing up the mess today, which is one of the reasons for the persistence of public folders in Exchange Online. The same need will arise to clean up unused and unwanted teams if organizations follow Microsoft’s advice to allow group creation by any and all. Microsoft promised to develop functionality to help with group sprawl in 2021. So far, there’s little sign of progress in this space, unless you include the ownerless group policy (2022) and the group expiration policy (available since 2020).

Group Creation Using the Microsoft Graph PowerShell SDK

The Microsoft documentation explains how to restrict group creation by running PowerShell to configure the Entra ID groups policy. Unhappily, the current version of the documentation uses cmdlets from the Azure AD Preview module, which is due for deprecation in March 2024, The same work can be done using cmdlets from the Microsoft Graph PowerShell SDK, which is what I cover here.

The basic approach is:

• Create a security group to control group creation. The members of this group will be allowed to create new Microsoft 365 groups via user applications like Outlook and Teams. Accounts holding roles like Global administrator, Teams service administrator, Groups administrator, SharePoint administrator, User administrator, and Exchange administrator can always use administrative interfaces like PowerShell or the Microsoft 365 admin center to create new groups. The members of this group need Entra ID Premium P1 licenses.
• Update the Entra ID groups policy to block group creation by anyone except the members of the security group.

I have no idea why Microsoft doesn’t make control over Microsoft 365 group creation available through an option in the Microsoft 365 admin center. My cynical side says that this is because they don’t want tenants to control group creation, so they force administrators to use PowerShell.

Create a Security Group to Control Group Creation

A simple security group is sufficient to define the set of accounts allowed to create new Microsoft 365 groups (Figure 1). You can either create a new group or use an existing group. Creating a new group is probably best because you can give the group an appropriate name and description and be sure that the group will only be used to control group creation.

Create a Groups Policy Object

Microsoft 365 uses a directory setting object to hold the settings to control creation and other aspects of Microsoft 365 groups. By default, tenants use default settings. To change these settings, you must create a copy of the template directory settings object and modify it. Here’s how to create a new directory settings object by retrieving the identifier of the default object and creating a new object for the tenant:

Connect-MgGraph -Scopes Directory.ReadWrite.All
$PolicyId = (Get-MgBetaDirectorySettingTemplate | Where-Object {$_.DisplayName -eq "Group.Unified"}).Id 
New-MgBetaDirectorySetting -TemplateId $PolicyId

The New-MgBetaDirectorySetting cmdlet fails if a tenant-specific directory settings object already exists.

Updating the Groups Policy to Limit Creation

With a groups policy object in place, we can update the settings. You can see the default settings by running:

Get-MgBetaDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"} | ForEach Values

To control group creation, two settings are updated:

• EnableGroupCreation: This setting controls if users can create new groups. The default is true. We update it to false.
• GroupCreationAllowedGroupId: This setting holds the identifier for the group whose members are allowed to create new groups.

The setting names are case-sensitive and should be passed exactly as shown.

To update the settings, fetch the identifier for the group (or have it available). Then populate an array with the current settings before updating the two settings described above. Finally, update the directory settings object with the new policy settings. Here’s the code:

$GroupId = (Get-MgGroup -Filter "displayName eq 'GroupCreationEnabled'").Id
$TenantSettings = Get-MgBetaDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}
[array]$Values = $TenantSettings.Values
($Values | Where-Object Name -eq 'EnableGroupCreation').Value = "false"
($Values | Where-Object Name -eq 'GroupCreationAllowedGroupId').Value = $GroupId
Update-MgBetaDirectorySetting -DirectorySettingId $TenantSettings.Id -Values $Values

Figure 2 shows these commands being run.

Updating the group policy settings (for instance, to switch the group defining who can create new groups) uses the same approach: find values, update values, update the directory setting object.

If you make a mess of the Groups policy, you can start over by removing the directory settings object and creating a new policy. Here’s how to remove the policy:

$PolicyId = (Get-MgBetaDirectorySetting | Where-Object {$_.DisplayName -eq "Group.Unified"}).Id
Remove-MgBetaDirectorySetting -DirectorySettingId $PolicyId

Keeping Groups Under Control

Even if you decide to limit group creation, it’s a good idea to keep a close eye on what groups and teams are in active use and trim (or archive) those that don’t meet usage thresholds. The Teams and Groups activity report script can help with this process. Another point to consider is that Teams doesn’t come with any form of directory to allow users check if a team already exists for a topic. It’s possible to create such a directory, but making people check the list is a different challenge.

Another example of using directory objects to control groups is to block guest access for individual groups and teams. You can do this with sensitivity labels or by updating the directory setting for individual Microsoft 365 groups with PowerShell.

The Reasons for Disabled Accounts

Many reasons exist why organizations disable user accounts, including when employees go on sabbaticals, take time off due to illness, or have leave following childbirth. A less innocuous explanation is when employees are suspended for some reason. In all cases, accounts might remain in a disabled state for long periods.

Disabling an account means that Entra ID won’t let the user sign into their account. Data remains online and accessible for corporate purposes such as eDiscovery. Here’s how to disable an account using the Update-MgUser cmdlet from the Microsoft Graph PowerShell SDK:

Update-MgUser -UserId Andy.Ruth@office365itpros.com -AccountEnabled:$False

When the user returns, run Update-MgUser again to restore access by setting the AccountEnabled property to $True. To find the set of disabled accounts, run the Get-MgUser cmdlet like this:

Get-MgUser -Filter "accountEnabled eq false" -Property AccountEnabled, Id, DisplayName -All

Licensing of Disabled Accounts

Because accounts might be disabled for a long time, thoughts turn to the monthly license charges levied by Microsoft. If someone’s away for six months, should the organization pay for six months’ of charges. If the account has a Microsoft 365 E3 license and perhaps an add-on license (like SharePoint-Syntex advanced management) and a Teams calling plan, the costs could mount to $300 or thereabouts while the user is away.

One or two accounts incurring charges without use might not be a big deal. Interest about controlling license costs mounts as the number of disabled accounts mount. Twenty disabled accounts means $6,000 over six months. At that point, it might be worthwhile taking action to remove licenses from disabled accounts until their owners return to work.

Removing Exchange Online Licenses Leads to Disabled Mailboxes

Before rushing to remove all licenses from disabled accounts, let me sound a note of caution about removing products that include Exchange Online. An Exchange Online service plan is included in many Office 365 and Microsoft 365 products. For instance, Exchange Online Plan 2 (necessary for option such as archive mailboxes) is part of the Office 365 E3 and Office 365 E5 products. If you remove disable the Exchange Online service plan or remove the license for a product that includes Exchange Online from an account, the mailbox goes into a disabled state. One way to find mailboxes without licenses is to use the Get-EXOMailbox cmdlet to check if mailboxes have a valid SKU (product license):

Get-EXOMailbox -Filter {SkuAssigned -eq $True} | Format-Table DisplayName, UserPrincipalName, ExternalDirectoryObjectId

Exchange Online permanently removes disabled mailboxes after 30 days. To move from the disabled state, the owner’s account must be assigned a license that includes an Exchange Online service plan.

When removing licenses from disabled accounts, it’s important to check for Exchange Online to make sure that a removal doesn’t lead to potential data loss. Two options are available:

• Retain assigned licenses that include Exchange Online for disabled accounts.
• Replace the assigned license with a lower-cost license that includes Exchange Online. For example, you could assign inexpensive Office 365 E1 or F3 licenses to keep account mailboxes in a healthy state.

Exchange Online supports license stacking, meaning that it’s possible to assign multiple licenses to accounts that include an Exchange Online service plan. When this happens, Exchange Online uses the most functional plan.

Scripting License Removal

This article covers the basics of license management with the Microsoft Graph PowerShell SDK. The outline of a script to find and remove licenses from disabled accounts might include the following steps:

• Connect to the Graph.
• Define exclusions for licenses that should not be removed from accounts (those with Exchange Online).
• Find disabled accounts.
• Loop through each account to examine the assigned licenses and decide if any can be removed.
• Run the Set-MgUserLicense cmdlet to remove the licenses.
• Report the actions taken.

If an organization uses group-based licensing, Set-MgUserLicense cannot remove licenses assigned using this mechanism. Instead, the correct approach is to remove the account from the group used by Entra ID to control license assignments.

My version of a script to process license removals for disabled accounts can be downloaded from GitHub. It includes code to exclude licenses containing Exchange Online service plans. As mentioned earlier, the alternative is to replace licenses with a cheaper version. The code to do this would be simple to add. The script excludes licenses assigned through group-based licenses. Again, it would be easy to add code to remove accounts from the groups used to assign licenses. Figure 1 shows the script in action.

The Shared Mailbox Approach

Another way to handle the question of what to do with mailboxes belonging to long-term absentees is to turn them into shared mailboxes for the duration of their owner’s absence. When the owner returns, revert the shared mailbox to make it a regular mailbox again. This technique preserves the mailbox because shared mailboxes don’t need licenses. Here’s what you do:

1. Convert the mailbox into a shared mailbox.
2. Disable the account and change the password.
3. Remove all licenses.
4. (Optional) Hide the shared mailbox from Exchange address lists.
5. (Optional) Remove the shared mailbox from distribution lists so that mail doesn’t pile up in the mailbox during the owner’s absence.

When the user returns:

1. Convert the shared mailbox to a regular mailbox.
2. Enable the account and assign a new password.
3. Assign licenses to the account.
4. Unhide (if necessary) the mailbox.
5. Restore distribution list membership.

Check and Verify Before Use

Remember that the script illustrates the principles behind license removal for disabled accounts. It is not a production-ready solution. Like any code downloaded from the internet, you should verify and test the script and adapt it to meet your needs (especially because it removes licenses from accounts). The nice thing is that everything’s done in PowerShell, so please go ahead and modify the code as you wish.

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.

Bing Chat Enterprise and its Place in the Copilot Spectrum

Microsoft published message center notification MC649341 in late August to inform eligible customers (with Microsoft 365 E3 and E5; A3 and A5 (faculty only); and Business Standard and Business Premium licenses) that they had enabled Bing Chat Enterprise in preview for their tenants. On September 21, Bing Chat Enterprise then featured in the announcement of General Availability for Microsoft 365 Copilot, when Microsoft listed Bing Chat Enterprise as one of the commercial SKU (product) line-up for Microsoft Copilot (Figure 1).

Bing Chat Enterprise is available to the same Microsoft 365 product SKUs as Microsoft 365 Copilot is (Microsoft 365 E3 and E5, Microsoft 365 Business Standard and Premium). When formally available, other customers can buy a Bing Chat Enterprise license for $5/user/month.

I didn’t pay too much attention to Bing Chat Enterprise when Microsoft made their big announcement because the details about Microsoft 365 Copilot are more interesting. Since then we’ve learned that Microsoft will require eligible customers to buy a minimum of 300 Copilot licenses and that all transactions must be approved by Microsoft sales. In other words, a Microsoft partner can’t go ahead and order 300 licenses for one of their customers without approval. Although unpopular with partners, this restriction and the minimum purchase requirement are likely to be short-term measures to allow Microsoft to ramp-up support and other capabilities for Copilot but they might frustrate smaller organizations.

For instance, Microsoft 365 Business Premium is an eligible SKU for Copilot but it tops out at 300 users. The current rule means that a customer running Microsoft 365 Business Premium must buy Copilot for everyone in their organization (costing $108,000 annually). I guess many organizations will wait for the initial rush to work through Microsoft systems before considering a Copilot deployment.

Managing Bing Chat Enterprise

Which brings me back to Bing Chat Enterprise (BCE). While you’re waiting for the mists to clear around Microsoft 365 Copilot, BCE is a good tool to educate users about how to interact with generative AI. BCE is like the Microsoft 365 Chat app that comes with Copilot. The big difference is that Microsoft 365 Chat has access to user data stored in Microsoft 365 repositories like SharePoint Online, Exchange Online, and Teams. BCE must make do with whatever Bing Search can find. However, the same kind of interactive prompting to find and refine information happens.

Microsoft has deployed a Bing Chat Enterprise service plan to user accounts with eligible licenses. This action is described in message center notification MC665935 (updated September 11) and replaces the original tenant on/off switch previously deployed (MC677230) through an online page. Microsoft plans to remove the tenant on/off switch soon and base user access to BCE exclusively on the service plan from November 2023.

The advantage of using a service plan is that administrators can selectively enable or disable BCE for accounts by either editing accounts through the Microsoft 365 admin center or with PowerShell by removing service plan identifier 0d0c0d31-fae7-41f2-b909-eaf4d7f26dba from accounts using the Set-MgUserLicense cmdlet. For example, this command removes the BCE service plan from an account with a Microsoft 365 E5 license:

$DisabledServicePlan = @("0d0c0d31-fae7-41f2-b909-eaf4d7f26dba") 
Set-MgUserLicense -UserId Sean.Landy@Office365itpros.com -AddLicenses @{SkuId = "06ebc4ee-1bb5-47dd-8120-11324bc54e06"; DisabledPlans = $DisabledServicePlan} -RemoveLicenses @()

Learning from Bing Chat Enterprise

Learning how to prompt AI tools for answers is a key skill for users to acquire. Microsoft has a nice write-up on the subject where executives give examples of how they use Copilot and include the Copilot Lab to help users acquire knowledge about prompting. However, as we know from queries given to search engines, many never move past the simplest query, and if that happens with Copilot, there’s little chance that people will be satisfied with the results.

Interacting with BCE to find and refine answers to questions is good practice for Copilot. Sure, Copilot prompts will be different because they can reference documents and other items stored in Microsoft 365 and direct that the output should be in a specific form, like an email, but the principle behind conversational interrogation remains the same.

For example, I asked BCE to generate a PowerShell script to check that an account already had a specific license before attempting to assign the license. The first response used cmdlets from the now-deprecated and non-functioning Microsoft Online Services module. I asked BCE to try again, this time using cmdlets from the Microsoft Graph PowerShell SDK. Figure 2 shows the response.

The script code looks like it should work except that it won’t. The command to pipe a variable to the Update-MgUser cmdlet will fail horribly because the SDK does not currently support piping. It’s one of the SDK foibles that Microsoft is working on to fix.

AI can make things up (“hallucinations”), but in this instance BCE based its answer on Microsoft documentation and contributions to the well-respected and chock-full-of-knowledge StackOverflow site.

The learning for users is to never accept what AI produces without checking the generated answer first to be sure that it is correct and answers the original question, even if the cited sources seem impeccable. Maintaining a healthy level of scepticism about AI generated text is essential because it’s possible that someone would prompt Copilot for some information, see what looks like good information coming back, and email that information without thinking that it could be wrong, contain sensitive content, or is otherwise inappropriate to share.

Learning with AI

We’re at the start of what could be a transformational phase in how we deal with Office information. Good as the technology might be at the start, it’s going to take time for people to master driving AI to do the right things. Rubbish in equals rubbish out. AI just makes rubbish generation faster, if you allow it to happen.

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

No Good Reason why SharePoint Limits Administrator Access to Document Libraries

A reader asked if a programmatic method exists to set the default sensitivity label for a SharePoint Online document library. The simple answer is “yes,” because the only way initially available to set a default sensitivity label when the feature was in preview was to use the SharePoint REST API. Microsoft subsequently updated the SharePoint browser GUI to allow site owners to set a default sensitivity label for a document library.

Using the REST API still works, but my reader wanted something like a nice simple PowerShell cmdlet. Something like this would be nice:

Set-SpoSite -Identity $SiteURL -DocumentLibrary "Documents" -DefaultSensitivityLabel c29e68f9-bc4f-413b-a741-6db8e38ad1c6

The command would be nicer if you could pass the name of a sensitivity label, but the display names for sensitivity labels can be translated into multiple languages, which might cause some issues in multilingual tenants.

In any case, the Set-SPOSite cmdlet doesn’t support the functionality today and I haven’t heard of any plans to change in this area.

Reasonable to Allow Administrator Access to Some SharePoint Online User Data

I think it’s perfectly reasonable for SharePoint Online administrators to be able to update the default sensitivity labels for document libraries, especially because assigning a default sensitivity label incurs the requirement for Syntex-SharePoint advanced management licenses. An unwitting site owner could decide to assign a default sensitivity label to a document library (Figure 1) without realizing that the organization is now on the hook for some licenses, and that’s not a good thing. SharePoint administrators should be able to review, assign, and remove default sensitivity labels.

But this stance goes against the general approach Microsoft takes to SharePoint Online administration which holds that administrators can operate at the site level but cannot interact with objects within the site. Apparently, a site can have up to 255 document libraries, all of which are invisible to SharePoint administrators unless they’re a member of the site.

I understand the perspective that drives the approach. Administrators shouldn’t have access to user data. However, while Exchange Online administrators can see the folders inside user and shared mailboxes and Teams administrators can remove user data such as chat threads. It’s also possible for administrators to analyze and report the tasks in Planner plans. And sometimes even SharePoint Online administrators can take action with user data, like removing the sensitivity label for protected files using the Unlock-SPOSensitivityLabelEncryptedFile cmdlet. Inconsistency is rife across the Microsoft 365 workloads.

Greater Flexibility Required

I’m not advocating for SharePoint Online administrators to be able to open and examine documents and other files held in document libraries. The ability to report the contents of document libraries is already possible, albeit with some effort. What I would like to see is greater access to document library settings through PowerShell or a Graph API (which means that PowerShell support becomes available through the Microsoft Graph PowerShell SDK). For instance, why shouldn’t an administrator be able to do this to create a simple listing of all files found in the document libraries for a site:

$DocumentLibraries = Get-SpoSite -Identity $SiteUrl -DocumentLibraries
ForEach ($DL in $DocumentLibraries) {
   $Documents = Get-SPODocumentLibrary -Identity $DL 
   ForEach ($Doc in $Documents) {
    Write-Host (“Document found {0} in folder {1}” -f $Doc.Title, $Doc.Folder)
  }
}

SharePoint Online is not the center of its own universe as is the case with on-premises SharePoint Server. SharePoint Online is a highly capable document management service that’s consumed by other Microsoft 365 workloads. As such, its administrative capabilities should be on a par with other workloads, and that means greater flexibility and access to the settings for document libraries. Being able to report, configure, and remove the default sensitivity label for a document library is just the start.

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.

Users Can Sign Up for Sixty Day Teams Premium Trial License

Is MSCommerce (the “PowerShell Module for accessing Microsoft Commerce APIs”) the worse PowerShell module produced by Microsoft? The thought went through my mind when I loaded version 1.9 of the module (the latest available from the PowerShell gallery, updated a mere 25 days ago) to find that not only did the module not support PowerShell 7, but it barely worked on PowerShell 5.

Well, barely rates the module too highly. Yes, the cmdlets generate output, but it’s odd output that’s not pipeable and is barely usable. So MSCommerce 1.9 is a terrible module, which is why I deleted it and went back to version 1.8 to work with the Teams Premium Trial offer that Microsoft is keen to offer to end users. For the record, I used these commands:

Uninstall-Module Mscommerce
Install-Module Mscommerce -RequiredVersion 1.8 -Scope AllUsers

Teams Premium Trial

According to MC670435 (24 Aug 2023), in late September, end users in commercial tenants “will be able to initiate a self-service trial of Microsoft Teams Premium using their Azure Active Directory (AAD) credentials with no requirement to input payment information.” In other words, users can decide to kick the tires for Teams Premium for sixty days to see if it’s worth the $10 monthly fee (available for $7/month until December 31, 2023). These licenses are different to the 30-day trial licenses available for 25 users within a tenant.

Microsoft hopes that the trial will “generate signals on utilization for IT to identify users that would benefit from a Teams Premium license.”

Tenant administrators can terminate the trial licenses at any time (or remove them from user accounts). At the end of the sixty-day trial period, the organization can decide to drop the trial or move to a paid basis by buying some “real” Teams Premium licenses. More information about administration of self-service purchases is available in Microsoft documentation.

The Worth of Teams Premium

Microsoft announced Teams Premium at the Ignite 2022 conference. Annoyingly, Microsoft followed up the announcement by moving four features from Teams Standard to Teams Premium. In July 2023, Microsoft said that they had sold 600,000 Teams Premium licenses, which sounds a lot until you remember it’s only 0.2% of the 300 million Teams monthly active user base. Microsoft is obviously very keen to increase the $72 million annual run rate for Teams Premium to a much higher number, which is why trials are available.

I quite like some of the Teams Premium features, the best being intelligent recap of meetings. However, deciding if Teams Standard is sufficient for your day-to-day team collaboration or you need the extra boost delivered by Teams Premium is highly subjective.

Managing Self-Service Purchases

Microsoft started selling self-service purchases to end users with Power BI Premium in 2021. Since that time, it has steadily increased the number of available products, such as the Windows 365 plans. A more recent addition is the Python in Excel add-on, announced in MC669648 on August 22, 2023. Many organizations don’t want users do purchase software, and that’s where the MsCommerce module comes into play. If you want to stop users seeing a product, you must disable it in the MsCommerce inventory.

For example, to block purchases of the Teams Premium trial, import the module, connect to the MsCommerce endpoint and run the Get-MsCommerceProductPolicies cmdlet to find the Teams Premium trial. Then set the Enabled state to False. Here’s what I did:

Import-Module MsCommerce
Connect-MsCommerce

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Where-Object {$_.ProductName -eq "Teams Premium" }| ForEach {Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $_.ProductId -Enabled $False }
Update policy product success

ProductName   ProductId    PolicyId                 PolicyValue
-----------   ---------    --------                 -----------
Teams Premium CFQ7TTC0RM8K AllowSelfServicePurchase Disabled
Success

To list the full set of self-service products available to users and their current state, run this command:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase | Sort-Object ProductName

ProductName                                            ProductId    PolicyId                 PolicyValue
-----------                                            ---------    --------                 -----------
Dynamics 365 Marketing                                 CFQ7TTC0LH3N AllowSelfServicePurchase Enabled
Dynamics 365 Marketing Additional Application          CFQ7TTC0LHVK AllowSelfServicePurchase Enabled
Dynamics 365 Marketing Additional Non-Prod Application CFQ7TTC0LHWM AllowSelfServicePurchase Enabled
Dynamics 365 Marketing Attach                          CFQ7TTC0LHWP AllowSelfServicePurchase Enabled
Microsoft 365 F3                                       CFQ7TTC0LH05 AllowSelfServicePurchase Enabled
Power Apps per user                                    CFQ7TTC0LH2H AllowSelfServicePurchase Disabled
Power Automate per user                                CFQ7TTC0LH3L AllowSelfServicePurchase Disabled
Power Automate Per User with Attended RPA Plan         CFQ7TTC0LSGZ AllowSelfServicePurchase Enabled
Power Automate RPA                                     CFQ7TTC0KXG6 AllowSelfServicePurchase Disabled
Power BI Premium per user                              CFQ7TTC0H6RP AllowSelfServicePurchase Disabled
Power BI Pro                                           CFQ7TTC0H9MP AllowSelfServicePurchase Disabled
Project Plan 1                                         CFQ7TTC0HDB1 AllowSelfServicePurchase Disabled
Project Plan 3                                         CFQ7TTC0HDB0 AllowSelfServicePurchase Disabled
Python On Excel                                        CFQ7TTC0S3X1 AllowSelfServicePurchase Enabled
Teams Exploratory                                      CFQ7TTC0J1FV AllowSelfServicePurchase Enabled
Teams Premium                                          CFQ7TTC0RM8K AllowSelfServicePurchase Disabled
Visio Plan 1                                           CFQ7TTC0HD33 AllowSelfServicePurchase Disabled
Visio Plan 2                                           CFQ7TTC0HD32 AllowSelfServicePurchase Disabled
Viva Goals                                             CFQ7TTC0PW0V AllowSelfServicePurchase Enabled
Viva Learning                                          CFQ7TTC0HVZG AllowSelfServicePurchase Enabled
Windows 365 Business                                   CFQ7TTC0J203 AllowSelfServicePurchase Disabled
Windows 365 Business with Windows Hybrid Benefit       CFQ7TTC0HX99 AllowSelfServicePurchase Disabled
Windows 365 Enterprise                                 CFQ7TTC0HHS9 AllowSelfServicePurchase Disabled

Teams Premium Needs a Comprehensive Trial

If an organization is interested in Teams Premium, I recommend that you run a planned trial by selecting a department to test and assigning trial licenses to 25 people to use over 30 days. I don’t see much value in individual users getting trial licenses to test on their own. Teams is all about collaboration, and collaboration involves multiple people. Taking that logic further, it seems like the right approach is to test as a team and not as an individual.

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

Surprise Announcement Highlights Inconsistencies Across Microsoft 365 Consoles

Microsoft’s 17 August announcement that they are not proceeding with support for dark mode in the Teams admin center (TAC) came as a surprise. Originally announced in message center notification MC567496 (2 Jun 2023), I covered the news briefly on June 6 and pointed out that dark mode for TAC had some problems with custom tenant colors. This didn’t seem like a big issue at the time. It’s the kind of fit-and-finish bug that tends to be taken care of before final release.

I don’t know why Microsoft decided not to deliver dark mode for TAC. Microsoft’s announcement simply says “We have made the decision not to proceed with this feature at this time,” which could mean anything. What’s for sure is that the toggle to enable dark mode has disappeared and won’t come back until Microsoft decides what to do next.

The news about TAC got me thinking about why Microsoft doesn’t have a common platform for Microsoft 365 administrative consoles. Despite efforts to make the consoles look and feel similar, the interfaces have their own foibles.

Authorization and Tokens

Take authorization as an example. The admin consoles use modern authentication, so the consoles need to acquire OAuth 2.0 access tokens and renew the tokens when they expire. Making token renewal a seamless experience for administrators seems to be a very complex technical challenge for the console developers.

The Microsoft 365 admin center manages things best. Behind the scenes, the console takes care of token renewal without a hitch. I seldom experience issues with this console, even after keeping the admin center open for extended periods. The SharePoint Online admin center is also pretty good. Other consoles struggle to deliver an elegant solution to token refresh.

For example, the new-and-improved Exchange admin center flashes errors up when it discovers the need to renew an expired token. Flash is the operative word because an error message appears and disappears in the blink of an eye. However, it’s there and I know it’s there and I worry that something more problematic than a brief pause in token renewal is the root cause. It seems like an issue that is highly solvable.

The Microsoft Purview compliance portal takes a more pedantic stance and insists that administrators should sign in regularly (Figure 1). At least you know where you are and what to do to proceed, and an arguable case exists that the compliance portal gives access to solutions that protect confidential information. But the inconsistency in behavior is obvious and jarring.

Teams Admin Center

And then we come to the Teams admin center. This console is fond of launching and appearing to work as normal before suddenly deciding that it should sign out the connected user (Figure 2). This action forces the user to reauthenticate before they can connect to TAC. And it can force the user to sign in again to other Microsoft 365 apps.

I’ve complained to Microsoft about TAC’s odd connection procedure several times. Each time I’m told things will improve. And to be fair to Microsoft, the issue occurs much less frequently now than it did in the past. Perhaps recent changes to the TAC contained some new code to address the problem. But I don’t trust TAC because I’ve experienced the sign-out issue within the last few weeks. I’m now keeping a watching brief on TAC to see if the issue reappears and if so, whether I can identify specific circumstances that might provoke the sign-out.

Dark Mode Support Across Admin Consoles

With the decision made not to support dark mode for TAC, the situation is that two of the five main Microsoft 365 admin consoles support dark mode while three do not:

• Support dark mode: Microsoft 365 admin center (Figure 3), Exchange Online admin center.
• Do not support dark mode: Teams admin center, Microsoft Purview compliance portal, SharePoint Online admin center.

The inconsistent implementation of dark mode is only an indication of the lack of consistency which still exists across the Microsoft 365 admin consoles. It demonstrates that Microsoft still has work to do to make Microsoft 365 administration a unified space. And when they’re doing that, making access token renewal work the same way across all consoles would be a great thing to do.

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

Why Some Deleted User Accounts Store License Assignment Information And Some Do Not

A reader asks why the Microsoft 365 admin center displays a license for a deleted user account (Figure 1). The follow-up question is how they can remove the license and reassign it to another user.

The answer is that they don’t need to do anything. When an administrator removes a user account, Entra ID moves the account into its deleted items container (aka the wastebasket). The deleted account remains there for 30 days, during which time an administrator can restore the account (see the big blue button in Figure 1). The ideal situation is for a restored account to come back with all its settings intact, including assigned licenses. Entra ID tracks the licenses that the deleted account once had so that it can reassign the licenses to the newly-restored account.

Any licenses assigned to a deleted user account become available following the account’s deletion. This includes accounts used for shared mailboxes where assigned licenses exist to enable features like archiving. No one wants to keep expensive licenses on ice pending account restores, so often the licenses end up being assigned to other accounts.

It Depends on How User Accounts Are Deleted

The interesting thing is that the presence of assigned licenses for deleted accounts depends on the method used to delete the account. When an administrator deletes an account through the Microsoft 365 admin center, the process removes license assignments before removing the account, which means that if you examine the properties of the deleted account afterward, no licenses are present (Figure 2).

However, if you use PowerShell or the Microsoft Entra admin center to remove an account, the deleted account object retains license information. The licenses are not assigned, but the license information is present in the properties of the deleted user object. This is why Figure 1 shows that a deleted account has a license.

The reason why the Microsoft 365 admin center removes licenses and other administrative interfaces do not is due to the multi-phase process the Microsoft 365 admin center uses for account removal. The process includes steps such giving another user access to the user’s OneDrive for Business account (Figure 3) to allow for the recovery of any important information before the permanent removal of the user account.

PowerShell and the Microsoft Entra admin center only concern themselves with the removal of the user account object, and that’s why some deleted user accounts have license assignment information and others do not.

Care Needed When Restoring Deleted Accounts

The Microsoft 365 admin center user restore process warns administrators to:

• Assign licenses after restoring the account.
• Change the account password.

A user account has no access to Microsoft 365 services after it is restored until these steps are complete.

By comparison, if you restore a deleted account through the Microsoft Entra admin center or PowerShell, the license assignments noted in the account properties become active again. This can lead to an over-assignment condition where too many user accounts have licenses for specific products, like Office 365 E3. In this situation, administrators must buy additional licenses or remove licenses from other accounts (or delete other accounts).

To check if the properties of any deleted accounts include license assignments, you can run these Microsoft Graph PowerShell SDK commands to fetch details of deleted accounts and report if any license data exists:

Connect-MgGraph -Scope Directory.Read.All
[array]$DeletedUsers = Get-MgDirectoryDeletedItemAsUser -Property DeletedDateTime, Id, displayName, userPrincipalName, assignedlicenses | Sort-Object DeletedDateTime -Descending
ForEach ($User in $DeletedUsers) {
  If ($User.assignedLicenses) {
     $Licenses = $User | Select-Object -ExpandProperty assignedLicenses
     [string]$Skus = $Licenses.SkuID -Join ", "
     Write-Host ("Deleted user {0} has license information noted in their account properties {1}" -f $User.displayName, $Skus ) }
}

If you use PowerShell to script the recovery of user accounts, you should check for license assignments and validate that available licenses are available before recovering the account. This article explains how to fetch subscription information using the Get-MgSubscribedSku cmdlet and the subscriptions API, including the count of assigned and available licenses. It’s easy to check if a license for a SKU is available before assigning it to a recovered account.

Alternatively, go ahead and recover the account and fix the licensing problem later through the Microsoft 365 admin center.

Processing Differences Exist

This discussion reveals a difference in behavior between the raw processing performed by Graph APIs and the wrapper around the APIs implemented in the Microsoft 365 admin center. Sometimes the differences bubble up to the surface and the reasons for the differences aren’t immediately clear until you poke around to discover why things happen the way that they do. Isn’t that often the case in IT?

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.

More Details Revealed About Microsoft 365 Backup and Microsoft 365 Archive During Inspire session

A week or so after the launch of Microsoft 365 Backup and Microsoft 365 Archive at their annual Inspire conference (for partners), I took the time to listen to the recording of the session covering the topic delivered at the event. It’s hard to get much detail from a 14-minute session after filtering out all the marketing messages delivered by the avuncular Chris McNulty, but I found some interesting points to ponder.

As a reminder, these products are not yet available. They might be toward the end of 2023. Then again, product dates have an unfortunate habit of slipping, especially when they’re for solutions in a new area. This is doubly true when dealing with solutions targeted at backup and restore and touted as a great solution for ransomware because of their “unprecedented speed and scale.”

McNulty started with some statistics:

• Microsoft 365 users add two billion documents and emails daily. I assume this figure includes Office documents, PDFs, Loops, OneNote notebooks, emails, Teams messages, and everything else that can be stuffed into SharePoint Online, OneDrive for Business, and Exchange Online. In September 2022, Microsoft said that Exchange Online processes 9.2 billion messages daily, 2.4 billion of which are spam. However, it’s unclear if these figures include system messages that are transient and not stored.
• Microsoft 365 user activity consumes 200 petabytes of storage monthly. Much of the data is unstructured. I assume that imports from SharePoint Server and other non-Microsoft 365 sources consume some of this storage. While providing such a large amount of storage is a heavy expense for Microsoft, its existence inside Microsoft 365 creates opportunities. For instance, it is the raw material for Microsoft 365 Copilot.

Microsoft also said that the estimated annual cost of ransomware is $20 billion (2021). They also noted a 74% increase in password attacks in one year, which is yet another good reason for Microsoft 365 tenants to make better use of multi-factor authentication even if attacker tactics like password sprays are less effective due to the removal of basic authentication.

Microsoft 365 Backup

The basic value proposition for Microsoft 365 Backup is simple: the ability to backup and restore data more rapidly than any other backup solution. This is because the data remains within Microsoft 365 and therefore doesn’t have to be copied across an internet connection. Partners have access to the Microsoft APIs for backup, restore, and archiving to allow them to integrate Microsoft 365 in their solutions. In this context, Microsoft will take care of the background processing and the partner looks after the user interface and integration with backup and restore solutions that handle other non-Microsoft workloads to create a single pane for all backup and restore operations.

Of course, keeping backups of your SharePoint Online, OneDrive for Business, and Exchange Online data within the Microsoft trust (security) boundary is a double-edged sword. Keeping all your data eggs in the one Microsoft basket is convenient, enables fast restore, and easy to use because operations are integrated in the Microsoft 365 admin center.

Jacklynn Hiranaka’s demonstration of backup and restore showed how easy it is to configure full backup for a tenant (Figure 1). She made the point that once backup is enabled, it becomes effective immediately. This is likely because Microsoft can utilize techniques like capturing SharePoint changes in the Preservation Hold Library or Exchange changes in Recoverable Items to generate backup items. You can imagine how restores operate like a supercharged version of the SharePoint Restore this library feature or Exchange’s Recover deleted items.

Even more impressive was the assertion that Microsoft 365 Backup can perform parallel restores for SharePoint Online, OneDrive for Business, and Exchange Online to restore information very quickly.

Microsoft 365 Archive

Brad Gussin covered details of Microsoft 365 Archive. This is a SharePoint Online option (Exchange Online has its own archiving). You can already archive Teams and put the associated SharePoint Online sites into a read-only mode. Microsoft 365 Archive puts inactive SharePoint sites into a state where administrators can still manage the sites (to bring them back into an active state) but the data is no longer “hot” (available for immediate user access).

The major advantage gained by moving sites to an archived state is that the storage they consume is no longer charged against the tenant’s SharePoint storage quota. The data is still in SharePoint, but just like the storage consumed by Syntex Repository Services to hold Loop app data, it’s not accessible in the normal way.

Administrators will be able to search for inactive sites and decide which sites to archive. Site owners can protest this action and negotiate with administrators to keep their sites online. Once the final decision to archive, the process to archive sites takes a couple of hours. Actions to archive or reactivate sites are available through the SharePoint Online admin center (Figure 2) or PowerShell. Microsoft hasn’t specified how the PowerShell option will work, but it could be through an updated Set-SPOSite cmdlet or perhaps dedicated cmdlets to archive and reactivate sites. Long-term, Microsoft plans to enable finer granularity by supporting archival at the file level.

Microsoft 365 features such as data loss prevention, data lifecycle management (retention processing), information protection, and search remain in place for archived sites. eDiscovery can find items in archived sites (using the search indexes) and retrieve items using search exports.

A cynic might say that Microsoft created the need for an archive solution by restricting the amount of storage made available to tenants (1 TB plus 10 GB per eligible license) and the way that retention processing consumes quota. The more intelligent versioning planned for document libraries might help restrain storage consumption, but overall it’s still true that SharePoint Online storage is expensive when compared to the abundant storage made available to OneDrive for Business accounts.

No Pricing Available

Microsoft hasn’t revealed how much Microsoft 365 Backup and Microsoft Archive will cost. I’ve been surprised by some recent Microsoft pricing decisions (like the $7/user/month demanded for slightly more intelligent Entra ID access reviews). The good thing is that backup for Microsoft 365 is a competitive market. Microsoft has some strong advantages, but if it goes too far in terms of inflated pricing, customers will vote with their wallets and go elsewhere.

Learn about using SharePoint Online, 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.

Outlook Monarch Controls for the New Outlook for Windows

Updated 8 November 2023

With the disclosure that Microsoft 365 Copilot will only work with the Outlook Monarch client, organizations interested in Copilot deployments might need to reassess their plans for the “new Outlook for Windows,” currently available in preview.

Because Monarch is under active development, the set of features that it supports changes all the time. An assessment of the client software available last September isn’t a good basis for deciding how ready Monarch is today (this support page includes a non-exhaustive list of key Outlook features). Apart from adding features for Microsoft 365 users, work is also ongoing to make sure that Monarch can support email accounts for other mail servers.

In a related development, Message center notification MC590123 (updated 20 June) and a support article laid out Microsoft’s plan to use Monarch as the default email and calendar client for Windows 11. The kicker here is the statement that “After this change is implemented at the end of 2024, Users with a Microsoft 365 or Office 365 subscription with access to the Microsoft 365 desktop apps can use the new Outlook for Windows.” With their normal enthusiasm for new software, Microsoft will take every opportunity to make Monarch available to end users. Some would say that they will stuff Monarch down peoples’ throats, but that’s going a tad far for me.

Controls to Block or Allow Access to Outlook Monarch

With Microsoft accelerating its plans for Monarch, administrator thoughts invariably turn to the set of controls available to enable or disable the new client. Microsoft documentation covers this topic (and there’s some interesting information in the FAQ), but here are the essentials together with some PowerShell that you might find useful.

Monarch is based on OWA, so it should come as no surprise that it functions like OWA. For example, a setting is available to disable the client at the access level (what used to be the Client Access Server in on-premises servers). This command blocks access to Monarch for the Terry Hegarty mailbox (account):

Set-CASMailbox -Identity Terry.Hegarty -OneWinNativeOutlookEnabled $False

To disable or enable a set of mailboxes, use either the Get-ExoMailbox (to search against mailbox attributes) or Get-User (to search against Azure AD account attributes) cmdlets and pipe the results to Set-CASMailbox:

Get-User -Filter {Department -eq "IT"} -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Set-CasMailbox -OneWinNativeOutlookEnabled $False

To report the set of mailboxes enabled for Monarch, we can do something like this (unfortunately, Get-CASMailbox doesn’t support server-side filtering against OneWinNativeOutlookEnabled):

Get-CasMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Where-Object {$_.OneWinNativeOutlookEnabled -eq $True} | Format-Table DisplayName, OneWinNativeOutlookEnabled

An OWA mailbox policy setting is available to block users from adding third-party email accounts (like Gmail) to Monarch. This command updates an OWA mailbox policy to disable personal accounts. The policy is effective with Monarch builds post 30 June. To block personal accounts, the Outlook profile must be first configured with an enterprise account with an Exchange Online mailbox. If not, blocks placed by Exchange Online OWA policies are ineffective.

Set-OwaMailboxPolicy -Identity OWAMailboxPolicy-Default -PersonalAccountsEnabled $False 

And to report the set of mailboxes to which the OWA mailbox policy applies, run:

Get-CASMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Where-Object {$_.OWAMailboxPolicy -eq "OwaMailboxPolicy-Default"}

Turning Off the “Try the New Outlook” Toggle

Recent Outlook for Windows builds include a toggle to allow users to switch to Monarch (Figure 1). If you’re not going to allow people use Monarch, it’s a good idea to remove the tempting toggle.

To hide the toggle, add a new DWORD value in the system registry called HideNewOutlookToggle at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General and set it to 1 (Figure 2). The next time Outlook restarts, the toggle is gone.

The change can also be made in a GPO using ADMX build 16.0.5401.1000 or later. The setting is “Hide the “Try the new Outlook” toggle in Outlook,” which sets HideNewOutlookToggle at HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\Options\General to either 0 or 1, depending on if the toggle is on or off. Publishing the change via a GPO might take a little time before the client responds and disables the toggle.

Removing Monarch

Because the Monarch client is fully supported for personal accounts, users might receive it as a preinstalled app on a new device or they might download the client from the Windows Store. To remove the app from a Windows image so that Windows does not install the app for new user accounts, you can remove the Outlook Monarch app package by running the Remove-AppxProvisionedPackage cmdlet. According to instructions given in MC676298 (22 September 2023), the command to remove the Monarch package is:

Remove-AppxProvisionedPackage -Path c:\offline -PackageName OutlookforWindows

To remove a previously-installed app, run the Remove-AppxPackage cmdlet.

Reporting Outlook Client Usage

Currently the Email Apps report in the usage reports section of the Microsoft 365 admin center doesn’t separate Monarch out from OWA when it identifies the different Microsoft clients that connect to Exchange Online (Figure 3). Hopefully, Microsoft can update the report to highlight people who use Monarch.

Monarch’s Coming. Are You Ready?

It seems like Microsoft has been on the journey to deliver the new Outlook for Windows forever. But let’s face it, replacing a client that’s been in use since 1997 is difficult to say the least. Code developed over decades can’t be replaced without huge engineering effort, especially when the desired outcome is a common Outlook code base that will work on multiple platforms and support faster innovation.

OWA introduces new functionality much faster than the legacy Outlook for Windows does. That’s not the fault of the older Outlook client. It is handicapped by decades of building features one step at a time. The new Outlook for Windows will eventually be a good replacement. The question is just when that time will be. In the meantime, some Outlook Monarch controls are a good thing to have.

Not Much Changes in Exchange Mobile Device Management

It’s been a while since I wrote about how to extract details of mobile devices registered with Exchange Online mailboxes. Time marches on and it’s time to take another look at how to generate a report about mobile devices used with Exchange Online, not least because there are upgraded versions of some cmdlets to use, like Get-ExoMailbox and Get-ExoMobileDeviceStatistics that didn’t arrive until late 2019.

Device management in Exchange Online goes back to on-premises management for mobile devices connected to Exchange Server via Exchange ActiveSync. Apart from making sure that everything works, Microsoft hasn’t done much to device management in Exchange Online. Most of the development activity has focused on leveraging synchronization of Outlook mobile clients with Exchange Online using the Azure-based architecture introduced in 2018 to introduce new functionality, like support for sensitivity labels.

The way Exchange ActiveSync management works hasn’t change much. A glance at the device access rules (which control what devices a tenant allows to connect) in the Exchange admin center (Figure 1) reveals entries like Acompli (the company Microsoft acquired to get Outlook mobile), Windows Phone, iOS 6, and so on. The advantage of this poor man’s mobile device management system is its simplicity. Even as Microsoft advanced to the final deprecation of the old Exchange admin center, not an iota of new functionality appeared in mobile device management.

The subtle hint here is that mobile device management is better done in a purpose-built device management framework like Intune. And so you should, if you feel the need.

Reporting Mobile Device Status

Getting back to reporting the set of devices registered for Exchange mobile device management, the code to do the job is straightforward:

First, find the set of user mailboxes.

[array]$Mbx = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox | Sort-Object DisplayName
If (!($Mbx)) { Write-Host "Unable to find any user mailboxes..." ; break }

For each mailbox, check if it has any registered mobile devices with a command like this:

[array]$Devices = Get-MobileDevice -Mailbox $M.DistinguishedName

If some registered devices exist (the devices might be very old), use Get-ExoMobileDeviceStatistics to fetch information about the synchronization status of each device.

You see here that I use the distinguished name of a device to fetch its statistics. According to the cmdlet documentation, the identity parameter accepts the device Guid or identifier. I think this is a documentation error because:

• Guid works, but it’s slow.
• DeviceId returns a “cannot be found” error.
• DistinguishedName is fastest (up to ten times faster than Guid).

Which means that we do this:

$DeviceStats = Get-ExoMobileDeviceStatistics -Identity $Device.DistinguishedName

Parse the information returned by Exchange mobile device management to extract whatever seems interesting. For example:

• Operating system installed on the device.
• First date of synchronization.
• Last successful synchronization.
• Device policy applied to device.
• Last time Exchange applied a policy to the device.

An example script to generate the report about devices synchronizing with Exchange Online is available from GitHub. The script creates a HTML report (Figure 2) and a CSV file containing its output. Feel free to modify the script as you wish!

Removing Obsolete Devices

Mobile device statistics allow the identification of devices that are not synchronizing. Any device that doesn’t synchronize in 30 days is likely no longer in active use and becomes a candidate for removal (after someone checks its actual status). When their obsolete status is confirmed, you can remove devices by running the Remove-MobileDevice cmdlet. Running the cmdlet breaks the partnership (link) between the mailbox and device.

For instance, this code finds devices reported with more than 365 days since their last synchronization and deletes the first device from the returned set.

[array]$SyncDevices365 = $Report | Where-Object {$_.DaysSinceLastSync -gt 365}
Remove-MobileDevice -Identity $SyncDevices365[0].DeviceDN -Confirm:$False

No Prospect for Change

At this point, it’s hard to see that Microsoft will make any dramatic change to the Exchange device management framework. What exists now suffices for small to medium businesses, and anyone who needs something more sophisticated should head to Intune or check out third-party mobile device management solutions.

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.

Targeted Release for Office 365

Targeted release is the mechanism used by Microsoft to make new features available to tenants a short time (normally four to six weeks) before general deployment (standard availability begins). Tenants can choose to use targeted release for all users or selected users via Release preferences under Org settings in the Microsoft 365 admin center (Figure 1).

On May 25, Microsoft announced that Teams will support targeted release for Microsoft 365 tenants. This step aligns Teams with the other major Microsoft 365 workloads which support targeted release (SharePoint Online and Exchange Online). The change applies to commercial cloud clients only. Tenants in other clouds, like GCC, will have to wait to see if Microsoft brings the change to their clouds.

Examples of important Teams features currently available to targeted release include the preview of the Teams 2.1 client and the new channels experience. Targeted release applies to the desktop and browser versions of the Teams clients (including Surface Hub). It has no impact on Teams mobile.

Supporting targeted release is a sensible change because the way Microsoft released Teams updates in the past was a tad chaotic in times. It’s reasonably common to see complaints surface in Twitter and the Microsoft Technical Community that an announced feature hasn’t turned up in some tenants several months after Microsoft highlights something in a blog post or a roadmap item says that a feature is rolling out.

The Teams preview program worked for some features and not others. To throw some more uncertainty into the mix, Microsoft changed the “P” (“preview”) indicator to “EA” (for early access) earlier this year, without explaining what was happening.

Early Teams in Many Forms

The kicker is that complexity still exists in the system. Microsoft says that:

Tenants wanting consistency in the availability of Teams features alongside the rest of Office 365 should use targeted release. Unless you’re only interested in new Teams features, in which case you should use the Teams preview program. Targeted release takes precedence over the Teams preview program when it comes to feature availability.

But if you want consistency between Teams and Office (Microsoft 365 apps for enterprise), use the Office Current Channel (preview).

Finally, if organizations want to live on the bleeding edge of technology to see new Teams features as early as possible, they can seek nomination to the Teams Technology Adoption Program (TAP) and experience the joys of chasing early bugs. However, Microsoft says that the Teams TAP is currently at capacity.

Given the size of Microsoft 365, different kinds of tenants, and the number of active users in the Teams installed base, it’s almost inevitable that software will appear immediately in some places and trickle out to others. Let’s hope that supporting targeted release will make Teams feature availability more predictable for all.

Teams Free Takes Over from Teams Chat

Also in the world of Teams, the Microsoft blog to announce the availability of Windows 11 Insider Build 23481 says that Windows 11 has replaced the Teams chat app with the Teams Free (aka Teams for Home) app.

This change makes perfect sense. The original Teams chat app was the first iteration of the Teams 2.1 client, albeit with very reduced functionality compared to the full client. It served its purpose as a replacement chat client, but Microsoft hardly wanted to keep it around for the long term. Every client variant creates more demand for engineering resources, so swapping in the Teams Free client is a reasonable strategy.

I doubt that many Windows users will notice the difference. The sad fact is that although Teams is successful in the corporate environment, it’s barely made a dent in the domination of apps like WhatsApp and Facebook Messenger when it comes to personal usage. Teams Free is a more functional app for Windows 11 users, but it’s hardly likely to move the needle in terms of attracting millions of new users.

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.

A New Microsoft 365 Audit Platform Service Plan, App Governance, and Fetching Service Principal Sign-in Information

Service principals are one of the fundamental underpinnings of application interaction with Entra ID (Azure AD). One way of thinking about service principals is that they’re a convenient container for holding the permissions granted to applications. This applies both to the set of applications registered by a tenant and enterprise applications created by a publisher like Microsoft or Apple and intended for use in many Microsoft 365 tenants.

Which brings me to MC549532 (Last updated Jun 9, 2023), announcing that Microsoft is adding a new Microsoft 365 Audit Platform service plan and adding the new service plan to accounts licensed to use the app governance add-on for Microsoft Defender for Cloud Apps (like accounts with Office 365 E5 licenses). The idea behind app governance is that it gives administrators better insight into the set of apps within the tenant. The original implementation in 2021 wasn’t great, but app governance is more comprehensive and useful now.

App Governance

Knowing what apps are present and the permissions held by the apps is important. Attackers like to plant OAuth apps in compromised tenant and use the apps to access data (here’s an example of an attack on Exchange Online). Reviewing the information available in app governance is helpful, but only if administrators take the time to look through the data and have sufficient knowledge about the apps in the tenant to know when something isn’t quite right.

App governance (Figure 1) includes app policies with “machine learning-based detection algorithms” to search for odd conditions within the tenant that can indicate the existence of an app that isn’t quite right. A set of predefined policies deliver immediate insight into the state of the tenant. If that coverage isn’t sufficient, administrators can tailor custom policies to address specific requirements.

Of course, not every tenant has Office 365 E5 or above licenses. If you’re in this situation, you can create your own automated checks (like this one using PowerShell running in Azure Automation) to look for anomalous conditions and report back to administrators.

Understanding Service Principal Sign-In Activity

The point is that tools exist to help organizations understand what’s happening within their Microsoft 365 tenant. The data is there if you go looking for it. For example, the Graph API (beta) includes a servicePrincipalSignInActivity resource. This is interesting because it allows tenants to know the last time apps use service principals to sign in. If an app isn’t being used, it becomes a candidate for removal unless a good case exists for its retention.

It’s easy to use the List servicePrincipalSignInActivities API to fetch sign-in activity information for service principals. The information returned is in a series of hash tables (one per service principal), so a little effort is necessary to parse the content of the hash tables and make them human-friendly.

Here’s a PowerShell script to:

• Connect to the Microsoft Graph PowerShell SDK with the AuditLog.Read.All scope (permission) needed to access audit data.
• Select the beta endpoint.
• Use the Invoke-MgGraphRequest cmdlet to fetch the sign in information for service principals.
• For each record, fetch some information about the service principal (display name, publisher, and creation date) and extract the last sign in date and time for both application and delegate access.
• Capture the information in a PowerShell list.

Connect-MgGraph -Scopes AuditLog.Read.All
Select-MgProfile Beta

[array]$AuditData = Invoke-MgGraphRequest -Method GET -Uri "https://graph.microsoft.com/beta/reports/servicePrincipalSignInActivities"
If (!($AuditData)) { Write-Host "Error fetching service principal sign in activity data..." ; break }

$AuditData = $AuditData.Value
$Report = [System.Collections.Generic.List[Object]]::new() 

ForEach ($SP in $AuditData) {
   $SpAppId = $SP['appId']
   $ServicePrincipal = Get-MgServicePrincipal -Filter "Appid eq '$SpAppId'"
   $SPName = $ServicePrincipal.DisplayName
   If ($SPName) {
      $SPCreatedDate =  Get-Date($ServicePrincipal.additionalProperties.createdDateTime) -format g
   } Else {
      $SPCreatedDate = $Null }

   $ReportLine = [PSCustomObject]@{
      AppId                   = $SP['appId']
      'Display name'          = $ServicePrincipal.DisplayName
      Publisher               = $ServicePrincipal.PublisherName
      'Sign in audience'      = $ServicePrincipal.SignInAudience
      'Last sign in'          = $SP['lastSignInActivity'].lastSignInDateTime
      'Last app sign in'      = $SP['applicationAuthenticationClientSignInActivity'].lastSignInDateTime
      'Last delegate sign in' = $SP['delegatedClientSignInActivity'].lastSignInDateTime
     }
   $Report.Add($ReportLine) 
}

# Filter out the records that can't be resolved against service principals in the tenant
$ReportSPs = $Report | Where-Object {$Null -ne $_.'Display name'}
$ReportSPs | Out-GridView

When I ran the script in my tenant, Entra ID responded with sign-in information for 347 application identifiers. However, many of these application identifiers could not be resolved in the tenant. I suspect that some belong to deleted apps and some are owned by Microsoft internal processes. I’m following up on this point. To clean things up, I create an array of service principals with complete information, shown using the Out-GridView cmdlet in Figure 2.

The list includes many Microsoft apps (not all stamped with a publisher name), some tenant apps, and some apps from other sources like idPowerToys.

The Persistence of the iOS Accounts App

We also see the iOS Accounts app from Apple used to reset iOS devices with modern authentication during the deprecation of basic authentication for Exchange Online last year. On the surface, that app is a candidate for removal because none of the iOS devices in the tenant need reconfiguration to work with Exchange Online, but I see a last sign-in date of 11 June 2023 at 20:46. That’s a delegate access, implying that a user invoked the app in some way. Maybe iOS is still checking to be sure that basic authentication is dead and gone. That’s yet another thing to follow up.

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.

Use Remove-CalendarEvents to Cancel Teams or Regular Meetings Owned By a Specific User

The question arose about how an administrator can cancel Teams meetings scheduled by a user who is currently unavailable. Because cancelling meetings on behalf of a user is not a day-to-day administrative operation, no option is available for this purpose in the Teams admin center or the Microsoft 365 admin center. However, the Remove-CalendarEvents cmdlet in the Exchange Online management module will do the job (the cmdlet is also available for Exchange 2019).

Normally, administrators don’t interfere with meeting arrangements. Those who create meetings (the organizers) take care of scheduling and maintaining meeting settings, whether they own the calendar or are a calendar delegate. Reasons why an administrator might intervene include:

• The organizer is unavailable for a sustained period and the need exists to rearrange the meeting.
• The organizer has left the company.
• The organizer is due to leave the company and part of the offboarding process involves cancellation of all their future meetings.

Mailbox Access Required

In all cases, Remove-CalendarEvents can only work if access is still available to the user’s mailbox. Exchange Online must be able to connect to the mailbox to access the organizer’s calendar to remove events. For this reason, if you plan to cancel a user’s meetings when they leave the company, the correct procedure is:

• Sign in as with an account holding the Exchange administrator or global administrator role.
• Revoke access to their account.
• Run Remove-CalendarEvents to cancel all future meetings in the user’s mailbox where they are the meeting organizer and the meeting has one or more attendees (including resources like meeting rooms). Cancellations cover both normal meetings and online meetings (using Teams or another online provider). Events without attendees (appointments) are left untouched. The mailbox sends meeting cancelations to meeting participants.
• Proceed with the remainder of the account removal process. If holds exist on the mailbox, it becomes inactive. However, you can’t cancel meetings from an inactive mailbox. If you forget to cancel meetings, restore the inactive mailbox, cancel the meetings, and then delete the mailbox again.

Running Remove-CalendarEvents

The Remove-CalendarEvents cmdlet can cancel meetings up to 1825 days (five years) in the future, which should be more than sufficient in most cases. You can perform a test run beforehand to see what meetings it will remove by including the PreviewOnly parameter. For example, this command previews what will happen if the cmdlet removes meetings from the current date up to 365 days in the future:

Remove-CalendarEvents –Identity chris.bishop@office365itpros.com -CancelOrganizedMeetings -QueryStartDate (Get-Date) -QueryWindowInDays 365 -PreviewOnly

Confirm
Are you sure you want to perform this action?
The meeting(s) will be canceled and removed from the calendar. This action cannot be undone.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
The meeting with subject "Glastonbury Meeting" and start date "09/06/2023" has been queued for cancellation.
The meeting with subject "Project X" and start date "09/06/2023" has been queued for cancellation.
The meeting with subject "Project Mercury" and start date "17/06/2023" has been queued for cancellation.
The meeting with subject "Project Botha" and start date "21/06/2023" has been queued for cancellation.
The meeting with subject "Project Botha" and start date "28/06/2023" has been queued for cancellation.

When ready to proceed, remove the PreviewOnly parameter and run the command again. Exchange Online connects to the mailbox, finds the relevant meetings, and cancels them.  Cancellation occurs immediately. Meeting participants receive a cancellation notice as normal (Figure 1).

Graph Delete Event API

If you need a programmatic method to remove calendar events, the Graph includes a Delete Event API. An app with the Calendars.ReadWrite application permission can connect to a mailbox, find relevant events in the calendar, and delete them.

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.

Edge is the Default Browser for Side-by-Side Viewing

Quite a backlash ensued when Microsoft announced that Outlook would open embedded links in email using the Edge browser instead of the system default browser (Figure 1). Apparently, this allows people to “stay in your flow” because side-by-side viewing allows the user to read and respond to the message with the link open, According to Microsoft, Outlook for Windows supports side-by-side viewing from build 16.0.16227.20280. I’m using build 16.0.6505.20002 on one PC and build 16.0.16501.20098 on another and don’t see the functionality in either. Some bits must still be en route.

Message center notification MC531738 (last updated 20 April 2023) describes an associated change for Outlook Mobile clients where the client will prompt users to choose between Edge and the system browser to open links. Microsoft says that these arrangements improve the user experience and has nothing whatsoever to do with their desire to drive increased usage for Edge.

Being able to open a web link in a seamless way makes a lot of sense and is a useful development. Microsoft caused the problem by presenting the feature as an Edge exclusive instead of saying that people could use other browsers. Microsoft plans to implement side-by-side viewing for “other Microsoft 365 apps” with Teams lined up to implement the feature next (presumably in both the classic and the preview of the new Teams 2.1 client).

Configure Cloud Policy for Browser Selection

The good news is that Microsoft documentation is available to instruct Microsoft 365 tenant administrators how to configure the browser used for side-by-side viewing. All that’s required is a change to the Microsoft 365 cloud policy assigned to users.

Head to the Microsoft 365 apps admin center and choose Go to Microsoft 365 cloud policy. This reveals the set of policies defined in the tenant. Select the policy to update. Make sure that the policy has the correct scope (the set of users it applies to) and move on to the policy settings. Search for the “Choose which browser opens web links” setting (Figure 2) and then select either Edge or the default system browser (set by the user). Remember to apply the setting and save the policy.

The big thing to remember is that if you don’t update the cloud policy, the default for Microsoft 365 apps is to use Edge. In other words, take action to update the policy or don’t complain afterward when Outlook wants to call Edge to display web pages.

The documentation also explains how to deploy the setting using Microsoft 365 administrative templates.

User-Driven Choice

Microsoft says that users will have an option to configure Outlook desktop settings to choose their preferred browser there (File > Options > Advanced > Link Handling). Teams respects the choice a user makes in Outlook. If an organization deploys policy settings to control the feature, the option to select a browser is grayed out in Outlook. I don’t see the option in either version of Outlook desktop I use.

The client-side option exists not only to allow choice for users in Microsoft 365 tenants but also to serve people with Microsoft 365 Personal or Family subscriptions where facilities like cloud policy management aren’t available. In addition, those using Microsoft 365 for business plans can only use the cloud management policy when it supports side-by-side viewing in Teams. Microsoft’s documentation for for the Family and Personal subscriptions says that Outlook only tries to use Edge on Windows 10 and Windows 11 PCs.

Poor Communications Get in the Way of a Good Idea

In summary, side-by-side viewing is a good idea that Microsoft mishandled in terms of communications. The controls to allow organizations to exert choice over the browser used in side-by-side viewing are available, and users can make their own choice if an organization policy is unavailable. If Microsoft had said that when they introduced the concept instead of focusing on Edge, no one would have been concerned and fuss and bother avoided.

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.

Organization Messages Serve a Single Purpose – Drive Microsoft 365 Adoption

Last month, I covered Microsoft’s unfortunate choice to begin running in-product ads in SharePoint Online. The ads highlighted the joys of attending the Microsoft 365 conference in Las Vegas at the start of May. Publicizing this conference was a reasonable choice given the heavy Microsoft sponsorship for the event and the line of Microsoft speakers from the SharePoint development group on the schedule, led by Jeff Teper.

Microsoft’s support for the conference wasn’t the point. The argument raged about the ethics of Microsoft running in-product ads directed at end users who would never attend such an event in software paid for by customer organizations. The tactic might be appropriate for no-charge consumer software; it’s not when you pay to consume a service. If you agree with this position, please consider upvoting the feature request to quash in-product ads.

Microsoft 365 Organization Messages

Enter organization messages, available through the Adoption Score (under Reports) section of the Microsoft 365 admin center, which seems to be an analogous technology. This time the messaging is under the control of the tenant, which is how it should be. The advent of organization messages for Microsoft 365 Office apps shouldn’t come as a surprise because Microsoft launched organization messages for Windows 11 (Intune) in preview in November 2022. That project continues, albeit still in preview. All these efforts have the same goal: send messages to end users as they work to prompt them to do something.

Organization messages are currently available to encourage people to:

• Encourage people to create files in SharePoint or OneDrive.
• Encourage users to email files with cloud attachments.
• Encourage people to communicate using Teams.
• Encourage people to use @mentions in Outlook.
• Encourage people to use Outlook mobile.

When a message is active, the targeted apps display the message tooltip in the business bar in the Word, Excel, PowerPoint, and Outlook desktop apps (aka, the “product surface”). The usual outcome is that the user either dismisses the message with a button often labeled “Got it” or they click another button to go to documentation for the suggestion made by the tooltip.

Creating an Organization Message

I decided that @mentions in Outlook would get the best response from users in my tenant, so opted for that message. The admin center launched a wizard to guide through the steps to create and schedule the message, starting with picking the message appearance (Figure 1). Your account must be a global administrator or hold the new Azure AD Organizational Messages Writer role to create, schedule, and monitor organizational messages.

The next step is to select message recipients (“the audience”). The easy option is to select everyone, but more granular filters are available to:

• Omit priority users (often executives, and you wouldn’t want to disturb their ponderings).
• Omit users by group (why bother the IT department with hints they already know about?).
• Apply filters based on group-level insights (like departments and locations) derived from Azure AD.

Before you can apply filters based on group-level insights, you must enable organizational insights through the org settings for Adoption score (Figure 2).

Next, you add a schedule for the message by setting start and end dates for the apps to display the message, which must be at least 48 hours in advance. You also set an interval for the message to reappear if the user dismisses the message without taking the recommended action (the nagging user parameter).

Finally, you either save the message as a draft or go ahead and submit it for scheduling (Figure 3). After scheduling a message, Microsoft 365 takes care of processing its display by prompting apps when a user within scope for a scheduled message connects.

Viewing Organization Message Tooltips

Due to the mandatory 48-hour lead-in period, a certain leap of faith ensues as those who schedule messages wait for the tooltips to appear in apps used by the target audience. Eventually, the tooltips show up in the targeted Office app to impress users (Figure 4).

You can’t customize the appearance or text in a tooltip in any way. Tooltips generated by organization messages use the same format as the other annoying prompts that Microsoft surfaces in the Office apps. I’m particularly taken by the way that Word offers me a tour of its facilities. Perhaps Word wants to show me features that I’ve never explored since starting to use Word 2.0 in 1992. More likely it’s just a sloppy implementation that results in unwanted tooltips appearing without good cause.

Monitoring Organization Messages

When organization messages are active, it’s possible to monitor the success of Microsoft 365 in delivering the message (tooltip) to users through a rudimentary (half-finished) dashboard (Figure 5). You can’t resize the columns, so you must scroll across to see the columns revealing the total for messages seen (shown to users) and total clicks (on a tooltip button). Clicking the name of a message does nothing.

If you feel the need to plan another communication campaign, you can clone an active message and schedule it for different dates and target audiences. For instance, you could start off with a test campaign focused on members of the IT department (identified by an Azure AD group) and then broaden communications to a wider audience after seeing user response to the tooltips.

Do You Need Organization Messages?

On the one hand, it’s good that Microsoft built a framework for delivery of administrator-authored messages to users via the Microsoft Office apps. There are times when administrators need to communicate on a broad basis with tenant users and doing so in the applications people work with most often seems like a promising idea. However, the downside is that the implementation (in preview) is terribly limited to the messages that Microsoft wants administrators to send. Being able to send custom messages would make this facility so much better and more valuable.

Pop-up messages can be like old-fashioned MFA challenges: easy to dismiss. The value gained by bombarding end users with helpful advice is doubtful. If anyone gains, it’s Microsoft. I’m unsure where any value exists for customers here, just like I doubt the value of in-product advertising of even apparently benign items like Microsoft 365 conferences you might like to attend.

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

Use a Verified Domain to Send Microsoft 365 Service Messages

Announced as Microsoft 365 message center notification MC531211 (21 March 2023, Microsoft 365 roadmap item 103628) and now rolling out to tenants, organizations can choose one of the verified domains available for their tenant as the domain used for product advisory emails (Microsoft 365 service messages).

Microsoft 365 apps that support the feature include:

• SharePoint Online
• OneDrive for Business
• Office
• Stream
• Planner
• Project
• Viva Connections
• Viva Topics
• Viva Amplify

Microsoft 365 apps use email addresses like no-reply@sharepointonline.com and no-reply@planner.com when they generate informational messages to communicate alerts, events, or digest information to users. For instance, when someone stores a document with a higher-level sensitivity label in a SharePoint Online site, SharePoint generates an email to tell them about the potential problem caused by the label mismatch. Figure 1 shows an example of such a message after selecting the office365itpros.com domain to send service messages.

The messages don’t cover service alerts (when a service has an outage), nor do they cover One Time Passcodes (OTP) generated by sharing actions from OneDrive and SharePoint Online. Sharing notifications continue to use no-reply@notify.microsoft.com to ensure delivery of these emails.

Using a Verified Domain

The steps to select a verified domain for service messages are laid out in the Microsoft documentation. In essence, tenant administrators use the Send email notifications from your domain option in the Organization profile section of Org Settings in the Microsoft 365 admin center to select a username and domain (Figure 2).

The domain must be one of the verified domains for the tenant. After saving the new configuration, the Microsoft 365 apps switch to use the selected username and domain instead of their default domains when they send email. Messages are now routed by Exchange Online on behalf of the organization. Just like any of the verified domains used for mail routing, the DNS records for the chosen domain should be configured for SPF, DKIM, and DMARC. This is especially important if email is relayed to Exchange on-premises or an external email service.

The Username for Service Messages

By default, the username is set to no-reply. The intention of a no-reply address is that users know that replying to the address will result in an undeliverable message. However, it’s possible to change the username to one for a routable address such as a shared mailbox so that users can get a response to questions about why they received a service message. Be careful if you do this because service emails then appear to be like any other email sent by the chosen address. Figure 3 shows an example of a message sent by SharePoint Online to report updates to documents in a site. The message appears to come from a shared mailbox because that’s what matches the configured address for service messages.

Not External Messages

Because the tenant’s instance of Exchange Online routes the service messages, they are now internal rather than external and therefore will not be tagged with the external indicator. In some respects, this is a major advantage of choosing to use a verified domain as users might better accept the content of the messages if they don’t come from an external source. The downside is that users might need to adjust inbox rules to process service messages correctly.

If you use a mail flow rule to protect administrator accounts from external email, remember to update the rule to deal with messages from your chosen domain.

Not a Change to Worry Too Much About

After using this option for a couple of weeks, I don’t see any great downside to using a verified domain to send Microsoft 365 service messages. Something might have slipped my attention (and if so, I’d like to know), but overall I think this is a good change that all tenants should consider.

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

SharePoint Block Download Policy Licensed by Syntex-SharePoint Advanced Management and Managed with PowerShell

One of the features covered by the new Syntex-SharePoint Advanced Management license blocks users from being able to download files from a SharePoint Online site or OneDrive for Business account. The idea is to protect sites that store very confidential material by forcing users to work with the files stored in the site using browsers. Users can’t even use the Office desktop apps because those apps download a temporary copy of files to work on them locally.

The block files from download feature is currently in preview. To enable a block download policy for a site, you’ll need to use the Set-SPOSite cmdlet from the latest version of the SharePoint Online management PowerShell module.

Restricting Download Access

I tested the feature by creating a new team called Project Aurora. I then configured the SharePoint Online site belonging to the team by running these commands to find all sites, select the URL for the Project Aurora site, and use it to configure a block download policy with an exclusion for site owners. In other words, site members can’t download files from its document libraries, but site owners can.

[array]$Sites = Get-SPOSite -Limit All
$Site = ($Sites | Where-Object {$_.Title -eq "Project Aurora"}) | Select-Object -ExpandProperty Url
Set-SPOSite -Identity $Site -BlockDownloadPolicy $True -ExcludeBlockDownloadPolicySiteOwners $True

The preview documentation says that site owners can grant exclusions to groups by passing the group identifiers in the ExcludedBlockDownloadGroupIds parameter. I see some issues here because Microsoft has long coached customers not to update membership of group-connected sites through SharePoint Online. In addition, adding a Microsoft 365 group to site membership creates an unsupported condition of nested Microsoft 365 groups. For now, I would avoid using group-based exclusions and concentrate solely on site owner exclusions.

After populating the default document library with some documents, I signed into the site with a member account. The site flagged the restrictions in place and removed the options to download files (Figure 1).

The Teams Files channel tab also removes the download option but doesn’t display a banner to inform the user about the restrictions. The Files channel tab does remove the option to use an Office desktop app to open a document. Before restricting downloads by policy, Microsoft recommends that you check any potential effect that the block might have on other applications, including Power Apps and Power Automate.

The file download restrictions are the same as when using a conditional access policy to limit access when users attempt to access SharePoint content from an unmanaged device. That’s the point of this feature: you don’t need to deploy conditional access policies to get equivalent protection. Although conditional access policies are a good way to control what people can do after they connect to a Microsoft 365 tenant, there’s no doubt that organizations can end up with many different policies to manage. Replacing a conditional access policy with a relatively simple download block applied at the site level might be a good thing to do, especially if you want to have finer-grained control over what sites block file downloads.

Applying the SharePoint Block Download Policy to Multiple Sites

As a practical example of how you might deploy block download policies, let’s assume that you want to stop downloads for all sites assigned the most stringent sensitivity label. In my tenant, that’s a label called “Confidential Access.” The important thing is to know the label identifier (GUID) because that’s how Microsoft 365 workloads connect to sensitivity labels. In this case, the GUID is c99e52c6-f5ff-4050-9313-ca6a3a35710f.

This script applies the SharePoint block download policy to all sites assigned the Confidential Access sensitivity label. First, we find the set of sites associated with Microsoft 365 groups. Because the Get-SPOSite cmdlet does not return all site properties when it processes multiple sites, we need to loop through the site of sites to check the sensitivity label for each site and apply the policy after detecting a matching label:

# Process sites and set the SharePoint block download policy
[array]$Sites = Get-SPOSite -Template "GROUP#0" -IncludePersonalSite:$False -Limit All
Write-Host ("Scanning {0} sites to find those with the Confidential Access label" -f $Sites.count)
[int]$i = 0
ForEach ($Site in $Sites) {
   $SiteData = Get-SPOSite -Identity $Site.Url
   If ($SiteData.SensitivityLabel -eq "c99e52c6-f5ff-4050-9313-ca6a3a35710f" -and $SiteData.BlockdownloadPolicy -eq $False ) {
      Write-Host ("Applying site download block policy to {0}" -f $SiteData.Title)
      Set-SPOSite -Identity $Site.Url -BlockDownloadPolicy $True -ExcludeBlockDownloadPolicySiteOwners $True; $i++
   }
}
Write-Host ("Finished processing. {0} sites updated with a block download policy" -f $i)

Remember Your Syntex Licenses

Remember that every member of a site that uses a block download policy to restrict downloads to site owners or groups must have a Syntex Advanced Management license. Given that you’ll probably only apply this kind of restriction to a limited number of sites, that shouldn’t be a big issue.

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.

Syntex-SharePoint Advanced Management Covers Secure Collaboration for SharePoint Online

Updated 2 March 2022

I know that many Microsoft 365 organizations don’t use sensitivity labels, even if they have the necessary licenses to use labels to protect content. All Office 365 licenses allow users to read protected content, but you need Office 365 E3 or above to apply labels to files, and Office 365 E5 or Microsoft 365 Compliance E5 for auto-label processing. At least, that’s been the case up to now.

Applying a default sensitivity label for a SharePoint Online document library (Figure 1) counts as automatic processing. Apparently, Microsoft considers the fact that new and modified documents in the library pick up the sensitivity label (unless previously labeled) as reason enough. In late January 2023, Microsoft revealed that this feature was one of the set to be licensed through a new Microsoft Syntex-SharePoint Advanced Management license.

Features Enabled by the Microsoft Syntex-SharePoint Advanced Management License

The new license is in preview and includes other elements to improve secure collaboration based on SharePoint Online and OneDrive for Business, including:

• Using sensitivity labels with Azure AD authentication contexts to limit access to SharePoint Online sites. This feature has been in preview since 2021.
• Restricting access to a SharePoint Online site to members of a Microsoft 365 group. This restriction blocks users who have received access to a file in the site.
• Blocking the download of files from SharePoint Online sites or OneDrive for Business accounts without the need to use Azure AD conditional access policies. In other words, users are forced to use a browser to access the site or account and cannot download, print, or synchronize files. The restriction also blocks access to the Office desktop apps because these apps need to download files to work on them locally.

In addition, Syntex-SharePoint Advanced Management includes some management and governance features. The three examples cited appear to be instances where it’s possible for administrators to do the same thing with some effort. Microsoft is making it easier. For example, the ability to limit access to OneDrive for Business to those who are members of a specific security group stops people licensed to use OneDrive but who aren’t members of the security group from using the app. The same effect is possible by simply removing the OneDrive service plan from their assigned licenses.

I haven’t seen what actions are included in the feature to export recent SharePoint site actions, but it might be possible to replicate the functionality by fetching SharePoint management events from the unified audit log.

My assumption is that any user who takes advantage of a feature licensed by Syntex advanced management requires a license. For instance, site members of a site where a document library uses a default sensitivity label all require Syntex-SharePoint Advanced Management licenses.

I can’t find a public announcement by Microsoft about the Syntex-SharePoint Advanced Management license. Cynics will say that this is another example of how Microsoft creates licenses for new functionality to generate additional revenue from its installed base. A more benign view is that the new license allows people with Office 365 E3 licenses to use the security and governance features enabled by Syntex Advanced Management. When I find out more details about licensing, including if some features covered by Syntex Advanced Management are also available through other licenses, I shall share the information.

Viewing Metadata for Protected Files

On an associated topic, I was asked why the metadata of documents protected by sensitivity labels remains visible to people who have no right to access these files. It’s a good question because some get confused when they notice an interesting document in a library but can’t open it because they’re blocked by the rights assigned in the label. For instance, who wouldn’t want to open a document with a title like “Proposed Pay Rises for Staff”?

When you enable SharePoint Online and OneDrive for Business to support sensitivity labels, it allows the workloads to deal with protected (encrypted) content. SharePoint Online stores protected files in an unencrypted format to allow functions like indexing and data loss prevention policies to work. Any access to a document, such as a user opening or downloading a file, causes SharePoint Online to encrypt the document so that the application used to open the file (like Word) can apply the rights assigned to the user. Everything works very nicely and those who have access to files can work with that content and those who don’t cannot.

When browsing items in a document library, site members can see metadata like the titles and authors of protected documents. Attempts to open these documents fail if the user doesn’t have the necessary rights. Because SharePoint Online doesn’t encrypt or obscure the metadata, those users know that documents with potentially very interesting content are available.

How SharePoint Online Stores Documents

The reason why document metadata is visible to all site members is rooted in how SharePoint Online stores documents. SharePoint Online uses Azure SQL as its storage platform. Blob storage holds documents and other files while metadata is in a separate table (list). The Azure SQL data is heavily protected against illegal access. Once a user has access to a document library, the assumption is that SharePoint can show them all the items, which is what they see in the list shown in a browser or the Teams files channel tab. It’s only when a user attempts to access a protected document that SharePoint Online validates their right to open that content.

You can argue that SharePoint Online and OneDrive for Business should hide the existence of protected documents that the user can’t open, but this would require SharePoint Online to check that access before displaying documents in a library. Such a check would incur a huge performance penalty because SharePoint Online cannot assume that the rights assigned in a sensitivity label are the same as the last time it checked.

New Functionality, New Costs

Although the news about the Syntex-SharePoint Advanced Management license will disappoint some, it’s reasonable that Microsoft should charge extra for security and management features that not every Microsoft 365 tenant will want or need. Those that need the functionality will simply have to pay the $3/user monthly cost. Hasn’t that always been the way?

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.

Relevance Recommendations for Message Center Notifications Help Tenant Admins Understand Impact of Change

Message Center notification MC466202 (12 November 2022) marks another step along the path to assist tenant administrators cope with the ongoing flood of change across the Microsoft 365 ecosystem. The developers added active user counts to notifications in January 2022. Now, a new “relevance recommendation” highlights important notifications (Microsoft 365 roadmap item 96289). Deployment to targeted release tenants begins in mid-November and should be complete by mid-December. Standard release tenants should see the new indicator show up starting in mid-January 2023. Full worldwide deployment is due by the end of April 2023.

Microsoft says that the new visual indicator helps tenant administrators understand how relevant a change is to their tenant. Microsoft calculates the value (High, Medium, or Low) based on multiple factors, including “service usage and the type of change.”

Relevance Recommendation Need Tenant Tweaking

The first thing to remember is that relevance is only a recommendation, not a dictat. Microsoft does their best to set the indicator appropriately for message center notifications, but you’ve always got to put the complete notification into context to understand its true impact.

When I looked at the current set of notifications for my tenant, there were no notifications with a high relevance recommendation. Applying the filter to show medium-level recommendations revealed the set shown in Figure 1. Note that MC466200 (announcing the public preview of Power BI integration with Microsoft Graph) gets a medium recommendation. Although a lot of Graph-based development work occurs in the tenant, Power BI is lightly used, so the tenant-adjusted recommendation is low rather than medium. On the other hand, MC466199, which announces the ability for Teams users to delete chats, is also rated medium and should be high. And as it happens, the notification that announces the relevance recommendation (MC466202) is graded as low.

All of which means that tenant administrators must still fully engage their brains when browsing message center notifications. It’s only by putting change in context using the knowledge of how a tenant works that you can conclude the true importance of an individual change. If you disagree with Microsoft’s recommendation, you can provide feedback using the “Do you like this change” section at the bottom of a message center notification. Make sure that you tell Microsoft why you disagree with their assessment (Figure 2).

No Retro Recommendations

Only message center notifications posted after the implementation of the new feature in a tenant have recommendations. Older notifications do not. New posts might show up with a recommendation of “Processing” (Figure 3). This means that Microsoft 365 is computing the score that drives the recommendation. Refreshing after a couple of minutes should reveal the actual recommendation.

Link to Planner

If you use the synchronize to Planner feature to create new tasks for message center notifications, recommendations show up in task notes. Of course, there’s nothing to stop you using one of the 25 labels available in a Planner plan to mark a task with your own assessment of the relevant importance of a change, which is what we’ve done in Figure 4.

It’s a pity that a separate property isn’t available to store this data, but it should still be easy to find the recommendations programmatically using the uprated Planner Graph APIs (MC449931).

Relevance Recommendation Helps Prioritization of Change

Any change that helps tenant administrators sort the message center wheat from the chaff is helpful. With over 400 notifications posted annually, it takes time and effort to read, understand, and assess how a change might impact a tenant. Microsoft’s relevance recommendation isn’t perfect, but it should improve over time and will be a valuable input to the prioritization of change by tenants.

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 Admin Center Releases Software Update Page

Message Center Notification MC397469 (July 5, 2022) announced the arrival of a new Microsoft 365 Software Updates page under the Health section of the Microsoft 365 admin center. The page is currently in preview, but according to Microsoft 365 roadmap item 82148, it should be generally available in August. The idea is that the new page gives tenant administrators a simple way to discover the update status of Office and Windows on devices known to the organization. As Figure 1 shows, my tenant is in pretty good shape.

Access to the data is limited to certain administrative roles including Global administrator, Global reader, Office apps admin, Reports reader, usage summary reports reader, Intune administrator, and Exchange administrator. The information presented in the report comes from device telemetry gathered when devices connect to Microsoft 365.

The Imminent Need for Upgrade

It’s a good idea to know whether software used to connect to a service is patched appropriately. Over the years, Microsoft has been reasonably accommodating in terms of the range of clients (desktop, mobile, and browsers) that people could connect to Microsoft 365. Things started to tighten up as the retirement of Internet Explorer approached. Indeed, Teams rejected IE as long ago as November 2020.

However, the need to upgrade client software is heading for a crunch period as organizations prepare for Microsoft to begin turning off basic authentication for seven email connectivity protocols in October 2022. The increasing number of warnings from Microsoft and the steps they’re taking to highlight the issue to customers is evident that some tenants might not be listening to the warnings.

Outlook

Outlook for Windows is a huge client for Exchange Online. Given its long history, it’s unsurprising that some older Outlook clients are still in use. Microsoft wants customers to make sure that they have enabled modern authentication for Outlook. Check by running the Get-OrganizationConfig cmdlet to ensure that the OAuth2ClientProfileEnabled setting is True:

Get-OrganizationConfig | fl OAuth2ClientProfileEnabled
OAuth2ClientProfileEnabled : True

There’s more to do after that, like making sure that users have recent Outlook clients installed. Outlook 2016 or later is recommended. The Outlook click-to-run version in Microsoft 365 apps for enterprise uses modern authentication out-of-the-box.

Apple Mail App

Last month, Microsoft released details of the automated approach they’re taking in conjunction with Apple to move Apple Mail app users to modern authentication. Two important gotchas need consideration. First, the automated approach won’t work if the organization deploys an MDM solution (Apple doesn’t want to mess with organization-controlled configurations, so they exclude these devices from their automatic update process). Second, the mail app uses Exchange ActiveSync to connect to personal Exchange Online mailboxes and that’s what the upgrade to modern authentication affects. If you use Apple devices to access shared mailboxes via IMAP4, the upgrade won’t do anything to enable modern authentication for IMAP4 (the Exchange ActiveSync protocol doesn’t support shared mailboxes).

If you’re in this position, maybe now is the right time to move from the Apple mail app to Outlook for iOS, which supports shared mailboxes natively. You might be waiting a while for Apple to update their IMAP4 implementation to connect to Exchange Online via modern authentication.

Other Exchange ActiveSync Clients

Microsoft and Apple are working together to solve the modern authentication issue for Apple mail clients, but what of all the other mobile device mail clients that use Exchange ActiveSync to connect to Exchange Online? The simple answer is that it’s the vendor’s responsibility to upgrade their clients so that they can connect to Exchange Online in a secure manner. The practical answer is that you should contact the vendor and ask them how their mail clients will work once basic authentication is unavailable.

IMAP4 and POP3

Speaking of IMAP4 and POP3, Microsoft has released support for modern authentication for the IMAP4 and POP3 protocols. This is something that client developers (like Apple) need to take care of rather than individual users. The folks who build the Thunderbird client have done a good job of making sure that this client is ready, but that’s not the case for other IMAP4 and POP3 clients, so make sure that you check if people in your tenant use these clients to connect to Exchange Online.

Developers who use IMAP4 and POP3 to retrieve messages for application rather than personal use must upgrade their applications using a different method to make sure that they can continue to access mailboxes.

No Silver Bullet for Client Health

The new Software updates page won’t tell you anything about the state of non-Microsoft clients. Tenants with Office 365 E3 or higher plans that include Microsoft 365 apps for enterprise might find the feature useful, but it’s not going to be a silver bullet to keep client software in robust health. Welcome as it is, the new Software updates page will be the source of some additional information, but that’s about all.

Keep up to date with developments like the transition to modern authentication for email connectivity protocols by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Odd Message Center Notification

In message center notification MC392289 (posted 14 June), Microsoft reminded tenants that the Teams meeting add-in for Outlook depends on the .NET Framework 4.8 and the Edge WebView2 component. The reminder is curious because Microsoft doesn’t issue this kind of warning very often. Something obviously provoked the notification, perhaps an outbreak of support calls where the meeting add-in doesn’t work as well as it should. Or, as Microsoft puts it, “a degraded experience.”

No further details are available about what the degradation involves. Perhaps the add-in can’t insert the deeplink required to connect to Teams meetings or other details into the meeting invitation, like the custom organization logo discussed in yesterday’s post. Microsoft’s documentation for the Teams meeting add-in says that if WebView2 is not installed, users are redirected to a browser interface, “which may provide a degraded experience especially at the time of meeting creation.” The documentation doesn’t mention the .Net framework, and neither does the support document for troubleshooting the Teams meeting add-in.

Edge WebView2

The Edge WebView2 component is important for Teams and Outlook. It is the basis for the development of the new Teams 2.0 client, and it’s used to enable the sharing of components between Outlook desktop and OWA. Since early 2021, Microsoft has included WebView2 in updates for the Microsoft 365 apps for enterprise (Office) suite, and it’s installed with the regular refreshes for the Edge browser. Looking at my PC, the last Edge update was five days ago (Figure 1).

Between Edge and the Microsoft 365 apps for enterprise, it should be easy enough to keep the WebView2 component up to speed.

.Net Framework 4.8

We’re left in the dark about the need to keep the .NET Framework current. The framework is used by many Microsoft products, so the assumption is that something in the depths of the add-in needs something in .NET Framework 4.8. An offline installer is available to bring a workstation up to speed, or you can download and install it online. But before you do anything, check the version you have.

The check depends on looking for a value in the system registry (Figure 1).

You can also check with PowerShell. This command checks if the current version is 4.8 or greater:

(Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full").Release -ge 528040

True

No Detail to Back Up Warning

Something always causes large companies like Microsoft to issue warnings to their customers, especially for something like the Teams meeting add-in that’s existed for several years. In this case, it might be that a bunch of recent support incidents has demonstrated that the root cause of many customer problems with the Teams meeting add-in has been due to outdated software components. Or it could be that a recent change in the add-in requires a particular version of the two components.

The nature of Teams and the way that its functionality leverages so many different services and components drawn from across Microsoft 365 makes it more likely that Teams should suffer from dependency defects that other products so. Support organizations like to take proactive steps to reduce an influx of customer problems, so this might be a preemptive strike to help people do the right thing.

In any case, the dearth of information released in MC392289 makes it difficult to say anything else than tenant administrators should keep an eye on what’s installed on user workstations. Just another item to add to an ever-growing checklist.

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

Invaluable Source of News about Microsoft 365 Workloads

I pay a lot of attention to message center notifications about new features posted to the Microsoft 365 admin center. I know many other people are diligent in their reading of these posts too, but it seems like many others ignore the flood of information posted by Microsoft.

Missing out on news is disappointing, but it’s human nature to focus on what seems to be important at the time. In other words, if people are busy with other aspects of tenant administration (or the rest of their job), reading up about new features drops off their list of things to do. Although understandable that other jobs take priority, this creates a problem for those tenants because Microsoft posts some critically important information in message center notifications.

Take the deprecation of basic authentication for Exchange Online connection protocols like POP3 and IMAP4. Microsoft wants to remove basic authentication for these protocols in October 2022. Great progress has already been made to remove basic authentication from tenants where they were not used, but as we get closer to the date, Microsoft will post messages to inform administrators about the progress of the removal of basic authentication connections within their tenant. If the messages are ignored, it could be a terrible shock if users unexpectedly discover that they have a problem. Changes like this which unfold over many months might be considered boring, but they need to be monitored.

Improvements in Message Center Notifications

Microsoft has steadily improved some aspects of the information posted in the message center. A recent example is the inclusion of affected user counts to help administrators understand the impact of a change on users. Another is the imminent introduction of better feedback from tenant administrators about changes covered in message center notifications (MC324461). Unfortunately, this change is delayed, but it should appear in mid-April and will allow administrators to tell Microsoft when change messages are relevant for their organization.

The updates do help. For instance, Figure 1 covers the topic of the auto-expiration policy for Teams meeting recordings, a change which is finally rolling out after several false starts. The change affects several workloads as Teams creates the meeting recordings and stores them in OneDrive for Business or SharePoint Online (here’s a script to track these events). Note that the change is flagged as a major update which will affect both administrators and users.

Delays

Microsoft’s poor record in delivering features when predicted is one reason I’ve heard from administrators to justify why they don’t pay as much attention as I think they should to the message center. Delays are endemic inside Microsoft 365. They exist across all workloads and feature areas. Delays often come about when Microsoft encounters quality problems (bugs) that must be fixed before features ship.

Microsoft originally announced auto-expiration for Teams meeting recordings on July 30, 2021 with the intention to roll-out the feature in September. Seven months later, Microsoft has worked through several blocking issues, such as increasing the default retention period from 30 to 60 days, and the roll-out is progressing. A seven-month delay is unusual in its length. The normal delay, if such a thing exists, tends to be around two months.

Bugs are part of software life and it’s important to deliver quality code. Although bugs do cause many delays, I also think that some Microsoft program managers are guilty of publishing message center notifications in hope rather than certainty that a feature will be ready in time. As an example, five of the eight message center notifications published on April 1 reported delays (Figure 2).

Nine of the thirteen posted on March 31 reported delays in features ranging from music on hold for VOIP calls (MC343429) to an updated group icon for OWA (MC303512). The latter is another example of a long delay as it first appeared on December 10, 2021, and Microsoft now expects the roll-out to be complete in mid-April. Sure, an update for an icon in OWA is unlikely to have huge impact (Figure 3 shows the new icon), but you’d wonder why such a delay happened on the road to availability for such a small change.

Message Center Notifications Still Valuable

Another point I could criticize is the lack of clarity in the explanatory text in some message center notifications. Even after reading the words several times, I’m often still uninformed about the importance and detail of a change. Some lessons in concise technical writing might not go amiss.

Even with my concerns, I still consider the message center notifications to be an invaluable source of information about change that’s happening inside Microsoft 365. If you struggle to keep up, consider synchronizing notifications to Planner. We do this to track change for the Office 365 for IT Pros eBook. Having everything in Planner helps us organize and manage updates that we need to cover in the book. Although it won’t reduce the delays in announced features, using Planner to track what’s going on is a great way of gaining extra visibility into what’s changing and what an organization needs to do to handle that change.

Preparing to Migrate Away from Old AzureAD cmdlets

Updated: 15 March, 2023

I received a lot of reaction when I described Microsoft’s new deprecation schedule for the AzureAD and MSOL modules. In summary, you have until 30 March 2024 to update scripts which assign licenses to user accounts. After this, Microsoft will disable the cmdlets. The other cmdlets will continue working after Microsoft deprecates the modules. However, they’ll be out of support, which is not a good foundation for PowerShell scripts used to automate administrative processes, like managing Entra ID user accounts.

With time running out, it’s obvious that tenants need to inventory and upgrade scripts. One reaction I received was that there’s a dearth of information to help people who are less familiar with PowerShell and might have inherited ownership of some scripts. My response is that the community will publish examples over time, just like they did when Microsoft launched the AzureAD module in 2016 and the Exchange Online management REST-based cmdlets at Ignite 2019. Let’s hope this is true.

Over on Practical365.com, I compare creating a new Entra ID user account and assigning licenses to the account using both the old AzureAD module and the Microsoft Graph PowerShell SDK. In this post, I consider some additional basic user account management actions.

Connections

The basics of using the Microsoft Graph PowerShell SDK (the SDK) is to connect. You can connect interactively (delegated access) or with certificate-based authentication (application access). You can also run SDK cmdlets in Azure Automation runbooks. The simplest approach is to run Connect-MgGraph interactively, which signs into the Graph using the account you signed into PowerShell with.

Scopes

SDK cmdlets interact with Microsoft Graph APIs. A big difference between the SDK and AzureAD modules is that the SDK forces you to request the set of Graph permissions you want to use. The SDK uses a service principal to hold the permissions, and over time, that service principal might become overly permissioned. It’s a thing to keep an eye on.

In this example, we define an array of Graph permissions we wish to use, and then connect. If you request a permission that the SDK service principal doesn’t already hold, you’ll see an administrator prompt for consent.

$RequiredScopes = @("Directory.AccessAsUser.All", "Directory.ReadWrite.All", "User.ReadWrite.All", “User.Read.All”)
Connect-MgGraph -Scopes $RequiredScopes -NoWelcome

Welcome To Microsoft Graph!

Updating Properties for Entra ID User Accounts

Let’s assume that you’ve created the Sue.Ricketts@Office365itpros.com account using the New-MgUser cmdlet as described in this article and stored the user identifier for the account in the $UserId variable.

$UserId = (Get-MgUser -UserId Sue.Ricketts@office365itpros.com).Id

To update the properties of a user account, run the Update-MgUser cmdlet.

Update-MgUser -UserId $UserId -JobTitle "Senior Editor" -State NY

Updating Email Properties for an Account

You can’t update the proxyAddresses property of a user account because the Graph treats it as read-only, possibly because Exchange Online takes care of email proxy address management. However, if you change the UserPrincipalName property of an account, Update-MgUser sets the primary SMTP address of the account to match the new user principal name. The logic here is likely that it is best practice to match the user principal name and primary SMTP address. In most cases, this is true and it’s a good idea to have the cmdlet behave like it does. However, in some circumstances, you might decide to have different values in these properties.

In both situations, you should use the Exchange Online Set-Mailbox cmdlet to update proxy addresses. For example, this command adds a new SMTP proxy address to the mailbox identified by the $UserId variable:

Set-Mailbox -Identity $UserId -EmailAddresses @{Add="Johnnie.West@Office365itpros.com"}

This command updates the primary SMTP address for the mailbox without changing the user principal name:

Set-Mailbox -Identity $UserId -WindowsEmailAddress Johnnie.West@Office365itpros.com

Exchange Online uses a dual-write mechanism to make sure that any change made to mailboxes happens simultaneously to the underlying user account.

Updating a User’s Manager

The manager of a user account is updated by reference (to their account) rather than simply updating a property. To update the manager of a user account, run the Set-MgUserManagerByRef cmdlet after storing the identifier of the manager’s account in a variable:

$ManagerId = (Get-MgUser -UserId Terry.Hegarty@office365itpros.com).Id
Set-MgUserManagerByRef -UserId $UserId `
   -AdditionalProperties @{
     "@odata.id" = "https://graph.microsoft.com/v1.0/users/$ManagerId" }

To check that the manager update was successful, we need to fetch the manager’s details (expanded into a dictionary object) and retrieve the property we want.

$ManagerData = Get-Mguser -UserId $UserId -ExpandProperty Manager
$ManagerData.Manager.AdditionalProperties['displayName']
Terry Hegarty

You can also use the Get-MgUserManager cmdlet to return the manager of an account.

Get-MgUserManager -UserId Chris.Bishop@Office365itpros.com | Select-Object @{n="DisplayName";e={$_.AdditionalProperties.displayName}},@{n="UserPrincipalName";e={$_.AdditionalProperties.userPrincipalName}}

DisplayName UserPrincipalName
----------- -----------------
James Ryan  James.Ryan@office365itpros.com

Obviously, Microsoft has made defining and retrieving the manager of an account more complex than it needs to be. It would be nice if they would hide the complexity in code and deliver some straightforward cmdlets that don’t create friction when the time comes to update scripts.

Another way of updating user account properties is with the Invoke-MgGraphRequest cmdlet, which runs a Graph API query. The advantage of this cmdlet is that if you can’t find a way to do something with an SDK cmdlet, you can refer to the Microsoft Graph documentation, find some example code, and run or repurpose it.

In this example, we create a hash table to hold the properties we want to update, convert the table to a JSON object, and pass it to a PATCH query run by Invoke-MgGraphRequest:

$Parameters = @{
   JobTitle = "Managing Editor, Periodicals"
   State = "Vermont"
   OfficeLocation = "Burlington" } | ConvertTo-Json
Invoke-MgGraphRequest -Method PATCH -Uri "https://graph.microsoft.com/v1.0/users/Sue.Ricketts@office365itpros.com" -Body $Parameters -ContentType "application/json; charset=utf-8"

Delete a User Account

The Remove-MgUser cmdlet soft-deletes a user account and moves it into Entra ID’s deleted items container, where it remains for 30 days until Entra ID permanently deletes the object. The cmdlet is very simple, and it doesn’t prompt for confirmation before proceeding to delete a user account.

Remove-MgUser -UserId $UserId

If you need to restore a soft-deleted account, run the Restore-MgUser cmdlet and pass the object identifier of the account you want to restore. See this article for information about how to list the set of soft-deleted user accounts.

Restore-MgUser -UserId $UserId

I’ve experienced some issues with the Restore-MgUser cmdlet in the 1.9.3 release of the SDK which I have reported to Microsoft. Basically, the cmdlet doesn’t work in this release. I’m sure the bug will be fixed soon.

Finding User Accounts

We’ve already seen how the Get-MgUser cmdlet fetches information for an individual user account. It also fetches sets of accounts. To fetch all the accounts in the tenant, run:

[array]$Users = Get-MgUser -All

I always specify that the variable used as the target for a set of objects is an array. This makes it easy to find how many objects are returned, as in:

Write-Host $Users.Count “User accounts found”

Note that unlike Graph API queries, the Get-MgUser cmdlet takes care of data pagination for the query and fetches all available objects.

If you don’t specify the All switch, the cmdlet fetches the first 100 accounts. You can fetch a specific number of accounts using the Top parameter, up to a maximum of 999.

[array]$Top500 = Get-MgUser -Top 500

The Filter parameter uses server-side filtering to restrict the amount of data returned. For instance, here’s how to find all the guest accounts in a tenant:

[array]$Guests = Get- MgUser -Filter "usertype eq 'Guest'" -All

While this filter returns the accounts who usage location (for Microsoft 365 services) is the U.S.

Get-MgUser -Filter "usagelocation eq 'US'"

You can combine properties in a filter. For example:

Get-MgUser -Filter "usagelocation eq 'US' and state eq 'NY'"

Another interesting filter is to find accounts created in a specific date range. This command finds all tenant non-guest accounts created between January 1, 2022 and Matrch 24. Note the trailing Z on the dates. The Graph won’t treat the date as valid if the Z is not present.

Get-MgUser -Filter "createdDateTime ge 2022-01-01T00:00:00Z and createdDateTime le 2022-03-24T00:00:00Z and usertype eq ‘Member’"

Support for SDK Problems via GitHub

Hopefully, the examples listed above are useful in terms of understanding the SDK cmdlets to perform basic management of Entra ID user accounts. If you run into a problem when converting scripts to use SDK cmdlets, you can report the problem (or browse the current known issues) on GitHub. Happy migration!

Understanding How to Delete Entra ID User Accounts and Restore Them Afterwards is a Critical Skill

According to message center notification MC344406 (18 March), in early April Microsoft plans to roll-out the capability of recovering deleted service principal objects. Service principals are critical parts of registered Entra ID apps, such as the apps used to execute Microsoft Graph API queries with PowerShell. They’re also used in Azure Automation accounts, the Microsoft Graph PowerShell SDK, and managed identities. In all cases, the service principals hold the permissions needed for an app or account to operate. The worldwide roll-out to all tenants should complete by late May.

When the capability is available, any time an administrator deletes a service principal (for instance, because a registered app is no longer needed) using the Entra admin center, PowerShell (using Remove-AzureADServicePrincipal), or the Microsoft Graph API, Entra ID will place the service principal into a soft-deleted state. This already happens today for user, group, device, and application objects.

Deleted Entra ID objects stay in the deleted items container for 30 days. When the retention period elapses (extending to maybe a few days afterwards), Entra ID proceeds to permanently delete the object.

During the retention period, administrators can restore an object, which makes it easy to recover if someone deletes an important item by accident. For now, the list deleted items API doesn’t support service principals, but it will after the roll-out. Figure 1 shows user objects in the deleted items container as viewed through the Graph Explorer.

Using Old Azure AD Cmdlets

MC344406 features two cmdlets from the Azure AD Preview module:

• Get-AzureADMSDeletedDirectoryObject: list details of a deleted object.
• Remove-AzureADMSDeletedDirectoryObject hard-delete a soft-deleted object.

In some respects, it’s odd that they use cmdlets based on the Azure AD Graph API because Microsoft has scheduled the Azure AD modules for retirement in March 2024.

Of course, apart from the licensing management cmdlets, the rest of the Azure AD cmdlets will continue to work after retirement, which makes it perfectly acceptable to specify the cmdlets now, especially if replacements in the Microsoft Graph PowerShell SDK are unavailable.

Using Microsoft Graph PowerShell SDK Cmdlets to Delete Entra ID User Accounts

The Microsoft Graph PowerShell SDK can be difficult to navigate. It’s composed of 38 separate sub-modules. Although cmdlets are gathered logically, it can still be hard to find the right cmdlet to do a job. As you’d expect, the current version (1.9.3) doesn’t appear to include cmdlets to handle soft-deleted service principal objects. For now, we can see how to perform common administrative actions with user accounts as a guide to what should be available for service principals.

With that in mind, here are the steps to soft-delete user accounts, list the accounts in the deleted items container, and hard-delete (permanently remove) an account.

Soft-Delete an Entra ID User Account

To soft-delete an Entra ID account, run the Remove-MgUser and pass the object identifier or user principal name of the account to delete. The cmdlet does not prompt for a confirmation and deletes the account immediately:

Remove-MgUser -UserId Sue.Ricketts@office365itpros.com

List Soft-Deleted Entra ID User Accounts

During the 30-day retention period in the deleted items container, you can recover the account from the Entra admin center or by running the Restore-MgUser cmdlet. Before we can run Restore-MgUser, we need to know the object identifiers of the objects in the deleted items container. This code:

• Uses the Get-MgDirectoryDeletedItemAsUser cmdlet to fetch the list of deleted user accounts. The Property parameter can be ‘*’ to return all properties of the deleted objects, but in this case, I’ve chosen to limit the set of properties to those that I want to use.
• Loops through the data returned by Entra ID to extract the properties we want to use. The different behaviour of the Azure AD cmdlets and the Microsoft Graph PowerShell SDK cmdlets is an example of why tenants need to plan the upgrade and testing of scripts which use old cmdlets.
• Lists the soft-deleted user accounts.

[array]$DeletedItems = Get-MgDirectoryDeletedItemAsUser -All -Property Id, DisplayName, DeletedDateTime, UserPrincipalName, Usertype
If ($DeletedItems.count -eq 0) { 
   Write-Host "No deleted accounts found - exiting"; break 
}

$Report = [System.Collections.Generic.List[Object]]::new()

ForEach ($Item in $DeletedItems) {
    $DeletedDate = Get-Date($Item.deletedDateTime)
    $ReportLine = [PSCustomObject][Ordered]@{ 
           UserId   = $Item.Id
           Name     = $Item.displayName
           Deleted  = $DeletedDate
           "Days Since Deletion" = (New-TimeSpan $DeletedDate).Days
           Type     = $Item.userType
     }
    $Report.Add($ReportLine)
}

UserId                               Name                      Deleted             Days Since Deletion Type
------                               ----                      -------             ------------------- ----
92cef396-1bd3-4296-b06f-786e2ee09077 The Maestro of Office 365 19/02/2022 17:36:44                  31 Guest
c6133be4-71d4-47c4-b109-e37c0c93f8d3 Oisin Johnston            26/02/2022 18:13:26                  24 Member
2e9f1189-d2d9-4301-be57-2d66f3df6bb1 Jessica Chen (Marketing)  04/03/2022 11:52:48                  18 Member
8cd64635-bce6-4af0-8e64-3bebe354e9a4 Alex Redmond              05/03/2022 17:36:45                  17 Member
0f16501c-8302-468a-99a6-78c22b0903d2 Jennifer Caroline         18/03/2022 21:33:13                   3 Member
3a6116ab-0116-490e-bd60-7e0cd9f36c9d Sue Ricketts (Operations) 20/03/2022 19:53:29                   2 Member
4a25ccf0-17df-42cf-beeb-4fd449531b47 Stephen Rice              22/03/2022 19:30:06                   0 Guest

To restore a soft-deleted user account, run the Restore-MgDirectoryDeletedItem cmdlet and pass the account’s identifier. After restoring the account, remember to assign licenses to allow the account to access Microsoft 365 services.

Restore-MgDirectoryDeletedItem -DirectoryObjectId 3a6116ab-0116-490e-bd60-7e0cd9f36c9d

Remove Soft-Deleted Entra ID User Account

To remove a soft-deleted directory object, run the Remove-MgDirectoryDeletedItem cmdlet and pass the object identifier. Like Remove-MgUser, the cmdlet doesn’t ask for confirmation and permanent deletion happens immediately.

Remove-MgDirectoryDeletedItem -DirectoryObjectId f9d30b84-ad5f-4151-98f0-a55dafe30829

Time of Transition

We’re in a time of transition now as Microsoft does its best to retire the Azure AD modules and build the capabilities (and hopefully the documentation) of the Microsoft Graph PowerShell SDK. In the intervening period, any time you see an example using Azure AD cmdlets, try to convert it to use the SDK. It’s a great way to learn.

Keep up to date with developments like the Microsoft Graph PowerShell SDK 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.

Protecting User Data from Unauthorized Access

Updated 28 June: The idle session timeout feature is now generally available.

As I noted on March 7, Microsoft 365 has many web apps, including applications like Planner and Forms whose only available user access is via a browser (unless you consider access via Teams apps). In any case, Microsoft 365 spans a bunch of web apps and Microsoft is now implementing a session timeout to increase app security by protecting “sensitive company data from unauthorized access while providing peace of mind for end users while working on unmanaged and/or shared devices.” Implementing forced sign-outs for browser sessions (together with warnings that a session is about to expire) is a good way of reminding people that they shouldn’t leave apps open if they’re not working in those apps.

According to message center notification MC343441 (March 16 – Microsoft 365 roadmap item 55183), administrators can configure a tenant-wide timeout policy to sign users out automatically when they’re inactive in Microsoft 365 apps. The move to apply consistency in session timeouts across Microsoft 365 web apps is a good idea as different apps use different values today.

Some of the high-profile apps like OWA and SharePoint Online implement their own idle session timeout mechanisms. OWA’s implementation won’t work if people opt for the Azure AD keep me signed in (KMSI) feature while SharePoint’s relies on conditional access policies and Azure AD premium licenses.

Microsoft says that the tenant-wide timeout will eventually take over from these implementations. In fact, if a tenant implements an idle session timeout policy, it takes precedence over the existing OWA and SharePoint Online mechanisms.

The policy complements existing features aimed at making browser access more secure such as continual access evaluation for critical events.

Roll-out

Idle session timeout is a preview feature which is rolling out and should be available worldwide by late March. The current schedule is for the feature to reach general availability in late June, subject to a successful preview. The policy applies to:

• OWA.
• OneDrive for Business.
• SharePoint Online.
• Office.com
• Office web apps.
• Microsoft 365 admin center.

The list is the same as for the new account switcher. The policy currently doesn’t control other web apps like Planner, Yammer, To-Do, and the Teams browser client or other admin centers like the Exchange Online admin center, Teams admin center, and Azure AD admin center. No doubt Microsoft will bring more clients within the scope of the policy over time.

Enabling Idle Session Timeout

By default, the idle session timeout policy is disabled. To implement the policy, go to the Org setting section of the Microsoft 365 admin center, access the Security & privacy tab, and select Idle session timeout. You can then opt to enable the policy and choose a timeout period ranging from one hour to 24 hours, or a custom value from 12 to 1440 minutes (Figure 1).

Interestingly, when the idle session timeout policy is in force, Microsoft says: “users who access Microsoft 365 web apps from an unmanaged device and do not select ‘Stay signed in?’ option at the time of sign-in might start seeing more sign-in prompts.” After testing using both Chrome and Edge, it seemed like it didn’t matter if I selected the stay signed in (keep me signed in) option as all sessions expired. Incognito sessions with the Brave browser saw the imminent expiration warning but never proceeded to expiration. Maybe these experiences are the result of preview glitches that Microsoft will resolve before general availability, but it’s a pointer that if you plan on using idle session timeouts, you might then consider removing the keep me signed in option through company branding.

The Idle Session Timeout Policy in Action

Users affected by the policy will see a notification that their session is about to expire about a minute before the period ends (Figure 2).

If they don’t respond, Microsoft 365 signs them out from all apps controlled by the policy in that browser (Figure 3). Microsoft 365 web apps in other browsers remain unaffected.

Activity means taking client-site actions (like opening a document or listing the contents of a folder) in any of the covered web apps in a tab in a browser. For example, you could have OWA and the Microsoft 365 admin center open and be working in OWA while inactive in the admin center. The activity in OWA is enough for the idle session timeout policy to be invoked.

Idle session timeout is not enforced when users sign into a managed device (defined as one deemed compliant by the organization) using a supported browser (Edge or Chrome with the Windows account extension). However, this scenario depends on using a conditional access policy to detect the managed state of the device.

Configure and Deploy

It makes sense to at least consider configuring an idle session timeout policy. The policy will replace current restrictions and become more powerful as Microsoft adds more web apps to its control. Over time, we’ll gain insight into the best way to use the policy alongside other settings; in the interim there doesn’t seem to be a downside in deploying it now.

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

Feature Can Suppress Sign-in Prompts

Azure AD’s Keep Me Signed In (KMSI) feature uses a persistent cookie to allow users with member accounts in the tenant directory to close and resume browser sessions without needing to sign in again. Azure AD generates the persistent cookie if a user responds affirmatively to the Stay signed in? prompt after a successful authentication (Figure 1). Azure AD uses the persistent cookie to extend the user session (and thus avoid sign-in prompts) and revokes the cookie only after the user signs out.

According to Microsoft’s documentation, Azure AD shows the KMSI prompt only when “it can benefit the user” and doesn’t prompt guest accounts, if Azure AD considers the sign-in risk score to be high, if persistent browser session control is configured in a conditional access policy, and if accounts sign in via SSO or AD FS.

The Value of KMSI

I understand the value of KMSI for users who work with Microsoft 365 apps through browser sessions. Some applications, like Planner, don’t have desktop clients, so you’re forced to use browser or mobile clients. SharePoint Online and OneDrive for Business are also in this category. However, if a high percentage of user interaction with these workloads is through Teams, I wonder how important persistent connectivity is for their browser sessions.

Overall, given the influence of Teams and mobile clients, the argument for facilitating persistent browser sessions weakens. A good case is arguable that it is better to disable KMSI and force users to reauthenticate if they close the browser as this removes the possibility of compromise should an attacker be able to access a workstation. Requiring reauthentication when opening a session to a Microsoft 365 application seems to take the proactive approach to security endorsed by Microsoft in their Zero Trust model. It also seems to be aligned with recent developments such as enabling continual access evaluation for critical Azure AD events in all Microsoft 365 tenants. In a nutshell, it might be true that KMSI is not as valuable as it once was.

Disabling KMSI

Unless you deploy conditional access policies to control browser session persistence, KMSI is either on or off for everyone in a tenant. If you decide to disable KMSI, the way to do so is through Azure AD company branding. Tenants with Azure AD Premium or Office 365 licenses can customize different graphic elements displayed on user sign-in screens, such as the background screen. Company branding is one of those often overlooked features that every tenant should use (Figure 2).

To apply custom branding, go to the Company branding section of the Azure AD admin center. You can then create elements for the default locale or for individual language-specific locales. Azure AD applies the default locale if custom elements aren’t available for a user’s selected language.

Applying custom branding is straightforward and requires just a few graphic files (PNG preferred, JPEG works fine):

• A background image (1920×1080 pixels). This is the type of image used in Figure 2.
• A banner logo (280×60 pixels). This is the type of image used at the top of the Enter password screen in Figure 2.
• Square logo (240×240 pixels). This image appears elsewhere, like the bottom of email notifications sent when users share files.

Azure AD replaces its standard images with the custom images defined in company branding Figure 3 shows the properties for company branding applied to my tenant. The important point for this discission is that the option for users to remain signed in is off (at the bottom of the screen).

When you disable KMSI, Azure AD notes:

Important: some features of SharePoint Online and Office 2010 have a dependency on users remaining signed in. If you hide this option, users may get additional and unexpected sign in prompts.

Given that Microsoft 365 no longer supports Office 2010, you can safely ignore that warning. I cannot find precise details of what SharePoint Online features the removal of KMSI affects, but so far, I have experienced few problems since I removed KMSI. OWA signs out automatically after a period of inactivity and sometimes users need to reenter credentials to keep a SharePoint Online session active, but that seems to be all. The rebuttal is that signing out and forcing users to reauthenticate after they leave browser sessions inactive for a while is a good thing. It’s less convenient for the users, but more secure for the organization,

It’s possible that the Azure AD warning is old and reflects concerns when Microsoft revamped the KMSI implementation in 2018. Although improvements in Azure, federation, and SharePoint Online since 2018 might have eliminated some or all of the difficulties reported in this Microsoft Technical Community discussion, it’s still worth reading to understand some of the complexities involved in authentication.

I obviously can’t test every authentication flow in use by tenants, so it’s important that anyone considering disabling KMSI should conduct a full suite of tests to validate whether this action causes problems for users.

Prioritizing Administrative Effort

One of the joys of working in the Microsoft 365 ecosystem is that there’s always something to investigate and debate. Disabling KMSI is probably an easier decision for cloud-only tenants. Hybrid deployments invariably introduce complications, especially in authentication. In those scenarios, it might be best to leave KMSI in place as there’s probably more urgent matters to deal with than plunging into the minutiae of testing authentication pathways.

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

Microsoft 365 Notifications User Counts Come from the Graph

Message center notification MC315739 (January 18, roadmap item 83946) brings news of a big change for the information included in notifications. Soon, along with the text describing new features or changes to existing Microsoft 365 features, notifications will include service usage data relevant to the change. Deployment starts for targeted release tenants in mid-January and should be complete worldwide for all tenants by mid-February.

Let’s take the change announced in MC302456 as an example. This notification describes how users can maintain their guest accounts in other tenants from Teams. To help administrators understand how many people will be affected by the change, the service communications API queries the Microsoft Graph reports API to retrieve the monthly active user data for Teams and reports this information in the notification.

Figure 1 shows a mock-up included in MC315739 to illustrate how Microsoft 365 notifications highlight user data. On the left, you see a notification for a change affecting multiple workloads together with the usage data for each workload (Outlook is really Exchange Online, but obviously non-Outlook clients can connect to Exchange Online mailboxes). On the right, you see a notification for Kaizala, which doesn’t store its usage data in the Microsoft Graph, so it’s impossible to display this information.

Editorial comment: The need for Kaizala is possibly now much reduced by the general availability of the Teams Walkie-Talkie feature.

The Problem with Microsoft Graph Usage Data

The Microsoft Graph reports API allows access to usage data about some Microsoft 365 services. Coverage is good for base workloads (SharePoint Online, Exchange Online, Teams, and OneDrive for Business) and not so good elsewhere (Planner, Stream, Forms, Whiteboard, etc.). Nevertheless, the usage data is detailed enough to build a picture of user activity over the last ninety days. If you’d like to know how to use the API with PowerShell, consider running the User Activity Analysis script to see how to make calls against the reports API and the kind of data the API returns. For example, this code creates a query to retrieve Teams activity data for users over the last 30 days. Data returned by the reports API is always a few days behind the actual date.

$TeamsUserReportsURI = "https://graph.microsoft.com/v1.0/reports/getTeamsUserActivityUserDetail(period='D30')"

[array]$TeamsUserData = (Invoke-RestMethod -Uri $TeamsUserReportsURI -Headers $Headers -Method Get -ContentType "application/json") -Replace "...Report Refresh Date", "Report Refresh Date" | ConvertFrom-Csv

The data returned by the API is in an array. Here’s the item in the area for an account:

Report Refresh Date        : 2022-01-16
User Principal Name        : Jane.Smith@office365itpros.org
Last Activity Date         : 2022-01-15
Is Deleted                 : False
Deleted Date               :
Assigned Products          : POWER BI (FREE)+ENTERPRISE MOBILITY + SECURITY E5+BUSINESS APPS (FREE)+MICROSOFT POWER AUTOMATE FREE+MICROSOFT VIVA TOPICS+MICROSOFT DEFENDER FOR CLOUD APPS – APP GOVERNANCE+OFFICE 365 E5 WITHOUT AUDIO CONFERENCING
Team Chat Message Count    : 58
Private Chat Message Count : 14
Call Count                 : 1
Meeting Count              : 5
Has Other Action           : No
Report Period              : 30

The data looks good and is useful. However, some workloads (like Teams) return data for both tenant and guest accounts, so the numbers reported in message center notifications will reflect that data. You might be concerned about how a change will affect guest users, but I hazard a guess that most tenant administrators will focus on the effect on tenant users.

Another issue (acknowledged in MC315739) is the non-specific nature of the report. Usage across all clients and all features is included into one workload figure. For instance, a change affecting Microsoft Lists in SharePoint Online and OneDrive for Business might affect just the five people who create and manage Lists, but the notification will say that the change affects everyone who has used SharePoint Online or OneDrive for Business in the last month. You won’t know either if a change is specific to a client platform, like Android or iOS.

Counting all and sundry who use a workload isn’t such a big problem for new features. It is more important for updated features and becomes even more critical when Microsoft deprecates some functionality. You then want to know precisely who is affected, or at least, how many are affected.

Another aspect of an all-up number is that it doesn’t take account of multi-geo deployments. You’ll know that some people in the organization might need to be informed about a change, but not their location.

Still a Good Change

Even with the caveats listed above, including user data in Microsoft 365 notifications is still a good change. If you see a notification where a low number of users will experience an impact, you can probably spend less time preparing for that change and more on changes affecting large user populations. The availability of data through Graph APIs limit what the developers can do to slice and dice usage data to make it more precise and informative. This will probably happen over time. In the interim, take the user information presented in Microsoft 365 notifications as a starting point to help you understand the likely impact of individual changes on users. Use this data in conjunction with your knowledge of the tenant and how people work within the organization, and the monthly active user data for affected workloads will be helpful. Taken as an exact guide, it won’t be.

I guess I might have to update my script to extract and report information from message center notifications to accommodate this change…

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.

Backup In Case Normal Authentication Fails

An obvious difference between cloud and on-premises management is that Microsoft 365 won’t allow you to sign into the console of a physical computer when all else fails and you need to access a server. Not having to go and reboot a server or perform other maintenance to resurrect a failing application is one of the joys of cloud services.

However, sometimes things do go wrong, and normal administrative sign-ins don’t work. It’s possible that an outage might interfere with the ability to sign into Azure AD to access administrator accounts. The most serious kind of outage is when a tenant comes under attack and the attackers change the password for the administrator accounts. A more mundane reason is that someone changes the password of the administrator accounts (perhaps with the best intentions) and promptly forgets. Or that you follow best practice and enable multi-factor authentication (MFA) for all administrator accounts only for the MFA service to go down as happened in November 2018.

To prevent the complete lock out of administrators when bad things happen, it’s a good idea to create one or more break glass accounts (otherwise known as an emergency access accounts). These are highly-permissioned accounts (perhaps holding the global administrator role) intended for use in emergency situations.

Break glass accounts don’t need Microsoft 365 licenses. Their sole role is to perform administrative actions when regular administrator accounts are unavailable. It’s a waste to assign licenses to these accounts as you’ll end up paying monthly fees for zero utility.

Characteristics of Break Glass Accounts

Break glass accounts have the following characteristics:

• Hosted in the cloud: To avoid any dependency on federation with an external or on-premises directory, break glass accounts are cloud objects. The user principal name for the accounts should use the tenant service domain (tenant.onmicrosoft.com). Although it seems logical to use a value like “Break Glass Account” in the user principal names and display names assigned to these accounts, it might be better to obscure their purpose with names that won’t attract attention like “Building Pipeline Maintenance” or something else that won’t attract attention.
• No simple passwords: Multiple layers of authentication such as MFA protect the accounts. However, you should take care to minimize the number of dependencies used by authentication to ensure that the account is available when needed. For instance, you should exclude break glass accounts from conditional access policies to ensure that a policy doesn’t block a signin attempt for the account.
• Varied authentication: To reduce the possibility that a failure blocks access to all break glass accounts, you should vary the authentication methods used for these accounts. Break glass accounts need MFA to access Azure administrative sites and tools. Don’t use SMS-based responses for MFA as the preferred challenge for all accounts. It’s a weak authentication method and a failure of the SMS service will prevent all access. Use a strong authentication method like a FIDO2 key instead and make sure that the keys are stored securely.

In the past, the recommendation was to give break glass accounts passwords that are complex, long, and obscure. Given the need to use MFA to access Azure administrative sites and tools, the need for such a password is reduced. However, multiple layers of security is usually a good idea, so set good passwords for or break glass accounts and store the passwords securely. The details of the storage location and how administrators can access passwords will vary from organization to organization. Some people suggest storing the passwords in fireproof containers in a locked safe. Others recommend dividing passwords up into several parts and storing each part in a separate network location (OneDrive personal, Google Drive, Dropbox, and so on). The important thing is that the process to retrieve break glass account password works, is documented, and audited to prove that it works.

Checking for Break Glass Sign-In Events

After each use of a break glass account, you should change the password. And to make sure that no unauthorized access happens, you should check Azure AD sign-in data periodically to pick up any attempts to log into the accounts. Microsoft documents how to use Azure Monitor for this purpose. The same Kusto queries will work with Microsoft Sentinel.

It’s also possible to run checks against the Office 365 audit log using the Search-UnifiedAuditLog cmdlet. For example, this code runs an audit log search for log in events for two break glass accounts and displays details of any events it finds.

# Identify the accounts to check
$Accounts = "Break.Glass.Account1@office365itpros.onmicrosoft.com", "Break.Glass.Account2@office365itpros.onmicrosoftcom"
$StartDate = (Get-Date).AddDays(-14); $EndDate = (Get-Date).AddDays(1) # Set your own date span here!
[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -Operations UserLoggedIn -UserIds $Accounts -ResultSize 5000
If (!($Records)) {Write-Host "No audit records found - exiting!"; break}
$Events = [System.Collections.Generic.List[Object]]::new() 	
ForEach ($Rec in $Records) {
   $AuditData = $Rec.AuditData | ConvertFrom-Json
   $DataLine = [PSCustomObject] @{
         ClientIP            = $AuditData.ClientIP
         Date                = $Rec.CreationDate
         User                = $Rec.UserIds
         UserAgent           = $AuditData.ExtendedProperties | ? {$_.Name -eq "UserAgent"} | Select -ExpandProperty Value
         OS                  = $AuditData.DeviceProperties | ? {$_.Name -eq "OS"} | Select -ExpandProperty Value
         Browser             = $AuditData.DeviceProperties | ? {$_.Name -eq "BrowserType"} | Select -ExpandProperty Value
        }
    $Events.Add($DataLine) 

}
If ($Events) {
     CLS
     Write-Host "Log in Events for Break Glass Accounts"
     $Events | Select Date, ClientIP, User, UserAgent
>> }

Log in Events for Break Glass Accounts

Date                ClientIP       User                                                  UserAgent
----                --------       ----                                                  ---------
10/01/2022 17:48:31 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:31 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:29 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:29 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....
10/01/2022 17:48:28 51.171.212.129 Break.Glass.Account1@office365itpros.onmicrosoft.com Mozilla/5.0 (Windows NT 10....

Multiple signin events for an account over a short period of time are not unusual. Teams, for instance, has a habit of generating multiple events when a user connects. The important thing is that evidence exists of sign-in activity for an account which should not be signing in. This deserves immediate investigation.

Not for Everyday Use

Hopefully, you never have to use a break glass account to rescue a tenant. Touching every available piece of wood in the immediate vicinity, I have never had to use my break glass account. But it’s there and waiting. Just in case.

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 development as they happen.

Use Teams, PowerShell, or the Graph

Vasil Michev, the Technical Editor of the Office 365 for IT Pros eBook, comes up with all sorts of weird and wonderful insights into Microsoft 365. A recent question he discussed on his blog was how to find the creation date for a tenant. It’s a good question because it forces respondents to know where to look for this information and is exactly the kind of poser we like to tease out as we write content for the book.

As Vasil points out, the obvious answer is to fire up the Teams admin center because the tenant creation date appears on a card displayed on its home screen (Figure 1). The Teams admin center is the only Microsoft 365 portal which shows this information. Why the Teams developers thought that it was useful to highlight the tenant creation date is unknown. After all, the date won’t change over time and static information is not usually featured by workload dashboards.

Opening an administrative portal is no challenge. Vasil suggests several alternate methods to retrieve the tenant creation date. It seemed like fun to try some of these methods against my tenant. Here’s what I found.

Using Exchange Online Data

If you’ve used Exchange Online from the start, you can check the creation date of the Exchange organization configuration object, created when an administrator enables Exchange Online for the first time.

(Get-OrganizationConfig).WhenCreated

Monday 27 January 2014 20:28:45

It’s an interesting result. Exchange Online reports its initiation in January 2014 while Teams is quite sure that the tenant existed in April 2011. I’ve used Exchange Online for email ever since I had a tenant, so the disconnect between Exchange Online and the tenant creation date is interesting.

Another way of checking Exchange data is to look at the creation dates for mailboxes. This PowerShell snippet finds all user mailboxes and sorts them by creation date. The first mailbox in the sorted array is the oldest, so we can report its creation date:

[array]$Mbx = Get-ExoMailbox -ResultSize Unlimited -Properties WhenCreated -RecipientTypeDetail UserMailbox | Sort {$_.WhenCreated -as [datetime]} 
Write-Host ("The oldest mailbox found in this tenant is {0} created on {1}" -f $Mbx[0].DisplayName, $Mbx[0].WhenCreated)

The oldest mailbox found in this tenant is Tony Redmond created on 27/01/2014 20:36:38

(Dates shown are in Ireland local format. The equivalent U.S. format date is 01/27/2014).

Grabbing all mailboxes to check their creation date will not be a fast operation. Even using the REST-based Get-ExoMailbox cmdlet from the Exchange Online management module, it will take time to retrieve all the user mailboxes in even a medium size tenant.

As it turns out, the oldest mailbox is my own, created about eight minutes after the initiation of Exchange Online. However, we’re still in 2014 when the tenant proclaims its creation in 2011, so what happened?

A search through old notes revealed that Microsoft upgraded my original Office 365 tenant created in 2011 to an enterprise version in 2014. It seems that during the tenant upgrade, Microsoft recreated the instance of Exchange Online. That explanation seems plausible.

Administrator Accounts

Another method is to examine the creation dates of administrator accounts to find the oldest account. This is usually the administrator account created during tenant setup. In other words, when you create a new tenant, you’re asked to provide the name for an account which becomes the first global administrator. If we look at the administrator accounts in the tenant and find the oldest, it should be close to the tenant creation date shown in the Teams admin center. That is, unless someone deleted the original administrator account.

Azure AD is the directory of record for every Microsoft 365 tenant, so we should check Azure AD for this information. The steps are:

• Find the set of accounts which currently hold the global administrator role. We omit the account returned with the object id 25cbf210-02e5-4a82-9f5c-f41befd2681a as this is a service principal used by Microsoft Rights Management services (you can confirm this by running Get-AzureADServicePrincipal -ObjectId 25cbf210-02e5-4a82-9f5c-f41befd2681a).
• Check each account to find the creation date. This is slightly complicated when using the Azure AD PowerShell module because the creation date is part of the extension properties. We therefore use the Get-AzureADUserExtension cmdlet to extract the date and then store it in the array used to hold details about tenant administrators.
• Sort the accounts by creation date and report the oldest.

Here’s the code I used:

# Find the identifier for the Azure AD Global Administrator role
$TenantAdminRole = Get-AzureADDirectoryRole | Where-Object {$_.DisplayName -eq ‘Global Administrator’} | Select ObjectId
# Get the set of accounts holding the global admin role. We omit the account used by
# the Microsoft Rights Management Service
$TenantAdmins = Get-AzureADDirectoryRoleMember -ObjectId $TenantAdminRole.ObjectId | ? {$_.ObjectId -ne "25cbf210-02e5-4a82-9f5c-f41befd2681a"} | Select-Object ObjectId, UserPrincipalName
# Get the creation date for each of the accounts
$TenantAdmins | ForEach-Object { $_ | Add-Member -MemberType NoteProperty -Name "Creation Date" -Value (Get-AzureADUserExtension -ObjectId $_.ObjectId ).Get_Item("createdDateTime") }
# Find the oldest account
$FirstAdmin = ($TenantAdmins | Sort-Object {$_."Creation Date" -as [datetime]} | Select -First 1)
Write-Host ("First administrative account created on {0}" -f $FirstAdmin."Creation Date")

The older Microsoft Online PowerShell module doesn’t require such a complicated approach to retrieve account creation data. Taking the code shown above and replacing the Get-AzureADUserExtension cmdlet with Get-MsOlUser, we get:

$TenantAdmins | ForEach-Object { $_ | Add-Member -MemberType NoteProperty -Name "Creation Date" -Value ((Get-MsOlUser -ObjectId $_.ObjectId ).WhenCreated) }

Using either cmdlet, the result is:

First administrative account created on 11/04/2011 17:35:11

The Teams admin center also reports April 11, 2011, so using administrator accounts might be a viable way to determine tenant age.

Use the Graph

Microsoft 365 stores information for each tenant in the Microsoft Graph, and it’s the Graph which is the source for the Teams admin center. We can retrieve the same information by running the https://graph.microsoft.com/V1.0/organization Graph query. The createdDateTime property returned in the organization settings is what we need.

Here’s the PowerShell code to run after obtaining the necessary access token for a registered app, which must have consent to use the Organization.Read.All Graph permission. Vasil used the beta endpoint when he showed how to fetch tenant organization settings using the Graph Explorer (which saves the need to write any code), but the V1.0 endpoint works too.

$Uri = "https://graph.microsoft.com/V1.0/organization"
$OrgData = Invoke-RESTMethod -Method GET -Uri $Uri -ContentType "application/json" -Headers $Headers
If ($OrgData) {
  Write-Host ("The {0} tenant was created on {1}" -f $Orgdata.Value.DisplayName, (Get-Date($Orgdata.Value.createdDateTime) -format g)) }

The Redmond & Associates tenant was created on 11/04/2011 18:35

The first administrator account appears to date from 17:35 while the tenant creation time is an hour later. This is easily explained because all dates stored in the Graph are in UTC whereas the dates extracted from Azure AD and reported by PowerShell reflect local time. In April 2011, local time in Ireland was an hour ahead of UTC.

An Old Tenant

After all the checks, it’s clear that I created my tenant in the early evening of April 11, 2011. Given that this was ahead of Microsoft’s formal launch of Office 365 in July 2011, I can claim to use an old tenant, for what that’s worth.

Do You Really Want Individual Users to Submit Feedback?

The Teams Feedback policy controls whether users can give Microsoft direct feedback and answer periodic surveys. The Give feedback option is available in the Help section of the Teams desktop, browser (Figure 1), and mobile clients. If allowed by policy, Microsoft posts surveys to ask users to rate their experience with Teams in the desktop and browser clients.

The feedback policy is one of the 40-odd policies used by Teams to manage different aspects of the application. No sign of the feedback policy appears in the set of policies managed through the Teams admin center. Instead, you must manage the policy using PowerShell, which might be the reason why its existence appears to be unknown to many tenant administrators.

Support Data

According to Microsoft’s documentation for feedback policies, they consider the information submitted when users give feedback as support data “under your Office 365 or Microsoft 365 agreement.” I assume this refers to the definition of diagnostic data shown in the Trust center (How Microsoft categorizes data for online services). I can’t find a definition for support data, but the summary for the page mentions support data, so that’s what we can go with.

Microsoft’s documentation for feedback policies says that the policy is a preview or early release feature. However, the policy has been around since late 2019 (see this discussion in the Microsoft Technical Community), so this is likely a false assertion. Or the feature is very delayed. According to the same documentation, feedback policies aren’t available in the GCC, GCC High or DoD clouds. And in Teams for Education, the options to submit feedback and suggest features are limited to teacher accounts.

Submitting Feedback

Submitting feedback is easy. Click the Give feedback option, enter the feedback in a pop-up screen (Figure 2), and send the data off to Microsoft.

Note the assertion on the screen that “Your IT admin will be able to collect this data.” It’s a curiously imprecise assertion. Does it mean that tenant administrators see the feedback submitted by users or just an audit event to say that a user submitted feedback? In any case, tenant administrators can find feedback submitted to Microsoft in the Product feedback section under Health in the Microsoft 365 admin center (Figure 3).

Feedback can be downloaded in a CSV file and analyzed to your heart’s content.

Blocking Feedback

Although admins can see where user feedback is posted, I still don’t like the idea of individual users submitting feedback to Microsoft. The view of an individual seldom reflects the priorities of the organization, and I think it is better for an organization to submit its feedback to Microsoft after gathering evidence, analyzing requirements, and understanding the impact of what changes in existing features or additional functionality they would like. I also think that it’s best to post suggestions for change in the Teams feedback portal. In fact, if you use the Suggest a feature option, that’s where the link takes you.

If you agree with my view, you’ll want to:

• Update the existing Global (default) policy to remove the options to give feedback and respond to surveys. Alternatively, Teams includes a feedback policy called Disabled for assignment to users whom you don’t want to submit feedback.
• Create a new feedback policy with the features disabled and assign it to the users who you do want to give feedback. Creating a new policy gives the tenant full control over its settings.

First, here’s how to check the available feedback policies by running Get-CsTeamsFeedbackPolicy:

Get-CsTeamsFeedbackPolicy | format-Table Identity, UserInitiatedMode, ReceiveSurveysMode

Identity       UserInitiatedMode ReceiveSurveysMode
--------       ----------------- ------------------
Global         Enabled           EnabledUserOverride
Tag:UserChoice Enabled           EnabledUserOverride
Tag:Enabled    Enabled           Enabled
Tag:Disabled   Disabled          Disabled

• Enabled (can submit feedback) or Disabled (doesn’t see the Give feedback option in clients).
• ReceiveSurveysMode controls if Teams surveys the user. If Enabled, Teams can survey the user. If EnabledUserOverride, Teams can prompt the user to take a survey and the user can then opt out. Disabled means that Teams can’t survey the user.

To assign the Disabled feedback policy to users, run the Grant-CsTeamsFeedbackPolicy cmdlet:

Grant-CsTeamsFeedbackPolicy -Identity Jack.Smith@Office365itpros.com -PolicyName Disabled

Unfortunately, Teams bulk policy assignment does not support feedback policies. If you want to assign the Disabled feedback policy to a bunch of users, an easy approach is:

• Run the Get-CsOnlineUser cmdlet to extract the SMTP addresses for Teams users.
• Export the data to a CSV file.
• Edit the CSV file to remove the users whom you don’t want to block.
• Assign the Disabled feedback policy to the remaining users.
• Check that accounts have the correct feedback policy.

Here are the PowerShell commands:

# Extract Teams user data
[array]$Users =Get-CsOnlineUser | Select-Object UserPrincipalName
# Export data to CSV
$Users | Export-CSV -NoTypeInformation c:\temp\Users.csv
# After editing the CSV, import back into an arra
Users = Import-CSV c:\temp\Users.csvy
# Assign the Disabled feedback policy to all users loaded from the CSV file
ForEach ($User in $Users) { Grant-CsTeamsFeedbackPolicy -Identity $User.UserPrincipalName -Policy Disabled }
# Check that the assignment works
Get-CsOnlineUser | ? {$_.TeamsFeedbackPolicy -eq "Disabled"} | Format-Table DisplayName, TeamsFeedbackPolicy

DisplayName          TeamsFeedbackPolicy
-----------          -------------------
HR Coordinator       Disabled
Nestor Wilke         Disabled
Miriam Graham        Disabled
HR Management        Disabled
Lee Gu               Disabled
Diego Siciliani      Disabled

To create a custom Teams feedback policy, run the New-CsTeamsFeedbackPolicy cmdlet

New-CsTeamsFeedbackPolicy -Identity "Tenant Enabled Feedback" -UserInitiatedMode Enabled -ReceiveSurveysMode EnabledUserOverride

You can then assign the new policy to the accounts you want to allow to submit feedback to Microsoft. Remember that you need to assign the appropriate feedback policies to new accounts after their creation.

Not Against Feedback

I’m not against the idea of providing feedback to Microsoft to improve their products. I give feedback on an ongoing and continuous basis, as many a Microsoft product manager can testify. I am against individual user feedback unless the organization has an opportunity to curate and assess the feedback. If an organization wants to do this, it’s easy to create a public team and ask people to submit and discuss their feedback there before giving Microsoft the collective wisdom gathered through internal debate.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

From September 1, Pseudonymized by Default

MC275344 (published August 3, updated August 31, Microsoft 365 roadmap item 81959) deals with the topic of anonymization of user information in Microsoft 365 usage reports. Until now, the situation has been that the usage reports show full usage data, including details of user principal names and group names with an option for the tenant to choose pseudonymized information. In this situation, anonymized values like A6968D016DB2256910FD3B85B4B0457B replace user or group identifiable information in the reports. You can still understand the overall context of the report and what it tells you about the usage pattern for a workload like SharePoint or Teams, but you can’t dive down into the detail at user level.

Microsoft says that de-identifying user data will help tenants support local privacy laws. The changeover to use anonymized data by default came into effect on September 1, 2021. Users with access to report data now see values like those shown in Figure 1.

Reverting to Real User Data

If you want to revert to see real user information in usage reports, a global administrator can switch through the Reports section of Org-wide settings by clearing the checkbox shown in Figure 2.

Updating the setting captures an UpdatedCFRPrivacySettings audit record. For instance, here’s an edited version of the audit record captured when I enabled identifiable user information in usage reports.

RecordType   : CoreReportingSettings
CreationDate : 06/09/2021 19:37:55
UserIds      : Tony.Redmond@office365itpros.com
Operations   : UpdatedCFRPrivacySettings
AuditData    : {
                 "ModifiedProperties": [
                   {
                     "Name": "PrivacyEnabled",
                     "OldValue": "True",
                     "NewValue": "False"
                   }
                 ],
                 "Id": "639e2bcc-eba9-4146-8885-333622ffb4b0",
                 "RecordType": "CoreReportingSettings",
                 "CreationTime": "2021-09-06T19:37:55",
                 "Operation": "UpdatedCFRPrivacySettings",
               }

Access to User Information Limited to Certain Roles

In the past, this would have been sufficient to let any account holding an administrative role with access to usage data to see user information. This is not now the case as Microsoft has made a further change to confine the ability to see user information to “administrative and report reader roles.”

In effect, this means that roles like:

• Global administrator.
• Exchange administrator.
• SharePoint administrator.
• Teams administrator.
• User administrator.
• Helpdesk admin.
• Service support admin, and:
• Reports reader.

Can see user information (anonymized or real as selected by the tenant setting), but other administrative roles such as Usage summary reports reader or Global reader, which used to be able to see user information, no longer have access. Users with these roles see only summary graphs (Figure 3).

Governs Programmatic Access Too

The change affects usage reports in the Microsoft 365 admin center and the Teams admin center. It also affects programmatic access to usage data through the Microsoft Graph usage reports API, including SharePoint site detail. This is because the usage reports API is the basis for reporting across Microsoft 365.

As noted when Microsoft originally introduced anonymized user data for reports, if the organization generates its own version of usage reports like my Office 365 User Activity Report, you’ll need to make sure to generate the report using an account with a suitable administrative role. Identifiable user data makes these kinds of reports much more valuable, especially if you use the reports to analyze usage patterns based on departments, locations, and workloads, and if you want the reports to contain this information, the org-wide setting to allow identifiable user data must be enabled when the report runs. Arranging for this to be done if the organization decides to use anonymized user information for reporting could be a challenge!

Good for Privacy

There’s no doubt that this is a good step from the perspective of privacy advocates. However, I wonder if obscuring information about how people use technology at the level of detail available in the Graph (like the number of emails sent and read, or Yammer conversations created) will make it harder for administrators to do their job. I agree with the move to restrict access to detailed information to the more highly privileged administrative roles, but wonder how many organizations will try to use anonymized user information before reverting because good reason exists to access detailed data.

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.

Expanding the Scope of Microsoft Viva

Message Center notification MC282545 (published September 2) announces the expansion of the Microsoft Viva brand to replace the Insights moniker used for MyAnalytics, Outlook Insights, and the Cortana daily briefing email. It’s all part of the strategy to bring the technology used to analyze signals gathered from user activity within Microsoft 365 under the Microsoft Viva brand.

Viva Insights is the new name in town for insights derived from user email and calendar activity. This trend has already surfaced in the Viva Insights app for Teams, which surfaces the same user-based analysis of behavior as available in MyAnalytics, wrapped up with some mediation and mindfulness videos and audios from Headspace and some additional functionality for a virtual commute to close the working day.

What’s Happening in the Viva Insights Rebrand

In practical terms, the announcement means:

• The daily briefing message from Cortana now comes from Viva. Microsoft says that the content will be expanded with recommendations to help users prepare for the day and week ahead.
• The MyAnalytics digest will now come from Microsoft Viva and be delivered monthly rather than weekly. The first edition of the digest (Figure 1) turned up in my (targeted release) tenant. on September 5. Microsoft says that the new digest will “aggregate insights across these four outcomes: focus, wellbeing, network, and collaboration.” Like the weekly digests from MyAnalytics, the monthly digests are injected directly into user mailboxes and don’t pass through the Exchange Online transport system, which means that they’re not subject to inbox or transport rules.

• A new Viva Insights home page will be available to Microsoft 365 users.
• The Outlook Insights add-in will be rebranded as Viva Insights.
• The MyAnalytics settings available in the Microsoft 365 admin center (Figure 2) to control the defaults for new accounts will soon have the Microsoft Viva branding. The same will happen for the MyAnalytics user dashboard where individual users can see insights derived from their activity and control if they can access the dashboard, receive the monthly digest, and use the Outlook insights add-on.

Microsoft says that the changeover and rebranding should be complete in all tenants by the end of November.

Controlling User Insights Settings

The Viva rebranding will respect existing user and admin settings. To control the settings for individual users (mailboxes), you can:

Turn Viva Analytics on or off for individual mailboxes by running the PowerShell code in this article. Users can re-enable Analytics afterwards if they wish. As explained in the article, administrators can use the Set-MyAnalyticsFeatureConfig cmdlet to remove access to individual features. For instance, many users don’t like the twice-monthly digest message containing an analysis of personal work patterns. You can block the digest email while allowing users access to the Analytics dashboard and Outlook add-in by running a command like:

Set-MyAnalyticsFeatureConfig -Identity Vasil.Michev@office365itpros.com -PrivacyMode "opt-in" -Feature digest-mail -IsEnabled $False

Remove the Insights by MyAnalytics service plan from individual user licenses using the PowerShell script described in this article. It’s likely that Microsoft will rename the service plan in the future to reflect the Viva brand. Users cannot reenable Analytics after the service plan is removed from a license.

We don’t know yet if Microsoft plans to rename the Set-MyAnalyticsFeatureConfig and Get-MyAnalyticsFeatureConfig cmdlets (in the Exchange Online management PowerShell module) used to control individual mailbox settings. It wouldn’t surprise me if this happened or if Microsoft combined the controls with those exposed by the Set-VivaInsightsSettings cmdlet, currently only used to configure access to the Headspace feature.

Item Insights

Although the information extracted from user email and calendar activity now comes under the aegis of Microsoft Viva, the same is not true (yet) for the document (item) insights used in apps like Delve and the Office 365 profile card. If you want to disable item insights for user accounts, you need to update the tenant configuration using the Microsoft Graph by following the advice contained in this article.

Sensible Rebranding?

Branding exercises can be confusing (think of the absolute clarity Microsoft achieved when it renamed Office 365 Pro Plus to Microsoft 365 apps for enterprise). In this instance, it probably makes sense to bring everything relating to email and calendar insights together under the Viva brand. Come November, it probably won’t make a different as those who use insights won’t care too much that they then have the Viva moniker.

Learn more about how Office 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 Office 365 ecosystem.

Videos and Slides Available to All

The Experts Conference (TEC) 2021 took place using a mixture of Teams Live Events and online meetings over September 1-2. The TEC organizers have posted videos and slides of the presentations online for all to access.

Naturally, you’ll check out my session on Leveraging the Graph to Manage Microsoft 365 (video and slides). While many of the topics covered in the session have also appeared in articles, there’s nothing like making a pitch on important topics like this to force you to think through the value of the subject.

Many other useful sessions are also available – certainly enough for anyone to find some nuggets of information. I’ve pointed to a set of sessions that I like here, including interesting talks about the Microsoft 365 substrate, Azure AD futures, and defending your company against sophisticated cyberattacks.

Looking Forward to TEC 2022 in Atlanta

The Experts Conference 2022 takes place September 20-21, 2022, in the Loews Atlanta Hotel. Although Teams has served as a worthy platform for TEC 2020 and TEC 2021, it will be great to get back to an in-person conference. Many great speakers have already been lined up, and the combination of talent and in-person interaction should make TEC 2022 a fantastic event to attend. Super early bird registration for TEC 2022 ends Feb 28, 2022, and costs $350. The registration gradually increases to $799, so this is a good example of getting in early to save money.

I look forward to meeting many Office 365 for IT Pros subscribers at TEC 2021 in Atlanta.

Controlling Document Insights

The Microsoft Graph Insights API proves different views of users and documents:

• Trending: Documents a user has access to which are popular with other users.
• Used: Documents a user has accessed recently.
• Shared: Documents shared with a user, including email and attachments in calendar appointments.

Insights are consumed by many apps and Microsoft 365 components such as MyAnalytics, Workplace Analytics, Viva Insights for Teams, and the Office 365 profile card. Figure 1 is a Microsoft graphic to explain the use of the Insights API and its value to “drive productivity and creativity in businesses.”

Delve and Sharing

Delve was the first app to surface insights, but used Office Graph settings to allow users to decide if they wanted to reveal information about their document-centric activities. Some users never want details of their work exposed, even to people who have access to documents, because they either don’t see the need or because they wish to preserve the confidential nature of the information they work with. They can protect content by assigning a sensitivity label with encryption to confidential documents, but this won’t stop document metadata like titles showing up in insights. The feature settings for Delve therefore have a slider to control showing documents in Delve (trending, used, and shared). When the slider is Off, Delve blocks insights based on documents (Figure 2).

Moving to the New Graph Sharing Controls

In April, I wrote about how Microsoft is replacing Office Graph controls over Item Insights with Microsoft Graph controls. The change is now effective in Microsoft 365 tenants and mean that instead of user-driven control over how the Insights API reveals information, a tenant has:

• An organization-wide setting to control insights privacy (isEnabledInOrganization). This is True if controls are active in the organization or False if not.
• An Azure AD group to control the set of accounts who do not want to use insights (disabledForGroup). Individual users can disable insights through the Privacy options of their MyAccount page. However, this does not add their account to the group.

Access to these settings is available through the Search & Intelligence section of the Microsoft 365 admin center (Figure 3).

The question arises how to find the current set of accounts with the option disabled in Delve so that you can add the accounts to the Azure AD group. As it happens, I was asked this question by a Microsoft customer engineer who wanted to help their customer move to the new Microsoft Graph controls.

The first step is to find the set of accounts with Delve insights disabled. This cannot be done with PowerShell only because no cmdlet exists to retrieve the value of the Delve setting. Instead, we can combine PowerShell with a call to the Graph Users API. Here are the steps:

• Get a set of accounts to check. This can be done with Get-ExoMailbox or Get-AzureADUser. We need the object identifier to make the Graph call. Either of these cmdlets wll return the necessary identifiers. I like the mailbox cmdlet because it has better filtering capabilities.
• Loop through the set of accounts and check the value of the Delve setting (contributionToContentDiscoveryDisabled). If True (insights are disabled), report the account.
• Generate whatever output is required (I usually create a CSV file because of its flexibility).

You can download the script I used to report users with Delve insights disabled from GitHub.

Updating the Group

The next step is to review the report and decide which accounts to add to the Azure AD group used to control item insights. To review the data, open the CSV file generated by the script (Figure 4), and remove any accounts which should not be added to the control group.

We can then use the updated CSV file as the input for a script which:

• Retrieves some tenant details.
• Retrieves the current privacy control settings from the Graph.
• Fetches the current membership of the group (we assume here that one is specified).
• Import the set of accounts from the CSV file.
• Loop through the accounts and add them to the Azure AD group if not already a member.

The essential code to fetch the settings from the Graph and update the membership of the control group looks like this:

$InputCSV = "c:\temp\DelveDisabledAccounts.csv"
$TenantDetails = Get-AzureADTenantDetail
$TenantId = $TenantDetails.ObjectId
$TenantName = $TenantDetails.DisplayName
$Uri = "https://graph.microsoft.com/beta/organization/" + $TenantId + "/settings/iteminsights"
$Settings = Invoke-RestMethod -Uri $Uri -Method Get -ContentType "application/JSON" -Headers $Headers -UseBasicParsing

If ($Settings.isEnabledInOrganization -ne $True) {
   Write-Host "Insights control setting not set for" $TenantName ; break }
Else {
   $DisabledGraphInsightsGroup = $Settings.disabledForGroup }

[array]$CurrentMembers = Get-AzureADGroupMember -ObjectId $DisabledGraphInsightsGroup | Select -ExpandProperty ObjectId

Write-Host "Adding users to the Disabled Graph Insights Group"
$Users = Import-CSV $InputCSV
ForEach ($User in $Users) {

   If ($User.ObjectId -notin $CurrentMembers) {
      Write-Host "Adding" $User.Name
      Add-AzureADGroupMember -ObjectId $DisabledGraphInsightsGroup -RefObjectId $User.ObjectId }
}

I haven’t published a script to GitHub for this purpose because the code is straightforward and simple to plug into an existing script (or add to the bottom of the script mentioned above). Happy Insights!

Learn more about how Office 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 Office 365 ecosystem.

Aiming for Workload-Agnostic Retention

Exchange and SharePoint on-premises servers both included retention processing. Exchange’s Messaging Records Management (MRM 2.0) persists today in the form of mailbox retention policies. Microsoft 365 retention policies, first introduced in 2017, replaced SharePoint’s equivalent (here’s an example of SharePoint retention in use) as part of a strategy to implement workload-agnostic data governance. In other words, deploy Microsoft 365 retention processing that worked for all workloads.

The initial implementation of retention policies (and classification labels, as Microsoft then called retention labels) supported Exchange Online (including public folders), SharePoint Online, OneDrive for Business, and Skype for Business Online.

Compliance Records and Microsoft 365 Retention Processing

Teams was the first Office 365 application to store compliance records in Exchange Online mailboxes. Compliance records are mail items created to capture details of chats and channel conversations, including messages sent by people who don’t have Exchange Online mailboxes like on-premises users, guest accounts, and external (federated) users (the substrate stores these messages in special cloud-only mailboxes). Yammer adopted the same mechanism in 2020, but only for networks configured in Microsoft 365 native mode. Planner announced that they would follow likewise but have not yet delivered this capability.

If you check the number of compliance items in your mailbox, you might find that you have more than you imagine. Most of my chatting happens in other tenants, but even so, I have quite a few compliance records for Teams chats (and fewer for Yammer conversations). Exchange Online doesn’t charge the storage consumed by these messages against user mailbox quotas.

$Folders = Get-ExoMailboxFolderStatistics -Identity Tony.Redmond@office365itpros.com -IncludeOldestAndNewestItems -FolderScope NonIPM
$Folders | Where-Object {$_.Name -eq "TeamsMessagesData" -or $_.Name -eq "Yammer"}| Format-Table Name, ItemsInFolder, FolderSize, NewestItemReceivedDate -AutoSize

Name              ItemsInFolder FolderSize                     NewestItemReceivedDate
----              ------------- ----------                     ----------------------
Yammer                      330 4.144 MB (4,344,857 bytes)     23/08/2021 08:23:50
TeamsMessagesData         14815 1.547 GB (1,660,565,924 bytes) 23/08/2021 17:22:38

Like any other Exchange Online content, Microsoft Search includes the compliance records in its indexes, which makes the records available for eDiscovery. Communications compliance policies also process compliance records to detect policy violations such as threatening or offensive behavior.

In addition to their role in eDiscovery, compliance records are the basis for retention processing for their originating workloads. Instead of having to create separate jobs to apply retention policies against the workload repositories, a single processing job runs against the compliance records and synchronizes policy actions such as removing items with the workloads.

Originally, the Exchange Managed Folder Assistant (MFA) processed the Teams compliance records. This was a pragmatic step because MFA could process the compliance records along with other mailbox content and avoided the need to create a special retention assistant for Teams. When MFA processed Teams content, it synchronized the results back to Teams, which applied the deletions to its Cosmos DB-based message store. Teams clients then picked up the changes from the message store and removed items in local caches.

The implementation worked well for Teams channel conversations and chat messages, but a better solution was needed to deal with the growth of workloads supporting retention policies and the need to process special cases like conversations in Teams private channels. To solve the problem, Microsoft implemented a specific background assistant to handle retention processing for all Microsoft 365 workloads except Exchange Online (Exchange is different because it supports both the older mailbox retention policies in addition to Microsoft 365 retention policies).

The Retention Assistant and the Microsoft 365 Substrate

Today, the retention assistant evaluates retention policies against OneDrive for Business, SharePoint Online, Yammer, and Teams using the “digital twins” of workload items stored in the Microsoft 365 substrate. Digital twins are copies of content stored in the Microsoft 365 substrate (in Exchange Online) to make it easier for shared services like Search and artificial intelligence services to process items. It’s much easier for a service to process items in a single place than having to deal with multiple repositories, each requiring a different interface (API).

In some cases, the digital twins are not complete copies, but they’re sufficient to allow shared services to operate efficiently and effectively. If you want to hear more about how the substrate works, consider signing up for TEC 2021 to hear Microsoft CTO for Modern Workplace Transformation Jeffrey Snover discuss the topic.

Substrate items coming within the scope of retention policies are subject to retention periods and actions. As the assistant processes items, it checks if the item’s retention period has lapsed, and if this is the case, invokes the retention action. This could involve additional processing, like putting the item into a manual disposition cycle, or it could be a simple delete action. The assistant interacts with the underlying workloads to ensure compliance with retention policy actions. For instance, if the assistant determines that the retention period for a document stored in a SharePoint Online document library has expired, it instructs SharePoint Online to move the document into the site recycle bin.

The Black Box of Microsoft 365 Retention Processing

Although it’s possible to track the processing done by MFA for mailbox items, Microsoft has not yet made an equivalent capability available for the retention assistant. This means that administrators who want to validate the effectiveness of retention processing need to make manual checks of content in repositories like SharePoint Online sites to ensure that items which should retention policies should remove are no longer present. As evident in this useful flowchart, understanding how retention policies process items can be a complex business, especially when locations like sites or teams come within the scope of multiple policies.

Making sense of complex retention policies is why the retention assistant exists. I’m sure it does its job very well. It would just be nice to be able to validate and understand exactly what actions the assistant takes for different locations. Is that too much to ask?

Learn more about how Office 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 Office 365 ecosystem.

Remove Service Plan PowerShell to Manage User Functionality

Note: This post is now obsolete. Please see this article for an updated approach to the problem.

Service plans are non-saleable elements of a Microsoft licensable product (SKU or stock keeping unit). SKUs are what people often think of when they discuss licenses. Individual Microsoft 365 accounts can have multiple SKUs, such as TOPIC_EXPERIENCES, ENTERPRISEPACK, and EMSPREMIUM. The product names for these SKUs are Viva Topics, Office 365 E3, and Enterprise Mobility and Security E5. Product names appear in places like the Billing section of the Microsoft 365 admin center (Figure 1).

At a more granular level, a “bundled” SKU like Office 365 E3 includes multiple service plans, each of which enable access to some functionality like an app. This page lays details the connections between SKUS and service plans.

At the time of writing, Office 365 E3 covers 28 service plans and Office 365 E5 has 53. Office 365 E5 includes service plans to license capabilities like advanced compliance features, customer lockbox, advanced auditing, content explorer, server-based auto-labeling for sensitivity labels and retention labels, records management, and information barriers.

Microsoft introduces new service plans to enhance its ability to license new features to different user communities or to provide control over user access to a new feature. Teams is a good example. The Teams service plan (TEAMS1) is in many Office 365 and Microsoft 365 SKUs. In April, Microsoft announced they would add the Teams Pro service plan to some SKUs and will use the Teams Pro service plan to allow accounts licensed with those SKUs to access new features. To date, Microsoft has not added the Teams Pro service plan to any SKU in my tenant nor have they described what features the new service plan will cover.

Reviewing Available Service Plans

In some cases, tenant administrators might not want users to be able to access a licensed app or capability. Perhaps the feature is obsolete, or the organization has different software to do the same thing, or maybe a delay is necessary to enable preparation of training, documentation, and support. Some years ago, Microsoft made a big thing about Kaizala and its impending integration into Teams. Kaizala is now an obsolete feature that’s still available in Office 365 E3 and E5. Sway is in the same category. Microsoft Bookings is an optional feature which isn’t often used by enterprise users, but it’s also part of Office 365 E3 and E5. In short, when you review the set of service plans bundled into Office 365 and Microsoft 365 SKUs, you might be surprised at the amount of unwanted debris in the mix.

Removing Individual Service Plans

Let’s say that we want to remove individual service plans from SKUs assigned to users. This post describes how to report the accounts assigned individual service plans (licenses) and explains how Azure AD stores the service plan information in user accounts. We want to go further by removing access to selected service plans, and as it turns out, we must use cmdlets from the older Microsoft Online Services module to get the job done. It’s possible to use the Set-AzureADUserLicense cmdlet to remove a service plan from an account. Laziness and the availability of some existing code to do the job stopped me using this cmdlet.

In any case, I wrote a script to demonstrate the principle of the steps to remove an individual service plan from multiple Microsoft 365 accounts. Three versions are available.

• Using Microsoft Online Services cmdlets to remove service plans (download the full script from GitHub).
• Using Azure AD cmdlets (download the Azure AD version from GitHub).
• Using Microsoft Graph PowerShell SDK cmdlets (download the Graph SDK version from GitHub).

Given that Microsoft deprecated the licensing management cmdlets in the MSOL and Azure AD modules in 2023, it makes sense to focus on the version based on the Microsoft Graph PowerShell SDK.

The major steps to remove a service plan from Azure AD licenses with PowerShell are:

• Determine the set of SKUs (products) available in the tenant.
• Select the SKU to remove a service plan from. A tenant might use many SKUs, so we read the information with Get-AzureADSubscribedSKU (or Get-MgSubscribedSku) and ask the administrator to choose a SKU.
• Select the service plan from the chosen SKU to remove. This is a matter of reading the service plans from the SKU and asking the administrator to choose one.
• Select the target accounts. I use Get-ExoMailbox to fetch a set of user mailboxes because this cmdlet supports a wide range of server-side filters (for instance, everyone in a country or department). The important thing is that you fetch the Azure AD object identifiers for the target accounts. The Microsoft Graph PowerShell SDK version doesn’t use Exchange Online because it reads the licensed account information direct from Azure AD.
• Access each account (using its object identifier) and remove the service plan. The MSOL version does this by running the Set-MsolUserLicense cmdlet. The Azure AD version uses the Set-AzureADUserLicense cmdlet, while the Graph SDK uses Set-MgUserLicense.
• Report the service plans removed from SKUs assigned to the target mailboxes.

Figure 2 shows the MSOL version of the script in action. You can see the selection of the service domain, SKU, and service plan and processing of user accounts. In this case, the selected options remove the Sway service plan from the ENTERPRISEPACK (Office 365 E3) SKU.

The report output is a CSV file. Figure 3 shows the information captured in the report as viewed through the Out-GridView cmdlet.

PowerShell Scores Again

I’m sure others will have different ways to solve the problem of removing service plans from SKUs, which is just fine. What’s obvious here (once again) is that PowerShell is a very flexible tool for automating administrative operations. Which is why I am so surprised when tenant administrators admit that they have never taken the time to become acquainted with the basics of PowerShell scripting. It’s not difficult; there are tons of available examples to learn from; and it gets work done. All good stuff!

Learn more about how Office 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 Office 365 ecosystem.

Changes to Close Off Creation Gaps in Administrative Interfaces

Message center notification MC275349 (August 3) informs tenant administrators of the need to check the group creation settings in the Azure AD admin center. Previously, these settings governed the ability of users to create new security groups and Microsoft 365 groups through the Azure AD admin center. However, the setting did not govern other administrative interfaces such as PowerShell or the Microsoft Graph Groups API. The new settings (Figure 1) cover all administrative interfaces and are now in place.

Microsoft advises checking your tenant settings to make sure that the change has not affected the way your organization manages group creation. I haven’t seen any issue in any tenant I use, but it’s good to be sure.

Groups-Specific Controls

Azure AD settings apply to administrative interfaces. Other controls exist at an application level. The best example of this is Microsoft 365 Groups, which use an Azure AD directory policy to store settings used to control different aspects of groups. The default value for the EnableGroupCreation setting is True, meaning that any user can create a new Microsoft 365 group. If False, the GroupCreationAllowedGroupId setting comes into play. This defines the GUID of a group whose members are allowed to create new groups.

Controlling group creation in this way requires Azure AD P1 Premium licenses. Many large organizations have Microsoft 365 plans which include these licenses so the requirement not usually an issue.

What’s a little more problematic for some is the lack of a GUI to control most of the policy settings (the naming policy and blocked words settings are available in the Azure AD admin center). Six years or thereabouts since the introduction of the directory policy for Teams, the lack of a complete GUI means that administrators must use PowerShell to access and update the other policy settings, including group creation.

For instance, to find out the set of users allowed to create groups and the name of the group defined in the policy, we can use this code:

$Values = Get-AzureADDirectorySetting | ?{$_.DisplayName -eq "Group.Unified"}
$GroupId = $Values.Values |?{$_.Name -eq "GroupCreationAllowedGroupId" } | Select -ExpandProperty Value
Write-Host ("The name of the group defined by policy to control group creation is {0} and its object identifier is {1}" -f (Get-AzureADGroup -ObjectId $GroupId).DisplayName, $GroupId)
Get-AzureADGroupMember -ObjectId $GroupId

The name of the group defined by policy to control group creation is GroupCreationControl and its object identifier is 12cb915b-2365-4bed-baf6-6257b3543273

ObjectId                             DisplayName                 UserPrincipalName                     UserType
--------                             -----------                 -----------------                     --------
bff4cd58-1bb8-4898-94de-795f656b4a18 Tony Redmond                Tony.Redmond@office365itpros.com      Member
edc6b121-44b8-4261-9ca7-3603a16caa3e Andy Ruth (Director)        Andy.Ruth@office365itpros.com         Member
43d08764-07d4-418c-8203-a737a8fac7b3 Global Tenant Administrator GblAdmin@office365itpros.com          Member

To modify the group used to control group creation, we must update the directory policy. For example, this code retrieves values for the group we want to use and the current settings and uses the values with the Set-AzureADDirectorySetting cmdlet to update the directory policy.

$ObjectId = (Get-AzureADGroup -SearchString "Group Creation Allowed").ObjectId
$Settings = Get-AzureADDirectorySetting | ? {$_.DisplayName -eq "Group.Unified"}
$Settings[“GroupCreationAllowedGroupId”] = $ObjectId
Set-AzureADDirectorySetting -Id $Settings.Id -DirectorySetting $Settings

Outlook Creation

The GroupCreationEnabled setting in the OWA mailbox policy assigned to mailboxes was the original control mechanism for group creation (OWA was the first client to support Office 365 Groups, as they were named in 2014). This setting persists today and must be True to allow users to create new groups with an Outlook client.

This article contains a more comprehensive treatment of the steps to control the creation of Microsoft 365 Groups.

Not Much Impact?

I suspect that the changes being made won’t affect many of the tenants who control group creation. Tenants that allow users to create groups and teams as they wish probably won’t be affected either, but they have other issues to cope with like a higher proportion of aging and obsolete groups. In any case, the change is a reasonable one to introduce, even if I wish Microsoft would spend some time on other obvious deficiencies, like the lack of a GUI for the Groups directory policy.

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

Switchover Coming in October 2021

Updated March 9, 2022

Message center notification MC275235 (August 3, updated on December 7, 2021) says that Microsoft is rebuilding the Whiteboard app on top of OneDrive for Business (Microsoft 365 roadmap item 66767). Whiteboard will use OneDrive for Business as its default storage starting in January 2022 (previously October), but tenants can opt-in now through the Whiteboard settings in the Microsoft 365 admin center (Figure 1) to use OneDrive-based storage for Whiteboard when the feature becomes available at the end of October. The opt-in period will last until mid-November. Opting in affects the storage of whiteboards for every user in the tenant. The latest news is that Microsoft will complete the transition to OneDrive when it delivers updates to several clients during March 2022.

The trade-off is that only certain Whiteboard clients currently support OneDrive-based storage:

• Whiteboard browser client.
• Whiteboard for Teams meetings (including Teams mobile apps).
• Whiteboard on Android.

Microsoft will deliver support for the other whiteboard clients (Windows 10/11), Surface Hub, the Whiteboard channel tab app for Teams, and iOS by October. Until then, if you choose to use OneDrive for Business, these apps will be unable to create or display whiteboards stored in OneDrive. Whiteboards created earlier and stored in Azure will remain accessible.

Solid Plan for Long-Term Whiteboard Storage

The switchover is like that done for Stream, which is also moving off Azure storage to OneDrive for Business and SharePoint Online (the final switchover for Teams meeting recordings is August 16, 2021). The new live (fluid) components which surface in applications like Teams chat, Outlook, and Whiteboard are also kept in OneDrive for Business. Moving off application-specific Azure storage to the more general-purpose storage managed by OneDrive for Business is a good idea for many reasons, including:

• OneDrive for Business is a well-understood storage platform with APIs: Utilities like reports of files in OneDrive accounts will include whiteboards along with other files.
• Available Storage: Although Microsoft doesn’t place any quota restrictions on the current Whiteboard Azure-based storage, OneDrive for Business offers very generous storage quotas which won’t be affected by the need to store a few whiteboards.
• Sharing: Whiteboards can be shared like any other OneDrive for Business file. Users sent a sharing link for a whiteboard will open the file in the browser client.
• Auditing: OneDrive for Business will log audit events for file operations against whiteboards.
• Information governance and compliance: Like any other file in OneDrive for Business, retention policies and labels are applicable to whiteboards. It’s not obvious yet if the content of whiteboards is indexed and available for eDiscovery.
• Tenant to tenant migration: Most tenant-to-tenant migration toolsets are very good at moving OneDrive for Business files around. Adding whiteboards to the mix gives them a little extra work to do but makes sure that these files end up in the right place in the target tenant.
• Backup: ISV backup products are well used to dealing with OneDrive for Business, so having some extra whiteboard files to include in the mix will cause no problems.
• User deletion: The Microsoft 365 workflow process for user account deletion allows another user to be assigned access to the deleted user’s OneDrive for Business account to copy important files before Microsoft 365 removes the account. The user assigned access can now rescue any important whiteboards from the deleted user’s account.

The Next Microsoft 365 App to Move is?

Moving storage to OneDrive for Business seems to be becoming a trend, which then poses the question of which will be the next Microsoft 365 app to move off Azure storage? Given the set which exists, Planner might be a candidate, but given its connection to Microsoft 365 Groups, the storage target is likely SharePoint Online instead of OneDrive for Business. We shall wait and see.

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

Microsoft 365 Privacy Messages in Case of Data Compromise

Microsoft posts notifications to the message center in the Microsoft 365 admin center to inform tenant administrators about a variety of different updates made to its service. MC272885 posted on Jul 24, 2021, has the title Attachments for messages with Data Privacy Tag, which might leave you scratching your head to understand what Microsoft means. At first glance, the combination of attachments and messages points to email and tag could mean a sensitivity or retention label. But that’s not what it means.

Reading the detail reveals that Microsoft is introducing a new tag for service update messages. Let’s explore what this means.

Tagging Service Messages

When Microsoft publishes a service update message, it applies tags to help tenant administrators understand the importance and potential impact of the change (Figure 1).

The tags shown in the message center include:

• Admin Impact: The change impacts the management of some aspect of the tenant. For example, a new API is available. MC272885 (described here) is deemed a change with administrator impact.
• Feature Update: Microsoft has changed the way a feature works. For example, MC264095 describes how the default setting for guest access in Teams changes from off to on.
• Major Update: The change described is considered major. For example, the retirement of Skype for Business Online on July 31 (MC266078) is obviously a big change in Office 365. Other updates tagged as major are debatable, but you can consider this tag to be a way for Microsoft to highlight important changes. Note: Unlike the other tags, this tag is marked by setting the IsMajorChange property of a message to $True.
• New Feature: A new feature is on its way for an app. For example, MC230680 describes the introduction of reactions in Teams meetings. Microsoft often misses the date for feature introductions and republishes the update, which is what happened on MC230680 on June 30 when they published new dates for availability of the feature in the GCC and DOD clouds.
• Retirement: Microsoft is removing a feature from the service. Skype for Business Online is an example, so is the final removal of Site mailboxes (MC266256). Not many shed tears when site mailboxes shuffled off into the great byte wastebasket.
• User Impact: Many changes impact users in some way. For example, MC271629 advises administrators that Project Moca is moving its spaces to the OWA calendar.
• Updated Message: This tag does not appear in the Microsoft 365 admin center. It’s used to flag service messages which have been updated since the original publication. This is usually due when Microsoft needs to clarify the meaning of the text.

Many updates have multiple tags. For instance, MC264095 has the major update, feature update, and user impact tags.

Analyzing Service Update Tags

Using the Graph API for Service Communications, we can fetch the messages currently available in the Microsoft 365 admin center to see what tags are in use. As you’ll recall, this API spans both incidents (outages) reported in the admin center and service updates. I took the example script I created for service updates and used some of the code to pull all update messages into an array.

$Uri = "https://graph.microsoft.com/beta/admin/serviceAnnouncement/messages"
[array]$Messages = Get-GraphData -AccessToken $Token -Uri $uri

I then used some simple code to analyze the tags placed on each message.

$TagAdmin = 0; $TagUpdate = 0; $TagMajor = 0; $TagNew = 0; $TagRetirement = 0; $TagUser = 0; $TagUpdatedMessage = 0; $TagDataPrivacy = 0
ForEach ($Message in $Messages) {
    ForEach ($Tag in $Message.Tags) {
      Switch ($Tag) 
        {
        "Admin impact"    {$TagAdmin++}
        "Feature update"  {$TagUpdate++}
        "New feature"     {$TagNew++}
        "Retirement"      {$TagRetirement++}
        "User impact"     {$TagUser++}
        "Updated message" {$TagUpdatedMessage++}
        "Data privacy"    {$TagDataPrivacy++}
       } # End Switch
    }  # End Foreach tag
   If ($Message.IsMajorChange -eq $True) {$TagMajor++}
} # End ForEach message 
Write-Host "Admin impact messages:  " $TagAdmin
Write-Host "Feature update messages:" $TagUpdate
Write-Host "Major update messages:  " $TagMajor
Write-Host "New feature messages:   " $TagNew
Write-Host "Retirement messages:    " $TagRetirement
Write-Host "User impact messages:   " $TagUser
Write-Host "Updated messages:       " $TagUpdatedMessage
Write-Host "Data privacy messages:  " $TagDataPrivacy

Admin impact messages:   165
Feature update messages: 65
Major update messages:   76
New feature messages:    119
Retirement messages:     31
User impact messages:    191
Updated messages:        96
Data privacy messages    0

The total count of messages was 266. You can see that:

• The most popular tag is user impact (191) followed by admin impact (165).
• There’s a surprising number of retirement messages (31).
• Many updates are issued (96).

Your mileage might vary because Microsoft issues service updates to tenants based on the feature set licensed by the tenant.

What’s Changing

Microsoft is introducing a new Data Privacy tag to indicate messages which need administrator attention because they potentially impact sensitive data. The change is due to roll out by the end of July.

Microsoft says that messages might also contain one or more downloadable attachments (if multiple, the attachments are in a zip file) to help administrators “gain additional insight into the described scenario.” For instance, an attachment might be a PowerShell script to report data or users affected by a service update.

Only accounts holding the Global administrator and Privacy reader roles can access the downloadable attachments.

It’s hard to be certain about how Microsoft will use the new Data Privacy tag and what kind of service update messages they will tag. I guess we will see when some messages appear with the tag (none are found in the messages in my tenant) and the kind of attachments available for the messages.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Three Windows 365 Options Available for Purchase

Microsoft’s announcement of Windows 365 on July 14 created a great deal of excitement in some organizations seeking a way to deploy and manage PC assets more easily (here’s an independent view on the topic). Five days later, Microsoft notified Office 365 tenants in MC271483 that end users will be able to buy Windows 365 licenses through the self-purchase license mechanism in the Microsoft 365 admin center. By default, Microsoft enables self-service purchases of Windows 365 licenses, so if you don’t want this to happen, you must disable the self-purchase option for Windows 365 using PowerShell.

Windows 365 comes in two versions. Microsoft’s definitions for the two are:

• Windows 365 Enterprise is for organizations that want to manage their Cloud PCs with Microsoft Endpoint Manager and take advantage of integrations with other Microsoft services, including Azure Active Director and Microsoft Defender for Endpoint.
• Windows 365 Business is for smaller organizations that want a simple way to buy, deploy, and manage Cloud PCs.

According to Microsoft, self-service purchases are integrated into the two versions as follows:

• Microsoft 365 Enterprise: IT admins who use Microsoft Endpoint Manager (MEM) will be able to purchase a license during the resize action on a user’s Cloud PC if their organization does not have any licenses available. 
• Microsoft 365 Business: Any user can purchase a license from windows365.com and automatically have a Cloud PC created for them.

Self-Service Purchase Options

Three Windows 365 options are available for self-purchase. Microsoft won’t confirm prices until August 1.

• Windows 365 Enterprise (CFQ7TTC0HHS9).
• Windows 365 Business with Windows Hybrid Benefit (“).
• Windows 365 Business (CFQ7TTC0J203). Apparently, this two CPU, 4GB RAM, and 128GB of storage option costs $31/month.

Self-service purchases are unavailable for government and academic tenants.

Using PowerShell to Block Windows 365 Self-Service License Purchases

Control over Windows 365 self-service license purchases uses the same mechanism as Power Apps, Power Automate, Power BI, Visio, Project Online, and (most recently) Power BI Premium and Power Automate with RPA. Here’s what you need to do:

First, if your workstation doesn’t already have version 1.6 of the MSCommerce PowerShell module, download and install the module. After the installation finishes, run the Connect-MSCommerce cmdlet to connect to the Commerce endpoint, authenticating using a global tenant administrator account.

Connect-MSCommerce

You can disable each Windows 365 option separately. For instance, here’s how to disable Windows 365 Business:

Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId CFQ7TTC0J203 -Enabled $False

To disable the three Windows 365 self-service purchase options, use this code:

$Windows365Options = @("CFQ7TTC0HHS9", "CFQ7TTC0HX99", "CFQ7TTC0J203")
ForEach ($Option in $Windows365Options) {
   Update-MSCommerceProductPolicy -PolicyId AllowSelfServicePurchase -ProductId $Option -Enabled $False }

Finally, check the current enablement status for each product available for self-purchase with:

Get-MSCommerceProductPolicies -PolicyId AllowSelfServicePurchase

ProductName                                      ProductId    PolicyId                 PolicyValue
-----------                                      ---------    --------                 -----------
Windows 365 Enterprise                           CFQ7TTC0HHS9 AllowSelfServicePurchase Disabled
Windows 365 Business with Windows Hybrid Benefit CFQ7TTC0HX99 AllowSelfServicePurchase Disabled
Windows 365 Business                             CFQ7TTC0J203 AllowSelfServicePurchase Disabled
Power Automate per user                          CFQ7TTC0KP0N AllowSelfServicePurchase Disabled
Power Apps per user                              CFQ7TTC0KP0P AllowSelfServicePurchase Disabled
Power Automate RPA                               CFQ7TTC0KXG6 AllowSelfServicePurchase Disabled
Power BI Premium (standalone)                    CFQ7TTC0KXG7 AllowSelfServicePurchase Disabled
Visio Plan 2                                     CFQ7TTC0KXN8 AllowSelfServicePurchase Disabled
Visio Plan 1                                     CFQ7TTC0KXN9 AllowSelfServicePurchase Disabled
Project Plan 3                                   CFQ7TTC0KXNC AllowSelfServicePurchase Disabled
Project Plan 1                                   CFQ7TTC0KXND AllowSelfServicePurchase Disabled
Power BI Pro                                     CFQ7TTC0L3PB AllowSelfServicePurchase Disabled

To Block or Not to Block

Self-service licensing has its place in some organizations. Others consider it inappropriate and unhelpful to allow end users to drive what they consider should be organization-led purchasing. If you’re in the latter category, go ahead and run the couple of lines of PowerShell given above to block users. If not, consider how to educate people about how self-service licensing works and when it should be used.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Don’t Assume Everything a Computer System Spits Out is the Truth

As Office 365 for IT Pros subscribers know, we publish a new edition annually. Part of the preparation for a new edition is an end-to-end technical review of all content. This happens to make sure that our material is current and accurate. The review picks up issues like dead hyperlinks, unnecessary (some might say verbose) text, and outdated graphics. It’s a good process to keep our authors focused on delivering the best possible book, something that’s only possible because of our ePublishing model.

Office 365 Client App Security

Microsoft 365 applications update GUIs on an ongoing basis. Sometimes it’s just a matter of adding a new option or changing the words on a button. Other times it’s a more fundamental makeover, such as the introduction of a new interface for content searches. Office 365 Cloud App Security (OCAS) is available to tenants with Office 365 E5 licenses. OCAS is a subset of the full Microsoft 365 Cloud App Security product, tailored for Office 365.

Figuring Out Impossible Travel

OCAS analyzes the data ingested from multiple workloads into the Office 365 audit log to identify anomalies and other potential issues. As we reviewed the chapter on reporting and auditing, the technical editor highlighted the need to refresh some screen shots to reflect the new OCAS GUI, which brings us to Figure 1, which shows how OCAS highlights a potential impossible travel activity issue.

In other words, the IP addresses captured by OCAS for client connection events over a certain period originate in multiple countries where it would be impossible for the user to travel between those countries during that time. In this case, the alert flagged interactions from Ireland and the Netherlands within a 99-minute period. It’s possible to fly from Dublin to Schiphol in this time, so that’s probably why OCAS uses this period to test for suspicious connections.

Applying the Human Touch

On the surface, this looks like a problem which deserves investigation to understand if an attacker has compromised the user’s account. In fact, it’s a good example of how human intelligence can quickly make sense of activity which a computer deems suspicious. At first glance, the facts are:

• The user signed in from two different IP addresses within a short period.
• The IP addresses indicate connections from Ireland and the Netherlands.
• In both cases, the application was Teams.

But when we examine the detailed records, we see a continuous set of connections first originating from The Netherlands and then switching to Ireland, all within a very short time (Figure 2). Most of the records are for login events. Some others (not shown here) record SharePoint Online activities like opening a document.

Searching the audit log with the Search-UnifiedAuditLog cmdlet to find the underlying records confirms that the user connected multiple times to work with Teams and SharePoint Online over the period. The IP addresses are correct, the connections valid, so what’s happening? Everything makes more sense when you consider that:

• Teams and its associated applications use Azure AD secure token service (AzureActiveDirectoryStsLogon) logons to validate user credentials. The logged sign-in events all use the token service.
• The tenant is in Microsoft’s EMEA datacenter region, and the Teams service runs in the region.
• The EMEA datacenter region includes datacenters in Ireland and the Netherlands.

Therefore, the most likely explanation is that the Teams client attempted to use its access token to connect. During this process, the server handling the request changed from a server in the Netherlands to one in Ireland. Azure AD captured details of the connections and sent them to the Office 365 audit log where OCAS picked up the information, analyzed the events, and concluded that a potential impossible travel situation exists. As it happens, I know that this is exactly what transpired, but it’s a great example of how tenant administrators need to apply their knowledge of Office 365 and how Microsoft’s datacenter infrastructure operates to assess and resolve a flagged alert.

Administrator in Office 365

Another thing to consider is that OCAS notes that the user is an administrator in Office 365. This doesn’t mean that the account is a tenant administrator. It means that the account holds an administrative role. In this case, the account holds the SharePoint administrator role. Again, when probing details of an incident, check before assuming the worst.

Resolving Issues

This case did not take much to resolve. Other OCAS alerts require substantially more effort to understand and conclude. The point I make is that OCAS is a tool to highlight issues to administrators which deserve some attention. Just because OCAS flags an alert isn’t evidence that a problem exists. Always use human intelligence to validate computer indications when resolving alerts. You’ll get better results that way.

Many Recent Changes

Information Protection and Governance is an area Microsoft has invested in heavily for the past few years. Many new features constantly appear, such as native support for sensitivity labels in the Microsoft 365 apps for enterprise, trainable classifiers, auto-labelling policies for sensitivity labels, and so on. Amongst all the change, one constant is that tenant administrators are often unsure about the licensing requirements demanded to protection data. Let’s try and figure out what the situation is.

The Split Between Manual and Automatic Processing

The first thing about information protection and governance features is that Microsoft makes a clear distinction between manual and automatic processing. When a user takes an action to do something, it’s manual processing and the required license is usually included in Office 365 E3. For information protection features, Microsoft enforced the differentiation in 2019 with the introduction of two Microsoft Information Protection service plans for Office 365. The standard plan is in Office 365 E3; the premium is in Office 365 E5.

The standard set of information protection and governance functionality in Office 365 E3 includes:

• Manual application of sensitivity labels to Office documents via Microsoft 365 apps for enterprise, Office Online (including OWA), and Office mobile.
• Manual application of sensitivity labels for container management to Teams, Groups, and Sites. Bizarrely, the person who applies the label (an administrator or group owner) must have an Azure AD Premium P1 license. The unfathomable logic is that the automatic inheritance of settings from the label to the underlying Azure AD group is advanced functionality.
• Manual Application of retention labels to documents and email.
• Basic Office 365 Message Encryption (OME). This includes the default Encrypt-Only and Do Not Forward templates to protect email.
• Data Loss Processing for Exchange Online and SharePoint Online (Teams is an outlier as its DLP policies require Office 365 E5).

Automatic processing usually means that some form of auto-apply policy is involved. For example, you can deploy auto-label policies to apply sensitivity labels or retention labels to documents and email. Office 365 E5 covers these policies along with Advanced OME and customer key for Office 365. Sometimes Microsoft’s definition of automatic is a little strained. For instance, if you define a default retention label for a SharePoint Online document library so that new documents created in the library receive the defined label, it’s automatic and therefore needs an E5 license.

However, for more advanced functionality like Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), or double-key encryption (DKE), you’ll need a premium license like Microsoft 365 E5, Microsoft 365 E5 Compliance, and Microsoft 365 E5 Information Protection and Governance. These licenses also cover scenarios like using S/MIME with sensitivity labels, data classification in SharePoint Online, and using sensitivity labels with Power BI.

Tools to Help Understand Licensing

Given the number of features and plans available in this space, the issue of licensing can be quite complex. Microsoft publishes guidance to help tenant administrators and licensing coordinators understand when premium licenses are required to cover security and compliance features. A useful Microsoft 365 compliance comparison spreadsheet (Figure 1) is also available to show which license covers each feature. The spreadsheet also identifies gaps in terms of desirable features not covered by licenses held by a tenant.

Non-Enforcement is No Excuse

In some cases, a feature might not enforce the stated licensing requirement. This could be because the necessary code is not yet available. The code might or not appear soon. In any case, a tenant must have licenses to use functionality. It’s a bad place to be in if features the business depends on suddenly stop working because Microsoft updates its license enforcement code.

Slower and Buggy

I can’t find a notification that the Microsoft 365 compliance center was to receive a GUI makeover for content searches, but maybe I missed that memo. As it turns out, the notification is MC246002, but it dates back to March 23 and was overtaken by events. In my unaware state, I was surprised when a new user interface is now available in the tenants I have checked. The documentation is dated May 11, so I assume that’s when things changed. Curiously, the documentation refers to Office 365 Groups instead of Microsoft 365 Groups and insists on talking about the mailbox associated with a team (for channel messages). This perpetuates the nonsense that Teams uses Exchange Online to store data and ignores the storage of compliance records for personal and group chats in user mailboxes, but hey, it’s only documentation.

The old content search interface was around for several years and needed a refresh, and this release brings the interfaces for content searches and Core eDiscovery in line with that used for Advanced eDiscovery (which requires Office 365 E5). It also aligns the interface with Microsoft’s accessibility guidelines. The problem of refreshing anything is the potential of breaking things or making a feature work worse than before. Microsoft has succeeded splendidly in attaining both objectives. The new content search interface is both slow and buggy. Let’s hope it improves over time.

Fresh Interface

The good news is that the new interface is better looking and in line with the other sections of the Microsoft 365 compliance center. Microsoft has clearly paid attention to simplifying the creation of searches. For example, they’ve rationalized the set of locations into three types: Exchange mailboxes, SharePoint sites, and Exchange public folders (Figure 1). This is a good step because it avoids getting worried about differentiating between user, shared, and group mailboxes, compliance records for Yammer and Teams (and Planner in the future), OneDrive and SharePoint, and so on.

Also, content searches now automatically include “app content.” Although this checkbox says that it includes content for on-premises users, it means content stored in cloud-only mailboxes created by the Microsoft 365 substrate to hold messages sent by hybrid, guest, and federated users. This capability existed in the old interface, but a tenant had to ask Microsoft support to enable support for app content. It’s good that the option is now available to all.

Problems in the Location Pickers

Unfortunately, things start to go downhill from this point. First, the picker used to select Exchange mailboxes is very slow. Even on my small tenant, it takes ten seconds or more to find a mailbox. Also, note that the email address field is promised but not displayed (Figure 2). Seeing the email address is often helpful in distinguishing mailboxes with similar display names. On the upside, the picker allows selection of distribution lists and Microsoft 365 groups, which makes adding a bunch of mailboxes easier. You can also add inactive mailboxes to a search.

The picker also suffers a deselection problem. Take the example where you have selected several mailboxes, groups, and lists for a search and the decide that you want to start over. Figure 3 shows that a search has eight mailboxes selected, but details of the mailboxes are not shown to allow their removal. The only way I have found to deselect a mailbox is to search for it again and then remove the check against its name. This might be acceptable for one mailbox; it is tiresome when a search spans many mailboxes.

The SharePoint site picker still insists on URLs to find sites. It’s reasonably easy to find the URL for a site, but it would also be good if the picker allowed input of the site name. Bizarrely, if you go back to the site picker to update the list of selected sites, a list of the selected sites is available and it’s easy to uncheck a site (Figure 4).

Keywords and Conditions

After selecting target locations, the next step is to add the keywords and conditions for the search. There isn’t much change in the keyword list, but the way to select conditions has changed. In the past, each condition showed if it was common (applied to both Exchange and SharePoint) or specific to a workload. For instance, the Sent date condition applies only to email whereas the last modified condition is really a document condition (emails don’t change after sending). Now, there’s no assistance about what condition can be used with the different locations.

If you try to use a condition not supported by a selected workload, you’ll see an error (Figure 6). In this case, I selected the message kind condition which SharePoint doesn’t support.

Fine. Let’s remove the offending condition. The compliance center still wasn’t happy and generated an obscure, impenetrable error (Figure 7). The point here is that Microsoft has worked on content searches for over five years. It’s unacceptable when error messages fail to tell the end user exactly what they need to do to resolve the issue. As I worked through content searches over several days, I encountered more errors and problems than in the last year, and most of the errors were incomprehensible.

After going back to the search summary screen, even more gobbledygook erupted with diagnostic information that might make sense to a computer but means absolutely zilch to me. In this case, the search criteria (query) still includes the problematic message kind condition, but the error persisted even after removing the condition.

There was no way out except to abandon editing the search and start over. Eventually, I created an acceptable set of conditions and keywords and saved the search. The compliance center then launches an estimate search to create a sample set of results.

Samples and Previews

An estimate search is just that. It is a quick search to estimate what items a full search will find. To help the searcher figure out if their query works, the estimate returns a small sample of items matching the query. In the past, this was called a preview search.

When the estimate is complete, the summary screen for the search displays search statistics such as the number of matching items found and how many mailboxes and sites the search processed. Unlike previously, you now need to use an explicit option (Review sample) to see the items retrieved by the search.

Running the estimate search seems slower than before. This is a gut feel because I don’t have the two interfaces to test. However, I have run enough content searches over the year to know when something is not quite right. Retrieving the review sample items is also slow. Painfully slow at times. In addition, the preview screen (Figure 9) doesn’t tell you how many sample items are available.

Two problems surfaced here. First, scrolling through the list of preview items sometimes failed and I had to return to the search summary to start again. Second, the previous facility to choose to display 50, 100, or 200 preview items is gone. You can only see what search chooses to display,

Another irritation is that although Microsoft’s documentation says Word documents can be previewed, this version stubbornly refused to preview documents.

Impact on Core eDiscovery

Content searches underpin the Core eDiscovery functionality in the Microsoft 365 compliance center. The new interface now appears for Core eDiscovery. However, the ability to perform bulk operations has disappeared. This creates a big gap because a major difference between running individual content searches and an eDiscovery case is that the eDiscovery case can span multiple searches, each with their own locations and search criteria. In the past, eDiscovery managers have been able to combine the results from multiple searches into a single bulk export. That option is no longer available.

Nice Interface, Shame About the Slowness and Bugs

The remainder of the content search lifecycle (exporting search results and reports) works largely as before and doesn’t need any commentary. But getting to the point where results can be exported now takes longer and the experience, although mitigated by a nice UI, is spoilt by slow and buggy code. I don’t know if any of the Microsoft engineers and testers who worked on the new content search UI have ever conducted a search in anger in the context of something like a fraud investigation. If they had, they might just have realized that what’s been given to customers has some real problems. And that’s sad.

I’m sure Microsoft will fix the problems in due course. Hopefully, that’s sooner rather than later. And it would nice if they tested the code first before releasing it to paying customers.

Update May 28: I’ve had a conversation with Microsoft about the issues noted above. Microsoft acknowledges that they have work to do to fix bugs and improve performance. We’ll track this activity in future.

We’re busily revising the Office 365 for IT Pros eBook to include details of the new UI for content searches. Subscribers will see this work in a monthly update coming soon.

The Looming End for the Security and Compliance Center

Updated 18 June 2023

A reader asked how to create a report of the membership of Microsoft 365 role groups. Although this sounds like a straightforward question, the answer is complex. Here’s why.

Originally, compliance functionality was workload-based. Exchange Online had its own features as did SharePoint Online. In 2016, Microsoft introduced the Office 365 Security and Compliance Center (SCC) to bring together functionality which applied across all workloads. Permissions for the SCC follow the Exchange Online Role-Based Access Control (RBAC) model. Users receive permissions to perform actions through membership of role groups. If your account is a member of the right role group, you can perform a compliance action, like running a content search or managing an eDiscovery case. If it’s not, you won’t see the options to perform those actions displayed in the SCC.

Here’s where the situation becomes complicated. We are in the middle of a transition from the SCC to the Microsoft 365 compliance center, which Microsoft launched in 2018. Three years and a lot of confusion later, an April 15 blog post warns that Microsoft will soon start to redirect users automatically from the SCC to the Microsoft 365 compliance center. Message center notification MC256030 posted on May 12 confirms that a new permissions management page in the Microsoft 365 compliance center will make role management easier (Microsoft 365 roadmap item 72239).

Update: The Microsoft 365 compliance center is now the Microsoft Purview compliance portal. I’ve also updated the PowerShell code in this post to use the Microsoft Graph PowerShell SDK.

New Permissions Management Page

The new permissions management page (Figure 1) allows management for both Azure AD roles and compliance center roles (more correctly, role groups). The differences between the two are:

• Azure AD roles allow performance of directory-related tasks. The full set of Azure AD roles is visible by running the Get-AzureADDirectoryRole cmdlet or through the Roles and administrators section of the Azure AD admin center. Azure AD roles support advanced role management functionality like Privileged Identity Management to assign roles to users for limited periods.
• Compliance center role groups allow performance of compliance tasks like eDiscovery. Each role group contains one or more roles, which is how accounts gain permission. The 43 compliance role groups (my tenant has 44 because I created a specific role group to handle certain processing) have no other function except to control access to different compliance features. The SCC was the previous location to manage these roles. To update the set of users who receive permissions through membership of a compliance role group, an account must be a global administrator or assigned the Role Management role (a role assigned only to the Organization Management role group).

The permission management page shows Azure AD roles used to performance compliance tasks. Currently, the page lists nine Azure AD roles like compliance administrator and compliance data administrator. Other Azure AD roles like Teams Administrator don’t appear because they are not associated with compliance management.

Reporting Who Holds Compliance Roles

Returning to the original question of how to generate a report about the holders of different compliance roles, the answer depends on if you want to report the membership of compliance role groups or Azure AD roles. Given that more functionality is governed by the latter type at present, the following code is a solution.

The steps to create the report are:

• Uses the Connect-IPPSSession cmdlet (in the Exchange Online management module) to connect to the Compliance endpoint. You’ll need to use a tenant administrator account or one holding the compliance Organization Management role.
• Fetches the list of known role groups.
• Parses the set of members for each role group by converting the odd values used to represent members FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/office365itpros.onmicrosoft.com/cad05ccf-a359-4ac7-89e0-1e33bf37579e into mailbox display names (the last part of the name is the Azure AD object identifier for the account).
• Writes details out into a PowerShell list and displays the results using the Out-GridView cmdlet.

Here’s the code:

Connect-IPPSSession
[array]$RoleGroups = Get-RoleGroup
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($RoleGroup in $RoleGroups) {
    $Members = $RoleGroup.Members
    $MemberNames = [System.Collections.Generic.List[Object]]::new()
    ForEach ($Member in $Members) {
       $MemberName = (Get-ExoMailbox -Identity $Member.SubString(($Member.IndexOf("onmicrosoft.com/")+16),36) -Erroraction SilentlyContinue).DisplayName 
       $MemberNames.Add($MemberName)
    }
    If ($RoleGroup.WhenChanged -eq "Wednesday 1 January 2020 00:00:00") {
       $RoleGroupChanged = "Never"
    } Else {
       $RoleGroupChanged = Get-Date($RoleGroup.WhenChanged) -format g }

    $MemberNames = $MemberNames -join ", "
    $ReportLine = [PSCustomObject][Ordered]@{  
       "Role Group"           = $RoleGroup.DisplayName 
       "Members"              = $MemberNames
       "Last Updated"         = $RoleGroupChanged   }
    $Report.Add($ReportLine) 
} #End ForEach $RoleGroup
$Report | Sort-Object "Role Group" | Out-GridView

Figure 2 shows what the report looks like. A simple Export-CSV command will write the details out to a CSV file if you want to manipulate the data in Excel.

The same approach works to create a report for the Azure AD roles. In this case, you use the Get-MgDirectoryRole cmdlet to find the set of roles and Get-MgDirectoryRoleMember cmdlet to process each role (here’s an example of using these cmdlets to report on Microsoft 365 admin accounts which aren’t protected by multi-factor authentication).

Connect-MgGraph -Scopes Directory.Read.All
[array]$RoleGroups = Get-MgDirectoryRole | Sort-Object DisplayName

$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($RoleGroup in $RoleGroups) {
  [array]$Members = Get-MgDirectoryRoleMember -DirectoryRoleId $RoleGroup.Id
  $MemberNames = $Members.additionalProperties.displayName -join (", ")
  $ReportLine = [PSCustomObject][Ordered]@{  
       "Role Group"          = $RoleGroup.DisplayName 
       "Members"             = $MemberNames
       "Description"         = $RoleGroup.Description  }
    $Report.Add($ReportLine) 
} #End ForEach $RoleGroup
$Report | Out-GridView

Simple questions often have complex answers. In this case, it’s a matter of deciding what kind of role holders you want to report. Once you know that, the PowerShell to generate the report is relatively straightforward.

Learn lots more about how different parts of Office 365 work by subscribing to the Office 365 for IT Pros eBook. We go where other writing teams don’t, and we keep our book refreshed with monthly updates.

Change in the World of eDiscovery

Message center notification MC255066 posted on 7 May covers some configuration changes Microsoft is making to Core eDiscovery and Advanced eDiscovery. After claiming that the changes will bring “performance, reliability and experience improvements” (surely the norm for all Microsoft announcements), the text goes on to note that “documented limits were previously not enforced.” The upshot is that eDiscovery might not work like it did once Microsoft enforces the changes on May 10.

Core eDiscovery and Advanced eDiscovery have different technical foundations. Core eDiscovery is a case-based wrapper around content searches and in-place holds. Each case can span multiple searches and holds, and exports from the searches can be combined into one set for investigators to review. Advanced eDiscovery, which requires Office 365 E5 or Microsoft 365 compliance licenses, has its own search, review, and analysis capabilities developed to handle high-end eDiscovery cases of the type found in large enterprises. These cases might involve millions of documents and email items.

Notable Changes

Microsoft has documented limits for content searches for several years. In a practical sense, the most notable changes cited by Microsoft are:

• Content search preview, which can retrieve up to 100 items per mailbox and display a total of 1,000 items from all mailboxes included in a search.
• Core eDiscovery no longer supports exports involving more than 100,000 mailboxes.
• The Advanced eDiscovery collection process now treats SharePoint Online sites as individual locations, so collection might be slower.

Few organizations need to search more than 100,000 mailboxes. Those who do likely use Advanced eDiscovery or a specialized third-party eDiscovery product. MC254890 (May 6) says that Advanced eDiscovery has “raised the maximum size of an export from an Advanced eDiscovery review set from 3 million documents or 100 GB (whichever is smaller) to 5 million documents or 500 GB (whichever is smaller).” Advanced eDiscovery uses multiple ZIP files to handle the export of such large amounts of data.

Advanced eDiscovery is not fast at building its collection of data under review today, so making it a little slower to process SharePoint Online sources is probably not a big issue.

The Meaning of Preview

Some think that a content search preview represents the results of a full search. This isn’t true. Search preview exists to allow investigators to assess the accuracy and effectiveness of search criteria by reviewing a representative sample of what the search might find. No investigator wants to find more information than necessary. A search which finds precisely the required information takes much less time to process than one which returns a bunch of unrelated (and unwanted) items. Being able to preview the items found by a search (Figure 1) gives investigators the chance to see what kind of items a full search will find, no more and no less. An export is preceded by a full search, and that’s when the true set of items found in the target locations is revealed.

All of which means that the limit of 100 items per mailbox is important. It could be that the 101^st item is critical for an investigator but doesn’t show up in a preview. Given the increasing amount of data stored in Exchange Online, SharePoint Online, and OneDrive for Business, it’s possible that the most important items are buried and will never appear in a preview. They will be found and included in an export.

More Attention Needed for Search Criteria

This doesn’t mean that the search criteria are flawed or that searching is ineffective. It does mean that investigators need to understand how to use content searches to accomplish their goals. Up to now, it seems like Microsoft didn’t always enforce the documented limits, so it’s possible that preview returned more items than it will after May 10. With that in mind, the real lesson here is that investigators need to pay more attention to search criteria to ensure that the best possible chance exists that important items will turn up in preview.

More Data Consumes Search Resources

Some might ask why Microsoft is making these changes? I think the answer is probably based on multiple influences, including:

• Organizations store more information in SharePoint Online and OneDrive Business. Microsoft is also moving applications like Stream and Whiteboard to use SharePoint Online and OneDrive for Business. The more data, the more resources are consumed by search.
• The 100 GB Exchange Online enterprise mailbox quota encourages users to keep more email.
• The Microsoft 365 substrate captures compliance records for Teams and Yammer and stores the records in Exchange Online user and group mailboxes to make these items indexed and discoverable. The growth of Teams usage over the last year to 145 million daily active users has an attendant growth in compliance record storage. Yammer only recently added support for compliance records, and it only happens for Yammer networks configured in Microsoft 365 mode, so it’s much less of a factor.

In a nutshell, more data than ever before needs to be searched. If you didn’t impose some limits, search would consume more and more resources, and that’s an unmanageable situation. Although I can’t prove it with hard data, content searches certainly seem to take longer to complete now than they once did. Perhaps the changes now being made will restore search performance to where it once was.

Confused about eDiscovery in Microsoft 365? The Office 365 for IT Pros eBook includes a complete chapter on the topic. Subscribe today to keep your knowledge updated as change happens.

Antiquated Report Revived Because of Customer Feedback (But Better Alternatives Exist)

Updated April 2022 with details of the new location for the Top Senders report and Top Recipients report in the Microsoft 365 Defender portal

Microsoft published an update to message center notification MC237975 on April 22, 2021 to cancel the proposed retirement of the Top Senders report and the Top Recipients report and its associated PowerShell cmdlet (Get-MailTrafficSummaryReport) previously advised on February 5, 2021. According to the update, Microsoft based its decision on customer feedback, which means that some customers must like the report and the cmdlet. I am mystified why this is so. It’s a simply horrible report. In their defense, those advocating its retention must not understand that better alternatives exist.

Reports in the Microsoft 365 Defender Portal

Originally located in the Office 365 Security and Compliance Center (SCC), the Top Senders report and Top Recipients report are now found under Email & Collaboration in the Reports section of the Microsoft 365 Defender portal. The reports section is organized into a series of widgets, each representing a report. The Top Senders and Recipients report can look back 90 days (the period for which Exchange Online preserves message trace data) and the data it presents is moderately interesting (Figure 1).

The Top Senders report and Top Recipients report and the underlying cmdlet are old (the cmdlet dates to at least 2015) and Microsoft has given them little or no tender loving care since. The data presented in the reports in the old SCC including all sorts of crud, such as message sent to replicate public folders between public folder mailboxes, updates sent by SharePoint Online when users share documents, and so on. You can’t apply a filter to remove all the system junk from the data, so you end up with useless statistics such as public folder replication represents 80.77% of all send message activity over the last 90 days. Thankfully, Microsoft applies better filters to the reports available in the Microsoft 365 Defender portal.

However, the Top Senders and Top Recipients reports don’t take account of recent advances such as plus addressing and the support in Exchange Online to allow users to send messages using any proxy address assigned to their mailbox. Each plus and proxy address is listed separately instead of being grouped under the mailbox.

It’s not difficult to filter out messages like those for system, group, and shared mailboxes to create a report based on mailbox activity. Take the PowerShell example below, which uses the Get-MailTrafficSummaryReport cmdlet to create two arrays of sender and recipient data for the last 90 days. After fetching the set of user mailboxes in the tenant, we loop through each mailbox to calculate the total number of messages sent and received. Because we focus solely on messages sent and received by user mailboxes, this approach excludes any system-generated traffic.

$StartDate = (Get-Date).AddDays(-92); $EndDate = (Get-Date).AddDays(+1)
[array]$SenderData = Get-MailTrafficSummaryReport -Category TopMailSender -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2 
[array]$RecipientData = Get-MailTrafficSummaryReport -Category TopMailRecipient -StartDate $StartDate -EndDate $EndDate | Select-Object C1, C2 
$MbxReport = [System.Collections.Generic.List[Object]]::new()

[array]$Mbx = Get-ExoMailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited
ForEach ($M in $Mbx) {
Write-Host "Processing" $M.DisplayName   
# Check each email proxy address to see if it was used to send email
[int]$TotalSentMessages = 0 ; [int]$Messages = 0
ForEach ($A in $M.EmailAddresses) {
      If ($A.Substring(0,4) -eq "smtp") {
         $Messages = $SenderData | ? {$_.C1 -eq $A.Split(":")[1] } | Select -ExpandProperty C2
         # Write-Host "Messages found for" $A " " $Messages
         $TotalSentMessages = ($TotalSentMessages + $Messages) }
}
# Check each email proxy address to see if it was used to receive email
[int]$TotalReceivedMessages = 0 ; [int]$Messages = 0
ForEach ($A in $M.EmailAddresses) {
      If ($A.Substring(0,4) -eq "smtp") {
         $Messages = $RecipientData | ? {$_.C1 -eq $A.Split(":")[1] } | Select -ExpandProperty C2
         Write-Host "Messages found for" $A " " $Messages
         $TotalReceivedMessages = ($TotalReceivedMessages + $Messages) }
}
     $ReportLine = [PSCustomObject] @{
        User                = $M.DisplayName
        Address             = $M.UserPrincipalName
        "Sent messages"     = $TotalSentMessages
        "Received messages" = $TotalReceivedMessages }    
      $MbxReport.Add($ReportLine) 
}
$MbxReport | Out-GridView

Figure 2 shows the output from the script. You can download a copy of the script from the Office 365 for IT Pros GitHub repository.

The Modern Usage Reporting Option

I imagine that the customers who protested the removal of the Top Senders and Recipients report did so because they use the report. Well, a better mousetrap exists for reports about user activity: the Microsoft Graph Reports API. The most important reason why is that the Graph API is the focus for future Microsoft development. The old Office 365 data warehouse, used as the basis for the older Exchange-based usage cmdlets, will eventually disappear.

The Exchange usage report in the Microsoft 365 admin center (Figure 3) is the closest to the Top Senders and Recipients report. It’s not perfect (what do “receive actions” really mean in terms of the number of messages received by a mailbox?), but it’s a good start. The data doesn’t line up exactly with what’s reported in the Microsoft 365 Defender portal. Usually, the Graph-based data for messages sent and received comes in under the figures reported by the Microsoft 365 Defender portal, but I’m willing to put that down to inconsistencies in the Office 365 data warehouse. In any case, tracking data about user activities is like using a personal step counter. The data might vary from device to device depending on how a device accounts for factors like stride length, but once you use the same device on a consistent basis, you have something to compare progress against.

The usage reports in the Microsoft 365 admin center use the Graph API and support features like the deidentification of personal user information. They also support going back 180 days instead of 90 days, and because the reports use a fully supported API, you can write your own code to generate the type of usage reports you want. An example of this is the per-user activity report spanning multiple Microsoft 365 workloads (Exchange, SharePoint, OneDrive, Teams, and Yammer) written using a combination of PowerShell and Graph API calls.

Time to Switch from the Old Reports

If you’re one of the customers discommoded by Microsoft’s plan to retire the Top Senders and Recipients report, it’s time for you to consider looking at the replacements which already exist within Microsoft 365. The reports available in the admin center might be different, but the usage data is there. And if you don’t like what you see, consider investing some time to develop familiarity with the Microsoft Graph Reports API, maybe using PowerShell. The Graph is the future; the old reports will eventually disappear. Why stay fixed in the past when the future beckons?

We offer insights like this throughout the 24 chapters of the Office 365 for IT Pros eBook. It’s one of the reasons why our subscribers stay on top of new developments inside Office 365.

Remove Old, Obsolete, or Unwanted Enterprise Apps

Vasil Michev’s article about creating a Graph-based PowerShell script to generate an inventory of Entra ID integrated apps and their permissions caused me to think about this dark corner. Microsoft’s Philippe Signoret covers some of the same ground with his PowerShell script, used in Microsoft’s documentation for detection and remediation of illicit consent grants, a topic which became more important in the light of the SolarWinds hack last year. As discussed here, you can also interrogate the Microsoft 365 audit log to report events captured when apps receive consent.

In any case, the point is that apps with permissions exist in a tenant and it’s good to know what the apps are, why they have permissions, and if they are still needed. An increasing number of ISV and other apps use the Graph APIs to interact with Microsoft 365 data. Each of these apps needs an OAuth 2.0 consent to interact with the Graph and ends up as an Entra ID integrated app (more commonly known as enterprise apps). By running Vasil’s script, I found 58 apps in my tenant. Based on what I see in other tenants, this is not uncommon.

Update: You can use Get-MgServicePrincipal cmdlet from the Microsoft Graph PowerShell SDK to return a list of enterprise apps known in a tenant.

Reviewing Enterprise Apps

Although you could review the set of enterprise apps through the Entra ID admin center (Figure 1), it’s often easier to perform a review using a shared resource like the CSV file generated by the script.

To make the data easier to work with, after running the script to generate the CSV files, I converted the CSV to an Excel worksheet formatted as a table and imported it into Microsoft Lists in Teams. Storing the data in a list accessed through a tab in a channel makes the information very accessible to people who might know what function apps serve (if any). I added a couple of fields to track the apps during the review, including creating a category to classify the apps and a notes field to capture comments made by reviewers. Here are the set of categories I used:

• Microsoft apps.
• Trial apps installed for testing purposes.
• ISV apps still in use.
• Tenant Apps registered to use PowerShell to call Microsoft Graph APIs.
• Apps requiring further investigation.
• Unwanted apps which can be removed.

Figure 2 shows how the list of apps for review appears in Teams.

Looking through the set of apps uncovered some interesting items. For instance, a bunch of apps exist to help with registering users for conferences. If you’ve ever attended a Microsoft event like Ignite, you’ll probably find an app called “Microsoft Events” with permissions to read user profiles. Sessionize.com has an app with the same permissions to help people like me submit sessions to conferences, while the EventPoint sign-in app seems to serve the same purpose while demanding access to users’ email addresses. And finally, the Nubelus app is, I think, used by the European Collaboration Summit, but limits itself to delegated permissions for selected users (me, in this case).

Each app needs careful examination to understand its purpose, who uses the app, and the permissions it holds. Bringing the information about the apps into the list made that review quicker and easier.

Focusing on Problem Apps

The highlighted app (CXP Previews Portal is a good example of a questionable app. Examining details of the app (Figure 3), we discover that its home page is http://bf.net.nz/, located in New Zealand and that its creation date (in the tenant) was 20 December 2016. Access is valid until 18 June 2017, so it is obvious that this app is unused and a prime candidate for renewal. The other information captured for the app makes me think that this app is used to gain access to some Microsoft previews (CXP is a Microsoft acronym for Customer Experience Program). All in all, this app is a great candidate for removal.

In total, the review highlighted 16 unwanted apps which could be removed immediately along with several others which needed more investigation. These apps belong to trials that I had signed up for in the past (like the four apps registered for Office365mon.com), others for services I looked at but never used, like Microsoft FastTrack, and some were old Microsoft pilot apps, like CollabDB, part of the Project Osaka initiative from 2017. I remembered some apps, while others needed an internet search to fill in the gaps. In many cases, several years (going back to 2015) had lapsed since the app was granted permissions.

Removing Unwanted Enterprise Apps

To remove an app, go to the Enterprise applications section of the Entra ID admin center and select the app. Click properties in the left-hand pane to reveal the option to delete the app (Figure 4). Click Delete and confirm to remove the app. The Entra ID admin center lists 50 apps in its UI, so if your tenant has more than 50 apps, you must search using the app id in to view its properties.

If you remove an app in error, it’s easy for an administrator to grant consent to the app and its required permissions the next time the app is needed.

After removing the 16 unwanted apps, my set of enterprise apps is now down to 42. I’m now gathering information about the seven apps which need further investigation (if I were bold, I would delete the apps to see what happens, but that’s seldom a good plan).

Time for an Enterprise App Spring Clean

What this exercise proves is that the set of apps integrated with Entra ID tends to grow over time and is not managed in any way by Entra ID. It’s up to administrators to audit the set of apps in their tenant and decide which apps remain useful and which can be discarded. Apart from cleaning out old apps, the purpose of the audit is to ensure that bad actors can’t leave highly permissioned apps behind to use after an initial visit.

The script described in Vasil’s article is a good starting point for an audit. Putting the results of the script into a Microsoft list makes the app more accessible and easier to work with. At the end of the day, humans must decide what apps to keep. Based on my experience, it should be possible to remove between 30-40% from a tenant. Your mileage may vary!

Apart from users and groups, it’s often surprising how little attention the contents of Entra ID receives from tenant administrators. Learn more by subscribing to the Office 365 for IT Pros eBook. We might not cover everything there, but what we do cover is important…

Teams is the Last Workload to Support Deidentification of Personal Data

On March 16, Microsoft published message center notification MC244599 to announce that the usage data in Teams reports would support the same obfuscation of personally identifiable information (PII) in usage reports as the other workloads do. On April 9, they said that the roll-out of the feature was complete. This is Microsoft roadmap item 70774.

The text in MC244599 and roadmap item 70774 might lead you to think that this is a Teams feature. It’s not. As evident in this December 2020 post, workloads like Exchange Online and SharePoint Online could disguise user-identifiable information like email addresses and display names as well as SharePoint site names in the Microsoft 365 admin center reports. This is a case of Teams catching up. What’s odd about Teams only now obscuring its usage data is that the Microsoft Graph was able to obfuscate the raw Teams usage data then (see the example in the previous post).

Obscuring Personal Data

The setting to control the display of obfuscated user, group, and site data is in the Org-wide Reports section (Figure 1).

After setting the switch, the usage reports for workloads available in the Microsoft 365 admin center contain obfuscated user data (Figure 2).

The setting also covers the usage reports available in the Teams admin center.

The Graph Reports API is to Blame

The setting to control the anonymization of personally identifiable data applies to all reports generated by the Microsoft Graph Reports API, which is the basis for the usage reports in the Microsoft 365 admin center. Deciding to obscure usage data can cause an admin to swap settings to access some information. For instance, the admin center has a report for Microsoft browser usage (Chrome, Brave, and Firefox are studiously ignored). The report is useful to find people who still use the legacy Edge browser, which Microsoft removed from the April 2021 update. But if you look at the report to find the names of people to contact to ask them to switch to a supported browser, you’ll be the deidentified strings like C58FABF670363F68A787078886FCB1A1.

The same issue exists in reports like active users or groups activity, which are examples where the data is all but useless if you don’t know what users are active (and who isn’t) and what groups are in use (and which are not). In all cases, an admin can fix the problem quickly by resetting the switch, but it does show how unintended consequences often flow from an action.

ISV and Your Own Reports as Well

Microsoft hypes the Graph Reports API to ISVs and customers as an easy way to integrate Microsoft 365 usage reporting into existing reporting solutions. This is true, but the downside is that the same switch used to control user anonymization in the Microsoft 365 admin center usage reports affects any other use of the API in a tenant.

For example, we have a PowerShell script to collect information about user activity from a range of Microsoft 365 workloads to present a per-user synopsis of how they interact with the service. The script uses the Reports API to fetch usage data from each workload and combines it together for each user to create the report. If the tenant switches on data obfuscation, the usage report fetched by the script is anonymized and returns data like this:

Report Refresh Date : 2021-04-13
User Principal Name : 47A3F2B66A3C6BF31F1C629D02B43A24
Display Name        : 24589499045E94C4FF5C4A681A467937
Is Deleted          : False
Deleted Date        :
Last Activity Date  : 2021-02-20
Send Count          : 76
Receive Count       : 123
Read Count          : 0
Assigned Products   : MICROSOFT 365 E5 DEVELOPER (WITHOUT WINDOWS AND AUDIO CONFERENCING)
Report Period       : 90

Although the user’s privacy is protected, from an organizational perspective the value of the report is negated.

Understand What Obfuscation Means

It’s easy to understand why Microsoft builds the ability to anonymize user data in reports into the admin center. Several user-assignable roles (like Reports Reader) can access the reports, so it’s good to have a way to protect user privacy, even if it’s only surface-deep. What’s less understandable is the impact the switch has on custom reporting. It just seems a little crude to have a binary switch which control all output.

Self-Service Photo Updates

It’s easy for tenant administrators to add photos for guest accounts using the Azure AD portal. They can also run the Set-AzureADUserThumbnailPhoto cmdlet to do the same job. The difference is that apps can display Azure AD guest photos where otherwise they’d show the default initials (Figure 1).

What isn’t easy is for people who have guest accounts in other Microsoft 365 tenants to update their photo without administrator intervention. Microsoft blocks guest users from the features built into apps like Teams to allow users to update their photos, probably because guest accounts are not subject to the OWA mailbox policies which control this feature for tenant accounts.

Then MVP Yannick Reekmans published a blog to explain how he used the Azure AD portal to update a guest account in another tenant. The article explains how to find the GUID of the guest account in the target tenant and how to use the GUID to update the account. The method certainly works, but it’s a tad overcomplicated for my taste.

PowerShell makes the task very easy. Here’s how to do the job in three steps.

Sign into the Target Tenant

The key to this method is to use cmdlets in the Azure AD or Azure AD Preview modules. Make sure to download and install one of these modules on your workstation. Then, run the Connect-AzureAD cmdlet to connect to the service domain of the target tenant.

The service domain is the sub-domain in onmicrosoft.com used by the tenant. For example, to connect to the Office365ITPros.com tenant, we’d use the command:

Connect-AzureAD -Tenant Office365ITPros.onmicrosoft.com

Azure AD prompts you to authenticate. Use your normal account and sign in with its password (and MFA, if required by the tenant). Your normal account connects to the guest account, so when you authenticate, you use the guest account to access the target tenant. If you don’t know the service domain for the target tenant, use the What’s My Tenant ID site to find tenant GUID and use it to sign in. For example:

Connect-AzureAD -Tenant 72f988bf-86f1-41af-91ab-2d7cdxab647

Then run the Get-AzureADTenantDetail cmdlet and examine the VerifiedDomains property to find the service domain.

(Get-AzureADTenantDetail | Select-Object -ExpandProperty VerifiedDomains | Where-Object {$_.name -match "onmicrosoft"}).Name

Figure Out the User Principal Name

You can reference Azure AD accounts with the GUID (object identifier) or user principal name (UPN). The UPN is usually easier to figure out because it follows a set format. For instance, the guest account for the account with UPN Tony.Redmond@office365itpros.com is:

tony.redmond_office365itpros.com#EXT#@xxxxx.onmicrosoft.com

Where “xxxxx” is the name of the target tenant.

To make things easier, we put the UPN into a variable:

$UPN = "tony.redmond_office365itpros.com#EXT#@xxxxx.onmicrosoft.com"

Update the Photo for the Guest Account

Azure AD needs a suitable photo file (JPEG or PNG) to update a user’s image. Unlike Exchange Online, which stores a higher resolution form of photo data for use by Microsoft 365 apps, Azure AD stores only small thumbnail images. These images are acceptable for the small photos seen in Teams conversations or in browser menu bars, but not for attendee cards used in Teams meetings, so they do not appear everywhere within Microsoft 365.

The maximum size of the input file is 100 KB. I’ve had good results with square photos measuring 500 x 500 pixels. You might have to play with a photo editor to create a good photo of the right size, but once you have one, you can write it into Azure AD using the Set-AzureADUserThumbnailPhoto cmdlet:

Set-AzureADUserThumbNailPhoto -ObjectId $UPN -FilePath c:\temp\MyPhoto.jpg

If you don’t see an error, you know Azure AD is happy with the photo. To check, you can run the Get-AzureADUserThumbnailPhoto cmdlet. Any response is good:

Get-AzureADUserThumbnailPhoto -ObjectId $UPN

Tag                  :
PhysicalDimension    : {Width=500, Height=500}
Size                 : {Width=500, Height=500}
Width                : 500
Height               : 500
HorizontalResolution : 95.9866
VerticalResolution   : 95.9866
Flags                : 77842
RawFormat            : [ImageFormat: b96b3caf-0728-11d3-9d7b-0000f81ef32e]
PixelFormat          : Format32bppArgb
Palette              : System.Drawing.Imaging.ColorPalette
FrameDimensionsList  : {7462dc86-6180-4c7e-8e3f-ee7333a7a483}
PropertyIdList       : {769, 305, 20752, 20753...}
PropertyItems        : {769, 305, 20752, 20753...}

Like any operation involving photo manipulation for Azure AD accounts, it takes some time for applications to refresh their caches and pick up new photos. You should expect that this will happen within a day. And once it does, you’ll see your bright smiling face in places where only your initials were before (Figure 2).

And then all you need to do is to rinse and repeat the process for every tenant where you have a guest account (possibly some of which you have forgotten). For whatever reason, some tenants always seem to be slower than others to respect photo updates. I have no idea why this happens. Stay patient and the photos should turn up eventually.

Not Too Much for Administrators to Worry About

It’s good when guest accounts have photos. People like to know with whom they collaborate, and a photo is a much better reminder of a person than their initials can ever be. Tenant administrators might be concerned that guest users can sign into their tenant to update their photos. It’s true that guests could exploit this technique to display an inappropriate image. If they do, I’m sure that action will follow quickly, just like it would if a tenant user selected a distasteful photo. Another concern might be that guests might be able to update other account properties, like the display name. Much as I would like to do this, I haven’t been able to in any of the tenants where I tried. Azure AD allows me to update my photo but stops me doing anything else to my guest account. Which is how it should be.

Need to know more about managing guest accounts in an Office 365 tenant? The Office 365 for IT Pros eBook is packed full of advice and guidance on this and many other topics.

Putting the Best Face on Every User

Updated 3 October 2023

Update: Microsoft announced (MC678855) the deprecation of the Exchange Online management cmdlets used to manage user photos (Set-UserPhoto, etc.). These cmdlets will be removed from use on 30 November 2023. You should upgrade scripts to use the cmdlets from the Microsoft Graph PowerShell SDK instead.

In April 2020, Microsoft introduced a policy to stop users being able to update their photo through the Teams client. More accurately, Teams adopted the SetPhotoEnabled setting in the Exchange Online OWA mailbox policy to control if a user can update their photo. Since then, I have noticed a flood of questions (or complaints) from people asking why their attempts to upload a photo is “blocked by policy.” Of course, the answer is that it is, and they should talk to their tenant administrator to have their photo updated, but that’s seldom a welcome response.

Given that user photos show up in places as diverse as the GAL, the Microsoft 365 user profile card, and avatars in applications like SharePoint Online and Teams, it’s a good idea to make sure that appropriate photos are available for users. For example, if a user photo is available, Teams meetings show the photo on a user’s attendee card when their video feed is turned off instead of the more generic “two-initials in a circle” card (Figure 1).

Two Strategies

Organizations usually consider two approaches before deciding on a strategy for user photo management.

• User-driven. While this strategy involves less work for administrators, it exposes the danger that some users might make less than suitable photo choices. It’s a poor choice for schools and other educational establishments.
• Organization-driven. This strategy usually means that some tool updates user photos based on a repository such as HR data. The upside of the strategy is the high standard of user photos. The downside is the need to either write a tool or find one to do the job (like Code Two Software’s Photos for Office 365).

Of course, given that control is exerted by OWA mailbox policies, you can run a hybrid strategy where some users can update their photos, and some cannot through the simple step of deploying multiple OWA mailbox policies, some of which enable photo updates and the others which don’t.

The Role Played by Exchange Online

Exchange Online plays a key role in user photo management for other Microsoft 365 applications. The SetPhotoEnabled setting in the Exchange Online OWA mailbox policy assigned to the mailbox controls the ability for users to update their photo. By default, this setting is $False, meaning that users are unable to upload a photo from apps and their Office profile. Users barred by policy see a message such as “picture options are disabled by policy” if they try to change their photo. To allow users to upload and update their photos, either:

• Update the OWA mailbox policies so that SetPhotoEnabled is $True in all policies, or:
• Create or update an OWA mailbox policy with SetPhotoEnabled set to $True and assign this policy to the mailboxes of accounts you want to allow to upload photos.

For example, to update an OWA mailbox policy, run the Set-OWAMailboxPolicy cmdlet:

Set-OWAMailboxPolicy -Identity OWAFullAccess -SetPhotoEnabled $True

To assign an OWA mailbox policy to a mailbox, use the Set-CASMailbox cmdlet:

Set-CASMailbox -Identity Chris.Bishop -OWAMailboxPolicy OWAFullAccess

Changes to an OWA mailbox policy take up to 30 minutes before they are effective.

OWA mailbox policies in Exchange Online obviously don’t affect users with an on-premises Exchange mailbox. These users are therefore able to update their photos in apps like Teams.

Updating User Photos Programmatically

Several PowerShell cmdlets are available to administrators to update user photos.

• The Exchange Online Set-UserPhoto cmdlet updates the photo data in a mailbox. Set-UserPhoto can also update a photo for a group mailbox (be sure to specify the GroupMailbox switch). You cannot use Set-UserPhoto to update other mail-enabled objects, like distribution lists or mail contacts. Photos loaded into Exchange Online are synchronized to other workloads, including SharePoint Online and Teams.
• The Teams Set-TeamPicture cmdlet updates the image for a team. This is analogous to running Set-UserPhoto to update the photo for a group mailbox. In most cases, it’s best to use Set-UserPhoto to avoid the need to load another module. It’s a good idea to highlight important teams with an appropriate image which conveys the purpose of the team.
• The Azure AD Set-AzureADUserThumbnailPhoto cmdlet writes photo data to an Azure AD user account. Use this cmdlet when you wish to update photo data for an Azure AD account which doesn’t have an Exchange Online mailbox, like guest accounts. As the cmdlet name suggests, the cmdlet processes thumbnail (small) photos. It does not generate the larger size photos which look better in Teams meetings. For this reason, always use Set-UserPhoto to upload photos for tenant accounts.

Update: With the deprecation of the Azure AD PowerShell module, you should upgrade scripts to use the Set-MgUserPhotoContent cmdlet from the Microsoft Graph PowerShell SDK to update photos for guest accounts.

Exchange Online and Azure AD synchronize photo data to make sure that user accounts have the latest picture. After a short delay to allow the apps to refresh their caches, an updated photo will be active across the ecosystem.

Teams owners can change the picture for a team by clicking the existing picture and uploading a new file (Figure 2). Group owners can do the same for Microsoft 365 groups by editing group properties in OWA’s Manage groups section. In both cases, the picture data is in the group mailbox and will synchronize to other apps.

Image files for user photos can be JPEG or PNG format and should be:

• Resolution: 648 x 648 pixels. This is the largest resolution supported. Behind the scenes, Exchange Online generates smaller 64 x 64 and 96 x 96-pixel thumbnails for apps to use when small thumbnails are appropriate. Most digital photos are much larger (in pixels) so some resizing is needed. Square photos are best as they won’t be cropped. Usually, best results are obtained when the user faces directly into the camera.
• Size: Less than 500 KB.

Although it can take 30 seconds or more to update a picture for a mailbox, running Set-UserPhoto is simple:

Set-UserPhoto -Identity Chris.Bishop@office365itpros.com -PictureData ([System.IO.File]::ReadAllBytes("c:\Temp\ChrisBishop.jpg")) -Confirm:$False

If you want to check if a mailbox already has a picture (to avoid overwriting it), use the Get-UserPhoto cmdlet. This cmdlet returns $Null if the mailbox has no photo. Remember to include the GroupMailbox switch if checking a group mailbox (including team-enabled groups).

If (Get-UserPhoto -Identity Chris.Bishop@Office365Itpros.com) {Write-Host "Chris has a photo"}

If you make a mistake and upload the wrong image, you can restart by removing the image with the Remove-UserPhoto cmdlet:

Remove-UserPhoto -Identity Chris.Bishop@office365itpros.com -Confirm:$False

An example of how to scan user mailboxes to update photos if none are found can be downloaded from GitHub.

The Personal Side of Users

User photos are extremely personal, and it should come as no surprise that people should be upset when they cannot change their image. If you decide to clamp down on user-initiated photo updates, perhaps it might be a good idea to create a process to allow users to request photo changes. It might just keep people happier.

Why You Might Need to Know Your Microsoft 365 Tenant Identifier

Every Microsoft 365 tenant is identified by a GUID, a globally unique identifier, which looks something like abf988bf-86f1-41af-91ab-2d7cd011db46. Applications use the tenant identifier to know which organization data belongs to. Occasionally, administrators need to know the identifier too:

• Microsoft support might ask for the tenant identifier as part of the information gathered for a support incident.
• If you participate in a test of new functionality, the Microsoft engineering group responsible for the feature will need the tenant identifier to enable (or “flight”) the software.
• Apps registered in Azure AD which use the Graph APIs to access tenant data must pass the tenant identifier along with the app identifier and app secret when requesting an access token. The combination of the three pieces of data allows Azure AD to grant the necessary token.

Applications like Teams include the tenant identifier in the links used to identify data. For instance, the deeplink used for a Teams meeting contains the tenant identifier.

Available to Allow Apps to Authenticate

Tenant identifiers are exposed publicly. If they were not, applications based on the Graph APIs or any others using OAuth 2.0 could not connect to a tenant. These apps use OpenID Connect, described by MVP Curtis Johnstone as “a simple identity layer that sits on top of OAuth 2.0. For Office 365 there is an OpenID Connect metadata document for each tenant which contains more of the information required for apps to perform sign-ins (including the tenant id).”

For instance, an app can find the information for Microsoft’s own tenant at https://login.microsoftonline.com/microsoft.com/.well-known/openid-configuration (Figure 1). Apps can fetch this information to receive the necessary data needed to navigate the OAuth 2.0 authentication process.

Finding the Tenant Identifier

Several methods exist to find the tenant identifier within Microsoft 365. Here are the most common, starting with PowerShell.

When you connect to Azure AD with PowerShell, the response contains tenant information, including the identifier.

Connect-AzureAD

Account               Environment TenantId                            TenantDomain    
-------               ----------- --------                            
Administrator@xxx.com AzureCloud  a462313f-14fc-43a2-9a7a-d2e27f4f3478 xxxxxxxx.com 

Microsoft intends to deprecate the Azure AD module in June 2023. The equivalent cmdlet in the Microsoft Graph PowerShell SDK is Get-MgOrganization:

Get-MgOrganization | Select Id, DisplayName

Id                                   DisplayName
--                                   -----------
a462313f-14fc-43a2-9a7a-d2e27f4f3478 Office 365 for IT Pros

Much the same happens when connecting to Microsoft Teams with PowerShell. Again, the connection responds with tenant information with the tenant identifier shown for both the tenant name and identifier!

Connect-MicrosoftTeams

Account               Environment Tenant                               TenantId
-------               ----------- ------                               --------
Administrator@xxx.com AzureCloud  a462313f-14fc-43a2-9a7a-d2e27f4f3478 a462313f-14fc-43a2-

If you have a PowerShell session connected to Azure AD, you can run the Get-AzureADTenantDetail cmdlet. This is the method I typically use.

Get-AzureADTenantDetail

ObjectId                             DisplayName               VerifiedDomain
--------                             -----------               --------------
A462313f-14fc-43a2-9a7a-d2e27f4f3478 Office 365 for IT Pros    Office365ITPros.com

The Overview page of the Azure AD portal includes the tenant identifier and has the useful ability to copy the identifier to the clipboard (Figure 2).

Azure Where’s My Tenant

Azure operates a service to lookup using a tenant (Figure 3) to find details of a domain belonging to an Azure AD tenant (Figure 3). You can also input the Microsoft 365 tenant identifier.

ShareGate’s Service

ShareGate is an ISV specializing in SharePoint Online solutions. It offers a similar service to the Azure lookup at WhatIsMyTenantId.com. Figure 4 shows the result after checking for Quest.com. Remember, the tenant information is public!

I don’t ever use WhatIsMyTenantId.com, but I’m sure others do, especially when you have a bunch of tenants to manage.

The detail makes the difference. Learn about the detail of managing your tenant by subscribing to the Office 365 for IT Pros eBook. Updated monthly to include those changing details which make all the difference…

Unannounced Feature

On 17 March, Microsoft posted message center notification MC244882 to announce the immediate general availability of auto-claim policies in the Microsoft 365 admin center. Strangely, no roadmap item was cited, meaning that this feature never appeared on the Microsoft 365 roadmap. Thankfully, some documentation is available and the feature is disabled by default.

Apparently, the idea was around early last summer, but I never picked it up.

Auto-Claim Basics

The basic idea is that tenants can create policies to allow applications to claim from a pool of available licenses when a user needs a license to use the app. Auto-claim policies sounds like a good idea if you have:

• Users who are unlicensed.
• No other way of assigning licenses to users either manually during the account creation process, or automatically using your own scripts or with Azure AD group-based licensing.

Mature organizations usually have their own methods for license management and not many new accounts are created without the attachment of licenses.

Teams is the only app which supports auto-claim policies today but given that the policies are now integrated in the Microsoft 365 admin center, it’s likely that auto-claim policies will cover other apps in future. On the surface, it seems odd that Microsoft is now introducing another method. However, Azure AD group-based licensing requires Azure AD Premium P1 licenses and Office 365 E3 or E5, while apps like Teams have a much wider target audience.

Enabling Auto-Claim

Before you can define an auto-claim policy, you need to enable the feature. Go to the Billing section of the Microsoft 365 admin center, then Licenses, and select the Auto-claim policy tab. Finally, hit the big Turn on setting button (Figure 1).

You can also enable the setting through Org settings in the Microsoft 365 admin center. Go to User owned apps and services and check the option to let users auto-claim licenses the first time they sign in (Figure 2).

You can disable the auto-claim policy in Org settings. This doesn’t remove the policy if one is defined. Instead, the policy goes into abeyance until it is reactivated by switching the setting on again.

Creating a Policy

An auto-claim policy applies tenant-wide. There is no way to scope the policy to process only a selected group of accounts. Only one auto-claim policy exists for the tenant. This might change in time as additional apps support license auto-claim or Microsoft introduces policy scoping.

Creating a new auto-claim policy is straightforward. After giving the policy a name (always a test of creativity), the important part is when you link an app (Teams) with assignable licenses. In Figure 3, I define that if an unlicensed user accesses Teams, the auto-claim policy will step in to assign an Office 365 license to the user account. If no Office 365 licenses are available, the policy will attempt to assign an Office 365 E5 license (aka, the backup product).

Licenses like Office 365 E3 span many apps. Some tenants like to disable apps covered by licenses because they don’t want people using them. For instance, you might decide that Microsoft Bookings is not needed by users and so disable that app in the license. When creating an auto-claim policy, it was noticeable that the policy removed Exchange Online Plan 2. I turned it back on to receive an odd warning (Figure 4) that enabling Exchange might disrupt email delivery. Given that Microsoft strongly advocates a position that Teams is best when coupled with Exchange, this is an interesting stance.

After checking all the apps available in the licenses to be assigned, save the policy. It becomes effective immediately.

Testing License Assignment

To test that the auto-claim policy worked, I created a new account in the Azure AD portal. I then added the new account to a team and logged into Teams as the user. After going through the normal routine for a new user (setting a new password, etc.), Teams started up as normal. No indication appeared that a license assignment happened. From a user experience perspective, this is how things should happen. People responsible for the delivery of training before people use apps might need to reconsider how they approach training if license auto-claim becomes the norm.

The auto-claim policy does not assign a license for Teams if a licensed account with the Teams app turned off attempts to use the app.

According to the documentation, an auto-claim policy report is available in the Microsoft 365 admin center to show all licenses assigned by policy over the last 90 days. No trace of a report is visible in my tenant, but this is probably due to the normal two-day delay before usage reports are available in the admin center. It’s easy to check if a license is assigned to an account by looking at its properties (Figure 5), where we find that the policy did indeed work and a license is present.

You can also track license assignment in the audit events logged for the account in the Azure AD portal. Figure 6 shows details of an audit event captured after a license is assigned when a user logs into Teams for the first time.

Audit records also appear in the Office 365 audit log. Search for “Update user” operations and look for license updates in the ModifiedProperties property of the Auditdata payload in the audit events. You’ll see a bunch of license assignments recorded there similar to those shown in Figure 6 (unsurprising, because it’s the same data).

Update: After 7 days, no auto-claim report has shown up in the admin center.

A Good Idea but Maybe Not for All

Auto-claim policies seem like a good idea. It’s hard to be definitive now because these policies need to be tested in the wild and assessed by organizations which already have their own methods for license assignment, including granular management of licenses at departmental or country level. Given that solutions already exist in this area (after ten years of Office 365, it would be hard if tools weren’t available), people will need to be convinced to move from what they do now. I could see this approach being popular in sectors with heavy account turnover, like schools, but perhaps less so in large enterprises where license management is often a well-defined art.

Avoiding the Need to Remove and Recreate Guest Accounts

Microsoft 365 applications like Microsoft 365 Groups, Teams, SharePoint Online, and Planner use Entra ID B2B Collaboration to enable guest user access to their resources. The result is that many tenants have a proliferation of guest accounts to manage. I’ve written quite a few tools to help, including a report of guest accounts and their membership of Microsoft 365 Groups and a comprehensive report of tenant and guest members in Groups and Teams. Management can even be a challenge for guests who want to renounce their membership of a tenant.

In any case, the details of some guest accounts change over their lifetime. On March 2, Microsoft issued documentation for Reset redemption status for a guest user. This doesn’t sound very exciting, but it’s really very interesting because the feature allows tenant administrators to adjust how a guest account is signed into without using the previous technique of removing and recreating an account. The downside of that approach is that access is lost to all the resources available to the guest account like Teams, SharePoint sites, shares to individual documents, and so on. After recreating the account, access must then be regranted for each resource. This process is tedious, especially when the guest features in multiple groups.

Microsoft anticipates that the reset feature will be used in scenarios such as:

• The user wants to sign in using a different email and identity provider. In other words, they now have a different account. For instance, the user might have moved companies and wishes to continue working with your company (a common scenario for professionals like IT consultants and lawyers).
• The account for the user in their home tenant has been deleted and recreated. Entra ID won’t recognize the link between the guest account and the user’s new account.
• The user’s responsibilities have been passed along to another user and they want to assign access to the resources which supported those responsibilities to that user.

Part of the change is performed using the Entra ID admin center. The rest is done with PowerShell cmdlets from the AzureAD Preview module, which you can download from the PowerShell Gallery.

Change the Email (Sign-in) Address for a Guest Account

Unlike tenant accounts, guest users don’t use their user principal name to sign in. Instead, they use their email address. To work, the reset feature changes the sign-in name for the guest account and nothing else. The mail user object created in Exchange Online to allow guest users to receive email is also updated.

In this example, I have a guest account for Jacko Winters. The original email address for this account is Flayosc@outlook.com. The guest is a member of multiple teams and shares some SharePoint documents. I want to reassign access to all these resources to another account called Flayosc@yandex.com. It’s an example of the first scenario described above.

The first step is to update the Mail attribute (Email address) for the guest account with the email address you want to use. Do this through the Entra ID admin center (Figure 1). The new email address cannot belong to any other mail-enabled object in the tenant, such as another guest account. If it does, Entra ID won’t allow you to update the account.

Moving to PowerShell, connect to AzureAD and get the Entra ID account identifier for the guest account you want to replace.

Connect-AzureAD
$ObjectId = (Get-AzureADUser -SearchString “Jacko Winters”).ObjectId
$ObjectId
558d8cbb-a5a2-4ea1-b950-0d0748ca5634

Now create a new User object and populate it with the object identifier for the account.

$OldUser = New-Object Microsoft.Open.MSGraph.Model.User -ArgumentList $ObjectId
$OldUser

Id                                   OdataType
--                                   ---------
558d8cbb-a5a2-4ea1-b950-0d0748ca5634

Issuing a New Invitation

The next thing to do is check that the values returned from the two commands match. If they do, use the New-AzureADMSInvitation cmdlet to reissue an invitation to the new email address. The identifier for the guest user account is passed in the InvitedUser parameter. The myapps.microsoft.com landing page is a default site showing apps available to a user. Here’s the command I ran:

New-AzureADMSInvitation -InvitedUserEmailAddress Flayosc@yandex.com -SendInvitationMessage $True -InviteRedirectUrl "http://myapps.microsoft.com" -InvitedUser $OldUser -ResetRedemption $True

Update: Given the deprecation of the AzureAD module in March 2024 (and the disappearance of the ResetRedemption parameter from the New-AzureADMSInvitation cmdlet), you should switch to the Microsoft Graph PowerShell SDK. This code is the equivalent using the Get-MgInvitation cmdlet:

$User = Get-MgUser -Filter "startsWith(mail, 'Flayosc@yandex.com')"
New-MgInvitation `
    -InvitedUserEmailAddress 'Flayosc@yandex.com' `
    -InviteRedirectUrl "http://myapps.microsoft.com" `
    -ResetRedemption `
    -SendInvitationMessage `
    -InvitedUser $User

See this documentation for more information.

Entra ID creates a new invitation to access the resources currently available to the guest account and sends it to the new email address. You’ll see a response like this:

Id                      : 129c1c12-da99-4879-b258-d14b34601d46
InvitedUserDisplayName  :
InvitedUserEmailAddress : Flayosc@yandex.com
SendInvitationMessage   : True
InviteRedeemUrl         : https://login.microsoftonline.com/redeem?rd=https%3a%2f%2finvitations.microsoft.com%2fredeem%
2f%3ftenant%3db662313f-14fc-43a2-9a7a-d2e27f4f3478%26user%3d129c1c12-da99-4879-b258-d14b34601
d46%26ticket%3dLStZd8uAONAIbLNIZyfaUZ91VsRczLbzqbFOeHsonSE%253d%26ver%3d2.0
InviteRedirectUrl       : http://myapps.microsoft.com/
InvitedUser             : class User {Id: 558d8cbb-a5a2-4ea1-b950-0d0748ca5634
OdataType: }

InvitedUserMessageInfo  : class InvitedUserMessageInfo {
                            CcRecipients: System.Collections.Generic.List`1[Microsoft.Open.MSGraph.Model.Recipient]
                            CustomizedMessageBody:
                            MessageLanguage:
                          }

InvitedUserType         : Guest
Status                  : PendingAcceptance
ResetRedemption         : True

Accepting the Reissued Invitation

The invitation arrives at the email address (Figure 2) and the user can accept the invitation to confirm their credentials (set a password) and create an OAuth consent to allow the tenant to read details of the user’s account (Figure 3).

Once the user consents to the permissions, the user account is updated to set the UserState property to Accepted and write the date of the redemption in UserStateChangedOn. We now have a fully functional guest account again. The important point is that the object identifier and user principal name for the account do not change. The only thing which changes is the mail address associated with the account.

The Entra ID audit log contains details of the issue (Figure 4) and redemption of the invitation. While the activity tab confirms the target address for the invitation, the target tab confirms the guest account.

Accessing Resources

In this instance, the guest account has access to several teams and some SharePoint documents. SharePoint access is immediate, including the sites used by Teams. Guest access to Planner also works properly.

After testing that access worked for SharePoint and Planner, I turned to Teams. I expected access to the Teams app to take longer because of the need to complete the process which synchronizes Entra ID with the membership roster used to control access to individual teams. Until this happens, the user is refused access to Teams (Figure 5) and the old email address assigned to the guest account remains visible in Teams (Figure 6). [Note that the display name of the guest account has reverted to Flayosc instead of Jacko Winters]

Unsurprisingly, because the account information in Teams is now outdated, any attempt to add the guest account as a new member of a team also generates an error (Figure 7).

To try to force synchronization, I updated the display name and several other attributes of the account. This had no effect, so I added a couple of new users to the group using Teams to force Teams to refresh its membership roster. The updates flowed through to Entra ID, but nothing happened in Teams.

Get-AzureADGroupMember -ObjectId b647d5ff-3bda-4333-b768-7990084569b6

ObjectId                             DisplayName                   UserPrincipalName
--------                             -----------                   -----------------
cff4cd58-1bb8-4899-94de-795f656b4a18 Tony Redmond                  Tony.Redmond@office365itpros.com
b3eeaea5-409f-4b89-b039-1bb68276e97d Ben Owens (Business Director) Ben.Owens@office365itpros.com
a6bfb216-e88c-4f1f-86d7-04747e5fc686 Ben James                     Ben.James@Office365itpros.com
9ba20686-f869-46e8-85a2-00ec8a035e48 James Joyce                   James.Joyce@office365itpros.com
acb778e8-f587-45de-ae3a-e76007e043b2 Paul Howett                   Paul.Howett@office365itpros.com
98dda855-5dc3-4fdc-8458-cbc494a5a774 Sean Landy                    Sean.Landy@office365itpros.com
6b52fba5-349e-4624-88cd-d790883fe4c4 Ken Bowers                    Ken.Bowers@office365itpros.com
558d8cbb-a5a2-4ea1-b950-0d0748ca5634 Jacko Winters                 flayosc_outlook.com#EXT#@office365itpro

Get-AzureADuser -ObjectId 558d8cbb-a5a2-4ea1-b950-0d0748ca5634 | ft mail, displayname, objectid

Mail               DisplayName   ObjectId
----               -----------   --------
flayosc@yandex.com Jacko Winters 558d8cbb-a5a2-4ea1-b950-0d0748ca5634

The Original email address can’t be used to sign into Teams either. Eventually, after a couple of days, Teams synchronized with Entra ID and the updated account details became visible in Teams. However, the updated account could not sign into Teams.

Come Home to Teams

Working with the Entra ID development group, the problem was diagnosed to due to the way Teams tries its best to bring a user to their home tenant. In the case of guest users, Teams uses the sign in address to locate the tenant and headed off to the wrong place. When using an explicit redirect to the tenant identifier, like https://teams.microsoft.com/?tenantId=c662313f-14fc-43a2-9a7a-d2e27f4f3478, the user can connect.

Obviously, there’s some work for Teams to do to cope when administrators assign new email addresses to guest accounts, but at least the problem is known, and Microsoft will no doubt fix the issue soon.

All this work for a few lines in Chapter 13 of the Office 365 for IT Pros eBook. It just goes to prove how much work and effort the writing team puts in to keeping content accurate, refreshed, and updated. Subscribe now to receive monthly updates of goodness.

App Consent Events Amongst Thousands of Audit Events Generated Across Microsoft 365

Following the publication of the article describing how to report the use of sensitivity labels by using audit events, a reader asked what’s the best way to discover if a feature generates an audit event. At the time of writing, Microsoft 365 workloads store more than 1,600 different events in the audit log, so understanding every auditable operation is a massive task, especially if you’re looking for something specific, like app consent events. New audit events show up in the audit log on an ongoing basis as Microsoft introduces new features, hopefully with an accompanying audit event, or backfills by updating features so that they generate audit events.

Looking for New Audit Records like an App Consent Event

Our method to discover new audit events is simple. It depends on the fact that every audit event notes an operation, or action performed to generate the event. You can filter audit records by specifying the type of operations to see. For instance, to see who send email on behalf of a shared mailbox, you can look for audit events with the SendAs operation. Here’s what we do to find if a new feature is captured in an audit event.

• First, use the new feature. Ideally, perform actions several times with different accounts.
• Second, wait for at least an hour to allow the ingestion of audit events from the source workload and appear in the audit log.
• Next, run a search to find all audit events for the current day and group and sort the results by operation. Make sure to specify the user principal name of the account which performed the accounts in the UserIds parameter.

[array]$Records = Search-UnifiedAuditLog -StartDate (Get-date).AddDays(-1) -EndDate (Get-Date).AddDays(1) -ResultSize 2000 -Formatted -UserIds James.Ryan@office365itpros.com -SessionCommand ReturnLargeSet

$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [datettime]}
$Records | Group Operations | Sort Count -Descending | Format-Table Count, Name

You should now be able to browse the sorted list of operations to find unfamiliar actions, such as Set-LabelPolicy (logged when someone updates a sensitivity label policy). You can take the same approach with the Audit search feature in the Compliance Center, but not all audit events show up there.

Investigating a New Audit Event

Typically, the new events appear at the end of the list. For instance, looking at a recent set, we see an event called Consent to application. This hadn’t come to our attention before:

    1 Consent to application.
    1 Get-DlpSiDetectionsReport
    1 New-Mailbox
    1 Set-TenantObjectVersion
    1 Set-AdminAuditLogConfig
    1 Get-ComplianceTag
    1 Send
    1 SoftDelete

Checking the event, we found that the event originated in Entra ID and relates to granting OAuth consent (permission to access data) to an application. Due to recent problems like the SolarWinds attack, there’s been heightened sensitivity to the need to understand what access to data has been granted within an organization. If you don’t know who can access data, you can’t detect and remediate illicit consents which might have been secured by attackers.

While other tools like the PowerShell script created by Microsoft (see this article) are better at enumerating and reporting consent grants for review, it’s interesting to find that Entra ID captures app consent events, In this case, an examination of the event data revealed that the consent was for the Microsoft Events app used for purposes like registering for the Microsoft Ignite online conference.

Checking the app registration in the Entra admin center, you can find the permissions assigned to the app. In this case, the app reads Entra ID to fetch details of people who register using their user account.

You can confirm that you’re looking at the same app by checking the application ID in Entra ID (e462442e-6682-465b-a31f-652a88bfbe51) with the details captured in the audit record:

{
                     "ID": "e462442e-6682-465b-a31f-652a88bfbe51;https://microsoft.onmicrosoft.com/aef17311-1f14-4e06-939b-42c0bcff5520",
                     "Type": 4
}

This example illustrates the value of checking for new audit events periodically. Now that we know that app consent events are available to track new consents, it’s easy to create a script to report consent grants over the last 90 days (the time audit events are kept for E3 accounts). You can grab an example script from the Office 365 IT Pros GitHub repository. See the Cloud Architect GitHub page for more information about resisting consent grant attacks.

If you want to distribute the report in other ways, you could:

• Format the content in HTML and send it via email (see this article for details).
• Create the report in a SharePoint document library (the basics of how to do this is explained here; the scenario is a script running in a Azure Automation runbook but the technique of using PnP cmdlets is the same in “regular” PowerShell).
• Post the report to a Teams channel or post a link to it in a message card created in a Teams channel using the inbound webhook connector. See this article for more information.

Microsoft Datacenter Operations

Searching the audit log to find new events also uncovers audit events logged when Microsoft updates tenant settings as part of their normal datacenter operations. For instance, Microsoft often updates OWA mailbox policies to introduce a control for a new OWA feature. When this happens, you’ll find audit events logged for a user called NT AUTHORITY\SYSTEM (Microsoft.Exchange.ServiceHost) for the policy updates.

You can do nothing about Microsoft configuration updates, but at least you can discover when they happen by poking around in the audit log.

Chapter 21 of the Office 365 for IT Pros eBook goes into how auditing works in great detail and describes several examples of how audit data answers important questions. If you’re running a tenant, you need to have this information!

Do Real User Mailboxes Receive a Message a Second?

What should we make of Microsoft’s decision to impose a hard limit on Exchange Online mailboxes receiving more than 3,600 messages per hour, as reported in message center notification MC239262 on February 13?

Simply this: in any large platform where resources are shared, some will try to take more resources than they should and it’s clear that some mailboxes are regularly exceeding thresholds. Microsoft says the number is very low, but once evidence of abuse appears, it becomes a candidate to be stamped out.

Microsoft has operated a soft limit (meaning that it wasn’t applied) for inbound message volume since Exchange Online commenced (other limits govern the ability to send outbound messages). The threshold of 3,600 messages per hour has been in place for at least four years. That’s one new message arriving in the inbox every second. Even the most productive user on the face of the planet cannot cope with such a torrent of inbound email, so the conclusion must be that mailboxes handling such amounts are used by automated processes rather than humans.

It’s possible that the automated processes are not trying to take advantage of Exchange Online. For instance, a process might generate email to inform recipients of its progress. Run in test conditions, the volume of email might be small and easily dealt with. When scaled up for production, the same code probably generates far more progress reports, and if several processes take the same approach to reporting and use the same target mailbox, it’s possible to imagine that the mailbox might receive a large volume of reports. But directing one new message per second over a sustained period to a single mailbox is too much. Mailboxes and their databases are not designed for that kind of sustained traffic.

Introducing Hard Limits

Microsoft says that they will impose a hard limit in April 2021. They will introduce the new limit gradually, starting with a higher limit and moving down to the published threshold. Think of this as a hard limit of 5,000/messages/hour being reduced weekly until the 3,600 figure is reached.

A new Mailboxes exceeding receiving limits report in the new version of the Exchange admin center (EAC) will help admins identify problems. The report lists mailboxes that have hit the threshold or are close to the threshold over the last 24 hours. The idea is that someone then calls up the mailbox owners to ask (politely) why they receive so much email. Microsoft says that admins should contact mailbox owners “to understand why they are receiving so many messages and inform them of ways to reduce mail volume and improve their experience.” In other words, “stop making my life difficult and change your code to reduce email volume.”

The Effect of Throttling

Once a mailbox hits the threshold, Exchange Online will throttle its ability to receive new email. In this context, throttling does not mean “slow down inbound traffic.” Instead, Exchange will refuse delivery of new email for an hour after the threshold is reached.

To make the mailbox owners aware that throttling is in force, Exchange sends an automated email to the affected mailboxes. Given the volume of new messages arriving in the mailbox, you’d wonder if the mailbox owner will ever see the notification of throttling. To offset the problem, Microsoft will make sure that the warning message appears at the top of the inbox.

Even with the warning message highlighted in the inbox, it is more likely that mailbox owners will more quickly react to sender complaints who receive non-delivery notifications (NDRs) saying that the mailbox can’t receive new messages because it has exceeded the threshold. Of course, if the senders are automated processes, they will probably ignore the NDRs.

EAC Highlights Problems

The EAC will highlight threshold violations in its Insights section with a notice saying that “one or more mailboxes have exceeded their receiving limits.” To avoid the need to access EAC to see what’s going on, Microsoft says that admins will be able to create an alert policy to send mail when a mailbox exceeds receiving limits. The ability to create alert policies doesn’t yet exist in EAC (Figure 1), but as the new version of the console is still under development, the functionality will hopefully show up before Microsoft beings to restrict high-volume mailboxes.

Hopefully, information about blocked mailboxes will also be posted as events in the Office 365 audit log. This will allow solutions like Microsoft Cloud App Security and third-party monitoring products to capture and signal problems with blocked mailboxes. Capturing events in the audit log also allows for at least a 90-day lookback (for E3 accounts – 365 for E5) should that need arise.

Need to learn more about how Office 365 and its apps work? Subscribe to the Office 365 for IT Pros eBook. We publish monthly updates to keep our subscribers updated about changes like the one described here.

Understand How People Use Sensitivity Labels to Protect Office Documents

If you enable support for sensitivity labels in SharePoint Online and OneDrive for Business (and you should), most of the previous frustrations that organizations have experienced in dealing with protected go away. Protected (encrypted) content can be indexed and found by eDiscovery, co-authoring is supported (with Office Online), and so on. And very importantly, Office 365 captures audit events when people apply, remove, or change sensitivity labels with Office documents.

Originally, only sensitivity label actions performed by the Office Online apps were captured. This is fine, but most user interactions with Office documents occur through the desktop apps. The gap in coverage is closing and the latest versions of the Microsoft 365 apps for enterprise (aka Office click to run) now create audit records when they apply or remove labels from documents. I’m using version 2012 – current channel preview (build 13350.20316) as the basis for this article, but I can see that audit records have been generated since mid-December.

Although the latter part of December is a period of low work activity, the number of events captured since compared against previous months confirms the view that desktop apps are used more heavily to generate documents, spreadsheets, and presentations. At least, in my tenant.

Separate Audit Events

Nice as it is to have the additional insight into the use of sensitivity labels, it’s regrettable that Microsoft did not use the same operation names when generating audit records for the desktop apps as they do for the online apps. The operation is the name of an auditable action.

It’s possible that the logic here is that the actions originate in two different sources and the different operations mean that administrators can conduct precise audit searches to find records for either the desktop or online apps – or both.

The new operations are:

• SensitivityLabelApplied: A sensitivity label is applied to an Office document. This operation is also used when capturing a record for the application of a label to a SharePoint site. The two can be distinguished by the record type, which will be either SensitivityLabeledFileAction (for Office) or SharePoint. Events are recorded when users apply sensitivity labels to Outlook messages, but not for messages protected by OME. OWA and Outlook mobile clients don’t currently generate audit events when users label messages.
• SensitivityLabeledFileOpened: An Office document with a sensitivity label is opened by a desktop app.
• SensitivityLabelRemoved: A sensitivity label is removed from an Office document.
• SensitivityLabeledFileRenamed: An Office document with a sensitivity label is renamed to become a new file. This event is also logged when a labelled file stored on a local device (not a copy synchronized by OneDrive) is edited.

As in many cases with Office 365 audit log records, the new events need to be parsed out before they’re useful. This is reasonably easy to do with PowerShell, albeit at the need to examine and interpret the payload content of each type of event.

Reporting Audit Events

Seeing is believing and it’s always easier to understand how things work when you have a practical example. I’ve written a script to grab all the events for sensitivity labels for the last three months and create a report. Each of the event types is unpacked and interpreted to make it clear what the event means. The output is a CSV file which can be analyzed in whatever way you wish. Or you can examine the output on-screen through the Out-GridView cmdlet (Figure 1).

The script is available in GitHub. You’ll need to connect to the Exchange Online management module and the security and compliance endpoint to run the cmdlets in the script. The compliance endpoint is used to fetch the list of sensitivity labels defined in the organization and create a hash table of GUIDs/identifiers (the keys) and label names (values). Some audit events contain label names but it’s more typical to only find a label identifier recorded, so lookups against the hash table translate identifiers into label names.

As you can see from the output, in my tenant most audit records are recorded when an Office desktop app opens a protected file:

Job complete. 370 Sensitivity Label audit records found for the last 90 days

Labels applied to SharePoint sites:  51
Labels applied to new documents:     45
Labels updated on documents:         5
Labeled files renamed:               29
Labeled files opened (desktop):      200
Labels removed from documents:       40
Mismatches detected:                 0
----------------------

Report file written to C:\temp\SensitivityLabelsAuditRecords.csv

In this case, no mismatches are noted between the label applied to a site (container management) and those assigned to documents stored in the site. My users might just be learning how to label documents properly!

We write tons of PowerShell scripts to check out how Office 365 really works and understand where any fault lines might be. Our GitHub repository is available to all. Even better, we explain how to use our scripts and other PowerShell commands to manage Office 365 in the Office 365 for IT Pros eBook.

Google Chrome might still be the favorite browser in terms of usage, but there’s no doubt that Microsoft Edge is slowly gaining a following, especially since the decision to embrace Chromium. The latest data gives Chrome a massive 63.63% versus 3.24% lead, but I guess hope springs eternal within Microsoft that Edge will make more of an impact over time. I stopped using Chrome some time ago and use Brave or Edge instead.

In any case, after a series of experiments, Microsoft announced the beta for sleeping tabs in the Edge browser in December. Everything seemed to go well and Microsoft enabled the feature in version 88 and later of the stable channel (Edge production). On the surface, the idea is excellent. Microsoft points to an average reduction in memory usage of 32% and an increase in battery life as benefits of the approach. Sleeping taps are greyed out until you select them (Figure 1) after which they reawaken.

More Authentication Cycles for SharePoint Online Sites

If, like me, you keep tabs open for SharePoint Online sites and other Microsoft 365 apps, sleeping tabs might become an annoyance. I typically have tabs open for three SharePoint Online sites plus Planner, the Microsoft 365 admin center, perhaps another admin center, and OWA. Since the introduction of sleeping tabs, I have been forced to reauthenticate access to sites more often than before. The process is something like this:

• Access sleeping tab.
• SharePoint looks for credentials.
• User enters credentials.
• SharePoint displays home site – not the site which was originally open.

The behavior seems to arise because the access token used for SharePoint Online is no longer valid. When a tab is “awake,” it can use a refresh token to acquire a new access token when the current access token expires. When a tab is asleep, its tokens might expire without having a chance to go through the renewal process. When that happens and the tab awakes, its access is invalid and reauthentication is necessary. Unfortunately, after securing new tokens through reauthentication, SharePoint Online returns the user to the home site instead of the site they had open. It’s very frustrating.

Other Microsoft 365 Sites Behave Differently

By comparison to SharePoint Online, Yammer protests about the lack of a token (Figure 2) but goes back to the same place once reauthentication happens. This only happens with Yammer’s new UI. It does not with the old UI.

OWA sleeps peacefully. When its tab awakes, a slight delay ensues while OWA figures out if new messages need to be fetched. To-Do doesn’t protest when awoken and Planner is content to return to its home page.

The Solution: Change Edge Settings

By default, tabs go asleep after two hours. The available options range from 5 minutes to 12 hours. Fortunately, the solution is simple. Edge allows you to create a list of sites that you do not want to sleep. Through the system section of Edge settings (edge://settings/system). In Figure 3, you can see that I’ve entered details of the sites I want to stay away, including any SharePoint Online site in my tenant.

The fix works and the sites on my list have returned to a normal authentication cycle. All is well with the world and I can get back to work.

The Office 365 for IT Pros eBook doesn’t cover this kind of thing, maybe because Edge has such a low usage percentage. But some might find this interesting, so we publish here.

After reading about the launch of Microsoft Viva, you might be interested in seeing whether the technology lives up to Microsoft’s promises. At present, the Teams Viva Insights app is available, but the full Viva Insights application won’t be generally available until later this year. For now, Viva Topics is the only component generally available. As it happens, I think Topics is the most interesting technology in the suite, so I was keen to see how it performs when exposed to real-life data.

Microsoft originally charged $5/user per month for Viva Topics on a one-year commitment before reducing it to its current rate of $4/user per month. Every user who interacts with Viva Topics (manages or consumes topics) needs to be licensed. Fortunately, Microsoft allows Office 365 tenants to run a 30-day trial to test Viva Topics for up to 25 users.

Starting a Free Trial for Viva Topics

To start, go to the Billing section of the Microsoft 365 admin center, select Purchase services, Purchase from Microsoft, then Add-ons, and search for “Topics Experiences” (you might have to expand the full set of add-ons to see Topics). Click Start free trial to get the ball rolling (Figure 1).

Quite why the admin center refers to Topic Experiences is unknown. The approved name is used on Microsoft’s Viva Topics page, where you can also initiate a trial. Both options end up with the same result. As you can see from Figure 2, Viva Topics can be licensed to run alongside many other plans.

Assign Licenses

The trial licenses are available immediately. Assign them to users who will participate in the trial using whatever method you like. Figure 3 shows assigning the Topics Experiences license to an account through the Microsoft 365 admin center. You can also assign licenses with PowerShell or by using Azure AD group-based licensing to control the set of trial accounts.

Setup Files and Content with the Viva Topics Wizard

The next thing is to start the process of automatic generation of topics for the organization. Go to the Setup section of the Microsoft 365 admin center. This section is where various components licensed for a tenant are configured. Find Files and content, labelled “Connect people to knowledge.” This is where you’ll configure Viva Topics. Click View to begin. When you’re ready to initiate Topics for your organization, start the Viva Topics Wizard (Figure 4).

The Viva Topics wizard presents four configuration steps:

• Discovery: Select the SharePoint Online sites to scan to categorize information used to build topics. A CSV file specifying sites as resources can be input. You can exclude topics from discovery, and again can use an input CSV file to specify those topics.
• Visibility: Define the set of users allowed to see the discovered topics in SharePoint pages (and eventually, other applications). Users can only see discovered topics when they have access to the files and pages the topic was discovered in. Accounts also must be assigned a Topics license before they can see topics in search results or applications. You can specify individual users or Azure AD security groups (not mail-enabled security groups).
• Permissions: Choose the set of users allowed to create new topics or update the details of AI-created topics such as the description, documents, and connected people (those who know about the topic). These people are the knowledge managers for the organization. They use the Topic management dashboard to review topics across the organization and perform actions such as creating and editing topics, plus confirm, reject, and view feedback on topics.
• Topic center: Define the name and URL for the SharePoint site to host the Viva Topics center.

The restriction on solely using Azure AD security groups to define people covered by the policy is odd. Most Microsoft 365 apps support Microsoft 365 groups and/or distribution lists for this purpose. In this case, the developers might be focusing exclusively on using groups as a security principal instead of simply using groups to define who can see topics or work with topics.

After a last check to make sure the settings are correct, go ahead and activate. This process creates the Topic center site and starts the scan of the nominated target sites to collect knowledge and form topics.

Changing Settings

If you need to change the settings such as adding new knowledge managers, tenant administrators or SharePoint administrators can do this through Topic Experiences under the Setup -> Services section of the Microsoft 365 admin center.

Moving on to Managing Topics

Once initiated, the AI generation process needs time to scan the set of sites identified as sources. Despite the massive amount of compute resources available within Microsoft 365, that process needs time to complete. When it does, you’ll have topics to work with, which is the topic of another article.

Microsoft Viva is a great example of combining different components drawn from across Microsoft 365 to create a new offering. Nice as it is, you still need to understand the fundamentals of managing Office 365 applications to work with new solutions. Keep updated with the only book to be refreshed with new information monthly by subscribing to the Office 365 for IT Pros eBook. We’re in the knowledge business too!

By now, everyone should be convinced that using basic authentication for connections to Exchange Online is a bad idea. Microsoft has been pushing to remove basic authentication for quite a while, with announcements at the Ignite 2019 conference setting the stage. At that time, Microsoft said they would remove support for:

• Exchange Web Services (EWS – following an earlier announcement in July 2019).
• Exchange ActiveSync (EAS).
• IMAP4.
• POP3.
• Remote PowerShell.

The logic for choosing these protocols is that they are the set most exploited by attackers. After clients replace basic authentication with modern authentication for connections, attackers have a lot less attack surface to target.

A Change in Plan

Microsoft’s original plan was to remove support for basic authentication using these protocols in October 2020. The Covid-19 pandemic interfered with the ability of many organizations to do the necessary preparation for the deprecation and in April 2020, Microsoft was forced to push the date out to mid-2021.

Now, Microsoft is changing its approach. The basic principles are:

• Expanding the set of protocols covered in the program.
• Disabling basic authentication when it’s not used.
• Leaving tenants who use basic authentication alone for the moment and giving 12 months’ notice for deprecation when the basic authentication removal program restarts.

Let’s dive into some detail.

Expanded Target Protocol Set

The set of protocols has increased to include:

• MAPI (Messaging Application Programming API): The API Exchange Server is built on.
• RPC (Remote Procedure Call). MAPI over RPC is known as Outlook Anywhere and uses basic authentication. MAPI over HTTP supports both basic or modern authentication.
• OAB (Offline Address Book).
• SMTP AUTH (see below).

Outlook desktop clients (Windows) already consume EWS to access information like free/busy data and MailTips. This change closes off potential vulnerabilities in Microsoft’s own client to align better with the work already done to support modern authentication IMAP4 and POP3 clients. There is no good reason for Outlook clients to connect to Exchange Online using anything but modern authentication. Microsoft is not including AutoDiscover in the protocol set. The logic here is that AutoDiscover only ever informs clients where to go to access user data; the protocol can never access user data, so it is of little use to attackers. Microsoft says that they will consider disabling basic authentication for AutoDiscover in the future, once the battle to eliminate basic authentication for the other protocols is won.

Use It or Lose It

Instead of a big-bang turn-off on a nominated date, Microsoft will disable basic authentication for protocols when tenants do not use this capability “to prevent potential misuse”. Microsoft notes that many organizations don’t realize what protocols are in active use, so they will measure the use of basic authentication within tenants and use that information to disable basic authentication for unused protocols. Tenants will receive a message center notification in the Microsoft 365 admin center 30 days before a protocol is blocked.

Extended Notice Before Blocks Descend

For an undefined period, basic authentication will not be disabled when it is in active use by tenants. Eventually, the period of tolerance for basic authentication will lapse and Microsoft will move into a more active closedown phase. However, Microsoft says they will provide at least 12 months’ notice to tenants before blocking basic authentication for protocols in active use.

SMTP AUTH

SMTP AUTH is the client submission protocol used by applications or devices to submit outbound email to Exchange for processing. Many PowerShell scripts use the Send-MailMessage cmdlet to send messages via SMTP AUTH. As noted in July 2020, Microsoft has already disabled SMTP AUTH for new tenants (don’t these folks send email via PowerShell?) and is now including SMTP AUTH in the overall program rather than handling it separately.

What Happens Next

If your organization uses the affected protocols, you need to build a plan to reduce and then remove the usage for basic authentication. This might involve client upgrades, software changes, and perhaps firmware upgrades to devices which connect to Exchange Online (notably to use SMTP AUTH). You’ll get a 12 month notice of deprecation when Microsoft restarts its basic authentication removal program.

If your organization doesn’t use the affected protocols, this fact will be picked up by Microsoft’s analysis and you’ll receive message center notifications to say that Microsoft is going to disable basic authentication for one or more protocols. Thirty days later, Microsoft will enforce the block. The potential exists that someone might overlook the notification, and in this case, Microsoft says that they are working on a self-service procedure to reenable protocols in the Microsoft 365 admin center. It’s a good idea to enable the integration between the message center and Planner to make sure you don’t miss important notifications.

In some respects, it’s sad that Microsoft has delayed removing basic authentication for vulnerable connection protocols. I suspect that the reason is rooted in analysis of telemetry from tenants around the world which concluded that implementing the block as planned in mid-2021 would be too disruptive. It’s easy to argue that Microsoft should plough ahead and make the change, but the consequences of blocking connections across many unprepared organizations might generate a severe interruption in service. Tenants would be less vulnerable to attack with the block in place, but stopping people from working is perhaps too big a price to pay for a general-purpose service.

Shifting dates like this is a great reminder of the value of a book with updated content to track developments. The Office 365 for IT Pros eBook covers updates so you don’t have to sweat.

Programmatic Access to Service Incidents

A reader asked if an easy way exists for programmatic access to information about Microsoft 365 incidents. To set context, several standard methods are available for tenant administrators to learn about an incident concerning a Microsoft 365 application. The Service Health dashboard in the Microsoft 365 admin center lists ongoing incidents and their status (Figure 1).

Incidents are also available through the Microsoft 365 admin mobile app (Figure 2). The app is available for iOS and Android.

Administrators can choose to receive notifications for incidents affecting their tenant in Outlook for Windows. Finally, nominated individuals can receive email about incidents (Figure 3) with the understanding that if problems can components which prevent email being sent. And sometimes email arrives to announce the end of an incident before you know that an incident happened. To configure the email addresses (up to 2) to receive notifications, access Preferences in the Service Health dashboard and choose the types of events and workloads you want to receive email about.

Microsoft targets communications about incidents to the affected tenants, but if you don’t want to rely on the standard methods, you can keep a close eye on Twitter accounts like Microsoft 365 status to get a heartbeat across the entire infrastructure.

ISV Monitoring

An alternative is to invest in third-party monitoring products, which usually deploy probes and other artificial transactions to establish what’s working well and where problems might be about to break. ISVs active in this space earn their bread by detecting problems before Microsoft makes formal announcements that an incident is active. They also concentrate on your organization and the workloads most important to your users.

DIY Service Monitoring

To return to the original question, programmatic access to the same information used by the Microsoft 365 admin center is available through the REST-based Office 365 Service Communications API. You can use this API to check for and display information about incidents in whatever interface you choose, such as a dashboard which includes Microsoft 365 and other services. The API supports access to historical status of incidents, current workload status, and messages, which include informational messages in addition to those about incidents.

Note: Microsoft will deprecate the Office 365 Service Communications API on December 17, 2021. You should transition your code to the Microsoft Graph Service Health and Communications API. See this article for details.

The basic approach used with Microsoft 365 REST-based APIs is followed (see this post for more information):

• Register an app with Azure AD. Note the app identifier and secret.
• Assign the permission to access service information to the app. This is the ServiceHealth.Read permission for the Office 365 Management APIs.
• Use the tenant identifier, app identifier, and app token to get an OAuth access token.
• Use the access token to authenticate the call to get service incidents.
• Parse and display the service incidents as required.

Here’s an example in PowerShell. At this point we assume that a suitable access token has been obtained and included in the $Headers variable. The commands retrieve the current messages and filter them for incidents with a status of “Service degradation.” We then loop through the incidents to find any with recent updates (within the last 30 minutes, as dictated by the $Minutes variable) and write out anything we find:

# Fetch information from Service Communications API
Write-Host "Fetching Microsoft 365 Message Center Notifications..."
$MessageCenterURI = "https://manage.office.com/api/v1.0/$($tenantid)/ServiceComms/Messages"
$ServiceData = (Invoke-RestMethod -Uri $MessageCenterURI -Headers $Headers -Method Get -ContentType "application/json") 
$ServiceData = $ServiceData.Value | ?{$_.MessageType -eq "Incident" -and $_.Status -eq "Service degradation"}

$Now = Get-Date
ForEach ($Incident in $ServiceData) {    
   $TimeSince = ($Now - ([datetime]$Incident.LastUpdatedTime)) 
   If ($TimeSince.TotalMinutes -le $Minutes) {  
      If ($Incident.EndTime -eq $Null) { $IncidentColor = "Red" }
      Else { $IncidentColor = "Yellow" } 
   $Title = "[" + $Incident.WorkloadDisplayName + "] " + $Incident.Title + " (" + $Incident.Severity + ")"
   Write-Host ""
   Write-Host "Microsoft 365 Incident" $Incident.Id
   Write-Host $Title -foregroundcolor $IncidentColor 
   Write-Host "Start time:       " (Get-Date $Incident.StartTime)
   Write-Host "Last Updated:     " (Get-Date $Incident.LastUpdatedTime)
   Write-Host "Current minutes:  " $TimeSince.TotalMinutes.ToString().Split(".")[0]
   Write-Host ""
   Write-Host "Incident Details"
   Write-Host "----------------"
   $Incident.Messages.MessageText
    } 
}

Figure 4 shows what the output looks like for an incident.

Obviously, there’s lots that you could do to refine and prettify the output to make it work the way you’d like it to look (here’s an example of how to post service incident information to a Teams channel). The same approach will work with any language which supports REST APIs.

Knowing the ins and outs of Office 365 administration includes understanding how to extend the basic functionality. We cover this kind of stuff in detail in the Office 365 for IT Pros eBook. Subscribe and stay up to date as things change.

The Enable-OrganizationCustomization Cmdlet

Apparently the Enable-OrganizationCustomization cmdlet for Exchange Online has been around for quite a while without me noticing it. Some say it’s been in the Exchange product code since the earliest days of Business Productivity Online Services (BPOS), the predecessor of Office 365. That’s a long time.

According to the documentation, “In the Microsoft datacenters, certain objects are consolidated to save space” and tenant administrators might be asked to run the cmdlet before they can add or modify certain configuration objects for Exchange Online.

In other words, new tenants use an out-of-the-box configuration for settings like role assignment policies, OWA mailbox policies, mailbox retention policies, and some Exchange Online Protection settings. Before these tenants can alter their configuration, the Enable-OrganizationCustomization must be run to move the tenant configuration to a customizable state. This can be done explicitly (an administrator runs the cmdlet) or implicitly (Exchange Online runs the cmdlet when an administrator changes a standard setting for the first time).

Hydrated Exchange Organizations

After running the cmdlet, the IsDehydrated setting in the organization configuration is set to False. This is a one-time operation and there’s no way to reset IsDehydrated.

In this context, a dehydrated tenant is one using the standard Exchange Online configuration settings while a hydrated tenant has a customized configuration. According to Microsoft, most tenants are in a dehydrated state, which is what you’d expect across the spectrum of Office 365 tenants where many are small tenants who never need (or want) to change anything.

Get-OrganizationConfig | Select isDehydrated

IsDehydrated
------------
       False

My tenant is heavily customized, but I have never run Enable-OrganizationCustomization. In fact, unless I missed it in passing, I have never run Enable-OrganizationCustomization in any tenant I have worked in, but people have told me that they have, such as when updating an OWA mailbox policy to allow users to access the Moca preview. Figure 1 shows what you see when EAC rehydrates tenant settings (the cmdlet is run to effect the change).

Avoiding Azure AD Bloat

Exchange Online uses standard settings whenever possible and only expands objects holding those settings when they are customized. Apparently, at the scale which Exchange Online runs, this approach makes a real difference for Azure Active Directory. If every Exchange Online stored every setting for every tenant, it would create significant directory bloat.

Outside directory bloat, the assertion that objects are consolidated to save space is less believable. The storage consumed by Exchange Online mailboxes and its use by the Microsoft 365 substrate to store data belonging to other applications is such that saving a few megabytes of configuration data per tenant would seem like a rounding error. Maybe the rounding error becomes more important when you’re dealing with 250,000 mailbox servers.

No Need for the Cmdlet

Doubtless Exchange Online gains some goodness from using standard configurations but I still don’t know why the cmdlet exists. It seems like an unnecessary barrier to tenants which could be removed if Exchange automatically upgraded a tenant to a hydrated state when the first customized configuration object was saved.

Teams also uses standard policies (and Teams has lots of policies). Microsoft manages the default versions of those policies. Organizations get their own copies if they change the default (global) policy for the tenant and the customized version takes precedence over Microsoft’s version. There’s no warning issued and the switch from default to custom objects is seamless.

Stopping Unnecessary Customizations

Since the introduction of PowerShell support in Exchange 2007, the customizability of the product has been one of its strengths. Tenants can still customize Exchange Online, albeit after running an annoying cmdlet to enter a hydrated state.

A cynic might say that putting a barrier in front of administrators might prevent some errors in configuration customizations which ultimately lead to support calls and increased costs for Microsoft. There doesn’t seem to be another good reason for the Enable-OrganizationCustomization cmdlet, especially as becomes a dead, useless cmdlet after it is run.

Using a centrally managed standard configuration for a complex application like Exchange Online is a good thing. Advising people to walk away slowly before making changes they might not understand is sensible. However, forcing the use of a cmdlet where a seamless background switch from dehydrated to hydrated state is possible is just over the top.

Learn more about Exchange Online in the Office 365 for IT Pros eBook.

Time to Move to a New EAC

Update April 22, 2021: Microsoft announced in MC252053 that the new EAC will reach general availability for standard and GCC tenants at the end of April while GCC High gets it at the end May and DoD in June.

Among the Exchange announcements made at the virtual Ignite 2020 conference was the assertion that the new Exchange admin center (EAC) is ready for prime time. Microsoft said: “We’ve recently reached parity with the legacy admin interface and are now adding new features such as personalized dashboards, cross tenant migration and providing actionable insights. We have also invested in a better mobile experience for admins on the go.”

I don’t buy the statement about parity in functionality because the new EAC links back to the old EAC for some functions, like management user role assignment policies. Understanding that these are marketing words and that the developers will close the gaps over time, let’s consider what the new EAC brings.

Anyone taking the invitation to opt-in from the old EAC or by going direct to the new EAC might be underwhelmed at first look. The home screen is under inspiring and the new console (Figure 1) is just another bland Microsoft 365 portal, even if it’s regained some functionality (like Mail Flow from the Security and Compliance Center), some new tricks (like administrator recovery of deleted items), and is the go-forward target for investment in new functionality.

The new EAC also inherits some smarts from the Microsoft 365 admin center, like how groups are processed, but there’s no magic present to convince you to set the toggle to default to the new portal (sometime in the future, the toggle will be disabled and using the new EAC will be the only choice).

PowerShell Created Portal Magic

I know you’re going to think me crazy that magic can exist in an administrative tools, but this has been the case in the two previous generations of Exchange administrative portals and it’s all to do with PowerShell.

When Microsoft came to design Exchange 2007, they took the brave decision to base all the administrative tools on PowerShell. EMC, the Exchange management console became a wrapper around PowerShell cmdlets, as did the later web-based Exchange Control Panel (ECP) and EAC. The great thing about this approach was that the consoles exposed the PowerShell code they used to perform actions through a feature called command logging. Figure 2 shows how the EMC displayed the code used to create a new mailbox. You could copy the code and reuse it in your own scripts.

Given that PowerShell was very new (Exchange was the first major Microsoft server to embrace PowerShell), this was a fantastic way for administrators to learn how to interact with Exchange and manage objects through PowerShell. In a nutshell, it was the best learning tool available at the time. I haven’t seen much to beat it since.

The unfortunate thing is that following the transition to Exchange Online, Microsoft proved adept at breaking PowerShell command logging. I’m sure this wasn’t deliberate; the developers probably didn’t put as much value on the feature as its fans did. And to be fair, fewer people needed to use command logging as experience of PowerShell grew and more information was available online.

The Graph is the Strategy

The truth is that the new EAC doesn’t use PowerShell. Like the other modern administrative consoles used across Microsoft 365, the new EAC is based on the Microsoft Graph. This is in line with Microsoft’s strategy to use the Graph whenever possible as the basis for Microsoft 365 management. It’s an understandable and reasonable approach to build everything on a common foundation, even if it loses some magic. And no, the new EAC never tells you anything about the Graph code it uses. Some secrets must be kept.

The folks who subscribe to the Office 365 for IT Pros eBook seem to know their way around PowerShell, so we have never covered command logging in depth. It’s sad to see it go, but we dedicate our pages to new stuff and not the past.

Microsoft 365 Audit Log is a Rich Source of Information About Workloads

The Microsoft 365 audit log (aka the unified audit log) is a rich source of information about what happens inside a tenant. Audit events generated by workloads go through an ingestion process to be added to the log to ensure that every event has a common set of fields like the date when the event occurred, the account responsible for the event, and the name of the event. In addition, a workload-specific payload of audit data is inserted into the AuditData property of events. This data varies from workload to workload. Interpreting the workload data is one of the challenges of dealing with the audit log that quickly becomes second nature (when you’ve done it often enough).

You can search the Microsoft 365 audit log using the Audit facility in the Microsoft Purview Compliance portal (Figure 1). This is acceptable when you’re looking for a specific event, but if you need to cast a wider net to look for events that might lead you to an answer, it’s easier and faster to do the job with PowerShell.

Who Did What or What Happened?

Most auditing queries are run to answer “who did what” questions. In other words, you want to know who performed a specific action. For instance, who deleted a document, created a group, recorded a Teams meeting, or sent a message from a shared mailbox. Chapter 21 of the Office 365 for IT Pros eBook contains many practical examples of parsing audit data from multiple workloads to answer who did what questions.

Sometimes you need to know what happened to a particular object, like a document or a user. Finding audit events for one or more documents is easy – all you need to do is pass the document names in the ObjectIds parameter. In this example, we create an array of document names to search for and then pass the array as the ObjectIds parameter for the call to Search-UnifiedAuditLog:

[array]$docs = "New Signature API for Email Signatures.docx", "Controlling default creation of online meetings with OWA.docx", "Anticipating Microsoft Ignite 2020.docx"
$Records = Search-UnifiedAuditLog -ObjectIds $docs -StartDate 1-Sep-2020 -EndDate 1-Oct-2020 -ResultSize 500

The events found are for all actions performed against the documents, such as being modified or downloaded. The same technique works for users:

[array]$Users = "Oisin.Johnston@office365itpros.com", "Kim.Akers@office365itpros.com"
$Records = Search-UnifiedAuditLog -ObjectIds $Users -StartDate 1-Sep-2020 -EndDate 1-Oct-2020

This search returns events for actions performed for these users (like being added to a group membership) rather than events performed by the users.

Actions Performed Against a Microsoft 365 Group

Microsoft 365 Groups are not users, so if we want to find the actions performed against a group, we must use the FreeText parameter to search audit records for instances of unique values that identify the group we’re interested in. Fortunately, the object identifier for a group is a good search term. In this example, we extract the object identifier for a Microsoft 365 group and use it to search for audit events. We then group the audit events to get an overview of the kind of activity performed against our target:

$ObjectId = Get-UnifiedGroup -Identity "Office 365 for IT Pros" | Select -ExpandProperty ExternalDirectoryObjectId
[array]$Records = Search-UnifiedAuditLog -FreeText $ObjectId -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date).AddDays(+1) -ResultSize 1000 -SessionCommand ReturnLargeSet

$Records | Group Operations | Sort Count -Descending | Format-Table Name, Count

Name                      Count
----                      -----
RecipientChange              17
TabUpdated                   10
TabAdded                      4
Remove member from group.     3
MemberRemoved                 3
Add member to group.          3
Update group.                 2
MemberAdded                   2
TabRemoved                    1
Set-UnifiedGroup              1
PutPermissions                1
Assign label to group.        1
StreamInvokeVideoSetLink      1

The technique also works for finding audit records for security groups (but not for distribution lists). It also works for Azure AD accounts, including guest users, but it’s much slower than using the ObjectIds parameter. As the name implies, FreeText means that a free text search is used to find matching audit events. In a large tenant, a free text search across potentially millions of records won’t be fast.

Remember that a single action can result in multiple events. For instance, if you add someone to a group, the MemberAdded and Add member to group events are captured by different workloads and ingested into the audit log. The duplication is easily detected by comparing the creation date for the events.

Mine the Audit Log

Every Office 365 administrator should know how to mine the Microsoft 365 audit log to answer questions about their tenant. It’s not hard and you’ll understand a lot more about how Office 365 works once you spend time deep in audit data. That doesn’t sound fun, but it’s better than it seems.