How to re-label documents classified with a deprecated sensitivity label

This article is contributed. See the original author and article here.

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).  


 


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:  



  1. When possible, renaming the display name of a label should be preferred as it does not imply any significant configuration changes while still allowing changing the user interface. 



  1. Keep in mind, Microsoft recommends implementing in production a classification taxonomy the most tailored to organizations’ needs from Day 1, avoiding having to deal with such situations. 


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: 



  • Compliance admin role 

  • PowerShell module to access SCC 

  • Access to Microsoft Compliance portal 

  • Information in the matrix below 

  • AIP UL client 

    • This process is not supported with Office built-in labeling feature (Windows, Mac, Mobile devices, and Web). 




























“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. 


 



  1. In SCC portal, change the display name of label “Confidential” to “Confidential.”

    • This is to make the display name “Confidential” available again and minimizing impact on user experience.



  2. In SCC portal, create a new label “Confidential-new” with “Confidential” as Display name.

    • All future mentions of labels in this process refers to Name and not DisplayName.



  3. In SCC portal, adjust the order of “Confidential-new” label to be located between “General” and “Confidential” labels.

    • Click of the “…” button of the label “Confidential-new” and “move up or down”).



  4. In SCC portal, select the appropriate label policy(ies) and add the new label “Confidential” for publication.

    • This is required to migrate sub-labels which are already published.



  5. Change the parent label of sub-labels “All Employees” and “User-Defined Permissions” from “Confidential” to “Confidential-new”.

    • In a PowerShell session, connect to SCC and run below commands:

      • Set-Label -Identity “All Employees” -ParentId $null

      • Set-Label -Identity “All Employees” -ParentId <Confidential-new_ImmutableID>

      • Set-Label -Identity “User-Defined Permissions” -ParentId $null

      • Set-Label -Identity “User-Defined Permissions” -ParentId <Confidential-new_ImmutableID>





  6. In SCC portal, unpublish label “Confidential” from all policies.

  7. In SCC portal, delete the label “Confidential”.

    • Before moving forward, ensure with below PowerShell cmd the label has correctly been deleted. It can take few minutes for a label to disappear

      • Get-Label





  8. Set the advanced setting “LabelByCustomProperties” to automatically reclassified “Confidential” documents as “Confidential-new / All Employees” when opened.

    • Set-Label -Identity “All Employees” -AdvancedSettings @{LabelByCustomProperties=“reclassificationrule,MSIP_Label_<Confidential_ImmutableID>_Name,Confidential”}



  9. Verify the advanced setting has correctly been set

    • (Get-Label -Identity “All Employees”).Settings

    • The setting “labelbycustomproperties” should be listed.



  10. Try to consume a “Confidential” document in new Word session

    • The label should be automatically updated to “Confidential-new / All Employees”, and it will work the same way for any documents classified “Confidential” and which be consumed with AIP UL client in future.

    • If ever it does not work, it may be the client did not download the last policy version. In that case, try following options:

      • Restart Word.

      • Reset AIP UL client settings (Sensitivity > Help and Feedback > Reset Settings).






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

Cannot Replicate Stored Procedure Execution when CDC is enabled

Cannot Replicate Stored Procedure Execution when CDC is enabled

This article is contributed. See the original author and article here.

With Transactional Replication you can replicate execution of the Stored Procedure like this:


 


Taiyeb_Zakir_0-1616012084473.png


 


This has several advantages as discussed in this article:


https://docs.microsoft.com/en-us/sql/relational-databases/replication/transactional/publishing-stored-procedure-execution-in-transactional-replication?view=sql-server-ver15


 


When you enable CDC at the Database level, replication of the stored procedure execution will NOT work. This is By Design. CDC does not support tracking at stored procedure execution level, which means individual rows logged by stored proc execution need to be flagged with REPLICATE bit, which makes it impossible for transactional replication to replicate stored proc execution.  As a result, ‘stored proc execution’ will work only when transactional replication is enabled and CDC is disabled.

Adaptive Cards community call – March 2021

Adaptive Cards community call – March 2021

This article is contributed. See the original author and article here.

THumbnailTitleSlide.png


 


