1        The configuration

To date, we have completed the implementation of the DKE solution with Purview and we have configured the data labels so that they use the URL in question of the key, as you can see in the following screenshot.

PS: For privacy reasons the value of the key has been changed

Figure 1 : Key information From Entrust Vault (Running in Azure)

Here you can see how the DKE label has been setup.

When we created the label and published it, we didn’t encounter any particular problems

This label was then published correctly through a policy. As a result, it appeared on the interface of the Word desktop application in particular, as well as on the Excel and Outlook applications

The version of Word we use is as follows

2         The issue

When we use this label with DKE encryption, it is not possible to save this document, as shown in the following figure

Unable to save or create this file. Check that the disk where you want to save the file is not full and write-protected or damaged.

3 Search for a solution

11/11/2025

CL2: DKE URL in root

The problem appears to be known to Microsoft, as indicated in the following link: https://techcommunity.microsoft.com/blog/microsoft-security-blog/dke-troubleshooting/2234252

Clause 2 does not seem to be correct in our configuration.

Our key URL does not seem to be in the correct format. Our key URL generated by the Entrust service is actually as follows:
https://dkeext.xxx.xx /v5/dke/a4863d9e–6514–8773–1f6fc730068f.dke_keys.DKEInterneUniquement

i will ask Entrust team to see if we can change this

CL4: Outbound connectivity to Azure AD

I have just asked our network team whether the workstations are able to connect to the Microsoft resources specified in this section. I am therefore awaiting their response.

CL5: Permissions in the sensitivity label used for DKE

The permission has been granted for all users in the tenant as required

CL6: Web application configuration

In the «Authentication» section of the DKE web application registration, verify that the redirect URI does not contain a trailing slash

No Trailing Slash

In the section “API permissions”, make sure the whole tenant has been granted consent to “User.Read”:

Permissions looks good

but expose API is not correct the documentation mentions this

but our Entrust Application looks like this 😦

let’s try to correct this. we try without other additionnal documentation to set the same configuration . Now our configuration looks like this

Now let see if it changes something on the application side.

Same issue ; we can not save Word DKE file locally.

CL8: Client connectivity to DKE and Azure AD

For acquiring the public key and for decrypting existing keys, clients needs to be able to reach the DKE service. To allow authentication, clients also require access to Azure AD.
Both transparent connectivity and forward proxies (with or without authentication) are supported.

wehn we try from the workstation to access to the DKE Url and because we use a Proxy we have this warning

I will ask the network teams to White list this server

CL9: DKE-related registry values are set on each client

Ensure the following registry values are defined on each client, please observe that some of the registry keys may also need to be created:

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\MSIPC\flighting]
"DoubleKeyProtection"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSIPC\flighting]
"DoubleKeyProtection"=dword:00000001

I add this 2 Registry entries in my workstation and reboot the  workstation

But after rebooting we still have the issue.

12/11/2025

After changing the configuration, we no longer have the same behavior. Messages encrypted with DKE can now be sent by Outlook. See: https://workingtogether.fun/2025/11/11/purview-dke-microsoft-outlook-was-unable-to-create-a-message-with-restricted-permissions/

However, we still have the same problem with Word, but with a different message this time.

Microsoft support had us change a setting in the data label, see below. The value was changed to Always instead of Never.

After 3 Hours the behavior of Word Desktop is the Same

Dec 1 2025

After several weeks, Microsoft support continues to ask me for screenshots but apparently is not able to respond to this unexplained problem

for my part, I updated the version of Office with the latest version available on Office 365 but the behavior is identical.

What is surprising is that to see people able to save Word files encrypted with the DKE option, on some labels and not others.

DEC 15 2025

After several tests, on several Windows 11 workstations, we found that we are able to reproduce the problem.

To avoid any problems with the versions of the Office suite, we have started with completely new and up-to-date versions. Unfortunately the problem is still present despite the fact that we checked that the registry keys were present in the workstation

We also verified that the workstation could easily reach the uRL specified in the Purview data label.

I remind you that this problem only occurs if the DKE data label allows the user to select rights holders on the document in question. For DKE data labels that do not allow this feature, the Office suite responds appropriately and allows the user to save this file with this level of encryption (DKE)