FlexNet Publisher Whitepaper

WH

ITE

PA

PE

R

The Unique Machine Number in FlexNet Publisher and FlexNet Operat ions

Table of Contents

Executive Summary ��2

Part I: Introduction to Binding, Activations, and Unique Machine Identifiers ��2Trusted-Storage Binding ��2Activation, Reinstalls, Returns and Repairs ��2First-Time Activation Process ��4Reinstall Process ��4Return Process ��4Repair Process ��4Properties of an Ideal Unique Machine Identifier ��5Real-World Unique Machine Identifiers ��5Difference Between Binding Elements and the Unique Machine Identifier ��5Methods for Securing First-Time Activation ��5

Part II: Development of the Unique Machine Identifier—From the Machine Identifier to Unique Machine Numbers ��6Summary of Use Cases for the Unique Machine Identifiers ��6Machine Identifier ��6Unique Machine Numbers ��6Issues with Unique Machine Number1 in FlexNet Publisher 11�6�1 to FlexNet Publisher 11�10�1 ��7Issues with Unique Machine Number2 in FlexNet Publisher 11�6�1 to 11�10�1 ��7Unavailability of Both Unique Machine NumbersLicense Generator Toolkit Policies for Unique Machine Numbers ��9


2 Flexera Software: FlexNet Publisher White Paper Series

The Unique Machine Number in FlexNet Publisher and FlexNet Operat ions Executive SummaryThis white paper describes the history and use of the unique machine number in FlexNet Publisher® and FlexNet® Operat ions�

The information about unique machine number usage in FlexNet Operat ions applies to the License Generator Toolkit as well� FlexNet Operat ions and License Generator Toolkit are publisher license server alternat ives� License Generator Toolkit provides a library on which to build a custom publisher license server; FlexNet Operat ions offers a complete publisher license server solut ion�

Best pract ices for using unique machine number in FlexNet Publisher on any platform include the following�

• Enable all anchors (the default) • On all Windows systems, always use the latest version

of the FlexNet Publisher Licensing Service • Incorporate appropriate reinstall, return and repair

policies in the back office

Part IIntroduct ion to Binding, Act ivat ions, and Unique Machine Ident ifiers This sect ion provides an overview of the bind, act ivat ion, reinstall, return and repair act ivit ies used to maintain trusted storage and describes the role that the unique machine ident ifier has in performing these act ivit ies.

Trusted-Storage BindingBinding is a technology in trusted-storage-based licensing designed to fulfill the following requirements:

• If trusted storage is copied to a new machine, it becomes untrusted

• If an exist ing machine with trusted-storage licenses undergoes incremental small hardware upgrades, trusted storage remains trusted after each upgrade

Binding is implemented as a measure of a number of hardware elements, each given a specific weight. A hardware element, known as a host ident ifier, can be the boot disk serial number, Mac address of a suitable Ethernet adapter, CPU ident ifier, BIOS ident ifier, RAM size, hostname, IP address, or another hardware element�

If the total weight of all host ident ifiers changes more than fifty percent all at once, a binding break occurs, causing trusted storage to become untrusted� If the weight of all host ident ifiers changes less than fifty percent all at once, the binding measurement stored in trusted storage is reset to reflect the new hardware environment.

When trusted storage becomes untrusted, end users can no longer check out its licenses� Usually the only way to reinstate trust is to run a repair on the trusted storage� (Repairs are discussed in the next sect ion, Activat ion, Reinstalls, Returns, and Repairs.)

Note: Consider the following addit ional information about binding:

• Pre-12.8 FlexNet Operat ions versions do not support the ability to customize the binding elements used in a binding configurat ion.

• FlexNet Operat ions 12.8 offers a virtualizat ion-aware binding option, described in part II: Relat ionship Between Unique Ident ifier for Virtual Machine and Virtual Machine Ident ifier

Activat ion, Reinstalls, Returns and RepairsThis sect ion steps through the basic processes used to act ivate, reinstall, return, and repair license rights in trusted storage� To understand these act ivit ies, be familiar with the following terms:


3Flexera Software: FlexNet Publisher White Paper Series

Term Definit ionUnique machine ident ifier The unique ident ifier for the machine from which an act ivat ion request originates

(also called the activat ion client). Two types of UMIs exist: the machine ident ifier and the unique machine number�

Fulfilment record The license rights loaded in the customer’s trusted storage as a result of an act ivat ion�

