This post has been republished via RSS; it originally appeared at: New blog articles in Microsoft Tech Community.
Back in October 2021 we announced the public preview of an exciting new Microsoft Information Governance and Records Management feature called adaptive policy scopes. This feature provides advanced flexibility when applying retention policies and labels to user, site, and group locations in Microsoft 365.
Many organizations have regulatory, legal, or business requirements that demand different retention rules to apply to various departments, locations, and roles. Adaptive policy scopes help to provide the flexibility needed to achieve these requirements by allowing administrators to scope policies based on common attributes and properties from Azure AD (including those synced from on-premises AD in hybrid environments) or indexed properties from SharePoint Online sites.
However, there are also certain scenarios in which an organization may want to include or exclude locations from a policy based on more granular attributes such as the type or state of an object. This is particularly true in Exchange Online as several different types of mailboxes exist. The most common types of mailboxes are user mailboxes and Microsoft 365 group mailboxes (which are used by Microsoft 365 Modern Groups and Microsoft Teams). These mailbox types are easily targeted using adaptive policy scopes with user and group scopes, respectively.
But there are several other types and states of mailboxes that organizations commonly use. These can include shared mailboxes, resource mailboxes, and inactive mailboxes. This blog post will review how an administrator can create scopes that include or exclude these other common types of mailboxes for maximum flexibility in applying Microsoft 365 retention policies and labels.
Shared mailbox retention with adaptive policy scopes
When adaptive policy scopes were in private preview one of the most common requests we received was to support shared mailboxes. Shared mailboxes are used by organizations when multiple users need to access a single mailbox such as a support, receptionist, or department mailbox. Unfortunately, although they were included in organization-wide retention policies using static scopes, we were unable to add shared mailbox support to adaptive policy scopes before it went to public preview. We are excited to announce that support for shared mailboxes in adaptive policy scopes has recently been fully rolled out and you can now create scopes to target them in your tenant today.
Shared mailboxes share many similar attributes with user mailboxes. There are several ways that you could effectively target them in adaptive policy scopes, such as using department, location, or even some custom identifiable information specified with CustomAttributes1-15.
For example, let’s say you want to target all mailboxes that are in the legal department and have retention requirements. You can use the department attribute and utilize one of the custom attributes to identify mailboxes that should be included in the scope, which are all available options in the simple query builder for adaptive policy scopes:
NOTE: If your organization synchronizes its on-premises directory with Azure AD, for synced objects you will need to configure most attributes on-premises and then synchronize any changes with Azure AD before querying them in adaptive policy scopes.
But, what if you want to include or exclude a shared mailbox in an adaptive policy scope based solely on the mailbox type? This is where the advanced query builder can be very useful.
The advanced query builder is an alternate configuration option for the adaptive policy scopes wizard. With user scopes (which target the types of mailboxes we are discussing in this blog), it uses OPATH to query objects. You can access the advanced query builder by clicking the blue button at the top of the simple query builder screen:
With OPATH and the advanced query builder, you can use the IsShared property of the mailbox to be inclusive with True or exclusive with False. Exchange Online PowerShell can be used to test the OPATH query:
Then, simply input the OPATH query into the advanced query builder within the adaptive policy scope wizard:
NOTE: For more examples of using OPATH and the advanced query builder, check out our recent webinar Building Advanced Queries for Users and Groups with Adaptive Policy Scopes.
Resource mailbox retention using adaptive policy scopes
Like shared mailboxes, resource mailboxes were also not available for use in adaptive policy scopes at the launch of the public preview, but now are available to use in your tenant today. Resource mailboxes are used to help manage physical resources in Exchange Online. There are two different types of resource mailboxes:
- Room mailbox is a resource mailbox that is assigned to a physical location, such as a conference room.
- Equipment mailbox is a mailbox assigned to a resource that is not location-specific, such as a projector.
Unlike shared mailboxes, however, resource mailboxes historically have never been included in Microsoft 365 retention policies. Now, with adaptive policy scopes, you can create policies specifically for your organization’s room and equipment mailboxes (such as a policy to delete items after 1 year) or include them in your organization's existing retention policies.
Since resource mailboxes are very similar to shared mailboxes, most of the options an administrator has for filterable properties are the same. For filtering by mailbox type using OPATH and the advanced query builder, you can use the property IsResource:
OPATH in Exchange Online PowerShell
The downside here, of course, is that you can’t explicitly tell the difference between a room mailbox and an equipment mailbox using just the IsResource property. For this, you could use a custom attribute:
NOTE: We are working on enabling support for additional properties that could be used to identify different mailbox types without using a custom attribute.
OPATH in the advanced query builder
Inactive mailbox retention using adaptive policy scopes
Unlike shared and resource mailboxes, inactive mailboxes have been supported with adaptive policy scopes since the public preview release. Inactive mailboxes are not a mailbox type; they are instead a mailbox state.
When a user object is deleted from Azure AD (such as when an employee leaves the organization), the Microsoft 365 license once again becomes available. But, if the associated mailbox has a legal or regulatory hold applied to it, we cannot delete the mailbox so, instead, it becomes inactive.
Before adaptive policy scopes, retention policies that applied to the entire organization (org-wide) for the Exchange location would automatically affect inactive mailboxes. However, there was no efficient way to have a retention policy specific to inactive mailboxes until now. For example, an organization may choose to keep inactive mailbox data for 1 year after an employee leaves but keep the data of active employees for 5 years.
With adaptive policy scopes, you can target inactive mailboxes using the advanced query builder similarly to how you would for shared and resource mailboxes, but using the IsInactiveMailbox property:
OPATH in Exchange Online PowerShell
NOTE: You can also filter on other properties such as department, location, and custom attributes however once a mailbox is made inactive, those properties cannot be changed.
Applying a scope to multiple mailbox types
One of the major benefits of adaptive policy scopes is how powerful they can be. Administrators can create extremely complex queries allowing virtually any requirement to be achievable. As a more advanced example, the following scope applies to shared mailboxes, room mailboxes, but excludes all inactive mailboxes:
OPATH in Exchange Online PowerShell
OPATH in the advanced query builder
Validating Advanced Queries in OPATH
We are working on providing some validation within the adaptive policy scope wizard, however, as of right now there is no validation to verify your query is accurate. To help fill the gap, I’ve created a script that can be used to validate OPATH queries for user and group scopes.
- You can view and download the validation script here: Validate-AdaptiveScopesOPATHQuery.ps1 - MIGScripts (brenle.github.io)
Additionally, as we previously stated, we hosted a recent webinar that discussed building advanced queries for user and group scopes.
What scope type should I use for shared, resource, or inactive mailboxes?
For shared, resource, and inactive mailboxes, you should use the “user” scope type as they all refer to user objects in Azure AD.
Do I need to use the advanced query builder and OPATH for shared, resource, and inactive mailboxes?
By default, all mailbox types are included in the scope. So, if you don't need to exclude any of these mailbox types, you can use the simple query builder provided the properties needed are available. If you do need to exclude one or more of these mailbox types or if the simple query builder doesn't have a property that you need to filter, you will need to use OPATH and the advanced query builder as IsShared, IsResource, and IsInactiveMailbox properties are not currently available in the simple query builder.
What if I have already created scopes for my organization but didn’t take into consideration shared, resource or inactive mailboxes?
If your existing scope doesn’t already exclude the types of mailboxes you don’t want included you should consider modifying the scopes using the above properties. If your existing scope uses a query built with the simple query builder, you will need to convert your query to OPATH and use the advanced query builder.
Do shared and resource mailboxes need to be licensed to use with adaptive policy scopes?
Yes, as with user mailboxes, shared and resource mailboxes need to have an applicable license applied for compliant usage with adaptive policy scopes. As of the publish date of this blog these licenses include the following:
- Microsoft 365 E5/A5/G5
- Microsoft 365 E5/A5/G5 Compliance
- Microsoft 365 E5/A5 Information Protection and Governance
- Microsoft 365 F5 Compliance
- Microsoft 365 F5 Security and Compliance
- Office 365 E5/A5/G5
How do you appropriately license an inactive mailbox?
Inactive mailboxes must have the appropriate license assigned to the mailbox before making it inactive. Once the mailbox is made inactive the license will be free to use elsewhere. For more information, see create an inactive mailbox.