Computer ID Types

This is an extremely important configuration decision that should be made when a KeyServer is first brought online BEFORE any clients are connected.

This dialog lets you configure how KeyServer assigns a unique ID to each Computer record. It is accessed under Settings -> Computer IDs in the Web UI, or by selecting Computer ID Types... from the Config menu in KeyConfigure. Changing the order after the computers list has been populated may cause duplicate entries for some computers. You would then have to retire any older orphaned records, as explained below. Please contact Support for assistance if you are considering or need to change your ID order. We have special tools and procedures to facilitate the conversion of existing records and avoiding problems and merge duplicates.

          

If you install KeyServer on Windows or Mac, the setup wizard that runs will allow you to choose a primary ID type. On Linux there is no setup wizard, and the default will be MAC address. Generally speaking, most customers today opt for Serial as the primary ID. MAC can be transient due to adapters on laptops, and Name is of course volatile. For example, 20 laptops imaged using the same ethernet dongle would tend to show up as a single computer record that all the clients share if using MAC. Conversely, if you rename a machine 5 times it will create 5 records if using Name, each consuming a license seat. Serial therefore becomes the most compelling option for lifecycle management.

Consider the above screenshot of the settings in the Web UI (right image). A session connecting from KeyAccess would follow this flow:

• If the connection is Thin (RDS/TS technology), it will use the name of the authenticated user as the Name of the computer record. Anything not Thin passes on.
• Thin client name is hard locked and would use the name of the connecting computer, but we have overridden this above with the User.
• Non-thin connections now evaluate to see if they are Virtual (thick VDI). If so, use the name of the virtual computer. Physical systems pass on.
• Now that we took care of all virtual items, the remaining physical computers try to use their Serial as primary ID.
• If the primary serial could not be determined, but any secondary serial exists (e.g. motherboard or BIOS), use a combined string of the values found.
• Failing to find any serial, use the UUID of the system so we at least have something largely unique and stable as an ID.
• Failing all the above, use the locked fall back option of a hardware hash.

The ID can be seen in each computer details window in the Categorization pane. The first letter of the ID correspondes to the types as detailed below, and is followed by the actual value of that type. For example, B93847TRGEYF is using Serial for a computer with OEM Serial 93847TRGEYF. Note in the Computer window of KeyConfigure you can show Computer ID as a column by right clicking on the column headers and choosing 'Arrange Columns...' to add it. You can then sort by that to group all IDs of a type.

See also our Tutorial Video on this topic.

Type Details