Fulfillment ID An instance of a customer’s RightsID. That is, the Fulfillment ID uniquely ident ifies a fulfillment record in the customer’s trusted storage. (The Fulfillment ID is allocated to one machine only.)

Publisher license server The publisher’s act ivat ion server, which, in response to a request from an act ivat ion client, act ivates, reinstalls, returns or repairs license rights in trusted storage on the client�

Activat ion client The customer machine that sends a request to the publisher license server to have license rights act ivated, reinstalled, returned or repaired in its trusted storage� This machine can be an enterprise license server or a FlexNet client (the machine running a FlexEnabled applicat ion).

Activat ion ut ility The FlexNet Publisher program on the act ivat ion client that generates requests and processes responses from the publisher license server�

Ent it lement ID In general, an identifier pertaining to a customer’s licence rights, but the meaning of this ID differs depending on whether you are in FlexNet Operations or FlexNet Publisher� In FlexNet Operations, the Entit lement ID is much like an invoice ID, referring to the entire bundle of license rights purchased by a single customer� This “invoice” is made up of individual activation entries, each identified by an Activation ID that the customer can then request to activate on their machine as needed�

In FlexNet Publisher, the Ent it lement ID value is the same as FlexNet Operat ion’s Activat ion ID, point ing to the specific act ivat ion entry that the customer wants to install from their FlexNet Operat ion’s ent it lement� The customer obtains this ID from the publisher and includes it in act ivat ion requests�

Note: FlexNet Publisher uses the Ent it lement ID label in its V1 act ivat ions� When FlexNet Publisher introduced V2 act ivat ions, it changed the Ent it lement ID label to RightsID� In either case, both IDs have the same value as FlexNet Operat ion’s Act ivat ion ID�*

Activat ion ID A FlexNet Operat ions ident ifier point ing to a specific act ivat ion entry in a customer’s ent it lement� Each act ivat ion entry contains a set of purchased rights that are related (for example, license rights for the same product or product edit ion or for the same license model). A customer’s ent it lement can contain mult iple act ivat ion entries� This Act ivat ion ID value serves as the Ent it lement ID or RightsID in FlexNet Publisher�

RightsID A FlexNet Publisher ident ifier that is the same as FlexNet Publisher’s Ent it lement ID. (FlexNet Publisher uses the label Entit lement IDs in V1 act ivat ions and RightsIDs in V2 act ivat ions.) FlexNet Publisher obtains this value from the publisher and includes it in the act ivat ion request sent to the publisher license server� Both the RightsID and the Ent it lement ID use the value of the corresponding FNO Activat ion ID in the customer’s ent it lement�



* The following process descript ions assume that an ideal unique machine ident ifier is being used.

First-Time Act ivat ion ProcessA simplified first-t ime act ivat ion between the publisher license server (in this example, FlexNet Operat ions) and the act ivat ion ut ility on the act ivat ion client might run like this:

1� The act ivat ion client generates the act ivat ion request (containing the RightsID and unique machine ident ifier) and sends it to FlexNet Operat ions�

2. FlexNet Operat ions generates a new Fulfillment ID and then records the unique machine ident ifier, associat ing it with the Fulfillment ID. Addit ionally, the Fulfillment ID is associated with the RightsID. (A single RightsID can have mult iple Fulfillment IDs associated with it.)

3� FlexNet Operat ions decrements the license count from customer ent it lement associated with this RightsID�

4� FlexNet Operat ions generates and sends the act ivat ion response (containing the fulfillment record, unique machine ident ifier, and act ivat ion request signature) to the act ivat ion client�

5� The act ivat ion client checks that the unique machine ident ifier in the response matches the unique machine ident ifier obtained from the act ivat ion ut ility. (This step is known as requester verificat ion.)

6. The act ivat ion client loads the fulfillment record into trusted storage�

Reinstall ProcessCertain situat ions require an end user to erase the data on the act ivat ion-client machine, result ing in the loss of trusted storage�1 Under such a circumstance, the customer should be able to re-instate their license rights on this same machine without decrementing the license ent it lement again� In this use case, the customer needs to reinstall the license, a process that uses the unique machine ident ifier:

1� The act ivat ion client generates the act ivat ion request (containing the RightsID and unique machine ident ifier) and sends it to the publisher license server (in this example, publisher license server).

2. Publisher license server looks up all Fulfillment IDs associated with the RightsID, and then determines which Fulfillment IDs, if any, match the unique machine ident ifier sent in the request.

