Copilot Branding Applied Liberally Across All Product Announcements at Ignite 2024

I decided to stay away from the Ignite 2024 conference in Chicago this week. The monetary investment to fly to Chicago, stay in a hotel, meals, lost time, and the conference fee outweighed the potential return. I would have liked to meet up with people, but the cost to attend what’s essentially a marketing event was way too high.

What’s clear from the announcements made at Ignite is that Microsoft is heavily focused at recouping the massive investments they’ve made to build out the datacenter infrastructure to deliver artificial intelligence functionality. That’s understandable in light of quarterly investments of around $20 billion in hardware, software, and datacenter fabric. Another factor is the need to extract more revenue from the Microsoft 365 installed base to offset a slowing in the growth of overall user numbers.

A Slew of AI Announcements at Ignite 2024

The net result is a slew of announcements for AI-infused functionality helpfully captured in the Ignite 2024 “Book of News.” The online document mentions Copilot 259 times and AI 278 times, which is a clear statement of where Microsoft’s PR priorities lie.

The announcements range from general availability for features that are already shipping (like Agents in SharePoint Online) to some very interesting developments for Teams, like the ability for Copilot in Teams to analyze information shared on-screen during meetings. Another thing that seized my attention was how Copilot can schedule focus time or 1:1 meetings similar to the way that the now-defunct Cortana Scheduler attempted to help users select optimum meeting slots. The ability to have live translation for multilingual meetings (rather than just from a single language into other languages) should also be popular in multinational organizations.

A welcome development is the introduction of detection of prompt injection in Purview Communication Compliance. After researchers at Black Hat 2024 described some vulnerabilities in Microsoft 365 Copilot Chat, including prompt manipulation, Microsoft said that they had addressed the issue without giving details. Now, Communication Compliance will detect and report attempts to inject prompts to “elicit unauthorized behavior from the large language model (LLM).”

Restricting Access to Information

On the tenant administrative side, the work to help organizations restrict the ability of Microsoft 365 Copilot to process documents continues. For example, a new DLP rule condition based on the sensitivity label assigned to documents can prevent Copilot summarizing information from documents or using content from documents in its responses. On the downside, it’s unbelievable that Microsoft can justify calling one new rule condition “Microsoft Purview Data Loss Prevention for Microsoft 365 Copilot.”

At a broader scale, Restricted Content Discoverability (RCD) will stop Copilot accessing documents in sites on a deny list. RCD is a more sensible and scalable approach than the 100-curated site allow list implemented in Restricted SharePoint Search.

I was pleased to hear that Microsoft plans to make SharePoint Advanced Management (SAM) licenses available to tenants with Microsoft 365 Copilot. I called for this to happen in an October 3 post. It didn’t make sense to ask customers to pay the $3/user/month fee for SAM to control aspects of Microsoft 365 Copilot that they pay $30/user/month for. Apparently, the roll-out of SAM licenses to eligible tenants will happen in early 2025.

Also in SharePoint Online, a new sensitivity label option will extend SharePoint site permissions to downloaded documents. The new configuration handles situations like when a user loses access to a site, or a file is deleted from a site. In these situations, the sensitivity label will recognize that the situation for a document has changed and block access. To implement the protection, you’ll need both an E5 license (to set a default sensitivity label for the site) and a SAM license.

Conditional Access for Generative AI

Not to be outdone by announcements by other development groups, the Entra ID team released details of Protect AI with a Conditional Access Policy, which is all about limiting access to AI services like Microsoft 365 Copilot and Security Copilot through conditional access policies.

To make the block work, Microsoft asks tenants to create two service principals to represent the Enterprise Copilot Platform and Security Copilot apps. The service principals represent the instantiation of the apps used by Copilot within a tenant and allow conditional access policies to monitor connections to the apps (read this article to discover more about sign-in activity for service principals). Conditional access policies can apply restrictions to app connections like enforcing multifactor authentication (MFA) or a certain type of strength for multifactor authentication, like requiring the use of a FIDO2 key.

I created a conditional access policy to require MFA for Copilot. It works, but the user experience isn’t great. For instance, Figure 1 shows what the user sees when an account that doesn’t use MFA attempts to connect to Microsoft Copilot.

It seems like the user-facing experience doesn’t cope well with the error that results when the browser attempts to connect to the Enterprise Copilot Platform app. No doubt the chat client will get an update to resolve the problem.

