Software Deployment

Can you install the patch normally without errors?

Tone,

Thanks for the reply.

I am unable to install the patch locally, or update the files from the install point.

I get the following warnings in the Application event log when attempting to run the patch;
(1)

Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1004
Date: 4/11/2007
Time: 10:36:51 AM
User: <domain>\jpqui
Computer: JPQUI-VM
Description:
Detection of product '{E33E8860-E7A5-4BBF-BF15-CED548A37BEE}', feature 'Desksite8.2NewFeature', component '{8480E570-96CA-4F6F-922F-C0CF2E9A7939}' failed. The resource 'HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\PackagerVersionDS' does not exist.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

(2)

Event Type: Warning
Event Source: MsiInstaller
Event Category: None
Event ID: 1001
Date: 4/11/2007
Time: 10:36:51 AM
User: <domain>\jpqui
Computer: JPQUI-VM
Description:
Detection of product '{E33E8860-E7A5-4BBF-BF15-CED548A37BEE}', feature 'Desksite8.2NewFeature' failed during request for component '{6F047836-AABC-4B72-A37B-852C93BA91AA}'

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


In regards to the warning #1, I confirmed I have a REG_SZ in the location is it referring to;

"HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\"

with the REG_SZ "PackagerVersionDS" with a data value of "8.2.0"

Does it need a key in that path (a 'folder' icon in the registry); "HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\PackagerVersionDS" ????

Doing some more trial-and-error testing...

Creating a registry key ("folder") for HKEY_CURRENT_USER\Software\Interwoven\WorkSite\8.0\PackagerVersionDS did not have any effect.

I decided I would check out the MSP file in ORCA....

In ORCA, I browsed to the original .msi file that was used to deploy the package, and went to Transform > View Patch, browsed to this patch I'm attempting to apply, and get the following message;

"This patch can not be applied to packages with the current Product Code."

So it seems like it's something with the product code... I'm not sure how to narrow it down to exactly what the issue is....

Back to testing...

*EDIT* (not sure if it'll help, but I figured I would document it anyway...)

From the property table, the ProductCode is {E33E8860-E7A5-4BBF-BF15-CED548A37BEE}

Looks like the vendor has created a dodgy patch, does it install from the .exe?

Tone,

It fails from both the .exe and the .msp

There is a "full installer" version with the patch integrated - as an .msi. Installing this works fine, but wanted to use this as a last resort, as that would require customizing the package to meet company requirements.

I'm still digging around, and will post if I find anything striking.

Any other ideas??

The main application was distributed using Group Policy, and originally customized by someone which is no longer with the company.

So it may not necessarily the vendor's patch that is causing the problem. Is it possible that the product code was altered in the base MSI as part of the original customisation ?

If you can get hold of the original vendor's MSI (in it's non-customised form) compare the ProductCode value in that MSI with the ProductCode value in the customised MSI and see if there is a discrepancy in the values.

Regards,

Spartacus

Ah sorry missed that it had been customized, its probably not a dodgy patch... appologies to the vendor.. lol

sparacus,

Thanks for the reply. I agree, it might not necessarily be the vendor's patch -- I'm leaning more towards something that was done with the original customization. Unfortunately, I cannot find any documentation of what was customized [:@]

Anyway, following your suggestion I was able to get the unaltered original MSI. The ProductCode is;

{8B4B08BC-C27C-41F7-9572-3FBE3409637F}

The ProductCode from the customized package;

{E33E8860-E7A5-4BBF-BF15-CED548A37BEE}

Interestingly enough, I opened the original unaltered MSI and attempted to Transform > View Patch, and selected the patch -- and it applied successfully! Before when attempting to accomplish this with the altered MSI, it generated the error "This patch can not be applied to packages with the current Product Code."

So it seems the ProductCode was altered during the customization. Is there any way to force the patch to accept the 'incorrect' product code from the customized setup?

This highlights one of the problems of modifying vendor MSI's directly rather than using a transform to make any customisations, however this is a situation that you have "inherited" so it's not a problem of your own making [;)]