3� FlexNet Operat ions does not decrement license count from end-user’s ent it lement�

4� FlexNet Operat ions generates and sends the reinstallat ion response (containing the fulfillment records, unique machine ident ifier, and act ivat ion request signature) to the act ivat ion client.

5. The act ivat ion client loads the fulfillment record into trusted storage, as it had done previously�

Return ProcessFor license management purposes, FlexNet Publisher can request to return one or more fulfillment records. FlexNet Operat ions would process this request as follows:

1. The act ivat ion client generates the return request (that includes the unique machine ident ifier, RightsID, and Fulfillment IDs of records to be returned) and sends it to FlexNet Operat ions�

2� FlexNet Operat ions looks up the unique machine ident ifier in its stored information and determines that it is indeed associated with this RightsID�

3� In the end-user’s ent it lement, FlexNet Operat ions increments the license count with the returned license�

4� FlexNet Operat ions generates and sends the response (containing the unique machine ident ifier and fulfillment IDs of records to remove) to the act ivat ion client.

5� The act ivat ion client processes the response to remove the license rights�

Repair ProcessA parallel use case to reinstallat ion is a repair� For various reasons, trusted storage can become untrusted (see the FlexNet Publisher: Best Pract ices for Recovering Trusted Storage white paper for more information). When this happens, FlexNet Publisher can issue a repair request� If the publisher license server (in this example, FlexNet Operat ions) grants the repair, trusted storage becomes trusted again� The following examples describe two ways in which trusted storage can become untrusted:

Case A: The trusted-storage file is copied to a new machine in an attempt to duplicate licenses� Such a security breach results in a binding break�Case B: The original licensed machine has a significant hardware upgrade, causing a binding break in trusted storage�

Both cases involve a binding break� However, the publisher would grant the repair request in Case B only, since the request ing machine is the original machine on which trusted storage was established�

In Case A, a new machine (now act ing as the act ivat ion client) is making the repair request. FlexNet Operat ions would process this request as follows:

1� The act ivat ion client generates the repair request (containing fulfillment IDs of records to be repaired) and sends it to FlexNet Operat ions�

2� FlexNet Operat ions determines that no unique machine ident ifier is associated with the fulfillment IDs.

3� FlexNet Operat ions denies the repair request and sends this response to the act ivat ion client�

1This is often the case when a laptop is returned by a employee who is leaving–IT reimages the laptop.



Propert ies of an Ideal Unique Machine IdentifierThe previous sect ion demonstrated that the unique machine ident ifier is instrumental in init ial act ivat ion, reinstall, and repair use cases. The unique machine ident ifier is recorded during init ial act ivat ion on a machine and then used to verify the machine for a reinstall or repair� Ideally, a unique machine ident ifier should have the following propert ies:

• Global uniqueness, and therefore uniquely ident ifies the host machine

• Consistent availability on all nat ive plat forms supported by FlexNet Publisher. In other words, the ident ifier is always retrievable from the subsystem of any FlexNet Publisher-supported native plat form; the retrieval process never returns a null value�

• Consistent availability on virtualized platforms supported by FlexNet Publisher

• No elevated, administrat ive or root-privilege requirement to extract it

• Encrypted format to protect the privacy of the activat ion-client machine

• Immutability*, the degree of which is determined by the unique machine ident ifier’s ability to remain unchanged under these condit ions:

1� Across consecut ive calls within a single act ivat ion process

2� After restart ing the act ivat ion process 3� After a reboot of the system 4. After configurat ion changes on the system 5� After the system has been re-imaged 6� After the operat ing system has been upgraded 7. After significant hardware upgrades in the system 8. After a FlexNet Publisher upgrade on the system* This document later refers to Type x Immutability, where x

is one of the eight types of immutability defined above.

Real-World Unique Machine IdentifiersIn pract ice, unique machine ident ifiers are not ideal. For example, some unique machine ident ifiers might have high uniqueness but low availability across an ecosystem of machines. Other unique machine ident ifiers might be unique and available, but do not have many of the immutability types defined in the previous sect ion.

In order to deal with varying levels of uniqueness or availability, one can generate mult iple unique machine ident ifiers with complementary propert ies. For example, one unique machine ident ifier is likely to be unique, while another has high-availability across mult iple different machines�

One can also define a set of heurist ics when retrieving unique machine ident ifiers, such as the following:

• A null unique machine ident ifier is better than non-unique one�

