Complete Checklist To Troubleshoot Intune WIP Issues For Absolute Beginners!

2
WIP Troubleshooting Checklist - LearnWIPwithJoy

This is a bonus article to round off the “Learn WIP with Joy” series. I hope you have read the articles from this series as listed below.

  1. Windows Information Protection | WIP Learn with Joy Part #1 | Intune
  2. Windows Information Protection WIP Deep Dive | Internals with Joy Part 2
  3. Learn WIP with Joy – File Protection Deep Dive – Part 3

Haven’t read them yet! You can always bookmark the links to read them at your leisure.

When you enforce Windows information Protection policy on your Windows workstations, various issues may arise like (not limited to) application stops working or does not works as expected when it is either working with corporate tagged data on the device or corporate identified resource in the policy.

Today, in this article, I will be talking about the general approach an Intune Admin should follow in order to troubleshoot any issues arising related to the enforcement of Windows Information Protection. This article is a complete checklist to troubleshoot Intune WIP poliies for absolute begineers!

The article is structured in two parts as shown below

  • Checking WIP policy state on endpoint – Basic, Intermediate and Advanced checks
  • Checking WIP related issues with applications

So let’s get started.

Check Intune WIP policy state and settings at device end

When we are checking the policy state on an endpoint, the 1st step is obvious to check if the device has recieved the policy from Intune.

Confirm that device has received the Intune WIP policy – Basic Check

Check from Settings > Accounts > Access work or school and from there, check the Info of the connected Work Account. If the managed policies overview shows DataProtection, Search and NetworkIsolation, then Intune has sent the WIP policy successfully to the device.

WIP Troubleshooting Checklist - Check Work Account Info to confirm if device recieced WIP policy from Intune
WIP Troubleshooting Checklist – Check Work Account Info to confirm if device recieced WIP policy from Intune

You can further generate an MDM diagnostic report to check the settings that has been delivered by viewing the exported HTML report.

Listing of the Intune WIP policy settings area above confirms the policy delivery from Intune. Once the policy settings has been delivered, scope of Intune ends.

It is then the responsibility of the corresponding CSPs (EnterpriseDataProtection CSP, AppLocker CSP and Policy CSP) which the OMA-DM client will invoke to get the settings implemented on the device as delivered.

Confirm the EDP State Change – Intermediate Check

As you have confirmed the policy delivery from Intune, now you should check if the Intune WIP policy got successfully implemented or not. If yes, the EDP state of the device will change.

Confirm EDP state of the device by having a look into the registry

Path:  HKLM\SOFTWARE\Microsoft\Provisioning\Evaluator\PostProcess\EDP

WIP Troubleshooting Checklist - Check registry to confirm present EDP state of device.
WIP Troubleshooting Checklist – Check registry to confirm present EDP state of device.

If there is any issues related to the implementation, for example, the policy has been delivered, however EDP enforcement failed and you see that EDP state is Off – it is essentially under the troubleshooting scope of Windows and not Intune.

If you face an error like above,  you can however check through the DeviceManagement-Enterprise-Diagnostics-Provider Admin events.

EDP enforcement on an endpoint has a few mandatory settings which must be configured for effecting the change in device EDP state

  • EDPEnforcementLevel in EnterpriseDataProtection CSP must be set
  • EnterpriseProtectedDomainNames in EnterpriseDataProtection CSP must be set
  • NetworkIsolation in Policy CSP must be set
  • AppLocker CSP

These dependencies are relevant if your MDM solution does not have an UI to configure WIP policy and you have to resort to custom OMA-URI to deliver the policy settings.

With Intune however, the dependencies will always be met as it has GUI to configure the WIP policy settings and as such it is impossible to miss the requirements.

In general, you will see the Intune WIP policy settings getting implemented via Event IDs 813 and 814

Event ID 813
 
