We have been installing Acrobat Pro 9.0 on machines. Now that the 9.3 update has been released we want to update the computers. I have followed the instructions to create an AIP. 9.0, 9.1, 9.1.2, 9.2, 9.3. When I attempt to install Acrobat Professional 9.3 on a computer that has Acrobat Professional 9.0 on it I receive the following error message.

Another version of this product is already installed. Installation of this version cannot continue. To configure or remove the existing version of this product, use Add/Remove Programs on the Control Panel.

If I install the package I created on a computer that does not have Adobe Acrobat Pro installed on it, there are no problems. The package is installed and it is at the correct version.

I obviously don't think I should have to manually remove Acrobat Pro 9 from the computers. Shouldn't the patched 9.3 product install over 9.0?

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

0
I'm in a similar situation now, except that I'm just getting started with this. I need to get all our installs patched from 9.0 to 9.3

If you were to manually apply patches, how do you go from 9.0-->9.3? Or even from 9.0-->9.1? I tried installing AcroProExUpd910_all_incr.msp from adobe's FTP site but I get an installer error "...the update patch may update a different version of the program".

There is nothing in the 9.0 directory on the FTP site.

edit: found it, using quarterly updates go 9.0 -> 9.1 -> 9.1.2 -> 9.2 -> 9.3

0
What a pain. So, if I understand this correctly, to properly deploy to 9.0 users, the AIP would have to contain every update from 9.2.0 forward? That's HUGE!

Is there any way to minimize the size of the file dl'd to the client for install? If we have, say 9.0, and what to get to 9.3.1, what's the best way to set up the installer so it does not require ALL the msp files? Or is this even possible?

0
Once you've patched the AIP, you won't need the MSPs because the existing files in the AIP get patched. Take a look in MSDN about what patching is

0
I'm trying to get this set up to deploy via the kbox 1000 - the AIP lacks the .cab file - appears to have a directory structure in it's place, which is very large (over 1.5gb) The original 9.1 installer, while large, is 1/2 that size.

Ideally I'd like to patch the originall installer to 9.3.1, but from what I've found this may not be possible.

The recommended option for the kbox is to create a zip file containing all dependencies, and associate that file to the application. When the software is deployed, the zip file is dl'd and expanded, and installation commands (user-defined) are run at that time. Works but due to the patching model chosen by adobe makes for a huge download for each target system.

Is patching the orginal install (setup.exe and everything else that came on the cd) doable, or is it worth the time to pursue?

0
ORIGINAL: pyperdown

What a pain.Ã‚Â  So, if I understand this correctly, to properly deploy to 9.0 users, the AIP would have to contain every update from 9.2.0 forward?Ã‚Â  That's HUGE

We use the term BLOAT here and Adobe products are full of it. What you might want to do is create an AIP and remember you have to create it from the disk. There is some issue with copying the files from the disk to your pc and then trying to create an AIP from that. Also Adobe has another hurdle. Only certain updates can be applied to your AIP http://kb2.adobe.com/cps/498/cpsid_49880.html Once you have an updated AIP and transform you can wrap it all back up using the WiMakCab.vbs to create an MSI with an embedded cab. the syntax is cscript wimakcab.vbs acrpro.msi Data1 /L /C /U /E This works really good.

0
Well, trying the AIP method. Works until I try to install 9.1.2, then fails with a dependency error. Can't find interop.adobepdfmakerx.dll

0
Have you seen the caveat in the 'Package KB' about which updates you can apply? If you have the enterprise-deployable package, you can't apply security updates to an AIP created from it, only the quarterly ones.

