August 16, 2008: Computer Description
SF-DC-01.
Many organizations name their computers (or at least the servers) like this. LOCATION-PURPOSE-NUMBER or similar. So the above would be a server in San Francisco, primarily tasked with being a domain controller, and having the number 01 just to differentiate it from any other domain controllers in SF. Personally, I am not a fan of name schemes like this, because they suffer a number of naggy little issues:
- Systems change over time. If SF-FS-01 (a fileserver) gets an AV signature server service added to it, do we have to rename the server to SF-FSAV-01? Or do we just live with the idea that our names aren’t as descriptive as they used to be?
- The computer name field is short. 15 characters is all you get. So you end up with rather cryptic names which can be …
- Hard to pronounce. If I’m talking to the guy in our (loud!) SF data center, and asking him to reboot SF-DC-01, but he instead reboots SF-BC-01, avoidable hilarity may ensue!
- Names become increasingly more cryptic, or people don’t apply them correctly. Some servers are SF-xx-xx, some are SFO-xx-xx. And what do we do about the servers in Redmond, WA, versus the ones in Redmond, OR? Or the fact that we now have two locations in Chicago?
- Name schemes paint us into corners when unexpected situations arise. Do we amend the name scheme and rename all systems to reflect the changes? Or do we live with the fact that we now have two or more different name schemes … and we can’t be sure which is which?
Which brings me to the point of this little article. You can use the Computer Description field to hold all that metadata:
Now from the commandline, with net view, you can do some neat stuff:
Notice how, by piping the command through a findstr, I was able to pull out just the Windows 2003 systems. Obviously there are many other ways I could use this to locate systems of interest. The other thing to notice is that now, names don’t do anything other than make a computer uniquely addressable. We can choose easy-to-pronounce names, and we can let employees name their own systems. The ‘name scheme’ has really moved to become a ‘description scheme’ which is much more flexible because we can change descriptions without changing the address of the computer. Also, since descriptions can be longer, they are easier to read and easier to search. And if our description scheme needs updating later on in life, it will be relatively easy to reset the description field for every system we have. So we can easily escape any corners we might paint ourselves into.
There are a few things to keep in mind. First, the Computer Description field can hold a lot of characters. I gave up counting when I got over 200 chars on a Windows 2003 system (via the dialog shown above), and Microsoft’s documentation of the registry value where this is kept gives no maximum limit. BUT, and this could be a showstopper, KB231312 documents a ‘by design’ 48 character limit, and KB932762 documents a (patchable) issue where descriptions larger than 48 chars could crash the Server service, on which many other services depend. It is not 100% clear whether this patch has been pushed out via the normal Windows Update mechanism, so I recommend staying under 48 chars in your descriptions.
Also, setting the computer description does not necessarily update the description field in Active Directory Users and Computers. I don’t think it would be to hard to write a script which gets all localcomputer descriptions, then updates AD with these values. You could run such a script daily or weekly. I don’t feel like writing that script at the moment, but if anyone asks (via comments), I just might be convinced to do it.
Finally keep in mind that unless you are running WINS, these computer desciptions will not be available for systems outside the subnet you are on. So that might be a good reason to either run WINS, or whip up the script I described above.
But what about non-Windows systems? Well, the various *nix OS’s can all run Samba, but using Samba just to publish system description fields is probably a bit of overkill. You could explore using MOTD, or QOTD to hold that information. Or perhaps TXT or SRV records in DNS.
Wrapping up: I think computer naming schemes usually look good when we’re thinking them up, but without iron-fisted control, often devolve into a sort of ratty and not-always-reliable mess as time goes by. Maybe we should just free ourselves from them entirely!