Those of us who are responsible for groups of production
computers, whether client or server class, are familiar with the conundrum of
having to adopt some logical and appropriate naming system for them. Different
companies of different sizes have historically adopted anything from the names
of the seven dwarves to a simple alphanumeric numbering scheme.

In an ideal world, a naming convention should allow you to
ascertain useful information describing the target host or hosts. Integrating a
certain amount of logic into a naming system will allow you to address any
specific subgroup of your managed environment, like querying a database for a
subset of information using the appropriate wildcards. This is especially
useful, for example, in applying policies or distributing software in some
automated manner.

In this article, I will discuss the qualities I feel a good
naming convention should have, examples and pros and cons of the kinds of
information I have historically found useful to include in such a system, some
of the potential technical limitations that exist and will conclude by
providing one possible naming convention scenario. I should also point out
that, for the sake of completeness, some of the points I am about to make
actually contradict each other. An ideal naming convention for your particular
situation will most probably require you to pick and choose certain elements of
this article while ignoring others.

When to consider implementing a naming convention

A structured naming convention will be most useful in a
large, dynamic environment. Large environments are usually more complex and
therefore require its administrators to be more organized. Of course, if you
are managing only a handful of computers, a naming convention may not be
critical, but you may still need to give it some thought.

If the environment you manage is small but highly dynamic or
called upon to grow within the foreseeable future, there may be a case to plan
ahead and establish a system that meets your needs today while providing room
to grow. It’s sometimes hard to predict the future, so if you have any
hesitation, it would be more conservative to adopt something that may seem
overkill at first so that you don’t regret it later. A few hours of thought,
research and planning might save you from having to rename every computer at
your company, and that’s in the best case scenario where you can agree on a
standard before the first computer is even deployed.

Most of us will, at one point in time, question the existing
standard (if there is one) and how well it meets your current needs. You may even
decide to bite the bullet and rename every computer, either all at once or by
attrition (by adopting the new standard “going forward” and live with
two standards until all computers have been migrated to the new convention) in
order to conform to newly adopted standards. The key is determining what makes
up a good naming convention to begin with/

Desirable characteristics

Effective naming conventions I have used in the past usually
have at least some of the following qualities:

Parsability

Parsability refers to the ability to parse the naming
convention for meaning. Basically, your naming convention should be made up of
combinations of acronyms that represent actual information that someone reading
any given computer name might like to be aware of.

Another benefit of “parsability” is that, given a
structured convention, automation and programming can easily be built around it
so that computers can be categorized more easily. An easily “parsable”
computer naming convention would be made up of the following characteristics:

A set number of characters for each informational component

Each possible value for each informational component should already
be identified and documented before the convention is adopted but other values
can also be defined later should new needs arise. For example, if the first two
letters of the naming convention should represent the country where the asset
is located, two letter acronyms for all countries with company offices should
be established.

If new offices are later opened in a new country, a new,
unique two letter acronym can then be added. This characteristic also has the
added bonus of making it easy to target a specific population based on any
informational component. Indeed, since each component is made up of a set
number of characters, the right number of wildcards can be used to ignore any
informational component not required for a given query.

An overall consistent number of characters for all computer names

Consistency is always easier to plan for at any level, so if
all computer names are of the same length, they should programmatically be
easier to deal with. If a consistent number of characters is impossible, then
the variable length component or components should be placed in the right most
positions so that the prefix remains predictable and meaningful, while the
variable length information can be isolated by eliminating all characters
before a certain position.

Informational Component “Permanence”

This characteristic basically means that the informational
components you choose to include in your computer naming convention should
strike a balance between their potential usefulness to stakeholders and the
overhead created by their level of “permanence”. For example, should
you choose to use the computer office location as a part of the name, the
computer would need to be renamed anytime the computer moves to a new office. How
much of a problem that is depends on how dynamic this information tends to be
for your environment. Ideally, a computer’s name shouldn’t have to change over
the course of its production lifetime or at least until it is recycled and
redeployed.

Logic, consistency, and intuition

A good naming convention should also strive to achieve a
certain level of logic so that stakeholders can intuitively deal with computer
names. This can be achieved by attempting to maximize the following qualities
of your naming convention:

Drill down approach

It is preferable to make each component a subset of a
previous one (apart from the first of course, which would set the tone). For
example, if a naming convention were used that was strictly based on
geographical location, it would make sense to use a structure such as Country,
Site, Building, Office, etc. rather than something like Office, Country,
Building, Site.

Consistent Number of characters per piece of information

Also, if at all possible, a naming convention using the same
number of letters for each informational component contained within it would
make it more intuitive to work with. Using the geographical location example
again, you can see how a stakeholder dealing with a name starting with “US”
which he/she correctly assumes refers to location, might intuitively look to
the next two letters as the following piece of information in the chain
relating to the asset’s location.

Reuse of existing information

If there are any existing, widely used systems within your
company that already use acronyms such as the ones needed for your naming convention,
you should look for ways to bank on their existing visibility to build extra
intuitiveness into your system.

Data That Describes the PC, not the employee

Information contained in the naming convention should also
be aimed at describing the computer itself rather than its user. Node names
pertain to the actual computing asset and some of its attributes are already
dynamic enough. Adding data pertaining to the owner would add a separate
dimension that would only increase the risk and frequency of changes to the
asset’s name. The connection to the employee, which represents a separate
entity, should already be documented in the asset tracking system anyway and
that’s where it should be managed.

Minimize the use of non meaningful characters

At one point, it does become necessary to assign a numbering
scheme to any defined prefix if the prefix itself cannot insure that the asset
can be uniquely identified. However necessary, this practice should be
minimized as much as possible to insure that the naming convention is as
intuitive and meaningful as possible. Also, it would be preferable that the
prefix be made of letters (or even acronyms, if space allows), followed by
numerical characters to make it obvious that the meaningful part of the name is
made up strictly of letters, while the numbers have no actual meaning.

Potential naming convention components

Here’s a list of components you can and
should try to include in your naming convention:

  • Operating Environment – Possible
    values for such an attribute include test,
    development
    or production.
    Computers would need to be renamed before moving from one environment to
    another, which shouldn’t be a problem since a computer would rarely “graduate”
    from one environment to the other without being at least renamed, if not
    completely rebuilt.
  • Location – Information could
    also be included regarding the computer’s location. Possible informational
    components could include:
      • Country
      • Site/City
      • Building
      • Office

Country and
site are not very likely to change for a given asset and provide an easy way to
programmatically obtain numbers on the quantity of deployed computers per
country / site. Building and office locations are likely to change relatively
often which would probably create excessive overhead in having to rename the
computer too often.

  • Usage Type – Possible values
    include Office, Lab or Kiosk/Public computers. This
    component would allow targeting of computers based on their intended use
    within the company.
  • Company
    Division / Department –
    Indicates the company division the asset
    is associated with. Whatever your company’s structure, it may be a good
    idea to include something to that effect within the naming convention
    since different divisions/departments have different needs and being able
    to isolate all relevant computers in a single stroke can be very useful.
  • Employee’s Username – This
    component could potentially make it easier to identify the computer’s user
    on the fly. However, it can constitute a major security risk. A DNS scan
    of your corporate network (which, most of the time, can be performed
    without any kind of network authentication) could potentially reveal the
    usernames of everyone in the company, and you know one of them probably has
    a really simple password. With username conventions most often containing
    at least part of the person’s name, high profile accounts can become
    easier to target. Also, not only does this information pertain to the user
    and not the PC, but if your usernames don’t all have the same length, this
    would mean introducing a variable length informational component.
  • Employee Employment Type – Potential
    values include contractor, temporary
    or permanent employment
    types. This component could allow us to target computers based on the
    employment type of the owner. It should be evaluated whether such a
    categorization is required since this is information pertaining to the
    employee, not the computer and should be avoided if possible. This
    component can also bring about the need to change the computer name if the
    employee’s status should change over time.
  • Platform – This component specifies
    the operating system used on the asset, such as Microsoft Windows or Linux.
    This component will only be useful if you support multiple platforms.
    Otherwise, it can be a waste of precious host name characters.
  • HW Portability – This component
    is basically made up of a character or abbreviation with two possible
    values, desktop or laptop, or something similar,
    indicating whether or not the computer is likely to change locations on a
    regular basis. This allows targeting of portable computers as opposed to
    non portable / desktop computers and could help explain why certain
    computers move around so much. For example, if a desktop computer is
    scanned on a network segment that does not correspond to the one recorded
    in the asset’s documented location, this could be proactively addressed.
  • Client / Server – So far, in
    this article, I have mentioned components that are mostly useful for
    workstation class computers. You may want your convention to cover your
    server farm as well, but this may become problematic as the information
    you want provided by the naming convention may vary from one platform to
    another. Server naming conventions will typically make some reference to
    the server’s main task which is usually unnecessary on the client side.

Technical considerations

There a lot of components you can include as part of your
naming convention. That doesn’t mean that you should include them. In some
cases, there may be limitations or technical considerations that will control
your naming convention. Here are some of them:

  • Maximum length of host names (DNS,
    Microsoft, etc.) –
    Computer
    names lengths are traditionally limited to 14 characters, which is where
    certain types of systems usually start having problems dealing with host
    names. It should be noted that this limitation is mostly imposed by older
    technologies and protocols which are no longer widely used, such as
    NetBIOS. How relevant this limitation is to you will depend on whether or
    not you are still expected to support such legacy technologies in your
    particular environment.
  • No Special Characters – Given
    that special characters basically represent some form of punctuation, they
    basically amount to a waste of space for a computer name, especially since
    there are a limited number of characters you can use. Also, some systems
    frown on such a practice and allowing them into your naming convention
    could cause unforeseen issues in the future. The only situation in which
    the use of separator type characters might be useful would be for
    readability purposes where a naming convention uses components of
    different lengths that, combined, don’t come anywhere near making up a
    name that may potentially be too long.

One naming convention scenario

After all of this theoretical discussion, let’s put some of
this information into play. Here is a naming convention that might make sense
for a large company:

DDCCSSUPOXXXX

Division (D) – Country (C) – Site (S) –
Usage Type (U) – Portability (P) – Operating Environment (O) – Numbering Scheme
(XXXX)

I personally like this convention because it provides me
with a lot of information I want to know about a computer on a routine basis.
Also, once the meaning of the different acronyms has been assimilated by
support staff, they can translate the computer name very easily into a
meaningful sentence. One example, using this convention, would be: “Manufacturing
desktop computer located in Boston, U.S.A. used for production office work”
while the actual name of the computer might be something like “MAUSBOODP0001”
or “Research laptop computer located in London, England used for testing
in a lab environment” for a node name like “RDENLDLLT0001”.

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays

Subscribe to the Developer Insider Newsletter

From the hottest programming languages to commentary on the Linux OS, get the developer and open source news and tips you need to know. Delivered Tuesdays and Thursdays