Great Technology Revealed at Ignite 2024, But Someone’s Got to Pay

It’s great that Microsoft continues to push the boundaries of how AI can help Microsoft 365 tenants. However, we shouldn’t lose sight of the fact that Microsoft 365 Copilot is not ass widely used within the 400-million plus installed base of Office 365 paid seats. It’s definitely in Microsoft’s interest to convince more of that installed base to buy Copilot, but it would be nice if every new feature that arrives didn’t come with the requirement for a new license, license upgrade, or add-on.

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.

Sensitivity Label Downgrades and Removals Could be Potentially Suspicious User Behavior

The publication of message center notification MC934733 on November 15, 2024 (Microsoft 365 roadmap item 466742) provoked some thought. The notification is about an update to Purview Insider Risk Management, a compliance solution to detect activities that might potentially expose the organization to risks like IP theft or data leakage. The solution is part of Microsoft’s E5 Compliance Suite and is also included in Office 365 E5/Microsoft 365 E5.

In this case, the update covers the detection of risk that might be indicated if people downgrade or remove sensitivity labels from files stored in SharePoint Online sites. This kind of behavior could indicate that a user is preparing to exfiltrate files from the organization, perhaps when they leave in the near future.

By removing sensitivity labels from files, they remove the block that Microsoft Information Protection would otherwise place on people who cannot prove their right to access the files. Normally, proof is secured by authentication, which is then compared against the set of rights defined for a file. Downgrading a label can have the same effect if the chosen label allows free access to files through a right like “any authenticated user.”

The ability to remove or change a sensitivity label for a file is governed by the rights assigned to a user in a label. If the user can edit the rights for a file, they can change or remove a sensitivity label. This right is included in the co-author role that is sometimes assigned to everyone in the organization or everyone in a group.

Use the Audit Log to Track Sensitivity Label Downgrades and Removals

This kind of check is very useful, but it might not be enough for an organization to invest in license add-ons or upgrades. If your tenant has Purview Audit Standard (check this PDF for product licensing information), then you can use PowerShell to analyze the events captured in the unified audit log to track and report sensitivity label downgrades and removals.

The idea is simple. Here’s what has to happen in a script.

• Connect to Exchange Online.
• Connect to the compliance endpoint.
• Run the Get-Label cmdlet to fetch details of the sensitivity labels used with files and store them in a hash table. In fact, two hash tables are used for fast lookup. One resolves label identifiers to return label display names. The other resolves label identifiers to return the label priorities. Each label has a priority number from 0 (least sensitive) up. By comparing the priority numbers when a label update occurs, you know if the update is a downgrade or an upgrade.
• Run the Search-UnifiedAuditLog cmdlet to look for FileSensitivityLabelRemoved and FileSensitivityLabelChanged events over whatever lookback period seems appropriate. See this article for more information about reporting sensitivity label events.
• Process each event to decide what happened and capture details in a PowerShell list.
• Do some analysis to figure out if an abnormal number of label downgrades or removals have happened and which accounts are involved.
• Report the details.

I put together a script to illustrate the principles involved in finding and analyzing the audit event information. You can download the script from GitHub. Figure 1 shows the results reported by the script when I ran it in my tenant. Clearly, the tenant administrators only have to worry about me…

Container Management Labels Are Changed Too

The sensitivity labels discussed so far are information protection labels that can apply rights management encryption to protect files. The other type are container management labels, which are used to apply settings to “containers” (teams, sites, and groups). Unhappily, just like someone can change a sensitivity label for a file, a container owner can change the assigned container management label. There’s no way for an organization to lock a label for a container.

However, you can monitor container label changes using the audit log using audit events and reapply the original label if a change is detected. The original article uses Exchange Online management PowerShell, and it’s also possible to monitor container management changes with the Graph APIs, albeit in a more complicated arrangement because of the need to store original label assignments for containers in a Graph-accessible location.

Detecting Sensitivity Label Downgrades Proves the Value of the Audit Log

Being able to track sensitivity label changes and removals for files is another example of how audit log information can prove useful for tenant administration. If you know what’s happening inside a tenant, there’s probably an audit log event captured for the action, and once you can find the audit log event, you can analyze it.

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

Exchange Online Security Updates Focus on EWS, Public Folders, Mail Transport, and More

