I know of a few 3rd party tools that will do this for free (7-Zip for example), but they would need to reside on the client machines =o(
We just make self extracting achieves using WinRAR, works rather well, it also allows us to script in other commands.
Here's a suggestion. You'll need the 7-zip command line tool. It specifically mentions in the license agreement that it's free even for commercial use. It conatins 7za.exe which is the self-contained version of the command line utility. It contains all dependent dll's and what-not inside it so no installation is necessary on the client. Here's a link to the download, but in case it changes you can Google "7za.exe"
- Download 7za920.zip
- Extract the files to a temporary directory. (There will be 2 files, 7za.exe and 7-zip.chm (the help file)
- Keep the CHM file for your reference, but copy 7za.exe and your zipped archive up to a package directory wherever you keep your packages.
- Next create a new distribution package in the console. Make it an exe package.
- Browse to the package folder and select 7za.exe as your main file.
- On the next tab, under command line parameters add the below line (subsituting your paths and zip file name). You can use windows environmental variables (but not LANDesk variables) for %ProgramFiles% %WINDIR% %TEMP%, etc.
e archive.zip -y -o"C:\wherever you want the extracted files" >nul
- e means extract
- archive.zip (or whatever your archive name is), will be downloaded to the same folder as 7za so we don't need to qualify the source path.
- -y don't prompt for overwrite (must-have with no UI)
- -o Extract to the following directory. There is no space between -o and the directory name. Use quotes as needed.
- >nul don't send the results to stdout (the target's screen) This may not be necessary because I think sdclient would suppress the UI anyway, but better safe than sorry. We need to make sure we avoid UI not only for the sake of being silent, but it could also cause issues if the target has UAC enabled.
3. Under "Additional Files", specify the archive file to download.
4. Test it a few zillion times before putting it into large-scale production.
If we do it this way only 7za.exe and the archive need to be copied down. Peer download will apply so other machines will be able to grab the package files from peer wotkstations. Remember, any time you change the archive file, even if its the same name, you must reset the package hash or it will fail. Once downloaded we're calling 7za.exe directly (rather than from a batch file or vbscript) so we can collect the actual exit codes.
That's all you need to accomplish what you asked for, so in the interest of keeping things simple you can choose to stop right here.
But being an LD Admin means we don't settle for simple...
Some enhancements you might add:
In v9 we gained the ability to create custom result codes specific to apps that don't issue standard result codes. 7za has a list of informative result codes that we can define in a custom result set for better confirmation of success or failure.
0 No error
1 Warning (Non fatal error(s)). For example, one or more files were locked by some other application, so they were not compressed.
2 Fatal error
7 Command line error
8 Not enough memory for operation
255 User stopped the process
Optionally you could output the results to a text file (>results.txt instead of >nul) and either parse it to something we can collect as custom data, or grab the file contents with the cfgfiles section of the ldappl3.template.