How to Fix Azure Information Protection Issues

Microsoft Fix Intermediate 14 min read Official Docs Grounded Updated April 20, 2026
What's in This Guide
  1. Why This Is Happening
  2. The Quick Fix
  3. Step-by-Step Solution
  4. Advanced Troubleshooting
  5. Prevention & Best Practices
  6. FAQ

Why This Is Happening

You opened Word, looked for the sensitivity bar, and it's just... gone. Or maybe your IT admin pushed an Azure Information Protection policy and now half your users are getting errors when they try to open protected emails. Or you're staring at a PowerShell window watching an AD RMS migration hang at the key import step. I've seen all of these , and the frustrating thing is that Microsoft's own error messages rarely tell you which layer of the stack actually broke.

Here's the core thing you need to understand: Azure Information Protection as a standalone add-in is retired. That's not a rumor , Microsoft made it official. The classic AIP add-in for Office apps has been replaced by sensitivity labels built directly into Microsoft 365 apps and services. If you're still deploying the old AIP add-in via Group Policy or an MSI, that's your problem right there. The world moved to Microsoft Purview Information Protection, and the AIP add-in didn't come with it.

That said, the underlying engine, the Azure Rights Management service (Azure RMS), is still very much alive and kicking. Azure RMS is the encryption backbone for everything: sensitivity labels, the Microsoft Purview Information Protection client, the MIP SDK, and the Purview scanner. When people say "AIP is broken," they usually mean one of four things:

  • The old AIP Office add-in disappeared or stopped working after a Microsoft 365 update
  • The Azure Rights Management service wasn't activated before applying labels
  • An AD RMS migration to Azure Information Protection hit a prerequisite wall
  • A third-party app using the MIP SDK lost its authentication to the protection service

The error messages don't help. You'll see things like "Your organization's policies do not allow you to share with these users" or a silent failure where labels simply don't appear in the ribbon. Windows Event Viewer ID 6151 and 6152 under the Microsoft-Windows-Rights-Management-Client-UI log are your first clue something is wrong at the RMS layer. Event ID 1000 under the AIP client log at Applications and Services Logs > Microsoft > AzureInformationProtection points to client-side failures.

The fix depends entirely on which layer broke. This guide walks through each one, from the five-minute Office-side fix to full AD RMS migration recovery. Browse all Microsoft fix guides →

The Quick Fix, Try This First

If you're an end user and the Azure Information Protection sensitivity bar or labels have vanished from your Office apps, the fastest path forward is switching from the retired AIP add-in to the built-in sensitivity label experience in Microsoft 365. This resolves the problem in under five minutes for the vast majority of cases.

Open any Office app, Word, Excel, or Outlook works. Go to File > Options > Add-ins. In the Manage dropdown at the bottom, select COM Add-ins and click Go. Look for an entry named Azure Information Protection or Microsoft Azure Information Protection. If it's there and checked, uncheck it and click OK. Restart the Office app.

Now check whether sensitivity labels appear natively in the ribbon under the Home tab. In Word and Excel you'll see a Sensitivity button. In Outlook it appears in the message composition toolbar. If your admin has deployed labels through the Microsoft Purview compliance portal, they'll show up here automatically, no add-in needed.

If the built-in Sensitivity button doesn't appear after removing the old add-in, your admin may not have published a label policy to your account yet, or your Microsoft 365 subscription may not include the Information Protection features. Ask your IT admin to verify that a sensitivity label policy is assigned to your user account in the Microsoft Purview compliance portal at compliance.microsoft.com under Information Protection > Label policies.

For admins: if you're managing a fleet of machines and the old add-in is being pushed via a registry key, check and remove this key from affected machines:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Word\Addins\MSIP.WordAddin
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\Outlook\Addins\MSIP.OutlookAddin

Removing these entries stops Office from loading the retired add-in and lets the built-in label experience take over cleanly.

Pro Tip
If you're managing this across an enterprise and Office apps keep re-enabling the old AIP add-in after your users remove it, check your Group Policy for a setting under User Configuration > Administrative Templates > Microsoft Office [version] > Security Settings > Trust Center. A "List of managed add-ins" GPO entry can force the old add-in back on. Removing that GPO entry fixes the problem at the source rather than playing whack-a-mole per machine.
1
Verify Azure Rights Management Service Activation

