Repackaging Acro Pro 6.0.2
Okay, Acrobat Pro 6 uses the following merge modules sqlsrv.msm,sqlbase.msm,sqlsrv_res.msm, I recieve this error on install of the MSI "Strong SA Password is required". Now MS recommendation is to, install SQL Sp3a with a setup parameter of blanksapwd=1. This did not fix the problem . Does anyone have a workaround, possilby editing the sqlsrv.msm with Orca? Assistance Required!
0 Comments
[ + ] Show comments
Answers (1)
Please log in to answer
Posted by:
craig16229
19 years ago
Scorpianfrog,
This sounds like you performed a capture on Acrobat 6.0.2, and then compiled it into a new .msi. Acrobat is already in .msi format, and the InstallShield Tuner for Acrobat can be used to create a transform file and acheive the customizations that are needed. Best practices say not to re-capture and re-compile an .msi into a new .msi. The best explanation of this can be found here:
http://www.appdeploy.com/FAQ/detail.asp?id=6
There are certain (rare) situations where this rule is broken, but you have to do so understanding the challenges, and you must test the re-packaged .msi far more than you ordinarily would. If you are in one of these situations, then here is what I would suggest trying: Take a look at where Acrobat installs the files that are a part of the SQL Merge Modules. If the files are in the program path, you can just leave them where they are. If they are installed in system folders, then you should consider re-locating and isolating them. If you are using Wise, you can run the Application Isolation tool to help achieve this. Again, once you are done, test test test test test, and do it on a machine that has your full load of applications.
I ran into this SQL merge module problem while repackaging DreamWeaver MX 2004. When first testing the resulting .msi, the SQL Merge Modules caused a bogus message about IE 5.0.xxxx not being installed on the system - even though it was. Once I got around that, I ran into the SQL "strong SA password" issue you described. First I tested DreamWeaver after completely eliminating the files from the package that caused Wise to suggest adding the Merge Modules. Although it tested fine (as far as the functionality that the client needed from Dreamweaver), I decided to take the other route. I let all the original files install, and made sure they were not installed to system directories.
Craig --<>.
This sounds like you performed a capture on Acrobat 6.0.2, and then compiled it into a new .msi. Acrobat is already in .msi format, and the InstallShield Tuner for Acrobat can be used to create a transform file and acheive the customizations that are needed. Best practices say not to re-capture and re-compile an .msi into a new .msi. The best explanation of this can be found here:
http://www.appdeploy.com/FAQ/detail.asp?id=6
There are certain (rare) situations where this rule is broken, but you have to do so understanding the challenges, and you must test the re-packaged .msi far more than you ordinarily would. If you are in one of these situations, then here is what I would suggest trying: Take a look at where Acrobat installs the files that are a part of the SQL Merge Modules. If the files are in the program path, you can just leave them where they are. If they are installed in system folders, then you should consider re-locating and isolating them. If you are using Wise, you can run the Application Isolation tool to help achieve this. Again, once you are done, test test test test test, and do it on a machine that has your full load of applications.
I ran into this SQL merge module problem while repackaging DreamWeaver MX 2004. When first testing the resulting .msi, the SQL Merge Modules caused a bogus message about IE 5.0.xxxx not being installed on the system - even though it was. Once I got around that, I ran into the SQL "strong SA password" issue you described. First I tested DreamWeaver after completely eliminating the files from the package that caused Wise to suggest adding the Merge Modules. Although it tested fine (as far as the functionality that the client needed from Dreamweaver), I decided to take the other route. I let all the original files install, and made sure they were not installed to system directories.
Craig --<>.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
