If you haven't done so already, creating a verbose log of the install is more often than not the best place to start.  Have you double-checked the Upgrade Details on your major upgrade to make sure your newest version isn't being excluded in your min. version to max. version range?

Well, I've made some headway on the issue:
I'd forgotten the rather simple step of changing the Patch GUID between each patch build.

This is, however, leading to another issue.

Apply patch #1 and then apply patch #2....if the original MSI is still present in it's original location, the patch installs properly.
We, of course, distribute all our installers as Single File EXEs.  That and, even if we distributed MSIs, how likely is a user to have a downloaded MSI still present on their system in the same location after 6 months and 1 patch...

When attempting to run the same patches on the EXE wrapped installer, we always get an error of:
'The feature you are trying ot use is on a network resource that is unavailalbe' and it's looking for a charming WIS%GUID%_%VERSION%.msi source file, which, of course, doesn't exist.

Having this issue with a vanilla, single file installer that I tossed together for easy testing. (deploys just 1 exe and the only changes to the installer are that one file, the productcode, packagecode and version)

Verbose log info relevant seems to be around here:

MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Now checking product {81CB0717-8512-40FE-AA4D-7A9EEA1E9A06}
MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Media is enabled for product.
MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Attempting to use LastUsedSource from source list.
MSI (c) (B8:78) [11:39:43:328]: Note: 1: 1706 2: 3: WIS9D7CE605EA2947AA9650FFA0DDE13E62_1_0_0.MSI
MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Processing net source list.
MSI (c) (B8:78) [11:39:43:328]: Note: 1: 1706 2: -2147483647 3: WIS9D7CE605EA2947AA9650FFA0DDE13E62_1_0_0.MSI
MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Processing media source list.
MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Trying media source ;LABEL.
MSI (c) (B8:78) [11:39:43:328]: Note: 1: 1706 2: 3: WIS9D7CE605EA2947AA9650FFA0DDE13E62_1_0_0.MSI
MSI (c) (B8:78) [11:39:43:328]: SOURCEMGMT: Processing URL source list.
MSI (c) (B8:78) [11:39:43:328]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (c) (B8:78) [11:39:43:328]: Note: 1: 1706 2: -2147483647 3: WIS9D7CE605EA2947AA9650FFA0DDE13E62_1_0_0.MSI
MSI (c) (B8:78) [11:39:43:328]: Note: 1: 1706 2: 3: WIS9D7CE605EA2947AA9650FFA0DDE13E62_1_0_0.MSI

Are you selecting full files or file deltas in your patching?
Is the original application fully installed?

The application of a patch often causes a "repair" of the existing application if there are any issues with the application that might create errors when the patch is applied. For example, applying a file delta to a file that has changed in ANY way from the original file installed, may result in a trashed file and therefore the original is reloaded from the install location, assuming the original can be found.

The following is copied from the help file MSI.CHM which is installed by Wise, although it is a Microsoft Windows Installer SDK file:

How can I prevent my patch from requiring access to the original installation source?

It is not possible to eliminate all circumstances under which the application of the patch may require access to the original installation source.

Adhere to following points to minimize the possibility that your patch will require access to the original source:

Prior to Windows Installer version 2.0, the application of a patch required access to the original installation source.
Use whole-file only patches. This eliminates the need to create binary patches for all previously released versions of the file. Note that whole-file patches will generally be larger in size than binary patches. You can easily set a patch to be a whole-file patch by authoring the IncludeWholeFilesOnly property with a value of 1 in the Patch Creation Properties (PCP) file.
Ensure that none of your custom actions access the original source location.
Ensure that the ResolveSource action is conditionalized so that it only runs when needed or alternatively is not present at all.
Populate the MsiFileHash table for all unversioned files. The Windows Installer SDK tool, Msifiler.exe, can easily do this for you.
Ensure that all files have the correct version and language information. The Windows Installer SDK tool, Msifiler.exe, can easily do this for you.

Source Requirements when Patching

Access to the original installation sources may be required to apply the patch in the following cases:

Prior to Windows Installer version 2.0, the application of a patch required access to the original installation source.
The patch applies to a feature that is currently run from source. In this case, the feature is transitioned from the run-from-source state to the local state.
The patch applies to a component that has a missing or corrupted file.
The patch applies to a file in a component that also contains unversioned files with no MsiFileHash entries. A populated MsiFileHash table is required to prevent unnecessary recopying of unversioned files from the source location.
The patch was applied with a REINSTALLMODE of amus or emus. This option is dangerous in that it will perform file copy operations regardless of file version. This can lead to down-reving of files and will almost always require the source. The recommended REINSTALLMODE value is omus.
The cached package for the product is missing. The cached package is needed for application of the patch. The cached package is stored in the %windir%\Installer folder.
The package is authored to make a call to the ResolveSource action. This action should generally be avoided or conditionalized appropriately because its execution will always result in an access of the source.
The package has a custom action that attempts to access the source in some manner. The most common example is a type 23 nested installation custom action.
The patch package consists of binary patches that will not apply to the current version of the file on the machine.

