MattHi,We just made a new release of our app, and in doing so moved to a new installer - a standard MSI install, having previously used ClickOnce.We have had reports of problems from some users with an exception calling UseTrial(), to do with permissions - "Insufficient System permission. Either start your process again as an admin / elevated user or call the function again with the TA_USER flag."
It seems a slightly strange one to me, in the sense that the same users didn't get the problem before (same code, although I have added an isgenuine call before the call the usetrial - could this be a problem??). As far as I know, ClickOnce apps don't run as administrator, but I must admit my knowledge is shaky.The user can run the app OK if he starts it as administrator - but this is not a good solution, as most trial users will just give up I'm sure (this guy was a paying customer).
I'm really just looking for any insights as to what to do. If I change to TA_USER, what will that do the existing user base that installed with TA_SYSTEM? I can modify the installer to start the app as administrator, which may or may not always work depending on the rights of the user.
Please advise!
thanks,matt
MattJust a PS to the post above.
In my installer authoring package I have the following options:
Install:
per-user onlyper-user (administrator rights required)per-machine only (fails if user is not administrator)per-machine if administrator, else per-user
I am using the last option.
Do you have any idea how these options might interact with the TA_USER/TA_SYSTEM flags, and what is the safest option for me to use (for both the installer and Lime)?
thanks again,Matt
I'm really just looking for any insights as to what to do. If I change to TA_USER, what will that do the existing user base that installed with TA_SYSTEM?
Anyone that's already used TA_SYSTEM will stay on it even if you use TA_USER later on. So you can use TA_USER without any problem.
Do you have any idea how these options might interact with the TA_USER/TA_SYSTEM flags, and what is the safest option for me to use (for both the installer and Lime)?
It doesn't matter where you install your app, what matters is what "elevation level" the calling process to TurboActivate has. So if your app is running as a limited user then your only real option is to use TA_USER. If you're calling TurboActivate from an "elevated" installer or from an elevated instance of your app, then you can use either TA_USER or TA_SYSTEM.
Does that make sense?
MattIt does make sense Sam - I just find it a bit odd that I have just run into this problem, as we have been using TA_SYSTEM for a while without issues. So you would say the *safest* course of action is to use TA_USER at all times? I can't guarantee that users will have admin rights, so I may try this. What if a user has already tried (and failed) with TA_SYSTEM, and I now change to to TA_USER? I have a user who I advised to use "run as administrator" which he did, with success. If I now change to the user flag, will he be able to run OK having already activated under TA_SYSTEM?
I myself cannot seem to replicate the problem by running as a non-admin user. Could this be because all the test machines have already had trials? Is there any way to create a test environment for this?If I do run with the TA_USER flag, does that mean you could just create a new user to get another trial?
thanks again - sorry for all the questions 🙂
Matt
I just find it a bit odd that I have just run into this problem, as we have been using TA_SYSTEM for a while without issues
On Windows, for a great majority of users, using TA_SYSTEM doesn't require any elevation. But if the admin of the computer has especially script ACL settings on the folders, then some users *must* be elevated on the initial call to TA_SYSTEM.
On all other operating systems (Linux / Mac OS X / Solaris / Android / et.c) using TA_SYSTEM *always* requires admin permission the first time it's called.
So you would say the *safest* course of action is to use TA_USER at all times?
If your installer never runs as an admin, then yes.
What if a user has already tried (and failed) with TA_SYSTEM, and I now change to to TA_USER?
It will succeed with TA_USER.
I have a user who I advised to use "run as administrator" which he did, with success. If I now change to the user flag, will he be able to run OK having already activated under TA_SYSTEM?
Yes.
I myself cannot seem to replicate the problem by running as a non-admin user. Could this be because all the test machines have already had trials? Is there any way to create a test environment for this?
You just have to set really restrictive permissions on certain "shared" public folders. It's very rare that people do this, hence only getting a single customer to mention it.
If I do run with the TA_USER flag, does that mean you could just create a new user to get another trial?
Yes.
MattThanks Sam for your comprehensive answers - I panicked a bit because we had moved to a new installer so I thought maybe this was a consequence and I was going to get a lot of support mails, but only the one so far..
What I think I might do then is try TA_SYSTEM, catch any exception and try again with TA_USER - does sound like a reasonable strategy? I get to keep the trial system wide for the vast majority of users, but also deal with the odd case like this.
Can you confirm that the only call that is likely to give an exception for this reason is UseTrial? or do all TA calls need to be wrapped to catch the case where a user previously activated under TA_SYSTEM?
thanks,Matt
What I think I might do then is try TA_SYSTEM, catch any exception and try again with TA_USER - does sound like a reasonable strategy?
Yeah, that would work.
Can you confirm that the only call that is likely to give an exception for this reason is UseTrial?
UseTrial() and CheckAndSavePKey()
