troubleshooting WIP

Troubleshooting Windows Information Protection on Windows 10

Last Updated on December 31, 2023 by Oktay Sari

July 2022

IMPORTANT UPDATE: Microsoft announced the sunset for Windows Information Protection! WIP will be discontinued over time. Support for Windows Information Protection Without Enrollment will end by the end of calendar year 2022. Please read the official announcement and more on the following 2 sites:

If you have plans to implement WIP, I suggest you rethink your strategy accordingly. I will follow-up on this and update the WIP posts I have when more information is released by Microsoft.


Troubleshooting Windows Information Protection can be a lengthy and time consuming process. If all goes according to plan, you can sit back and relax. If not, I hope this post will help you get on the right track again.

There are a couple of other post you might want to read: This post is part of a series.

  1. Introduction to Windows Information Protection
  2. Configuring MDM user scope and MAM user scope
  3. WIP-WE / MAM – Windows Information Protection without enrollment
  4. Windows Information Protection with Enrollment
  5. Windows Information Protection User Experience
  6. WIP-WE User Experience – WIP Without MDM enrollment
  7. Set up Azure Rights Management for WIP
  8. WIP Without Enrollment Selective Wipe
  9. Troubleshooting Windows Information Protection (this post)
  10. Monitoring and collecting WIP audit event logs
  11. WIP Learning mode
  12. Support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE

Troubleshooting Windows Information Protection

There are many things to consider when you start troubleshooting Windows Information Protection (WIP). For enrolled devices (Windows Information Protection With Enrollment) you have more options, logging and control than for devices that are not MDM enrolled. (WIP-WE). It might be helpful to have a couple of test devices at hand to do some fieldwork. Make sure you also read official Microsoft documentation that is available: Limitations while using Windows Information Protection (WIP)

Troubleshooting WIP topics:

  1. Your WIP policy does not apply
  2. You want to limit access to SharePoint or Exchange Online on BYOD
  3. Downloads from SharePoint or OWA in 3rd party browsers are unprotected
  4. You have no internet connection with 3rd party browsers and WIP
  5. File downloads have no WIP protection
    • Files downloaded from SharePoint online are not WIP protected
    • downloads from OneDrive Online are not WIP protected
    • Files downloaded from Word online are not WIP protected
    • Files saved as from Word online or Excel Online are not WIP protected
    • When users download multiple files, WIP protection does not apply.
  6. Personal devices automatically MDM enroll with Intune
  7. WIP-WE does not work without Azure AD registration
    • WIP-WE policies do not apply to BYOD
  8. Office Outlook offline data files (PST and OST files) are not protected
  9. Your RMS template does not apply to your WIP protected devices

Your WIP policy does not apply

Check your MDM and MAM users scopes. Also check the Intune App Protection policy and the assigned groups. Make sure the user is in the included group and not excluded. For WIP-WE make sure the device is Azure AD registered. Without Azure AD registration WIP-WE will not work.

You want to limit access to SharePoint or Exchange Online on BYOD

Check the Microsoft Documentation:

I’ll be writing other blog posts about these topics and in particular discuss the user experience with session control.

Downloads from SharePoint or OWA in 3rd party browsers are unprotected

WIP-WE is great but has it’s limitations. With WIP-WE targeting BYOD you don’t have full control over every app users have installed on their personal devices. With WIP-WE you only have control over enlightened apps. This is important to understand so let it sink in for a moment. Even if you add apps like Chrome or Firefox to your Targeted apps list for WIP-WE, it will do nothing. There is no documentation I could find about this behavior, except for a little text above your Targeted apps that gives a hint.

Only enlightened apps are allowed on devices without MDM

You can’t get Firefox, Chrome or any other unenlightened app to mark files as corporate on a BYOD that is only registered in Azure AD without MDM. Without MDM enrollment, these apps are considered personal only.

To better understand why, let’s have a look at how it works with MDM enrolled devices:

On a corporate device that is MDM enrolled in Intune, you can protect corporate data within most unenlightened apps by adding them to your targeted apps list. When unenlightened apps like Firefox and Chrome are listed as allowed apps, everything you do in these browsers, is considered corporate and protection is applied. So reading your personal e-mail or browsing Facebook with Chrome, is also considered corporate.

Any configuration settings or profiles you have in these browsers are encrypted. When you remove WIP from these devices, you’ll probably have to re-install these targeted applications because encryption can’t be undone completely. That is why Microsoft recommends to only add enlightened apps or any LOB apps.