0
Hi folks,
to get a useful version of Acrobat Pro 9.3.1, one has to invest quite a bit. :-(
1. As Joe already pointed out, the correct sequence of patching is crucial!
2. To get the AIP REALLY patched, you need to set the property PATCHAIP=1 on the command line!
Otherwise the patches are only chained up and are applied on the fly, while installing.
3. If you want to get rid of all the patch files, you can delete them from the file table or disable the feature UpdateFiles.
This reduces the load by more than 1500 files and over 200MB!
4. To reduce the network load, one can CAB that stuff up again. Our CAB for v9.3.1 is about 580MB!
However, we use a slightly changed wimakcab.vbs, which puts higher values for CompressionLevel and CompressionMemory into the DDF file.
Installing from an AIP, it would be about 1,3GB to transfer to each machine!

@Joe: You are talking about an embedded CAB. How do you do that?
We tested that and it never worked, because an CA, which checks the certificate in the original MSI, doesn't like that.

Hope, this gives some input here and there.
Regards, Nick

0
Can you provide a commandline example of the PATCHAIP=1 usage?

My problem so far is that I can get the AIP patched to 9.1.0, but it fails at the 9.1.2 (next quarterly update) version with a missing dll error.

I have altered my approach to the following batch file, but it will not wait until the first msiexec completes.

 @echo off net use q: <\\uncpath> <password> /user:<userid> q: start /wait msiexec /i AcroPro.msi TRANSFORMS=AcroPro.mst REBOOT=REALLYSUPPRESS /qn start /wait msiexec /update AcroProStdUpd910_T1T2_incr.msp;AcrobatUpd912_all_incr.msp;AcrobatUpd920_all_incr.msp;AcroatUpd930_all_incr.msp;AcrobatUpd931_all_incr.msp REINSTALLMODE=vomus REINSTALL=ALL REBOOT=REALLYSUPPRESS /qn c: net use q: /delete 

0
Hi Jeff,
here the commands to build the initial AIP and to patch it with 9.1.0.
msiexec /p AcroProStdUpd910_T1T2_incr.msp /a AcroPro.msi TARGETDIR=C:\MSI\AcrobatPro_9.3.1_ML\adm PATCHAIP=1

Don't use network drives to build an AIP! Do it locally should solve your file missing error.

Regards, Nick

0
Thanks Nick - I will give it a try. I did switch to building to a local dir, with the same missing dll results. Do I need to do anything with the intermediate .msp files, ie 9.1.2->9.2.0->9.3.0?

Also, this is a volume license version - I've heard that using an administrative install point for this version causes problems, ie turns it into a retail version, and the serial number ceases working. Should this be a concern?

I finally got something working with a batch file that first installs the app and then applies all the patches. Works except for borking the icons on the shortcuts in the start menu. I'm less than thrilled with the "support" from adobe. Given this is one of the reasons cited for opting for proprietary software over FOSS, I'd say Adobe is making proprietary software look pretty lousy.

0
Here's the code I used... Runs as local system account (we use Kace KBOX-1000)

 @echo off net use q: <UNC PATH> <PASSWORD> /user:<USERID> q: start /wait msiexec /i AcroPro.msi TRANSFORMS=AcroPro.mst REBOOT=REALLYSUPPRESS /qn start /wait msiexec /update AcroProStdUpd910_T1T2_incr.msp;AcrobatUpd912_all_incr.msp;AcrobatUpd920_all_incr.msp;AcrobatUpd930_all_incr.msp;AcrobatUpd931_all_incr.msp REINSTALLMODE=vomus REINSTALL=ALL REBOOT=REALLYSUPPRESS /qn c: net use q: /delete 

0
PATCHAIP=1 causes process to fail. msiexec does not like that syntax. Back to square 1.

0
Hi Jeff,
PATCHAIP=1 on the msiexec command line sets only a public property and should work on every package of the world.
So it seems, there is a problem with your command line.
Make sure, that you point your command at the right files.
In my example above, you need to start the patch action from the directory with the AIP.
Regards, Nick

0
Nick - I copied your command line. The only difference I can see is that I did not start it from the aip, but the path containing the original install files (data1.cab, etc), and pointed it to the directory containing the AIP. I could not find ANYTHING regarding the PATCHAIP property. Perhaps my mistake is running the script from the wrong path? Also, I have no problem patching to 9.1.0. The problem is in patching to 9.1.2 and beyond. 9.1.0->9.1.2->9.2.0->9.3.0->9.3.1.

It would appear that Adobe has hired a bunch of microsoft engineers and placed them in decision-making roles. And all the negatives that this implies.

0
Hi Jeff,
do you have logging enabled? I hope so.
Regards, Nick

0
Nick, did the PATCHAIP=1 apply to version 8 as well? I'm guessing that it does.

ORIGINAL: nheim

Hi folks,
to get a useful version of Acrobat Pro 9.3.1, one has to invest quite a bit. :-(
1. As Joe already pointed out, the correct sequence of patching is crucial!
2. To get the AIP REALLY patched, you need to set the property PATCHAIP=1 on the command line!
Ã‚Â Ã‚Â  Otherwise the patches are only chained up and are applied on

@Joe: You are talking about an embedded CAB. How do you do that?
We tested that and it never worked, because an CA, which checks the certificate in the original MSI, doesn't like that.

Hope, this gives some input here and there.
Regards, Nick

0
Hi Jeff,
try the patching again, but this time do a CD to the AIP-directory first.
Regards, Nick

0
Will do, and will enable logging as well.

0
Switching to the aip dir before installing patches allowed the AIP to get patched and built. Thanks for that tidbit [:D] I am aware that subsequent quarterly updates will require removal of security patches before application. I will likely just rebuild the entire thing. Now to test transforms.

[font="courier new"]C:\AcrobatPro9>msiexec /a AcroPro.msi TARGETDIR=C:\AcrobatPro9AIP

C:\AcrobatPro9>cd \AcrobatPro9AIP

C:\AcrobatPro9AIP>msiexec /p c:\AcrobatPro9\AcroProStdUpd910_T1T2_incr.msp /a AcroPro.msi TARGETDIR=C:\AcrobatPro9AIP PATCHAIP=1

C:\AcrobatPro9AIP>msiexec /p c:\AcrobatPro9\AcrobatUpd912_all_incr.msp /a AcroPro.msi TARGETDIR=C:\AcrobatPro9AIP PATCHAIP=1 /Liv install.log

C:\AcrobatPro9AIP>msiexec /p c:\AcrobatPro9\AcrobatUpd920_all_incr.msp /a AcroPro.msi TARGETDIR=C:\AcrobatPro9AIP PATCHAIP=1 /Liv install.log

C:\AcrobatPro9AIP>msiexec /p c:\AcrobatPro9\AcrobatUpd930_all_incr.msp /a AcroPro.msi TARGETDIR=C:\AcrobatPro9AIP PATCHAIP=1 /Liv install.log

C:\AcrobatPro9AIP>msiexec /p c:\AcrobatPro9\AcrobatUpd931_all_incr.msp /a AcroPro.msi TARGETDIR=C:\AcrobatPro9AIP PATCHAIP=1 /Liv install.log

0
Transforms from the AIP appear to work - anyone know how to test for retail -vs - volume license?

Again, thanks Nick for pointing me in the correct direction. Now for the obligatory n00b question - is this a "best practices" technique (switching to aip dir before patching) or is it just an adobe thing?

0
Nick just to reiterate - this was the key. IMO Adobe owes you some 

Make that \$

ORIGINAL: nheim

Hi Jeff,
try the patching again, but this time do a CD to the AIP-directory first.
Regards, Nick

0
Hi Jeff,
you can't blame this particular one at Adobe. If you patch an AIP, you have to point the command line to the MSI in the AIP.
Regards, Nick

0
Hi Joe,
no, that one was invented in V9.0.
However, you could do it yourself. Basically,
it does the patching sequences, which are done in InstallExecuteSequence
But is worth the hassle?
Regards, Nick

0
Nick... I've been doing THAT all along (pointing to AIP directory). The key was CD-ing to that directory.

0
nheim, am curious on #2 and #3:

I setup the MSP patches to 9.0.0 AIP with PATCHAIP=1.

That means, i can remove the UpdateFiles safely?

ORIGINAL: nheim

Hi folks,
to get a useful version of Acrobat Pro 9.3.1, one has to invest quite a bit. :-(
1. As Joe already pointed out, the correct sequence of patching is crucial!
2. To get the AIP REALLY patched, you need to set the property PATCHAIP=1 on the command line!
Ã‚Â Ã‚Â  Otherwise the patches are only chained up and are applied on
3. If you want to get rid of all the patch files, you can delete them from the file table or disable the feature UpdateFiles.
Ã‚Â Ã‚Â  This reduces the load by more than 1500 files and over 200MB!
4. To reduce the network load, one can CAB that stuff up again. Our CAB for v9.3.1 is about 580MB!
Ã‚Â Ã‚Â  However, we use a slightly changed wimakcab.vbs, which puts higher values for CompressionLevel and CompressionMemory into the DDF file.
Ã‚Â Ã‚Â  Installing from an AIP, it would be about 1,3GB to transfer to each machine!

@Joe: You are talking about an embedded CAB. How do you do that?
We tested that and it never worked, because an CA, which checks the certificate in the original MSI, doesn't like that.

Hope, this gives some input here and there.
Regards, Nick

0
Yes

0
one more question :)

the PATCHAIP=1 doesn't work on Acrobat 7?

I've patched 7.0.0 with 7.1.0 & 7.1.3 and then remove the UpdateFiles. After installation, the patched never applied.

thanks!

ORIGINAL: nheim

Yes

PATCHAIP=1

0
Hi David,
have a look at post #25.
Regards, Nick

0
ahh it's do-able then.

for me, i think it's worth it cuz removing the UpdateFiles can shaves 69MB. Upon compressing the AIP, overall package size is around 140MB (rough size after manually removing Updates folder in the AIP).

any chance of tutorial/points to edit the MSI table (InstallExecuteSequence/AdminExecuteSequence)? :)

if it's troublesome, then nvm.

thanks!

0
Hi David,
had a quick look at the package. It seems pretty easy to do.
 PreparePatchByFile (Not REMOVE="ALL") And PATCHAIP 1490 ApplyPatch_ACROBAT_Imm (Not REMOVE="ALL") And PATCHAIP 4150 ApplyPatch_ACROBAT (Not REMOVE="ALL") And PATCHAIP 4160 
The "PATCHAIP" property is optional, it makes the behavior the same as in V9.
To make it even easier, you could copy the 3 lines from the InstallExecuteSequence table.
This stuff is best done in ORCA, of course.
This should work on Acrobat Pro v7 + v8.
So, that's it folks, the rest is yours!
Awaiting to see some (positive) feedback her. ;-)
Regards, Nick

