locked
App-v 4.6 SP1 package editing RRS feed

  • Question

  • hi all,

     

    I've been using App-v in a POC environment I am very pleased with it. of course I am not starting this thread just to say that, which is nice :) but I actually have a question related to editing virtual application packages.

    so I am working with an application that has 2 components, server component and then client component.

     

    I am able to virtualize both and they are working very well, but now that I know the process of virtualizing them, I'd like to create one package of each and be able to to change the listner port for the server, which is in a config file, and the same change on the client, which is also in a config file.

    I'd like to then save each package under a new name and then deploy to the streaming servers.

     

    what is the right / best way to do this?

     

    It'd save me a lot of time having to sequence a little over 1300 of each :0

     

    Thanks in advance and I hope you all have a great weekend.

     

    MJ


    Mohsen Almassud
    Friday, November 18, 2011 11:43 PM

Answers

  • I don't think it'll be easy to script editing a config file, but I'll see if I can find anything online or hopefully one of the guys here will lend me a hand.

    I don't think you would really want to script the editing part as such, but rather script it so that the script copies appropriate version of the config file into package VE and as the one the application expects to see.

    Something like this:

    <SCRIPT TIMING="PRE" EVENT="LAUNCH" PROTECT="TRUE" WAIT="TRUE">

    <SCRIPTBODY>

    @copy /Y q:\package\scripts\script.v123 q:\package\app\config.cfg

    </SCRIPTBODY>

    </SCRIPT>

    ...and change the path to the "source" file according the environment. Or copy it from outside the package from some set location, if you have such available (like known network drive or local directory), to avoid packaging of all variations of the config files into that staging directory inside the package itself.

    Another idea would be to somehow utilize virtualized environment variables and pipe those using script to the config file itself (if you can figure out how to do the editing part using scripting). That way the script could be static and you would only need to change the virtualized environment variables per each OSD.

    Having 1300 branched copies of the same package does sound bit excessive, like others have mentioned. I would seriously consider having one "master" package and X number of OSD files which handle the customization per customer.

     


    br,
    Kalle Saunamäki
    http://blog.gridmetric.com/
    Sunday, November 20, 2011 9:04 PM
    Moderator

