Locally installed adobe reader update prompt RRS feed

  • Question

  • We have a problem when launching the locally installed version of adobe reader 10.1 from within an app-v virtual environment. This happens when launching help from within an application or launching a shortcut to a PDF located within the app-v package.

    Shortly after the PDF loads, we receive a request for an adobe update.

    This should be disabled by the local machine registry entry:

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockDown

    Which has the value ‘Bupdater’ set to dword:0 on the local machine registry.

    This key is set by the adobe customization wizard for our deployment.


    When launching in the virtual environment it would appear that the 2<sup>nd</sup> low integrity process has no access to the FeatureLockdown key

    (app-v Access Denied.pml)

    The acrord32.exe process seems to get access denied twice on the ‘featurelockdown’ key and then proceeds to the ‘Originals’ Key.

    When looking at a normal launch of adobe (same pdf but on local machine) the acrord32 second process gets access denied, but then in contrast to the app-v version the initial process queries the same key and succeeds. This then happens for the of sub-keys in the featurelockdown location before it then also proceeds to the ‘Originals’ keys.

    (App-v Normal Launch.pml)

    It appears that in the app-v environment the low integrity process is unable to get the required information from the key by itself, or via the parent process.

    Removing protected mode from adobe reader allows the application to work correctly.


    Can we have a protected mode version of adobe reader locally installed but launched inside the app-v environment and still obey the group policy registry settings?

    Researching app-v and the group policy registry settings would suggest that as of app-v 4.5, sequenced applications should always use the locally installed key.

    Any ideas on potential workarounds for this?

    Attempted workarounds:

    ·          Installed app-v Hotfix 4

    ·          Adding the keys to the app-v passthrough registry.

    ·          Virtualising the featurelockdown key (without values) and using merge option.

    ·          Removing protected mode in app-v (this works but not ideal)


    Adobe's policy appears to be 'if it works on the standard OS system then it is an app-v issue'.

    Wednesday, January 11, 2012 11:57 AM

All replies

  • Does App-V Hotfix 4 mean App-V 4.6 SP1 Hotfix 4? Have you tested with Reader X 10.1.1?

    Is a Reader process already running before it's brought into the virtual environment? If so, what happens if no Reader processes are running before the action?

    Reader X Protected Mode will work when Reader is virtualised, but I haven't tested with an installed Reader X running in a virtual environment.

    Twitter: @stealthpuppy | Blog: stealthpuppy.com

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.

    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.

    Wednesday, January 11, 2012 1:19 PM
  • thanks for the response.

    Yes app-v 4.6SP1 hotfix 4 is installed.

    I've just tried with reader X 10.1.2 (latest on website) and the process still prompts and the process monitoring still reveals its getting access denid on the key.

    I previously was not running with an adobe process running prior to launch, but thought i would see what happens. If i open an instance of Adobe on the local machine, then click to launch a PDF shortcut from the start menu it fails as it cannot open the file adobe reader message: 'There was an error opening this document. This file cannot be found'. Of course i cant browse to a PDF either as the acrord32.exe process cannot see the virtual environment.



    Wednesday, January 11, 2012 4:00 PM
  • Hello,

    Have you set LOCAL_INTERACTION_ALLOWED= TRUE within the OSD-file?
    Nicke Källén | The Knack| Twitter: @Znackattack
    Wednesday, January 11, 2012 4:22 PM
  • Hello,

    Have you set LOCAL_INTERACTION_ALLOWED= TRUE within the OSD-file?
    Nicke Källén | The Knack| Twitter: @Znackattack

    I hadn't, just tried and still no luck.

    I did try thumbing through the OSD illustrated page for something that may help but nothing jumped out at me.

    Wednesday, January 11, 2012 4:37 PM
  • Hello,

    I usually resolve this by setting the key within the virtual environment. Quick-fix. Since its lockdown values, they are rather generic - but of course if you upgrade they will need to be updated
    Nicke Källén | The Knack| Twitter: @Znackattack
    Wednesday, January 11, 2012 4:40 PM
  • One of the options I considered was setting these values inside the package, or as we have done before when we used to disable protected mode, create a new virtual package with the key and use DSC to link them. However this can be a bit of a pain, as you say we would then need to update this package when adobe is updated.

    I was hoping someone would have a nicer solution :)

    Wednesday, January 11, 2012 5:02 PM
  • If you want to disable Protected Mode in the bubble on a locally installed Adobe Reader launched from within the virtual environment. You can use OSD scripting and set a registry key, to disable Protected Mode in the bubble only.

    <REGKEY HIVE=”HKCU” KEY=”SOFTWARE\Adobe\Acrobat Reader\10.0\Privileged” NOREDIR=”FALSE”>
    <REGVALUE REGTYPE=”REG_DWORD” NAME=”bProtectedMode”>00000000</REGVALUE>

    Read all about here: http://www.the-d-spot.org/wordpress/2011/12/29/app-v-and-adobe-reader-access-denied-when-opening-a-pdf-file/

    Thursday, January 12, 2012 8:59 AM
  • Thanks for the responses guys, Yes we could virtualise the keys, but i am very reluctant to do so.

    1) Adobe protected mode is there for a reason, why reduce the security?

    2) When we upgrade adobe, or decide to change a setting we will have to modify all of our app-v packages that contain this fix.


    My prefered solution at the moment would be to keep protected mode running inside the virtual app (as it does seem to work ok) and live with the prompt awaiting a newer version of app-v or adobe which may solve the problem.

    Friday, January 13, 2012 10:04 AM