none
Rebuild App-V 5.x Shortcuts? RRS feed

  • Question

  • Is there an easy, fast, way to republish/rebuild/recreate the App-V 5 published shortcuts? If there is, the following info might not be necessary.

    Ok, so a little history. We use the full App-V infrastructure and are migrating from 4.6 to 5.0. With 4.x and managed profiles, we would often get orphaned shortcuts, and sometimes duplicates. Since the valid/active shortcuts were rebuilt/recreated each time the client refreshed the published app list, we could have a user delete any questionable shortcuts (or all of their shortcuts), and refresh. Once this was done, they would have all their valid, published, shortcuts.

    This also helped out a ton if a user decided to accidently or purposefully delete a shortcut for whatever reason, and then later wondered where it disappeared to.

    Now, in migration mode, we are testing our first round of App-V 5 apps, (testing, while keeping the old 4.6 apps published and available for technical support). When the App-V 5 apps are first published, the shortcuts are updated (and I believe the entire app is removed from the 4.6 client), but the problem is, that it doesn't stay that way. On the next 4.6 refresh, that (4.6) client recognizes that the application is still published to the 4.6 management server, re-activates the package, and takes over the shortcuts again. If I could easily get the 5.0 shortcuts republished, it wouldn't be much of an issue since we are, as stated before, in our testing round of our migration. Currently the only way I can get this done is to unpublish and republish the app using one of these 2 commands and following with a client refresh...

    Get-AppvClientPackage | Unpublish-AppvClientPackage | Remove-AppvClientPackage

    or

    Get-AppvClientPackage | Unpublish-AppvClientPackage

    The first takes forever to fully remove all the packages from the client, but the refresh is fairly quick, and the second unpublishes the packages quickly, but then the refresh takes forever.

    Once we get past testing and begin a production type roll-out, we can disable the old 4.6 package at the same time we enable the 5.0 package, or possibly even modify shortcut locations to isolate them from their 4.6 counterparts, but then we still have the issue where some users randomly decide to delete a shortcut... How do we instruct frontline support to fix the issue? If they know 'exactly' what is missing, they can unpublish/republish that specific package, but they might not have that info.

    Monday, August 5, 2013 5:46 PM

Answers

  • OK - I think I may have an idea of what is happening.

    There's a new SFTMIME command with App-V 4.6 SP2. It is used by the App-V 5 client to communicate which of the two clients owns the Shortcuts and FTA's.

    The command that is sent to the 4.6 client is:

    SFTMIME.EXE CONFIGURE PACKAGE:"{GUID}" /NO-UPDATE-FTA-SHORTCUT TRUE /CONSOLE

    You can try this command manually or set the specific key it modifies. I am wondering if that key is not set correctly.

    This command writes to the NoUpdateFTAShortcut registry value for the 4.6 package setting the value to 1. If the value is at 0, then the 4.6 client will reclaim the shortcut's and FTA's for this application on the next 4.6 refresh. 


    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    • Marked as answer by DraBaZ Monday, September 2, 2013 5:31 PM
    Wednesday, August 7, 2013 6:44 PM
  • UPDATE

    After opening a support case up with the MS App-V team, and after some discussion they explained to me that the App-V 5 client does 'not' pass this command to the 4.6 client, and therefore does not permanently claim FTAs beyond the initial publish. I was hoping for a smoother (integrated) solution from them, but they could not provide it. So I wrote a PowerShell script to initially process through entire App-V 5 package directory, individually create powershell scripts for each package on publish and unpublish to run that SFTMIME command to enable or disable the NoUpdateFTAShortcut registry value. The script then modifies the user and system config files for each package to point to the newly created scripts. Then we just applied the config files to each respective package. The modified config files didn't work (in that they couldn't be imported) for approximately 1 in 50 packages for whatever reason, so we're taking care of those manually. For reference, this is an annoying solution when you have multi-hundreds of packages visible to a user (support staff mostly) because each package takes about an extra 10-15 seconds to run the PowerShell script on Publish, which adds up.

    There is still no easy way that we could find to repair deleted shortcuts, or enforce published shortcuts short of unpublishing and publishing a package, but the solution above seems to work for the majority of cases.

    Thanks Steve Thomas for getting me on a starting path that provided the solution.

    • Marked as answer by DraBaZ Monday, September 2, 2013 5:31 PM
    Monday, September 2, 2013 5:31 PM

