Azure Information Protection Automatic Classification

Leave a comment

Another interesting behavior I came across when adding conditions and the way labels are applied.

My Confidential AIP labels are configured as shown below.


I configured the parent label (Confidential) to automatically classify documents.


I entered the text below to trigger one of the conditions. I noticed that the document was labeled as ‘Confidential \ Restricted’ which is the last child label listed in my AIP portal. Well, this was, obviously, not what I expected.


To further test if it will always default to the last child label, I reordered the child labels. I moved the ‘Restricted’ child label up and now ‘Anyone (not protected)’ is listed as the last child label.


Just as I expected, the new document was labeled as ‘Confidential \ Anyone (not protected)’ automatically.


In this experience, I learned that I need to configure the conditions at the specific child label level to get the anticipated results.

Thanks for reading!



Encrypt E-mail with Attachments

Leave a comment

As I continue to test different settings in Azure Information Protection, I want to share one that I find interesting.

I configured AIP for e-mail message with attachments to automatically apply a label that matches the highest classification of those attachments.

I created an e-mail where a default label ‘Official Use’ is automatically applied to my e-mail message. I then attached a document classified as ‘Restricted’, the classification of my e-mail message automatic changed to ‘Restricted \ All Employees’. This is the expected behavior.

I then sent the e-mail with the attachment to a trusted partner (in this case myself with a different domain) which I have configured ‘Viewer’ rights to view and reply the e-mail and the attachment.

Below is the e-mail message I sent to the trusted partner.


However, when the trusted partner (again, myself with a different domain) received the e-mail and tried to click on the ‘Read the message’ link (image below shows e-mail message received by the trusted partner), the trusted partner received “You do not have permission to view this message.”


After much testing, in order to allow my trusted partner to read the message, I had to change permissions from ‘Viewer’ to ‘Reviewer’ in Azure Information Protection.

As I continue to work with Azure Information Protection, I find myself learning new things every day.

Thanks for reading!

Protect and Manage Sharing of Sensitive Documents

Leave a comment

In my previous post, Classifying and Protecting Data in Office 365, I created an AIP (Azure Information Protection) label / policy that applied a footer text with “Sensitivity: Confidential”.

In this post, I’ll describe how you can take advantage of the properties stored in the document, by applying a rule to protect information sharing.

For example, to protect documents from being sent to external organizations via e-mail, you can configure a rule in Exchange to detect the document properties with a sensitivity label. Here’s an example of the configuration I created.

Exchange Mail Flow Rule

When a user within your organization attempts to send an e-mail with an attachment labeled with ‘Confidential’, the mail flow rule blocks it and the message sender receives the following delivery failure message as seen below (with the recipients e-mail addresses grayed out).


However, if you need to send to your trusted partners or customers, you can add their specific domains to the exception list in the mail flow rule. In the example below, I added one trusted domain to the rule.


With this exception, I was able to send the document labelled with ‘Confidential’ to the external recipients with the domain specified.

With the latest and greatest changes to AIP, and Office 365 Message Encryption capabilities, announced during the recent Microsoft Ignite Conference, the user experience of protecting and sharing your documents may be different than what is written in this post. I’ll continue provide updates and new information becomes available.

If you’re interested in learning more about data classification and protecting your organization’s information assets, feel free to connect with us at


Retention and AIP Protected Documents

Leave a comment

This is a follow up to my previous post (Which Office 365 Retention Policy Should You Use?).

Before I jump in, I want to provide additional information on documents stored in my SharePoint site.

I configured Azure Information Protection labels and published them. Note that All Employees sub-label of Restricted label is configured with protection. I created several documents, applied these labels manually and automatically, and uploaded them to SharePoint.

AIP Labels2

After applying retention policies to these documents (my previous post), one thing I noticed after the retention policies automatically applied to these documents, two of my documents classified as ‘Restricted All Employees‘ have no policies applied to them.  I waited additional days thinking that I was just too impatient.  After several days, still nothing.

AIP RMS Enabled

I have always known that AIP protected documents are not viewable in Office Web Apps, but I couldn’t understand why retention policies were not able to apply to these documents.

After researching more on this behavior, I’ve learned that SharePoint is not able to index AIP protected documents.  Because of this there are no metadata available for the retention policies to query on these documents.

I hope this helps explaining why O365 retention and SharePoint don’t always give you the expected results.


Which Office 365 Retention Policy Should You Use?

1 Comment

As I started to work on applying retention policies to documents stored in SharePoint using Office 365 Security & Compliance Center, I was confused why the retention policies were not working as I had hoped.