0
ok, preliminary results = WORKING! [:D]

I will need to reconfirm this by doing a manual version check on the plugins (where most of the patches are applied), and some other important files (acrobat.exe, *.exe, *.dll).

version check of the plugins are WITHIN acrobat, so this may take a while.

my comparison will be based on the PATCHAIP-method --vs-- conventional AIP method (whereby in v7, the updates are chained and executed post-installation).

side notes: @nheim, you mentioned 'bout copying all the lines from InstallExecuteSequence table. <-- i noticed there are MANY lines to be copied over. However, i think i understand why you proposed this as the sequences are replicated from InstallExecuteSequence (normal install method) --> AdminExecuteSequence (AIP method).

So if copied over, whenever AIP is used, it *behaves* as if the patches are being applied *normally*

anyhow, much appreciate the tips!! [:)]

0
Hi David,
good to see you make progress.
The statement "copy all lines" maybe wasn't exact enough. It was referencing only the 3 lines mentioned.
I have corrected this in my earlier post.
Regards, Nick

0
ok, i spoke too soon.

culprit is with v7.1.0 patch. <-- besides patching existing files from v7.0.0, it also introduces many *NEW* files as well <-- one 'marker' file i take note is AcroIF.dll

so, if i use the PATCHAIP method for v7.1.0, v7.1.3, v7.1.4 and delete the UpdateFiles inside the MSI (and regenerate the AIP again), the *new* files from v7.1.0 patch will not be copied over (because the references have been deleted as well after i removed UpdateFiles in the MSI).

