CheckAndSavePKey without key with TA_SYSTEM fails even if correct

Hello,

I am now debugging our application, 'cause we have problems with an activation process.I found out, that calling to the function `CheckAndSavePKey(0, TA_SYSTEM)` as recommended in the tutorial is returning TA_FAIL, even if the calling process has elevated privileges, and the next calling of CheckAndSavePKey(KEY, TA_SYSTEM) succeed correctly.

Is this intended behavior?

How can we distinguish the problem with not correctly setup TA_SYSTEM without a key from the correct behavior?Or is it possible to ignore this particular TA_FAIL response and handle correctly TA_E_PERMISSION and other codes?

We are now using TA 3.4.6, is this changed in TA 4?

Thanks for your answer.

All of the functions have significantly improved in TA 4.0. There are too many bug fixes to list. Get it, it's our best version yet. https://wyday.com/limelm/api/ta-changes/

Regarding returning TA_FAIL instead of TA_OK, in the next version we've updated the documentation to explain this better:

/* Checks and saves the product key.

Note: If you pass in the TA_SYSTEM flag and you don't have "admin" or "elevated" permission then the call will fail.

If you call this function once in the past with the flag TA_SYSTEM and the calling process was an admin process then subsequent calls with the TA_SYSTEM flag will succeed even if the calling process is *not* admin/elevated.

If you want to take advantage of this behavior from an admin process (e.g. an installer) but the user hasn't entered a product key then you can call this function with a null string:

TA_CheckAndSavePKey(yourHandle, 0, TA_SYSTEM);

This will set everything up so that subsequent calls with the TA_SYSTEM flag will succeed even if from non-admin processes.

Note: Calling TA_CheckAndSavePKey(yourHandle, 0, TA_SYSTEM) will return TA_FAIL if the system files were correctly setup. It will return TA_E_PERMISSION if the system files were not setup due to lack of permissions. The reason it returns TA_FAIL instead of TA_OK is because passing in a "NULL" product key is not valid.

Returns: TA_OK on success. Handle all other return codes as failures.

Possible return codes: TA_OK, TA_FAIL, TA_E_PERMISSION, TA_E_INVALID_FLAGS TA_E_ALREADY_ACTIVATED*/TURBOACTIVATE_API HRESULT TA_CC TA_CheckAndSavePKey(uint32_t handle, STRCTYPE productKey, uint32_t flags);

I'm trying to verifying that this is working for my product, but I can't it working as described.

If I run my program and call CheckAndSavePKey with TA_SYSTEM, it succeeds even when running without Administrator privileges. Is that because I had previously run it successfully? If so, how can I uninstall TA so that it will subsequently return TA_FAIL as described?

>> "Is that because I had previously run it successfully?"

Yes.

>> "If so, how can I uninstall TA so that it will subsequently return TA_FAIL as described?"

Create a VM instance, create a snapshot of that instance and that will be your "base clean machine". Then you can run all the tests you want.

We would like something similar (in terms of CheckAndSavePKey and admin vs. non-admin invocations) for UseTrial(). Currently, if we perform a CheckAndSavePKey(0) as admin we can perform CheckAndSavePkey(<real product key>) and Activate() from a non-admin invocation at a later time. We'd like to be able to do the same with UseTrial() (in order to prevent users from having to run as admin just to start a trial). Is this possible?

>>>Create a VM instance, create a snapshot of that instance and that will be your "base clean machine". Then you can run all the tests you want.>>>

I tried that. I built a simple program that makes 2 calls to the TurboActivate DLL:handle = TA_GetHandle(my_product_GUID);thenret = TA_CheckAndSavePKey(handle, My_product_key, TA_SYSTEM);

Then I copied the program with the DLL and the TurboActivate.dat file to a new VM with Windows 8.1 newly installed, but when I ran the program - from a non-admin account - I got the value 0 (TA_OK) returned. Where am I going wrong?

I want it to fail so that I can check that my installer does the first admin level call correctly.

On Windows, 99% of the time the TA_SYSTEM call will work even from non-admin (due to the way Windows is designed, where the files are stored, etc.).

On Mac, Linux, and other unix variants, TA_SYSTEM will only work the first time from an admin or "elevated" user.

>> On Windows, 99% of the time the TA_SYSTEM call will work

Doh! - I've just spent time testing this out on many different physical and virtual machines trying to remember if I had ever used TurboActivate previously on them and not seeing the TA_FAIL result.

Perhaps you could update the documentation, the following implies it will always fail, first time.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>Note: If you pass in the TA_SYSTEM flag and you don't have "admin" or "elevated"permission then the call will fail.>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

As our product is Windows only I might as well just change the CheckAndSavePKey call to always use the TA_USER flag, there's no reason not to, is there?