MDM PolicyManager: Set policy int, Policy: (EDPEnforcementLevel), Area:
(DataProtection), EnrollmentID requesting merge: (2C81E4D2-6C11-446D-B046-
B215C989CB57), Current User: (Device), Int: (0x3), Enrollment Type: (0x6), Scope:
(0x0).
 
Event ID 814
 
MDM PolicyManager: Set policy string, Policy: (EnterpriseProtectedDomainNames), Area:
(DataProtection), EnrollmentID requesting merge: (2C81E4D2-6C11-446D-B046-
B215C989CB57), Current User: (Device), String: (joymalya.xyz), Enrollment Type:
(0x6), Scope: (0x0).
 
MDM PolicyManager: Set policy string, Policy: (EnterpriseCloudResources), Area:
(NetworkIsolation), EnrollmentID requesting merge: (2C81E4D2-6C11-446D-B046-
B215C989CB57), Current User: (Device), String: (blueear.sharepoint.com|
blueear-my.sharepoint.com|/*AppCompat*/), Enrollment Type: (0x6), Scope: (0x0).

The Event ID 1651 is related to the EDP dependency check and once the policy settings are implemented, you would see the below

Event ID 1651
 
Windows Information Protection dependency check result: Dependency Name: (EDPPolicy),
State: (EdpOff), IsDependencySatisfied: (0x1), Result: (0x1).

Windows Information Protection dependency check result: Dependency Name: (AppLocker),
State: (EdpOff), IsDependencySatisfied: (0x1), Result: (0x1)

If the dependencies are met (1=True), you will see the EDP state being changed as shown below (any changes to EDP state is via Event ID 1653)

Event ID 1653

MDM Evaluator Scenario Evaluate Result: Scenario: (EDP), Previous State: (EdpOff),
Last Dependency: (NULL), Final State: (EdpOn), Result: (The operation completed
successfully.).

If the device has Direct Access enabled, WIP policy may get implemented partially, in the sense AppLocker files and NetworkIsolation properties will get effected in the registry, but EDPEnforcementLevel will fail and thereby the EDP state will not change from current value. You will get an error Event for the same Event ID 404 with win32 error code 0x807c0003

Direct Access is not supported with Windows Information Protection. Check Microsoft document for WIP limitations.

Confirm implemented policy settings from Registry – Advanced Check

To check the Intune WIP policy settings as implemented, look into the registry at below path HKLM\SOFTWARE\Microsoft\PolicyManager\current\device

  • DataProtection node contains the EDP settings
  • NetworkIsolation node contains the configured EDP resources (Cloud resource, Network Boundaries)
  • Search node contains the EDP settings for Windows Search
WIP Troubleshooting Checklist - Check registry to confirm present EDP settings
WIP Troubleshooting Checklist – Check registry to confirm present EDP settings

The reg_path HKLM\SOFTWARE\Microsoft\EnterpriseDataProtection\Policies gives you a view of whether user is allowed to decrypt protected files and the EDP enforcement level

WIP Troubleshooting Checklist - Check registry to confirm present EDP enforcement level (Blocked, Allow Override or Silent)
WIP Troubleshooting Checklist – Check registry to confirm present EDP enforcement level (Blocked, Allow Override or Silent)

EDP enforcement level values are predefined in the enum EnforcementLevel of Windows.Security.EnterpriseData namespace

namespace Windows
{
    namespace Security
    {
        namespace EnterpriseData
         {
             enum EnforcementLevel
                   {
                        NoProtection = 0,
                        Silent       = 1,
                        Override     = 2,
                        Block        = 3
                    };

Reg_path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\AppID\Configuration\EDP shows the

  • DataContext – the corporate identity to which local data identified as corporate will be tagged to.
  • EnforcementLevel

Reg_path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntfs\EFS\Parameters shows

