Does anyone else struggle with the JUCE Machine ID changing for users on a regular basis or not being “unique enough” for windows.
Is there any chance we could have a better cross platform unique machine identifier implementation? There are multiple better proposals floating around online – and it seems unlikely these machine IDs are actually used in practical applications developed in the field by the JUCE team? it appears these IDs get used in the unlocking tutorials – but I’ve had a ton of trouble using them in the field.
macos: first MAC address found using the i/o registry
windows: value of registry key SOFTWARE\Microsoft\Cryptography\MachineGuid
YMMV, it seems to work for the users that have relied on it. It doesn’t handle cases where you have multiple users/licenses on the same machine, but imho you can solve that on the backend.
yeah, agreed. windows users are upgrading from 10 to 11 and requiring reactivations - whilst not the worst thing in the world, would be nice to not have to deal with such things.
Seems it also happens on major upgrades within Windows 11. We have some users in the Windows “preview” program reporting that. I am crossing fingers, it has to do with the preview versions only.
Nope, this is happening with minor updates within Windows 10 already. We’re experiencing a flood of new machine ID requests every 8-9 months which can be backtracked to users getting their Windows updated (most of them automatically which makes it much more annoying).
I programmed my back end so that users simply login to their account, delete the old activation, then reactivate the plugin. The server handles evrything. So, no support calls or emails at all. Its been working great for several years.
If you have access to how your backend is programmed, this may be an option.
Exactly. I made sure to explain everything so it is clear what steps to take. Before I did that, some people were emailing. After that, nothing! It really has been quite dramatic. And, it has worked well for a long time now.
Especially for initial activation, the website gives very clear instructions. For example, I state clearly that the user must use and confirm a real email address (via that email) in order to ceate the account. Otherwise, they will not be able to activate their plugin!
In fact, I’ve gone so far as to make most tasks completely under the server’s control. I cannot even do most of the user account management manually. The server must do it. I am a very small operation, so that was necessary for self defense. This may or may not work for everyone.
I’m seeing something strange with one Linux user - their machine ID was a duplicate of another user’s. I had assumed this was not possible. I checked to make sure they were not using the same machine.
I have seen this before too on Linux. It happened because several enterprise users had VMs spun up by their sysadmins in a way that duplicated /etc/machine-id. In our case we could adjust our backend not to assume machine ids were unique per user (which is useful anyway, since multiple users could use the same machine).
It gets better if you discard the Locally Administered MAC addresses, i.e. those MAC addresses that are “generated” by macOS. They can (and do) change: for example I noticed that some of them assigned to virtual network interfaces have a different value every time macOS reboots.
I’ve been hit by this as well: you want to stick to Universally Administered addresses, they are (hopefully) globally unique and burned in hardware.
A bit of the MAC address is used to discern between the two. See: