Table of Contents
Group Members Become the Target Set for the Adaptive Scope
Adaptive scopes are queries executed against Entra ID to find users, Microsoft 365 groups, or SharePoint sites for processing. Like dynamic groups, the idea behind adaptive scopes is that if the directory is accurate, policies like Microsoft 365 retention policies will always process the correct target set of locations without requiring administrator intervention as people, groups, and sites join or leave the organization. Adaptive scopes require Office 365 E5 or advanced compliance licenses.
All of this is well-known information. Adaptive scopes have been around since late 2021, and people have figured out by now if they want to use adaptive scopes with users and groups or SharePoint Online, with or without the extra layer of complexity that using adaptive scopes alongside administrative units can introduce.
Creating a User Adaptive Scope Based on Group Membership
Then I was asked if it was possible to create an adaptive scope based on the membership of a group. Out-of-the-box, this isn’t a supported scenario. Adaptive scopes to target user resources like mailboxes and OneDrive accounts are quite different to those targeting Microsoft 365 groups, and the query builder for a user adaptive scope doesn’t include member of a group as an option.
The logic for having a group involved is the desire to use the group for communication, either as a plain distribution group for email-based communication or a team for channel-based discussion and to control access to other resources like a SharePoint site. It makes sense to align the retention policies applied to all members of such a group, especially if the accounts share a common geography or job type.
Where there’s a will, there’s often a way. In this case, the solution is to base both the group membership and the adaptive scope on a common attribute. The best option for such an attribute is likely to be one of the fifteen custom attributes available for Entra ID accounts. The custom attributes are supported as a queryable property by dynamic distribution lists, dynamic Microsoft 365 groups, and adaptive scopes.
Populating User Accounts
To illustrate the concept, I found a custom attribute that wasn’t in use. This can be difficult because organizations use custom attributes for many different purposes and all the attributes might already be in use. If this is the case, then another common attribute is needed. For instance, the attribute could be department, office, or job title.
To populate the attribute, I found the set of target mailboxes and updated them with Set-Mailbox. For example:
Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {Office -eq "New York"} | Set-Mailbox -CustomAttribute11 "Permanent Employee"
Create a Dynamic Microsoft 365 Group
Next, I created a Microsoft 365 group and used the same attribute (and same value) in the membership rule (Figure 1):
Finally, I created an adaptive scope which again checks the same attribute for the same value. Microsoft says that it can take five days for a background process to evaluate the query to find the set of target accounts. That was certainly true in the early days of adaptive scopes, but the day is more like a day now. After the background process to run the query, the set of target users is visible in the Purview portal (Figure 2).
Everything works and we have an adaptive scope whose target set of user accounts for retention processing is dictated by the membership of a dynamic group. As changes occur to user accounts, they join or leave the group and will subsequently join or leave the adaptive scope.
Stitching Stuff Together
This isn’t a particularly high-tech solution nor is any innovation present. Instead, it’s an example of combining existing features to work around an apparent functionality gap. The trick is to get to know Microsoft 365 components well enough to know how to stitch them together, and that’s an ongoing and onerous task.
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.
Tony, will this work if only the group has the custom attribute or does each member of the group, trying to avoid setting a custom attribute to each user. Thank you
All accounts that you want to find will need to have the attribute.
Thanks do you know of another way , since to target Onedrive accounts it cant be a m365 group , no membership choice and not other way to add a group from my understanding.
What do you want to do? You can always have a distribution group of OneDrive account owners you want to retain, and add the OneDrive accounts for those people to a retention policy with PowerShell.
Tony, not sure what I am doing incorrectly, do you have a sample of a powershell command that adds users based on email address to adaptive scoApe ?
You configure the adaptive scope with attribute(s) so that Microsoft 365 can find the target users https://practical365.com/adaptive-scopes-retention-policy-user-groups/. PowerShell isn’t involved at all, unless you use it to populate the attribute used by the adaptive scope.
sorry , I was not clear on ask, I want to take users who are in a group , and update a scope with all those emails for users to reduce adding custom attributes to every user.
But adaptive scopes are based on attributes, so you are going to end up populating attributes to make it possible for adaptive scopes to work.
Tony, we want to apply a retention policy for Teams recordings, Microsoft said to target just recordings for Teams use this, we just want recording based on Onedrive accounts not all of SP. Was told to use this in adaptive scope to do this (ProgID:Media OR ProgID:Meeting), issue is how to target just onedrives since need to base on user or URL and url way is a nightmare.
You mean like this? https://office365itpros.com/2021/06/22/teams-meeting-recordings-auto-label/
Is this what you mean, so since we large org would use a runbook to add any new users?# Loop through each member and add their OneDrive account to the retention policy
foreach ($member in $groupMembers) {
$userPrincipalName = (Get-ADUser -Identity $member).UserPrincipalName
# Add the OneDrive account to the retention policy
Set-RetentionCompliancePolicy -Identity “YourRetentionPolicyName” -AddExchangeLocation $userPrincipalName
}
You’d be adding their OneDrive URI to OneDriveLocation, not Exchange location.