Steps on how to re-publish applications RRS feed

  • Question

  • Hi all,

    We currently have an App-V 4.6 SP1 infrastructure and it all seems to be going well, but we're not entirely sure of the exact steps to re-publish applications within certain scenarios. So I'm wondering if someone can help guide us...

    1. Upgrading applications:

    We have a centralised repositry of applications, which holds the vendor source files, documentation, and our packaged/sequenced applications. We then copy the sequenced application folder (example: "proj2007Std_v001") which contains all of the sequence files into the root of the content share.

    E.g. \\servername\content\proj2007Std_v001\

    We then create the appropriate AD groups, and set-up licensing etc, import and publish the apps using the App-V management console. All of this goes well. However when we find an issue with the application, we open the application for editing and save the newer version. Thus the .sft file number incrememts.

    My question is what files do we need to copy into the "proj2007Std_v001" folder in the content share, all of them or just the files which have changed, and is it safe to overwrite the files?

    Also, am I right in saying that we just select 'Add Version' within the Packages section in the Console?


    2. Running applications side by side:

    Let's just say that we occassionly need to run an application side by side with the same application. Eg. Project2007Std and Project2007Std. Don't ask why! What's the best way of doing this?

    The reson why I ask this is that we've run into issues whereby the "name" (Microsoft Office Project 2007) and "version" (12.0.6423.1000) are the same, so we've had to amend both in the SOFTPKG element in the package. We of course call the saved file different names (by adding a version number (Project2007Std_v1/v2/v3 etc.. ) and saving into a different folder in the Content share.

    I was wondering if editing the SOFTPKG name and version is standard practise and if this is correct?



    P.S. Are their any courses in the UK that are good for these kind of questions with App-V? I've been on the official Microsoft course and the material was rather basic to say the least, and the trainer we had was absolutely USELESS!

    I'm looking for a course that tackle real world issues and covers some intermediate / advanced concepts.

    Friday, June 10, 2011 3:38 PM

All replies

  • That's fantastic, as we are having the exact same issue here now. Trying to define a process to "branch" an app so it can go through a UAT phase, then retire the old and the new branched app becomes the new version.

    I've recently discovered that Branching worked up to 4.5. Beyond that, it's broke. I'm not hi-jacking your thread, just letting you know, you are not alone :)

    To answer your first question, I just copy the new .sft file in and import it as a new version from the Packages section. Question two is where you are not alone. This is where we're running into trouble to. Eventually, we get it working, but it use to be a lot easier when Branching worked. The Save as New is still in the v4.6 sequencer, but does not work because if the Root folder on the Q:\ drive was changed, all the virtual registry/files still point to the old Root folder.  I am bringing this up because for question two, you want to Branch the app so you can run them side-by-side. I believe this is what you are asking for.


    Friday, June 10, 2011 4:08 PM
  • Hi WorkFaster,

    Thanks for confirming question 1.

    As for Q2, yes - we're trying to branch the app and the only solution thus far is to amend the NAME and VERSION in the SOFTPKG element.

    Not exactly user friendly.

    I wasn't aware this worked in 4.5. - We've only just really started to do this is 4.6


    Friday, June 10, 2011 4:22 PM
  • I can't figure out what the point of "Save as" and then that checkbox to create a "new" app is for??
    Friday, June 10, 2011 7:29 PM
  • Saturday, June 11, 2011 7:00 AM
  • That doesn't work znack. The sequence, when launched, produces "The directory name is invalid." err: 0000010B

    All the root paths still point to the original app folder.


    Monday, June 13, 2011 3:05 PM
  • Hello,

    See this article;


    Monday, June 13, 2011 3:34 PM
  • That's not the issue :)  100's of entries in the newly created Branched app virtual registry and file system, when following the instructions from the first link, still point to the app Root folder on the Q:\ drive.



    • Proposed as answer by znack Monday, June 13, 2011 4:13 PM
    • Unproposed as answer by Aaron.ParkerModerator Saturday, November 17, 2012 2:19 PM
    Monday, June 13, 2011 3:44 PM
  • Confused... and I think I ended up hi-jacking RL57's thread here (sorry).  Can you chime in RL57?
    Monday, June 13, 2011 4:31 PM
  • Hello,

    See this page;



    Hi /Znack,

    This doesn't work as the OSD file remains the same (Microsoft Office Project 2007 12.0.6423.1000.osd) even when you Choose a different package name, different package path and Save As. Thus the question re the NAME and VERSION fields in the SOFTPKG element. (Only when amending these do both version appear for the user to launch).

    Perhaps someone else can try this?

    Wednesday, June 15, 2011 3:23 PM
  • Hello,

    You can manually alter these
    Wednesday, June 15, 2011 3:25 PM
  • Hi,

    I'm totally aware these can be amended manually - as per my original post I mention that we amend these values, but the question still stands - this is not documented and I wondering if this is related to the bug/s mentioned, as I'm presuming this is not normal practise....

    Thursday, June 16, 2011 8:55 AM
  • Hello,

    Microsoft hasn't released any practice regarding the name + version - however it is documented that there is a requirement for all applications to have a unique OSD-filename and a unique combination of Application + Version.

    Depending on your naming standards and requirements - there maybe some knowledge to reuse in terms of avoiding a duplicate scenario.

    Usually customers I deal with track this within a seperate system and use the previous .3 part of the 8.3-compliant unique asset folder to maintain a unique version number along with a unique OSD-filename.

    Thursday, June 16, 2011 9:02 AM
  • Thanks Znack,

    Apologies for the basic questions, and to top this off I don't perform the sequencing, however I have seen the sequencing person perform the tasks and he does choose a different path on the Q: drive everytime, and save as a different package name. We don't use 8.3 as we started sequencing with 4.6SP1 and it's my understanding that 8.3 is no longer needed?

    However the name of the saved package and the path doesn't seem to make any difference as to what the .OSD filename is called. - It seems to be made up of the Appname and version.

    See the sample directory output below:

    <DIR>          Firefox_3615_01_MNT_GLB Icons
    Mozilla Firefox

    So when we saved a branched / side by side (whatever it's called) we increment the version number, but this doesn't change the OSD name.

    Thursday, June 16, 2011 9:22 AM
  • Hello,

    If you do not use a 8.3-compliant name as an asset directory - then yes, you can not use it as a base for your versions. I suggest using a different way to track the versions.

    OSD-filenames has to be unique as well and their name can be manually altered - just like the Name and Version of all applications.
    Thursday, June 16, 2011 12:28 PM