any ideas? ;)

0
Hi Dave,
if it were that easy, everybody woul/could do it... :-)
The guide in post #9 is only working on v9!
For v7+v8, leave the UpdateFiles feature as it is and delete all the patch file (with rtp extension) from the file table.
That should do it.
Regards, Nick

0
tried this. not effective.

there are 3 subfolders under UpdateFiles: UpdateFiles_710, UpdateFiles_713, and UpdateFiles_714. <-- all files listed in the table ends with .RTP extension.

e.g. the new file AcroIF.dll is listed as AcroIF_dll_710.rtp.

0
Hi Dave,
that is not true!
We have old v7 AIP's here and it shows clearly, that this file was introduced in v7.0.5 (all files file from seq 3012 to 3090 stem from the 7.0.5 update).
So, it depends on, where you start. If you start with the 7.1.0 full installer, this should be no problem at all.
If you start with 7.0.0, make sure, you apply all the patches needed.
To get a clean picture, its best to use msitran from the SDK an produce an MST from the updated version against the base version.
Then open the base version in ORCA and apply the MST. With this, you see all the changes.
Regards, Nick

0
well, i start from 7.0.0 base source, then move upwards with 7.1.0 > 7.1.3 > 7.1.4.

the update path is referenced from http://kb2.adobe.com/cps/498/cpsid_49880.html

Below the page, it's also stated this:

The oldest patch shown above for Acrobat Version 7 is 7.1.0. Although previous patches were released between the 7.0.0 original product and the 7.1.0 patch, Adobe recommends that any current customer deploying version 7 bypass the interim patches and step directly to 7.1.0 and beyond.