As has been mentioned in other notes elsewhere on appdeploy, it isn't really possible to modify the MSP (in ORCA, for example, you have already seen that the only option of patches is to view them). So your idea to make the vendor's MSP "accept" the altered product code is not really feasible IMHO.

As I see it, you have a couple of options

1) You could try and "fool" the patch into being applied by resetting the product code of the customised MSI to the of the original vendor's MSI. This could be problemmatical though depending on the extent of the customisations that were originally performed. If all the original vendor's components are still present in the customised MSI and equally importantly have their original component codes then this has an outside chance of working. The (big) assumption here is that any customisations were applied through additional features and components.

2) Alternatively, you could create your own MSP to be used in addition to the vendor's MSP. Here's how it (could) work :

Take the original vendor's MSI and the customised MSI and create a patch to represent your customised changes (you might need to modify the product code of the customised MSI back to the original product code before you start). AdminiStudio and Wise Package Studio have wizards to guide you through creating a patch, or use could use the Windows Installer SDK tools.

Now assuming you have managed to create your own MSP, you could then perform an administrative installation of the original MSI, but specifying that it is patched with both your newly created MSP and the vendor's MSP, i.e.

msiexec /a <original.msi> /p <your.msp>;<vendors.msp>

If this is successful, you will end up with a patched MSI in the admin point which contains both your customisations and the vendor's changes. This MSI would still have the original product code which means any future patches the vendor releases would then be useable.

Whether either of the above suggestions works would depend on the extent of the customisations that were made to the original MSI - if, for example, components that the vendor's MSP is expecting to patch were removed as a result of the customisations then you may be out of luck [:(]

Regards,

Spartacus

spartacus,

Thank you very much for the informative reply. And yes, this is an inherited package -- after all I've read around AppDeploy.com, one thing I know is to NEVER ALTER THE VENDOR MSI DIRECTLY!! [;)]

I will play around with generating my own patch, then applying it like you suggested.

I have no idea the extent of the customizations made for the package. I know it was made from a SnapShot method through AdminStudio [&:]

Thanks again for the suggestions. I'll post back with any progress [:)]

I was *not* able to figure out a way in AdminStudio to compare the two MSI's and generate a MSP...

I just thought of this (not sure if it would work - what do you think?)

What if i change the ProductCode for the customized package (this is the 'incorrect' code), change it to the 'correct' ProductCode which would match the un-altered MSI?

Apply the patch to the admin install point, then redeploy the application (via GPO, select "Redeploy Application").

The process sounds like it would work to me, but I'm no MSI guru [8|] Any thoughts?

*EDIT*
adjusted for readability

Alright, so I think I got it...but not the best news...

I discovered that both the ProductCode and UpgradeCode were altered from the original vendor-MSI. So after changing them back, the patch applied successfully. But after I reinstalled the "patched" version, the file versions were the same (v8.2.97) as they were prior to the patch.

There is an alternative way to get up to "Patch 3" status, by a "Full Installer" which is a complete MSI package (rather than the MSP I've been trying to deal with). When I go through the install process with the Full Installer version of 8.2 P3 - the file versions end up being 8.2.102 -- so I know something is not correct, as no matter what route I took to get there, the file versions should be 8.2.102.

So...

patching with MSP = file versions of 8.2.97
full install with MSI = file versions of 8.2.102

I'm not sure if it needs to reference some sort of feature or component that is not present in the customized version which is not allowing the files to get updated.

Looks like I might just have to deal with starting a new build based off the Full Installer Patch 3 -- at least this way I know the future patches will not have this problem!! [:'(]

you still could have an underlying issue here.

depends if you want to look at it or not.

At the end of an MSI installation the MSI is registered on the machine as being installed.

The product itself is registered and the following which is likely to be your issue is that each component is also registered.

However when the component is registered the product code is written into the components meta data which is in actual fact how the reference count scenario comes into play.

As such you may find that during uninstallation the application may not be installed as although you fooled the patch into being installed I doubt you will of fooled the uninstall.

When you do the uninstall of a product each component removes the associated product code from the component registration metadata.

When the component has no more products registered against it the component will be removed.

All of your original components will of installed against the incorrect product code which in turn means that the components will not unregister causing to them remain on the machine.

worth a look :-)