Hi there!
I’m trying to package a program and include the activation key in the command line. I have successfully deployed the MSI/MST manually by adding the Property TAXPREPACTIVATIONKEY to the Property table via an MST file and setting the value to the activation key. If I run:
from a command prompt, everything installs and works fine. Ideally, I’d like to leave the value of that Property as “none” in the MST and specify it in the command line. I’m building this (and other) packages with the idea that other technicians at my job will take over this software and package newer versions in the future on their own, so I want to simplify it as much as I can. Setting that value in the command line will mean they only have to change the key in the Deploy-Application.ps1 file in the future instead of creating a new MST file, which most of them don’t know how to do. I have tried a half-dozen different commands in PSADT to get this done, but none of them seem to work. The install completes just fine, but the activation key value isn’t working. I get a message that it’s invalid before the program opens. My last attempt (based on a post on this forum) was:
Any Property that is all UPPERCASE can be set from the command line. They are called PUBLIC properties. If the Property contains even one lowercase character, it becomes a private property and must be set via the MST or by modifying the MSI. Sometimes you can set it via an InstallSheild setup.exe.
In your case, the only thing that you might have done wrong is the quotes " around the (activation key).
That doesn’t work either, sorry. In case it matters, the TAXPREPACTIVATIONKEY property was something I found in the “SecureCustomProperties” values list, which is why I added it with the MST file. Since it works when running the MSI manually in a command prompt, I figured there shouldn’t be a problem doing it with PSADT, but maybe there is?
It’s a SecureCustomProperty. The MSI is designed to prevent it from being changed from the command line. so "TAXPREPACTIVATIONKEY=(activation key)" would fail in a CMD console too.
Since it worked at a CMD console, it should work in PSADT.
Maybe PSADT can’t find the MST file.
The PSADT log file would tell you.
In the PSADT log file it looks like it’s executing the MSI silently automatically first: [Installation] :: Executing [C:\Windows\System32\msiexec.exe /i "C:\Users\Steve West\Desktop\Tools\PSADT\PSADT - TaxPrep Corporate\Files\CorporateTaxprep.msi" REBOOT=ReallySuppress /QN /L*v "C:\Windows\Logs\Software\CorporateTaxprep_Install.log"]...
And then lower down, about 20 seconds later it’s executing again, but this time it includes the mst file: [Installation] :: Executing [C:\Windows\System32\msiexec.exe /i "C:\Users\Steve West\Desktop\Tools\PSADT\PSADT - TaxPrep Corporate\Files\CorporateTaxprep.msi" TRANSFORMS="$dirFiles\Custom.mst" TRANSFORMSSECURE=1 REBOOT=ReallySuppress /QN /L*v "C:\Windows\Logs\Software\CorporateTaxprep_Install.log"]...
I’ve tried using both with and without $dirFiles in the MST path.
Then you must have 2 line trying to install the MSI.
BTW: Kudos on using TRANSFORMSSECURE=1
(For those who don’t know: If you use a TRANSFORM without this, when you uninstall the MSI, MSIEXEC.EXE will ask you for the path to the MST file and fail when not provided)
Ok, I have a solution. It isn’t pretty, but it works. Part of the problem here was that the zero-configuration section of the PS1 file was taking over and installing the program before it even tried to use my commands. No idea why, but I think I’ll comment out that section of my baseline PSADT folder so it doesn’t affect me again. I ended up creating a CMD file with the commands that were working for me, and using Start-Process to run it instead. Now I can do the install, have the serial number work, and all anyone else will have to do to change the serial in the future is edit the CMD file instead. Not pretty. Maybe if I went back to zero and tried again without the zero-config section it would work, but I’ve already spent WAY too much time on this package. Onto the next one. Thanks for your help!
The network guy who introduced me to PSADT says that it’s the missing $appName variable that triggers the zero-config install. I never fill in that info because it’s all in SCCM and all our installers are silent. So that info wouldn’t get used normally. Now I’ve gotta go through all our SCCM packages and change the Install-Application.ps1 files to fix this, then update the DPs. And then I get to recreate the 20 InTune packages I’ve already done. Argh. Oh well, lesson learned I guess.