Have a good naming convention for your network

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