Consider the following example where Windows Installer requires access to the original source when applying a patch:

Install RTM version of the product Example.
Apply patch Qfe1.msp to the computer. This patches version 1.0 of Example.dll to version 1.1.
A new patch, Qfe2.msp is provided, which updates Example.dll to version 1.2 and obsoletes Qfe1.msp. However, the patch was only created to target version 1.0 of Example.dll because it was generated using the RTM version of the product. Example.dll version 1.2 includes the fix contained in Example.dll version 1.1, but the .msp file was generated between the RTM and QFE2 images. So, when Qfe2.msp is applied to the computer, Windows Installer will need to access the original source. The binary patch for Example.dll cannot apply to version 1.1; it can only apply to version 1.0. This results in the Installer recopying version 1.0 of Example.dll from the original source location so that the patch can be applied successfully.

Well, I've started my testing on a vanilla installer that only deploys a single .exe file.
No custom actions, no changes to the .WSI (ie: it's the generic base .wsi you get when you fire up WfWI)
The patches are created using whole-files, not deltas.
Patches are installed with a REINSTALLMODE value of omus, and I've also tried setting REINSTALL to 'ALL'

If I create minor upgrade installers (different version, same productcode) and create patches off of those installers, I can perform multiple MSP installations without any requests for the source code.  Minor upgrades, of course, are not a viable option for us.

If I create major upgrade installers (different version, different productcode) and create patches off of these installers, I can install the first MSP just fine..subsequent patches make the call for the source file.
And it's always when the 'ProcessComponents' action starts, it's triggering a ResolveSource action it seems.

The base installer and the 1st patch are getting saved in \Windows\Installer.  When prompted for the installer source though, pointing to that cached MSI results in a 'not a valid installer' error.

So, after a week of hammering away at different patching options with no solution...I have to ask, has anyone successfully deployed two major-upgrade patches to a base installer without being prompted for the original install source?

If you look at the excerpt from MSI.CHM I posted, you will see a reference to the ResolveSource custom action being a known cause of the request for the source MSI. In any package, this MUST have a condition applied of "NOT Installed" to ensure that this custom action only runs on first install and never on any future maintenance operations.

Taking things a step back, can you confirm which version of which Wise tool you are creating your patches with?

Microsoft have made several changes to Windows Installer services since 2000, one significant change being at version 3.x of the windows installer service, which introduced removeable patches, and patch sequencing.  In line with this, Microsoft also updated key patch generation DLL files such as mspatch.dll, and these DLL files are installed and utilised by the Wise tools for generating patches.

If you are running an older version of Wise, eg WFWI 6.x, then as a first step you should download a recent edition of the Windows Installer SDK, and update the patch DLLs in the Wise folders.

Also - are you running UpgradeSync between the different MSI files used to create your patches?

Wise Installation Express 7.3.0.250 in this case.
I've run UpgradeSync, specified Major Upgrade, set a new version and have no issues reported
Again, this is just a test install script with one .exe file (3 different versions of it, of course).  So, as simple and straight forward of an installer as I can make.

As for the ResolveSource action, I've looked through the tables for the MSI and do not see a ResolveSource call anywhere.
Looking at the logs for a failed patch, it appears that ProcessComponents is what's triggering a call to an embedded 'ResolveSource'-like action.

Wrapping 'ProcessComponents' in a 'NOT Installed' or 'NOT PATCH' doesn't work, of course, as you end up with no installed files after the 1st patch application.  (and still needing the source file if you try the 2nd patch)

Another note....the patching works just fine if the original install is done via the MSI and the MSI is still in the same location it was installed from.

Move that MSI, you get prompted for the source when applying any patch.

Install via a single-file .EXE, your first patch will install fine...subsequent patches come up looking for the pesky:
"C:\Program Files\Common Files\Wise Installation Wizard\WIS%GUID%_%VERSION%.msi"

The problem appears to be that *after* the 1st patch is applied, that MSI is removed from the system.
Backup that file before applying the 1st patch, restore it after appyling the patch and you can then install the 2nd patch without getting prompted for source media.

So...how the heck do I keep that MSI from being deleted when a patch is applied?

Are you installing from an MSI compiled to EXE and then updating from a straight MSI ?

Also, a copy of every MSI installation is cached in the hidden folder c:\windows\installer - so the original MSI is there, but without any internal CABS. If your patch is requesting access to the original MSI source, then it appears to need access to an actual source file from the original MSI, so you need to investigate exactly what it is looking for.
As the extract from MSI.CHM states, it is not always possible to create a patch that doesn't ask for the original source media, but if you can identify what is causing the request for the original source, it will be impossible to determine whether a solution is possible that avoids calling the original MSI.

Cross check your application event log, as this can also record MSI activity such as repair operations, which may have a bearing on the problem you are experiencing.

Let me recap:

Install via a MSI, leave the MSI on the PC in the same location for the patch process, all the patches apply correctly.

Install via a single-file EXE (ie: under Build Options in the Installation Expert), the initial install works.  the CAB-Free MSI is cached to \windows\installer AND it also copies the full MSI to \Program Files\Common Files\Wise Installation Wizard.
Install the first patch and the cached MSI is deleted from \Program Files\Common Files\Wise Installation Wizard, preventing further patching as the source is no longer available.
To top it off, the 2nd patch will not let you use the cached CAB-Free MSI in \Windows\Installer.

I'm rather certain that this isn't a patch issue persay anymore.  The patches work just fine and do what they're supposed.  Just something in the Wise patch process is triggering that is deleting the cached installer from
\Program Files\Common Files\Wise Installation Wizard.  The log doesn't show anything specifically killing that file either.  The directory is used as the PatchedProductSourceList variable and PackageName holds the MSI value of WIS8887D70E4A494BEDBFBB45EB330F9DDB_1_0_0.MSI

Flag that MSI as read-only and the patch doesn't delete it and all subsequent patches work just fine, for what it's worth.

This is a *very* easy to recreate scenario.  Just make a simple install with one versioned file in it.
Compile 3 copies of it (single-file EXE installs), v1.0.0, v1.0.1 and v1.0.2, each with different versions of that file in it.
Create two patches, one that goes from v1.0.0 to v1.0.1 and a second that will upgrade v1.0.0 and v1.0.1 to v1.0.2
Install v1.0.0, open up \Program Files\Common Files\Wise Installation Wizard, note the cached MSI.
Install the v1.0.1 patch...note that the cached MSI is deleted.

The fact that Wise also caches a full copy of the MSI install onto the local hard disk is frankly not representative of MSI installers in general.

Microsoft SMS, depending on client configuration, will typically cache the full MSI install in the System32\CCM subfolders, but this too has an expiry date associated with it, and will be overwritten if the assigned cache space is required for a newer install.

The advent of Windows Installer 5 from Microsoft brings in a new feature where Windows Installer will cache the entire MSI in the c:\windows\installer folder, because it has been discovered that uninstalling signed MSI files using earlier installers has been failing.
This is due to the cached MSI's code signing being damaged when the internal CAB files are stripped out as with current versions of the Windows Installer service.
Clearly Microsoft would not need to do this if MSI installers were already caching the entire MSI in the Common Files subfolders, as Wise is doing.

So we come back to the issue of finding exactly what aspect of your patch process requires access to the original source install.
If this proves impossible then you need to implement a solution that marks the cached MSI in the Wise Installation Wizard folder as read only. This could be achieved using ATTRIB run from the Runonce registry key, and a post install reboot, for example.

Yes, back to what is requiring source access....not sure why a single file install, with zero customization would require source access.  Full file patch, no custom actions...just the vanilla template that Wise supplies with a single file in it.

In the meantime, for both this simple installer and our actual product, dropping in a vbscript to set the readonly attribute on this cached MSI fixes all the issues.  Well, worksaround the issues...it's not really a fix.  Script just takes the ProductCode and ProductVersion, converts them for use as a file name and forces a ReadOnly attribute on the cached MSI.  I'll need to work something out that will clear the readonly flag on uninstall...but at the same time, *not* clear it when a patch is running.
Script is below for anyone who cares:

Dim fso, f

On Error Resume Next

Session.Property("CLEANPRODUCTCODE") = replace(Session.Property("ProductCode"), "-", "")
Session.Property("CLEANPRODUCTCODE") = replace(Session.Property("CLEANPRODUCTCODE"), "{", "")
Session.Property("CLEANPRODUCTCODE") = replace(Session.Property("CLEANPRODUCTCODE"), "}", "")
Session.Property("CLEANVERSION") = replace(Session.Property("ProductVersion"), ".", "_")

FileWithPath = Session.Property("CommonFilesFolder") & "Wise Installation Wizard\WIS" & Session.Property("CLEANPRODUCTCODE") & "_" & Session.Property("CLEANVERSION") & ".MSI"

Set fso = CreateObject("Scripting.FileSystemObject")
Set f = fso.GetFile(FileWithPath)
f.attributes = 1

Don't suppose anyone has had any further insight in to this issue?

....then unfortunately they have not shared it with us here.

Well...it's a rather odd issue I must say.
Out of curiosity, I recreated the patch creation steps listed above using a demo version of Installshield 2010.  Single versioned .exe file in the installer, 3 signed .exe wrapped installers and 2 patches to upgrade from v1 to v2 to v3...

No problems with the v1 source file being removed from the system after the v2 patch has been applied.

Is anyone familiar with how to submit what might actually be a product bug to Wise/Altiris/Symantec when you don't have a support contract?

michael_grueber@symantec.com