0
Hi Dave,
i have to apologize!
This is a true Adobe-mess! They install new files in this cumulative update with the patcher!
No wonder, there are so many problems out there to update or uninstall such stuff. Just unbelievable.
As i mentioned in the previous post, in the upgrades like 7.0.5 they install the new files with the InstallFiles action.
You could apply all the minor patches up to 7.1.0 and see, if the File table is populated the right way.
However, the only way to make it tight, would be to watch the changes with a tool like Installwatch or InCntrl.
Wish you good luck.
Regards, Nick

0
no sweat 'bout this, nick. [;)]

Adobe fixes their software but breaks a lot more on the packaging. They should've released a COMPLETE & FINAL v7.1.4 package as it has reached EOL.

anyhow, i was planning to integrate v7.0.5 [cumm] > 7.0.7 [?] > 7.0.8 [?] > 7.0.9 [?] > 7.1.0 [qtr] > 7.1.3 [qtr] > 7.1.4 [qtr]

i know i need the cummulative updates (e.g. 7.0.5) but i'm not sure what type/category of updates for 7.07--7.09.

on another note, i know 7.0.8 is needed as Acrobat.exe was last updated from this branch.

nonetheless, will try them out over the weekend :)

THANKS!

0
It was my understanding that even-numbered patches were the quarterly updates and the odd-numbered ones were security fixes and that they weren't to be (or couldn't be) mixed. Perhaps that's only for v9 upwards....

0
Take a look here, (scroll down to the version 7 part)...

Quoting:
The oldest patch shown above for Acrobat Version 7 is 7.1.0. Although previous patches were released between the 7.0.0 original product and the 7.1.0 patch, Adobe recommends that any current customer deploying version 7 bypass the interim patches and step directly to 7.1.0 and beyond.

0
Nice one, Rowan. It would be useful to post that link to ALL the Adobe Acrobat/Reader entries in the 'Package KB'.

0
Haha, davidlimcg23 actually beat to me this, just a few posts above me, an almost identical post. (I just noticed this when scrolling down and getting confused because my name wasn't on my post)

But I'll add them to all the entries in the Package KB, it's not like I've got anything better to do (Ran out of apps to package for current customer ;P)

0
got a VERY GOOD news :)

just integrated v7.0.0 with 7.0.5 > 7.0.7 > 7.0.8 > 7.0.9 > 7.1.0 > 7.1.3 > 7.1.4 patches

All files are fully updated and identical as per normal MSP chaining and AIP.

in fact, integrating 7.0.9 is a good idea cuz it updates AcroPDF.dll (in ActiveX folder)!! <-- which, btw, is NOT UPDATED by 7.1.0/7.1.3/7.1.4 updates (hence AcroPDF.dll is still 7.0.0).

All in all, the PATCHAIP reduces the whole AIP size to 522MB uncompressed (vs 593MB of non-PATCHAIP method <-- redundant ~71MB due to temporary patches)

well @nheim, shaving ~71MB from the AIP package do worth the hassle :D only need time and effort to find out the WHY ;)

p/s: now time to do serious compression (repackaging) with 7-Zip [:)]

0
update: compressed v7.1.4 AIP (522MB) --> 138MB (7-Zip) [:D]

