MoAltiris

Whether I'm using a VBS or Batch or just the command line "msiexec.exe /uninstall /myapp.msi /quiet" it will fail when run with System rights! Any of the above methods work fine when tested locally on the machine by any administrator account.

This is a SWD and if I specify a user it will fail since we have Security Groups as administrators on the local machine. Can I specify a local user account like "administrator"? This job would run on many computers with different names. I tried %computername% in the "Domain" field, %computername%/admin in the “User” field, and left the “Domain” filed blank, none of it worked. I don't want to hard code a username or password in a script.

Any ideas would be helpful!!
Thanks.

andykn

I think you should try and find out why the uninstall will not work using the system account. Two things to try:

1/ Open a command prompt as the system account using the AT command and then run the msi so you can see what's failing.

AT 13:45 /interactive "cmd.exe"

2/ add /lie* c:\temp\myapp.log to the uninstall command abnd then look at the log.

You can't use local users in an SWD task.

You could create a Domain User and make that a member of a Security Group that is administrator on all your machines but solving the original problem is better.

Dildano

Intalls that do not require interaction with network resources should install fine using the local system account. However, your command line looks a little suspect. I always deliver msi packages using %comspec% as it usually prevents any path issues and should mean you don't need to type 'msiexec' try this:-

%comspec% /c myapp.msi /x /qn

If your install needs access to anything other than the local machine then you must provide credentials that have the required access rights

Ff you are having problems using setup.exe (esp Installshield) files then this may be assosciated with them impersonating interactive user sessions, google it, you may need to modify iiscript.msi or the registry.

__________________
Steve Adams
Altiris Engineer

London, England.

itsmillertime4u

I've ran into problems with some software (especially scanner software), requiring everyone modify rights to part of the registry. I usually do a manual instal first using msiexec /i some.msi /qb, and then if I encounter errors I use something like MS process monitor in order to figure what the error is. Once I got it figured out we deploy the package using msiexec /i some.msi /qb! so the user gets a notification that it is installing, but they can't cancel the operation.

MoAltiris

andykn

Do you mean "run the uninstall from a command prompt run as the local system account"?

Where is the msi? Where was the orignal install performed from?

itsmillertime4u

I have to agree with andykn, this isn't an uniinstall MSI error this is unable to find file error. Is the MSI on a network share or somewhere inaccessible from the system account?

I suggest you do this, make the command for the task "cmd /k", run it only when someone is logged on, interactively, run as system, and set it to manual. Then run this task; you should get an cmd propmt being ran as system admin where you can try your unistall command and any other test to figure out what your problem is.

MoAltiris

itsmillertime4u

The other thing you can do is find out the MSI product code from the registry, should be in the uninstall string for the application. Once you have this, you can use this for the uninstall; the command is:

msiexec /x {89890-78AD..} /qb!

Just replace {89890-78AD..} with the product GUID. Then the uninstall will kick off without having to know the path to the MSI, it instead reads the information from the registry and preforms the uninstall.

andykn

Hmmm.

Just to confirm.

You open a command prompt when logged in as a user with local admin rights, change directory to the ...\software delvery\{guid}\cache directory and then run where myapp.msi is in the cache directory and it uninstalls.

You open a command prompt as the Local NT Authority\System account, do exactly the same thing and get the message about the installation package could not be opened.

Don't involve .bat or .vbs files at this point.

• Check permissions on the \cache directory and all files.
• Try another msi with the system account
• Try another installer option with the system account /f or /a maybe.
• check permissions on the Windows Installer Service in Group Policy, I think it is set to Manual and starts when invoked by a comand.
• Are there any Event Viewer messages relating to Windows Installer that are different between the Admin User and Local System account attempts?

The next thing I would do is use Sysinternals Process Monitor (Regmon and Filemon in one new package).

itsmillertime4u

Nooooo, no, no not the Altiris GUID the internal MSI product GUID. This should be easy to find since you have the MSI and the application is already installed which it is in this case.

To find the product GUID from the MSI see here:
VBScript get MSI ProductCode « A little work blog

To find it from the installed system registry see here:
See Method 2

and then /uninstall is not a valid msiexc switch, you want to use msiexec /x {someProductGUID}
see here: Command-Line Options (Windows)

MoAltiris

I have to change gears now, I have found out the problem. The problem is that this MSI is set to install on a 'per user' basis. System did not install this so System cannot uninstall this. I found this out by using a newly created admin account, I was using the same admin accounts to install and uninstall during this whole process. Sorry this has dragged out so far, that is a tier 1 mistake I should have caught.

Is there a way to uninstall a MSI of this type if you don't know who installed it? I can't think of a way, but that does not mean it can't be done.