We have a guest post today from @thibaudcolas from our Services Team.
Disclaimer: With the introduction of cross platform co-auth support announced recently at Ignite (Announcing co-authoring on Microsoft Information Protection-encrypted documents and labeling updates), this capability will change in the future as the metadata location used to store the sensitivity label will change and not be readable by this approach, once co-auth support is enabled in your tenant (which is not the case by default).
The purpose of this process is to allow the re-classification of existing documents classified with a deprecated sensitivity label to a new one. This process mainly aims to reclassify files which have been manually classified and which are not reachable by the AIP scanner. Files not matching these criteria can also be addressed, but other solutions exist (e.g. MCAS).
A deprecated label is a label which cannot be used anymore for technical reasons. An example could be when a label used to classify documents becomes a top label (sub-labels have been introduced). Then, as documents cannot be classified with a top label, these legacy items may fail some mechanisms (e.g. attachment’s inheritance to mail or sensitivity labels as a condition with M365 DLP).
Notes:
Context:
Contoso had the following classification taxonomy:
General |
Confidential |
Highly Confidential |
Contoso used to have a label “Confidential” which was set as a default label for all new documents. Therefore, a significant amount of newly created and edited documents has been classified as “Confidential”.
Then, the classification has been updated by the introduction of two sub-labels:
General |
Confidential |
Highly Confidential |
All Employees |
All Employees |
|
User-Defined permissions |
User-Defined permissions |
To ensure “Confidential” documents can still be protected by M365 DLP or benefit the attachment’s inheritance to mail, they must be reclassified to “Confidential – All Employees”.
Requirements:
“Confidential” label custom property* |
MSIP_Label_<Confidential_ImmutableID>_Name |
“Confidential” label custom property value* |
Confidential |
“Confidential-new” ImmutableID** |
<Confidential-new_ImmutableID> |
Sub-label 1 to migrate |
All Employees |
Sub-label 2 to migrate |
User-Defined permissions |
* : Open a “Confidential” document > click File > Info > Properties > Advanced Properties > Custom
** : Use “Get-Label -Identity “Confidential-new” | fl”
Note: This process relies on the utilization of the advanced setting “LabelByCustomProperties”. This one only works with properties it “does not know”, which includes metadata applied by the client. As long as the deprecated label will exist in the tenant, the advanced setting will not work as it “knows” its associated custom properties. For this reason, the deprecated label must be deleted.
Solution:
We will recreate the “Confidential” label and sub-labels structure with a new label which will looks identical for end-users.
Note: This process should be transparent for end-users if no one opens a new Office app during the process. However if it happens, the user will receive the policy as it is at this moment. Once the process completed, sensitivity labels will look identical for end-users.
Note: This process should be transparent for end-users if no one opens a new Office app during the process. However if it happens, the user will receive the policy as it is at this moment. Once the process completed, sensitivity labels will look identical for end-users.
Thanks for reading and we hope you find this useful! If you haven’t already, don’t forget to check out our resources available on the Tech Community.
Thanks!
@Robin_Baldwin on behalf of the MIP and Compliance CXE team
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.