Software Deployment

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

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?

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

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?

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

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

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!

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...

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

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.

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).

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.

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.

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.

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.

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.

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

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.

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.

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.

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!

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.

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.

wynnem:

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

Thanks.

EMPfu

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.

Hi folks,
the Acrobat MSI is kind of special.
See: http://itninja.com/question/faulttree-108402&mpage=1&key=AIP&#
Regards, Nick