Computer naming schemes

I often get asked what I recommend for server/client naming schemes. Although there is no definitive answer; this always depends on your organization and what your specific requirement are, here are some pointers:

Things you would often want to include in the name of a machine:

  • Your organization name or an abbreviation of it: <org>
  • The machine type; laptop, desktop, workstation, server etc.: <type>
  • The computers MAC address: <MAC>
  • Asset tag: <asset tag>
  • Make/Model: <model>
  • The name of the user who owns/uses the machine: <username>
  • The department it belongs to: <dep>
  • A running number: <n>
  • The OS the machine is running: <OS>

You can combine these any way you want; using hyphens or other separators, or not. Here are a few I often use:

  • <org>-01234 (eg. BigFirm-56798)
  • <org>-<type>-01234 (eg. BigFirm-l-87980)
    V=Virtual
    W=Workstation
    L=Laptop
    K=Kiosk
    etc.
  • <org>-<asset tag> (eg. BigFirm-A5B98)
  • <org>-<MAC address> (eg. BigFirm-AABBCCDDEEFF)
  • <org>-<model>-01234 (eg. BigFirm-HP8100-89476)
  • <org>-<username>(-<type>) (eg. BigFirm-BobH-V)

If you have any suggestions of either complete schemes or things you like to include in your machine names, please leave a comment and I will update the article.

Also, remember that Windows computers use both DNS hostnames and NetBIOS names. NetBIOS names are limited to 15 characters, but DNS hostnames are not. Windows will not stop you from using names that are longer than 15 characters, but the NetBIOS name of the machine will be limited to the first 15 characters of the name you choose. If the part of your name that makes it unique is beyond the 15th character you will have more than one machine on your network with the same NetBIOS name. Furthermore, although Windows itself will work with a name longer than 15 characters, many tools will not. An example of this is MDT 2010.

Happy naming!

Some thoughts on Active Directory OU structure design

Over the years I have been involved in quite a few Active Directory deployments and restructures. On these projects much time is always spent, or should be spent, on designing the OU structure.
The main thing about OU structure desing is to keep thing simple. Some organizations like to take the organizational chars and copy that in AD. Chances are that that structure will not be very useful for the people whose job it is to manage the network. They need an OU structure that reflects groupings of users, computers, groups and servers which have the same management and configuration needs.
There are many approaches to the design process. Eg. geographical where your OUs reflect the geographical locations of your company or users and computers. Functional; which organizes users by the function they have in the company, for example Sales users etc. A much used variant is one where some or all of the regular approaches are combined, for example geographical and functional.
Now, let’s consider an example. You have been charged with designing the OU structure for a large school or university. You decide that you want to use the functional approach and decided to create two main OUs to hold all your user accounts. The OUs will be called Students and Teachers. Upon first inspection this would seem to work well. You would be able to manage all your student users easily, same for teachers. But what if you have a user who works at the school as a teacher but would also like to attend courses or classes? (I assume here that we want to honour the principle of one user, one account.) That user should be treated as a student at one point, but as a teacher the next. Clearly our OU structure is not cut out for this. You could try to classify the user further and determine that he or she is mostly a teacher or mostly a student, but you probably do a lot of stuff based on which OU the user resides in, so you will eventually run into trouble. Not all your users will fit neatly into your two categories.
The problem here is that OUs are exclusive. You can only be located in one at any give time. So our desing here does not fit users that have dual identities. We have to come up with something that caters to this need. Back to the drawing board.
On our next try we start out with just one OU called Users. (Yes, I know there is already an object in Active Directory called Users, but that object is a container and we are creating an OU so that is not a problem.) In this OU we put all users regardless of their role or function. We now create groups to identify the needed roles. One group for students and one for teachers for example. We add all students to the Students group, all teachers to the Teachers group and users who are both to both groups. We now use Group Policy filtering to apply our GPOs to the correct group. A GPO that configures settings for students is filtered on the Students group, likewise for teachers. The GPO links that give the most access or have the least restrictive settings, should have a higher priority than more restrictive GPOs. That way if a user is a member of two or more groups with different access levels he or she will get the least restrictive settings.
Contrary to OUs, groups are inclusive, you can be a member of more than one. This lets your users assume several identities and get access to information and settings available to both.
I realize this approach is contrary to many accepted “truths” about Active Directory design, such that your should try to never filter your GPOs, but with the tools like GPMC it is very easy to see where your GPOs are linked and how they are filtered.