No, this article isn’t about the famous ELO song! It’s about the magic number, a hardware fingerprint that uniquely identifies a PC or a VM and that has been used for years in Objectif Lune product licenses. This article explains what the magic number is and how to plan for potential software deactivation if the magic number changes.

What’s in a number – part 1

The magic number is a hash of several hardware and OS-based values. For obvious reasons, we don’t want to divulge all the ingredients that go into the magic number recipe, but we can summarize it as follows:

Component	Details
CPUs and Cores	Speed, stepping rate, type etc.
BIOS	Various entries related to the BIOS
Operating System constants	Values that only change when re-installing Windows

The important thing to remember from the above table is what it does not contain: network adapters, graphics card, RAM, hard drives, etc. In other words, peripherals – which are likely to change over time – are not taken into account, which leaves users free to upgrade their system without risking deactivation of OL products.

Granted, you may want to upgrade your CPU at some point, in which case it’s likely that the magic number will change… but then again, it’s likely you’ll have to reactivate Windows as well!

We’ve been asked before why we don’t simply use a network card’s MAC address (which is deemed globally unique) as our magic number, instead of looking at all kinds of different values. The reason is that network cards can be swapped, they can completely disappear (when undocking a laptop, for instance), there can be tons of them (VPNs and VMs all create virtual adapters) and the order in which they are listed may change on every boot up sequence, etc.

And besides, our proprietary method of computing a magic number in order to uniquely identify a PC worked fine for many years, so there was no need to change it.

And then virtualization happened…

What’s in a number – part 2

With the rise of virtual environments, the actual hardware on which virtual machines are running is somewhat hidden from the VM itself. In other words, the VM only sees what the virtual environment allows it to see. In addition to that, a VM can be moved from one physical server to another in the blink of an eye, either manually or automatically.

This obviously throws off the magic number scheme: one minute the software thinks it’s running on a specific set of hardware, and the next it’s running on a server with completely different features.

So the licensing scheme was modified to allow for multiple magic numbers to be included in a single license file. This allows a VM to be moved to any known physical server without the software getting deactivated because the license file contains an entry for each server’s magic number.

This modified licensing scheme worked well, was backward compatible and allowed users to run the software on popular environments like VMWare. Note that VMWare’s vMotion allows for VMs to automatically be moved to a different server, with each server having different hardware settings. In that environment, it is strongly recommended that the Enhanced vMotion Compatibility setting be enabled in the vCenter host as it instructs the system to report various values consistently across physical servers, thereby eliminating discrepancies in magic numbers.

So with that change, OL products could run on physical machines as well as virtual machines, and those VMs could be moved around from server to server and everything would still work as expected.

And then the Cloud happened…

What’s in a number – part 3

The next evolutionary step in virtualization platforms was the move to Cloud environments. VMs are no longer being hosted locally on an organization’s internal network. Instead, VMs are hosted on Azure, AWS, Google Cloud and any number of other cloud providers.

The problem with the Cloud – from a software licensing point of view, that is – is that you can no longer associate a VM with a specific physical server, or even with a known cluster of servers. In many, if not most instances, you don’t even know where your VM currently is. 

The licensing scheme therefore had to adapt once again to the changing environment to handle Cloud implementations. Fortunately, most Cloud providers have methods that allow software to uniquely identify the VM on which it is running. Unfortunately, that method changes from one Cloud provider to the next and is rarely documented adequately. And in some cases there are even restrictions on how often a software is allowed to poll for unique VM information. But with OL Connect 2020.2 and OL Connect 2021.1, the licensing scheme included a number of tweaks that allowed it to be activated properly on Azure and AWS, by far the most popular providers worldwide.

So, now that we can run the software on physical, virtual and cloud environments, we should be all set, right?

Well… have you heard of containers?

The future

Containers are the next wave of infrastructural changes that is already sweeping across the computing industry. You can think of a container as a minimal VM: instead of virtualizing an entire Operating System like a VM does, a container is like a bubble that only virtualizes the OS kernel, which makes it very quick to spin up and allows multiple instances to run simultaneously on a physical server. Containers have been around for a while already, but they are gaining momentum (although they do require major changes to software applications, changes that don’t pertain to licensing, but that’s another discussion). 

Still, Objectif Lune is already working on eventually supporting containers, which is a challenging endeavor – again, from a licensing point of view. But we’ve managed to get over environment hurdles before, so we are confident we can figure this one out as well. And then we’ll be good to go for the foreseeable future.

What was that? Did I hear someone mention microservices? *sigh* … Yes, we know about them too. And the products will adapt to them just like they will for containers…

How to prevent/plan for deactivation

You can prevent software deactivation by making note of the following potential pitfalls, depending on the environment in which OL products is running. And if you can’t prevent it, you can at least plan around it to minimize downtime caused by an application being deactivated.

Physical servers

If you are running OL Connect software on a physical server, the following actions may cause the magic number to change. You should therefore plan to include the reactivation process in your upgrade procedure:

• Upgrading the CPU
• Reinstalling Windows or modifying system-wide information (registered owner and Organization)
• Upgrading the BIOS firmware

VMWare

If you are running vMotion, you should enable the Enhanced vMotion Compatibility feature in vCenter to ensure the hardware is reported consistently across all servers. Once the feature is enabled, the magic number will remain the same, regardless of the server on which a VM is currently hosted.

If you cannot enable that feature, or if you’re not running vMotion, then you should – whenever possible – install the trial version of OL Connect on a VM and move it to each physical server on which the VM may be hosted, recording the magic number for every machine. Providing that information to our Activation Department will allow them to include all the magic numbers inside a single license file.

Remember that the activation relies on hardware values, so even after a successful activation of the software on a VM, moving that VM to another server will cause issues if the license doesn’t find the appropriate magic number in the license file.

Azure & AWS

For Azure and AWS environments, you don’t have to do anything special: the software will recognize the platform and use environment-specific values to compute the magic number, regardless of the physical server on which the VM is hosted at any given time.

Note that with older versions of OL Connect, AWS EC2 M5 environments were not supported, even though M4 worked as expected. This was fixed with the 2020.2 release.

How to reactivate the software

Sometimes, planning is just not possible. A server may decide to die unexpectedly, leaving your organization high and dry. Reinstalling the software or restoring a backup on another machine can be done fairly quickly, but you still need to reactivate the application before you can resume normal operations.

It is very important that your staff in charge of reactivating the software know and understand the procedure. That’s especially critical for reactivations that occur outside of business hours.

The first thing to do is to jot down the magic number for the software on the new machine or VM (from the software’s Help>Software activation menu option). Then, the procedure is pretty straightforward: go to  https://www.objectiflune.com/webactivationmanager, click on the Request an activation link and follow the instructions. You will receive new activation codes within 3 hours of requesting them.

If you’re in need of an urgent reactivation, the web activation manager also gives you the option of obtaining an immediate code that will be valid for 7 days. To do so, you will need to provide your user name and password to access your account, so again, make sure that the persons in charge of reinstalling and reactivating the software have the proper credentials to log on to the account. Once logged on, follow the instructions.

Conclusion

Hopefully, you now understand better what the magic number is and how a change can cause the software to get deactivated. This will allow you to plan your maintenance schedule accordingly and to painlessly reactivate the software in order to keep downtime to an absolute minimum.