Frequently asked questions for the Azure Information Protection classic client

When is the right time to migrate my labels to unified labeling?

We recommend that you migrate your Azure Information Protection labels to the unified labeling platform so that you can use them as sensitivity labels with other clients and services that support unified labeling.

For more information and instructions, see How to migrate Azure Information Protection labels to unified sensitivity labels.

Do I need to re-encrypt my files after moving to sensitivity labels and the unified labeling platform?

No, you don’t need to re-encrypt your files after moving to sensitivity labels and the unified labeling platform after migrating from the AIP classic client and the labels managed in the Azure portal.

After migrating, manage your labels and labeling policies from the Microsoft 365 compliance center.

For more information, see Learn about sensitivity labels in the Microsoft 365 documentation and the Understanding unified labeling migration blog.

What's the difference between labels in Microsoft 365 and labels in Azure Information Protection?

Originally, Microsoft 365 had only retention labels, which enabled you to classify documents and emails for auditing and retention when that content was stored in Microsoft 365 services.

In contrast, Azure Information Protection labels, configured at the time using the AIP classic client in the Azure portal, enabled you to apply a consistent classification and protection policy for documents and emails whether they were stored on-premises or in the cloud.

Microsoft 365 supports sensitivity labels in addition to retention labels. Sensitivity labels can be created and configured in the Microsoft 365 compliance center.

If you have legacy AIP labels configured in the Azure portal, we recommend migrating them to sensitivity labels and unified labeling client. For more information, see Tutorial: Migrating from the Azure Information Protection (AIP) classic client to the unified labeling client.

For more information, see Announcing availability of information protection capabilities to help protect your sensitive data.

Is the Azure Information Protection client only for subscriptions that include classification and labeling?

No. The classic AIP client can also be used with subscriptions that include just the Azure Rights Management service, for data protection only.

When the classic client is installed without an Azure Information Protection policy, the client automatically operates in protection-only mode, which enables users to apply Rights Management templates and custom permissions.

If you later purchase a subscription that does include classification and labeling, the client automatically switches to standard mode when it downloads the Azure Information Protection policy.

Setting Rights Management owners

By default, for both Windows Server FCI and the Azure Information Protection scanner, the Rights Management owner is set to the account that protects the file.

Override the default settings as follows:

  • Windows Server FCI: Set the Rights Management owner to be a single account for all files, or dynamically set the Rights Management owner for each file.

    To dynamically set the Rights Management owner, use the -OwnerMail [Source File Owner Email] parameter and value. This configuration retrieves the user's email address from Active Directory by using the user account name in the file's Owner property.

  • Azure Information Protection scanner: For newly protected files, set the Rights Management owner to be a single account for all files on a specified data store, by specifying the -Default owner setting in the scanner profile.

    Dynamically setting the Rights Management owner for each file is not supported, and the Rights Management owner is not changed for previously protected files.

    Note

    When the scanner protects files on SharePoint sites and libraries, the Rights Management owner is dynamically set for each file by using the SharePoint Editor value.

Can a file have more than one classification?

Users can select just one label at a time for each document or email, which often results in just one classification. However, if users select a sublabel, this actually applies two labels at the same time; a primary label and a secondary label. By using sublabels, a file can have two classifications that denote a parent\child relationship for an additional level of control.

For example, the label Confidential might contain sublabels such as Legal and Finance. You can apply different classification visual markings and different Rights Management templates to these sublabels. A user cannot select the Confidential label by itself; only one of its sublabels, such as Legal. As a result, the label that they see set is Confidential \ Legal. The metadata for that file includes one custom text property for Confidential, one custom text property for Legal, and another that contains both values (Confidential Legal).

When you use sublabels, don't configure visual markings, protection, and conditions at the primary label. When you use sublevels, configure these setting on the sublabel only. If you configure these settings on the primary label and its sublabel, the settings at the sublabel take precedence.

How do I prevent somebody from removing or changing a label?

Although there's a policy setting that requires users to state why they are lowering a classification label, removing a label, or removing protection, this setting does not prevent these actions. To prevent users from removing or changing a label, the content must already be protected and the protection permissions do not grant the user the Export or Full Control usage right

How can DLP solutions and other applications integrate with Azure Information Protection?

Because Azure Information Protection uses persistent metadata for classification, which includes a clear-text label, this information can be read by DLP solutions and other applications.

For more information about this metadata, see Label information stored in emails and documents.

For examples of using this metadata with Exchange Online mail flow rules, see Configuring Exchange Online mail flow rules for Azure Information Protection labels.

Can I create a document template that automatically includes the classification?

Yes. You can configure a label to apply a header or footer that includes the label name. But if that doesn't meet your requirements, for the Azure Information Protection classic client only, you can create a document template that has the formatting you want and add the classification as a field code.

As an example, you might have a table in your document's header that displays the classification. Or, you use specific wording for an introduction that references the document's classification.

To add this field code in your document:

  1. Label the document and save it. This action creates new metadata fields that you can now use for your field code.

  2. In the document, position the cursor where you want to add the label's classification and then, from the Insert tab, select Text > Quick Parts > Field.

  3. In the Field dialog box, from the Categories dropdown, select Document Information. Then, from the Fields names dropdown, select DocProperty.

  4. From the Property dropdown, select Sensitivity, and select OK.

The current label's classification is displayed in the document and this value will be refreshed automatically whenever you open the document or use the template. So if the label changes, the classification that is displayed for this field code is automatically updated in the document.

How is classification for emails using Azure Information Protection different from Exchange message classification?

Exchange message classification is an older feature that can classify emails and it is implemented independently from Azure Information Protection labels or sensitivity labels that apply classification.

However, you can integrate this older feature with labels, so that when users classify an email by using Outlook on the web and by using some mobile mail applications, the label classification and corresponding label markings are automatically added.

You can use this same technique to use your labels with Outlook on the web and these mobile mail applications.

Note that there's no need to do this if you're using Outlook on the web with Exchange Online, because this combination supports built-in labeling when you publish sensitivity labels from the Microsoft 365 compliance center.

If you cannot use built-in labeling with Outlook on the web, see the configuration steps for this workaround: Integration with the legacy Exchange message classification

How do I configure a Mac computer to protect and track documents?

First, make sure that you have installed Office for Mac by using the software installation link from https://admin.microsoft.com. For full instructions, see Download and install or reinstall Microsoft 365 or Office 2019 on a PC or Mac.

Open Outlook and create a profile by using your Microsoft 365 work or school account. Then, create a new message and do the following to configure Office so that it can protect documents and emails by using the Azure Rights Management service:

  1. In the new message, on the Options tab, click Permissions, and then click Verify Credentials.

  2. When prompted, specify your Microsoft 365 work or school account details again, and select Sign in.

    This downloads the Azure Rights Management templates and Verify Credentials is now replaced with options that include No Restrictions, Do Not Forward, and any Azure Rights Management templates that are published for your tenant. You can now cancel this new message.

To protect an email message or a document: On the Options tab, click Permissions and choose an option or template that protects your email or document.

To track a document after you have protected it: From a Windows computer that has the Azure Information Protection classic client installed, register the document with the document tracking site by using either an Office application or File Explorer. For instructions, see Track and revoke your documents. From your Mac computer, you can now use your web browser to go to the document tracking site (https://track.azurerms.com) to track and revoke this document.

When I test revocation in the document tracking site, I see a message that says people can still access the document for up to 30 days—is this time period configurable?

Yes. This message reflects the use license for that specific file.

If you revoke a file, that action can be enforced only when the user authenticates to the Azure Rights Management service. So if a file has a use license validity period of 30 days and the user has already opened the document, that user continues to have access to the document for the duration of the use license. When the use license expires, the user must reauthenticate, at which point the user is denied access because the document is now revoked.

The user who protected the document, the Rights Management issuer is exempt from this revocation and is always able to access their documents.

The default value for the use license validity period for a tenant is 30 days and this setting can be overridden by a more restrictive setting in a label or template. For more information about the use license and how to configure it, see the Rights Management use license documentation.

What's the difference between BYOK and HYOK and when should I use them?

Bring your own key (BYOK) in the context of Azure Information Protection, is when you create your own key on-premises for Azure Rights Management protection. You then transfer that key to a hardware security module (HSM) in Azure Key Vault where you continue to own and manage your key. If you didn't do this, Azure Rights Management protection would use a key that is automatically created and managed for you in Azure. This default configuration is referred to as "Microsoft-managed" rather than "customer-managed" (the BYOK option).

For more information about BYOK and whether you should choose this key topology for your organization, see Planning and implementing your Azure Information Protection tenant key.

Hold your own key (HYOK) in the context of Azure Information Protection, is for a few organizations that have a subset of documents or emails that cannot be protected by a key that is stored in the cloud. For these organizations, this restriction applies even if they created the key and manage it, using BYOK. The restriction can often be because of regulatory or compliance reasons and the HYOK configuration should be applied to "Top Secret" information only, that will never be shared outside the organization, will only be consumed on the internal network, and does not need to be accessed from mobile devices.

For these exceptions (typically less than 10% of all the content that needs to be protected), organizations can use an on-premises solution, Active Directory Rights Management Services, to create the key that remains on-premises. With this solution, computers get their Azure Information Protection policy from the cloud, but this identified content can be protected by using the on-premises key.

For more information about HYOK and to make sure that you understand its limitations and restrictions, and guidance when to use it, see Hold your own key (HYOK) requirements and restrictions for AD RMS protection.

What do I do if my question isn't here?

First, review the frequently asked questions listed below, which are specific to classification and labeling, or specific to data protection. The Azure Rights Management service (Azure RMS) provides the data protection technology for Azure Information Protection. Azure RMS can be used with classification and labeling, or by itself.

If your question isn't answered, see the links and resources listed in Information and support for Azure Information Protection.

In addition, there are FAQs designed for end users: