If you are unfamiliar with adaptive policy scopes, it is an exciting new Microsoft Purview Data Lifecycle Management and Records Management feature that provides the ultimate level of flexibility when applying retention or deletion to Microsoft 365 locations. It allows organizations to meet regulatory, legal, or business requirements that demand different retention rules to apply to various departments, locations, and roles.
Besides an immediately clear use-case for adaptive policy scopes - applying to scenarios where multiple circles of users, sites, or groups have different data lifecycle requirements - it can also be used to enhance more broadly applied policies, such as those that are applied to an entire location.
By choosing to migrate your organization’s existing static-scoped policies to new policies that apply to adaptive policy scopes, you can:
- enable granular flexibility - for example, choosing whether or not to apply to shared, resource, or inactive mailboxes in policies applied to Exchange Online
- resolve common frustrations with static scopes, such as inclusion/exclusion limits
- ensure future fluidity – policies will update automatically when your business changes
- guarantee simple, low-administrative effort location updates – policies are applied based on attributes or properties that can be changed without editing the policy
With this post, our goal is to outline the recommended approach for migrating your entire-location and static-scoped policies to policies based on adaptive scopes in just 5 simple, at-your-own-pace, steps:
Let’s dive into each step in more depth!
Step 1: Plan
Although adaptive policy scopes enable a ton of useful functionality because of their flexibility, it is important to ensure your organization plans appropriately for the changes they introduce including how objects are identified. Below are a few tips that we recommend considering during the planning phase.
Shared, resource, and inactive mailboxes
Entire location policies that apply to Exchange Online automatically include inactive, shared, and resource mailboxes within your organization. Adaptive user scopes also include all 3 of these types by default.
If you don’t want to include one or all of these different types of mailboxes, ensure you exclude them via the scope’s query. Additionally, if you do want to include shared or resource mailboxes, ensure they are licensed appropriately for use with adaptive policy scopes.
SharePoint site scopes
Static scopes apply to OneDrive and M365 Group sites as separate locations, however, SharePoint site scopes within adaptive policy scopes will automatically include all site types. If you want to exclude either of these types, make sure the scope query is configured to do so – we recommend using the SiteTemplate property for this.
OneDrive location is linked to users
Utilizing user scopes for OneDrive policies can offer more options than if using static scopes or SharePoint site scopes as you can query the user’s Azure AD properties such as department, location, or role. Additionally, it prevents issues caused by UPN changes (including when a user leaves the organization) when including/excluding a OneDrive site by URL.
Plan for static scopes policies applied to groups
At this time, adaptive policy scopes cannot query group membership (for example distribution lists, mail-enabled security groups, or M365 groups), however, static scopes can include/exclude based on group membership at the time the policy is created/modified. As an alternative to group membership, consider using Azure AD properties within your queries to determine scope inclusion.
Azure AD properties
Since user/group scopes rely on Azure AD properties, ensure your organization has the properties properly configured for everyone in the organization. If your organization synchronizes on-premises AD with Azure AD, any updates will need to be made on-prem, then synced to Azure via Azure AD Connect.
Step 2: Create the scopes
Deploying a policy based on adaptive policy scopes is a two-step process. First, you must create the scope, then, create the policy and link it to the newly created scope. Because of this separation in workflow, you can use the first step as an opportunity to take time to ensure the scope is configured correctly and includes all of the objects expected. During this phase, you can create as many scopes as you’d like without any end-user impact.
Based on the needs of your organization you may be able to use the simple query builder or - especially if you want to be more granular - you may need to use the advanced query builder to create queries using OPATH (user/group scopes) or KQL (site scopes).
For example, as mentioned above, site scopes include all sites by default. If you want to replicate the same inclusion that a static scope would have for SharePoint, you’ll want to use the advanced query builder with the following KQL query because SiteTemplate is not a property available in the simple query builder:
SiteTemplate=SITEPAGEPUBLISHING OR SiteTemplate=STS
Something else to consider during this phase is initially configuring the scope in a way in which it will only apply to a handful of locations. Doing this will allow your organization to slowly roll out the new policies without affecting the entire organization – and because adaptive scope queries can be edited at any time, very precise control of deployment is possible. When targeting smaller groups of locations for testing, consider the following:
- As mentioned above, you can create many different scopes without any user impact, so use that to your advantage by creating a few different scopes with different potential queries to compare. After creating the policy, scopes are interchangeable and stackable within the policy configuration.
- To limit user and group scope results, consider using a custom attribute.
- To limit site scope results, consider using a custom site property.
- When performing limited testing, you’ll likely want to keep the number of locations within the static scope inclusion/exclusion limits so that you can perform a full end-to-end test by excluding those locations from the existing static scope policies. For example:
- If testing user or group locations, stay under 1,000 users or groups as that is the maximum number of exclusions on a static policy
- If testing site locations (including OneDrive), stay under 100 locations
NOTE: Adaptive scopes are not affected by the same limitations as static scopes, so the user/group/site limits above would not apply - however, here we suggest adhering to them during this step so that you can more effectively test later by excluding the locations from the static policy. Once the static policy is removed/disabled, these limitations won't matter anymore.
After the scope(s) have been created, the objects matching the scope query can be reviewed by accessing the scope details after 24-48 hours:
Further tweaking of the scope can be done to ensure proper configuration, however it takes approximately 24-48 hours for any updates, so if using the advanced query builder, it’s quickest to first validate your OPATH or KQL queries before configuring the scope.
Step 3: Create new policies applied to adaptive scopes
Once satisfied, the next step is to create new policies targeting the new adaptive scopes. Since existing static scope policies can’t be modified to instead use an adaptive scope, new policies must be created. But this also encourages a less risky transition period as it allows your organization to keep the existing policies around during deployment of the new policies. Because of the principles of retention, no unintended actions should take effect during this phase (though initial small-scale testing is still recommended).
Your organization may have several different policies – both retention policies and retention label policies, so ensure the new policies are labeled appropriate to indicate they are an adaptive scope version of the original static scope policy.
Additionally, note that it generally takes up to 7 days for the new policies to synchronize to the locations and apply to the content. For this reason, plan on letting the new policies apply for about a week or so.
Step 4: Validating new policies deployed
After about 1 day we recommend you ensure the policies show successful distribution. Successful distribution will show a status of “Enabled (Success)” when selecting the newly created policy:
Alternatively, if you have several policies, you can check the distribution status of them all via SCC PowerShell with the following command:
Get-RetentionCompliancePolicy -DistributionDetail | ft -a Name, DistributionStatus
NOTE: If the policy distribution status is (Error), you can retry the policy distribution via PowerShell.
Then, after about a week, you can confirm that the new policies have been successfully applied to the locations included in your scopes. With the release of adaptive policy scopes, another useful feature called Policy Lookup was made available, which can be used to quickly spot check users/sites/groups. Remember, at this point, you should have both the original static-scope policies and the new policies based on adaptive scopes applied to each location you check.
Step 5: Remove the legacy policies
Once there is confirmation that the new policies have been successfully deployed to the correct objects, the last step is to remove the legacy policies.
If you chose to start small-scale by limiting the number of users/sites/groups that the new policies apply to (which we highly recommend), the locations can be excluded from the static scope version of the policies. For example, with an entire location policy, individuals, sites, or groups can be added as exclusions:
Otherwise, if you’ve already completed small-scale testing, you can simply delete or disable the legacy policy. While applying a policy takes up to 7 days to take effect, however, removing a policy takes a bit longer.
There’s a special grace period built into Microsoft Purview Data Lifecycle Management and Records Management that kicks in if any location is released from a retention hold. This grace period effectively prevents any deletion from occurring for 30 days to so that no unintended result from accidental policy modifications occur. Because of this, depending on the location, you may need to wait a little bit longer to fully confirm that the new policy is working as expected (another reason why first testing small scale is highly recommended).
Conclusion
As you can see, while it may seem like a daunting task, in reality, migrating from static scoped policies to adaptive policy scopes is a relatively painless process that can be broken up into several phases over a time period that works with your organization’s change control process.
The benefits that adaptive policy scopes provide can help modernize your data lifecycle policies, simplify future administrative effort, and expand the possibilities and compatibilities for future regulatory or policy updates - something much more difficult using static scopes.
We hope you enjoyed this post!