We are in the process of converting our Software Library in prep for a new systems management platform, LANDesk. This system has us looking at our current software packages in a different light. We now have to look at our packages and compress the amount of files being delivered to the endpoint. Most MSI's are ok, they are usually just the MSI, a Transform and maybe an extra CAB file. We are ok with that. It's the larger packages, with MANY Files, that are our current issue. LANDesk has a file checking mechanism in software delivery that makes it damn nere impossible to deliver over a certain amount of files, we have had packages with 10,000 files take over 6 hours to deliver down to the client. Obviously this is not a good situation, so we are now looking into compressing those files into either 1 or just a few.

I have been running into a few packages that are MSI's with thousands of external files. These from the vendor, and from what I researched it's best not to repackage vendor MSI's for various reasons. My question now is, can I simply open the MSI with Wise Studio, hit the media option and choose either Compress files into external CAB files or Compress files inside of .MSI then do a recompile? Or would this be the same as a Vender MSI repackage No No? Also I have tried to run this route and it seems to compile fine, but when we go to run the MSI and install we end up with missing files.

Would I be best to just zip up these files and deliver these types of packages with a script? I do have a 5 day training course on Wise Package Studio coming up in June, but as company calls for DO IT NOW, I am forced to try and muddle my way throught this at the present time. If helps we are using Wise Package Sutdio version 8. Thanks for any information in advance!
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
can I simply open the MSI with Wise Studio, hit the media option and choose either Compress files into external CAB files or Compress files inside of .MSI then do a recompile?I don't see why not. The "no editing of vendor MSIs" rule wouldn't really apply here, since you're not altering it in a functional way. Nonetheless, I'd retain the original MSI as a fall-back.
Answered 05/13/2010 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

can I simply open the MSI with Wise Studio, hit the media option and choose either Compress files into external CAB files or Compress files inside of .MSI then do a recompile?I don't see why not. The "no editing of vendor MSIs" rule wouldn't really apply here, since you're not altering it in a functional way. Nonetheless, I'd retain the original MSI as a fall-back.



I would agree with Ian here. If all you are doing is effectively modifying the Media table and the attributes settings for each file from uncompressed to compressed in the File table, then the vendor MSI is not being altered in a functional way so in the majority of cases it should all work fine. In fact, in my workplace we have developed an automated tool to do just this type of conversion.

Just a slight word of caution, I have encountered some vendor MSI's (thankfully only a few) that include custom actions which expect certain external files to be present and uncompressed in the source folder alongside the MSI. These are typically support files which assist the installation process but don't actually form part of the package payload. However, if such files are internalized then you may find this type of custom action will not function correctly so you would need to handle these differently.

Spartacus
Answered 05/13/2010 by: spartacus
Black Belt

Please log in to comment
0
ORIGINAL: spartacus

I would agree with Ian here. If all you are doing is effectively modifying the Media table and the attributes settings for each file from uncompressed to compressed in the File table, then the vendor MSI is not being altered in a functional way so in the majority of cases it should all work fine. In fact, in my workplace we have developed an automated tool to do just this type of conversion.

Just a slight word of caution, I have encountered some vendor MSI's (thankfully only a few) that include custom actions which expect certain external files to be present and uncompressed in the source folder alongside the MSI. These are typically support files which assist the installation process but don't actually form part of the package payload. However, if such files are internalized then you may find this type of custom action will not function correctly so you would need to handle these differently.

Spartacus

Heck one of those vendor MSI's wouldn't happen to be Hummingbird Exceed woud it? [&:]
Answered 05/13/2010 by: Ascott860
Senior Yellow Belt

Please log in to comment
0
Scott,

in addition to what Ian and Graham said...

is it ABSOLUTELY paramount that you copy your files to the LANDesk cache location before the installation? Can you not trigger the installations from the network directly for your huge packages? This way you would bypass the problems LANDesk has caching your installation.

We use LANDesk here too (8.8 still, I'm guessing you're at 9?) and have set up a system using Distribution Packages that have no additional files (we were having issues with file hashes not updating after changes). Instead of adding all the files we call an install.cmd that contains pretty much only %1<installer.msi>. We then use the Install/uninstall options Command Line to pass the network path to the cmd file for the %1.

To ensure LocalSystem has access to the installer, we gave Domain Computers Read access to the network share that contains our installations

Hope this helps.

PJ
Answered 05/13/2010 by: pjgeutjens
Red Belt

Please log in to comment
0
pj,
I guess that is something we need to look at. Thanks for the heads up on what you all do. As I understand the only way you can deliver push packages to devices outside of the network, that are managed by the LDMS Gateway Device, your push packages need to be HTTP Shares. Run from source is not doable with HTTP Shares, must be from UNC only, hence we were trying to make everything we had deliverable to any device we manage on our WAN or manged by the Gateway Device in the DMZ.

