title: Functional Server Naming Conventions
body: <p>I've seen "<a href="https://stackoverflow.com/questions/262657/the-coolest-server-names-closed">The Coolest Server Names</a>," and I've seen another <a href="https://stackoverflow.com/questions/631220/good-server-naming-convention">smaller-ish question</a> related to mine, which was unfortunately closed.</p>
  
  <p>It's a serious question though, as I'm on an internal applications dev team that manages the apps on a couple dozen servers. The networking folks typically don't care what we call the servers as long as they know about 'em, so we can come up with whatever conventions.</p>
  
  <p>The apps the servers deal with can be home-grown custom apps, or they can be larger vendor ones like SharePoint. They can be:</p>
  
  <ul>
  <li>In multiple networking environments that can't speak to each other (think firewalled-off external servers versus intranet-esque servers)</li>
  <li>In different physical locations (California office versus New York, etc.)</li>
  <li>In multiple deployment tiers (production, staging, testing, dev)</li>
  <li>Have one or many functions (web server, DB server, mail server, app server)</li>
  <li>Load-balanced or not</li>
  <li>Standby (for disaster recovery purposes) or primary</li>
  </ul>
  
  <p>Whew! Think it's even possible to come up with a convention that can address all of these aspects, or significant ones? It'd be nice to hear a server name (or DNS entry for it) and be able to immediately know what it does, and it works for getting new guys up to speed as well. "sharepoint-IPC-1 is down" could be parsed into "the internal production SharePoint web server in the California datacenter that's the first node in the load balancing is down!"...but that seems overly complicated at first glance.</p>
  
  <p>Another thing in the back of my mind is that an old mail relay server is getting decommissioned, which means we have to scour through a lot of old apps to repoint hardcoded server values (I know... :).</p>