Offline activation failing as "expired"

Hi,

We have a user who activated their product back in April as an offline activation. All was well until today they reported that their license suddenly is coming up claiming that the license is "expired", despite the fact that their license isn't set to expire until April 2015. I had them check their system time on their server but they claim its correct and in sync. Anything I can check to figure out what's going on or have them do on their end to fix this?

Thanks,Ian

Hey Ian,

First, make sure they're using the latest version of your app, and that the latest version of your app is using the latest version of TurboActivate.

Next, make sure they have the date/time/and timezone settings all correct.

One last question: is this error happening when they're using the activation response file to offline-activate your app, or is this happening when you're calling another function in your app?

Hi Sam,

Sorry for the incredibly late response - that time, the issue turned out to be user error and resolved itself.

That said, we've got the same thing happening with a different user and are wondering what might be going on here. We've resolved the problem for now by redoing the offline activation, but only after confirming with the user that the time is set correctly on the server (and having them resync the time / time zone) and the hardware hadn't changed.

They're also using the latest version of our application, which uses TurboActivate 3.4.6.

The error happens when the app checks to see if the license is valid - it reads as being invalid and comes up with an expired message. The application had been activated successfully with the activation response file a few months before.

The problem seems to be "solved" for now, but they're wondering (as are we) what might have caused this and how we can prevent it from happening in the future, and if it does, if there's any way we might solve it outside of running the offline activation process again.

Thanks,Ian

What does you mean it has "expired". What's the exact error code for which function?

Is the customer using the same offline activation response file on every start of your app? Because they shouldn't.The should just delete that file after it has been used successfully once.

If I had to guess, based on our experience here, they're running into the problem that even if you do an offline activation, the TA library STILL wants to periodically check in with the server.

If you go beyond GENUINE_OPTIONS::nGraceDaysOnInetErr days of not being able to check in and make sure that the license hasn't been revoked, IsGenuineEx will return a value other than TA_E_INET or TA_E_INET_DELAYED.

In our application, we check whether an online activation or an offline one was performed and set nGraceDaysOnInetErr to different values. (the recommended 14 days for an online activation and 90 days for an offline) We have GENUINE_OPTIONS::nDaysBetweenChecks set to 0.

tl;dr: Even with an offline activation, it still wants to periodically check in to make sure that the license is still valid for this machine. And if the user refuses to allow the machine to access the internet, even with a proxy, you end up having to periodically redo offline activation.

We have GENUINE_OPTIONS::nDaysBetweenChecks set to 0.

Don't do that. That will re-verify with the servers every time an instance of your app is launched. So, if they launch your app 20 times in a day it will reverify with the servres 20 times. That's complete overkill.

And if the user refuses to allow the machine to access the internet, even with a proxy, you end up having to periodically redo offline activation.

No, that's not correct.

IsGenuineEx() will recheck with the servers (or try to) every nDaysBetweenChecks. Whether you use offline or online activation, it doesn't matter. If an offline activation successfully re-verifies with the servers using IsGenuineEx(), then that offline activation is converted to an online activation (because it has access to the servers).

Wyatt wrote:> Don't do that. That will re-verify with the servers every time an instance of your> app is launched. So, if they launch your app 20 times in a day it will reverify> with the servres 20 times. That's complete overkill.

That's fair. This setting is probably left over from when the person who wrote that part of our code was doing development and testing to ensure that deactivations were being properly handled.

Wyatt wrote:> If an offline activation successfully re-verifies with the servers using IsGenuineEx(),> then that offline activation is converted to an online activation (because it has> access to the servers).

Well, THAT's braindead behavior! Where is that documented?

So, if I do an offline activation for a customer because the machine cannot be relied upon to have an internet connection, the very first time my application is run where they happen to have an internet connection, it gets converted to an online activation. And if the machine goes back offline for more than nGraceDaysOnInetErr days, you get exactly the behavior that we're both describing.

Where is that documented?

In TurboActivate.h above the TA_SKIP_OFFLINE flag:

/* If the user activated using offline activation   (TA_ActivateRequestToFile(), TA_ActivateFromFile() ), then with this   flag TA_IsGenuineEx() will still try to validate with the LimeLM   servers, however instead of returning TA_E_INET (when within the   grace period) or TA_FAIL (when past the grace period) it will   instead only return TA_OK (if IsActivated()).


   If you still want to get the TA_E_INET error code, without   deactivating after the grace period has expired, then use   this flag in tandem with TA_OFFLINE_SHOW_INET_ERR.


   If the user activated using online activation then this flag   is ignored.*/#define TA_SKIP_OFFLINE ((uint32_t)1)

The fact that an offline activation is "converted" to an online activation is implied in the TurboActivate.h, but never stated explicitly. We'll improve the header so this doesn't confuse anyone else.