Opening .PDX file in VDI desktop

[rwulffenstein]

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

[creative explorer]

@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.

[rwulffenstein]

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-virtua...

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

[AnandSri]

Hello @rwulffenstein!

I hope you are doing well, and thanks for reaching out.

++Adding to what has already been shared by our product community expert, when Adobe Acrobat Reader attempts to open a .PDX file, it tries to write to the Windows Registry to associate the file type and enable in-place browsing. On a regular desktop, this works fine because the user typically has sufficient permissions. However, in a VDI environment, especially one that is non-persistent or managed via App Volumes, users often lack the necessary rights to modify keys under HKEY_LOCAL_MACHINE\SOFTWARE\Classes

This triggers the "install" behavior you're seeing—Acrobat is trying to repair or re-establish file associations, but fails due to restricted permissions.

To resolve this, your IT or VDI administrator should:

Pre-configure the Registry Keys:

Ensure that the base image or application layer (e.g., AppStack) includes the necessary registry entries for .PDX file handling.

Specifically, the key \Software\Classes\Acroexch.Document.DC should be present and correctly permissioned.

Set Proper Permissions:

Grant read/write access to the relevant registry keys for standard users, or use Group Policy to apply these settings during login.

Use Application Layering Tools:

If you're using VMware App Volumes or similar, ensure Adobe Acrobat Reader is packaged with all required registry settings and file associations.

Avoid Runtime Repairs:

• By ensuring all associations and permissions are in place in the image, you prevent Acrobat from attempting to self-repair at runtime, which it cannot do without elevated privileges.

If the issue continues, please share the current OS version installed, the version of Acrobat or Reader installed, a quick screen recording, and the logs from the affected machine. To collect the logs, download and run the Log Collector tool. Make sure to select all log options and attempt to reproduce the issue. After that, close the Log Collector tool; it will generate the logs along with a log ID. Please share this log ID with us for further investigation.

Thanks,

Anand Sri.

[edited response]