On November 18, as interest in the Microsoft community turned to the marketing fest at the Ignite conference in Chicago, Microsoft released an interesting technical community post covering security updates for Exchange Online. Given the fundamental role that email plays within Microsoft 365, this is a topic that every tenant needs to pay attention to.

Many of the items listed are restatements of previous news, like the February 2025 deprecation of the App Impersonation RBAC role (I covered this point as a footnote in yesterday’s article). Basically, this is a role that allows Exchange Web Services (EWS) apps to access mailboxes. Microsoft wants to remove the role because it can be a vector to potential mailbox compromise. The problem is that tenants might be unaware that the role is used by an app or script. Microsoft has a PowerShell script to locate accounts that hold the role. It’s worth running the script, just in case.

It’s worth noting that equivalent Graph permissions are available to access content in user mailboxes. Microsoft answer is that tenants should use RBAC for Applications to restrict app access to the set of mailboxes that need to be processed. I agree.

Microsoft restated the plan to remove EWS from Exchange Online in October 2026, noting that the change will break any app based on EWS. Originally, Microsoft originally planned to implement an exception to allow their own EWS-based apps to continue running, but now they say that they’ll phase out EWS well before October 2026.

Gaps in Graph Coverage for EWS Functionality

More interestingly, Microsoft points to known gaps where Microsoft Graph APIs are not capable of taking over from EWS today. They say that they are working to support access to archive mailboxes, but don’t have a delivery date. I imagine that the Exchange admin center will need this API to perform tasks like enabling archives, reporting archive mailbox size, and so on.

Microsoft also noted that they will soon release Graph support for Application settings for Exchange client applications to cover user configuration and folder associated information (FAI). User configurations and FAIs are stored in mailboxes and used to hold settings needed by applications. I imagine that this work involved an extension of the current Graph support for mail items.

The big news in the announcement is that Microsoft says that they cannot deliver Graph support for “several admin features that are available to developers via EWS,” such as setting folder permissions or managing delegates for user mailboxes. Once EWS is deprecated, developers who implement these features in their apps will have to find a different way, perhaps by calling PowerShell using Azure functions.

Exchange Online Management – After much investigation, we have concluded we are unable to provide Graph API access to several admin features that are available to developers via EWS. Once Microsoft removes EWS from Exchange Online, to perform tasks such as setting folder permissions or managing delegates for a user, you will need to call PowerShell in code or use alternative ways to deliver this functionality.

The Final Demise of Public Folders

In addition, Microsoft says that they will no longer provide APIs to programmatically manage public folders after the removal of EWS in October 2026. I assume Microsoft thinks it’s simply not worthwhile to recreate public APIs for public folders because of low usage. Public folders were hot technology when Exchange 4.0 appeared in 1996 and have been on a downhill slope ever since. Despite suitable efforts to eradicate public folders over many years, use persists in a small number of Exchange Online tenants. Microsoft will continue to provide access via “supported” Outlook clients and for bulk import/export.

I presume that the new Outlook for Windows will support public folders. An option is available to add one or more public folders to Outlook favorites but the button to actually add the folder is missing. Maybe Copilot for Outlook didn’t like it. No doubt the button will show up before Microsoft removes for support for Outlook classic sometime after 2029.

I’m not sure if tenants will take the news as a broad hint that they should get off public folders (they should). It’s just sad that the tools to analyze the data in public folders and move what needs to be kept to a more modern alternative are so weak.

Exchange Online Security Updates in Mail Transport

Rounding out the post, Microsoft covers a bunch of recent improvements around DNSSEC and DANE. The news is that Mandatory Outbound SMTP DANE is coming in May 2025 with per-tenant and per-domain settings. Microsoft didn’t cover other efforts to increase the security of the Exchange Online email service, like the introduction of the external recipient rate limit (due on January 1, 2025) or the continuing effort to force hybrid tenants to upgrade on-premises servers to a supported version before email can flow across a connector to Exchange Online.

Finally, Microsoft notes that they recently added OAuth support to the preview of the High Volume Email feature (HVE). This summer, I spent some time working with HVE and ECS, the Azure Email Communication service. Both can do a job for tenants that needs to send bulk email, with HVE a better option for internal-focused email and ECS more suitable for outbound communications. You can read more, including sample PowerShell to send email via HVE and ECS, on Practical365.com.

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.

