Adobe Standard error on terminal server with roaming profiles

A while ago I got tasked with som application trouble for some users of the licensed Adobe Acrobat DC.
Sometimes applications need some adjustment when beeing used in a virtual environment, and dont always work as you want them too.
Now, Adobe has some guidelines for setting up Adobe products on RDS environments, which in this case already was implemented.
More on that here and here.

Now the case.
Users were reporting getting the below error message when starting pdf files within Citrix/RDS environment, only occurs for users with full licenced Adobe Acrobat.

After some basic troubleshooting it seemed like this only occured for users having enabled the preview function whitin Windows Explorer.
With this option enabled, the error came when selecting a pdf file, and no preview showed up in explorer. Selecting more than one file was also not possible.
Double click to open the file launced Adobe and showed the file as expected.
Turning of the preview in explorer made the error og away.

Looking around the web for similar problems eventually gave the following.:

The last response in link nr 2 solved the problem.
«The reason you are getting the error is that the prevhost.exe process that is being invoked in the preview pane looks for a folder in the user’s local profile, AppData\Local\Adobe\Acrobat\11.0 (or whatever version).»

Adobe is looking for the «version» folder under local appdata.
Using folder redirection and roaming profiles in a terminalserver environment, appdata\local is usually excluded. But some applications still like to put some required data here, to give IT some headaches.

Knowing this, the solution became to leverage Group Policy and Group Policy targeting, to create the mentioned folder upon user logon for the Adobe Acrobat Standard users.

In my case this was on a Citrix environment, with Citrix User Profile Management for User profiles.
To make sure this folder lived on whitin the users profile, an inclusion was set to sync this spesific folder to the central user profile store for later.
(But testing shows its not really needed, as adobe is just looking for the folder, and dont seem to care that much about what is actually inside the folder, datawise)

The problem, from reading on the web, also can happen on a normal computer, the solution is the same, just create the folder whitin the users profile for the affected user.

GPO for making the folder for the user upon logon:

User configuration\prefrences\windows settings\folders

Group policy targeting, pointing to security group for the Adobe Acrobat Standard users:

After setting the above no more reports on the same error occured. Hopefully this helps anyone else looking at the same problem.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Discover more from

Subscribe now to keep reading and get access to the full archive.

Continue reading