Back to BYOD and Azure AD registered devices without MDM; When you add app to the list Microsoft has very scarce documentation available but here’s a hint:

These apps are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. Only enlightened apps are allowed on devices without MDM.

You can only use enlightened apps on devices without MDM. If you do decide to MDM enroll BYOD then be aware of the consequences.

On personal devices, you do not want to encrypt everything in unenlightened (targeted) apps. This would ruin the day when users decide to remove Azure AD registration, only to find out that they have to re-install apps they use personally every day.

A possible solution is to combine WIP-WE with DLP, session control and conditional access. If you want users to use Office 365 apps and the OneDrive client on BYOD, WIP-WE is a good solution, but you still have the problem with 3rd party browsers.

Limiting Access to SharePoint Online.

If you combine WIP-WE with DLP by setting restrictions on SharePoint Online browser sessions, you can block downloads in any browser. This still enables users to work online, but only within the browser session. Users cannot download anything from SPO ore ODB. They can still use the OneDrive client to sync their personal folders and since the OneDrive for Business client is an enlightened app, WIP-WE can do its job. SharePoint Online is now in a read-only mode.

Limiting Access to Exchange Online and OWA

The same applies to Exchange online. Use Session control and conditional access to limit access to Exchange Online sessions. This basically limits user access to Exchange online in any browser by blocking download of attachments. Users can still work in Exchange online, but in a read-only mode. They can still open word documents to work with in Word Online, but can’t download documents.

The good thing is, this also blocks any copy/paste actions in browsers, preventing data leaks.

Microsoft Documentation:

Combine WIP-WE with session control and conditional access to provide the best possible work experience on BYOD. I know it’s not a perfect solution and it could have been easier, but it’s something we can work with.

You have no internet connection with 3rd party browsers and WIP

If you find out that after configuring WIP, you can’t use 3rd party browsers to access any internet site, it’s probably because you didn’t configure the /*AppCompat*/ string. Please read the documentation here. If it’s still not working after adding this string, check to see if you copy/pasted any spaces before or after /.

Copy paste without “ marks:

  • “/*AppCompat*/” will work.
  • “/*AppCompat*/ ” will not work! Notice the space after the forward slash /

File downloads from SharePoint or OneDrive have no WIP protection

When you download files from SharePoint Online or Onedrive, check the download URL’s. You’ll see that these URL’s change depending on your location and the download action. The same applies to files you save from Word Online or download as a PDF. The URL’s also change when you download multiple files from SharePoint Online or OneDrive. Here are some examples of problems you may encounter:

  • Files downloaded from SharePoint online are not WIP protected
  • Downloaded from OneDrive Online are not WIP protected
  • Files downloaded from Word online are not WIP protected
  • Files saved as from Word online or Excel Online are not WIP protected
  • When users download multiple files, WIP protection does not apply.

So go ahead and download some files from OneDrive and SharePoint. Then check the download links:

File downloads from SharePoint or OneDrive have no WIP protection

Depending on your location, you’ll  see some of the following URL’s:


Have a look at Office 365 URLs and IP address ranges and in particular sections 39 and 46

Add| to your cloud resources and test again. It this does not solve your problems, you’ll have to add all (sub)domains from sections 39 and 46.

WIP Network boundaries- other MS download location

For your convenience:|||||||||||

Personal devices automatically MDM enroll with Intune

This can be confusing but most of the time there is a logical explanation. If you want to block personal Windows 10 devices from MDM enrolling their devices with Intune, you’ll need to set enrollment restrictions for Windows 10. Please read the MS documentation for more info.

Also have a look at my previous blog about Configuring MDM and MAM user scopes. The Microsoft documentation has updated info so please read it if you run into problems. Check out Set up enrollment for Windows devices. The following text has changed a couple of times since I started troubleshooting Windows Information Protection.

Set up enrollment for Windows devices

WIP-WE does not work without Azure AD registration

WIP-WE will only work when a device is Azure AD registered. When users sign into a Office 365 application, the device will not register by default. This also applies to the checkmark “Allow my organization to manage my device”. If the user removes this checkmark, app protection is not enforced and you’ll have no control over corporate data.

By default, users are not enforced to register their personal devices with Azure AD. They can simply skip this step. Luckily, there is a way to enforce Azure AD registration for BYOD, but this will impact every user you target and on all their devices (personal and corporate).

Azure Active Directory terms of use

By configuring Azure Active Directory terms of use, you can force users to Azure AD register their devices before getting access to corporate data. Depending on how you configure this, you’ll be able to force Azure AD registration on every device.