• A null unique machine ident ifier is better than one with a high mutability� One can set a minimal immutability heurist ic, such as requiring that a unique machine ident ifier have at least Types 1, 2, and 3 Immutability (see the previous sect ion) in order to be usable.

• For any machine, at least one unique machine ident ifier should have a non-null value�

Difference Between Binding Elements and the Unique Machine IdentifierThough interrelated, binding elements and the unique machine ident ifier differ in primary purpose: • Binding is a process on the act ivat ion-client machine

that locks trusted storage to the hardware fingerprint of a machine to prevent the copying of its trusted storage to another machine

• The unique machine ident ifier is used by the publisher license server to verify that the machine request ing a reinstall, repair or return request is the same one on which the licenses were originally act ivated

Methods for Securing First-Time Act ivat ionAt the t ime an act ivat ion request is issued, vulnerability exists to process the response on addit ional machines, thus granting the fulfillment record to unauthorized locations.

The following two methods serve as solut ions for deterring this exploitat ion�

Method 1: Binding Before Act ivat ionBefore the request for license rights is granted, require that trusted storage be created and bound to the request ing machine (see previous sect ion). Then, when the request for act ivat ion is generated and sent to the publisher license server, a copy of the request is also saved in the newly bound trusted storage� The response from the publisher license server includes the sequence number and signature of the original request, which, in turn, is compared to the outstanding request stored in trusted storage� Any attempt to copy trusted storage to a second machine by processing the response on that machine results in a binding break, thus prevent ing the response from being processed�

Method 2: Requester Verificat ionIn this case, the unique machine ident ifier is sent in the request, which is also stored in the (unbound) trusted storage on the request ing machine� The response from the publisher license server now includes the sequence number and signature of the original request, as well as the unique machine ident ifier. As a result, the act ivat ion ut ility must verify not only that the sequence number and signature in the response matches that of the request, but also that the unique machine ident ifier of the host matches the one in the response�



Methods Used in V1 and V2 Act ivat ionsFlexNet Publishers first generat ion of act ivat ion, called V1 act ivat ion, uses Method 1� The second generat ion of activat ion, introduced in FlexNet Publisher 11.8.0 and called V2 act ivat ion, uses Method 2 and involves the use of the composite transact ion�

FlexNet Publisher 11�10�1 incorporates both methods in its V2 act ivat ion transact ions� That is, it introduces a default trusted configurat ion, which allows binding when the first-t ime request is saved to trusted storage�

Part IIDevelopment of the Unique Machine Identifier—From the Machine Identifier to Unique Machine Numbers The previous sect ions introduced use cases for unique machine ident ifiers—how these ident ifiers are needed to provide requester verificat ion for various act ivat ion act ivit ies and how they differ from the ident ifiers used in trusted-storage binding� Two types of unique machine ident ifiers are available—the machine ident ifier, introduced first, and the unique machine number, introduced later in response to the machine ident ifier’s immutability issues. The following sect ions describe these two types of unique machine ident ifiers.

Summary of Use Cases for the Unique Machine IdentifiersIn summary, the unique machine ident ifier provides requester verificat ion for the following use case types:

• Type 1–Reinstall • Type 2–Repair • Type 3–Return • Type 4–Secure first-t ime act ivat ion via requester

verificat ion

The machine ident ifier was FlexNet Publisher’s first attempt at providing a unique machine ident ifier for these use cases. Later, FlexNet Publisher introduced the unique machine numbers in response to immutability issues with the machine ident ifier.

Machine Identifier The machine ident ifier is generated from all host ident ifiers specified in a binding configurat ion. Given that the machine ident ifier is based on the binding configurat ion, a trusted sect ion must be in place (that is, the trusted configurat ion processed) in order to generate machine ident ifier. Each trusted sect ion has its own machine ident ifier.

The following describes the machine ident ifier’s reliability as a unique machine ident ifier for the request ing machine:

As the table shows, the machine ident ifier has a low level of immutability� You can raise this level to some degree by removing more volat ile host ident ifiers (such as the IP address and hostname) from the composite. However, the machine ident ifier remains a poor choice for immutability and is therefore not suitable for reinstall, return, or repair use cases�

The following are addit ional considerat ions about the machine ident ifier:

• In FlexNet Publisher 11.8.0 through 11.10.0, requests for first-t ime V2 act ivat ions do not contain the machine ident ifier.