This is the step that catches most admins off guard. You can have labels configured, policies published, and the right licenses assigned, and protection still won't work if the Azure Rights Management service isn't activated in your tenant. The Azure RMS service is what actually encrypts content when a sensitivity label with protection is applied.

To check activation status, open PowerShell and connect to the AIPService module:

Install-Module -Name AIPService
Connect-AipService
Get-AipService

You're looking for the output Enabled. If it says Disabled, run:

Enable-AipService

Wait two to five minutes for the change to propagate, then run Get-AipService again to confirm. One important note from the migration documentation: if you're in the middle of an AD RMS to Azure Information Protection migration, Microsoft explicitly recommends not activating the Rights Management service before you've exported your AD RMS keys and templates. Activating too early during a migration means users start encrypting new content with the Azure RMS key before the old AD RMS content is properly migrated, that creates a situation where some content can't be decrypted at all.

If activation fails with an authorization error, make sure the account running the command has the Global Administrator or Information Protection Administrator role in Microsoft Entra ID. The built-in Rights Management Administrator role in Entra ID is sufficient for this specific operation.

When it's working correctly, a user applying a protection label in Word will see the document marked with the label and the file will be encrypted when saved. The title bar will show the label name.

2
Install and Configure the Microsoft Purview Information Protection Client

If your users need features beyond what's built into Office, like protecting files from File Explorer, applying labels to PDFs outside of Office, or running the Purview scanner on file shares, you need the Microsoft Purview Information Protection client. This is the current replacement for the old AIP unified labeling client. The add-in-free version is generally available, meaning it installs without injecting itself into Office apps.

Download the client from the Microsoft Download Center. The installer package is named PurviewInformationProtection.exe. For a silent enterprise deployment:

PurviewInformationProtection.exe /install /quiet /norestart

After installation, verify it's registered correctly by checking:

Get-Module -ListAvailable PurviewInformationProtection

The client installs a right-click context menu option in File Explorer called Show Sensitivity, which lets users apply labels to files directly without opening them. It also enables the Purview Information Protection Viewer, which is what you need when a user tries to open a protected file without a Microsoft 365 app, for example, a .ptxt or .pjpg protected file.

If users report that right-click labeling options don't appear after installation, check whether the shell extension registered correctly. Open a command prompt as administrator and run:

regsvr32 "C:\Program Files (x86)\Microsoft Azure Information Protection\MSIP.ShellExt.dll"

A successful registration dialog confirms the shell extension is active. Log out and log back in for the context menu to appear. If it still doesn't show, Explorer may need a restart via Task Manager.

3
Fix Sensitivity Label Policies Not Appearing for Users

This one burns hours if you don't know where to look. An admin creates beautiful sensitivity labels in the Purview compliance portal, publishes a policy, and users still don't see them. Nine times out of ten, the issue is scope: the label policy wasn't assigned to the right users or groups.

Go to compliance.microsoft.com and navigate to Information Protection > Label policies. Click on the policy in question. Under Assign admin units and the Users and groups setting, verify that your user's account or their security group is listed. If you see "All" listed and users still don't see labels, the policy replication delay might be the issue, it can take up to 24 hours for a newly published policy to propagate to all clients.

To force a client to pull the latest policy immediately, run this in an elevated PowerShell window on the affected user's machine:

Start-Process -FilePath "C:\Program Files (x86)\Microsoft Azure Information Protection\msip.exe" -ArgumentList "/resetpolicy" -Wait

Alternatively, if the Purview client is installed, users can open any Office app, go to Sensitivity > Help and Feedback, and click Reset Settings. This forces a fresh policy download on the next Office launch.

Also check whether the user's license includes the Azure Information Protection P1 or P2 plan, or whether they have a Microsoft 365 Business Premium, E3, or E5 subscription that includes it. Without a valid license, the policy won't be delivered to that user even if they're in the assigned group. You can verify license assignment in the Microsoft 365 admin center under Users > Active users > [user] > Licenses and apps.

4
Resolve AD RMS to Azure Information Protection Migration Errors