In this month’s community call, there is a quick roadmap update – 9 features in development to be delivered in Schema versions 1.4, 1.5, 1.6 over the next 3 months.   Then there is a deep dive with demos and Q&A, focused on the Action.Execute feature and underlying Universal Actions Model for Microsoft Teams, Outlook and more, rolling out mid-April in Schema v1.4.  The new Action.Execute action type synchronizes activity (payload) in the back-end while rendering cards natively in Teams and Outlook front-ends.   Developers no longer need to build separate applications for each environment.   The call was hosted by Matt Hidinger (Microsoft). Presenters include Shiladitya Saha (Microsoft Teams) and Karan Thapar (Microsoft Outlook).  Recorded on March 11, 2021.


 



 


Demo:


Deep dive into Universal Actions for Microsoft Teams and Outlook – cards authored using the new Action.Execute action type “just work” in Teams chats, Outlook emails and more thanks to seamless back-end activity synchronization.  Action.Execute can return a new card to replace the current one.   Several light demos show the experience.  Also shown: Contextual views in Teams bots/adaptive cards – allows specific users to have individualized cards and Sequential Workflows support on Teams – progress through a multi-step process in a single adaptive card using auto invoke and synchronized refresh capabilities. 


 


Referenced in this call:



Resources in General: 



Stay connected:


Get in on March's #MonthOfMEM

Get in on March's #MonthOfMEM

This article is contributed. See the original author and article here.


MicrosoftTeams-image (9).png


 


 


Get in on March’s #MonthOfMEM


 


Two days of Microsoft Ignite just wasn’t enough to contain all of the technical skill-building, question-answering, and 1:1 engaging that the Microsoft Endpoint Manager engineering and product teams had to offer. That’s why we introduced the #MonthOfMEM: three dedicated weeks of post-Ignite training, Ask the Experts, 1:1 consultations, and real-world experience sharing designed to help IT pros build their knowledge, skills, and connections with the people building the endpoint management capabilities they rely on every day.


 


In the public sector? We’re here for you!


 


Join one of our three remaining Ask the Experts sessions, each of which is conveniently preceded with 24 hours of early access on the Tech Community to ensure that everyone has a chance to get their questions to our experts. We’ve already done two of these fun, informative events—two more to go!


 




We’re also offering free 1:1 consultations with the engineering team March 15-19 from 12:00 a.m. to 2:00 p.m. Pacific Time. This is a great opportunity for dedicated troubleshooting and specific advice for your environment and needs!


 


And, on March 24th, IT administrators from the University of Washington will be sharing their insights on how they were able to use Windows Autopilot and Intune to successfully deploy and manage devices in an education environment.


 


After the #MonthOfMEM


 


We’ll continue to host monthly Ask Microsoft Anything (AMA) events on the Tech Community. Folks can stay tuned to the to the Microsoft Endpoint Manager AMA space for details and bookmark the Microsoft Endpoint Manager blog for a full recap of the #MonthOfMEM and links to recordings of all activities on demand in the Video Hub.


Teams Meeting Delegation Diagnostic Now Available in Microsoft Remote Connectivity Analyzer

Teams Meeting Delegation Diagnostic Now Available in Microsoft Remote Connectivity Analyzer

This article is contributed. See the original author and article here.

Hi Teams Community,


 


We’re back with another addition to Support Diagnostics for Microsoft Teams.  @Chunlong Li has written our second offering in the Microsoft Remote Connectivity Analyzer.


 


This new test will help you troubleshoot and test if you meet requirements to Schedule a Teams Meeting on behalf of a Delegate.  If you’re assisting one of your users with Teams Delegate configuration or troubleshooting, this diagnostic is for you!


 


Typical symptoms of Delegate issues include an error message in Outlook:


 


Looks like you don’t have permission to schedule meetings for this account. Talk to the owner to get permission and try again.


 


To access the new diagnostic, navigate to Microsoft Remote Connectivity Analyzer, select Microsoft Teams, then click on the Teams Meeting Delegation test. 


 


TeamsDelegateMRCA.jpg


 


At a high level the Diagnostic attempts to create a test meeting in the Delegator’s calendar using the provided user account credentials and returns the result from the Teams Scheduling Service.  Success indicates Delegation is configured correctly and should work for the Delegate. 


 


Any failures will result in an error message that can be used by Support to assist Administrators in troubleshooting further.  In fact we expect this Diagnostic to greatly lessen the administrative burden of collecting Outlook and Teams client logs to troubleshoot these issues.  For the vast majority of failure cases the output from the MRCA Teams Meeting Delegation test should be all we need to help you fix the issue!



Please give this new Diagnostic a try with your Teams users’ Delegation issues, and let us know how it goes?



Thanks!
Microsoft Teams Support