All replies

  • Hello,

    Application Virtualization only supports virtualization of client-applications.

    No full software suites are supported as a secondary package
    See the sequencing whitepaper;

    http://technet.microsoft.com/en-us/appvirtualization/cc843994

    If you need to virtualize server applications, see the to-be-released Server App-V;
    http://blogs.technet.com/b/serverappv/



    /Znack
    Saturday, November 19, 2011 7:18 AM
  • You could use a PRE LAUNCH script in the OSD file to make the changes to the configuration files at runtime: http://support.microsoft.com/kb/939085

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.
    Saturday, November 19, 2011 8:03 AM
    Moderator
  • Hello,

    Use Packet Branching, if necessary;

    http://blogs.technet.com/b/appv/archive/2007/09/25/methods-for-upgrading-or-updating-virtualized-applications.aspx

    However, I do suggest that Aarons approach of building a script that has logic built into it which can manipulate the configuration.

     


    /Znack
    Saturday, November 19, 2011 9:41 AM
  • Aron,

     

    Thanks for taking the time replying to my question.

     

    I checked the article out, and I am not sure how would PRE LAUNCH script could help in creating mutiple app-v packages from a single one without having to sequence over and over.

     

    could you please explain it to me?

     

    Thanks again 


    Mohsen Almassud
    Saturday, November 19, 2011 9:42 AM
  • Hello,

    You would not focus on multiple packages, instead you would focus on having a single package.

    The script would alter the configuration for the session beeing depending on the input you provide.


     It seems that you have already set your mind to a specific technical solution - I would suggest you test the one you have in mind in a real lab and determine if it suites your scenario. If it doesn't, you should look into the alternatives we have suggested


    /Znack
    • Edited by znack Saturday, November 19, 2011 9:48 AM
    • Proposed as answer by Aaron.ParkerModerator Sunday, November 20, 2011 9:58 AM
    Saturday, November 19, 2011 9:47 AM
  • I checked the article out, and I am not sure how would PRE LAUNCH script could help in creating mutiple app-v packages from a single one without having to sequence over and over.

    As Znack says - change the configuration file on the fly, before the application starts. The script could determine which machine the package is running on and change the configuration file accordingly

    This forum post is my own opinion and does not necessarily reflect the opinion or view of Microsoft, its employees, or other MVPs.
    Saturday, November 19, 2011 10:24 AM
    Moderator
  • it sounds like a good solution, but then we'll have the same package name running for all customers and that would cause a mess that we can avoid by having a single package for each customer and that's this.

     

    so I guess I should've mentioned this, but the same application services all the customers with a minor change, which is what database server they point to.

    so it'll be something like this:

     

    Customer1:

    DB-SRV1

    DB1

    ---------------------

    Customer2:

    DB-SRV1

    DB2

    --------------------

    Customer3:

    DB-SRV1

    DB3

    --------------------

     

    and so on.


    Mohsen Almassud
    Saturday, November 19, 2011 12:23 PM
  • How about creating what's called a branched upgraded of each. You open the existing sequenced app of each with the sequencer. Change the name and do a save as. For the configuration change I'd suggest managing it via a pre-script as Znack has suggested. Once you have the script down, you can continue to re-use it in your new versions.

    How often does the config file change? If I was you I think I'd look at what the exact requirements are and then make a game plan around how often it changes and what changes are likely. Maybe it would suit to only change the Name tag in the OSD, do you need to support old versions etc.

    Sunday, November 20, 2011 2:36 AM
  • I thought about doing this and I am testing it now, but I am not sure about the script part, because I never used it before and don't have enough information about it.

     

    the way those packages change always, because each new customer will have their own database, so we'll have to open the package and make this change in the config file. also I am not sure how the package names will end up being, because I am just opening the package with edit, and then I find the config file in the Q: drive, change it, and then do a save as, but I am still testing to see if this alone will work any way.

     

    I don't think it'll be easy to script editing a config file, but I'll see if I can find anything online or hopefully one of the guys here will lend me a hand.

    Thanks

     


    Mohsen Almassud
    Sunday, November 20, 2011 4:34 AM
  • I don't think it'll be easy to script editing a config file, but I'll see if I can find anything online or hopefully one of the guys here will lend me a hand.

    I don't think you would really want to script the editing part as such, but rather script it so that the script copies appropriate version of the config file into package VE and as the one the application expects to see.

    Something like this:

    <SCRIPT TIMING="PRE" EVENT="LAUNCH" PROTECT="TRUE" WAIT="TRUE">

    <SCRIPTBODY>

    @copy /Y q:\package\scripts\script.v123 q:\package\app\config.cfg

    </SCRIPTBODY>

    </SCRIPT>

    ...and change the path to the "source" file according the environment. Or copy it from outside the package from some set location, if you have such available (like known network drive or local directory), to avoid packaging of all variations of the config files into that staging directory inside the package itself.

    Another idea would be to somehow utilize virtualized environment variables and pipe those using script to the config file itself (if you can figure out how to do the editing part using scripting). That way the script could be static and you would only need to change the virtualized environment variables per each OSD.

    Having 1300 branched copies of the same package does sound bit excessive, like others have mentioned. I would seriously consider having one "master" package and X number of OSD files which handle the customization per customer.

     


    br,
    Kalle Saunamäki
    http://blog.gridmetric.com/
    Sunday, November 20, 2011 9:04 PM
    Moderator
  • here's the answer to this thread:

    <DEPENDENCY>
    < SCRIPT TIMING="PRE" EVENT="LAUNCH" WAIT="TRUE" PROTECT="TRUE">
    < SCRIPTBODY> @echo on \n
    Echo Y | reg delete "HKEY_LOCAL_MACHINE\\Software\\App &amp; Name" \n
    regedit /s "\\\Server\\Share\\RegistryFile.reg"\n
    < /SCRIPTBODY>
    < /SCRIPT>
    < /DEPENDENCY>

    ===================================================

    the amp is added after the &, because that's how the XML parser can understand it and therefore pars it.

    ========================================================================

    here's the big one :)

    if you want to create one package for an application and create multiple clones, then you need to follow the steps here:

    http://blog.appvtraining.com/Blog/tabid/87/EntryId/6/How-to-manually-duplicate-an-OSD-file.aspx

     

    I hope this helps anyone else who's running to a similar situation.

     

    Thanks

     


    Mohsen Almassud
    Tuesday, November 29, 2011 2:57 AM