Mandatory MFA for Microsoft 365 Admin Center Connections from February 3, 2025

After their communications triumph around the announcement of the imposition of an MFA requirement to sign into Azure administrative endpoints like the Entra admin center earlier this year, Microsoft is moving to its next target. According to a Microsoft Technical Community post of November 11, 2024, they will roll out the requirement for connections to the Microsoft 365 admin center to pass a mandatory multifactor challenge beginning on February 3, 2025.

Rolling out a change like this to hundreds of thousands of Microsoft 365 tenants can’t be done overnight. Microsoft says that tenant administrators will receive notification 30 days before the restriction commences.

The last time round, people panicked when they assumed that all connections to Azure, including those from non-privileged user accounts, would need to use MFA. However, the set of affected endpoints featured sites that few “normal users” go near simply because they have no need to connect to administrative portals like the Intune admin center or PowerShell modules like Azure.

The same rules apply here. Only accounts holding administrative roles that need to connect to the Microsoft 365 admin center are affected. There’s probably a broader set of roles involved, and the new restriction means that staff like help desk personnel might be required to use MFA for the first time. But here’s the thing: anyone accessing the Microsoft 365 admin center to perform administrative tasks for a tenant should already be using MFA. Those who don’t are inviting compromise of their accounts by attackers that leads to potential compromise of the entire tenant depending on the roles held by the account.

Figuring Out Who Might be Affected by the Mandatory MFA Requirement

If you have Entra P1 licenses, you can use PowerShell to analyze Entra Audit sign-in logs to determine the set of accounts that use MFA. Audit logs only go back 30 days, but it’s enough to have a good idea. Alternatively, you could use PowerShell to interrogate the sign-in logs to find successful connections to the app used by the Microsoft 365 admin center (the app name reveals its roots), reduce the set to find unique user accounts, and check each user account to validate if it uses MFA. In this example, I use the Get-MgServicePrincipal cmdlet to find the identifier of the app. You could also scan the sign-in logs in the Entra admin center to find a record for a connection to the Microsoft 365 admin center. The beta version of the Get-MgAuditLogSignIn cmdlet is used to fetch sign-in records because it returns information about authentication requirements. Here’s some code to do the job (available from GitHub):

Connect-MgGraph -Scope AuditLogs.Read.All
$M365AdminCenterId = (Get-MgServicePrincipal -Filter "displayName eq 'Microsoft Office 365 Portal'").AppId
Write-Host "Checking for sign-ins to the Microsoft 365 Admin center..."
[array]$M365PortalSignIns = Get-MgBetaAuditLogSignIn -Filter "AppId eq '$M365AdminCenterId' and status/ErrorCode eq 0" -All -PageSize 500
[array]$UniqueUsers = $M365PortalSignIns | Sort-Object UserPrincipalName -Unique
$Report = [System.Collections.Generic.List[Object]]::new()

ForEach ($User in $UniqueUsers) {
    $MFA = "Not enabled"
    If ($User.authenticationRequirement -eq 'multifactorauthentication') {
        $MFA = "Enabled"
    }
    $ReportLine = [PSCustomObject] @{ 
        User                = $User.UserDisplayName
        'MFA Status'        = $MFA
        'Last sign-in'      = $User.createdDateTime
    }
    $Report.Add($ReportLine)
}

$Report

User                                    MFA Status  Last sign-in
----                                    ----------  ------------
Hans Geering (Project Management)       Enabled     09/11/2024 20:50:47
Ken Bowers                              Enabled     16/11/2024 13:20:40
Lotte Vetler (Paris)                    Enabled     15/11/2024 13:23:06
Paul Robichaux (Office 365 for IT Pros) Not enabled 29/10/2024 19:46:04
Tony Redmond                            Enabled     03/11/2024 15:30:24

Another approach is in the user passwords and authentication report script, which generates a comprehensive report about user accounts, passwords, sign-ins, and registered MFA methods. You can check this report to make sure that the users detected using the Microsoft 365 admin center have suitable MFA methods registered.

Another helpful script generates a report about accounts holding administrative role assignments. You can use the information in the report (and the CSV file generated by the script) to focus on the accounts that will be affected by the new mandatory MFA requirement. For example, accounts holding the user administrator role (Figure 1) will need to satisfy the mandatory MFA requirement to connect to the Microsoft 365 admin center after Microsoft deploys the change to your tenant.

