Just wondering if anyone has the same issue or is my process wrong?

With Adobe Acrobat Standar 9.0, I create the admin install on a network shares and ran the Adobe Customization Wizard 9.0 to create a custom MST file. I also had the serial number in the MST. All sweet and working fine.

Now, with the 9.1.0 patch. (AcroProStdUpd910_T1T2_incr.msp), I patched the admin installation point by:

1. changing to admin install diretory in the command prompt (run as admin in vista)
2. msiexec /a Acrostan.msi /p AcroProStdUpd910_T1T2_incr.msp /passive /norestart

When I ran the install from the patch 9.1.0 admin installation path, I get the serial number error in a dialog box???
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
Hi AH,
just solved the exact same issue.
The problem is, that the custom action, which sets the serial number, checks the signature of the MSI package.
You can circumvent this, by creating a transform from the changes, which does the 9.1 patch to the MSI.
Something like this:
msitran -g AcroPro.msi AcroPro9_1.msi diff91.mst
Then use a command line like this to install:
msiexec /i AcroPro.msi TRANSFORMS=diff91.mst;1033.mst

Regards, Nick
Answered 03/25/2009 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Hi Nick,

So, If I understand to you correctly, what you meant was creating a transform for the changes from 9.0 to 9.1 and apply 2 mst to the 9.0 msi when installing on client?

I have 2 admin path, one for 9.0 and one for 9.1
c:\9.0 and c:\9.1

How to do this in AdminStudio if I don't use the msitran utility? Will InstallShield MSI Diff do the job?
Answered 03/25/2009 by: ahcash
Orange Belt

Please log in to comment
0
Hi AH,
yes, exactly.
but i strongly encourage you, to use msitran. It's in the Installer SDK.
It does what's needed and nothing else!
What i forgot in my first post: You need to set the "Administrative Image" checkbox and remove the "Compressed by default" in the Summary Information dialog in the original MSI file.
Good luck.
Regards, Nick
Answered 03/26/2009 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
Hi Nick,

OK. I managed to generate an MST (91diff.mst) using msitran. There is one question which I need to ask and pardon my ignorance.

If I ran the installation using msiexec /i original_9_0.msi TRANSFORMS=91diff.mst;custom.mst , If there are new files that are required, how does it know where to get the new files from since the MST file does not contain any files.

