Is it vital to have a naming convention for all the servers in your infrastructure? The answer depends on the number of servers you have. If you have only a few servers, you probably know each machine intimately: You know where it's located, and you understand its relative importance to the infrastructure if a problem arises.
But what if you have a large, distributed infrastructure that spans hundreds of servers? Suppose your beeper goes off, notifying you that your monitoring service has identified a problem with a specific system: Problem with SERVER27.You have to rack your brains to figure out where SERVER27 is and what it does. If SERVER27 is a backup server for a production system, you probably don't need to rush to fix the problem, but if it hosts Microsoft Exchange Server for senior management, you need to know about any glitches right away. The ability to find servers quickly when things go wrong is the best and most practical reason to use a naming convention.
Common Methods
How do you decide what kind of naming convention to use? Here are several considerations to keep in mind.
- Office or location codes—If your company has many offices, you can use office or location codes to identify server locations. For example, I know a company that uses location codes, such as ZKO, REO, and DBO. If your location contains several buildings, you can add numbers to identify certain buildings, such as REO1 and DBO2. Remember, however, that if you close down an office and relocate servers, you'll have naming problems.
- Geographic names—The big benefit of geographic names such as London, Paris, and New York is that they're unlikely to change before you need to replace a server. For this reason, many companies use three-or four-character abbreviations of geographic names—such as LON, PAR, and NYC—as the basis of their naming convention.
- Function indicator—Knowing the location of a problem server is valuable, but knowing that server's function is essential. Many companies use values such as EXMBX (Exchange mailbox server), EXBHS (Exchange bridgehead server), EXPFS (Exchange public folder server), GC (Global Catalog server), DC (domain controller), DHCP (DHCP server), and WS (individual workstation) to specify a particular computer's importance to the infrastructure.
- Identifier—If you have more than one server of a specific type in a certain location, you'll need to assign values that create unique identifiers. Some companies number their servers, whereas others use values that provide more information about the server. For example, a company might use CL1 to specify the first node in a cluster, or PL380-4 to specify that the server is a four-way HP ProLiant DL380. Remember, however, that extreme specificity can be excessive, and simple numbering schemes are typically sufficient.
Put It All Together
Using these naming-convention methods, you might end up with a name that looks like NYC1-EXMBX1—this sample server is located in Building 1 in New York City and is the first Exchange server in the office. Some administrators recommend specifying the user community that Exchange servers support, so they might add suffixes such as -VIP (VIP mailboxes), -FIN (Financial Department mailboxes), and so on. So, the resulting name might look like NYC-EXMBX-FIN1.
On a cautionary note, before you include the server's role in your naming convention, ensure that your security team doesn't mind. Some security teams believe that adding this kind of information makes servers more visible as attack targets. However, it's also fair to say that security teams are paranoid because of the nature of their business. They would prefer that you give servers names such as AAAZZZ-ZXYY-003-AAZ. In fact, if Windows would let you include special characters in server names, the security team would want you to do that, too.
Does It Matter?
Some administrators believe it isn't important what server name you use, simply because it's possible to rename servers later. In practice, however, most administrators never get around to renaming servers. Instead, they leave servers with their original names until the servers gently degrade over time and eventually leave the infrastructure. I recommend selecting a naming convention that is resilient to change and that meets the restrictions that others in the organization (e.g., your auditors, IT security) place upon you.
