0

I feel silly posting this, but I'm baffled and nobody in my department seems to want to help me out or communicate.

I'm supposed to be rolling out a script tonight/tomorrow that installs a new version of one of our crucial programs.

I scripted it, it utilizes the command start /w and installs 3 or 4 different MSI's using MSIEXEC. My problem is, afterwards, applications that were originally installed by using an MSI (most importantly our ShoreTel Communicator program) are not opening. It appears they are trying to connect back to the original install location for whatever reason.

Behavior doesn't appear to be the same on different computers. One machine, the applications appears to launch, however I get an install bar and the following error message.

The path \server\apps\etc\etc\Shore Tel Communicator.msi cannot be found. Verify that you have access to this location and try again, or try to find the installation package ShoreTel Communicator.msi in a folder from which you can install the product ShoreTel Communicator.

then....

Error 1706. No valid source could be found for product SHoreTel Communicator. The Windows Installer cannot continue.

This doesn't appear to be just this application. I rolled these MSI's out to two departments last night and our Financial area is reporting a similar error with one of their Financial programs.

I'm guessing this is happening because the local user doesn't have install rights. I really don't know how our GPO/Permissions are set. They are a mess and I don't handle that stuff.

Basically, what I'm asking is if anybody is aware of a situation where installing one MSI can cause issues to other applications that were installed by MSI's in the past.

Any help would be greatly appreciated. I'm supposed to have a half day today however that doesn't appear to be happening. :(

Improve this question

2 Answers 2

Reset to default
0

Some things you can check:

One possibility is that one of the applications you are installing is changing a dependency for one of the other apps already installed. If this is the case that app will try to find its original install source. If that is not available you can update the location where the app will look for its source files to update itself.

You mentioned you are updating multiple applications; remove one at a time to see which install is changing a dependant object.

You can check the MSI install flag to see if an previous application did not finish installing.

For critical applications I copy the source files to the local machine as part of the installation script. If a user is out in the field and cannot gain access to the UNC share this overcomes the issue.

Improve this answer
1
  • thank you for the response. I believe the issue has to do with a change in a dependency. I wasn't aware this happens (i really need to research Windows Installer). Is this normal behavior when dealing with certain/all MSIs? One thing I noticed is our Office applications behaved similarly, however they didn't crash. Office MSI's are local. I know for a fact that the problematic software's original MSI location has moved on our network. Are limited user accounts able to use these MSI's? If that's the case it seems, as you said, moving to the local machine is a good procedure.
    – Barbados Slim
    May 24, 2015 at 18:46
0

I'm guessing this is happening because the local user doesn't have install rights

Possibly, but that error is talking more about file system permissions. The local user may not have access to the server share where your *.msi files are sitting. This is running as an automated script, so it may be that the script user doesn't have access to that shared folder. Don't forget that you need to check both the file system permissions on the server and the share permissions.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.