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.