If your organization is migrating from Active Directory Rights Management Services to Azure Information Protection, there are hard prerequisites that will stop you cold if they're not in place. I've seen migrations fail at the very last step, key import, because someone skipped checking supported OS versions.

Your AD RMS servers must be running one of these: Windows Server 2012 (x64), Windows Server 2012 R2 (x64), or Windows Server 2016 (x64). That's it. If you're on Server 2008 R2, you have to upgrade the AD RMS role to a supported OS before attempting the migration, there's no workaround.

For the key export step, you'll export your AD RMS cluster key as a Trusted Publishing Domain (TPD) file. Before doing this, configure your clients with registry settings that point to Azure Information Protection instead of the AD RMS SCP, because service discovery order goes: registry first, then SCP, then cloud. While the SCP still exists pointing to your old AD RMS cluster, you must override it per client via this registry path:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\ServiceLocation\EnterpriseCertification
Value: REG_SZ
Data: https://[your-tenant].aadrm.com/_wmcs/certification

If the key import to Azure Information Protection fails with a permissions error, verify that the account performing the import has the Global Administrator role and that the AIPService module command being used is:

Import-AipServiceTpd -TpdFile "C:\migration\exported.xml" -ProtectionPassword (Read-Host -AsSecureString)

One critical rule: a key from one AD RMS cluster can only be imported to one Azure Information Protection tenant. If you have multiple forests with multiple RMS clusters and want separate Azure tenants, treat each as a completely independent migration. Mixing keys across tenants is not supported and will break decryption for affected content.

5
Fix MIP SDK Authentication and Protection Failures

If you're a developer integrating the Microsoft Information Protection SDK into a line-of-business app, a CAD/CAM tool, a DLP solution, or a cloud access security broker, and protection operations are suddenly failing, authentication is the usual culprit. The MIP SDK authenticates against Microsoft Entra ID to get a token for the Azure Rights Management service, and that flow can break in several ways.

First, check that your Entra ID app registration has the correct API permissions. The MIP SDK requires the Azure Rights Management Services permission user_impersonation under delegated permissions, or Content.DelegatedWriter and Content.Writer for application permissions depending on your auth flow. Missing these permissions causes silent failures or MIPNET_ERROR_AUTHENTICATION errors in your SDK logs.

Enable MIP SDK diagnostic logging to get real error details. In your app initialization code, set the log level to Debug and point the log output path to a writable directory. The SDK writes verbose logs that include the exact Entra ID token request that's failing, which tells you whether it's a scope mismatch, a consent issue, or an expired secret.

For apps using the SDK to reason over data encrypted with Azure Information Protection, for example, a DLP solution scanning protected files, make sure the service principal has been granted super user access in the AIPService module:

Add-AipServiceSuperUser -ServicePrincipalId "[your-app-object-id]"
Enable-AipServiceSuperUserFeature

Without super user access, the SDK can authenticate successfully but still fail to decrypt content for inspection. You'll see HTTP 403 responses from the RMS endpoint even when the token is valid. The super user feature must be explicitly enabled at the tenant level, it's off by default for good security reasons, before individual service principals can be added to it.

Advanced Troubleshooting

When the standard fixes don't land, you need to dig into the infrastructure layer. Here's how to approach Azure Information Protection problems in domain-joined enterprise environments.

Event Viewer Analysis

The AIP client writes detailed logs to a dedicated channel. Open Event Viewer and navigate to Applications and Services Logs > Microsoft > AzureInformationProtection. The most useful event IDs to filter for are:

  • Event ID 1001, successful policy download from the Purview service
  • Event ID 1002, policy download failed (look at the description for HTTP error codes)
  • Event ID 2001, label applied successfully
  • Event ID 3001, protection operation failed (usually an Azure RMS connectivity or auth issue)

For RMS-layer errors, also check Applications and Services Logs > Microsoft > Windows > Rights-Management-Client. Event IDs 6151 and 6152 here indicate the RMS client couldn't reach the Azure RMS endpoint, usually a network or firewall issue.

Group Policy Conflicts

In large enterprises, Group Policy can interfere with Azure Information Protection in ways that are hard to spot. The most common conflict is a GPO that enforces the old AIP add-in as a managed COM add-in via the registry path:

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\[appname]\Resiliency\DoNotDisableAddinList

