Hello,

I am working with the program Interwoven iManage Desksite 8.2, and trying to apply the latest patch (Patch 3). This comes as a InstallShield EXE with the .MSP file inside to apply. The main application was distributed using Group Policy, and originally customized by someone which is no longer with the company.

I run the EXE, which extracts the MSP file to %temp%.

I attempt to run the following command to update the installation point;

msiexec /update Patch.msp /a "\\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi" /l*v C:\msilog.log

This is the log file which was generated;

=== Verbose logging started: 4/10/2007 13:16:28 Build type: SHIP UNICODE 3.01.4000.2435 Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (54:14) [13:16:28:546]: Resetting cached policy values
MSI (c) (54:14) [13:16:28:546]: Machine policy value 'Debug' is 0
MSI (c) (54:14) [13:16:28:546]: ******* RunEngine:
******* Product: \\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi
******* Action: ADMIN
******* CommandLine: **********
MSI (c) (54:14) [13:16:28:921]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (c) (54:14) [13:16:28:937]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (54:14) [13:16:29:234]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (54:14) [13:16:29:234]: SOFTWARE RESTRICTION POLICY: Verifying package --> '\\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi' against software restriction policy
MSI (c) (54:14) [13:16:29:234]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (c) (54:14) [13:16:29:234]: SOFTWARE RESTRICTION POLICY: \\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi is not digitally signed
MSI (c) (54:14) [13:16:29:249]: SOFTWARE RESTRICTION POLICY: \\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi is permitted to run at the 'unrestricted' authorization level.
MSI (c) (54:14) [13:16:29:562]: Cloaking enabled.
MSI (c) (54:14) [13:16:29:562]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (54:14) [13:16:29:578]: End dialog not enabled
MSI (c) (54:14) [13:16:29:578]: Original package ==> \\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi
MSI (c) (54:14) [13:16:29:578]: Package we're running from ==> C:\DOCUME~1\jpqui\LOCALS~1\Temp\e051c.msi
MSI (c) (54:14) [13:16:29:624]: APPCOMPAT: looking for appcompat database entry with ProductCode '{E33E8860-E7A5-4BBF-BF15-CED548A37BEE}'.
MSI (c) (54:14) [13:16:29:624]: APPCOMPAT: no matching ProductCode found in database.
MSI (c) (54:14) [13:16:29:624]: MSCOREE not loaded loading copy from system32
MSI (c) (54:14) [13:16:29:640]: Machine policy value 'TransformsSecure' is 0
MSI (c) (54:14) [13:16:29:640]: User policy value 'TransformsAtSource' is 0
MSI (c) (54:14) [13:16:33:234]: Original patch ==> C:\Documents and Settings\jpqui\Desktop\Desksite 8.2 P3\Patch.msp
MSI (c) (54:14) [13:16:33:234]: Patch we're running from ==> C:\DOCUME~1\jpqui\LOCALS~1\Temp\e051d.msp
MSI (c) (54:14) [13:16:33:266]: SOFTWARE RESTRICTION POLICY: Verifying patch --> 'C:\Documents and Settings\jpqui\Desktop\Desksite 8.2 P3\Patch.msp' against software restriction policy
MSI (c) (54:14) [13:16:33:266]: Note: 1: 2262 2: DigitalSignature 3: -2147287038
MSI (c) (54:14) [13:16:33:266]: SOFTWARE RESTRICTION POLICY: C:\Documents and Settings\jpqui\Desktop\Desksite 8.2 P3\Patch.msp is not digitally signed
MSI (c) (54:14) [13:16:33:266]: SOFTWARE RESTRICTION POLICY: C:\Documents and Settings\jpqui\Desktop\Desksite 8.2 P3\Patch.msp is permitted to run at the 'unrestricted' authorization level.
MSI (c) (54:14) [13:16:33:266]: SequencePatches starts. Product code: {E33E8860-E7A5-4BBF-BF15-CED548A37BEE}, Product version: 8.2.0, Upgrade code: {C8B7B9E6-84E8-4DEB-B92A-894E7BFE1E1E}, Product language 1033
MSI (c) (54:14) [13:16:33:281]: PATCH SEQUENCER WARNING: C:\Documents and Settings\jpqui\Desktop\Desksite 8.2 P3\Patch.msp patch will not be sequenced because it does not contain any transform that may apply to product!
MSI (c) (54:14) [13:16:33:281]: SequencePatches returns success.
MSI (c) (54:14) [13:16:33:281]: Final Patch Application Order:
MSI (c) (54:14) [13:16:33:281]: Other Patches:
MSI (c) (54:14) [13:16:33:281]: Unknown\Absent: {FB5B03F7-5B8A-4C78-9299-72E34978ADF7} - C:\Documents and Settings\jpqui\Desktop\Desksite 8.2 P3\Patch.msp
The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer an
d that you have the correct upgrade patch.
\\dcris\apps$\TestArea3\Imanage\Desksite\8.2\Desksite82.msi
MSI (c) (54:14) [13:16:33:328]: Product: Desksite 8.2 - Update '{FB5B03F7-5B8A-4C78-9299-72E34978ADF7}' could not be installed. Error code 1642. Additional information is available in the log file C:\msilog.log.

MSI (c) (54:14) [13:16:33:328]: Note: 1: 1708
MSI (c) (54:14) [13:16:33:328]: Note: 1: 2729
MSI (c) (54:14) [13:16:33:391]: Note: 1: 2729
MSI (c) (54:14) [13:16:33:391]: Product: Desksite 8.2 -- Installation failed.

MSI (c) (54:14) [13:16:34:344]: Attempting to delete file C:\DOCUME~1\jpqui\LOCALS~1\Temp\e051d.msp
MSI (c) (54:14) [13:16:34:359]: MainEngineThread is returning 1642
=== Verbose logging stopped: 4/10/2007 13:16:34 ===


And the error message box states:

The upgrade patch cannot be installed by the Windows Installer service because the program to be upgraded may be missing, or the upgrade patch may update a different version of the program. Verify that the program to be upgraded exists on your computer and that you have the correct upgrade patch.

I know for sure that the correct program/version is installed. I think by reading the logs, it is saying that a feature it's looking for is missing (MSI (c) (54:14) [13:16:33:281]: Unknown\Absent: {FB5B03F7-5B8A-4C78-9299-72E34978ADF7}).

Is there any way to figure out what feature it is looking for? Or how to make it bypass the 'missing' feature and only update what is present? It's possible my predecessor may have removed some features on purpose?

Thanks in advance for any help or suggestions.
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
Can you install the patch normally without errors?
Answered 04/10/2007 by: Tone
Second Degree Blue Belt

Please log in to comment
0
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" ????
Answered 04/11/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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}
Answered 04/11/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
Looks like the vendor has created a dodgy patch, does it install from the .exe?
Answered 04/12/2007 by: Tone
Second Degree Blue Belt

Please log in to comment
0
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??
Answered 04/12/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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
Answered 04/12/2007 by: spartacus
Black Belt

Please log in to comment
0
Ah sorry missed that it had been customized, its probably not a dodgy patch... appologies to the vendor.. lol
Answered 04/12/2007 by: Tone
Second Degree Blue Belt

Please log in to comment
0
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?
Answered 04/12/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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
Answered 04/13/2007 by: spartacus
Black Belt

Please log in to comment
0
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 [:)]
Answered 04/13/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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
Answered 04/13/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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!! [:'(]
Answered 04/13/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
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 :-)
Answered 04/17/2007 by: jmcfadyen
Fifth Degree Black Belt

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