• As a result of the previous point, FlexNet Operat ions versions 12�7 and later do not use the machine ident ifier as a unique machine ident ifier.

• FlexNet Publisher 11.10.1 provides an optional feature (default trusted configurat ion), which results in a machine ident ifier being provided in first-t ime V2 activat ion requests�

Unique Machine Numbers In response to concerns about the immutability of the machine ident ifier, FlexNet Publisher 11.3 introduced the unique machine ident ifier.

Descript ion of Unique Machine Number1 and Unique Machine Number2The following table below describes the source of unique machine number1 and unique machine number2 on the various plat forms for FlexNet Publisher versions 11�6�1 to 11�10�1� For these versions, FlexNet Publisher generates two unique machine numbers to increase the probability that at least one is always retrieved on a given supported platform�

2In this case, machine ident ifier is a composite of virtualised host ident ifiers

Unique Machine Ident ifier Property

Machine Ident ifier on Native Plat forms

Machine Ident ifier on Virtualized Plat forms

Uniqueness High probability of uniqueness

Medium probability of uniqueness2

Never Null High confidence level in having a non-null value

High confidence level in having a non-null value, even on unsupported virtualized environments

Fulfillment ID Yes Yes

Publisher License Server

Types 1, 2, and usually 3

Types 1, 2, and usually 3



Issues with Unique Machine Number1 in FlexNet Publisher 11.6.1 to FlexNet Publisher 11.10.1The following are limitat ions in retrieving unique machine number1:

• Unique machine number1 requires elevated privileges on Windows, Mac, and Linux machines

• On Windows and Linux, a few instances exist where hard-disk manufacturers provide models of hard disks with serial numbers that have a low degree of uniqueness. In addit ion, a virtualized boot disk is likely to have a serial number with a low degree of uniqueness, or have no serial number at all� No serial number results in a null unique machine number1�

• On Windows RAID devices, obtaining the boot-disk serial number might require dist inct device drivers or methods that FlexNet Publisher does not support� Consequent ly, FlexNet Publisher might be unable to derive a unique machine number1 from a RAID (Redundant Array of Inexpensive Disks) device even if a valid serial number is available�

• On Linux, only IDE devices are queried for serial numbers� Consequent ly, unique machine number1 is often null on Linux systems�

Issues with Unique Machine Number2 in FlexNet Publisher 11.6.1 to 11.10.1New versions of Linux allow names other than eth(x) for Internet Ethernet devices. (For example, these versions might use em(x).) FlexNet Publisher does not yet support querying interfaces for the new names; this can result in an inability to retrieve unique machine number2 on some newer systems�

Unavailability of Both Unique Machine NumbersOn certain unsupported platforms, FlexNet Publisher might retrieve neither unique machine number1 nor unique machine number2� When a request contains all null values for the unique machine numbers, FlexNet Operat ions treats the request as having an error�

Unique Machine Number3 FlexNet Publisher 11�10�0 introduced unique machine number3 as a unique ident ifier for virtual machines. Unique machine number3 is a hash of the virtualized SMBIOS3 value. SMBIOS is commonly virtualized by hypervisor providers such as VMware and Microsoft� In addit ion, virtualizat ion management systems such as VMware’s VMotion ensure that all virtual machines being managed have a unique SMBIOS value�

Operat ing System Unique Machine Number1 Unique Machine Number2Windows Boot disk serial number� Primary Ethernet Machine address

(from first non-removable, non-virtual Ethernet device)

Mac Mac Unique System ID� On newer systems, this ID is burned into the motherboard; rendering the number unchangeable� For older systems, this information is on disk and requires low-level formatt ing to overwrite it�

Primary Ethernet Machine address

Linux Composite of the serial numbers for all non-removable integrated device electronics devices� This value is available only if the FlexNet Publisher Licensing Service is installed� See Trusted Storage-Based Licensing Programming Reference for installat ion details�


AIX Unique hardware serial number� This value is available on all PCI-based AIX hardware�


HP/UX Unique hardware security key� Primary Ethernet Machine address

Solaris Serial number generated during manufacturing and written to the EEPROM�

This value changes during an operat ing-system reinstallat ion on PC hardware. (In other words, unique machine number1 on Solaris Intel does not have Type 6 Immutability.) However, an operat ing-system reinstallat ion on SPARC hardware has no effect on unique machine number1�


3See http://www.dmtf.org/standards/smbios for further information



Note: Consider the following addit ional information about unique machine number3:

• FlexNet Operat ions support for unique machine number3 starts with version 12.8.

• Unique machine number3 is available on virtualizat ion-aware FlexNet Publisher architectures only�

Relat ionship Between Unique Machine Number3 and Virtual Machine IdentifierOn virtual machines, FlexNet Publisher generates a virtual machine ident ifier for trusted storage binding and includes this in the act ivat ion request� To support the virtual machine ident ifier, FlexNet Operat ions 12.8 introduced a virtualizat ion-aware binding option. If this opt ion is enabled, FlexNet Operat ions specifies a bind-to- virtual machine ident ifier binding configurat ion in the response for any V2 act ivat ion request containing a virtual machine ident ifier.

The virtual machine ident ifier and unique machine number3 have the same value, which is a hash of the virtualized SMBIOS�

Note: Consider the following addit ional information:

• SMBIOS is available also on the native hardware, but is not so widely supported by hardware providers as it is by hypervisor providers� However, the SMBIOS remains a candidate for a unique machine number(x) value for nat ive systems in future FlexNet Publisher versions�

• Unique machine number3 and virtual machine ident ifier are ident ical values in requests generated in FlexNet Publisher 11�10�0� However, they remain as separate designations in the request because they are logically dist inct: unique machine number3 is for machine verificat ion in a reinstall, return or repair request, while the virtual machine ident ifier is the binding element�

Unique Machine Number MutabilityWhen a unique machine number value changes, FlexNet Operat ions can deny reinstall, repair or return requests� Consequent ly, Flexera Software avoids changing the underlying method by which a unique machine number is obtained across FlexNet Publisher releases (Type 8 Immutability). However, in some situat ions, circumstances beyond Flexera Software’s control cause a unique machine number to change� One of these circumstances occurs when the operat ing system of a machine is upgraded (Type 7 Immutability). The upgrade can alter the order in which hardware devices are discovered�

In addit ion, FlexNet Publisher can occasionally make minor updates to the methods of obtaining exist ing UMNs to take advantage of newer technologies or to fix bugs in the unique machine number retrieval process� Such updates

will be made in such a manner as to minimally degrade the Type 8 Immutability of that unique machine number(x) value.

Relat ionship Between the Enterprise License Server and Unique Machine NumbersThe Enterprise License Server, also known as the vendor daemon, is a license server residing in an enterprise� The Enterprise License Server supports V2 act ivat ions between itself and a publisher license server to obtain and manage its licenses� However, the Enterprise License Server supports only V1 act ivat ions between itself and its enterprise clients� Addit ionally, it does not store unique machine number details about the enterprise clients during V1 act ivat ions and therefore cannot support reinstalls on those clients�

Unique Machine Number1 on Solid State Drives A number of Windows machines that feature a solid state drives as the primary drive have been evaluated for use with FlexNet Publisher� Start ing with FlexNet Publisher 11�6�1, unique machine number1 has been successfully retrieved on those solid state drivers systems evaluated�

Unique Machine Number1 on Windows RAID SystemsOccasional issues occur in retrieving unique machine number1 from RAID systems on Windows� Since FlexNet Publisher 11�6�1, reports of these issues have substant ially decreased� In cases where unique machine number1 is not available, FlexNet Operat ions uses the unique machine number2 value�

FlexNet Operations Policies for Unique Machine NumbersThe following describes how FlexNet Operat ions 12�7 or later handles unique machine number information:

• Any request containing all null values for unique machine numbers is rejected�

• All unique machine numbers that are present in a request are recorded and associated with the Fulfillment IDS of any fulfillment record that FlexNet Operations creates�

• FlexNet Operat ions maintains and periodically updates heurist ics defining which unique machine number(x) values must be ident ical to those in the original act ivat ion request in order to grant a reinstall, repair, or return request� These heurist ics can take into account a combination of factors including (but not limited to) the following:

– Historical reliability of a unique machine number(x) – A new unique machine number(x) (such as unique

machine number3) – Whether the platform from which the request

originates is known to be virtualized – The presence of the machine ID in the request

These heurist ics are internal to FlexNet Operat ions, not configurable by publishers, and subject to change across FlexNet Operat ions versions�



• All unique machine numbers that arrive in a request are specified in the <RequesterVerificat ion> sect ion of the response�

• Publishers cannot configure these policies.