• Thin Client Name - if KeyAccess is installed on a Thin Client server to support its client sessions, the computer ID for each session is W followed by the name of the client computer that is displaying the session, not the name of the RDS Server where KeyAccess is installed. Note: for the purpose of this discussion, a Thin Client session is not considered a VM ("Virtual Computer"), but simply one of possibly many "remote desktops" served out from an RDS Server. The W identifier will ensure that each session will have a distinct computer record in KeyServer, assuming that the computers (or devices) displaying the sessions are named uniquely.
• QND Identifier - computer ID starts with Q. This id will only be seen on sites that also use a specific Japanese language deployment tool.
• MAC Address - the computer ID is based on the MAC address of the physical or virtual computer that is running KeyAccess – KeyAccess attempts to use an "on board" ethernet address first, not wireless, and when there are multiple MAC addresses, it will continue to use the same address once it has chosen one for the first time. When KeyAccess is on a physical computer, the ID will be the MAC address prefixed with N. If it is installed in a virtual computer (e.g. VMWare, or Parallels), the ID will be the MAC address prefixed with V.
• Combined Computer Serial Number - the computer ID is S plus a value formed from 2 different Serial Numbers found in computer hardware. This is potentially more unique than serial number alone (the next id type choice).
• Computer Serial Number - the computer ID is B followed by the serial number of the computer. On some Windows computers the true Serial Number is ambiguous, so the "Combined..." type above gives better results.
• Computer Name - the computer ID is C followed by the name of the computer. If you have tight control over computer names at your site (guaranteed uniqueness, and infrequent name changes) this can be a very good type to use for computer ID, but we cannot make those assumptions for a default configuration.
• Hardware Digest - the computer ID is H followed by a digest of hardware properties. In practice this should never be used (unless you have disabled all other types), but it exists as a fallback just in case all other basic properties cannot be reliably determined by the client.
• Domain and Computer Name - the computer ID is D followed by the Domain, a forward slash, and then the computer name. This ID type is only implemented on Windows clients. In a multi-domain environment, this id type may guarantee uniqueness, while computer name alone would not.
• Virtual Computer Name - when KeyAccess 7.3 (or newer) is running in a VM, the computer ID is F followed by the virtual computer's Name. KeyAccess running on a physical computer will not use this id type. Putting Virtual Computer Name above (in the hierarchy) any ID type used by physical computers will let you easily distinguish the computer records for virtual machines. Note: creating an F id depends on the ability of KeyAccess 7.3 running within common VM technologies to determine that it is not a physical computer.
• Virtual Host Name - if KeyAccess (7.3 or newer) is running in a VMWare View / Horizons VDI, or KeyAccess (7.6.0.2 or newer) is running in Citrix VDI, the computer ID is G plus the name of the computer running the viewer client. That is, the computer from which the VM is being accessed not the Virtual Computer Name (where KeyAccess is running). This id type is useful when you wish to create a single computer record that will correspond to all VMWare view instances that were viewed on a specific "host" computer. Note: if this "host" computer itself also has the KeyAccess client installed, you will see two records in the Computers window, both with the same computer name – but the id of one of these records will be prefixed with "G" and the other with the relevant ID (like N or C) based on your settings.
• UUID - KeyAccess (7.3 or better) supports the identification of a computer using its UUID with prefix I. This might be more reliable than MAC address (which might change), but not all manufacturers burn in a value (and at sites with older KeyAccess, it is not an option).
• Virtual Client MAC Address - if KeyAccess (7.5 or newer) is running in a VMWare View (Horizons) client, the computer ID is J plus the MAC address of the computer running the viewer client, that is the computer from which the VM is being accessed– not the MAC address (where KeyAccess is running). This id type is useful when you wish to create a single computer record that will correspond to all VMWare view instances that were viewed on a specific "host" computer. Note: if this "host" computer itself has the KeyAccess client installed, you will see two records in the Computers window, both with the same computer name – but the id of one of these records will be prefixed with "J" and the other typically with "N".
• Thin Client User - if KeyAccess is installed on a Thin Client server to support its client sessions, the computer ID for each session is L followed by the name of the logged in user that is displaying the session. This is an alternate to Thin Client Name. It will use the same ID whenever the same user is logging in to display an thin client session, regardless of the name of the computer (i.e. thin client device) that is used for display.
• SCCM Unique ID - if KeyAccess (7.3 or newer) is running on a Mac or Windows computer that is also an SCCM client, this computer ID is M followed by the hex representation of the "Configuration Manager Unique Identifier" (SMSUniqueIdentifier).
• Processor Serial Number - computer ID starts with P. This is a legacy id type that should no longer be used.
• Thin Client User and Server Name - if a user session is for a Thin Client Session, the computer ID is T plus the user name plus the computer name of the RDS server. This should only be used in unusual circumstances since it has the potential to create multiple computer records for the same user.
• User-specified - the computer ID starts with U, and comes from a value placed in the registry (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\KeyAccess\Settings\logon\machine or a plist (sudo defaults write /Library/Preferences/com.sassafras.KeyAccess machine mycustomname) of the client computer (physical or virtual) that is running KeyAccess.
• User Name - will use the user login name starting with Y. Not commonly used.

Note on Thin Clients - For clarity, any technology we recognize as thin client (many users can log in to single virtual system, as opposed to 1:1 virtual machine pool technology), we force the use of W, L, or T identifiers. This is to prevent license abuse in a many:1 technology and allow for distinct use by "computer" in reporting. Other ID types are ignored, which is why L and Y for example may seem redundant, but L is exclusive to thin client settings. You should also ensure a Rule has been set up to handle these ID types if you use them, so that the records do not Audit and are set to Leased. This allows a 4 hour timeout to Dormant after end of Session so as to not "permanently" consume a license.

Note on Virtual Machines - For clarity, virtual computer records are denoted with a Green or Orange icon instead of Blue (physical machines) in the Computers Window of KeyConfigure. Because there are certain ID types exclusive to virtual systems (G, J, F) that will be ignored by physical machines, it's possible to identify virtual and physical machines by entirely different methods. For example use MAC (N or V) normally, but if you want to use Name for virtual systems put F above that so they don't use V.

Orphaned Computer Records

As mentioned above, there are conditions under which a client may abandon an ID and adopt a new one. Generally we try to prevent this, but there are either intentional or accidental situations that can cause this to happen. Some examples include:

• If using Name, renaming the computer will cause a new record, because it has been told this must be the unique identifier. Conversely, two computers with the same name would share a record causing data and inventory confusion.
• If using MAC, changing the dock/dongle used by the client system could cause it to adopt a new ID due to changing interface, or even abandon this ID entirely due to stability concerns and adopt a fallback. Conversely, multiple machines imaged using the same dock would all have the same ID at "birth" and share a record.
• If using Serial, if there is a hardware or OS issue which makes the serial not accessible, the client will need to fall back and create a new record with a secondary ID type.

In any of these cases, the old record will remain in place but will no longer be associated with any computer (i.e. it will be "orphaned").

To help check for and remediate any possible orphans/duplicates, we have a variety of reports. These are the Duplicate reports, which come in Serial, Name, and Mac variations. Using the one that relates to your primary ID is the best choice. Once you identify the duplicates, you can move the old records to a Dormant state to retain data but free up the license seat. It's usually not recommended to delete the records as that can orphan the Audit and Usage data linked to that record and create report gaps. If you need any advice about cleaning up duplicates, contact Sassafras Support for help.