KACE: Scripting: How To Create a Script to Launch a .MSP File (Autodesk 3ds Max Design 2013 Update

How To Create A Script To Launch A .MSP File (Patch)   Updated 10/2/2012**

This is a comprehensive guide that will show you the basic creation of a script to launch a .msp file.  Since .msp files are compiled similarly to .msi files the parameters might need to be tweaked.

What is a .MSP file?

Answer= An application that has been installed using the Microsoft Windows Installer can be upgraded by reinstalling an updated installation package (.msi file), or by applying a Windows Installer patch (an .msp file) to the application.

A Windows Installer patch (.msp file) is a self-contained package that contains the updates to the application and describes which versions of the application can receive the patch. Patches contain at a minimum, two database transforms and can contain patch files that are stored in the cabinet file stream of the patch package


Pre Requisites

3dsMaxDesign2013_PU05_Win_64-bit.msp file
A test machine to update (Patch)

(Note:  On your test machine please have desktop or remote desktop access to it for troubleshooting.)

Configuring The Script

Configuring the script is pretty straight forward.  The most important part will come during the parameters.  Don't worry I have attached screenshots. :)

1.  From the home screen click on "Scripting".

2.  Click on "Add New Item".

3.  Choose Online KScript.

(Note:  Look to the right of this screen.  There are alot of helpful tips and explanations.)

4.  Change the Status to Production.

5.  Click the checkbox to enable the script.

(Note:  If this box is not checked the script will not run.)

6.  Choose a test computer before applying this script to a Smart Label.

7.  Choose a supported operating system.

(Note:  Uncheck the box that says Pick Specific OS Versions for simplicity.)

Your configuration screen should look a little like this!

Now comes the tough part.

8.  Add a new dependency.

(Note:  Browse to where the .msp file is located)

9.  Add a task.
    a.  Add a Verify task.
        i.  Verify a directory exists...
        ii.  Directory:  $(KACE_DEPENDENCY_DIR)
(Note:  This is where the Kbox download the dependencies too.)

  b.  Add an On Success task
        i.   Launch a program...
        ii.  Directory:  C:\Windows\System32
        iii. File:  msiexec.exe
        iiii.Parameters: [/quiet /update "$(KACE_DEPENDENCY_DIR)\3dsMaxDesign2013_PU05_Win_64-bit.msp"]
(Note:  These parameters worked on this program.  Different .MSP's and .MSI's require different parameters and you can find that information from the software manufacturer.  A link to a list of standard Installer Command Line Options can be found at the bottom of the blog.)
        iiiii.Save Changes
(Note:  Brackets [] need to be removed the quotes "" should stay and are important for the correct functioning of the script.)

Your Policy or Job rules should look something like this!

10.  Save the Script.

11.  Now click on the script you just created and run it by clicking on the "Run Now" button.

(Note:  For troubleshooting purposes enabling a custom pre-install message can be fun and let you know when the script is being pushed to the client.)

Did it work?

If so, then create a label that looks for machines in you environment that has the application that needs to be patched.

Then add that label to the deployment section.

Congratulations!  You have created your script with a .msp file.

Standard Installer Command Line Options



  • This is a great post showing how to deploy and MSP file. I only have a couple of comments:
    Instead of adding my test computer to the list on the script I test using the "Run Now" tab. This way I can still setup my script to deploy to the machines I know will need it (normally based on a label in our environment). I normally leave the script disabled until the testing is complete and then I enable it.

    For the task sequence I will verify that the program that needs to be patched exists on the machine, and specifically that it matches the version that the patch applies to. This way if there is a chance that the script runs on a machine that it doesn't apply to it won't try to run the patch on that machine and generate an error. - chucksteel 11 years ago
  • Thank you for the comment. I edited the Blog to include some of the info you had suggested. - c_brock 11 years ago
  • that what i call a good post. thanks for it... - blackbyte 11 years ago
This post is locked
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