Server name strategy

Some may know that my background has mostly been in infrastructure and systems management. One thing that is pretty inconsistent across people and companies is: what do you name your servers?

This came up in conversation twice, so per my rule – I’m writing a blog post about it!

What do I avoid?
Generally-speaking, I don’t find arbitrary names to be useful. Some use constellation names, Star Wars/Star Trek character names, etc, etc. Using a standard like this causes a few issues:

  • Doesn’t give you any information at all about what the server is or what it does or where it is.
  • Has inconsistent server name length, which adds to the chaos of trying to effective manage a bunch of servers. For example, in scripts, you can’t parse the server name and make some assumptions about it.
  • It’s unprofessional. Do you instill confidence in your customers when you tell them to connect to the “hansolo” server? It makes the business think that you don’t take their computing environment seriously.
  • Copyright infringement?!

So for me, there is no scenario where I would name something “ice cream cone”, “kitkat”, “lollipop”, or “chewbacca”. To me, that is unprofessional, and really counter-productive. Aside from it being silly, there is no upside and nothing but downside.

Including metadata in the name:
When managing systems, each being it’s own little ecosystem, it helps to curb the chaos by including some metadata in the name. For example, include designations for various key components, which aren’t likely to change:

  • Location code (can be city or airport code: TPA, SJO, or just two letters: NY, SH, etc)
  • OS type code (Windows, Linux, Unix, etc)
  • Environment (dev, qa, production, etc)
  • Use (web, db, pdc, etc)

What should you not use?

  • OS version number, like UB14 for Ubuntu 14.x. When you upgrade that server, it’s going to break all of your users!
  • Business domain name – every time there is a change in senior management, they need to justify their job by doing a reorg. So now, the servers that were named after “sales track” all need to be renamed to “smart tracker”… and then you’ll repeat the process the next time there is a reorg!
  • Don’t base the names off the domain name. With mergers and acquisitions, it’s only a matter of time until that will need to change.

My preference:
In my time with managing servers both professionally, and for what I do at home, I think I’ve evolved to the following standard – which works pretty well:

  • Location – 3 character city is probably enough and supports common prefixes like “east” and “west”. For example, East Hartford might be EHF and West Avon might be WAV.
  • OS type (W=Windows; U=Ubuntu; R=Red Hat; V=OpenVMS; A=AIX, etc)
  • Environment (D=Dev; Q=QA; P=Prod, etc)
  • 3 letters for use (DAT, BAT, WEB, PDC, BDC, DNS, etc)
  • Then a number – like 01, 02, 03

I choose a 3 letter acronym for use simple for consistency – so “DAT” instead of “DB”. Again, if I am automating something, I have a guaranteed 10-character server name, which makes parsing easier.

So, the reason I like this is because this tells me everything I need to know at a glance. If you had offices in Columbus, OH and Chicago, IL – what do you think these servers do?

  • COLRQWEB04 – Columbus, Red Hat Linux, QA, web server, #4
  • COLWPPDC01 – Columbus, Windows server, Prod, primary domain controller, #1
  • CHIWDWEB06 – Chicago, Windows server, Dev, web server, #6

Or, in pictorial form:


which would translate to something like this:


Why is this good?

  • I know the location, operating system,environment, and use.
  • I can easily script against these server names since that are 10-character
  • Since they are 10-character, they work as NetBIOS names too – which need to be 11 characters or less.
  • This is scalable in every direction, and minimizes as much as possible, for the reasons you’d need to change the name – whilst also giving you a lot of information about what, where, and why about that server.

Everyone has their own preferences, this is mine!

What you should use:
First and foremost, if your company has a standard – you should definitely, definitely use your company’s standard. This post is really just to share my strategy, particularly for naming servers at home or for any outside work I do when there is not a standard.

If you are setting up new servers and there are no standards yet – consider the above, maybe that will help solidify what you use. One thing that you will appreciate later is simply being consistent. There is nothing worse then having one set of servers named “the old way”, but these ones are named “the new way” – it becomes tedious to manage.

What is your preference for server naming standards?

Posted in Best-practices, Computers and Internet, General, Infrastructure, Linux, Uncategorized, Windows
One comment on “Server name strategy
  1. […] the new servers in place:In my case, I wanted to do fresh installs, and use my new server naming strategy. So first, I bring up my domain controllers as regular (NOT read-only) domain controllers. This […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Enter your email address to follow this blog and receive notifications of new posts by email.

Join 9 other followers

%d bloggers like this: