We only put in Activation code when we make the 1:a Installation in a virtualdesktop and from that installation we make the SCCM sw distribution pagage for all ouer users and No One have ever asked me of the Activation Code. Of ouer 50 users about 15 is new user that should have needed the activation code if manual install.
If you're cloning a completed install from a VM (or a physical machine for that matter) it works just fine. The key word is "completed."
The EA installer writes its registry stuff into HKU\.DEFAULT (aka HKU\S-1-5-18)
1 and the client then copies it out of there to HKCU\Whoever on first start. Then any settings the user changes get written to HKCU.
If you look at HKU\.DEFAULT\Software\Sparx Systems\EA400\EA\OPTIONS, you'll see it only has a very small number of values compared to what's in HKCU. Things like recent files are only in HKCU, which makes sense, while things like the license file/server are in HKU\.DEFAULT, which also makes sense. You'll find ActivationCode in HKU\.DEFAULT as well (in Settings, not OPTIONS).
But since the license reference and activation code aren't set during install, it appears that the EA client does a bit of writing to HKU\.DEFAULT as well. Hence the need to start EA up once to complete the install.
The white paper recommends distributing HKCU data (though it doesn't specifically mention the activation code), and you can do that but it will only work for the logged-in user. On a shared machine, each user has to import HKCU data separately. (Although since the EA client writes back to HKU\.DEFAULT you might not actually have to, provided you start EA once after doing the registry import -- but I haven't checked that.)
So for a mass deployment you want to make sure HKU\.DEFAULT has got the goods. Best way to do that is to take a clean machine, do an install, start the tool, enter the activation code and shared license details if you use those (maybe the support link and other bits and bobs if you like), then clone it and distribute with your tool of choice.
first of all many thanks and sorry if it's not admin friendly to push the topic :/
No you're alright, Q just meant that you should always be friends with your IT admins, especially when dealing with EA which has a few quirks (proprietary license mechanisms is just one of those things IT hate for no better reason than because it makes their job harder).
as I stated before, when using reg, users have to confirm their ssks server on my side.
Possibly if the users import the registry data before starting EA for the first time, EA ignores what's in HKCU and overwrites it because it checks for the presence some other registry value than the ones you've created, doesn't find it and goes wallop.
When using the .ini, activation key is required
There's nothing in the white paper about the activation code (pretty sure the white paper predates the activation thing, which EA only introduced a few versions ago), so if you've followed that to the letter it's not surprising that users have to activate manually.
The .ini file referred to in this thread is just a registry export, so it doesn't make sens to speak of the .ini file on the one hand and the registry on the other. The .file is just so you don't have to edit the registry manually. Please clarify if I'm not understanding.
If you want to use a registry (.ini) file, make sure it includes EA\Settings\ActivationCode and EA\Settings\ActivationDate.
and I also noticed that if by any way you want to change the key server in the interface (by using register menu) it's not saved when you restart EA, and only way is to modify ini file which I don't want users to make ..
This is interesting, and seems to imply that EA doesn't write those changes back to HKU\.DEFAULT. As I said, the best way to resolve everything is to do a clean install and distribution with a proper tool (eg MS ECM/SCCM), and not to piddle about with registry files. Way too error-prone.
HTH,
/Uffe
1 This is poor design. EA writes to HKU\.DEFAULT, but that's actually not the right place for this data.
HKEY_USERS\.DEFAULT is not "default stuff for all users" but "stuff for the default user" which (poor design on Microsoft's part) is in fact the Local System account, aka S-1-5-18.
HKEY_LOCAL_MACHINE, "default stuff for all users on this machine", is where this data should go.
