…and we’re back. After some unavoidable hosting issues ended the previous incarnation of retrohack, I seriously, considered just letting it go. I mean, I wasn’t spending that much time on it, hadn’t in years, had gone months between posts, and really didn’t think anyone cared. Then two things happened. The first was that I got an email from someone who actually missed the site, and who said some very nice things about it. Then, I needed to enable stealth mode on Skype again, and couldn’t remember how to do it. Thank the gods for archive.org, which seems to have a copy of most of my old content. So, as time and interest allows, I will try to recreate some of the old posts from the website formerly known as retrohack.com, and who knows, maybe I will even add some new ones. Stay tuned, or not, as you see fit :-). And if there’s actually a post you’d like to see, use the contact form to let me know and I will try to nudge it up to the front of the queue.
I spent all weekend with a 6 second long sound bite stuck in my head. It’s from a song I used to love, that I’d played thousands of times, and probably haven’t thought of this century. I knew that the name of the group had something to do with Bangkok, or Tokyo, or some vaguely Asian location, and while I could hear the tune inside my head (at least when the voices gave it a rest) I could NOT come up with the name, or even enough of a lyric to let Google work it’s magic. I needed the name. And that got me thinking. I’ve worked on hundreds of networks, and I’ve seen just about every server naming scheme you could imagine; the good, the bad, and the ugly. Most fall into the cracks between good and bad; let’s call them the indifferent. You can almost classify the techno-geek maturity level of an IT organisation by their naming convention. (You like that? It just happened!) New orgs stick with the classics, like X-Men characters, mythological deities, chemicals, planets, etc. Orgs that are trying to ‘grow up’ err on the other extreme, trying to develop a naming convention that invokes the corporate name, or give as much detail as you would expect to find on the server list on SharePoint.
What’s in a name? That which we call a rose by any other name would smell as sweet.
-Romeo and Juliet, Act II Scene II. William Shakespeare
…see, a guy works a Shakespeare quote into a post, he must know something good.
But that which we call in a UNC path has to be easy to use and remember, and must be resolvable in our DNS. There are some common mistakes that I have encountered over time, and it was one such recent charlie-foxtrot that prompted me to pen this narrative.
Out in the real world, there are two main schools of incorrect thought on the subject of naming systems. I like to call them ‘the Hyphenators’ and ‘the Cryptics.’ In ages past, the forebears of the Hyphenators found out that they could put a hyphen (dash, minus sign, call it whatever you want, it looks like this – ) in computer names, so they did. What followed was years of needlessly breaking names up with countless dashes, and endless “Please check the name and try again” messages from telling users server names, while not saying the “dash” since “everyone should know it’s there” incidents. Actually, I think they eventually devolved into getting kickbacks from the keyboard manufacturing industry, because they put so damn many hyphens in their computer names that you’ll wear out the button on your keyboard!
All of the Cryptics descended from the single forsaken lovechild of a government bureaucrat from the Department of Acronyms, and Rainman. Reproducing asexually, they like to assign a specific, uniform designator to every facet of a machine, and concatenate that together with a location and a number and a department and a distinction between test and production and another between physical and virtual and another for the operating system and another for the version and….you get the point. They used to be called ‘the Run-Ons’ but the Hyphenators got pissed that the name had a hyphen in it. You can imagine what happened next. Well, maybe you can’t. In a fit of Capulet v Montague amour, two of them combined, and the world came to be burdened by hyphenated-cryptics! Many Shuvs and Zuuls knew what it was to be roasted in the depths of the Slor that day, I can tell you!
Before we discuss what makes a good naming convention, let’s discuss the things that govern what we can and cannot do. We’ve got four categories, which are summarised below.
NetBIOS names (as implemented by Microsoft) are still (even Windows 7 and Server 2008 R2) heavily used by Microsoft. We’ll likely never get away from them entirely. They are exactly 15 bytes in length, which provides for no more than 15 ASCII characters, null padded if necessary, plus a 16th hexadecimal service identifier, or primitive, that indicates the type of name (workstation, server, messenger, domain controller, etc.) While they can contain any letter or number, they cannot contain spaces, cannot consist only of numbers, and the only permitted punctuation characters are underscores and hyphens.
•Host (DNS) Names
Host names can exist alone, or are mapped into a DNS zone as fully qualified domain names. While an FQDN can contain up to 255 characters (plus a . to reference root), a single label can contain no more than 64 characters. Host names can contain any ASCII letter or number, or hyphens only, with periods separating levels of the hierarchical name and terminating the namespace.
Called “Choosing a name for your computer,” this RFC lays out some good guidelines to use when naming hosts. Highlights include favouring shorter names, avoiding words with alternate spellings, and not using digits at the beginning of names.
•(un)Common sense Names
Names should be easy to remember. They should convey useful information. They should not require different treatment based on use (encoding characters in HTTP, escaping characters in LDAP or scripting languages, etc.) They should make sense to the end users and the admins, and err on the side of the end user. Everyone knows where they work…you do not have to include the company’s identity in the server name!
So if we take all that into consideration, we want to shoot for names that are around eight characters long, are easy to remember, and tell users and admins both something useful about the system. We’ll avoid the use of hyphens and underscores completely. So taking all that into account, what do we do?
First, we’ll start the server name with an identifier for the location. Three letters works well here, so you just need to come up with a scheme that identifies all of your locations. The three letters should be easy for end users and IT to remember. Most muggles won’t know airport codes that don’t line up with real city names unless they fly there regularly, so don’t use them. The larger a company is, the more likely you will have cities with similar names, so try to come up with a list of all your locations early on, and vet it with the global team to make sure everyone can live with it. If you are an international team, check to be sure that the city abbreviation doesn’t say something naughty, especially when combined with a server function. I had a naming convention once that would have placed an EX (Exchange) server in BISmarck, ND…therefore Bismarck became BMK.
Next, we will use some standard abbreviations to identify the type of server. Here, understanding is more important than consistency, so some codes may be two letters, while others are three or more. Notice that some apps get full names, while others get abbreviations. The distinction is arbitrary, and you are welcome to modify it to fit your needs. What I have below works for me, and should be a good start for you. You could always leave a comment with more suggestions
server type code domain controller DC file server FS print server PS VMware ESX host ESX MS Hyper-V host HV web server WEB MS SQL server SQL Oracle server ORC generic application server APP accounting server ACCT human resources server HR media server MEDIA VPN concentrator VPN Internet Security and Acceleration server ISA Threat Management Gateway server TMG DNS server DNS DHCP server DHCP SharePoint server SP SolarWinds server SW Splunk server SPLUNK SNA server SNA VoIP server VOIP Call Manager server CM Unity server UNITY Cisco Emergency Responder server CER Exchange server EX Exchange mailbox server MB Exchange Client Access server CAS generic mail server MX Lotus Notes server CRAP etc.
Finally, add a number. Start with 1, and increment up from there. The number is more to allow for redundancy than to indicate ancestry or lineage. Let go of the need to have certain servers always be referenced by the same name. That is what aliases are for, and in an upcoming post, we’ll discuss the common DNS aliases every company should use.
That’s all there is to it. Following the above, you will have server names between seven and eleven characters that are easy to remember, and to spell out to users. From the name you will be able to determine where the server is, and what it’s for. In a name, that is all you really require. If you want to know the operating system, the patch level, how much RAM, Disk, etc. it has, and whether it is physical or virtual, use bginfo to display this on the console, or consult your server list on SharePoint. Your domain controller in Orlando will be ORLDC1, your file server in Jacksonsville will be JAXFS1, the ESX host in your Miami datacenter will be MIAESX1, and your VoIP server in Chicago will be freezing I mean, CHIVOIP1.
Hopefully this will help someone out, and maybe give them the ammunition to convince some hyphenator to STFU and GBTW, and let the real geeks make the important decisions. Hopefully if you have to show this to your boss to convince them that easy is better…they’ll have a similar sense of humour to me! Hopefully, you care enough for my sanity that you wonder if I ever found the song. I did. It just came to me as I was finishing this post. Some bizarre association, or maybe my muse just wouldn’t give it up until I got another post done. Either way, maybe now I can get some sleep! It was Saigon Kick’s “Love is on the Way!”
If you are like most Windows admin’s, you find yourself accessing the console of various servers throughout the day. If you are using an rdp client like mstsc, or rdesktop, you may have several remote sessions open at the same time. And unless you just went through a major hardware refresh, you probably have a variety of different hardware platforms in production. If you are running multi-homed servers, or servers that for some reason cannot reliably resolve all required names through DNS, you probably have static route entries, and either a HOSTS file, an LMHOSTS file, or both, in use on your system. If you are like me, it gets kind of confusing trying to keep track of each system that you are on, and you might have wasted some time trying to troubleshoot a connectivity problem before realising that there was a static route, or an out of date ip.addr in the local file. Over time, I have come to make bginfo a standard part of every Windows server I stand up, and if I have to spend more than five minutes on someone else’s server and expect that I’ll have to come back later, odds are I will add it to that server too.
This tool was developed by the geniuses at Sysinternals, and though they are now a part of Microsoft, is still one of the free tools available here. When run, this tool will take whatever wallpaper you have, and overlay text information such as the system hostname, ip.addr information, cpu, ram, free disk space, or free form text. You can control the font, size, and colour of the information, and the placement on the desktop, and when you update, you can update the active desktop, terminal sessions, and even the wallpaper before login.
Here is a screenshot from one of my servers.
It is an ISA server, so there are both static routes, and the use of a HOSTS file. You can see that I feature that information prominently at the top of the page, along with the following standard information: hostname, boot time, ip.addr’s, cpu, ram, and free disk space.
As part of any server build, I use the following four files.
bginfo.exe-see the download link above
bginfo.cmd-a simple batch file to run at each login. You can also schedule it if you want more frequent updates without logging in. Here’s the contents of that file.
bginfo.exe c:\windows\config.bgi /timer:0
This is a binary file, so I cannot paste it here. The first time you run bginfo.exe, customise the basics as you want them, and save that as the default. This will create a %windir%\config.bgi file that you can copy to other hosts. The first time you run it, you will see all the available default fields. You can also define custom fields, or even insert images like the corporate logo if you want to.
This registry key can be imported into your registry, and sets up the RUN key so that the bginfo.cmd executes at each login. Here’s the contents of that file.
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run] "bginfo"="c:\\windows\\bginfo.cmd"
Copy the first three to %windir%, and just double-click the reg file to import it into your registry. Now, each time someone logs onto the server, the cmd file will run and update the information on the wallpaper. You can of course manually run it from the cmd line or start, run. You will probably want to play around with the colours of the text and background, as well as the fields that are displayed, until you find the right mix for you and any other admins on your team who will have to deal with your servers. Once you do, you will find this to be a great addition to your standard deployment, and find yourself wondering how you lived without it.
More information is available from Microsoft’s website at https://docs.microsoft.com/en-us/sysinternals/downloads/bginfo.