All replies

  • If you have shortcuts with the same name and going to the same folder, one will over-write the other. No matter what the technology.

    When you are pushing out the App-V 5.0 version of an app, why not remove the 4.x sequenced version first for the user who is testing?

    If you can't do that, for the sake of testing, you could publish the App-V 5.0 Shortcuts to a different folder e.g. Programs\AppV Applications\ Also, They could Remove just that app by passing the Application name as a parameter and then do a publishing server refresh e.g. Sync-AppVPublishingServer. It should sync only the applications that are not present which the user\machine is entitled to.. Removing all application, is not necessary


    PLEASE MARK ANY ANSWERS TO HELP OTHERS Blog: rorymon.com Twitter: @Rorymon

    Monday, August 5, 2013 8:46 PM
  • Hello,
    if you convert a package (using the PowerShell Conversion modules) they will tag the new package with the GUIDs of the old one and set it to over-take any previous entry points.

    You can verify this via the Deployment config (or User-config?), I can't remember the XML-syntax, how this works.


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

    Tuesday, August 6, 2013 5:51 AM
  • additional to the requirement of converted packages (v4 and v5 package having the same GUID), also the App-V 5 client has to have the MigrationMode setting enabled... and the App-V 4 client mist be 4.6 SP2 


    Falko

    Twitter @kirk_tn   |  Blog kirxblog   |  Web kirx.org

    Tuesday, August 6, 2013 2:10 PM
    Moderator
  • When it comes to overlapping shortcuts and FTA's between a modern AppV package and a legacy App-V package, be aware of the following:

    Legacy App-V package must be 4.6 SP2 (as you know already including all of the previous replies ;) )

    The Migration Mode Setting: This is a setting in the registry (HKLM\Software\Microsoft\AppV\Client\Coexistence) - value is MigrationMode. This is automatically enabled if 5.0 is installed on top of 4.6 SP2

    The ManagingAuthority Setting: This is in the Deployment/User Config XML. This is automatically created by Package Converter when converting 4.6 packages.

    Check the setting:

    <UserConfiguration  PackageId="{GUID}" DisplayName="App Name" xmlns="http://schemas.microsoft.com/appv/2010/userconfiguration">
    <ManagingAuthority TakeoverExtensionPointsFrom46="true" PackageName="{GUID}"/>
    </UserConfiguration>

    Another thing that could be going on, if you add the converted package to the App-V 5.0 client first, then add the legacy package to the 4.6 SP2 client, you will run into problems. If this has happened, Unpublish both packages then republish using 4.6 one first.

    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    Tuesday, August 6, 2013 3:00 PM
  • If you have shortcuts with the same name and going to the same folder, one will over-write the other. No matter what the technology.

    When you are pushing out the App-V 5.0 version of an app, why not remove the 4.x sequenced version first for the user who is testing?

    If you can't do that, for the sake of testing, you could publish the App-V 5.0 Shortcuts to a different folder e.g. Programs\AppV Applications\ Also, They could Remove just that app by passing the Application name as a parameter and then do a publishing server refresh e.g. Sync-AppVPublishingServer. It should sync only the applications that are not present which the user\machine is entitled to.. Removing all application, is not necessary


    Thank you for the response. Unfortunately we cannot remove the 4.x version at the same time during testing, because our testing, support staff still needs to have access to the 4.x version until we move to production. As I said in my original post, the shortcut isolation has been considered, and might be implemented during the testing period. Also, I did state that support could remove the single application, but they do not always know what application needs to be removed. If a user calls and says "I accidentally deleted my Adobe" the support staff doesn't doesn't necessarily know what "Adobe" product the user is asking for, and in 4.x they only had to walk the user through a publishing server refresh. Now there is no quick band-aid, they will have to determine access, compare to what's visible, determine the missing shortcut, figure out what the package name is, remove the specific package, and finally initiate a Sync. It's doable, but is a lot of work for a shortcut.
    Tuesday, August 6, 2013 3:00 PM
  • Hello,
    if you convert a package (using the PowerShell Conversion modules) they will tag the new package with the GUIDs of the old one and set it to over-take any previous entry points.

    You can verify this via the Deployment config (or User-config?), I can't remember the XML-syntax, how this works.


    Nicke, you are correct that the new client will initially take over the package from the old client. However, unless you disable (or remove access to) the old package from the management server, the old 4.6 client will reactivate, and overwrite the shortcuts on the next publishing refresh. Unfortunately, we aren't able to disable or remove access to the old package at this time. The 5.0 client never attempts to reclaim ownership of those packages, and doesn't fix shortcuts after the first-publish job.
    Tuesday, August 6, 2013 3:07 PM
  • additional to the requirement of converted packages (v4 and v5 package having the same GUID), also the App-V 5 client has to have the MigrationMode setting enabled... and the App-V 4 client mist be 4.6 SP2 


    Falko

    As stated in my original post, we are using migration mode. I suppose it's not explicitly stated, but the setting is, in fact, enabled. Though I did run a test from one of our clients to see if disabling migration mode changed the handling of shortcuts by the 5.0 client, but the shortcut handling stayed the same.
    Tuesday, August 6, 2013 3:10 PM
  • Hello,

    To enable migrationmode is not suffice.

    You need to define which package it over-takes, using GUIDs.

    Is this defined in the new packages?


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

    Tuesday, August 6, 2013 3:57 PM
  • When it comes to overlapping shortcuts and FTA's between a modern AppV package and a legacy App-V package, be aware of the following:

    Legacy App-V package must be 4.6 SP2 (as you know already including all of the previous replies ;) )

    The Migration Mode Setting: This is a setting in the registry (HKLM\Software\Microsoft\AppV\Client\Coexistence) - value is MigrationMode. This is automatically enabled if 5.0 is installed on top of 4.6 SP2

    The ManagingAuthority Setting: This is in the Deployment/User Config XML. This is automatically created by Package Converter when converting 4.6 packages.

    Check the setting:

    <UserConfiguration  PackageId="{GUID}" DisplayName="App Name" xmlns="http://schemas.microsoft.com/appv/2010/userconfiguration">
    <ManagingAuthority TakeoverExtensionPointsFrom46="true" PackageName="{GUID}"/>
    </UserConfiguration>

    Another thing that could be going on, if you add the converted package to the App-V 5.0 client first, then add the legacy package to the 4.6 SP2 client, you will run into problems. If this has happened, Unpublish both packages then republish using 4.6 one first.

    Steve Thomas, Senior Consultant, Microsoft

    Everything you have suggested is already in place. 4.6SP2 clients with 5.0SP1 installed over, with verifictation of migrationmode enabled. UserConfig settings are verified. All current apps being tested were already in 4.6, and converted over, and those settings were already in place. This also means that we've never published a 4.6 package after already publishing it in 5.0.

    So basically what I'm getting from the all responses so far is that there is nothing I can do to 'just rebuild the shortcuts of published apps', short of unpubishing and republishing the application(s).

    Also, I am still unclear on if I'm experiencing the expected results with regards to the behavior and interaction of the 4.6SP2 and 5.0SP1 clients. I was focusing my original question on the shortcuts, but it does, in fact, affect the FTAs as well. Here's a reiteration of what I experience. 1: Client 4.6SP2 has published app. 2: Client 5.0SP1 is installed, and verified in migrationmode. 3: Client 5.0 publishes the app, takes over the shortcuts and FTAs, and removes the application from the 4.6SP2 client. 4:on login or manual refresh, because it's still enabled, the 4.6PS2 client checks its publishing server, republishes the app, takes over the shortcuts and FTAs. 5:The 5.0SP1 client never attempts to reclaim the FTAs or shortcuts, unless the package is republished (i.e. removed before a sync). I can still access the 5.0 app if a shortcut exists (because it was copied, or published to a different location) but the FTAs still are pointed to the 4.6 client.

    Is that the expected behavior? or am I having a problem that I didn't even know was there? My original thought were that the migrationmode was expected to only be used in conjuction with disabling the old application on the 4.6 management server, and that was why I was experiencing these issues.

    Thanks for your reply.

    Tuesday, August 6, 2013 7:55 PM
  • Hello,

    To enable migrationmode is not suffice.

    You need to define which package it over-takes, using GUIDs.

    Is this defined in the new packages?


    Nicke Källén


    Yes, it was confirmed in my earlier post that the migration mode initially works and takes over the package as expected, but then the 4.6 client reclaims those package shortcuts and FTAs when it does a publishing refresh. I also manually confirmed that the packages converted indeed had the correct GUIDs defined for the package it was expected to overtake.
    Tuesday, August 6, 2013 7:59 PM
  • OK - I think I may have an idea of what is happening.

    There's a new SFTMIME command with App-V 4.6 SP2. It is used by the App-V 5 client to communicate which of the two clients owns the Shortcuts and FTA's.

    The command that is sent to the 4.6 client is:

    SFTMIME.EXE CONFIGURE PACKAGE:"{GUID}" /NO-UPDATE-FTA-SHORTCUT TRUE /CONSOLE

    You can try this command manually or set the specific key it modifies. I am wondering if that key is not set correctly.

    This command writes to the NoUpdateFTAShortcut registry value for the 4.6 package setting the value to 1. If the value is at 0, then the 4.6 client will reclaim the shortcut's and FTA's for this application on the next 4.6 refresh. 


    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    • Marked as answer by DraBaZ Monday, September 2, 2013 5:31 PM
    Wednesday, August 7, 2013 6:44 PM
  • OK - I think I may have an idea of what is happening.

    There's a new SFTMIME command with App-V 4.6 SP2. It is used by the App-V 5 client to communicate which of the two clients owns the Shortcuts and FTA's.

    The command that is sent to the 4.6 client is:

    SFTMIME.EXE CONFIGURE PACKAGE:"{GUID}" /NO-UPDATE-FTA-SHORTCUT TRUE /CONSOLE

    You can try this command manually or set the specific key it modifies. I am wondering if that key is not set correctly.

    This command writes to the NoUpdateFTAShortcut registry value for the 4.6 package setting the value to 1. If the value is at 0, then the 4.6 client will reclaim the shortcut's and FTA's for this application on the next 4.6 refresh. 


    Steve Thomas, Senior Consultant, Microsoft

    App-V/MED-V/SCVMM/Server App-V/MDOP/AppCompat

    http://blogs.technet.com/gladiatormsft/
    The App-V Team blog: http://blogs.technet.com/appv/
    The MED-V Team Blog: http://blogs.technet.com/medv
    The SCVMM Team blog: http://blogs.technet.com/scvmm/

    “This posting is provided "AS IS" with no warranties, and confers no rights. User assumes all risks.”

    This seems to be an accurate assessment. I couldn't find any reference to the NoUpdateFTAsShortcuts (reg Dword) in the HKLM paths. However, I did find that it exists for all applications in the HKCU\Software\Microsoft\SoftGrid\4.5\Client\Applications\{specific application} keys. Unfortunately they are all populated {0} (FALSE). Running the manual sftmime command that you posted updated this value to {1} (TRUE) at only this location. I checked the other HKLM keys to see if it did anything there, but it had not changed anything.

    Following this, I removed, and resynced the application I was testing with in App-V 5. Validated the current shorcuts pointed to the App-V 5 version. Refreshed the publishing server on the App-V 4.6 SP2 client. The App-V 4.6 client took over everything except that application I was testing, which still pointed to the App-V 5.0 version.

    So, any idea what might be causing the App-V 5 client to not update this accordingly?

    Wednesday, August 7, 2013 8:39 PM
  • UPDATE

    After opening a support case up with the MS App-V team, and after some discussion they explained to me that the App-V 5 client does 'not' pass this command to the 4.6 client, and therefore does not permanently claim FTAs beyond the initial publish. I was hoping for a smoother (integrated) solution from them, but they could not provide it. So I wrote a PowerShell script to initially process through entire App-V 5 package directory, individually create powershell scripts for each package on publish and unpublish to run that SFTMIME command to enable or disable the NoUpdateFTAShortcut registry value. The script then modifies the user and system config files for each package to point to the newly created scripts. Then we just applied the config files to each respective package. The modified config files didn't work (in that they couldn't be imported) for approximately 1 in 50 packages for whatever reason, so we're taking care of those manually. For reference, this is an annoying solution when you have multi-hundreds of packages visible to a user (support staff mostly) because each package takes about an extra 10-15 seconds to run the PowerShell script on Publish, which adds up.

    There is still no easy way that we could find to repair deleted shortcuts, or enforce published shortcuts short of unpublishing and publishing a package, but the solution above seems to work for the majority of cases.

    Thanks Steve Thomas for getting me on a starting path that provided the solution.

    • Marked as answer by DraBaZ Monday, September 2, 2013 5:31 PM
    Monday, September 2, 2013 5:31 PM
  • >MigrationMode.This is automatically enabled if 5.0 is installed on top of 4.6 SP2

    Not correct, we had to enable it manually.


    Jan Hoedt

    Tuesday, August 18, 2015 2:13 PM