Essentially, PowerShell is your friend when it comes to finding out who uses MFA in a tenant.

The Ongoing Need to Accelerate the Adoption of MFA

According to a Microsoft research report, MFA reduces the risk of account compromise by 99.22% across all accounts and by 98.56% for leaked account credentials (usernames and passwords). The last figures shared by Microsoft said that only 38% of Entra ID monthly active users use MFA (February 2024). Microsoft is on a campaign to get that number to at least 80% and enforcing mandatory requirements for MFA to connect to different sites is a good way to drive that message home.

One thing’s for sure. Microsoft is not going to stop imposing mandatory MFA requirements to connect to Microsoft 365. I expect the campaign to continue and spread to user-focused applications like Teams and Outlook. Quite when that will happen is anyone’s guess, but the important thing is to get ahead of the game by accelerating the adoption of MFA to protect Microsoft 365 user accounts, preferably using strong authentication methods like the Microsoft Authenticator app, FIDO2 keys, or software passkeys.

Another Big Change Coming in February 2025

Another big thing that will happen in February 2025 is the deprecation of the ApplicationImpersonation role in Exchange Online. This might not seem important to you, but it might be. Many bespoke and third-party tools use this role with Exchange Web Services (EWS) to access mailboxes. If you don’t check now, you might have an unpleasant surprise early in 2025. The Microsoft post references some tools to help check a tenant. It’s worth taking the time to do so.

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.

Add Eligible and Active PIM Role Assignment Requests

I recently wrote about Microsoft’s recommendation to use the UnifiedRoleDefinition Graph API instead of the older DirectoryRole API. In that article, I show how to use the Microsoft Graph PowerShell SDK to make role assignments to user accounts. Assignments made in this manner are effective immediately. The assignments are permanent and last until an administrator removes them from accounts.

In many Microsoft 365 tenants where a limited set of administrators run operations, permanent role assignments work well. However, in larger tenants, some additional control is often desirable. Microsoft’s answer is Entra ID Privileged Identity Management (PIM), designed to enable administrators “manage, control, and monitor access to important resources in your organization.” PIM assignments can be permanent, but more commonly the assignments are time-limited to allow administrators to perform tasks on a just-in-time basis without their account needing elevated permissions on an ongoing basis. PIM is not part of the basic Entra ID license granted with Microsoft 365 and administrators need a license like Entra ID P2 to use PIM. See this page for more licensing information.

Microsoft’s Recommendation to use Entra Admin Center to Manage PIM Role Assignments

The PIM overview contains the interesting recommendation that tenants should use “PIM to manage active role assignments over using the unifiedRoleAssignment or the directoryRole resource types to manage them directly.” In other words, Microsoft thinks it better to use the GUI built into the Entra admin center to create and manage PIM role assignments. The reason for this might be that the GUI includes guardrails to stop administrators from making mistakes, which is something to avoid when assigning privileged roles.

In any case, PIM organizes role assignments into two categories:

• Eligible assignments are roles granted to users, groups, or service principals (apps) that are not active. These assignments must be activated by the holder (principal) before they can perform the privileged tasks enabled by the role. By default, eligible assignments are activated for a maximum of 8 hours, after which the activation can be extended or renewed.
• Active assignments are roles that are currently available for use. An active assignment can be permanent, but more often in PIM it is time-limited.

Both categories have a schedule, and Graph APIs and SDK cmdlets are available to add requests to add, update, and remove assignments from the schedules.

Creating an Eligible PIM Role Assignment

Here’s the PowerShell code to create a new eligible assignment schedule request to add a user account to the User administrator role. Before the New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest cmdlet can run, a certain amount of setup is necessary to fetch the identifiers for the account and role and define the period during which the assignment is eligible. You also need to decide whether the assignment is for the entire directory or an administrative unit.

$User = Get-MgUser -UserId Lotte.Vetler@office365itpros.com
[array]$DirectoryRoles = Get-MgRoleManagementDirectoryRoleDefinition | Sort-Object DisplayName
$UserAdminRoleId = $DirectoryRoles | Where-Object {$_.DisplayName -eq "User administrator"} | Select-Object -ExpandProperty Id
[string]$StartAssignmentDate = Get-Date -format "yyyy-MM-ddTHH:mm:ssZ"
[string]$EndAssignmentDate = (Get-Date).AddDays(30).ToString("yyyy-MM-ddTHH:mm:ssZ")