License Generator Toolkit Policies for Unique Machine NumbersThose publishers intending to use license generator toolkit must implement their own unique machine number-handling algorithm and back-end database� The following is offered as a best-pract ice recommendation� This recommendation attempts to provide some flexibility in support ing requests across mult iple versions of FlexNet Publisher and license generator toolkit-based-publisher license servers and in allowing machines to update their unique machine numbers� A simpler—but harsher—policy is always to require unique machine numbers in a request to be ident ical to those stored in the database and to treat the request ing machine as a new machine if no match is found�

Database DesignIn a FlexNet Publisher request, the following information (when present) is used to ident ify the machine from which the request originated:

• The various unique machine number(x) values included in the request

• The machine ID(x) values included in the request • The RightsID (or Ent it lement ID in older V1 requests) • The FulfillmentIDs within the <Exist ingFulfillments>

sect ion of V2 requests (that is, exist ing FulfillmentIDs)

This can be encapsulated in the following database design:

This design assumes the following:

• An entry in the E_RIGHTS ent ity is uniquely ident ified by RightsID�

• An entry in the E_FULLFILLMENT ent ity is uniquely ident ified by Fulfillment.

• A RightsID can result in mult iple unique FulfillmentIDs across mult iple machines�

Consider the following in using this database design:

• The important ent ity is E_MACHINE, which is the connector between the unique machine numbers of a machine and the FulfillmentIDs allocated to that machine�

• The design correct ly reflects that a machine can have mult iple unique machine numbers and that each FulfillmentID is allocated to only one machine.

• A machine generates a separate MachineID for each trusted sect ion it creates� Most machines will have one trusted sect ion, but mult iple MachineIDs exist per machine can exist� MachineIDs should be stored in E_UMN.

• A crucial factor in deciding whether to grant a request is being able to ident ify the machine from which the request originated� According to this design, if an exist ing FulfillmentID is included in the request, determining the request ing machine is easy� However, if no exist ing FulfillmentIDs are present in the request (as might be expected in reinstall requests), determining the request ing machine is more difficult. The two cases are dealt with separately in later sect ions�

Performing the Update-Unique Machine Number StepAfter license generator toolkit processes and grants any valid request, it should always perform an update-unique machine number step:

• If exist ing FulfillmentIDs are included in the request, with at least one trusted FulfillmentID, then license generator toolkit should do the following to update the database:

– Ident ify the machine in E_MACHINE associated with the trusted FulfillmentID, and update E_UMN with any new unique machine numbers or new MachineIDs in the request� A new unique machine number is defined as a non-empty unique machine number (x) in the request for which no corresponding entry current ly exists for that machine in E_UMN.

– Ensure E_FULFILLMENT has entries for all trusted FulfillmentIDs in the request.

• If new or repaired FulfillmentIDs are sent in the response, E_FULLFILLMENT and E_UMN entit ies are updated with the new unique machine numbers or MachineIDs sent in the matching request�

The purpose of this step is to ensure that new unique machine number (x) (and MachineID(x)) values are incrementally added to the set of unique ident ifiers associated with a machine�

Requests With Unique Machine Number3Unique Machine Number3 takes precedence over every other unique machine number (x) in a request. If a request contains unique machine number3, a machine with a matching unique machine number3 must exist in order to grant the reinstall, repair or return request� This requirement exists because unique machine number3 is FlexNet Publishers only virtual machine ident ifier.

1 0..N 1..N 1 1 1..NE_RIGHTS E_FULFUILLMENT E_MACHINE E_UMN



If the request is granted, license generator toolkit must update the unique machine number information in the database as an addit ional step in request processing�

Requests Without Unique Machine Number3 But With Exist ing FulfillmentIDsRepair, return or upgrade requests might include exist ing FulfillmentIDs, but contain no unique machine number3. The full algorithm for determining if the request should be granted is defined in the sample grantRequest pseudocode funct ion specified in Using Machine Numbers and Exist ing FulfillmentIDs to Decide Whether to Grant Requests.

The algorithm is forgiving on older clients, but t ightens up on new clients�

If the request is granted, License Generator Toolkit must update the using machine number information in the database (see Performing the Update-Unique Machine Number Step) as an addit ional step in request processing.

Requests Without Unique Machine Number3 and Exist ing FulfillmentIDsA request containing neither unique machine number3 nor exist ing FulfillmentIDs can be either a first-t ime act ivat ion or a reinstall request use case� FlexNet Operat ions dist inguishes between the two request types by requiring the <Reason> element in the request act ivat ion act ion to have a value of 1 (for license servers only) or by a reinstall policy.

