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.
- Windows Information Protection | WIP Learn with Joy Part #1 | Intune
- Windows Information Protection WIP Deep Dive | Internals with Joy Part 2
- 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 the Windows Information Protection policy on your Windows workstations, various issues may arise, such as (not limited to) applications stopping working or not working as expected when they are either working with corporate-tagged data on the device or a corporate-identified resource in the policy.
In this article, I will discuss the general approach an Intune Admin should follow to troubleshoot issues related to enforcing Windows Information Protection. This article is a complete checklist for troubleshooting Intune WIP policies for absolute beginners!
Article Structure
The article is structured in two parts, as shown below
- Checking the WIP policy state on the 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 the device end
When we check the policy state on an endpoint, the 1st step is to check if the device has received the policy from Intune.
Confirm that the 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.
You can further generate an MDM diagnostic report to check the settings that have 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 have been delivered, the scope of Intune ends.
The corresponding CSPs (EnterpriseDataProtection CSP, AppLocker CSP, and Policy CSP) that the OMA-DM client invokes are then responsible for implementing the device’s settings as delivered.
Confirm the EDP State Change – Intermediate Check
As you have confirmed the policy delivery from Intune, you should now check whether the Intune WIP policy was successfully implemented. If yes, the device’s EDP state will change.
Confirm the EDP state of the device by having a look into the registry
Path: HKLM\SOFTWARE\Microsoft\Provisioning\Evaluator\PostProcess\EDP
For example, the policy has been delivered if there are any issues related to the implementation. However, EDP enforcement failed, and you see that the EDP state is Off—it is essentially under the troubleshooting scope of Windows and not Intune.
If you face an error like the 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 the 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 a UI for configuring the WIP policy and you must resort to a custom OMA-URI to deliver the policy settings.
With Intune, however, the dependencies will always be met as it has a 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 will 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 the EDP state are 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, the WIP policy may get implemented partially, in the sense that AppLocker files and NetworkIsolation properties will get affected in the registry, but EDPEnforcementLevel will fail, and thereby the EDP state will not change from the 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 the 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 the below path HKLM\SOFTWARE\Microsoft\PolicyManager\current\device
- The data protection node contains the EDP settings
- The network isolation node contains the configured EDP resources (Cloud resource, Network Boundaries)
- The search node contains the EDP settings for Windows Search
The reg_path HKLM\SOFTWARE\Microsoft\EnterpriseDataProtection\Policies Gives you a view of whether the user is allowed to decrypt protected files and the EDP enforcement level
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.
- EnforcementLevel
Reg_path HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Ntfs\EFS\Parameters shows
- EdpExcludedExtensions – file extensions that are excluded from WIP by default
- EdpExcludedPaths – paths that 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
What about the AppLocker files – Protected and Exempt Apps
Thinking about what about the applications – Protected and Exempt Apps. You can check if those have been delivered from here
HKLM\SOFTWARE\Microsoft\EnterpriseResourceManager\Tracked\(Provider GUID)\device\default
The AppLocker policy files, as uploaded to Intune (when you import an AppLocker xml to Intune), are locally stored on the device at the location C:\Windows\System32\AppLocker\MDM
Based on the target, you will see separate folders for EDP Allowed and EDP Exempt for both EXE (Desktop apps) and Store Apps. Inside, you will get a Policy file that can be opened using Notepad or any XML editor.
In general, the 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 using PowerShell and Graph API. Easy Hack!
This ends the scope of check for an Intune Administrator. However, troubleshooting CSP faults is not within Intune’s scope once it is confirmed that Intune has delivered the correct settings as configured in the console.
Now, let’s move to the next part, troubleshooting application issues due to Intune WIP enforcement.
Check Intune WIP-related issues with applications
The golden rule to determine if an issue is related to WIP is to check the application context
Check App Enterprise Context
From the T’s 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 this, open Task Manager, go to the Details tab and Add the column for Enterprise Context.
- Personal—This group has no access to the EDP-protected data resource defined in the policy and can only work with personal data.
- Exempt – Has access to EDP-protected data resource defined in the policy, but no protection is enforced.
- Unenlightened (tagged to corporate identity) – Has access to EDP-protected data resources, but protection is enforced, even if the app works with personal data.
- Enlightened (tagged to corporate identity) – Has access to EDP-protected data resources, but protection is enforced for corporate data only. No protection is applied to personal data.
If your LOB app is WIP Unenlightened and it works with both personal and corporate data, you should consider putting such an app under the Exempt App list. In such a 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 can 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 the 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 the connection to the 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.
For the unsigned app, it shows the path to the executable.
It is recommended to deploy the 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. Then, fine-tune the WIP policy by making the necessary changes in the Protected/Exempt app list before switching the WIP protection mode to Blocked.
Check EDP Events: EDP-Audit-Regular
If the 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)
This log also records a file downloaded to the local system using the Save As option and selecting it to save as Personal from a policy-defined resource.
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.
The End of #LearnWIPwithJoy series
From an 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 listed above and see that the issue is still ongoing, it’s time to involve Microsoft support!
However, the purpose of the “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 is responsible for delivering the policy settings to the device
- the Windows OS components responsible for implementing the settings as delivered
- the configuration 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. Until then, keep reading and learning, and most importantly – Stay Safe!
We are on WhatsApp. To get the latest step-by-step guides and news updates, Join our Channel. Click here –HTMD WhatsApp.
Author
Joymalya Basu Roy is an experienced IT service professional with almost 5 years of experience working with Microsft Intune. He is currently working as a Senior Consultant – Architect with Atos India. He is an ex-MSFT, where he worked as a Premiere Support Engineer for Microsoft Intune. He was also associated with Wipro and TCS in the early stages of his career. He is awarded the Microsoft MVP award for Enterprise Mobility in 2021. You can find all his latest posts on his own blog site MDM Tech Space at https://joymalya.com
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.
I created a WIP and assigned to a limited scope of users. all users have latest win 10 build but policy wont apply at all. All devices are registred in Azure but for some reason WIP is not applying to any devices.
after deployed wip policy to a user group and i excluded the user group, the wip policy still applies. how to cleanly remove wip policy on a computer that applied to the user group?
You might need to look at the CSP policy for these settings. I think policy tattooing impact would there for these policies (I assume). I have not specifically checked WIP policies but some examples are there in https://www.anoopcnair.com/intune-policy-tattooed-not-tattooed-windows-csp/