Software Deployment

even if you could do it, which I doubt your asking for a world of pain.

You could try dropping the registerUser and RegisterProduct actions to see if it avoids the caching process. Its dangerous and potentially problematic but may solve your issue. Not something I would advise but worth a shot all the same.

Thanks for the reply John.

Unfortunately the reason for not caching (which i failed to explain properly) is that the i've only got 37 mb approx free out of the 256 mb. The MSI itself is about 12 mb, and i know I can locate the cache msi via registry however as the install will be pushed out via an Altiris install job this means a randomly named file (?) for each thin client.

I have seen other products that seem to support / allow this (Symantec Endpoint Protection 11.0 has the CACHEINSTALL property) - or is this something completely different?

Is this possible, if not any suggestions on ways to approach this problem?

A 12Mb MSI can't be too complex, making it a candidate for using an alternative deployment method, e.g. by script. Something simple like copying a folder structure and, if the app requires registry entries, merging a .REG....worth thinking about.

Yeah I had thought of that though more as a last resort. Just would be nice to use the vendor supplied MSI if disabling the local cache of the install was easy, which it doesn't appear to be.

Thanks for the reply.

Hi Dodgy,
what app are we talking about here?
There is no generic caching mechanism in MSI.
But usually, its quite easy to turn it off.
Regards, Nick

Hi Nick,

The install in question is the XenApp Plugin for Hosted Apps (aka Citrix ICA Client) 11.000.

I've made some in roads with this by creating an administrative install then installing from there to limit the cache file to a smaller msi (about 3mb). Seems the base msi extracts another msi which then has properties modified / added to as per dialog options chosen from the base msi (if that makes sense), of course this extracted msi sits in %temp% directory during the install.

So this means the 37mb free ends up being about ~20mb (35 - 12mb - 12mb), when the total application install (based on my options) is ~22 mb hence install fails.

The annoying thing about this package is that it includes all language variations and uses custom actions to determine which localised files to install. These localised files are then copied to the install folder under resource (why, when all i care about is english) and occupy about 10mb.

Normally HP release updated client installs for their thin clients, but unfortunately for our models haven't done so for some time.

Why HP thought 256 mb was enough i'll never know.

Hi dodgy,
ok wait a minute.
I think, i understand your needs now. Have reread your OP.
Had the caching of the MSI itself in mind. The caching, you are referring to here, stems from decompressing the CAB.
You need 2 things here, i think.
1. Create an admin install, like you've done before, but check the uncompressed button.
BTW: This is the only option for an admin install on a "regular" MSI.
This removes the need of unpacking the files from the CAB-file on the target machine.
2. Remove unwanted language resources.
See the notes here: http://itninja.com/link/how-to-repackage-the-presentation-server-client-for-32-bit-windows-microsoft-installer-package
In your case, set the LANGID property to ";1033;"

With this, you should be able to reduce the footprint to less than 17MB.

Regards, Nick

Nick,

Yeah initially I thought it was the msi cache causing the out of space errors, then it turned out to be the vendor install and how it works.

Anyway I will give your suggestion a try and reply back and rate if it works.

Thanks