This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.

You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Help Removing Previous Version

solarwinds-admin over 11 years ago

Hello all,

First time here and very new 2 using Patchmanager.

The problem I am having is rolling out Autodesk NavisWorks Freedom 2012. I have created a package that installs the software without any problems. However the issue comes about as Navisworks 2012 does not upgrade 2010. I want to keep the network clean and remove the old version. 2010 was rolled out manually.

I have created several files that are capable of removing the 2010 version if run directly from the PC. I have tried several methods of attaching these files to the 2012 package but the uninstall refuses to run.

With the .cmd or .exe removal files added to the package content and run from within the XML file we get to see the content file downloaded to c:\windows\software distribution\download\install for a brief moment before it dissapears again.

I have tried running the uninstallers from preexectution, exectution and post execution and get the same results every time.

If I use the .exe uninstaller as a standalone package it works fine and removes the software.

Can anyone please advise on the superseded and bundled options. Is it possible to link one package to another or am i using totally the wrong approach?

Thanks Pete

0 solarwinds-admin over 11 years ago

I am having a similar issue. When trying to publish an uninstall script I get unable to validate the execuable. I realize this is probably a good thing to protect my environment but my script is harmless, how can I validate it?

Thx.

0 solarwinds-admin over 11 years ago in reply to solarwinds-admin

First, regarding your '2010' uninstaller -- it sounds to me like the package is getting to the client, and executing, but either not doing anything, or failing. If the uninstaller has any logging capability, you might be able to get additional feedback from verbose logging. Also, double-check the return codes you've defined in the <program> element that declares the uninstaller.

Uninstalling the previous version in the <preexecution> section is the appropriate place to do this task.

Another way to approach this is packaging the uninstaller as its own separate package, rather than implementing it via PackageBoot. PackageBoot is a great way to do downlevel product uninstallations, particularly if they're MSI based and you only need to provide the ProductID, but for scripts or EXE packages, it can get a bit more complex.

Neither superseded nor bundled scenarios would be appropriate for this task.

The superseded option allows you to define a previously existing package that you now want the Windows Update Agent to universally ignore, because a newer package has been declared.

The bundled option is designed to allow two separate independent packages (i.e. Firefox and the Flash PlugIn) to be treated by the Windows Update Agent as a composite set of updates. In this scenario, if neither were installed on a system, both would be installed. If only one is present, the other would be installed. The end result is that when the 'package' is reported as Installed, you know that both that version of Firefox AND that version of the Flash PlugIn have been installed.

It is not possible to link one package to another, except to the extent that you can tie pre-execution or post-execution steps in PackageBoot to a single package.

0 solarwinds-admin over 11 years ago in reply to solarwinds-admin

> When trying to publish an uninstall script I get unable to validate the executable

If this error is occuring while executing the Publishing Wizard, it usually indicates that there is a mismatch on the Select Package screen in the Package Wizard, typically that the value in the Package field does not match the name of the file specified in the Download URL field, or that the file does not exist at all. Also, take note that you cannot directly publish a script as the primary component of a package. The program file of a package definition must be an EXE, MSI, or MSP. So, if you selected EXE, but then defined the Package field as some other filetype, the file validation will also fail.

Now, it is theoretically possible to build a package with, for example, CSCRIPT.EXE as the package file, and then specify a VBS file on the command line and include the VBS (and CSCRIPT.EXE) in the Additional Files listing.

Another way you can approach scripting files in a package, is to wrap the VBS into a self-extracting EXE, and define the EXE as the package installer file. Then in a <postexecution><programs><program> element, you can execute CSCRIPT (from the local instance of CScript.exe) and call the VBS file that was transported in the self-extracting EXE.