Activation problem on VMWare Horizon

Well, the first thing to do is update your version of TurboActivate. There are always a number of bug fixes (both listed, and smaller ones that we don't list).

Next, you need to handle Terminal Services / Remote Desktop Services / Citrix / VMWare Horizon / and the billion other clones of the same software as a particular type of environment. Namely, you need to treat them like they are: not single machines. But rather they're operating systems on top of multiple machines. And where multiple users log into them to use your app from remote machines.

This is a long way of saying that TurboActivate is the wrong job for this problem. Use TurboFloat. That's what it was designed to handle: VMs, Terminal Services type environments, and cases where organizations need a "pool" of licenses to work from.

TurboActivate: is node-locked (a.k.a. hardware-locked) licensing. It locks your software to a specific machine. Copying the license files to another machine won't work (nor should it).

TurboFloat: is floating licensing. The TurboFloat Server runs on a real piece of hardware and is the "anchor" for the licensing. Your app can run on any machine, any session, or an VM, and request leases from the TurboFloat Server.

Does that make sense?

I totally agree and we will definitely add support for float licensing in further versions of our software for virtualized environments. (I imagine its not a problem to deploy TurboActivate and TurboFloat within the same application and use one of the two depending the environment?)

But for the actual situation (I want to understand the systems I'm working with as deep as possible):- It it possible that the successful activation on the server image (with TA_SYSTEM) which gets rolled out to the client images destroys somehow the TA_USER activation on the client image (profile)? (The server image gets repeatedly "merged" to the client images as soon new software is installed / any configuration is changed)- Is it true that the client activation with TA_USER gets saved entirely in the registry within HKEY_CURRENT_USER? <-- This should not be touched by any virtualization environment as its strictly user related. - Somewhere in the forum I read that TA_SYSTEM is higher prioritized than TA_USER. Can an activation with TA_SYSTEM which was once successful but fails now because the hardware changed overrule a TA_USER activation which unchanged hardware?

Your thoughts about that would be highly appreciated. If I could solve the actual issue with a configuration change I would have the time to correctly implement TurboActivate within our software and would not be forced for a fast shot.Kind regards,Felix

(I imagine its not a problem to deploy TurboActivate and TurboFloat within the same application and use one of the two depending the environment?)

Nope, no problem at all.

- It it possible that the successful activation on the server image (with TA_SYSTEM) which gets rolled out to the client images destroys somehow the TA_USER activation on the client image (profile)? (The server image gets repeatedly "merged" to the client images as soon new software is installed / any configuration is changed)

The difference between TA_USER and TA_SYSTEM is where the activation data is stored. That's it. TA_USER isn't activating a single user. It's just storing the activation data on the user profile because they may or may not have access to write to a space that can be accessed from all users on the machine.

- Is it true that the client activation with TA_USER gets saved entirely in the registry within HKEY_CURRENT_USER? <-- This should not be touched by any virtualization environment as its strictly user related.

No, that's not true. Activation data is stored on the disk in files.

- Somewhere in the forum I read that TA_SYSTEM is higher prioritized than TA_USER. Can an activation with TA_SYSTEM which was once successful but fails now because the hardware changed overrule a TA_USER activation which unchanged hardware?

If the TA_SYSTEM files exist (regardless of what's inside them -- corrupt data or not) the TA_SYSTEM files will take priority. In fact, you shouldn't use TA_USER at all if you can avoid it.

But, like I implied in my other post, the problem has nothing to do with where the data is stored, but rather the fact that the underlying hardware is changing. That is the fingerprint of the hardware your app is running on has change from when your app was activated. Hence the solution being using TurboFloat for cases like this.

Ok, slowly I understand whats going on:

1. TA_SYSTEM activation on server image --> will write to c:\ProgrammData\icsxml & c:\ProgrammData\ms-drivers2. Rollout to client image --> These files get written to client image3. Of course client hardware is different and activation will not work on client.4. Client activates with TA_USER --> Will also write to previously mentioned folders. Successfully activated.5. There is a change in the server image --> New client image gets generated, user profile unchanged. Previously mentioned folders get overwritten BECAUSE THEY EXIST IN THE SERVER IMAGE. --> Activation is not anymore correct as the hardware is not the same as within the server image.

Do you agree that if I delete the mentioned folders on the server image and the client hardware does not change the activation should not get lost? Or are there any other files getting touched during the activation?

Kind regards & thanks for your time,Felix

3. Of course client hardware is different and activation will not work on client.

Correct.

4. Client activates with TA_USER --> Will also write to previously mentioned folders. Successfully activated.

Using TA_USER after using TA_SYSTEM is pointless. TA_SYSTEM will be use regardless of a subsequent call to TA_USER.

But this is all beside the point. The problem is not TA_USER vs. TA_SYSTEM. The problem is the customer is cloning an activated piece of software to different machines. So will it work on the new machines? No, of course not -- it would be a flaw in TurboActivate if it did work. Why? Because the machines are different, and the whole point of LimeLM is to give you absolute control over which machines your software is run on.

See: How the competition does licensing wrong

Do you agree that if I delete the mentioned folders on the server image and the client hardware does not change the activation should not get lost? Or are there any other files getting touched during the activation?

Well, the actual solution to this problem is TurboFloat. All the cloned machines will have the location of the TubroFloat Server cloned alongside the operating system, your software, etc., so customers can get up and running with your app immediately, and each instance of your app will just request new leases from the TurboFloat Server.

If you're determined to still use TurboActivate for this particular problem, then you can either keep using it the same way (have customer clone the machines, but they'll have to re-activate every single machine they clone to).

Thats not what I'm talking about.

I dont care if all client machines have to activate the software on their machine for this particular case. But I dont want that they have to re-activate every time their image gets updated from the "master image" (which was once activated with TA_SYSTEM).

My resulting question: What will I have to delete on the "master image" (which was once activated with TA_SYSTEM [obsolete]) so that a merge of this master image to an existing client image with functional TA_USER activation will not destroy the clients activation?

WHERE IS THE ACTIVATION STORED? Which files or registry keys should not be touched to leave the activation valid?

Or are you afraid of this question because you are working with security by obscurity?

Best regards,Felix

Or are you afraid of this question because you are working with security by obscurity?

No, we've answered this question at least half a dozen times on this forum (here's one time), and you yourself had the locations. The short answer: don't depend on implementation details. The location of the activation files have changed in the past and they'll change again in the future.

The actual solution to the problem is 1 of 2 things:

a) Use TurboFloat.

and/or

b) Fix the cloning process so that "system and user-specific configuration files" (like those found in C:\ProgramData\) are not cloned along with the other files.

But deleting the activation files for TA_SYSTEM will sort of fix the problem (unless your app or installers use TA_SYSTEM any time in the future). Also, this presumes that whatever cloning process the end-user is using doesn't also incorrectly clone user-config files.

Yes that was finally the aim, to remove the unnecessary TA_SYSTEM activation on the server image.

It seems like it worked now like that, I will look not into the TurboFloat approach for the future.Thanks!

Felix