When this key forces the AIP add-in to always load, and the add-in is retired, Office enters a loop trying to load a broken COM component. Run gpresult /h C:\gpresult.html on an affected machine, open the report, and search for any policy referencing MSIP or AzureInformationProtection under the Office add-in settings.

Network and Firewall Prerequisites

The Azure Rights Management service requires outbound HTTPS access to specific Microsoft endpoints. If your firewall blocks these, protection operations fail silently. Required endpoints include:

*.aadrm.com (TCP 443)
*.azurerms.com (TCP 443)
*.informationprotection.azure.com (TCP 443)
login.microsoftonline.com (TCP 443)

For organizations using the RMS connector to protect on-premises content from Exchange or SharePoint Server, the connector server itself needs bidirectional HTTPS access to both the Azure RMS service and your internal Exchange/SharePoint servers.

Bring Your Own Key (BYOK) Issues

If your organization manages its own Azure Information Protection tenant root key through BYOK, storing the key in Azure Key Vault instead of letting Microsoft manage it, key rotation or access policy changes in Key Vault can break the entire protection service. If protection suddenly stops working across your whole tenant after a key vault change, check the Key Vault access policy and confirm that the Azure Rights Management service principal still has Get, WrapKey, and UnwrapKey permissions.

When to Call Microsoft Support
If your Azure Rights Management service shows as enabled but protection operations are failing tenant-wide, you've confirmed firewall rules allow the required endpoints, and Event Viewer shows successful authentication but failed protection calls, that points to a backend service issue you cannot fix yourself. Also escalate if key import during an AD RMS migration fails after verifying all prerequisites, or if you suspect tenant-level corruption in your Rights Management configuration. Open a support ticket at Microsoft Support and include your tenant ID, the full error text from Event Viewer, and the output of Get-AipServiceConfiguration, that PowerShell command dumps your full tenant AIP configuration and saves time during the support call.

Prevention & Best Practices

The best Azure Information Protection problems are the ones you never have. Most of the painful issues I see in enterprise environments come from not tracking the product lifecycle and letting deprecated components quietly accumulate.

First: get off the retired AIP add-in now if you haven't already. Microsoft has documented this clearly, the add-in is out, and the built-in label experience in Microsoft 365 is its replacement. Every month you keep the old add-in deployed via GPO is a month where an Office update can break it again. The migration to built-in labels is straightforward: publish your existing label policy through the Purview compliance portal and confirm users see labels in the native Office ribbon. Done.

Second: keep a test user or test group that gets label policy changes before your full user base. When you modify sensitivity labels or protection settings in the Purview compliance portal, publish the updated policy to a pilot group first. Give it 24 hours to propagate, validate that the expected labels appear and that protected content opens correctly, then extend to your full organization. Skipping this step is how protection breaks for 10,000 users at once on a Monday morning.

Third: document your Azure Rights Management key management choice and review it annually. Whether you use Microsoft-managed keys or BYOK, write down what you chose, where the key lives, and who has access to Key Vault. Key management decisions made during initial setup often aren't documented, and when the person who made the choice leaves, no one knows why certain Key Vault permissions exist or whether they can be changed.

Fourth: if you're running the Purview Information Protection scanner on file shares or SharePoint Server, review the scanner's service account permissions quarterly. The scanner service account needs specific rights on the repositories it scans, and those permissions tend to erode as file server admins rotate service account passwords or tighten ACLs without realizing the scanner depends on them.

Quick Wins

Frequently Asked Questions

What exactly is Azure Information Protection and how does it relate to Microsoft Purview?

Azure Information Protection is the umbrella service that provides the Azure Rights Management encryption technology used across Microsoft's information protection products. The old AIP add-in for Office is retired, but AIP as a service is still the engine behind everything. Microsoft Purview Information Protection is the modern brand that sits on top of Azure Information Protection, it includes sensitivity labels, the Purview client, the scanner, and the MIP SDK. Think of Azure Information Protection as the engine and Microsoft Purview Information Protection as the car. You interact with the car, but the engine is what makes protection work. If you're looking for the Purview compliance portal, go to compliance.microsoft.com, that's where all the modern label and policy management lives now.

