locked
Is it possible to recreate Office 2010 FTAs if publishing only shortcuts in App-V 5 SP2? RRS feed

  • Question

  • Greetings,

    I am trying to sequence only shortcuts for locally installed office 2010 to be used in connection groups with combinations of add-ins utilizing user targeting. Package with shortcuts work fine, however when I try to add file type associations (FTAs) the result is quite poor. Double click on file with registered extension seems to be triggering the shortcut but not with desired result from the office application (excel is started without opening the file being clicked, Outlook is starting instead of opening the msg file, etc)

    Is it possible to publish only shortcuts and achieve full functionality of FTAs as they would normally work in office? What is the best/recommended way to go about it?

    I have tried exporting registry keys from HKEY_Classes_Root, HKLM\Software\RegisteredApplications, HK??\Software\Microsoft\[Appname]\Capabilities and few others and import them in the package but wasn't able to get the sequencer to recognize the FTAs and adding it manually doesn't achieve the desired result

    Environment: App-V 5 SP2 with hotfix 5, windows 7 64bit stateless VDI (xendesktop), full app-v infrastructure (no sccm), shared content store

    Any help/direction will be appreciated

    Wednesday, September 17, 2014 6:14 AM

Answers

  • Thank you for your reply

    Your suggestion (office globally, add-in user published in CG) would be one of the options. As with all the others it doesn't appear to be a clean way of doing it as App-V server infrastructure is not supported. That will mean manually creating (and updating) xml files, using login scripts etc to make it happen. All the others have similar limitation. (This is where I urge MS to re-think their office add-in support and improve it in next version/update.) All that is provided I get buy in for virtualizing office in the first place. There is quite a reluctance at that (myself included) but that is a different topic.

    As for the other people that may be looking to do something similar. It is possible (though not straightforward) to achieve this (using file extensions to open apps inside appv bubble) This may not be the best way to do it but I have found it to work so I will share it.

    file extensions are stored in the registry in HKEY_CLASSES_ROOT (among other places). Example .xlsx. Underneath that particular key there are subkeys (either openwithprogids or progid/long key itself example: Excel.Sheet.12 - more information on that bing search for "msdn cc144148" as I am unable to post links at this time). Same ProgIDs/long names are defined again in HKEY_CLASSES_ROOT (HKCR\Excel.Sheet.12). Under that key there should be shell key with one or more commands (open, edit, etc). Yet another subkey called command will reveal the executable called for the extension (example: HKEY_CLASSES_ROOT\Excel.Sheet.12\shell\Open\command). Default property shows clear text command, command property shows the same command possibly with different encoding (example for excel: xb'BV5!!!!!!!!!MKKSkEXCELFiles>VijqBof(Y8'w!FId1gLQ /dde)

    This is the place where I tested adding the appvve:/guid_guid switch and it worked.

    Hint: searching registry for particular command (xb'BV5!!!!!!!!!MKKSkEXCELFiles>VijqBof(Y8'w!FId1gLQ) helps revealing all location that need changing per application. In my example there were 61 locations for excel alone. Powershell is really helpful with that. Search registry script bing search "Searching the Registry with PowerShell Bill Stewart" (another hint: use [regex]::escape(xb'BV5!!!!!!!!!MKKSkEXCELFiles>VijqBof(Y8'w!FId1gLQ))

    Since you will probably have more than one combination of add-ins like me you want to use connection groups. If you want to use this option you have to use only one connection group for a particular user for the same file extension. Login script can be used to set the proper /appvve switch on the fly every time user logs on)

    As I mentioned in the beginning it is neither clean nor simple but it is possible. example script code used for proof of concept (all registry locations are listed in office_keys.txt instead of searching to speed up processing. Format is registry location on a line by itself example: "HKCR:\Excel.Sheet.12\shell\Open\command" . Connection group published to user starts with "office". Change as needed)

    New-PSDrive -PSProvider Registry -Name HKCR -Root HKEY_CLASSES_ROOT
    $officeKeys = Get-Content .\office_keys.txt
    $cg = Get-AppvClientConnectionGroup office*
    
    If ($cg) {
        $appvve = "$($cg.GroupID)_$($cg.VersionID)"
        foreach ($key in $OfficeKeys) {
            $command = get-itemproperty $key.ToString() "command"|select -ExpandProperty command
            if ($command -notmatch "appvve") { $command = $command + " /appvve:$appvve"}
            Set-ItemProperty -Path $key.ToString() -Name Command -type MultiString -Value $command
        }
    }

    Regards,

    Gantcho Radoslavov

     


    Friday, September 19, 2014 5:55 PM
  • Gotcha.

    We are in a very similar situation, we run a lot of stateless VDIs (VMWare).  One trick we have used...its not always pretty, but it does work around this issue.  For the record, I really wish MS would give a way of enabling run virtual to user published packages...however that happens, even if it means globally publishing via user based targeting would work for us because stateless VDIs aren't shared machines.

    Anyway, here is the workaround.
    We have used the add package system context scripting event to publish the package globally - manually through powershell.  Essentially you just kicking off publish-appvclientpackage -name "package" -global at that scripting event (if I recall correctly just don't make your script WAIT).

    We have a handful of packages where we actually publish to a user, that then publishes globally, and then populates the HKLM Run Virtual keys as part of that same scripting event.

    EDIT:  Forgot to mention... I can try to give you more information, but also keep in mind that to have a CG use runvirtual, the CG has to be published globally, which means ALL the packages have to be published globally. 
    Friday, September 19, 2014 7:07 PM

All replies

  • Hello,

    Not really sure what you are aiming at here...

    But yes, you can achieve this - however if Explorer.exe is already running in an instance it will use the native registry.

    There is a setting to run multiple instances of Explorer.exe, which might resolve the issue. You would need to validate the exact scenario and if that suites you.

    This outdated and non-applicable article is most likely still valid on howto configure the Seperate Process for Explorer.exe

    http://support.microsoft.com/kb/156366


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

    Wednesday, September 17, 2014 9:43 PM
  • Hi Nicke,

    Thank you for your response though i am not sure i follow your thought. Are you suggesting to run the shell as virtualized explorer and thus all processes started to run in an app-v bubble? If that is possible it is an interesting concept.

    My goal is to devise a plan (and i have seen other threads discussing the same goal) for providing support for multiple office add-in combinations for different user communities. At the moment all options are possible though the clock is ticking and i may soon have a deadline. 

    Among the options considered are:

    Locally installed office with local add-ins. Too many gold image changes required and longer SLAs. Not everyone needs all add-ins though we can control them for the most part with loadbehavior registry keys of the add-ins.

    Locally installed office with global publishing of add-ins and use of runvirtual registry key. This will force us to maintain more desktop pools and requires more resources in general.

    Virtual office and virtual add-ins. At the moment requirements do not allow upgrade to office 2013. Still best practice recommends targeting office globally and not per user

    One of my preferred choices remains local office with connection group combining add-ins and office shortcuts. We have made proof of concept virtual packages and add-ins load as expected when virtual shortcuts are used to launch office apps. We can instruct users not to use start/run (here is the part where i question why runvirtual reg key is not supported with user publishing,) however opening an office file should open the app within the bubble and add-ins should be available at that time. This is the place where i struggled. Shortcuts show up on the FTA page of the sequencer and i can create file associations but they are not working as expected. (FTAs are launching the shortcut as expected but file is not properly loaded within office app, after all the file name is passed to a shortcut or not to the proper progid)

    I would welcome any other options at solving the office add-ins support or guidance of getting the FTA so office files can open properly inside the bubble.

    Hope this clears any confusion.

    Thank you,


    Thursday, September 18, 2014 1:01 AM
  • Hello,

    From my point of view, your issue has nothing todo with FTAs.

    You can publish Connection Groups to a user, with a plugin published to the user, however Office 20XX still published globally.

    See the steps for implementing it in App-V 5.0 SP2 Hotfix 5 - which is also required;

    http://support.microsoft.com/kb/2963211


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

    Thursday, September 18, 2014 7:48 AM
  • Thank you for your reply

    Your suggestion (office globally, add-in user published in CG) would be one of the options. As with all the others it doesn't appear to be a clean way of doing it as App-V server infrastructure is not supported. That will mean manually creating (and updating) xml files, using login scripts etc to make it happen. All the others have similar limitation. (This is where I urge MS to re-think their office add-in support and improve it in next version/update.) All that is provided I get buy in for virtualizing office in the first place. There is quite a reluctance at that (myself included) but that is a different topic.

    As for the other people that may be looking to do something similar. It is possible (though not straightforward) to achieve this (using file extensions to open apps inside appv bubble) This may not be the best way to do it but I have found it to work so I will share it.

    file extensions are stored in the registry in HKEY_CLASSES_ROOT (among other places). Example .xlsx. Underneath that particular key there are subkeys (either openwithprogids or progid/long key itself example: Excel.Sheet.12 - more information on that bing search for "msdn cc144148" as I am unable to post links at this time). Same ProgIDs/long names are defined again in HKEY_CLASSES_ROOT (HKCR\Excel.Sheet.12). Under that key there should be shell key with one or more commands (open, edit, etc). Yet another subkey called command will reveal the executable called for the extension (example: HKEY_CLASSES_ROOT\Excel.Sheet.12\shell\Open\command). Default property shows clear text command, command property shows the same command possibly with different encoding (example for excel: xb'BV5!!!!!!!!!MKKSkEXCELFiles>VijqBof(Y8'w!FId1gLQ /dde)

    This is the place where I tested adding the appvve:/guid_guid switch and it worked.

    Hint: searching registry for particular command (xb'BV5!!!!!!!!!MKKSkEXCELFiles>VijqBof(Y8'w!FId1gLQ) helps revealing all location that need changing per application. In my example there were 61 locations for excel alone. Powershell is really helpful with that. Search registry script bing search "Searching the Registry with PowerShell Bill Stewart" (another hint: use [regex]::escape(xb'BV5!!!!!!!!!MKKSkEXCELFiles>VijqBof(Y8'w!FId1gLQ))

    Since you will probably have more than one combination of add-ins like me you want to use connection groups. If you want to use this option you have to use only one connection group for a particular user for the same file extension. Login script can be used to set the proper /appvve switch on the fly every time user logs on)

    As I mentioned in the beginning it is neither clean nor simple but it is possible. example script code used for proof of concept (all registry locations are listed in office_keys.txt instead of searching to speed up processing. Format is registry location on a line by itself example: "HKCR:\Excel.Sheet.12\shell\Open\command" . Connection group published to user starts with "office". Change as needed)

    New-PSDrive -PSProvider Registry -Name HKCR -Root HKEY_CLASSES_ROOT
    $officeKeys = Get-Content .\office_keys.txt
    $cg = Get-AppvClientConnectionGroup office*
    
    If ($cg) {
        $appvve = "$($cg.GroupID)_$($cg.VersionID)"
        foreach ($key in $OfficeKeys) {
            $command = get-itemproperty $key.ToString() "command"|select -ExpandProperty command
            if ($command -notmatch "appvve") { $command = $command + " /appvve:$appvve"}
            Set-ItemProperty -Path $key.ToString() -Name Command -type MultiString -Value $command
        }
    }

    Regards,

    Gantcho Radoslavov

     


    Friday, September 19, 2014 5:55 PM
  • Hi Gantcho,

    Been following this thread for a while, I think what you posted above is very interesting.  What do you mean when you say,

    "Locally installed office with global publishing of add-ins and use of runvirtual registry key. This will force us to maintain more desktop pools and requires more resources in general."

    Why is it that using runvirtual would make this process harder for you? 

    Friday, September 19, 2014 6:23 PM
  • Hi agallucci,

    runvirtual is registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\RunVirtual. It allows to force an executable to run in specific App-V bubble. It is however (to my knowledge) only available for globally published apps (published to computers and not to users) For more information seach for KB2848278. What it allows you is to force excel to start in the virtual environment of your excel add-in no matter if the person used a shortcut, start\run or opened an excel document

    On making it harder, we use stateless VMs in VDI environment. This means that people with different office add-in requirements will get random workstation whenever they login. If I need to publish to different desktops I have to increase the number of pools available, increase the disaster recovery capacity, increase maintenance work to maintain those pools.

    Cheers


    Friday, September 19, 2014 6:35 PM
  • Gotcha.

    We are in a very similar situation, we run a lot of stateless VDIs (VMWare).  One trick we have used...its not always pretty, but it does work around this issue.  For the record, I really wish MS would give a way of enabling run virtual to user published packages...however that happens, even if it means globally publishing via user based targeting would work for us because stateless VDIs aren't shared machines.

    Anyway, here is the workaround.
    We have used the add package system context scripting event to publish the package globally - manually through powershell.  Essentially you just kicking off publish-appvclientpackage -name "package" -global at that scripting event (if I recall correctly just don't make your script WAIT).

    We have a handful of packages where we actually publish to a user, that then publishes globally, and then populates the HKLM Run Virtual keys as part of that same scripting event.

    EDIT:  Forgot to mention... I can try to give you more information, but also keep in mind that to have a CG use runvirtual, the CG has to be published globally, which means ALL the packages have to be published globally. 
    Friday, September 19, 2014 7:07 PM
  • Thanks agallucci,

    I got an idea how your solution works. Doesn't make it any pretier than mine, though it covers the scenario where user might use start\run to execute the app. My solution will also not work on a RDS server as you can only set one appve guid in HKCR. For the record I tried using environment variable which would have made that possible but it doesn't expand it.

    Really a call to Microsoft to take a look at the hoops the people are going through to make this work.

    I will have to present all these options and hope management doesn't throw App-V out of the picture alltogether.

    Friday, September 19, 2014 7:53 PM
  • Interesting way of making the virtual app available through the local excel FTA's.... But my question; you created a dummy package with only the shortcuts to excel/word/etc... but why did not you create the FTA's also? We have a simular situation, where we created a dummy package for the office shortcuts and FTA's (office locally isntalled). Virtual Addins will dynamically be added together with the dummypackage to a connectiongroup (custom script at logon). But I agree, they should make runvirtual available for user published packages, not only global ones.
    Wednesday, September 24, 2014 10:18 AM
  • Hi Tiberivs,

    I tried creating the FTA's in the package. I tried two ways: assigning the extensions to the lnk files and I tried adding the office shortcuts without publishing them to neither desktop, nor start menu. Both of them will force opening a file to start the app in the bubble. The issue was that the document will not open as expected inside the office app. Ability to manage FTA's from sequencer is quite limited compaired to what MS has using different verbs, different ProgIds, etc.

    Friday, September 26, 2014 2:44 PM