Christopher Lentz | March 24, 2016 08:00 AM
As a network engineer, I have encountered the gambit when it comes to odd configurations and strange practices. Sadly, this doesn't just apply to small business networks; even some of the big boys are not playing with a full deck! In IT, there is a certain expectation that some kind of standards have been followed by the previous administrators and/or engineers. When that is not the case, it can be a slow process for someone new to the environment to get up to speed or even comprehend the "how" and "why" of those setups. One of the most commonly debated issues in IT and networking revolves around naming conventions or schemas. Why all the fuss? Let's dive into the factors that come into play when deciding on a schema.
There are circles in IT that believe that a naming convention should not give too much information away about what the device is or its purpose in the grand scheme of things. Others however, believe that the name should be a quick way to recognize where you are so as to not confuse one system with another. I think both sides present valid points. On the one hand, security is important and on the other, ease of management is important.
Let's say we have an Microsoft Exchange Mailbox Server that we want to name, the security side might say "Let's name it VMPSF-01" where the V represents a virtual server, the MP represents a primary mailbox server, the SF represents San Francisco, and the 01 is a numeric identifier. The ease of management folks have a completely different idea "Let's name it VIR-MAIL2013-SF-01"; where VIR stands for virtual again, MAIL2013 is an obvious one, SF is again the location, and 01 tells us it is the primary.
A common Shakespeare quote comes to mind, "A rose by any other name would smell as sweet...", making the plea that how things are named does not make them what they are. That being said, I tend to incorporate both sides into naming systems. Combining the two can provide security with ease of management; "P-MB-SF-01" where P is a physical server, MB is mailbox, SF is the location, and the 01 identifies the primary.
One of the greatest mentors I have had the privilege to work for always mentioned K.I.S.S. (Keep It Simple Stupid). It has stuck with me my entire career, at every place I have worked in my 17 years in IT because it is the wisest advice anyone can take. Keeping things simple allows the security and management side to take equal strides. To be honest, if you have proper security implemented on all your systems, giving devices the most obvious names should not be a concern. Why? Security through obsurity is one of the most dangerous plagues to hit IT and network engineers since the Black Death. Do yourself and those who follow you, keep the names simple.
Now that we have a bit of background, let's discuss why we need a naming schema in the first place. The first item that comes to mind for me is the ability to quickly determine what devices and systems perform specific functions. In our above examples, an understandable pattern relieves newcomers of deciphering the cryptic mess that was the previous administrators work of art. You can accomplish this best by gathering all your departments to discuss the systems and their functions. Now, with that information in hand a smart schema can be greated that is both simple and easily translated to newbies and even experienced team members. Finally, be sure to document the schema and share it will your entire business so they can follow the same process over the entire infrastructure.
See...that wasn't so hard, was it? Believe it or not, things like this can make or break a business. Go get your teams together and come up with that schema, if you need some help we're not going anywhere!