This post describes an issue that surfaced late in 2020 with policy tips not showing within emails in Outlook where data loss presentation policy rules are matched.

Full disclosure, I’ve got a series of posts planned on my experiences of Microsoft 365 compliance that I had hoped to publish last year, but other things have got in the way so apologies for the lack of any background I’d hoped to have in place – but it is coming!

For the past twelve months or so I’ve been creating, testing and tuning data loss prevention rules in Microsoft 365 in my organisation. We’ve published several of the Microsoft standard data loss prevention policies as well as creating our own custom sensitive information types and policies.

Data loss prevention (DLP) policies allow you to enable policy tips to be shown with custom text when a policy match occurs. Going through user acceptance testing in Autumn 2020 there no were no major issues – DLP rules were matching correctly and the policy tips were displaying consistently throughout Microsoft 365 from SharePoint to Outlook.

In November 2020, I noticed that policy tips that had been showing in Outlook had stopped appearing all together. It was around this time I came across this article from Microsoft that says:

This issue occurs because the compatible version criteria that’s processed by the policy evaluator is based on the version of mso20win32client.dll, not the version of Outlook. In many cases, the version of mso20win32client.dll is not the same as the version of Outlook and Office.

For example, an administrator may configure a very restrictive policy that applies only to version 16.0.11727.20244 or a later version of Outlook. However, the policy evaluator uses version 16.0.11727.20222 of mso20win32client.dll and determines that the rule should not be applied. In this example, the rule would have to indicate the minimum required version of 16.0.11727.20222 to have the policy tip appear in Outlook.

From <https://docs.microsoft.com/en-us/outlook/troubleshoot/security/can’t-display-dlp-policytip>

Now I’ve interpreted, plus also had it confirmed by Microsoft support that effectively means the policy ips will not work if the version of Office/ Outlook you are running is newer than the version the policy evaluator is using. It doesn’t say that specifically in the excerpt above, but it is most definitely the case. I’ve tested using Outlook on the web as the article describes and the policy tips still show. I’ve also deleted the registry value as suggested in the resolution section of the article to no avail too.

An additional support article was brought to my attention on this issue which you can read here. The article doesn’t reference the one I’ve highlighted in this post, but does mention some additional issues I was hadn’t noted:

• Outlook DLP policy tips are not detecting sensitive information in PDF, Excel, Word and other attachments and it may work inconsistently across attachments
• Policy tip detection may work for smaller attachment such as a 15KB file, but not for larger attachments such as a 2MB file
• Outlook is also not detecting HIPAA or ICD-9 or ICD-10 correctly in the message body
• In some cases, Outlook is not detecting key words with certain syntax such as quotation marks
• In some cases, Outlook is not showing the policy tip if the message is being retrieved from a Draft 

FROM: https://support.microsoft.com/en-us/topic/outlook-dlp-policy-tips-not-working-for-certain-conditions-in-email-body-and-attachments-8a32496a-3478-403c-b2eb-04a218f7443c?ui=en-us&rs=en-us&ad=us

Update from Microsoft – FIXED 12/05/21

STATUS:  FIXED 

Initial fixes for the Outlook Desktop client are available starting with Version 2105, Build 14026.20000. This build is now available in the Beta Channel and Current Channel Preview and is estimated to go to production Current Channel the week of May 24th. You can monitor the Update History page to confirm when Version 2105 goes to current channel.

Service fixes are now available in mailbox version 15.20.4128.0 and higher. You can check your mailbox version using the Outlook Connection Status Dialog.

To improve reliability and stability the current implementation of the policy tip feature in Outlook Desktop is undergoing a broad update.  Starting in May 2021 you should start to see a more reliable and predictable experience when using the policy tips feature in Outlook.  This work will continue and throughout the year you will see incremental improvements to feature scope and reliability. 

Not every potential problem with policy tips is caused by the current design limitations so you should apply normal troubleshooting steps to any new issue.  If a determination is made that a new problem is one of those covered by our current renovation efforts, then fixes for that new problem will first be possible in the following months when the updated implementation reaches production.

Update from readers 22/02/21

One of the readers of this blog – @AT added an update that they had received from Microsoft on this issue:

Click here for the latest Microsoft support article

Our reader had found the policy nudge files weren’t being downloaded to the app data folder when applied (these are under appdata\local\microsoft\outlook). They added that the policy nudge files started to re-appear last weekend (14 February 2021), but the policynudgerules.xml file was incomplete. Pasting text from old policy nudge files into the newly downloaded one allows the override to be seen.

They added that the workaround they used was as follows:

• Close Outlook
• Delete the registry key LastDownloadTimesPerAccount
• Delete the 2 PolicyNudge.xml files in users app data folder
• Reopen outlook and create a new email (this re-creates the registry and 2 .xml files)
• Edit PolicyNudgeRules.xml file
• Restart Outlook

Aside from the fact the policy tips do not detect sensitive information in attachments in Outlook, our reader also noted that Outlook will try to re-download the policy files after 24 hours on an Outlook restart, so the edited PolicyNudgeRules.xml file will be replaced with the incomplete one. At the end of the registry value there is a 9 digit number which is Epoch time, that’s being used to detect if 24 hours has elapsed.

Update from Microsoft 15/02/21

I’ve been in discussions with various people from Microsoft who have also tried to help move this issue forwards. Here are some of the suggestions I’ve had so far:

1. Update to the latest version of Office on the semi-annual channel to see if the problem persists
2. Create a new Windows 10 VM with the latest version of Office installed, added to an OU, but with no organisational GPO’s set to prove if it isn’t related to GPO’s
3. Add a device on the insider channel to know when the issue is fixed natively fixed on the Outlook client
4. Speak to Microsoft Premier Support

In my organisation we have client machines on different versions of Office so I can rule out option 1, as I test more of the suggestions I will update this post!

---