none
Adivce on Cutomizing the JRE sequence

    Question

  • Guys,

    I have successfully sequenced the JRE 1.6 U 27 and its running perfectly. However, I have numerous in house applications that require various file (deployment.config, trusted.certs) added to it depending on the application. I could add these directly to the package but I would prefer to keep the original sequence of the JRE as clean as possible and add the files dynamically at runtime. So, I can think of 2 possible ways of doing this:

    1. Runs a script in the OSD before starting the JRE sequence
    2. Use dynamic suite composition to add the files

    Now, both pose certain problem.

    Method 1:

    I could run a script to copy the various files but this will fail for non-admins as the normal user would not have write access (by default) to the .\bin\ directory of the JRE installation. I suppose I could modify the security descriptors in the sequence to allow that but again it seems clumsy to have to copy the same .dll files into the users VFS each time they run the app when I could pre-include them. This would also add considerable time to the start-up as there could be 100 .dll files to add

    Method 2:

    This method has posed problems also. When I installed the JRE, I followed best practice and installed to T:\JRE16U27\. This means, the JRE instance started in the sequence will look for .dll files in T:\JRE16U27\bin. Now, the only way I can figure of getting the files in there is

    1. Again, modify security permission and run a script to copy them in at runtime
    2. Edit the package and copy them in. This would create a new .SFT file though and again seems like needless replication
    3. Somehow use DSC?

    Now, the problem with option 3 is that when I create new sequence that will contain only these additional files, the JRE installation directory, T:\JRE16U27\, would not be present. I suppose I could re-do my sequence and install the JRE to its default directory but I already have another version installed on my clients so that would be messy.

    Any thought/ideas would be greatly appreciated :)


    Thursday, February 07, 2013 12:12 PM

All replies

  • Hello,

    I would pick the option you and your support staff could handle. All of them should work.

    Good to know about about DSC is that it is the last loaded package in the list that wins any potential conflict between registry keys and files.


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

    Thursday, February 07, 2013 1:12 PM
  • I'm the support staff :)!

    DSC doesn't appear to work though. Is it possible to create 2 sequences that install to say T:\MyApp and then use DSC with these components?

    Thursday, February 07, 2013 1:57 PM
  • No, each package requires a unique asset directory, so you won't be able to install two packages to the same path.


    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.


    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or other MVPs.

    Twitter: @stealthpuppy | Blog: stealthpuppy.com | The Definitive Guide to Delivering Microsoft Office with App-V

    Thursday, February 07, 2013 3:39 PM
    Moderator
  • Thansk Aaron, I guessed as much. Any ideas on how I could acheive this? Basically, each custom app will have a number of additional .dll files that will amount to say 1 MB. The JRE is 90MB so it seems messy to have to keep editing the ()mb package, add 1 Mb of additional files and then create a new packge of 91 MB. Multiple this out by 100 application and the App-C client cache is going to be bloated needlessly (unless it can compress all these similar packages?)
    Thursday, February 07, 2013 3:43 PM
  • Guys., just wondering if anyone had any further ideas on how to do this or am I just going to have to accept that I'd need to create a new package to do this (i.e. a new 90 MB package)?
    Tuesday, February 19, 2013 7:20 PM
  • I would think DSC might be the simplest approach and you'd just have to live with deploying those packages and the space they consume.


    Please remember to click "Mark as Answer" or "Vote as Helpful" on the post that answers your question (or click "Unmark as Answer" if a marked post does not actually answer your question). This can be beneficial to other community members reading the thread.


    This forum post is my own opinion and does not necessarily reflect the opinion or view of my employer, Microsoft, its employees, or other MVPs.

    Twitter: @stealthpuppy | Blog: stealthpuppy.com | The Definitive Guide to Delivering Microsoft Office with App-V

    Tuesday, February 19, 2013 9:50 PM
    Moderator
  • Hi, why just not resequence JRE 1.6.0.27 to, for instance c:\whatever\jre1.6.027. Use this as main package.
    Sequence all other packages (with those dlls), also to c:\whatever\jre1.6.027, and use DSC to link them.

    Wednesday, February 20, 2013 7:42 AM
  • Thanks Aaron,

    But as outlined above, how can I use DSC when that would mean both packages have the same installation path (which is not possible right?)

    Wednesday, February 20, 2013 9:44 AM
  • Thanks Tiberivs,

    But is this not impossible since 2 different packages cannot have the same installation path and be used with DSC ?

    Wednesday, February 20, 2013 9:45 AM
  • Sure they can.  The physical path on the q-drive should be unique for each app-v package.

    If you don't install these packages to the q-drive (in your case the t-drive) but into c:\program files\app or c:\whatever they end up in the VFS. Because to CSIDL variables point to the same directory your secondary DSC package will be in the same directory as your main package.

    Wednesday, February 20, 2013 10:18 AM
  • Thanks Tiberivis,

    The issue though is I have to have another version of the JRE installed locally. BY default, the JRE looks into its installation path for various things so I install to VFS instead of the T: drive, it tends to pick up things in the base JRE (i.e. other .dlls etc.). I could do what you suggest if there was a way of blocking the JRE sequenced to VFS from seeing other files in the real file system at the same path.

    Wednesday, February 20, 2013 10:24 AM
  • You could install your local java package on the sequence machine pre-sequence, and uninstall it during sequence so does files/keys will be marked for deletion and so are hidden as soon as your app-v package starts. Check out this arctile for more information, I sequences some JRE's that way successfully.
    Wednesday, February 20, 2013 11:03 AM