This blog is part of a series on Teams. For more articles, check back often
Written: 27/10/2021 | Updated: N/A
I am about to go into one hell of a month. Starting with Ignite next week (2-4 Nov) I have a number of teaching deliveries and a lot of course updates. I am also back on the circuit courtesy of aMS Germany and Power Platform France. As always, thank you to the organisers for having me. Yet, despite all this good stuff I am also acutely aware that I haven’t done any technical writing on the blog since the day before I got Covid – and as my good friend Vesku Nopanen released one today on the new Whiteboarding features in Teams, the situation demands I write. So where to start? Having effectively had two months off I can certainly say I am not in short supply of subject matter – but one that I thought I would start on since I am really interested in it is adaptive scopes for retention and label policies.
Teams, as many of you may have heard it described, is a converged application. It is based upon other apps in the Microsoft 365 ecosystem such as Exchange and SharePoint. When we have a conversation in a channel or in a private chat, or when we upload a file to a Teams Channel to collaborate on it, all of that data is not stored in Teams itself. For example, chats and conversations are stored in Exchange and Files are stored in SharePoint and OneDrive. Video – for example Teams meetings recordings are stored again in SharePoint and OneDrive. Now, there are many reasons why an organisation would like to retain this data – compliance is a reason, to re-use it again in the future without fear of deletion is another. However, up until this point we have only been able to set up retention policies and labels statically with what you would call a static scope. What this means is that when I create the retention or label policy I can only apply it to users and locations and those never change unless I go in and manually change the policy or the label. So, you may ask, where is the limitation in static scopes given they have generally worked well and I can set policies and labels for the specific locations and users I want. Well, the limitation is that organisations themselves aren’t static. Things like people’s roles change over time and as administrators we can’t always be aware of such changes in our organisation. The structure of organisations and their geographies change. Static also means a lot of manual work to maintain those policies and labels and ensure they cover everything and everyone we need them to cover, or not cover. Imagine in my org I wanted a retention policy applied to all executives so that their Exchange, OneDrive and any Teams Chat Conversations are retained for 10 years. In this situation it is not required for anyone other than the executives because there isn’t a compliance need and it could hammer our storage. Sure I could do that with a static scope if I knew all of the executives. However, it would be much easier with an adaptive scope. An adaptive scope – similar in a sense to a dynamic AD group – adapts and applies based upon users Azure AD attributes, SharePoint Site Properties or Microsoft 365 Group attributes. What I can now do, for example, is set up an adaptive scope based on the executive job title in my organisation so anyone who has this job title has a retention policy automatically applied for Exchange, OneDrive and Teams Chats and Conversations. Another good example is, what if you have a Finance Team who work with a number of different files which have different retention requirements who need a far more diverse set of labels than the rest of the organisation? Again, instead of monitoring who is going in an out of that team simply set an adaptive scope in the label policy so anyone in the department Finance will have that diversified set of labels per the correct policy.
So we can see the benefits clearly. Powerful targeting of retention and label policies. You can also include Teams and Yammer in the same policies whereas with static, per docs, you can’t. Yet even before we look at this, we already know a few things which an we’ll need to go into it with our eyes wide open. The first is that Azure AD will need to be kept clean and up to date. For example, if I am basing a retention policy on an Azure AD attribute for users such as a role or department this may involve a bit of upfront tidying of Azure AD, and it will certainly need maintenance. Miss out a users attribute in Azure AD and they won’t be added to the policy. Static scopes may therefore be more beneficial as catchalls where keeping Azure AD up to date is low on the agenda, user onboarding is generally weak or, for example, IT within the org are not notified of role changes. Secondly, adaptive scopes are more granular which means they could make the retention landscape more complex and management overhead higher. Imagine you have several retention policies in play and several adaptive and static scopes. For any individual user, what retention actually applies? Whilst Microsoft have included a policy lookup tool in the compliance centre which you can query it will be interesting to hear how that goes in real world situations. Organisations who want a simple life will probably veer away from adaptive scopes. Lastly, since this is a preview feature at the time of writing their is little on licencing. The test tenant I use has Microsoft 365 E5 licencing, so it may well be an added cost. Like you I hope not. Also at the time adaptive doesn’t cover exchange public folders or preservation lock so if you want these things you’ll need to use static
This blog will cover
- Applying an Adaptive Scope to a Retention Policy
- Applying an Adaptive Scope to a Retention Label Policy
- Policy Lookup
Note this blog will have some abridged steps which will assume some experience with a Microsoft 365 environment.
- Global Admin Permissions or Compliance Administrator permissions
- Microsoft 365 Licences which permit adaptive scopes (yet to be confirmed since feature is in preview but is within Microsoft 365 E5 per testing)
APPLYING AN ADAPTIVE SCOPE TO A RETENTION POLICY
Example Requirement: ensure that all Exchange Messages, OneDrive Files, Private Teams Chats and Private Channel Messages are retained for 10 years for everyone who has the job title Consultant. Delete after that time
Let’s do this.
1.) Log into https://login.microsoftonline.com
2.) Select Admin on the left app launcher
3.) The first job is to ensure Azure AD has the correct information. In the Microsoft 365 Admin Centre, select Azure Active Directory from the left nav
4.) Select Users
5.) Select the user to open their attributes
6.) Since the adaptive scope will use Job Title ensure that this attribute is correct. If not, Edit, correct the attribute and then Save
7.) Rinse and repeat for all users who have that Job Title in the org
8.) Back in the Microsoft 365 admin portal, select Compliance from the left nav
9.) Select Information Governance
10.) Now create the adaptive scope. Select Adaptive Scopes (Preview)
11.) Select Create Scope
12.) Add a Name and Description for your scope. It’s recommended here to make the naming conventions very explicit so its clear in a list should there be several scopes. Also, the scope name cannot be renamed once created. Once done select Next
13.) Since this example will be an adaptive scope based on Job Title – and hence user based – select Users then Next
14.) Now is the time to set the attribute itself. There are a number of attributes to use, however this example uses Job Title so it has been set as that. Other examples include First Name, Last Name, Country and even custom attributes. This is set as shown so that the job title is equal (which again other options can be chosen) to Consultant (added manually) which is the job title of several users in Azure AD. Anyone with this job title in the organisation will go on to have the retention policy applied when the policy is created. Note, that a limitation here is that the operator only uses equal/not equal and starts with/does not start with. It would be awesome later on it could have ‘contains’ as many roles have similar words in their title – think here Chief, Consultant, Architect, etc., however there is a way to include multiple job titles – see FAQ’s. Once done select Next
15.) Review and then Submit
16.) The scope is now created. Select Done and the adaptive scope is now listed
17.) Our users are set in Azure AD. The adaptive scope is built. Now for the policy. Select Retention Policies
18.) Select New Retention Policy
19.) Add a Name and Description for your policy. Recommended here to make it very explicit so its clear who it is applied to and what is retained by the policy. Additionally you could also add years. Good naming conventions are useful if have several policies. Note also that you cannot retain everything within a single policy which will be explained in the next few steps, so with this policy I am going to name it Exchange and OneDrive as these are the services which will be retained in the policy. Once done select Next
20.) Select Adaptive then Next
21.) Select Add Scopes. Add the adaptive scope created and this will refine what can be retained in the policy
22.) Set the locations to be retained. As you can see below it is only possible to select Exchange and OneDrive. These cannot be selected at the same time as Teams Chats, Private Channels and Yammer. In this example the need is to retain Exchange, OneDrive, Teams Chats and Private Channels so a second policy is needed after this one. Once done, select Next
23.) Now set the Retention Settings. The requirements were to retain for 10 years and to delete after that time. Set the retention settings as you would a static scope then select Next
24.) Review and then select Submit
25.) The retention policy is now created, select Finish
26.) The policy is now created. It will be a pending state for a period after it has been created. It is recommended to check back until it is marked as success which means it is applied and running
27.) To finish the task rinse and repeat to create a second retention policy covering Teams Chats and Private Channel Messages using the same adaptive scope. Again 10 years and again to delete after that time. That wraps it up! Our job here is done. Two retention policies have been created based on a single adaptive scope that covers Exchange, OneDrive, Teams Chats and Private Channel messages for everyone in my org who has the Job Title Consultant. No worries after this except making sure Azure AD stays up to date and ensuring users have the right job title for the retention policy to apply.
APPLYING AN ADAPTIVE SCOPE TO A RETENTION LABEL POLICY
Example Requirement: Ensure that the Finance Team has the label ‘Finance’ that they can apply to Teams Meeting Recordings and personal documents and can retain it for 10 years. Delete after that time.
1.) Let’s get back to the Microsoft 365 Admin Centre. Select Azure Active Directory
2.) In Azure AD ensure Users
3.) Select the user to open their attributes
4.) Since the adaptive scope will be applied to the Finance Department make sure the Department attribute is correct. If not, Edit, correct the attribute and then Save
5.) Rinse and repeat for all users in the Finance Department
6.) Back in the Microsoft 365 admin portal, select Compliance from the left nav
7.) Select Information Governance
8.) Now create the adaptive scope. Select Adaptive Scopes (Preview)
9.) Select Create Scope
10.) Add a Name and Description for your scope. It’s recommended here to make the naming conventions very explicit so its clear in a list should there be several scopes. The scope cannot be renamed once created. Once done select Next
11.) Since this example will be an adaptive scope based on Department – and hence user based – select Users then Next
12.) Now is the time to set the attribute itself. There are a number of attributes to use, however this example uses Department so it has been set as that. Other examples include First Name, Last Name, Country and even custom attributes. This is set as shown so that the job title is equal (which again other options can be chosen) to Finance (added manually) which is the department of several users in Azure AD. Anyone with in this department in the organisation will go on to have the retention label issued when the policy is created. Note, that a limitation here is that the operator only uses equal/not equal and starts with/does not start with. It would be awesome later on it could have ‘contains’ as many departments have similar words in their title – Finance, Financial Consulting, Financial planning, however there is a way to include multiple job titles – see FAQ’s. Once done select Next
13.) Review and then Submit
14.) The scope is now created. Select Done and the adaptive scope is now listed
15.) Users are completed. Adaptive Scope is completed. Let’s create the label. Select Labels and then Create a Label
16.) Give the label a Name and Description. Recommended here to make it very explicit so its clear what the label is used for. Once done select Next
17.) Set the Retention Settings and then select Next. Here it is shown that the items marked with the label will be retained for 10 years and then deleted
18.) Review and then select Create Label
19.) The label is now created. The final part is to create a label policy with an adaptive scope. Select Publish this label to Microsoft 365 Locations and select Done
20.) Select the label and then select Next. If this is the first label there will be no choice
21.) Select Adaptive and then Next
22.) Select Add Scopes. Add the adaptive scope created and this will refine what can be retained and the labels applied to
23.) Set the locations where the labels can be applied. As you can see below it is only possible to select Exchange and OneDrive when using adaptive user scopes with label policies. Select Next
24.) Add a Name and Description for your label policy. Recommended here to make it very explicit so its clear who it is applied to and the services the label covers. Additionally you could also add years. Good naming conventions are useful if have several policies. Once done select Next
25.) Review the labeling policy and select Submit. Note it takes up to 1 day for the label to appear to scoped users
26.) Select Done and the labelling policy shows up under Labelling policies. It will be in pending state for a period after it has been created. It is recommended to check back until it is marked as success which means it is applied and running
27.) Our job here is done. The Label has been pushed to the users in the Finance Department who can now use it in Exchange and OneDrive to apply to their Teams Meeting recordings and documents. Here is a screen shot of one of the users in the Finance Department who can now apply the Finance – Retain 10 Years label to the Teams Meeting
Q. Can an adaptive scope be renamed?
A. No once it is created it cannot be renamed (at least not through the GUI). You would likely need to create another adaptive scope, and then amend the respective policy to use the new scope – although caution needs to be applied here as this isn’t documented as of the time of writing
Q. What about SharePoint Sites? With retention policies in User Adaptive Scopes everything but SharePoint shows up and with the labelling policies, only Exchange and OneDrive shows up. What if I had a situation where that department or group of users (with the same job title) all use a specific SharePoint Site/Team and I want them to be able to apply the label to files within the SharePoint Site or apply a retention policy to that site? Is that possible?
A. A good question and one which has been tested. The answer is as follows. Let’s say we have the same scenario with retention policies or labels as the above scenarios and the users have a specific SharePoint site they use. Grab the URL of the SharePoint Site
Create a new adaptive scope based upon the SharePoint Site and that URL as opposed to a User Adaptive Scope
Then add the adaptive scope inside the existing policy which lights up SharePoint
Or create a new policy purely based upon the Site adaptive scope. Of course, splicing the new Site adaptive scope within the existing retention or labeling policy has an impact on the naming conventions so this ideally needs to be thought through at the start. Seperate policies would probably be the way to go, or a static scope based upon that specific site.
Q. How can I get around multiple job titles without creating multiple adaptive scopes
A. Within the adaptive scope add attributes using or as shown below. As mentioned above, long term, it would be good to add contain as an operator which may make the adaptive scope simpler as opposed to having to think of every variant of a job title in an organisation
Q. Can auto-labeling be used with adaptive scopes?
A. Yes it can. One scenario which this could be used for is Teams Meeting Recordings for a subset of users in the org. Create an adaptive scope as the examples above. Create a label and then a labelling policy including ProgID:Media AND ProgID:Meeting
Q. What about if a Department, for example, had a specific Team they used and wanted to capture conversations?
A. Exactly the same as a SharePoint Site, add a Microsoft 365 Group adaptive scope and then add that scope to the Retention Policy or create a separate adaptive scope and policy.
A final note concerns the new Policy Lookup functionality which is also under Information Governance within the Compliance centre. As using adaptive scopes will – at least in theory – create more complexity in the organisations tenant since several scopes (static and adaptive) may be applied to users, sites or Microsoft 365 Groups, it is really important to be able to see what policies apply to which users. This could be useful when we want to see what policy wins out according to the general principles of retention, if we want to find out whether a user is in a policy or not, or whether we simply want to test that the policy applies to the user, the site, or Microsoft 365 Group
As shown, the policy lookup works for both retention and labeling policies. Vesku, who is a consultant, has the retention policies applied, and Adam, who is in Finance, has the label policy applied as we configured in the previous examples