Network Names For Systems

Apr 14, 2009
by:   Tim Stanley

When you have five machines to keep track of, the naming format for those machines may not be important. When you have 500,000 in twelve countries, identifying and locating a machine or groups of machines becomes impossible if you haven’t planned ahead. Even if you have a simple home network, it doesn’t take long for iPods, routers, file servers, workstations, laptops to add up.

Here are some tips for naming physical device machine names so that they can easily be identified down the road. It may seem a bit obsessive compulsive at first, but there is logic behind the naming guidelines.

Searching Names

Why Names Are Important

The name of a system is only important for a few reasons. The most common is when you need to access a resource on the system and you need to know the DNS name. In secure environments, system logs record the machine where services are open or running, or they record the machines used to access other resources on the network. These become important for auditing requirements certain regulatory compliance laws. The next most common is the name used for system admin purposes when managed from other services.

Group Policies

Microsoft’s Active Directory allows applying group policies to certain machines.  It’s a bit easier if all the same type of machine have a similar pattern.

Regulatory Compliance

Many of the recent laws including PCI DSS Compliance, Sarbanes Oxley, Gramm-Leach-Bliley Act (GLBA), HIPPA, and the Fair Credit Reporting Act require the auditing and logging of access to secure resources. Having a consistent machine naming convention makes it much easier to identify and process the information.

Resources Should Use Logical Names

Good server resources and network shares should be like URls that don’t change. The most common situation I’ve seen over the years is putting installation resources on a server, then over time, the network share is moved or the server changes name and then when workstations need to update, reinstall, the path to the original resource is no longer valid and it’s difficult to configure where to search for the new one.  This is due to the fact that quite a bit of software (including Microsoft’s) embeds in the registry the original installation path.

The problem can be avoided by creating a DNS name that is separate from the physical name of the server.  For example, if the copies of all CD software is on a server, create a CDSW.domain.com DNS entry, then create a share on the server and you can move it to another server easily without having to re-configure the workstations.  The same technique can be used with a Distributed Files System (DFS).  I recommend the DNS approach because in the circumstances where I’ve seen DFS used in an Active Directory environment, it becomes impossible nearly to remove or move a DFS share if one of the servers holding the share happens to be down.

Characters Allowed In Names

Physical names ultimately convert to DNS domain names and have limits on the characters that can be included in the name. Allowed characters include the ASCI LDH set: A..Z, 0..9, and - (hyphen or dash).

Token Combination Schemes

Defining the name format in a way it can be parsed and broken into tokens will give tremendous flexibility down the road. Organizations will go through buyouts, mergers, or reorganizations every few years. A well planned naming scheme should be able to remain consistent despite these changes.

Note: I’ve added spaces to the examples below to aid in readability. Spaces aren’t permitted characters in real device names.

Examples:

  • {string} {number}
  • {string} - {string}

These two patterns can be extended and chained together. Keeping the tokens of strings are separated by numbers or hyphens gives a lot of flexibility for future expansion without breaking things already in place.

Tip: I don’t recommend using N characters or N numbers. These always are ignored at some point and cause limitations (when store # 1000 is opened and you have a three number scheme). Using some leading zeros can help with making some of the number a little bit more readable though (i.e. svr001, svr032)

Examples:

  • {IATA} - {Building} {Floor} {Office} - {Workstation Role} {Workstation #}
  • {IATA} - {Building Type} {Building #} {Workstation Role} {Workstation #}
  • {IATA} - {Workstation Role} {Workstation #}
  • {IATA} - {User} - {Device Role} {Device #}

Token Types

Airport Codes

It’s often helpful to characterize a device’s physical name with it’s physical location. The airline industry has a convention using unique airport locator codes that I’ve used that is helpful in tracking devices. Airport locator codes include IATA codes and are mostly unique three letter codes and the ICAO provides unique four letter codes.

Usually the nearest international airport is unique enough for most organizations I’ve seen.

Examples:

  • KRDU – ICAO for Raleigh, Durham Airport
  • RDU – IATA for Raleigh, Durham Airport

Building Codes Or Numbers

Adding a building name or number, floor, and office number can be helpful in identifying and locating a machine. If you decide to include a floor and office, I recommend using some string to differentiate the token 2314 could be office 314 on the second floor or office fourteen on the twenty third floor. F23O14 seems pretty clear to me.

This works fine for physical equipment that doesn’t move often like routers, firewalls, hubs and such. I don’t recommend this for user workstations. Users will move frequently and any scheme that takes a users building and floor location into place is going to be obsolete in three to six months.

Examples:

  • {Building} {Building # } – S1433 (Store 1433), W27 (Warehouse 27), O23, B8 (
  • {Floor} - FL2
  • {Office} – O22

Tip: Don’t us HQ as a building type.  Mergers and buyouts will change this at some point and cause conflicts.

Machine Type Or Roles

Using a dictionary of preferred machine types helps when collecting inventory, or multiple administrators are involved on a network.  Some sample machine types

  • AP – Access Point
  • RTR – Router
  • SWT – Switch
  • DC – Domain Controller
  • WKS – Workstation
  • LT - Laptop
  • SVR - Server
  • DB – Database Server
  • WEB – Web Server

Machine Numbers

Giving between two and four digits for numbers to a machine name is useful, but sometimes confusing.  Let’s see, was the web server on SVR13 or SVR12?  I’ve seen various names used to help folks instead.  Anything from Sleepy, Dopey, and the other dwarves to Donald and Mickey. I still have found that using some role and number is easiest, then using a DNS name for easy access for resources seems to work best.

User Names

Because user names have to be unique in a company, user machines can often be named after the user.  Using a suffix like WKS for workstations or LT for laptops is helpful when users have both.

References

Related Items