Update (2022-02-08🙂 This blog has been updated to include recent changes in the feature.
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.
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 RecipientTypeDetails property of the mailbox with the SharedMailbox type. Exchange Online PowerShell can be used to test the OPATH query:
Update (2022-02-08): This article previously recommended using the IsShared property but since then RecipientTypeDetails has been supported. RecipientTypeDetails is a better choice for shared mailboxes as it excludes certain system mailboxes such as discovery search mailboxes.
Get-Mailbox -Filter {RecipientTypeDetails -eq "SharedMailbox"}
Name Alias Database ProhibitSendQuota
---- ----- -------- -----------------
TestSharedMailbox20211... testsharedma... NAMPR13DG031-db016 99 GB (106,300,44...
TestSharedMailbox22022... testsharedma... NAMPR13DG091-db016 99 GB (106,300,44...
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.
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:
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 again use the property RecipientTypeDetails with RoomMailbox or EquipmentMailbox types:
Update (2022-02-08): This article previously recommended using the IsResource property but since then RecipientTypeDetails has been supported. RecipientTypeDetails is a better choice for resource mailboxes as allows you to distinguish between room and equipment mailboxes.
Get-Mailbox -Filter {RecipientTypeDetails -eq "RoomMailbox"}
Name Alias Database ProhibitSendQuota
---- ----- -------- -----------------
testRoomMailbox testRoomMailbox namPR13DG304-db141 99 GB (106,300,44...
Get-Mailbox -Filter {RecipientTypeDetails -eq "EquipmentMailbox"}
Name Alias Database ProhibitSendQuota
---- ----- -------- -----------------
testEquipmentMailbox testEquipmen... NAMPR13DG086-db021 99 GB (106,300,44...
Get-Mailbox -Filter {RecipientTypeDetails -eq "RoomMailbox" -or RecipientTypeDetails -eq "EquipmentMailbox"}
Name Alias Database ProhibitSendQuota
---- ----- -------- -----------------
testRoomMailbox testRoomMailbox namPR13DG304-db141 99 GB (106,300,44...
testEquipmentMailbox testEquipmen... NAMPR13DG086-db021 99 GB (106,300,44...
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:
Get-Mailbox -IncludeInactiveMailbox -Filter {IsInactiveMailbox -eq "True"}
Name Alias Database ProhibitSendQuota
---- ----- -------- -----------------
inactivemailboxTest inactivemail... NAMPR13DG282-db075 99 GB (106,300,44...
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.
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:
Update (2022-02-08): This article previously recommended using the IsShared and IsResource properties but since then RecipientTypeDetails has been supported. RecipientTypeDetails is a better choice for shared and resource mailboxes as it excludes certain system mailboxes such as discovery search mailboxes and allows distinction between resource mailbox types.
Get-Mailbox -Filter {((RecipientTypeDetails -eq "RoomMailbox") -or (RecipientTypeDetails -eq "SharedMailbox")) -and (IsInactiveMailbox -eq "False")}
Name Alias Database ProhibitSendQuota
---- ----- -------- -----------------
TestSharedMailbox20211... testsharedma... NAMPR13DG031-db016 99 GB (106,300,44...
TestSharedMailbox22022... testsharedma... NAMPR13DG091-db016 99 GB (106,300,44...
testRoomMailbox testRoomMailbox namPR13DG304-db141 99 GB (106,300,44...
Update (2022-02-08) Previously, we never had any validation for OPATH queries. That meant if the query was incorrectly formatted you would only know after waiting several days for the scope the populate. We've since released basic query validation for OPATH. If an incorrect query is entered and the scope is saved/created, an error message will display:
However, you may want to know which objects will match the query while building it. To help understand what objects a query will return, we've created a script that can be used to validate OPATH queries for user and group scopes.
Also, 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 RecipientTypeDetails, 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:
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.