Enhancing Existing Data Lifecycle Management Policies by Migrating to Adaptive Policy Scopes
Published May 02 2022 09:11 AM 3,429 Views
Microsoft

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:

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:

 

Migrating existing policies to use adaptive policy scopes consists of five, easy, at-your-own-pace steps.Migrating existing policies to use adaptive policy scopes consists of five, easy, 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

 

By default, site scopes include all site types, so the SiteTemplate property can be used to filter by type.  When using the SiteTemplate property with site scopes, the advanced query builder must be used.By default, site scopes include all site types, so the SiteTemplate property can be used to filter by type. When using the SiteTemplate property with site scopes, the advanced query builder must be used.

 

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:

 

The scope details populate after about 24-48 hours and allow visibility into objects that match the scope's query.The scope details populate after about 24-48 hours and allow visibility into objects that match the scope's query.

 

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.

 

While it takes about 1 day for policy distribution, it can take up to 7 days for the policies to fully apply to content.While it takes about 1 day for policy distribution, it can take up to 7 days for the policies to fully apply to content.

 

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:

 

After 1 day we recommend confirming policy distribution was sucessful.After 1 day we recommend confirming policy distribution was sucessful.

 

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.

 

The new policy lookup tool is a very useful resource to determine whether a policy has been applied to a location or not.The new policy lookup tool is a very useful resource to determine whether a policy has been applied to a location or not.

 

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:

 

Static scope policies allow you to exclude locations which is a great way to test the new policies on a handfull of locations.Static scope policies allow you to exclude locations which is a great way to test the new policies on a handfull of locations.

 

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!

2 Comments
Co-Authors
Version history
Last update:
‎May 02 2022 09:11 AM
Updated by: