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. It is accessed by selecting Computer ID Types... from the Config menu. Changing the order after the computers window has been populated may cause duplicate entries for some computers so you would then have to remove 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.

By default, physical computers will normally be identified by their ethernet hardware address (MAC address). This can be seen in each computer details window as the "Computer ID" (with the letter "N" as a prefix). You may notice that various flavors of virtual computer have an ID beginning with some other letter as explained below. Note: the Computer window does not show the Computer ID field by default – right click on a column header and choose 'Customize Columns...' to add it.

Details

KeyAccess attempts to get each piece of computer identifying information shown in the dialog above, starting at the top of the left column. The first reliable and unambiguous identifier it gets will be used as the computer ID, prefixed by a letter code which identifies the type.

It is important that a computer is assigned a reliable, unique ID for two reasons:

• If two computers are given the same ID, they will look like a single computer in the KeyConfigure interface, so for example, program usage which is actually occurring on two different computers will get mixed together, and appear to all be happening on a single machine.
• If one computer does not reliably use the same ID, you will get two entries in the Computers window for the same computer. Most likely, they will have the same name, and all the same hardware information, as well as the same list of audited programs. However, besides not letting you see a complete picture of usage on the one computer, this could mean that the single computer is using up two node-lock licenses for a single policy.

The default ordering is designed to provide reliable, unique IDs, and should do so for most sites. Therefore we strongly urge that you do not change anything in this dialog box without first contacting Sassafras Technical support to make sure you have considered all the ramifications. Typically the first match for a physical computer will be the ethernet hardware address (i.e. a MAC Address). Assuming the MAC address is reliable (i.e. its network interface is always present) the default id ordering will produce a computer ID which starts with an “N”, followed by the hex representation of this address.

If you are very sure that all computers at your site have unique computer serial numbers, you might consider moving the Combined Computer Serial Number ID type into the first position – but to avoid orphaning a previous record, such a change should be done before installing KeyAccess (or un-install/re-install KeyAccess after changing the ID ordering). If you have tight control of computer names (guaranteeing uniqueness), Computer Name (or Domain & Computer Name) might have some advantages — assuming the computer name is retained across hardware upgrades, historical usage would remain connected to the same computer record. When virtual computing technologies are in the mix there are various options to consider. Contact Sassafras Technical Support to discuss the implications of making any change from the default.

See also our Short Burst Training Video on this topic.

Specific Types

By default the following id types are tried in order:

1. 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.
2. QND Identifier - computer ID starts with Q. This id will only be seen on sites that also use a specific Japanese language deployment tool.
3. 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.
4. 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).
5. 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.
6. 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.
7. 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.

By default the following are the specified as "Do not try these":

1. 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.
2. 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.
3. 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.
4. 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).
5. 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".
6. 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.
7. 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).
8. Processor Serial Number - computer ID starts with P. This is a legacy id type that should no longer be used.
9. 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.
10. User-specified - the computer ID starts with U, and comes from a value placed in the registry or a plist of the client computer (physical or virtual) that is running KeyAccess.
11. 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. Other ID types are ignored, which is why L and Y for example may seem redundant, but L is exclusive to thin client settings.

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. 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

There is one situation where the default settings may cause a computer to choose one ID initially, and then change to a new ID, never to change back. This will happen if computers change their MAC address. Most likely this would happen on a portable, as a result of using docks, or changing PCMCIA cards. If the MAC address does change, the ethernet address will no longer be considered reliable so a new computer record will be created using another id type lower in the hierarchy (e.g. Combined Computer Serial Number). The old record will remain in place but will no longer be associated with any computer (i.e. it will be "orphaned").

Orphans can sometimes result from changing the ID hierarchy and/or upgrading an older version of the KeyAccess client. If you notice a duplicate record in the computers window, and you are sure that it is the same computer appearing with a different ID, you may want to manually delete which ever entry is older. The deleted record will reappear if in fact there is still a computer corresponding to the record. If you are not sure how to clean up duplicate records, call Technical Support for help.