Category Archives: naming conventions

Naming Conventions: SQL Server Names


If you’re working in a Windows environment like me, you have to deal with 15 character limitations (at least if you care about NETBIOS resolution).  Honestly, really cramps my style, but these conventions were written with that limitation in mind.  If you’re using this for a Linux based server running MySQL or PostgreSQL, you might be able to get a little more detailed.

Multi Environment / Cluster or standalone:

At my employer ASI, we have to contend with multiple applications, multiple environments for each application and in a lot of cases clusters.  Trying to come up with a name that works for them all can be tough, but I think I’ve got a few good ones depending on your use cases.

Here is an MSSQL server naming convention:


  • cmp-sqlps1-01
  • cmp-sqlus1-01
  • cmp-sqlss1-01
  • cmp-sqlds1-01
  • cmp-sqlps1-02
  • cmp-sqlps2-02
  • cmp-sqlus1-02

Let’s break it down:

  • cmp = company.  Use whatever prefix you want, doesn’t need to be all letters and doesn’t need to be three, but I wouldn’t go beyond three.
  • (_) underscores = separators
  • SQL = SQL server
    • Next letter = environment
      • P = Prod
      • U = UAT
      • S = Stage
      • D = Dev
    • Next letter = Clustered or standalone
      • S = Standalone
      • C = Cluster ***More on this later
    • Following number = the number of SQL servers for this environment and application.  If you have multiple stand alone servers for “app1” this allows you to accommodate them.
  • The final number is a number to represent the application.  Doesn’t matter what the number is, but once its assigned, your other environments should fall into the same number.  I can look at the last number and quickly go “oh that’s app 20”.  Ok, maybe not quickly, but its easy enough with a matrix.

You can quickly determine if the servers function, environment, is it a cluster and the apps.


Cluster management resource name

  • cmp-sqlpc-01
  • cmp-sqluc-01

Cluster Node Name:

  • cmp-sqlpcn1-01
  • cmp-sqlpcn2-01
  • cmp-sqlucn1-01
  • cmp-sqlucn2-01

Cluster application resource name

SQL AAG Name / SQL Listener Name
  • cmp-sqlpcdg1-01
  • cmp-sqlpcdg2-01
  • cmp-sqlucdg1-01
  • cmp-sqlucdg2-01
SQL Traditional Failover Cluster Name
  • cmp-sqlpcdi1-01
  • cmp-sqlucdi1-01

Let’s break it down:

SQL clusters require a lot of computer accounts / names, and having a naming convention helps to keep them grouped and organized.

  • CMP-SQLPC = we should already know this based on the previous explanation.  This part tells me its a SQL production cluster.
    • If it goes straight to the application number, that means this is the cluster management resource.
    • If it goes to N1 or N2 = that’s the node of that cluster.  N1 = node 1, N2 = Node 2.
    • If it goes dg1 = Database Group 1, or SQL AAG1 and it belongs to this cluster.
    • If it goes DI1 = Database Instance 1, or SQL failover instance 1.
  • The following number of course is the application we’re assigning.


That’s pretty much it, short and sweet.  It’s not designed to scale to massive levels, but I think it will work for most environments.


To see other naming conventions or posts about naming conventions, head over here.

Naming Conventions: Windows Local Administrator Group via Active Directory


One thing that always kind of sucked with windows servers (and its even worse with Linux) is dealing with how to manage local administrator rights.  Now I realize a lot of you just add yourself to the domain admins and use that account (not a security best practices) to administer your servers, but what about everyone and everything else that might need local admin access?  What I have for you here is how I not only created a new naming conventions, but also how I tackled managing local administrator access in windows domain environment.

What you need:

  1. This is dependent on active directory. If you’re dealing with non-domain systems, this post isn’t really for you.
  2. You’re going to need a group policy object and your servers / desktops are going to need to support group policy preferences (2003/XP and above).

What you’ll want:

  1. More than likely a provisioning process that automates something which GPO/GPP can’t. For example, a simple PowerShell script that you run once the server is provisioned to finish the little things.

The naming convention:

I use a pretty simple naming convention for local administrators.  There are three main conventions I used which are below.

  • _asi_lad_%Server or Computer Name%
  • _asi_lad_All Servers in AD
  • _asi_lad_All Desktops in AD

Naming convention breakdown:

  1. The underscores are used as separators. At some point you may need to do queries with scripts, and knowing that an “_” represents a separator will make it easy to know where to start looking for variables.  For example, if you just looked in AD for something like *ServerName* you might get back more than one AD object, but if you look for *_lad_Servername you’re only going to get back local administrator groups.
  2. “ASI” in my case stands for Advertising Specialty Institute, which is an acronym for my company name. I used to work at the Pew Charitable Trusts and used “PCT” for them.  I use a company name to start out everything because down the road, you never know who you’re going to merge with.  While there is always a chance that ASI could merge with a company named “Advanced Internetworked Servers” or something like that, its not likely.  Plus, if you’re running a sort of multi-tenancy, this allows you to keep different companies separate.  It doesn’t need to be an acronym, nor does it need to be three letters, but it should be specific to a company.  Heck, if a small GUID makes sense go for it, just keep in mind that 64 character limit with AD (yes I’ve hit it with group names).
  3. “LAD” as you can guess stands for Local Ad Again, it doesn’t need to be three, but it should be consistent.
  4. The final part
    1. The server name is kind of obvious.
    2. All servers is kind of obvious
    3. All desktops is kind of obvious


