I got pinged awhile back about machine names. Believe it or not, we have some rules around machines names. Actually, we have one super important rule, one preferred process, and a bunch of minor guidelines.
There are four sets of names you need to worry about on a regular basis: Domains, Servers, Workstations, and Printers. You might have additional devices (scanners, time clocks, nuclear imaging devices, etc.) for some clients. For all of these, the guidelines we use for printers will suffice.
Why Do We Have Names?
As silly as it sounds, people like to find machines and devices by name and not by IP address. Once you allow people to name things, they tend to choose things they like. In my file of strange and interesting bits of knowledge from the past, I have several printouts of various reports on the popularity of machine names.
It used to be easy to compile these before there was a distributed DNS system. Believe it or not, there was a time when you had to download the latest HOSTS file in order to access all the machines on the Internet. Of course that made it easy to grep the hosts file and run analyses.
A good example of this is found in
RFC 1296. In 1992, the first most common host names were Venus, Pluto, Mars, Jupiter, Saturn. The planet theme is very clear here. Greek gods, characters from The Hobbit, Star Trek, and the Seven Dwarfs are well represented too.
But even 20 years ago, it is clear that simple workstation numbers were very popular. PC1, PC2, PC3, Mac1, Mac2, Mac3. Those series (PC and Mac) represent 28 of the 100 most common machine names.
I like themes. Just remember that one theme can simply be the machine's most basic identity (server01, workstation02, printer03, etc.). Just be prepared to take some grief if you use these labels, even though they are perfectly acceptable.
Limitations on Names
Keep in mind that there are some common sense limitations to domain and machines names. There are limits within NetBIOS, limits within DNS, and operating system limits. You should stay within the most restrictive limits. That means you should keep machine names to 15 characters or less.
Microsoft has a history of both allowing and encouraging you to make stupid decisions about domain names and machine names. Bad decisions here WILL bite you in the butt later on down the road. For example . . .
- Since Windows 2000, 64 bit machines can have very long machine names. Don't do it.
- Older versions of SBS defaulted to renaming machines for the current user. Don't do it.
- NT 3.5 and 4.0 allowed domain with hyphens. Once active directory showed up on the scene, these machines (e.g., SBS servers) could not become domain controllers. Ouch.
- For awhile (e.g., SBS 2003), Microsoft encouraged you to use your public domain name (e.g., KPEnterprises.com) as your internal domain name. This led to all kinds of problems down the road. Most people were sharp enough to use .local or some other "fake" domain extension, so they avoided problems down the road.
Lesson: Be careful about advice from Microsoft on computer names.
Also note that some operating systems deal with hyphenation better than others. So avoid it. Don't start machine names with a number. That can be confusing to some programs. Start with an alpha character. User numbers if you want. But avoid spaces and any special characters.
The One Big Rule
I mentioned that we only have one big rule. We have already discussed it a bit:
Do NOT name machines after their users.
Corollary: Do not name machines after their function.
When small businesses first started getting computers, they were delighted to be able to name things. The server was named Server. Bob's machine was named Bob, Carol's machine was named Carol. And that was great for awhile. Then Bob left and Ted took his place. Alice was hired and got Carol's machine as a hand-down.
So Ted's machine is named Bob. Alice's machine is named Carol. And Carol's new machine can't be named Carol because you can't have two machines with the same name.
The problem can arise if you re-purpose a server. When SQL1 is replaced with SQL2, you might want to use that old machine as a file server. So the file server is now named SQL1. Yes, you could rename it, but then you begin to create the kind of spider-webbed active directory you say you hate. Remember that renaming a machine always leaves residue. This is less of a problem than it used to be, but why take steps that "might" be troublesome down the road.
This is a pain in the neck on desktops and a minor annoyance on servers.
The One Preferred Process
I mentioned that we have one big rule (above) and one preferred process. Our preferred process is very simple. We like to name the "big" server with the date it was new. This applies primarily to small business environments. For example, our favorite server names are
- SBS2011
- SBS2010
- Johnson2009
- Unity2008
- ABC2007
The core machine name is either the client's name (Johnson, Unity, ABC), or simply SBS. The date is the year the machine was installed. Clients don't care about server versions (2003, 2008, 2011).
The date format allows you to see at a glance how old the server is. You can use this to help diagnose problems. You can also use it to remind the client of how old the server is. "Well, sir, XYZ2004 is now seven years old. Some of the slowness you're experiencing may be related to that!"
In addition, this habit allows you to quickly identify machines. If all your servers are named SBS or Server, that's not helpful. It reminds me of all the resumes we get named "resume.doc" (not helpful).
Bunch of Minor Guidelines
So, how do we recommend naming machines? Here are some miscellaneous guidelines.
First, if you can get the client to go along, try the basic Station1, Station2, Station3 or Workstation1, Workstation2, Workstation3. Yeah, I know it's boring. But it's easy and straight forward. More and more clients are accepting this. Unlike ten years ago, desktop machines are now just another part of business. They're no longer a play-thing.
Second, pick a name that includes part of the company's name and a workstation number. This is our favorite. ABC01, ABC02, ABC03, etc. It is handy if you already have a 3- or 4-digit code for each client. Just use that.
Third, if the client wants something more imaginative, have them pick a theme. Depending on the size of the office, you'll need to pick a theme with enough options so that you won't run out of names. If you pick planets, for example, you won't be able to have more than ten desktops without using planet names you heard on Star Trek reruns.
Some good themes we've seen include:
- Car parts
- Planets
- Greek alphabet
- Rock bands
- Flowers
- Geographic locations (states, mountains, lakes)
- Colors (again, not too many options here unless you run a paint department)
- Elements
Fourth, consider a generation-based naming scheme. For example, when a client does a technology refresh, give a standard name with a two-digit number. For example, Alpha, Beta, Gamma generations will have Alpha01, Alpha02, Beta01, etc. So you know that Beta machines are all newer than all Alpha machines. This might not be worth the trouble.
Fifth, you might use a department name along with a counter. Sales01, sales 02, finance01, finance02, etc. This works best in large offices. As with personal names, you don't want to find yourself with machine finance02 in the sales department. :-)
Plan on Retiring Machines
One of the key things to remember with computers is that machines die, get old, become obsolete, and are retired. So the names need to allow for this. Ideally, you will be able to retire a name and not reuse it. Or at least not reuse it for a few years. This works well with Station01 ... Station99. It's not as successful with the Seven Dwarfs.
Server01 might be a SQL server this year and an Exchange server next year. But after that, it might be a donation to the local charity. So the name Server01 should be retired and another server added to the end of the machine list.
This policy -- not reusing machine names -- saves confusion in the long run. This is particularly true with RMM tools and PSA systems. You don't want to have sales03 in your paper documentation be different from sales03 in your PSA and even different from sales03 in your RMM tool.
So think of machine names as single-use resources.
We have a spec sheet for machine names. That's where we lay out the plan for machine names. In some cases (e.g., flowers or Greek alphabet), we find a good list on the Internet and put a copy in the
network documentation binder. That way a tech on site can just look up a new name and not waste any time.
It is important to keep track of all machines on a network. We have layers and layers documentation on this. As I just mentioned, there's paper documentation, Autotask documentation, and Zenith documentation. Keeping this straight is a lot easier if you never reuse a machine name.
And therefore, it makes a lot of sense to plan out your machine names as early as possible.
And when you get new clients, set up a policy and begin putting new machines into the new naming scheme as you can.
Implementation Notes
The most basic element of implementation is to simply write 1-2 sentences explaining the naming scheme for each client. This should live in their
network documentation binder. You might also put a note in Autotask or other PSA.
Machine Spec Sheets will of course help in this process.
Your Comments Welcome.
- - - - -
About this Series
SOP Friday - or Standard Operating System Friday - is a series dedicated to helping small computer consulting firms develop the right processes and procedures to create a successful and profitable consulting business.
Find out more about the series, and view the complete "table of contents" for SOP Friday at
http://www.smallbizthoughts.com/events/SOPFriday.html.
- - - - -
Next week's topic: Celebrate Anniversaries (Employees and Clients)
:-)
SMB Books, Audio Programs, and More
100% Small Business I.T. Focused
- Technical - Business - Marketing -
- Managed Services - Cloud Computing -
- Network Migrations - Sales -
All these resources and more.
SMB Books is THE resources for the small business IT consultant who wants to move up to the next level.
|