When it comes time to name servers, every organization has their own way — or lack thereof — of handling the task. Early on in my IT career, I remember seeing servers in all kinds of places named things like Spock, Kirk, Neptune, Pluto, and Venus. It was obvious that these organizations decided to standardize their server names on Star Trek and the planets — back when Pluto was still a planet, of course.
When I was a systems engineer for Thomson Financial, we had two server naming conventions: UNIX servers were named after global currencies, while the servers on the Windows side of the house were named after various presidential pets. In the case of the Windows servers, my boss wanted a server naming convention that was at least somewhat scalable to a few dozen servers while also being somewhat obscure.
There was a day in which "security through obscurity" ruled the roost when it came to naming servers (this is still the case in many places). In these instances, the server name was completely decoupled from the server's role. As you can tell from my Thomson Financial server naming convention, that organization felt that naming servers with names that had nothing to do with the server's role assisted in helping to secure the environment. At that time and in that environment, this outlook certainly made sense, particularly given the fact that we weren't running a firewall at the front end of the network. (For the record, it was 2001, and the exclusion of a firewall was a decision that was made by people well above my pay grade.)
I understand the security through obscurity argument that's commonly made when it comes to randomizing server names. The general thought is that tying a server name to a function gives an attacker one more bit of information that could be used to refine or target an attack at a specific service.
Although I I understand the argument, in the kind of environment I work in now, I don't agree with it. I believe that the additional administrative difficulty that is introduced with random names is not worth the semblance of security that is achieved. I'd much rather see IT not have to refer to a server index when it comes time to do work. For example, suppose someone is having a problem with Microsoft Exchange. Is her mailbox housed on Frisco, or is it housed on Turtle? Obviously, over time, administrators will learn which servers do what, but this also extends the training period for new administrators.
I much prefer server naming conventions based on the role of the system. Boring? Yes. Functional? Yes. Some of our server names at Westminster include ESX1, ESX2, Mail1, DC1, and so forth. Sure, an argument could be made that we still don't know which server houses a particular user's mailbox, but at least we know where to start looking when we have to track down a problem.
Naming conventions on campus aren't limited to servers. We've recently moved to a new print server and, at the same time, moved to a common convention for our printers. Our next target is desktops. As IT team members have come and gone, we've run the gamut of desktop naming conventions, and every single one of them are in use to this day. Can I tell you how difficult it is to understand what's actually out there when we're using something like four naming conventions? It's time to tighten that up. This has truly come to light as we've begun to deploy System Center Configuration Manager, which is very client-focused. The goal is to build SCCM collections that include, for example, computers that reside in the Business Office. When you have a bunch of naming conventions (which really means you have no naming convention), it's really difficult to figure out which machines are which.
Good naming conventions aren't just for IT, either. Users benefit from consistency. For example, we seriously simplified the process for connecting to a new printer on campus. Now, the printer directory actually makes sense. It's reduced printer-related support calls to the help desk, too.
As for Westminster, we're making progress on this front and will continue to do so. As we retire servers, the replacements come in with names that match our current naming convention, and life is just easier all around.
- Naming conventions ease the burden on support
- Determining a good naming convention for your network
- Scooby-Doo or SFRANFILE: The hows and whys of server names
Want to keep up with Scott Lowe's posts on TechRepublic?
Since 1994, Scott Lowe has been providing technology solutions to a variety of organizations. After spending 10 years in multiple CIO roles, Scott is now an independent consultant, blogger, author, owner of The 1610 Group, and a Senior IT Executive with CampusWorks, Inc. Scott is available for consulting, writing, and speaking engagements and can be reached at email@example.com.