Participating Frequently

Answered

Opening .PDX file in VDI desktop

Forum|Forum|8 months ago
May 27, 2025
2 replies
1302 views

We are attempting to launch/open a .PDX file so that we are able to search PDF files with a large number of pages on a VDI desktop. On a regular desktop, the user just double clicks on the .pdx file and it launches and they are able to search without issue.

On the VDI desktop when we double click on the .PDX file (or right click on the file and select "Open with Adobe Acrobat Reader") an install process is attempted (screenshot attached). It will eventually produce an error which is outlined below and also attached to this post.

The error says "Error 1406: Could not write value BrowseInPlace to key \Software\Classes\Acroexch.Document.DC. Verify that you have sufficient access to that key or contact your support personnel."

How is this accomplished on a Omnissa Horizon VDI desktop?

Thank you.

Rachel

Correct answer Tariq Ahmad

Hello @AnandSri !

Thank you for the response and information.

I powered on the image and launched the registry to confrim the key HKLM\\Software\Classes\Acroexch.Document.DC was indeed there and it is. I attached a screenshot showing the registry keys - Screenshot 2025-06-23 173300.png.

I then looked at the permissions of the registry and it appears the USERS only have READ access to it. When I attempt to add WRITE access I have two options - WRITE Owner and WRITE DAC. Screenshot 2025-06-23 173949.png. Which do I select?

Thank you,

Rachel

Hi @rwulffenstein,

Sorry for the delayed response. @AnandSri is currently out.

Thanks for your detailed follow-up and screenshots — very helpful.

To answer your question:

When attempting to add write access to the registry key (HKLM\Software\Classes\AcroExch.Document.DC), you’re presented with “WRITE Owner” and “WRITE DAC” as options:

You should select “WRITE DAC”, not “WRITE Owner.”

Note:

WRITE DAC (Discretionary Access Control) allows a user or group to modify the permissions (DACL) of the registry key — which is necessary to grant write access to USERS.
WRITE Owner allows changing ownership of the key, but not the permissions. It won’t help in this case unless ownership explicitly blocks changes (which is rare).

What to do next:

1. Select “WRITE DAC” to give yourself permission to change the key’s access control list.

2. After that, open the registry key’s permissions, click Add, and:

Add the “Users” group (or relevant user context for your VDI environment).
Grant it Read and Set Value or Full Control, depending on your requirement.

3. Apply the changes and close Registry Editor.

4. Reboot the image or log out/in to ensure the new permissions take effect.

This approach ensures the application can interact with .pdx files as intended, without compromising registry integrity or escalating privileges unnecessarily.

Best regards,
Tariq | Adobe Community Team

L

linda_1865

New Participant

i want to access my pdf file for my paychecks

T

Tariq Ahmad

Community Manager

Thanks for reaching out, @linda_1865.

What is the problem you are facing with Adobe applications. Could you please elaborate about your question/problem.

Best regards,
Tariq | Adobe Community Team

C

creative explorer

Braniac

@rwulffenstein

Verify that you have sufficient access to that key or contact your support personnel" on an Omnissa Horizon VDI desktop when opening a .PDX file is a classic permissions issue within a locked-down virtual environment. This is less about the .PDX file itself and more about how Adobe Acrobat Reader is deployed and managed in the VDI. When a user double-clicks the .PDX file, Acrobat Reader tries to write a registry entry to correctly associate and handle the file type for "in-place Browse," which is a normal part of its operation. On a VDI, especially non-persistent desktops or those managed by tools like App Volumes, users typically don't have the necessary administrative privileges to modify core registry keys like HKEY_LOCAL_MACHINE\SOFTWARE\Classes. The "install process" you're seeing is likely Acrobat attempting to "repair" or re-establish these crucial registry associations, which it cannot do due to permission restrictions.

The solution lies in ensuring that Adobe Acrobat Reader is properly deployed and configured within your Omnissa Horizon environment with the necessary pre-configured registry permissions or application layering. This is an IT/VDI administration issue, not an inherent flaw in Acrobat or the .PDX file itself.

Your VDI administrators need to ensure that the base image or application package (e.g., AppStacks if using App Volumes) has all required registry keys and file associations pre-populated and correctly permissioned for standard users to read and write where necessary, preventing Acrobat from needing to make these modifications at runtime. They should consult Adobe's official guides for deploying Acrobat Reader in virtualized environments like VMware Horizon, which specifically address these types of permission and registry errors, often recommending the use of the Adobe Customization Wizard or specific command-line installations to prevent auto-updates and registry attempts by end-users.

R

rwulffensteinAuthor

Participating Frequently

Thank you for the response.

I figured the issue was with the setup of Adobe on the image and not having the correct registry settings which is the reason the install is happening. My question is WHAT are the settings that are missing and need to be added so the user can double click on the .PDX file and search as they would on a regular windows desktop.

I looked through the document below but did not find anything that is not already set on the image. https://www.adobe.com/devnet-docs/acrobatetk/tools/VirtualizationGuide/vmware.html#tuning-for-virtual-envs

Where else can I look to find the registry entries that need to exist on the image? Adobe Reader is installed on the image

T

Tariq Ahmad

Correct answer

Community Manager

Hello @AnandSri !

Thank you for the response and information.

I powered on the image and launched the registry to confrim the key HKLM\\Software\Classes\Acroexch.Document.DC was indeed there and it is. I attached a screenshot showing the registry keys - Screenshot 2025-06-23 173300.png.

I then looked at the permissions of the registry and it appears the USERS only have READ access to it. When I attempt to add WRITE access I have two options - WRITE Owner and WRITE DAC. Screenshot 2025-06-23 173949.png. Which do I select?

Thank you,

Rachel

Hi @rwulffenstein,

Sorry for the delayed response. @AnandSri is currently out.

Thanks for your detailed follow-up and screenshots — very helpful.

To answer your question:

When attempting to add write access to the registry key (HKLM\Software\Classes\AcroExch.Document.DC), you’re presented with “WRITE Owner” and “WRITE DAC” as options:

You should select “WRITE DAC”, not “WRITE Owner.”

Note:

WRITE DAC (Discretionary Access Control) allows a user or group to modify the permissions (DACL) of the registry key — which is necessary to grant write access to USERS.
WRITE Owner allows changing ownership of the key, but not the permissions. It won’t help in this case unless ownership explicitly blocks changes (which is rare).

What to do next:

1. Select “WRITE DAC” to give yourself permission to change the key’s access control list.

2. After that, open the registry key’s permissions, click Add, and:

Add the “Users” group (or relevant user context for your VDI environment).
Grant it Read and Set Value or Full Control, depending on your requirement.

3. Apply the changes and close Registry Editor.

4. Reboot the image or log out/in to ensure the new permissions take effect.

This approach ensures the application can interact with .pdx files as intended, without compromising registry integrity or escalating privileges unnecessarily.

Best regards,
Tariq | Adobe Community Team

What to do next:

What to do next:

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.

Scanning file for viruses.

This file cannot be downloaded