  • EdpExcludedExtensions – file extensions which are excluded from WIP by default
  • EdpExcludedPaths – paths which are excluded by default

EDP enforcement on an endpoint disables anonymous access to server Pipes and Shared folders except those listed in the NullSessionPipes and NullSessionShares registry entries. Signified by the enabled value (True = 1) for restrictnullsessaccess key under reg_path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters

WIP Troubleshooting Checklist - EDP enforcement disables anonymous access to server Pipes and Shared folders
WIP Troubleshooting Checklist – EDP enforcement disables anonymous access to server Pipes and Shared folders

What about the AppLocker files – Protected and Exempt Apps

Thinking about what about the applications – Protected and Exempt Apps. You can check if those has been delivered from here

HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\(Provider GUID)\device\default

WIP Troubleshooting Checklist - checking AppLocker policy delivery from registry - Protected App and Exempt App list
WIP Troubleshooting Checklist – Checking AppLocker policy delivery from registry – Protected App and Exempt App list

The AppLocker policy files as uploaded to Intune (when you import an AppLocker xml to Intune) are locally stored on the device at location C:\Windows\System32\AppLocker\MDM

WIP Troubleshooting Checklist - WIP AppLocker policies are stored locally on device at location C:\Windows\System32\AppLocker\MDM
WIP Troubleshooting Checklist – WIP AppLocker policies are stored locally on device at location C:\Windows\System32\AppLocker\MDM

Based on target, you will see there will be separate folders for EDP Allowed and EDP Exempt for both EXE (Desktop apps) and Store Apps. Inside, you will get Policy file which can be opened using Notepad or any XML editor.

In general, WIP policy is ideally global to all devices. As such you can easily get a backup of your AppLocker information uploaded to Intune from here without the need to use PowerShell and Graph API. Easy Hack!

This ends the scope of check for an Intune Administrator. However, troubleshooting CSP faults is not within Intune scope once confirmed that Intune has delivered the correct settings as configured in the console.

Now lets move to the next part which is troubleshooting application issues due to Intune WIP enforcement.

Check Intune WIP related issues with applications

The golden rule to determine if issue is related to WIP is to check the application context

Check App Enterprise Context

For TS perspective, it is important to understand the Context in which an application is running in a WIP enabled system – both MDM and MAM. To check the same, open Task manager, go to the Details tab and Add the column for Enterprise Context.

WIP Troubleshooting Checklist - check and confirm the Enterprise Context of the application
WIP Troubleshooting Checklist – check and confirm the Enterprise Context of the application
  • Personal – Has no access to EDP protected data resource defined in policy. Can only work with personal data.
  • Exempt – Has access to EDP protected data resource defined in policy but no protection is enforced.
  • Unenlightened (tagged to corporate identity) – Has access to EDP protected data resource but protection is enforced, even if the app is working with personal data.
  • Enlightened (tagged to corporate identity) – Has access to EDP protected data resource but protection is enforced for corporate data only. No protection is applied on personal data.

If your LOB app is WIP Unenlightened and it works with both personal and corporate data, you should consider putting such app under the Exempt App list. In such case, it will be allowed access to corporate resources but no protection will be enforced. If the app works with corporate data only, you should put it as a Protected App in the policy.

When you add an App to either the Protected App list or Exempt App list you get to choose the ACTION as either Allow or Deny, based on which the app will be allowed to access policy defined resources or not. However, if you import an app, the ACTION is by default set to Allow. This cannot be modified from the UI but you can always use Graph API for the purpose.

Check EDP Events: EDP-AppLearning

If an App is not in either the Protected App list or Exempted App list of the enforced WIP policy, and it tries to access