In such cases, one can expect the request to contain a RightsID and one or more non-empty unique machine number (x) values.

For reinstall requests, the first step is to generate a list of candidate machines – that is, a list of machines on which any FulfillmentID was ever generated against the RightsID cited in the request. The next step is to call the findMachine pseudocode funct ion (see Using the RightsID and Unique Machine Numbers to Find Matching Machine). If a machine is found, the reinstall is granted�

Using Unique Machine Numbers and Exist ing Fulfillment IDs to Decide Whether to Grant RequestsRepair, return or lifecycle-operat ion requests (such as a product upgrade) are likely to contain details of exist ing FulfillmentIDs. For a given request, license generator toolkit should determine whether the request comes from the same machine on which the original act ivat ion occurred� The following is a sample pseudocode algorithm that license generator toolkit could use to determine whether to grant the request. (A lookup in the E_FID database ent ity determines the machineObj.)

BOOL grantRequest (machineObj m, requestObj request){

if request.UMN(3).exists or m.UMN(3).exists then { if (m.UMN(3) == request.UMN(3)) return TRUE else return FALSE }

// Prefer UMN1 over UMN2 // we always send up UMN1 in requests, even if it’s the empty string // if a UMN1 was empty in the past, don’t require it to be empty in the future // i�e� only check UMN1 if it’s not empty if not(request.UMN(1).empty) and m.UMN(1).exists then { if (m.UMN(1) == request.UMN(1)) then return TRUE else return FALSE }

// Prefer UMN2 over MID // we always send up UMN2 in requests, even if it’s the empty string // if a UMN2 was empty in the past, don’t require it to be empty in the future // i�e� only check UMN2 if it’s not empty if not(request.UMN(2).empty) and m.UMN(2).exists then { if (m.UMN(2) == request.UMN(2)) then return TRUE else return FALSE }

// Finally, check any MID values for_each MID md in m { if (request.mid(md.trustedID) == mid) { return TRUE; } }

return FALSE;

}



Using the RightsID and Unique Machine Number to Find Matching MachineIn the reinstall use case, the request might contain no exist ing FulfillmentIDs, only the RightsID and unique machine numbers. If such a request is received (and license generator toolkit determines it to be a reinstall request), the following sample pseudocode algorithm determines to which machine, if any, the reinstall request can be granted� (Before calling findMachine, the caller first determines a list of candidate machines via a lookup in the E_RIGHTS database ent ity.)

machineObj findMachine(listOfMachines lm, requestObj request){

// UMN3 trumps other UMNs� No UMN3 match means we fail to find a machine if request.UMN(3).exists then { for_each machineObj m in lm { if request.UMN(3) == m.UMN(3) then return m } return nullMachine; }

// if we can’t find a UMN3 match, we’ll look for a UMN1 match, // but only in machines where there is no exist ing UMN3 in E_UMN if not(request.UMN(1).empty) then { for_each machineObj m in lm such_that not(m.UMN(3).exists) { if request.UMN(1) == m.UMN(1) return m } }

// if we can’t find a UMN3 match, or a UMN1 match we’ll look for a UMN2 match, // but only in machines where there is no exist ing UMN3 or UMN1 in E_UMN if not(request.UMN(2).empty) then { for_each machineObj m in lm such_that ( not(m.UMN(3).exists and not(m.UMN(1).exists ) { if request.UMN(2) == m.UMN(2) return m } }

// finally we’ll look for a MID match for_each machineObj m in lm such_that ( not(m.UMN(3).exists and not(m.UMN(1).exists and not(m.UMN(2).exists ) { for_each MID md in m { if (request.mid(md.TrustedID) == md) { return m; } } }

return nullMachine;}

WH

ITE

PA

PE

R

Flexera Software LLC1000 East Woodfield Road, Suite 400Schaumburg, IL 60173 USA

Schaumburg (Global Headquarters):+1 800-809-5659

United Kingdom (Europe, Middle East Headquarters):+44 870-871-1111+44 870-873-6300

Japan (Asia, Pacific Headquarters):+81 3-4360-8291

For more office locat ions visit:www.flexerasoftware.com

Copyright © 2012 Flexera Software LLC. All other brand and product names mentioned herein may be the trademarks and registered trademarks of their respect ive owners. FNP_WP_UMN_Feb12

Documents

FlexNet Publisher Whitepaper