My objective was to have retention policies automatically applied to documents stored in SharePoint without needing the end-user to select the correct retention policy. I created several labels and policies under Classifications, configured one of them to detect content that contains specific words or phrases, and set them to auto-apply to my SharePoint site.  It gave me a warning that it may take up to seven (7) days for the label to apply.


I waited for seven days, but nothing showed up in my SharePoint site.

After a bit of digging I found that label policies created under Classifications only appear for users to manually select from SharePoint.


Since this did not meet my objective, I deleted these label policies from O365 Security & Compliance Center.

After more research and testing, I found that in order to achieve my objective, I had to create the retention policies under Data Governance.


Again, I had to wait.  But this time it only took one day for the policies to auto-apply.


In summary, if you want users to manually select retention policy, use Label Policies under Classifications.  If you want an automated method, use Retention under Data Governance.  I hope this helps others who have tried to make sense of which retention policy method to use.


Microsoft Information Protection (MIP)

Leave a comment

While I’m at Microsoft Ignite in Orlando this week, many new announcements were made including AI integration, mixed reality, and of course, cloud technology across Office 365. My area of focus today is Security and Compliance.

With the current version of Azure Information Protection, you can create an AIP label and apply Rights Management to classify and protect data. In order to apply retention to data, you would need to access Security and Compliance Center, create label and a retention policy.

Microsoft announced a new product called Microsoft Information Protection (MIP). This new product consolidates Azure Information Protection (AIP) and Security Retention Labels into one.

Here are a couple of screenshots I took during the sessions I attended.



As you can see from these screenshots that you can apply protection and visual markings to documents from Security and Compliance Center where these features are only available in Azure Information Protection Portal today. For those who have already created labels in Azure Information Protection, no worries, they will automatically synchronize to MIP, so you do not need to recreate them.

Other new features include event based retention where you can associate specific events, e.g. employee termination, contract expiration, etc. when configuring the retention settings.

This screenshot shows the roadmap of what will be available this year and next.


I will continue to share as I learn more about Microsoft Information Protection product.


Classifying and Protecting Data in Office 365

Leave a comment

In my previous post, I introduced how to classify data with Azure Information Protection (AIP). In this post, I’ll introduce how to create a policy / label and additional data classification features you can use to enhance and protect your data.

Creating Azure Information Protection Policy (Label)

You can access Azure Information Portal from the Microsoft Azure Portal. With each AIP label, you can further protect your data by applying any or all of the additional features:

  • Create visual markings (header, footer watermark). Watermarks are applied to Word, Excel, and PowerPoint only.
  • Associate Azure Rights Management (RMS) policies
  • Define conditions that could detect data patterns for automatic classification. Custom conditions can be either words, phrases, patterns, and even regular expressions.

Create New Label: The process of creating a new label is pretty straight forward. You will need to provide a label name, and description. Optionally, you can change the color of the label, and add visual markings such as header, footer, and watermark to the documents.

AIP Visual Markings

In this example, I created a label called ‘Confidential Project’, a footer text of ‘Sensitivity: Confidential’, and added ‘Contoso Confidential’ for its watermark. After the label is saved and published, when the user selects the above label, the document displays as shown in the following image.

AIP Document Visual Marking

Note that visual markings are not applied to documents when the label is applied by using File Explorer and the right-click action, or when a document is classified by using PowerShell.

Associate Azure Rights Management (RMS) Policy: Azure RMS is the protection technology used by Azure Information Protection. Azure RMS allows you to set permissions and automatically applies protection for documents and emails.

You can protect your data within AIP by selecting one of the available options:

  • Do not forward – allows recipients to read the message, but cannot forward, print, or copy content.
  • Select a predefined template – must use PowerShell (New-AadrmRightsDefinition) to create templates for the entire organization
  • Set (custom) permissions

By selecting ‘Set permissions’, you can select users or groups from your tenant. You also have an option to select users or domains from outside your organization, and apply different permissions as necessary.


Define Conditions: Within AIP, you can define one or more conditions within a label. You can select from one of the default conditions or create custom conditions. When a document or email matches the condition associated with the label, you can automatically apply the label to the document or email, or visually show the user a recommendation.

AIP Conditions

These are just a few examples of how you can extend AIP and RMS features to protect your documents and email.

Establishing and maintaining an effective security and information management program involve people, process and technologies working in concert. From the technologies standpoint, IT administrators can start by enforcing rules to ensure documents are classified and protected by using tools available in Office 365.

These are some of the features in Azure Information Protection and Exchange Online. In my next post, I will cover how you can protect your data when sharing with external organizations by integrating the footer information used in this post.


Older Entries