  • WIP protected data on the device, or
  • WIP protected network resource

it will get an error. If the app has logging capabilities, in the app log you may see that connection to requested URI was terminated or access denied errors.

Such event gets logged under EDP-AppLearning events against Event ID 401

Event ID 401
 
An application tried to access enterprise resources

Clicking on details will show you the application Publisher details if the app is a signed app.

WIP Troubleshooting Checklist - Check EDP-AppLearning events to determine which app has been blocked from accessing WIP protected resource. For Signed App it shows the Publsiher information.
WIP Troubleshooting Checklist – Check EDP-AppLearning events to determine which app has been blocked from accessing WIP protected resource. For Signed App it shows the Publsiher information.

For unsigned app, it shows the path to the executable.

WIP Troubleshooting Checklist - Check EDP-AppLearning events to determine which app has been blocked from accessing WIP protected resource. For Unsigned App it shows the path to the executable.
WIP Troubleshooting Checklist – Check EDP-AppLearning events to determine which app has been blocked from accessing WIP protected resource. For Unsigned App it shows the path to the executable.

It is recommended to deploy WIP policy either in Allow Override or Silent mode at the beginning (Pilot phase) to understand the application usage in your workplace by reviewing these entries and then fine tune the WIP policy by making the necessary changes in the Protected/Exempt app list, before switching WIP protection mode to Blocked.

Check EDP Events: EDP-Audit-Regular

If EDPEnforcementLevel level is set to 2 or 1 (i.e. Allow Override or Silent) you will get the copy/paste actions that the user performed from a WIP protected resource to personal context logged here

Event ID 201
 
Text|Locale|AnsiText|OEMText has been copied (CopyPaste) from O=MICROSOFT
CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING
SYSTEM\NOTEPAD.EXE\10.0.18362.1 (tagged as joymalya.xyz) to O=MICROSOFT CORPORATION,
L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING
SYSTEM\NOTEPAD.EXE\10.0.18362.1 (tagged as personal)
WIP Troubleshooting Checklist - File downloaded from policy defined resource using Save As and changing ownership to Personal also gets logged!
WIP Troubleshooting Checklist – File downloaded from policy defined resource using Save As and changing ownership to Personal also gets logged!

A file downloaded to local system using the Save As option and selecting it to save as Personal from a policy defined resource is also logged here.

Event ID 301
 
C:\Users\JoymalyaBasuRoy\Desktop\Document.docx has been changed from O=MICROSOFT
CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING 
SYSTEM\PICKERHOST.EXE\10.0.18362.1 (tagged as joymalya.xyz) to 
C:\Users\JoymalyaBasuRoy\Desktop\Document.docx (tagged as Personal) in O=MICROSOFT
CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING SYSTEM\PICKERHOST.EXE\10.0.18362.1

Check EDP Events: EDP-Audit-TCB

Removing protection of corp tagged data by changing the file ownership (allowed if EDPEnforcementLevel is set to 2 or 1) gets logged here.

WIP Troubleshooting Checklist - Removing File Protection by changing File Ownership is logged under EDP-Audit-TCB events
WIP Troubleshooting Checklist – Removing File Protection by changing File Ownership is logged under EDP-Audit-TCB events

The End of #LearnWIPwithJoy series

From L3 level perspective, this is all that you can check to help troubleshoot an issue related to Windows Information Protection. If you have completed all the checks as listed above and see that the issue is still ongoing, time to involve Microsoft support!

However, the purpose of “Learn WIP with Joy” series was to empower you with the knowledge of Intune WIP policy configuration and the underlying components involved, so that you would be able to confidently determine the scope of the issue, whether it is

  • the Intune service responsible for delivering the policy settings to the device
  • the Windows OS components responsible for implementing the settings as delivered
  • the confifguration made in the console – if the applications are added to the proper list to allow access

With this, I would call an end to the day! Will be back with some other topics on Intune soon. Till then, keep reading and keep learning and most importantly – Stay Safe!

2 COMMENTS

  1. Thank you for the comprehensive explanation on how to troubleshoot WIP policies deployed via Intune to Windows 10 devices. Can you please confirm if once Selective Wipe is created that corporate data including the protected data gets deleted?

    • Hi @Eronad,

      App selective wipe for WIP doesn’t remove the locally saved corporate data, but it does revoke the encryption keys. That effectively removes the access to the locally saved corporate data.
      However, you have to ensure that you have in the policy “Revoke encryption keys on unenroll” set to “On”. The wipe essentially removes the work account from the device as far as I know.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

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