0
All of the Acrobat deployment doc needs improvement. I've been posting this to let folks know that's happening now (can't do much about the actual product though. . ):

Hi folks,
Adobe recognizes a clear need to provide admins with more and better documentation and resources. To this end, resources are being updated and corralled in an enterprise portal here: http://kb2.adobe.com/cps/837/cpsid_83709.html. Note that one resource is an AIR application which contains much of the documentation and an ever growing Preference Reference documenting over 300 keys. Expect several hundred more pages of new and updated doc in the coming months.
thanks,
Ben

0
When trying to patch my Acrobat Pro 9 AIP (current version of AIP is 9.0), I keep getting an annoying "Error 1305: Error reading from file D:\managedsw\acrobatpro\9\AcroPro.msi. Verify that the file exists and that you can access it."

(D:\managedsw\acrobatpro\9 is the AIP)

Yes, the file exists in that exact location (D: is not a mapped network drive or a substituted drive letter) and I can definitely access the file. Here is the command (including prompt) I'm using from a command prompt with D: the selected drive and CD'd to the AIP path:

D:\managedsw\acrobatpro\9>msiexec /p F:\path\to\patches\AcroProStdUpd910_T1T2_incr.msp /a AcroPro.msi TARGETDIR=D:\managedsw\acrobatpro\9 PATCHAIP=1

I've tried this without the TARGETDIR and PATCHAIP variables, enabled logging (/lv* ...), granted SYSTEM user full control of AIP and a few other steps. Haven't tried swearing yet--at least not audibly. Yes, I'm running this as an administrator (domain administrator to be specific). F: is also a volume proper, not a mapped or substituted drive. For kicks, I even downloaded AcroProExUpd910_all_incr.msp and tried patching the AIP with that update, but that at least returns "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..."

Any suggestions?

0
@berserk,

try setting the TARGETDIR to different folder/location.

0
ensure AcroPro.msi is not being used/loadedI'm intrigued to learn exactly how an MSI gets patched without being loaded...

0
I never did figure out what was going on. I had tried the TARGETDIR variable at one point, but that didn't seem to help. Eventually, I built the AIP on my Windows 7 client then copied it over to the Windows 2003 server I had been attempting to build it on. This worked, but it still annoys me. Would like to get to the bottom of it. [:)]

0
Hi all,
Let me add some frustration to this long Acrobat upgrade thread... Following the guidance on several fora i tried this:
I created a new patched distribution source for "acrobat professional 9".
The original v9.0 distribtion source was patched to version 9.3.3 via an AIP with following patches
AcroProStdUpd910_T1T2_incr.msp
AcrobatUpd912_all_incr.msp
AcrobatUpd920_all_incr.msp
AcrobatUpd930_all_incr.msp
AcrobatUpd932_all_incr.msp
AcrobatUpd933_all_incr.msp

So far no problem, the patched source works fine for new installs, but when I try to use this installer to upgrade an existing 9.0 I get the "Another version of this product is already installed" error (hmmm, the same error this thread started with...). Is there any way to eliminate this? I created an .mst via the customization wizard that mentions that previous version should be uninstalled?

I want to eliminate having an upgrade procedure for exisitng installs and another procedure for new installs.

Only thing I can do now is uninstall the existing version before installing with the 9.3.3 source or create a separate upgrade distribution that does a chained patch install.

0
I can't be fagged going through the entire thread but don't I recall reading that you shouldn't/can't patch with the even-numbered patches AND the odd-numbered ones? That would make your 933 patch spurious...

0
ORIGINAL: VBScab

I can't be fagged going through the entire thread but don't I recall reading that you shouldn't/can't patch with the even-numbered patches AND the odd-numbered ones? That would make your 933 patch spurious...

It should be OK.
Acceptable: Acrobat 9.0.0 (Original Product) -> 9.1.0 (Quarterly) -> 9.1.2 (Quarterly) -> 9.2.0 (Quarterly) -> 9.3.0 (Quarterly) -> 9.3.2 (Quarterly) -> 9.3.3 (Quarterly)

0
Excellent. They'd know if anyone would [uncrosses fingers]

0
ORIGINAL: VBScab

Excellent. They'd know if anyone would [uncrosses fingers]

Sure... :-)

So anyone an idea about the "Another version of this product is already installed" error ?

0
So anyone an idea about the "Another version of this product is already installed" error ?

I had a quick look at the package we have here for Adobe Reader. First off lemme tell you it's 9.1.1, but my remarks might still be pertinent.

In the upgrade table there's a number of entries that seem to check for different versions of the Reader sharing the same UpgradeCode. They all evaluate to a property called UT_FR.
Furthermore there's a CA called OlderOverNewerAbort that has a condition Not Installed And UT_FR

This to me looks like a likely candidate for disabling as a little test... would do it myself but I REALLY can't spare the time..

PJ

0
Hi folks,
The "Another version of this product is already installed" error comes exact from what it says. It is thrown when an app with the same Productcode is already installed.
This is the case here, because the patches do not change the Productcode, which remains the same from version 9.0 onward.

One could change the Productcode of a new release, like 9.3.3, but i wouldn't recommend it, because there are several CA's in the package which use the Code.
Adobe is (mis-) using the Productcode for different things (like the distinction between retail and volume licensing). See the link above.

We use our deployment system to uninstall and install a newer version in one task.

Regards, Nick

0
If u get an error messge another version of this product is installed Jusst at the end of MSi use the properties in command line REINSTALL=ALL REINSTALLMODE=OMUSlike msiexec /i {} REINSTALL=ALL REINSTALLMODE=OMUS
It WOrks...

0
It's as well to NOT advise people how to work around situations which are clearly not right but rather to tell them how to fix them. Remember my car analogy in your post about port settings? To stretch it further, using the logic you express here, the "solution" in that situation would probably be to wear ear defenders...