$ScheduleInfo = @{}
$ScheduleInfo.Add("startDateTime", $StartAssignmentDate)

$ExpirationInfo = @{}
$ExpirationInfo.Add("type", "afterDateTime")
$ExpirationInfo.Add("endDateTime", $EndAssignmentDate)

$ScheduleInfo.Add("expiration", $ExpirationInfo)

$AssignmentParameters = @{}
$AssignmentParameters.Add("action", "adminAssign")
$AssignmentParameters.Add("justification", "Assign User administrator role to user")
$AssignmentParameters.Add("roleDefinitionId", $UserAdminRoleId)
$AssignmentParameters.Add("directoryScopeId", "/")
$AssignmentParameters.Add("principalId", $User.Id)
$AssignmentParameters.Add("scheduleInfo", $ScheduleInfo)

$Status = New-MgRoleManagementDirectoryRoleEligibilityScheduleRequest -BodyParameter $AssignmentParameters
If ($Status.Id) {
   Write-Host ("Assignment for user administrator role for {0} added to eligibility schedule" -f $User.displayName)
}

The values in the hash table holding the parameters for the new assignment looks like this:

$AssignmentParameters

Name                           Value
----                           -----
justification                  Assign User administrator role to user
scheduleInfo                   {[startDateTime, 2024-11-12T17:51:03Z], [expiration, System.Collections.Hashtable]}
directoryScopeId               /
roleDefinitionId               fe930be7-5e62-47db-91af-98c3a49a38b1
principalId                    ce0e26f8-da88-4efa-90ad-d16df1d9500d
action                         adminAssign

The result of a successful assignment as seen in the Entra admin center looks like the example shown in Figure 1.

The assigned user receives email about the assignment and can use the link in the message to activate their assignment (Figure 2). See this article about approval workflows that you might like to use to control activations.

Accounts holding the Privileged Role Administrator or Global Administrator role also receive email to inform them about the new assignment.

Creating an Active PIM Role Assignment

The code to create a PIM active role assignment request is like that used for the PIM eligible role assignment request. In this example, we create an active role assignment schedule request for the Groups administrator role and limit the assignment to a six hour period from now. The duration is expressed in ISO8601 duration format, so PT6H means six hours.

$GroupsAdminRoleId = $DirectoryRoles | Where-Object {$_.DisplayName -eq "Groups administrator"} | Select-Object -ExpandProperty Id
[string]$StartAssignmentDate = Get-Date -format "yyyy-MM-ddTHH:mm:ssZ"
$ScheduleInfo = @{}
$ScheduleInfo.Add("startDateTime", $StartAssignmentDate)

$ExpirationInfo = @{}
$ExpirationInfo.Add("type", "afterDuration")
$ExpirationInfo.Add("duration","PT6H")

$ScheduleInfo.Add("expiration", $ExpirationInfo)

$AssignmentParameters = @{}
$AssignmentParameters.Add("action", "adminAssign")
$AssignmentParameters.Add("justification", "Assign Groups administrator role to user")
$AssignmentParameters.Add("roleDefinitionId", $GroupsAdminRoleId)
$AssignmentParameters.Add("directoryScopeId", "/")
$AssignmentParameters.Add("principalId", $User.Id)
$AssignmentParameters.Add("scheduleInfo", $ScheduleInfo)
$Status = New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $AssignmentParameters
If ($Status.Id) {
   Write-Host ("Assignment for Groups administrator role for {0} added to active schedule" -f $User.displayName)
}

To remove a role assignment from a schedule, create another role assignment schedule request and state the action to be “adminRemove” rather than “adminAssign.” For example, the request to remove the assignment request created above is:

$AssignmentParameters = @{}
$AssignmentParameters.Add("action", "adminRemove")
$AssignmentParameters.Add("justification", "Remove Groups administrator role to user")
$AssignmentParameters.Add("roleDefinitionId", $GroupsAdminRoleId)
$AssignmentParameters.Add("directoryScopeId", "/")
$AssignmentParameters.Add("principalId", $User.Id)
$Status = New-MgRoleManagementDirectoryRoleAssignmentScheduleRequest -BodyParameter $AssignmentParameters#
If ($Status.Status -eq "Revoked") { Write-Host "Active assignment revoked" }

