This project has moved and is read-only. For the latest updates, please go here.

How to deploy msi files together with msp files that need FULL path? (e. g. Adobe Reader XI)

Topics: Publishing Issue
Dec 14, 2014 at 6:12 PM
Edited Dec 14, 2014 at 6:13 PM
Hello again,
I was trying to create a WPP update which deploys Adobe Reader 11.0.0 and the newest msp patch file for this, the Version 11.0.10.
I added the AdbeRdr11000_de_DE.msi as the main file, than added an .mst and the AdbeRdrUpd11010.msp files to the update.
After Publishing this update with this command line: TRANSFORMS="reader11.mst" PATCH="AdbeRdrUpd11010.msp", the update fails. Next I was trying to manually install this package on the Client with the command line executed in the Directory where the three files are: msiexec.exe /i "AdbeRdr11000_de_DE.msi" TRANSFORMS="reader11.mst" PATCH="AdbeRdrUpd11010.msp"
This has failed also with a message that the patch files was not found.
I did some goolge searching with the disappointing result, that msp files must have the FULL path in the command line to get this to work.
Is there a way to manage this problem with the WPP update creator?
What is the full path at the Moment, the updates are applied on the client?
Dec 14, 2014 at 9:05 PM
Edited Dec 14, 2014 at 9:06 PM
A Workaround is to use a network share (e. g. the wsus content share) to store the .msp files. In this case they must not be added to the wpp update.
It works with a command line like this: TRANSFORMS="reader11.mst" PATCH="\\server1\wsuscontent\share\patches\AdbeRdrUpd11010.msp"

But what about the Support of some variables for the command line of the wpp updates? In my tests from cmd it worked with PATCH="%CD%\AdbeRdrUpd11010.msp" so why can't this work with the wpp updates too???
Dec 14, 2014 at 9:51 PM
What %cd% mean ? How it is translate on your system ?
Dec 14, 2014 at 11:00 PM
In a cmd cli this variable represents the current directory. example: echo %cd% c:\users\Username
Dec 18, 2014 at 7:42 PM
I suspect that %cd% can only be translate in a 'User Context' and not in a 'System Context'. try to revise the update and check the option "Can request user input". This will allows to install the update in a user context.
Dec 22, 2014 at 10:44 PM
A system context variable path that may work is the following:
This is the folder that WPP unpacks custom updates to for installation, at least in my experience.
Dec 26, 2014 at 7:44 PM
It's Windows Update Agent that unpack updates on the client computer.
Once the update have been published in Wsus, WPP is not involve anymore in the process of updating clients.
Dec 29, 2014 at 1:43 PM
You're correct. I meant to say that this is where customupdateengine.exe and the included files usually gets unpacked to this location on my systems, though this is anecdotal, and not authoritative.

Interestingly enough, I don't have this issue with the MSP files, though, I just came up with a better idea altogether:

In your updater, you can move the files out of the unpacked directory to a directory that you define, so move files from .*.msp to PATH_TO_INSTALL_FOLDER, then install the MSP files from there, then delete them or move them back into the current working directory and delete the folder if it's empty afterwards.

Another thing that you could do is use a VBScript to copy the installer to a known working directory and call msiexec from there, then clean up the working directory afterwards, or just use VBScript to get the full current path, and use that to call MSIExec.