The Azure Information Protection bar is gone from my Office apps, how do I get it back?

The AIP bar tied to the old add-in is gone for good, Microsoft retired the add-in. What replaces it is the built-in Sensitivity button in the Home ribbon of Word, Excel, PowerPoint, and Outlook. If you're not seeing that button, check two things: first, confirm your admin has published a sensitivity label policy that includes your account in the Microsoft Purview compliance portal. Second, check whether a Group Policy is forcing the old AIP COM add-in to load, which can block the native experience from initializing. Removing the old add-in via File > Options > Add-ins > COM Add-ins and then restarting Office usually brings the native Sensitivity button into view within a minute.

How do I migrate from AD RMS to Azure Information Protection without losing access to old protected content?

The migration path is well-defined but has strict prerequisites: your AD RMS servers must be on Windows Server 2012, 2012 R2, or 2016 (x64). You export your AD RMS cluster key as a Trusted Publishing Domain file and import it into your Azure Information Protection tenant using the Import-AipServiceTpd PowerShell cmdlet, this is what preserves the ability to decrypt old AD RMS-protected content after migration. Crucially, Microsoft recommends keeping the Azure Rights Management service deactivated until after you've completed the key import, because activating it too early means new content gets encrypted with a key your old clients can't use yet. After import and activation, users can still open legacy AD RMS-protected documents because the old key is now registered in Azure.

Why can't my users open protected emails or documents, they just get a permissions error?

A few things cause this. Most commonly, the user's account isn't included in the protection policy that was applied when the content was protected, this is an access control issue, not a software bug, and the content owner or an admin with super user access needs to re-protect the file with broader permissions. Second possibility: the Azure Rights Management service got deactivated, which stops all protection operations tenant-wide. Run Get-AipService in PowerShell and check the output. Third: if the content was protected using an AD RMS cluster and you've migrated to Azure, but the old AD RMS key wasn't imported correctly, decryption will fail. Check Event Viewer under the Rights-Management-Client log for event IDs 6151 or 6152 to confirm which scenario you're in.

What's the Microsoft Information Protection SDK and do I need it?

The MIP SDK is a developer toolkit that lets you build Azure Information Protection labeling and protection directly into third-party apps and services, things like line-of-business applications that need to tag files on export, CAD tools, or data loss prevention solutions that inspect encrypted content. If you're an end user or IT admin managing labels and policies, you don't need the SDK, that's for developers extending the platform. If you're a developer whose app needs to apply sensitivity labels to files, read the classification of protected content, or reason over encrypted data, the MIP SDK is what gives your app access to the Azure Rights Management service. It's available for C++, .NET, Java, and Python, with the C++ API being the most feature-complete reference implementation.

How do I use Azure Information Protection to protect PDFs, does it work with Adobe Acrobat?

Yes, AIP-protected PDFs work with Adobe Acrobat Reader, but there's a specific setup required. Microsoft's official documentation calls out that the Purview Information Protection client handles PDF protection using the ISO standard for PDF encryption (not the older PPDF format). When you apply a sensitivity label with protection to a PDF through the Purview client's File Explorer integration, the resulting file stays as a .pdf but is encrypted using Azure Rights Management. To open it, recipients need either the Purview Information Protection Viewer or an Adobe Acrobat Reader with the Azure Information Protection plugin installed, that plugin is available from the Adobe marketplace and integrates directly with the Azure RMS service to decrypt the file on open. For newer versions of Acrobat Reader (DC 2020 and later), the plugin experience is significantly smoother than it was in earlier versions.

Related Microsoft Fix Guides

Microsoft Fix
How to Fix Windows Update Errors (Error 0x80070003 & More)
Microsoft Fix
Fix Microsoft 365 Sign-In Problems, Complete Guide
Microsoft Fix
Azure Active Directory Troubleshooting Guide
Browse All
5,000+ Microsoft Fix Guides →
H
Sai Kiran Pandrala
Our team includes certified Microsoft engineers, Azure architects, and system administrators with 10+ years of enterprise IT experience. Every guide is written from hands-on troubleshooting, not guesswork. We test every fix before publishing.