You could of course take it much further than this if you want, it really depends on how granular you want to get.  I try to keep things balanced.  If your servers themselves have a good naming convention, you can likely already key off of that.

How it works:

  1. I created a GPO for my servers and a different one for my desktops. To be VERY clear, this GPO is not dedicated to this purpose.  I try to use one GPO to rule them all as much as possible.  So I add this to my GPO which applies to all servers and the one for all desktops for other things.
  2. Create a computer GPP setting which adds the respective “_company_lad_all server” and “_company_lad_all desktops”. This gives you an easy way to drop a service account into a group that will gives them local admin access to all servers WITHOUT giving them domain admin rights.
    1. As an aside, we also create a GPP that removes domain admins.
  3. Now, for the servers specifically (we don’t do this for desktops) I create a server specific group (via a script) and add it to that server (via script). You now have an ability to add a user to the local admins without ever needing to login to that local server anymore.


Powershell Snippet for creating a group and adding it to the local admins:

#Create and assign default local admin group


$ServerName = “cmp-servername-01”

$GroupName = “_lad_cmp_” + $ServerName

$OUPath = “OU=YourOUPath,DC=Domain,DC=Name”

$FQDN = “”

#Creating group

New-ADGroup -DisplayName $GroupName -GroupCategory “1” -GroupScope “1” -Name $GroupName -SamAccountName $GroupName -Path $OUPath

Start-Sleep -Seconds 15

#Add Group to servers local administrators

$de = [ADSI]”WinNT://$ServerName/administrators,group”



That’s it really.  You can of course take it further, but this is a simple way to get a handle on your local administrators, and centrally manage them all from AD going forward.  You also now have a naming convention which makes it easy to track them down and automate various tasks.


To see other naming conventions or posts about naming conventions, head over here.


Naming Conventions: Introduction


If there was one area in IT that I tend to be fanatical about (some would say fanatical isn’t a strong enough word), I would have to say its naming conventions.  For me, learning about naming conventions in school and then seeing it put into practice in my first real gig, really enforced the concept that naming conventions are important.  I actually consider myself pretty lucky in that respect because I don’t think a lot of people have had the fortune of studying about the concept, let alone working for a company that had a decent naming convention.  After walking fresh into two different employers and seeing the mess they made, and also working through a few mergers, I know that good naming conventions don’t always exist.

This post is going to be refreshingly short, and instead really serve as an introduction to a new series I’m going to start.  The series will be a culmination of naming conventions for different things in IT.  I manage a ton of different things, so there’s always an opportunity for a new naming convention.

Why do you need a naming convention?

Here’s the thing, you don’t need a naming convention, but you should want them.  Not caring about names of objects not only makes your life hell, but also everyone that either replaces you or works with you.    The end goal of a naming convention is to put a little effort up front, so you can save a ton of time down the line.

How does a naming convention save you time?

Let me give a few examples:

  1. Once you have an established naming convention for an object, naming the next related object usually requires little thought.
  2. It keeps you and your peers organized.
  3. It provides consistency, and consistency leads to intuition, and intuition basically means second nature. If something is second nature, you’re not really thinking about it, and thus saving time.
  4. Getting a little more technical, naming conventions allow you to search and filter predictably.
    1. Being able to do this, means you can now effectively use scripts with deterministic targets.
    2. Writing reports is easier
  5. Identification of what something is becomes easier
  6. When done right, they’re forward thinking so they can be easily updated to reflect new changes.

When naming conventions don’t make sense?

Almost never, I don’t care if you have one AD group for managing a single server.  Now you might not need a super complex naming convention in that case, but you should still have something predictable.

That being said, Tags are slowly but surely becoming the new way to identify objects.  It makes a lot of sense, and to some degree it does invalidate the need to have monolithic naming convention.  Beyond that, even the best naming conventions will at times run into scaling issues.  Tags are infinitely more flexible and I’m looking forward to their eventual ubiquity in every aspect of technology.  Even with this, you should still keep in mind that tags are just as easily susceptible to bad naming conventions.  Your tag names and categories should have well thought out standards to ensure consistency as well.


Naming conventions to me are right up there with regular maintenance, patching and other important but boring aspect of IT.  You need a plan, and you need to stick to it.  Don’t be one of those lazy IT people that can’t think further into the future than now.  Saying you “don’t have time” is a load of bytes, there is ALWAYS time for a naming convention.


This post is also where I plan to host the table of contents for all naming conventions posts.  If you think you missed a post, or can’t find it, track back here to look for it.  I plan to include a link to this post in the end of every naming convention post.