Best practices
For more ideas on server naming, I really like this article, and the handy abbreviations he has come up with.<location><role><sequence>
Example for some database servers in Ontario (ON = Ontario, SQL = SQL Server):
ONSQL01
ONSQL02
Drawbacks of the "smart" naming approach
The one drawback of this approach is that server roles are often changing, and installing a new service would could render the function of a server to something completely different. Many services will refuse to work properly if the server is renamed, and this is often hard to predict, so the approach should always be "don't rename servers" in my book. There may be certain roles that never change, i.e. things like Active Directory, where its fairly certain that an AD server will always be an AD server.The second drawback of such a naming scheme is that the names can get so unwieldy that you may as well have gone with servers named after Looney Tunes characters and simply looked them up in a name -> role table.
Commentor "Bish" in the above reference blog post at retrohack.com writes:
My company is the embodiment of your plan. USWAFTP104, UKLODC62, etc. It is the hell anyone would instantly recognize after 12 seconds of consideration.
Which machine was that? Do you mean USMIESX4H2 or was that USMIESX2H4 that you just shut down? Oh no! The amount of times that someone remotes (ssh, rdp, etc) into a box and – even if they double-check the number 6 times – shuts down, patches or reboots the wrong host is astounding.A lot of my clients are using UNC paths (\\) to launch applications and services, and trying to explain to a user to open a Run window and type USMIESX4H2 as the server name is just very unfriendly.
Because of this, it may be wise to implement completely "agnostic" names such as those listed at namingschemes.com. Of course, naming all of your servers after ships that appear in Star Trek may is probably a logical approach (thanks, Spock), but your resident boss may think they are too childish. In my opinion this plays a factor only if your organization is client facing, ie, "Hi Mr. Schneider, yes, log into your client portal on daffy.procompany.com".
My picks today are (appropriately nerdy):
- Car parts (pedal, clutch, wheel)
- Chess pieces (rook, queen, pawn)
- Periodic table elements (copper, chromium, hydrogen)
- Planets (mars, jupiter, saturn)
- Greek alphabet (alpha, beta, though there are some unfriendly names like 'mu'), this is closely related to the UN/NATO Alphabet.
What Microsoft Says
And of course, what post on this blog would be complete without poking a bit of fun at Microsoft for going the exact opposite direction in recommending non-industry standard naming conventions. I like this gem:"Identify the owner of the computer in the computer name."from KB909264 at Microsoft's site.
No! No! No! This is some terrible advice! I run into this all of the time, where a client lets an employee go and wants to change the name, or confusion rising out of "Fred" using a PC called "TomPC1". Absolutely couter-intuitive.
Not to mention that some well-known RFCs discourage this naming convention, such as RFC1178.
Not only that, but I've had clients insist that the name of their computer be changed, even though for most intents and purposes, the hostname is never seen and is irrelevant to their job function, but it just feels wrong, because "Tom" stole from the company and "I might get some bad juju from being associated with him in any way." Then I need to explain that changing the name may break some services in an unpredictable way somewhere down the line, and in the process see the user get the glazed-over look.
For client PCs
I settled at first on desktop-XX for desktops then notebook-XX for notebooks as my company's naming conventions for clients (under 100 employees), and later I dropped the hyphen because it's unnecessary.So there you have it.