So it comes down to a matter of what larger packages we may want to push by way of this device. AutoCAD/Exceed/Hyperworks type of pacakges, probably not. But Things such as adobe pro, standard, CS4, we will probably have to deliver "off-network". Great feedback, you definately have given me something to think about. We are using 9.0, well we are pilot testing it and waiting for SP1 before a production roll-out.

I found out my issue with the "missing files" after containing the external files into the MSI or Single External CAB with Wise! It seems you need to install the package on the machine first, then open the original MSI and pack them in!
Answered 05/14/2010 by: Ascott860
Senior Yellow Belt

Please log in to comment
0
you need to install the package on the machine first, then open the original MSI and pack them in!Actually, all you need to do is adjust the path to the source files in the WiseSourcePath table. I suspect that the current value is the default INSTALLDIR, hence your installing "magically" made the source files appear.

You can search-and-replace via the UI. Make sure you select 'This table only' when doing that, though.
Answered 05/14/2010 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

you need to install the package on the machine first, then open the original MSI and pack them in!Actually, all you need to do is adjust the path to the source files in the WiseSourcePath table. I suspect that the current value is the default INSTALLDIR, hence your installing "magically" made the source files appear.

You can search-and-replace via the UI. Make sure you select 'This table only' when doing that, though.


Thanks! I will definately be trying this in a few minutes!
Answered 05/14/2010 by: Ascott860
Senior Yellow Belt

Please log in to comment
0
Run from source is not doable with HTTP Shares, must be from UNC only, hence we were trying to make everything we had deliverable to any device we manage on our WAN or manged by the Gateway Device in the DMZ.

this is correct in as far as I know and have seen here. Are you however gonna want to push extremely large packages (I'm going to assume a link between too large a number of files and large packages) to machines that are not part of your core network (and thus probably not all equipped with high speed network lines) :)
Answered 05/14/2010 by: pjgeutjens
Red Belt

Please log in to comment
0
ORIGINAL: pjgeutjens

Run from source is not doable with HTTP Shares, must be from UNC only, hence we were trying to make everything we had deliverable to any device we manage on our WAN or manged by the Gateway Device in the DMZ.

this is correct in as far as I know and have seen here. Are you however gonna want to push extremely large packages (I'm going to assume a link between too large a number of files and large packages) to machines that are not part of your core network (and thus probably not all equipped with high speed network lines) :)


And that is where we need to draw a line in the sand. My theory is that anything large file size that will not be utilized off-site due to things like FLEX/LM Licensing will most likely be run from source as they are used only on the WAN. But things like Adobe Pro 9, which has around 8,000 files and is close to 1GB in size, may be viable for an end user who is remote and needs these things to do "Office Administrative" types of activities. So the need to either zip or compress into MSI will be there. Lots of game planning to do here. [8D]

TGIF!
Answered 05/14/2010 by: Ascott860
Senior Yellow Belt

Please log in to comment
0
ORIGINAL: VBScab

you need to install the package on the machine first, then open the original MSI and pack them in!Actually, all you need to do is adjust the path to the source files in the WiseSourcePath table. I suspect that the current value is the default INSTALLDIR, hence your installing "magically" made the source files appear.

You can search-and-replace via the UI. Make sure you select 'This table only' when doing that, though.


My WiseSourcePath table has nothing in it. What value would I input here for compressing the external files into a single MSI?
Answered 05/14/2010 by: Ascott860
Senior Yellow Belt

Please log in to comment
0
My WiseSourcePath table has nothing in itWhat a dolt I am! I completely forgot that this was a vendor MSI. You can still work this out, though.

Make a copy of the original MSI as a fall-back. Now, save your working MSI copy as a Wise project (WSI). You should now have a populated WiseSourcePath table but with the source path pointing to the locally-installed files. Now you can search-and-replace. You should use relative paths here, to save storing explicit drive letters/UNCs.
Answered 05/14/2010 by: VBScab
Red Belt

Please log in to comment
0
Does anyone have a script for cycling through the file table and adding 16384 (compressed file bit mask) to the attributes of each of the files?

Thanks,

Mike
Answered 05/18/2010 by: mike_c
Yellow Belt

Please log in to comment
0
Download the Platform SDK (I think the Windows Installer SDK is no longer available as a separate download). Therein you'll find several VBSs which deal with interrogating and updating MSI tables, albeit not necessarily the File table.

Also, FFR, AppDeploy has a specific forum for 'Scripting'.
Answered 05/18/2010 by: VBScab
Red Belt

Please log in to comment
0
Thanks for the pointer VBScab.

Also although it is a scripting question, I thought it was relevant to this thread, particularly in relation to Spartacus response (re changing the media table and the file table attributes).

Thanks
Answered 05/18/2010 by: mike_c
Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity