We are currently trying to create .MSI distributables for a large NT to XP desktop migration project. We have been trying an evaluation version of Wise Package Studio (version 5).

Previously we used the old SMS packager as provided by Microsoft but feel we need something more up to date. I am experiencing a problem with the Wise package studio that I hope someone might be able to assist me with.

I am packaging an application by means of a before and after snapshot, I then use the installer editor to change some options (not packing user registry keys etc), and then compile to create an MSI

The MSI then installs the application on another PC and appears to load properly but when running the application, it always starts the Wise installer process and tries to locate the original MSI install package, presumably to load a feature.

This is probably something simple, but is causing us problems and we can't seem to find the solution within the help files.

Any assistance would be most welcome.
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
You seem confused about MSI not Wise.

MSI technology requires the original source in order to repair broken components that include files.

If you have user specific components (containing HKLM keys, or profile-based files), these components will have to be installed for every new user. This is normal.

If however, the installation repairs itself over and over again, every time the user logs on, then you might have a component without a key path.

Try validating your package using either the Wise Package Validation tool or Orca.
Answered 11/12/2004 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
0
Yes it was a missing key path - identified it using MSISpy & ORCA, thanks for the tip. We are using this Wise tool to package up applications for a network rollout and it's possible that sometimes a .MSI might be copied onto a CD for a local install directly onto a PC (i.e. not using SMS).

Is it reasonable practice to code an MSI so it would always look for the source to auto-heal from a static location (network drive where the source is stored), rather than the CD media used to install from as there's more chance of locating the source that way.
Answered 12/01/2004 by: upthorpe
Senior Yellow Belt

Please log in to comment
0
Definitely! In fact, I'd recommend using a DFS share as opposed to a share on a server. That way you can seamlessly move your package library to another server if it becomes necessary. It also has the benefit of being able to hold your package library in multiple locations for failover and/or scalability. If you have a HUGE emergency deployment, you have the option to add a few servers to take the load and pull them off later.

Still, if you don't use DFS, having source on removable media should be avoided at all costs. It effectively "breaks" the self repair ability since the required source file is probably not present. If you have to pull out a CD, heck you might as well install it manually!
Answered 12/01/2004 by: VikingLoki
Second Degree Brown Belt

Please log in to comment
0
ORIGINAL: upthorpe

Yes it was a missing key path - identified it using MSISpy & ORCA, thanks for the tip. We are using this Wise tool to package up applications for a network rollout and it's possible that sometimes a .MSI might be copied onto a CD for a local install directly onto a PC (i.e. not using SMS).

Is it reasonable practice to code an MSI so it would always look for the source to auto-heal from a static location (network drive where the source is stored), rather than the CD media used to install from as there's more chance of locating the source that way.


Just so there's no confusion, I meant "HKCU" in my previous post (not "HKLM")!

You may find this VBScript code interesting?

Dim oInst

Const sNEWSOURCE = "\\SomeServer\SomeShare\"

Const sPRODCODE = "{782750FA-653A-4790-B2FD-557A123CA32E}"

Set oInst = CreateObject("WindowsInstaller.Installer")

oInst.AddSource sPRODCODE, "", sNEWSOURCE

Set oInst = Nothing
Answered 12/01/2004 by: WiseUser
Fourth Degree Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity