locked
Sequencing with silent install RRS feed

  • General discussion

  • When sequencing one could run through the GUI's of a setup. After that some adjustments are likely needed like deleting the uninstall/desktop shortcut and so on.
    The other possibility is to use a silent setup as input for the sequencer. A lot off applications come with a vendor .MSI nowadays. This gives the opportunity to create a transform file which in many occasions can prevent the creation of uninstall/desktop shortcuts and other customization's as needed.

    Now, I'm writing guidelines on how external parties should deliver app-v packages to us. I stated that, if possible, they should deliver the command line of the silent setup used as input for the sequencer. However, they see this as the creation of two packages, MSI/silent setup and App-V.

    I wanted to check how other people work. Do they first create a silent setup and use that as input or do they launch the setup GUI and repeat what is documented in the manual installation document.

    In my opinion the advantage of using a silent setup as input is that you can easily replicate a local install in case there is a problem with the appv package. It also customizes the setup during install so adjustments afterwards are not needed, resulting in a somewhat cleaner package. The 3th advantage I see is that often you can reuse the .mst/command line when a new version is needed.

    What are your thoughts on requesting a silent install from the sequencers?
    Thursday, February 19, 2015 12:34 PM

All replies

  • It's normal your external party sees it as two packages, you get a silent msi install and an appv package. If you request both, it seems fair to pay double.

    For me personally it depends on the installation. I prefer automation (with transform or even silent install trough batch/powershell), why? It easy to adjust and perform a new sequence in case you forgot something, or did something wrong. It also comes in hand if you need to perform an upgrade, of create a new version of the package (so you do not need to reinvent the wheel again ;)).

    Thursday, February 19, 2015 1:22 PM
  • In my opinion the advantage of using a silent setup as input is that you can easily replicate a local install in case there is a problem with the appv package. It also customizes the setup during install so adjustments afterwards are not needed, resulting in a somewhat cleaner package. The 3th advantage I see is that often you can reuse the .mst/command line when a new version is needed.

    What are your thoughts on requesting a silent install from the sequencers?

    This is a perfect case of there is no wrong way to do it, but what you said above is very true.  In fact, packaging software like Flexera Admin Studio encourage you to do it this way.  They don't want you to think of a package as a single deployment type, but rather however you want to deploy the software (MSI, App-V, etc).

    The investment in time is likely the biggest hurdle.  When you have to do something simple, creating an MSI/silent command first and then creating an App-V package is 2x the work.  Its not a bad standard to go with though.  And as Tibervis said, it does come in handy if you need to perform an upgrade or otherwise need to start sequencing from scratch again.  It is in my opinion 2 packages, just as it would be 2 packages to create an App-V 4 and App-V 5 package even if you used powershell to convert the 4x package to 5.  This gets very into your process though. 

    Just watch out you aren't making you own life 10x harder to protect yourself from something that only might happen a small percentage of the time.  Keep in mind that there are also going to be deployments where the App-V package requires work the MSI doesn't - a driver, a component that needs to be outside the bubble, etc.  Having an MSI won't help you create the App-V in that case, and if you ask packagers to create an MSI, an App-V, and an App-V instruction guide (for packagers eyes only) you might be shot on sight.

    Thursday, February 19, 2015 1:58 PM
  • I have used three different third party vendor tools for automated App-V Sequencing with very mixed success. If the applications you are using are packaged MSIs, you'll have a higher success rate. And that's because things like auto-updates are likely already disabled (in a well managed enterprise) and splash screens, first time pop ups will be supressed BUT you will still have failing points. e.g. Applications that are simply not compatible with App-V, applications that require files to go to a location which is in your App-V exclusions list

    I will say this, if you're looking at a Product like Flexera AAC tool for sequencing, I'd suggest using the App-V Sequencer option. I've had a higher success rate by using the Sequencer.


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

    Thursday, February 19, 2015 4:03 PM
  • Automated sequencing is not really the reason I want to request the sequencer to use a silent install as input. I see this as a best practice. However, automation might be considered in the future.

    In my guidelines I do ask the sequencers to start the application during the sequencing process (not stream training, I always use fault streaming) so the app-v is as close as possible to the run state of the application. In a tool like Flexera automated application converter (AAC) I don't see any post-installation option to start the application during sequencing. What are your thought on the lack of application start during automated sequencing?

    Monday, February 23, 2015 10:14 AM
  • I do too have a higher success rate using the sequencer. Admin Studio with virt-pack for instance converts the project you have. So any post install actions are captured while creating your project. So yes indeed, most 3th party automated sequencers are very limited. Thats why I prefer the native sequencer.

    By automation, I mean; create a silent install for your sequencer. I indent to keep the packages/sequences as clean as possible, so it depends on the software/post install actions if I start the application while still in monitoring phase or not.

    Wednesday, February 25, 2015 11:46 AM
  • As how I see it: keeping the packages clean (by not starting during sequencing) could have a negative impact in (especially) non-persistent scenarios. Because the .appv does not include potential files and registry keys from the user profile these have to be created by the application start and possibly have to be roamed by an UEM when these need to be preserved.
    Wednesday, February 25, 2015 5:15 PM
  • As how I see it: keeping the packages clean (by not starting during sequencing) could have a negative impact in (especially) non-persistent scenarios. Because the .appv does not include potential files and registry keys from the user profile these have to be created by the application start and possibly have to be roamed by an UEM when these need to be preserved.

    We actually prefer these be created 'outside' the virtual environment so they are not tied to a specific GUID.  If you have version 1 deployed, the client sets up data, then when version 2 comes out and you start the new capture from scratch, the end user has lost settings as they are tied to the GUID for version 1.

    No right or wrong, it depends on what you want.  Remember though App-V doesn't roam anything for you, you will always require something to roam the per user changes, whether they be in the COW locations or not.

    As for Admin Studio... we have and use it, but we are not comfortable with the auto repack or whatever its called.  It ignores any custom actions, really anything that isn't 'flat' in the tables.
    We have many MSIs that execute custom actions dependent on OS version, and various other things.  All that gets ignored in the auto repack.  You end up needing to create a flat MSI FROM your normal MSI to then auto repack..and if the MSI does anything that is bitness or OS specific, you have to create a flat MSI for each of those.  Its more work but I would definitely use the sequencer (from within Admin Studio) if you are going down that road.

    Thursday, February 26, 2015 2:30 PM
  • Like often is the case: it depends on the application. However, when an application creates files/registry in the user profile which are static in my opinion it's better to include them in the .appv by starting the application during sequencing. So it comes down to the intake process to know if a application needs config files/registry items in the profile or not. Anyone disagrees? Anyone knows a good way to teach the intakers how to handle this?
    Thursday, February 26, 2015 2:55 PM