To explain a bit more: (hope I don't confuse you..)

I have 9.0 administrative image in c:\9.0 for example
and
I have 9.1 administrative image in c:\9.1

There will be a whole bunch of files and stuff in 9.1 which will be replacing 9.0 I am sure..
So, if I ran the msitran and created the diff.mst and run it against the 9.0 admin image,

How does the MSI knows where the new files are since we are?
Answered 03/26/2009 by: ahcash
Orange Belt

Please log in to comment
0
Hi AH,
you need to rename the resulting AcroPro.msi in your 9.1 directory.
Then copy the original AcroPro.msi into 9.1. Afterwards, do the checkmark thing to it.
In this directory you have all the files, you need for 9.1, right?
So call your 9.1 install from this directory and you are all set.

You also could compress the files again with: cscript WiMakCab.vbs AcroPro.msi Data1 /L /C /U
Then, you wouldn't even have to change the compressed checkmark.

Regards, Nick
Answered 03/26/2009 by: nheim
Tenth Degree Black Belt

Please log in to comment
0
I'm sorry, maybe I'm missing something here. I've got a VLK for Acrobat Pro 9.0 and a deployment that has been working perfectly for months. I needed to make a new install for 9.1, so I created an admin install point and applied the 9.1 patch. I then ran the ACW against the AIP that included my key and generated a new .mst. When I try to deploy this new install it fails with a serial number error. Nick, is this the problem you've addressed above? It sure looks like it, but I'm really confused because I would have suspected that more people would be asking about this problem. I haven't found any info on this anywhere, and most certainly not from Adobe. It sounds like this behavior is by design, and yet we haven't received any new keys from Adobe that support the new patched .msi, or any other communication for that matter. Again, maybe I'm missing something, but this doesn't seem like something we should have to be "working around."

Thoughts?
MrH
Answered 04/13/2009 by: MrH
Orange Belt

Please log in to comment
0
I'm having trouble with this as well. Modifying the original msi with the changes suggested (uncheck "Compressed by default", and "Administrative Installation") changes its signature, which causes the original error when you try to install it with the transform that contains the serial number.

I'd be fine with leaving the installation point as it is and apply the msp to workstations individually, but that seems to screw up installations to the point that Windows Installer wants to repair it.

Help!
Answered 04/15/2009 by: steeef
Yellow Belt

Please log in to comment
0
I actually had this problem even with the 9.0 by itself. I extracted the MSI, created an MST through the customization wizard, installed it manually to test, worked like a charm. I proceeded to add it to my client's deployment tool (Altiris) which runs the installation under a predetermined network account and BAM serial number error.

So, in Altiris, rather than installing the application via command line with a specified user account, I selected the option where it would copy all the files to the local machine and then run under the System account...worked like a charm (grant it, took a lifetime).

Needless to say, the same behavior occurs when I upgraded to 9.1. IMO, this is a faulty DLL trying to set the serial number (EMI_ORIENTATION.dll). Or, "flawed by design" as I've come to warmingly think of some vendors' packaging practice...
Answered 04/24/2009 by: jcarri06
Senior Purple Belt

Please log in to comment
0
I have this working without a bunch of extra junk. What we did was to do an admin install of the package with the original mst (yes, I know...can't be done, right?) msiexec /a acropro.msi /qb TRANSFORMS=acropro.mst

Then we applied the patch to the admin install msiexec /p ...

Then we ran the installation as the system account with the original mst and everything came down just fine. [:D] msiexec /i acropro.msi /qb /l*v install.log TRANSFORMS=acropro.mst

Hope this helps everyone out there. I honestly don't know how we're going to apply subsequent patches when they come out, but we'll cross that bridge when we get to it.

HTH
Answered 04/24/2009 by: got2bmvp
Yellow Belt

Please log in to comment
0
What we did was to do an admin install of the package with the original mst (yes, I know...can't be done, right?)
Oh, it can be done. How? The transform is ignored.
Answered 04/27/2009 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: got2bmvp
Then we ran the installation as the system account with the original mst and everything came down just fine.


Correct HTH, that's what I mentioned on my earlier post. The registration DLL works when ran under the logged on user or the System account...but has issues when running as a different account (whether by trying Run As or a tool that you specific which user to run the installation as...such as Altiris).
Answered 04/27/2009 by: jcarri06
Senior Purple Belt

Please log in to comment
0
I'm using SMS 2003 to distribute it, and by default, SMS uses the local administrator account to install packages, and indeed, that's what I was using to install the base package (9.0, which worked), and the update (9.1, which did not).

I could specify to run as the current user, but I always assumed this wouldn't work unless they had the ability to install software.
Answered 04/27/2009 by: steeef
Yellow Belt

Please log in to comment
0
I tried specifying "run as logged in user" in SMS, but as I suspected, this only worked when the user was an admin. If an admin logs in, the update applies successfully, and after a reboot, anyone can use Acrobat after it's been updated.

Any help automating this? I'm not going to manually log in as an admin every time.
Answered 04/27/2009 by: steeef
Yellow Belt

Please log in to comment
0
Steef,

When I run my 9.0 and 9.1 installations (with MST) as the System Account, it installs fine. The 9.1 was created like every other admin method...create admin install, patch, apply mst.

There is still an issue however with installing it under a specified user account...which shouldn't be impacting SMS users out there anyhow :P.

Don't think I can be of much assistance besides that...it's all in the DLL that's causing trouble, which goes back to the vendor. Maybe one of the guys here may have deeper insight.

Good luck.
Answered 04/27/2009 by: jcarri06
Senior Purple Belt

Please log in to comment
0
Yeah, SMS installs as the System account by default, so I gave it another go, but no dice. Applied the patch to the install and then had SMS attempt to install it. It returned the same error as when I tried to install it manually, stating the serial number in the error message.
Answered 04/27/2009 by: steeef
Yellow Belt

Please log in to comment
0
Hi VBScab,

Would you mind elaborating on why the transform is ignored? I'm having similar problems and can't seem to get the transform to apply after patching the installation source. Also tried nheim's solution using msitran, but the MST is still not being applied.
Answered 06/04/2009 by: itismike
Senior Yellow Belt

Please log in to comment
0
Would you mind elaborating on why the transform is ignored?When you understand what patches and transforms are, it's easy enough. In simple terms, a transform is a delta of the original database. A patch makes changes to a database and creates, in effect, a new MSI. It would therefore be pointless applying a transform to a changed database.

So, the correct method is to create the AIP, patch the MSI, then apply the transform to that MSI for subsequent installs. Thus:

msiexec /a acropro.msi
msiexec /a acropro.msi /p whatever.msp

Then on the target workststations:

msiexec /i acropro.msi TRANSFORMS=acropro.mst /qb /l*v install.log
Answered 06/04/2009 by: VBScab
Red Belt

Please log in to comment
0
ok thanks for explaining the basics. It helps to hear it laid out like that.
So if an mst is applied to an msi creating a new msi (with changes), it might break when an msp is applied if something touched by the original transform was modified by an update. Or at least that's how it makes sense to me.
Answered 06/04/2009 by: itismike
Senior Yellow Belt

Please log in to comment
0
Transforms applied to an MSI don't create a new MSI: only patches do that.The gist of what you say is correct, in that it's conceivable that a patched MSI may not work with its original transform. It's highly unlikey to be an issue (I've yet to come across it in almost 10 years of this nonsense) but testing is always advised.
Answered 06/04/2009 by: VBScab
Red Belt

Please log in to comment
0
I see. I misunderstood the result of the mst. So that only applies to the target installation, not the msi. Thanks again for clearing this up. I look forward to gaining more experience in this realm soon.
Answered 06/04/2009 by: itismike
Senior Yellow Belt

Please log in to comment
0
Ok I got it! Only caveat is that Adobe's Customization Wizard seems unable to really suppress a reboot. The directions two posts up worked smoothly:
http://itninja.com/question/gnu,-freeware-and-shareware-programs-to-cloning6524&mpage=1&key=&#
  1. create administrative install point
  2. push all msp patches
  3. create new transform using the Customization Wizard to include the serial number and other preferences
Then I used the following to install it on the clients:
msiexec /i \\[SERVER]\[SHARE$]\install\AcrobatPro\Current\AcroPro.msi TRANSFORMS=\\[SERVER]\[SHARE$]\install\AcrobatPro\Current\acropro.mst /qb /l*v %SYSTEMDRIVE%\techs\install\logs\AcroPro_8.1.5.log REBOOT=ReallySuppress

Thanks again VBScab!
Answered 06/06/2009 by: itismike
Senior Yellow Belt

Please log in to comment
0
I still have this issue.

As suggested above I have created my admin install and applied my patches (4 in total to bring Acrobat Pro up to V9.1.3) and then used the Customization Wizard on the patched MSI to create my transform. I still get the error message, I assume because the MSI is now not the original provided by Adobe.
Answered 09/22/2009 by: wynnem
Orange Belt

Please log in to comment
0
I managed to resolve my issue.

The problem was I was patching from V9 to V9.1.3.

I had to create an AIP of 9..then slipstream 9.1.0 -> 9.1.2 -> 9.1.3

I read on the Adobe web site you can not apply Quaterly patches over the top of Interim Security Patches, thats why I had to miss Slipstreaming 9.1.1.

I then ran the customization wizard on the AIP 9.1.3 MSI and Tested AOK.
Answered 09/23/2009 by: wynnem
Orange Belt

Please log in to comment
0
wynnem:

Could you please explain how you manage to resolve the issue?
Does your serial # still working?

Thanks.

EMPfu
Answered 12/22/2009 by: empfu
Yellow Belt

Please log in to comment
0
Create an Admin Point first
msiexec /a pathtomsi\test.msi
Specify where to extract the msi when dialog comes up
Patch the Admin Point msi
msiexec /a pathtomsi\test.msi /p pathtomsp\test.msp
if patched successfully you will notice you msi date midified will change to the current date.
Create new tranform from the pathed msi.
Answered 04/28/2010 by: bermade
Senior Yellow Belt

Please log in to comment
0
Hi folks,
the Acrobat MSI is kind of special.
See: http://itninja.com/question/faulttree-108402&mpage=1&key=AIP&#
Regards, Nick
Answered 04/30/2010 by: nheim
Tenth Degree Black Belt

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

Share