Required Permissions for PIM

Adding role assignments requires the RoleManagement.ReadWrite.Directory permission. If you’re only reading role information, the RoleManagement.Read.Directory permission is sufficient. In addition, when using delegated permissions, read operations are only possible when the signed-in account holds one of the Global Reader, Security Operator, Security Reader, Security Administrator, or Privileged Role Administrator roles. Write operations, like adding a new role assignment to a schedule, require the signed-in account to hold the Privileged Role Administrator (or Global administrator) role.

Most Will Use the Entra Admin Center

Although it’s straightforward to create and manage PIM role assignment schedule requests with PowerShell, it’s easier to use the Entra admin center. Microsoft has done the work to create and refine the GUI and create the necessary checks to make sure that administrators don’t do something silly. I suspect that most administrators will interact with PIM through the Entra admin center, but it’s nice to know that the option to automate with PowerShell exists too.

Need more advice about how to write PowerShell for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

Trimming Unwanted Versions Stopped by Retention Policies and Labels

Last month, I wrote about the introduction of Intelligent Versioning for SharePoint Online. I think this is a great feature because its automated management of versions created during editing sessions reduces the storage quota consumed to store file versions. The advent of AutoSave for Office increased the number of versions created for files, and keeping 500 or so versions for a file, when some versions only include minimal changes, is effective but expensive.

Microsoft allows tenants a default storage quota for SharePoint Online that’s consumed by items stored in sites and Loop workspaces (containers). If a tenant exceeds their SharePoint storage quota, they must buy more from Microsoft or use Microsoft 365 Archive to move the storage consumed by inactive sites to cheaper “cold” storage.

As I noted in the article, the big issue with the current implementation of intelligent versioning is that it doesn’t work with Purview Data Lifecycle management, aka Microsoft 365 retention policies. If SharePoint Online sites come within the scope of a retention policy or individual documents have retention labels, then the requirement to retain information about files trumps the desire of intelligent versioning to remove unwanted versions for those files.

Checking Expired Versions Trimmed by Intelligent Versioning

Microsoft’s documentation explains how retention works with document versioning. I decided to check out what happens when versions expire for documents in a site with a retention policy in force. On November 6, I noted that several versions were in an expired state (Figure 1).

The next day, the expired versions were gone from the list. In one respect, this is what you might expect to happen. A background SharePoint Online job detected the existence of expired versions and removed them, which is what intelligent versioning is all about (the process is called trimming).

But the retention policy applied to the site set a five-year retention period and the document had a retention label with a ten-year retention period. The document is a source file for the Office 365 for IT Pros eBook, and you can never be too careful with source material. The longest retention period wins, so SharePoint Online should retain the file for ten years. However, no trace could be found of the removed versions.

Microsoft’s documentation says that versions for items subject to a retention hold are not automatically purged. In addition, users cannot delete versions from the Version history. When intelligent versioning trims versions in a site without retention policies, the files bypass the recycle bin. This didn’t apply, so it seemed like the site preservation hold library is the logical place to look. However, nothing was found in the preservation hold library except the copy of the file containing all versions prior to the implementation of intelligent versioning in the tenant.

Reappearing Versions

Then the removed versions reappeared in the version history complete with a new expiration date (Figure 2). Interestingly, SharePoint Online adjusted the expiration date for some other versions to make sure that full coverage of changes to the file is available.

After chatting with Microsoft engineering, I understand that the observed behavior is quite normal. The expired versions are removed by a background job, only for retention processing to detect that the removed versions are still within their retention period. This causes SharePoint to add a week to the previous expiration date for each version and make the versions available again. The cycle then repeats until the retention period for removed versions lapses to allow SharePoint Online to permanently remove the unwanted versions from its store.

More Intelligence in the Future?

It’s unfortunate that a clash exists between storage management and retention. Microsoft’s current approach is probably the best that can be done for now. I’m sure that they have an eye on the potential to extend intelligent versioning to interact with retention processing better. One possibility is to allow organizations to decide if selective version trimming is permissible, perhaps at a less aggressive level. For instance, it’s OK to remove versions that only contain formatting changes but not OK to remove any that contain text additions or deletions. Perhaps some storage savings are possible without compromising retention. It’s a hard nut to crack.

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.