Software Deployment

Why not go radical and snapshot the entry of the serial number? It can only be being written to a file or (more likely) to a registry entry. You can use a lightweight snapshotter (e.g. Ziff-Davis' In Control) or monitor it "live" with ProcMon. Once you have the file/entry, add it to a transform: never alter a vendor MSI, if at all possible.

You could either install with verbose logging and see which property that is used for the license info or debug the installation and get the property that way.

For the latter please have a look at my comment "Monitor MSI installation actions in real time" at http://juice.altiris.com/article/1358/troubleshooting-wise-packages-with-windows-installer-log-files

Many vendors use PIDKEY for the Serial number. Business Objects is one of them. you can feed the key via public property of PIDKEY=12345-WHATEVER-ETC.

I usually open the MSI with wise and check out the dialogs looking for the one that gets the key and then see what property they're using to pass it into in order to get that setting and anything else that is typically changed during the install.

Yeah check for the PIDKEY property entry in your property table. If you see it you can use that property. Otherwise it is most likely a registry entry or embedded within an ini file or something.

Thank you all for your responses. It really helped me.

Regards,
Nilo

Do one thing............use the Picture taker tool and find whether it is generating either file or registry, then add it to ur package.

Welp, since I'm building this same package I figured this was a good time to firstpost. So first... Hey all! :-)

Well, I used a snapshot process and I can see the items it is modifying but unfortunately for some reason integrating the changes into my main Xcelsius application package doesn't work, nor just applying the raw changes of the before/after activation snapshot. Though there is clearly multiple items relevant to the activation in my snapshot file (registry keys for esellerate, updated esellerate.dll, etc....even a reg key with the product code and an encrypted activation code) it does not seem to satisfy the activation even after several snapshot attempts in different ways. I'm going to contact eSellerate and see if they have a way to satisfy the activation via script, etc. This should not circumvent their security because you would still need the activation code they provide as if you are doing a manual activation.

If nothing else I may kludge together a script or something to do an automated responce to the activation window. I'll keep everyone updated.

After you've run your package, start up ProcMon then the app and see what file/registry entry the app is missing. You may find that it's trying to write something to a file/registry entry to which the account you're using doesn't have appropriate rights or, more usually, you simply missed something! :)

No, I'm afraid it's not that easy. I'm using a local admin account. The package snapshot process does capture changes so I know what registry keys and files are modified, but when you create a package with these changes and apply them the application still doesn't think it's activated. I frankly don't know how they're doing it that it can't be packaged.

Eh? ProcMon isn't a snapshot tool: it's a real-time file and registry monitor. The app can only realistically be reading/writing files and/or registry entries so use ProcMon. If any are missing, it'll highlight them for you.

Of course, it *could* be that the file/registry stuff is there but not in the correct format: that is when you'd use a lightweight snapshotter, so you can see what changes the app made.

Yes I know Sysinternals ProcMon. ;-) In fact that is what I used to discover all the hardware queries this thing is doing which prompted me to call eSellerate. There is no way you can package something if it is bound to certain hardware; if/when the appliction or activation process requeries the hardware it won't match and all the extra reg and file entries in the world won't fix that.

I called eSellerate and there is no "silent" way to activate so the end user doesn't see it. They even agreed it would be a good option to have in the future. Also it is hardware and user dependant which means packaging is out. The only thing I can think if we really wanted to make this silent is to somehow use a script that intercepts the activation window and supplies the responce to activate: VBscript, AutoIt, etc.

ORIGINAL: EnigmaV8
I called eSellerate and there is no "silent" way to activate so the end user doesn't see it. They even agreed it would be a good option to have in the future. Also it is hardware and user dependant which means packaging is out. The only thing I can think if we really wanted to make this silent is to somehow use a script that intercepts the activation window and supplies the responce to activate: VBscript, AutoIt, etc.



The registration details must be written somewhere, file, registry, or somewhere. Otherwise you'd be prompted everytime the app is started. ini file, registry, registration file, must be something.
You just need to figure out where, and then include it in the msi.
Install the app using the original media, use regmon/filemon when you have to register.

GOT IT FIXED!! ...sort of.

I made an AutoIt compiled exe that takes care of the whole activation and closes the resulting Crystal Xcelsius window when it runs. Following is a ZIP with two different scripts. I have included a script (Activate_Xcelsius_Wait.exe) to be used in a startup key, etc. as it simply waits for the Activation window to open instead of opening Xcelsius itself and completing activation. Both scripts will also delete themselves once complete from either Local or CurrentUser Startup folders or start reg keys. Either of these can be included in packages or used in scripted installations as a run-after type deal. If you are not familiar with AutoIt and want this modified slightly for your situation just let me know what you want it to do and I can help.
Now some caveats:
1. The user has to be logged in because these scripts use the GUI windows, which is fine since activation is per-user anyway.
2. These scripts do the auto activation via the Internet so if you need otherwise this will have to be modified.
3. If you want the script to auto-delete itself you MUST keep the word "Activate" in the executable name if using in a Startup folder or you MUST use the name Activate_Xcelsius as the key value name if putting in a startup reg key as these are both hardcoded in the script.

http://mysite.verizon.net/enigma.v8/ActvXcl.zip

ORIGINAL: reds4eva


The registration details must be written somewhere, file, registry, or somewhere. Otherwise you'd be prompted everytime the app is started. ini file, registry, registration file, must be something.
You just need to figure out where, and then include it in the msi.
Install the app using the original media, use regmon/filemon when you have to register.



I'm not sure you guys are understanding me. I know what keys and files it is modifying/adding. The point is these are tied to a unique hardware query. Since this hardware information is not the same (even on exact models) there is no way to package this kind of activation.
The Installation ID (and the resulting Activation code) are generated from and a result of hardware queries. There is no way you can match an installation key and activation code to a separate machine. In theory you could build a package that would only work on the machine used to build it. If I wanted to give eSellerate actual credit I'd say it was by design that this cannot be captured, but I'm assuming there. ;-)

Those of you with ProcMon skills take a look for yourself. You will be surprised at the extensive hardware querying.

Just to follow up I have a slightly customized version I'm using of the Activate_Xcelsius_Wait.exe AutoIt script I posted and I have a completed package that now automatically activates the product on first run--even if the the user logs off or reboots before running Xcelsius. A CMD script in the startup folder is calling the AutoIt compiled script that waits for the first Xcelsius run and then cleans everything up once the activation completed successfully. Real slick!