We are having a truly bizarre problem.

We have Adobe Acrobat 9.3.3.
This is a monster install so we created an Admin install for it.
All of our source files live on our DFS Share.
We push out an instruction .EXE that says "go to DFS share and run the following:
msiexec /i "dfs share\acrobat.msi TRANSFORMS=dfs share\acrobat.Mst /qb! REBOOT=R"

We have 7 different cities in our environment.
I have confirmed that the DFS share and files are all the same.

When we manually run this Acrobat 9.3.3 exe from 1 city it works.
When we manaully run this Acrobat 9.3.3 exe from a remote city it prompts for the Serial number.

Why on earth would it do that? And.....if I try to run it all "without" the .MST and specify the ISX_SERIALNUBER on the command line using the Exact Same Serial number from the .MST file it fails......unless I run it from City #1.

What the heck? Why would Acrobat do that? What causes this?
0 Comments   [ - ] Hide 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.
Answer this question or Comment on this question for clarity


ze log, it tells all.
do ze verbose log and see where it fails.
Answered 07/19/2010 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
Log is not needed. It throws up a dialog saying "Your serial number 1111-22222-33333-44444-55555-6666 is not valid. Yet it IS a vaild serial number which works when run from certain DFSShares. So what I am going to do is copy all the files to the local C:\ drive and then run it. If removing the DFS Share from the picture works then we know problem.
Answered 07/19/2010 by: mhsl808
Fifth Degree Brown Belt

Please log in to comment
If the MSI/MST works from a command line and that is what you used in your EXE, and EXE works fine in city 1, then if everything is equal (the files on the servers, etc.), then it won't matter where you run the exe from as long as the EXE can get to the DFS. So, my quess is that it's not the MSI/MST but either the EXE you created, or, it's environmental. Maybe there is a snytax error in your EXE (like an explicit or implicit path) that works fine locally in city 1 but not anywhere else?

I agree with Owen that if you put a verbose log in your EXE and run it from city 1 and then run the EXE from another city, you should be able to look at the 2 different logs and find the problem.
Answered 07/19/2010 by: bearden3
Purple Belt

Please log in to comment
Ok.....it is not Adobe :-) (but they still make packaging harder than it should be). It was our DFS Share. When I ran everything from City 1 it works. When I would remote into a PC in City 2 or City 3 and ran the Adobe installer it would die. Then, from both City 2 and City 3 I forced the machine to point to the DFS share in City 1 and it all worked. Now, I need to examine our DFS share to find out what's up.
Answered 07/20/2010 by: mhsl808
Fifth Degree Brown Belt

Please log in to comment