Licensing Issues Resulting from System ID Changes

From support-works
Revision as of 08:53, 10 April 2015 by Rickyf (talk | contribs) (Created page with "{{Template:Basic Cover |title=Licensing Issues Resulting from System ID Changes |type=FAQ |htl=Y }} {{Template:Basic Status |status=Published |version=1.0 |authors=HTL QA |...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search



Status: Published
Version: 1.0
Authors: HTL QA
Applies to: Supportworks ESP / Assetworks

Licensing Issues Resulting from System ID Changes

The licence key for any given Supportworks or Assetworks server is generated from the system ID of the computer on which it is installed. The system ID is a 16-digit string comprising the 12-digit MAC address of the server's primary network adapter (with each pair of digits transposed) and the four digits that make up the CPU flags.

Because of this dependency on the system's hardware (or its virtualisation), licence checking will invariably fail if either of the system ID's components change at any time after the original server installation. Some common ways in which these can change, and the means of resolving the resultant licence-key failure, are described below.

Change of Network Adapter Access Order (MAC Address)

If your Supportworks or Assetworks server has multiple network adapters, and some event causes Windows to change their access order, you may find that your licence key fails. This is because the adapter that was previously at the top of the access order list maintained by Windows may have been demoted to a lower level.

Both Supportworks and Assetworks use the same order of access to network adapters as Windows uses. When enumerating adapters, Supportworks/Assetworks will select, for licence-key purposes, the first one on the Windows-defined order list that is not a virtual (say, VMware) adapter. It is on this adapter's MAC address that the first part of the system ID is based. Therefore, if you believe that the licence-key issue may have been caused by an adapter demotion, all you need to do is check in Windows whether the original adapter is still at the top of the list (ignoring any VMware adapters) and, if not, use the relevant facilities to reinstate it.

You access those facilities via the Network Connections window in Control Panel, where you select Advanced > Advanced Settings. The access order is displayed in the Connections area of the Adapters and Bindings tab. If necessary, you would then use the relevant arrow buttons to move selected adapters up or down.

Change of CPU (Flags)

When running under a virtualised enviroment such as VMware, it is often the case that, on moving the virtual server to a new host machine, the network adapter (and hence the MAC address) and/or the CPU (and hence the flags) change, resulting in licence-key failure. Equally, the licence key will fail when you simply replace the CPU with a new one.

Within VMware, it is possible to set the MAC address as required, but such virtualisation is not supported for the CPU flags.

Before Version 7.4.0 of Supportworks, nothing could be done to overcome the effect of a CPU change other than requesting a new licence key, since the flags were always read directly from the host machine. However, since Version 7.4.0, the flag information is stored in, and read from, a Hornbill-specific key in the Windows registry. Therefore, by editing this registry key, you can set the last four digits of the system ID for any Supportworks server installation. The key concerned is as follows:

HKLM/Software/Hornbill/cflag

If you set the value of this key to be the last four digits of the original system ID, then no matter what underlying CPU you have, the server will still start.

Note that, currently, this only applies to Supportworks, as Assetworks still reads the CPU flags directly from the hardware.