Please read the official Microsoft documentation for more info and make sure you fully understand the impact:

To configure your terms of use, go to

To require users to accept your terms of use on every device they use to access corporate data, set Require users to consent on every device to On.

Azure AD Terms of Use

As you can read in the highlighted section, the user will be required to register their device in Azure AD prior to getting access. Make sure you target the correct user groups. I suggest you use a dynamic user group, where users have the right subscription assigned. You’ll need a subscription that includes Azure AD Premium P1 (Azure AD Premium P1, P2, EMS E3,EMS E5, M356 E3 or M365 E5).

Office Outlook offline data files (PST and OST files) are not protected

This one bothered me for quite some time.

When performing selective wipe on BYOD (Azure AD registered), the ost file remains on the device. Normally this is not an issue but the file is not WIP protected to start with! This can be a security risk. I did some testing and share my thought here;

  • When I export the Inbox to a PST it is WIP protected no matter where I save the PST file. This is a good thing.
  • I noticed that all files in AppData\Local\Microsoft\Outlook\Offline Address Books\ (.oab files) are WIP protected upon creation, so that’s also good.
  • When a selective wipe is performed, the oab files and pst file show “revoked” as “File Ownership” This is good and I have no access to these files until I add my work account again.

I copied the OST file from a BYOD (azure ad registered/WIP-WE policy applied) to another device and tried to open it using various ost viewers and ost2pst converters but wasn’t able to read or convert. In ost viewers I can see the Mailbox structure and e-mails but everything is scrambled. Some of the ost viewer even gave a error message saying the file was encrypted or corrupted.

To make sure, I copied another ost file from yet another test-device where I have no WIP protection and simply configured a test e-mail account in outlook. This time I can open the file in my ost viewers and convert it to pst without any issues. I can read emails and everything else.

Although there is a user voice for this one, it did not receive many votes so I guess it will stay on the WIP limitations list for a while. Please test this in your own tenant and make sure it works as you expect.


Your RMS template does not apply to your WIP protected devices

Microsoft Azure Rights Management (Azure RMS) helps secure files when users want to share data using removable USB drives. For this to work , you must have Azure Rights Management set up. When Users copy WIP protected files to a USB drive, the protection stays with the data. There’s another blog about Azure Rights Management with WIP you might want to check out. Please note that Label management in the Azure portal and AIP is going to be deprecated by March 31, 2021. If you have already moved to the new unified labeling and migrated labels to the Microsoft 365 compliance center, you are on the right track.

There is one thing you might encounter when you create a unified label and specify the protection template ID for Azure RMS in your WIP policy.


The template ID might not apply or deploy to your devices. First, you have to publish your unified label! If you don’t publish the label, it will not work. Secondly, you’ll have to be patient. It can take up to 24 hours or a little more.

  1. Make sure you have published your unified label
  2. Specify the Azure RMS template ID in your WIP policy
  3. Start a sync on your test device. Go from Settings–>Accounts–>Access work or school.
  4. Create an Advanced Diagnostic Report from within the Account Settings page
  5. Open the MDMDiagReport.html file
  6. Search for RMSTemplateIDForEDP
  7. Check the ID. If it matches the ID you specified in step 2, it’s all good.
  8. Be patient. Wait at least for 24 hours and test again



I hope this post helps you with troubleshooting Windows Information Protection. I’ll update this blog when I have something to share but if you have something you’d like to share, I invite you to share your thoughts and give your feedback below.

5 4 votes
Article Rating

Oktay Sari

#Microsoft365 | #Intune |#MEM | #Security | Father | #Diver | #RC Pilot & #Magician in spare time | Microsoft MVP

Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Newest Most Voted
Inline Feedbacks
View all comments
3 years ago

We know that WIP is designed for one user per device, but we all know that this isn’t always the case in the BYOD world. What are the potential limitations with this scenario? Also, what does the statement “WIP does not support multi-identity, only one managed identity can exist at a time.” actually mean, can you perform an example?


[…] Troubleshooting Windows Information Protection […]

2 years ago

Great article. Short conclusion….. it does not do what it is supposed to do 🙁 It should protect corporare data in every situation. But there are so many exceptions and workarround for users.. it sucks in everey possible way.

Another scenario is that an external hired person brings his own (corporate managed (his own company)) device. You can’t connect to 2 MDM/MAM solutions with one Windows device. So a device registered with another companies MDM is not managable by the other companies MDM.

I think it is a totaly crappy solution.