locked
Appv Client does not work in Terminal Server 2008 RRS feed

Answers

  • What essentially has happened is that an application was launched associated with one package then another new application with a different GUID was attempted on the same machine. It can happen after an OSD file has been cached but the original package (often an Office package) was switched to a different package hence the GUID Attribute for the CODEBASE element changes.

    For example, a launch of an OSD (either by direct SFTRAY launch, IFS, or publish via Citrix or TSREMOTEAPPS points to an identically named OSD file as to one that has been cached but from a different package (hence the different package GUID.)

    Then you get the following error when trying to launch:

    The Application Virtualization Client could not launch the application you requested.

    The Application Virtualization Client could not use the specified OSD file because the application package identifier has changed. Report the following error code to your System Administrator.

    Error code: xxxxxxx-xxxxxx44-00001004
     

    And the following shows up in the SFTLOG.TXT
     
    The app manager could not create an application from ‘<PATH>\<APPNAME.OSD>’ (rc 0C403644-00001004).

    If you recently re-sequenced a package with the same names and applications and tried to load it with a client that had the previous package still cached, this can happen.

    1. Compare the GUID in the CODEBASE element in the PSD file you are trying to launch with what is currently cached.
     
    2.) Then on the App-V Client’s administrative console, locate the application.
     
    3.) Right-click the application and select “properties.”

    4.) Copy the local OSD File.

    5.)Open that file in Notepad and check to see if the GUID is different

    If the Locally cached OSD file is different, verify that GUID is registered as a package in the App-V Client’s registry.

    Once that has been verified, unregister that package by running the following from an Administrative command prompt
    SFTMIME DELETE PACKAGE:{GUID}

    Then refresh against the server and reload the application.


    Steve Thomas, SSEE, Microsoft
    App-V/MED-V/SCVMM/SCCM/AppCompat
    http://madvirtualizer.wordpress.com/
    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.”
    • Proposed as answer by znack Sunday, June 12, 2011 7:56 PM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 11:25 AM
    Saturday, June 4, 2011 12:22 AM

All replies

  • Hello,

    You most likely have a conflict with a previously created package that has not executed on your clients, but only on your terminal server.

    See this blog-article howto avoid creating packages with conflicts;

    http://www.viridisit.se/eng/blog/?p=921

    Apart from the above - any combination of Name + Version and OSD-file name must be unique

     


    /Znack
    Tuesday, May 31, 2011 4:19 AM
  • If you are using a management Server, chances are a new sequence was copied to the content folder and/or imported without the clients purging the existing application(s) out of its cache.

     


    Steve Thomas, SSEE, Microsoft
    App-V/MED-V/SCVMM/SCCM/AppCompat
    http://madvirtualizer.wordpress.com/
    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.”
    Thursday, June 2, 2011 11:01 PM
  • What essentially has happened is that an application was launched associated with one package then another new application with a different GUID was attempted on the same machine. It can happen after an OSD file has been cached but the original package (often an Office package) was switched to a different package hence the GUID Attribute for the CODEBASE element changes.

    For example, a launch of an OSD (either by direct SFTRAY launch, IFS, or publish via Citrix or TSREMOTEAPPS points to an identically named OSD file as to one that has been cached but from a different package (hence the different package GUID.)

    Then you get the following error when trying to launch:

    The Application Virtualization Client could not launch the application you requested.

    The Application Virtualization Client could not use the specified OSD file because the application package identifier has changed. Report the following error code to your System Administrator.

    Error code: xxxxxxx-xxxxxx44-00001004
     

    And the following shows up in the SFTLOG.TXT
     
    The app manager could not create an application from ‘<PATH>\<APPNAME.OSD>’ (rc 0C403644-00001004).

    If you recently re-sequenced a package with the same names and applications and tried to load it with a client that had the previous package still cached, this can happen.

    1. Compare the GUID in the CODEBASE element in the PSD file you are trying to launch with what is currently cached.
     
    2.) Then on the App-V Client’s administrative console, locate the application.
     
    3.) Right-click the application and select “properties.”

    4.) Copy the local OSD File.

    5.)Open that file in Notepad and check to see if the GUID is different

    If the Locally cached OSD file is different, verify that GUID is registered as a package in the App-V Client’s registry.

    Once that has been verified, unregister that package by running the following from an Administrative command prompt
    SFTMIME DELETE PACKAGE:{GUID}

    Then refresh against the server and reload the application.


    Steve Thomas, SSEE, Microsoft
    App-V/MED-V/SCVMM/SCCM/AppCompat
    http://madvirtualizer.wordpress.com/
    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.”
    • Proposed as answer by znack Sunday, June 12, 2011 7:56 PM
    • Marked as answer by Aaron.ParkerModerator Saturday, November 17, 2012 11:25 AM
    Saturday, June 4, 2011 12:22 AM