Activation of Client Side Products and Registry Basics


Applies To
Product(s):SELECTserver - License Management Tool
Version(s):08.09.00.00 - Present
Environment: N/A
Area: N/A
Subarea: N/A
Original Author:Jonathan Jezorski, Bentley Technical Support Group

Warning:  Making these changes can cause serious, system-wide problems within your environment. Do not make these changes unless you are confident with these steps and understand the impact to your system and other applications running on it.

Overview

If an Administrator installs Bentley client products on a client machine and the client has different permissions than the administrator, the client software may not activate.  If this is the case, the clients user account needs to be granted permissions to write to the Registry of their machine.  The following is an overview of a Registry as well as the permissions needed for the end user for licensing.

Registry Basics

The registry has several sections, often referred to as "hives" (if you want to know why, see http://blogs.msdn.com/oldnewthing/archive/2003/08/08/54618.aspx). There are two primary sections that are of interest: HKEY_CURRENT_USER (abbreviated as HKCU) and HKEY_LOCAL_MACHINE (HKLM). The former is used for user-specific settings, and the latter is used for machine settings.

For licensing, we first try to write to the machine section. The rationale has several parts. First off, if multiple users share the machine we want to minimize the amount of setup. Second, since licensing is used by a lot of different products, we want all products to use the same server name and activation key. Third, server products typically run as various system accounts, which are not users that log in. So when an actual administrator logs into the server, they change the licensing settings in HKLM and have it affect all server products.

However, unprivileged users can't write to HKLM. In this case we fall back to HKCU. We test this by actually trying to write to HKLM and either succeeding or failing. The decision about which section of the registry to use is done once, and early on.

  1. We first look to see if there is any data in HKCU. If so, then we use HKCU.
  2. If not, then we look to see if there is any data in HKLM. If so, we use HKLM.
  3. If there is no data in either, we then try to write to HKLM. If that succeeds, we use HKLM.
  4. Otherwise we use HKCU.

Product Registration data always goes in HKCU since that is per-user information.

Standard Location

All licensing goes in the same registry keys; as mentioned previously, this can be in either HKLM or HKCU, or possibly other places in the more difficult cases mentioned below. However, doing a Send Logs Now from the license management tool will record the data in the licdebug.log.

Under the licensing version key in the registry there are two keys. The Applications key contains the application data, listed by product ID. The LastSent key contains the information where the logs are being kept in Windows Explorer.

In the licensing version key we store the basic licensing information provided by the user, such as the server name, activation key, whether to use SSL, and proxy information. We also store information provided from the server, such as the company name and site id.

Policies

Group Policies are enforced by the IT department. For licensing, they provide a simple way to keep everyone's server name and activation key in sync. For example, you're probably familiar with the group policies that set your screen saver to lock after 30 minutes.

For the purposes of licensing, the keys live in HKLM\Software\Policies and HKCU\Software\Policies, though usually in the latter. We look in HKCU\Software\Policies\Bentley\Licensing\1.1 (and the HKLM equivalent) for specific keys such as the server name, activation key, whether to use SSL, and proxy information. If they are set there, then those values are used regardless of what may appear in the registry.

Windows XP/2000/ME/98

Vista/Windows 7/ Windows Server 2008

Recent Windows Operating Systems have this concept of Registry Virtualization, which is designed to protect the system. If the user is running with User Access Control (UAC) on and the application requests to run at elevated permissions level, it is allowed to write to HKLM. However, in this case it will write to a Virtual Registry (http://msdn2.microsoft.com/en-us/library/aa965884.aspx). Most Bentley products do not run at elevated permissions. However, some products run under AutoCAD, which does not run at the normal permission level. So in this circumstance, previous license clients would write to the Virtual HKLM. Then when the transmit application was spawned, it runs non-elevated, so it couldn't see the data written to the virtual HKLM. All license clients since 8.11 will forcibly write to HKCU if the other option is the virtualized HKLM. Note that this problem did not affect many users because if the License Tool or Activation Wizard was run at installation, it would write to HKCU (since it does not try to run elevated), which would in turn force all licensing to use the HKCU key.

It is also important to note that User Access Control (UAC) does not recognize administrator logins.  Even if you log onto the machine as a domain administrator, UAC will treat the login with the lower level permissions.  By default, UAC will always require you to tell it to run as administrator if you want something done at the administrator permission level.  Although the login may have administrator permissions, UAC always check to verify that you want to perform an administrative task.

64-bit OS

Windows 64-bit Operating Systems also have registry magic going on under the covers in the form of registry redirection (http://support.microsoft.com/kb/896459). In this case, the goal is to allow both 32-bit and 64-bit applications to exist simultaneously and not interfere with each other. To achieve this, when a 32-bit application runs the keys under HKLM\Software are written into HKLM\Software\Wow6432Node. We have also seen the Wow6432Node under HKCU in Windows Server 2008. However, for Bentley licensing, we prefer to have only one location for all the licensing information. So, on all 64-bit OS's we use the flag so that it uses the 32-bit registry view, which means that the data will always be in the 32-bit section of the registry. We would rather that the data always exist in the 64-bit section, but we can't do that for two reasons. First if we try to move the data to the 64-bit section and the operation fails, we have no options. So we have to take the safer approach. And second, we can't create a link from the 32-bit section to the 64-bit section because the links are by name, and 32-bit apps look in the Wow6432Node if you tell them to look at the key name, making it recursive.

Work Around

  1. On an Operating System that utilizes UAC and will have an application that runs as a system service, to have licensing written to the registry hive where it can be read by the application that runs as a service (SELECTserver Gateway, ProjectWise Integration, etc), run the installation package as an administrator (right click on installation package and select “Run as administrator.”

  2. When installing software as an administrator and the users do not have permission to write to the HKLM registry hive, after installation, do not run the product activation wizard as an administrator.  Log off of the machine as the administrator, and log on under a user profile.  Launch the application and complete the Product Activation.

How To Set Permission For End Users

SEE ALSO:

Licensing TechNotes and FAQs

External Links Bentley Technical Support KnowledgeBase

Bentley LEARN Server

Comments or Corrections?

Bentley's Technical Support Group requests that you please confine any comments you have on this Wiki entry to the "Comments" area below. THANK YOU!