LA_USER and LA_SYSTEM usage for SetVersionGUID

General
#1

Hello,

In our workflow, on Windows, the executable will sometimes run under user’s account sometimes run as service.
Under service mode, the user account can be “Local System” account.

Neither of cases, the account has admin priviledge. (it is fine to require admin priviledge during installation and activation, but for usual use, our customer will prefer to run without admin priviledge)

In this case, how can I activate product key and works properly on all cases?

Please let me know

#2

Hi,

Depending on whether app is run with admin privileges or not, you can pass the LA_USER or LA_SYSTEM flag at the time of start of your app. And you would need to activate it twice using LA_USER and LA_SYSTEM flags separately. That would store the activation data for both the admin as well as current user. Since machine fingerprint doesn’t change you will use the same key ofcourse.

#3

Hello

Thank you for your answer.
I confirmed that activating twice for LA_USER and LA_SYSTEM works fine.

But, during deactivation, we can deactivate only once, so either of LA_USER or LA_SYSTEM has to rely on server sync to clean up locally stored activation data. (Or, I have to use GenerateOfflineDeactivationRequest() method to forcibly clear activation info stored locally)

So, it is bit tricky to do double-activation… is that possible to support something like this?

  • Activating with LA_SYSTEM will store the data in somewhere where the only admin user can write, but any other users can read.
    (It is a similar idea of usual installers does - installing on Program Files where the only admin user can write, but any other users can at least read, same for LOCAL_MACHINE regKey.)

If you guys could do that, activation info wrote from LA_SYSTEM can be referenced from non-admin users.
(I believe that it is a common use case… using admin user for installation/activation, and using non-admin user for running application)

Hope you guys would consider to support such case…

#4

Hello,

The activation data in this case is dynamic, if admin user writes the data, and (say) value of custom field changes on the server, then server sync will fail locally, to update the custom fields as local user will have read only access only.

But, during deactivation, we can deactivate only once, so either of LA_USER or LA_SYSTEM

We are looking into local deactivation cleanup even if server deactivation has occurred.

#5

Hello, Thank you for your answer

The activation data in this case is dynamic, if admin user writes the data, and (say) value of custom field changes on the server, then server sync will fail locally, to update the custom fields as local user will have read only access only.

Oh I see. I thought changing custom field on client end requires re-activation, but actually server-sync will also update the custom field?

We are looking into local deactivation cleanup even if server deactivation has occurred.

Thank you for taking a look at it. Hopefully Deactivation method will succeeded in such case to clean up local info.

#6

Oh I see. I thought changing custom field on client end requires re-activation, but actually server-sync will also update the custom field?

Yes, server changes in custom field values causes a local update on server sync automatically.

#7

Now that makes sense. Thanks for your answer