locked
PDF FTA not getting set correctly RRS feed

  • Question

  • Good Morning:

    I am attempting to sequence Adobe Standard/Professional 9.  I understand the limitations, and they work fine in my environment.  I am currently running these applications in production using App-V 4.6, and I am migrating to 5.0.

    App-V 5 allows more features to be available in the application, so I am re-sequencing instead of converting.  Everything seems to work properly except for one small but important detail: the FTA is half broken.

    In my environment, everyone has access to Adobe Reader.  It's on every machine to allow for PDF integration with Web Browsers as well as providing a PDF viewer for users that do not have access to Standard/Pro version of Adobe.  So by default, Adobe Reader opens for everyone.

    After publishing my Adobe Standard package, Adobe Reader still opens all PDFs.  The desired (and expected) behavior is that the App-V 5 package will be used.   If I right click a PDF file and choose Open With, Adobe Reader and Adobe Standard is available, so I know the FTAs are working correctly.  However, it is not setting the default association.

    I did a bit of digging and I believe I have found the root cause, but I'm looking for some creative assistance to find a solution.

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice\ProgID is set to "AcroExch.Document.11", which is not Adobe Standard 9.  If I change "AcroExch.Document.11" to "AcroExch.Document", everything works fine.  And I would be more than happy to target this value with a group policy preference policy, but -- the user is explicitly denied access at the UserChoice key.  I'm not setting the permissions -- this is something that windows does when you use the "choose default program" option (right click, open with , choose default program).

    Any ideas?

    Tuesday, November 4, 2014 3:56 PM

Answers

  • I believe I have a better understanding of what is happening.  I think this is probably an expected behavior of FTA management.

    You're right -- FTAs can be configured at HKLM level or HKCU level.  HKCU will lay over the HKLM settings allowing the user of a machine to make their own independent choice of what applications handles a specific FTA.

    When you publish an app-v 5 application, it will adjust the FTA configuration.  If it's published to the machine (global), it will adjust the HKLM configuration.  If it's published to user, it will adjust the HKCU setting.

    If a user never makes a choice as to which program they want to handle the FTA, this works perfectly.  However, if you use the built in method of setting a program to open an fta, it will make a permission change on the registry that actually sets a deny in the access list.  When app-v attempts to set the FTA, it will fail because of this deny.  The deny is set on the following registry key (obviously, change .pdf to whatever extension you are troubleshooting):

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice\

    In the end, this makes perfect sense.  You want to give the user a choice of which program to use, and giving them a choice doesn't mean changing the FTA type every time a new application is published.  Once they make their choice, it really is set!

    In my environment, I will have to most likely write a script that removes this key once.  I know many users have assigned the .pdf fta to open with the app-v 4 client, which then opens Adobe.  Moving to App-V 5, the 4 client will still be there but the Adobe 4 sequence will not.  This will generate some problems if not handled correctly.

    Thanks for your help on figuring out this issue!

    • Proposed as answer by Joe.Robinson Wednesday, November 5, 2014 1:21 PM
    • Marked as answer by kirk_tnModerator Thursday, November 6, 2014 11:09 AM
    Wednesday, November 5, 2014 1:21 PM

All replies

  • Hello,

    If you deploy the package to a computer without any PDF association set. Does .PDF-Files get associated?


    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, November 4, 2014 4:18 PM
  • It works fine in that scenario.

    In fact, the only time the problem occurs is when a user has, at one point, manually set the application they wish to use as a default.  

    I'm thinking about a one-time delete of the userchoice key, since the user can delete the key, they just can't explicitly set any values underneath it.

    Still curious what others have done to deal with this problem.

    Tuesday, November 4, 2014 4:35 PM
  • Hello,

    FTAs can be set both per-user or per-machine (HKCU v HKLM).

    If the user has set a preference (HKCU), my guess is that this would override the HKLM (which can be considered a default.

    See this more detailed explanation of the scenario (and the opposite use-case);

    http://appsensebigot.blogspot.se/2014/04/deploying-per-user-file-type.html


    Nicke Källén | The Knack| Twitter: @Znackattack

    Tuesday, November 4, 2014 8:56 PM
  • I believe I have a better understanding of what is happening.  I think this is probably an expected behavior of FTA management.

    You're right -- FTAs can be configured at HKLM level or HKCU level.  HKCU will lay over the HKLM settings allowing the user of a machine to make their own independent choice of what applications handles a specific FTA.

    When you publish an app-v 5 application, it will adjust the FTA configuration.  If it's published to the machine (global), it will adjust the HKLM configuration.  If it's published to user, it will adjust the HKCU setting.

    If a user never makes a choice as to which program they want to handle the FTA, this works perfectly.  However, if you use the built in method of setting a program to open an fta, it will make a permission change on the registry that actually sets a deny in the access list.  When app-v attempts to set the FTA, it will fail because of this deny.  The deny is set on the following registry key (obviously, change .pdf to whatever extension you are troubleshooting):

    HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf\UserChoice\

    In the end, this makes perfect sense.  You want to give the user a choice of which program to use, and giving them a choice doesn't mean changing the FTA type every time a new application is published.  Once they make their choice, it really is set!

    In my environment, I will have to most likely write a script that removes this key once.  I know many users have assigned the .pdf fta to open with the app-v 4 client, which then opens Adobe.  Moving to App-V 5, the 4 client will still be there but the Adobe 4 sequence will not.  This will generate some problems if not handled correctly.

    Thanks for your help on figuring out this issue!

    • Proposed as answer by Joe.Robinson Wednesday, November 5, 2014 1:21 PM
    • Marked as answer by kirk_tnModerator Thursday, November 6, 2014 11:09 AM
    Wednesday, November 5, 2014 1:21 PM
  • Hi, the above issue should only occur if the user modified the FTA manually.

    If you converted your App-V 4 package to App-V 5, the v5 package should take control about the previous FTAs and shortcuts propperly.


    Falko

    Twitter @kirk_tn   |   Blog kirxblog   |   Web kirx.org   |   Fireside appvbook.com

    Thursday, November 6, 2014 11:09 AM
    Moderator