In today's IT scene, it is important to know which products are enterprise ready. Cliff Wells provides a useful evaluation of certain popular technologies. He also sets the baseline for what enterprise ready really means. Go see if your technology is Enterprise Ready.

Love or hate Dell, they do do a few things right. They provide a Service Tag on every PC with which you can get a host of information off their support site. Drivers, manuals, you name it. The service tag is generally on a little black tag someplace on the case. On the tag there is also an Express Service Code. If ever you call for tech support on your Dell computer, you will be asked to enter this number to route your call correctly. Now, you don't actually need it, but it is handy to have.

The service tag is in the BIOS and can be extracted fairly easily, at least from a windows machine with WMI enabled. A simple little python script to do so would look like:

import win32com.client as w32c
comp = "."
wmi = w32c.Dispatch("WbemScripting.SWbemLocator")
wbem = wmi.ConnectServer(comp,"root\cimv2")
colItems = wbem.ExecQuery("Select * from Win32_SystemEnclosure")
for chassis in colItems:
    if 12 in chassis.ChassisTypes:
        continue
    print ("Service Tag: %s" % str(chassis.SerialNumber))
    continue

Not bad. Looks almost identical to it's VBScript counterpart

Now, the real question is: If I have the service tag, but not the express service code, how do I get the express service code?

Good question. There are a few tools^{1 2} online that will generate an Express Service Code from a service tag.

Digging a bit deeper, we find that the service tag is simply a base 36 number. We also discover that the express service code is simply the bae 10 representation of the service tag. Ah ha! We can handle this! We could always use VBScript to do the conversion³. But that would be too easy, so we'll use Python

print ("Express Service Code: %s" % str(int(service_tag,36)))

Tough, wasn't it?

I like Trac. That may have been obvious due to hosting the logs for the IRC channel. Or the fact that this site runs on trac¹. The simple fact is that Trac is just plain hot.

In my day job, I have the wonderful opportunity to manage two similar, but distinct networks. All-in-all, it's not so bad. However, the older of the two networks, suffers from severe lack of documentation (left to me by The Predecessor). The newer network is still in its infancy. So while there is more documentation, it's still not complete. What's more challenging, is keeping the documentation that is there, up-to-date. Add to this the fact that I really hate "documenting" and it all adds up to a mess.

I've been thinking to myself: "Trac is hot, and documentation is good. There must be some way to merge documentation of a network with Trac". Now, it's easy to say: "Well, Trac has a wiki, just keep the documentation up to date". Great idea, except for the fact that I hate "documenting". On top of that, when things are busy, adjusting documentation is that last thing that I do (and first thing I forget to do).

I agree that Trac is a great start. It's got ticketing, a nice easy wiki, source control integration, just about everything one needs to have good documentation. However, it's lacking the automation. This isn't really Trac's fault, as that's not what it was originally designed for. However, it fits so well, and Trac has such a nice plugin system, it's just begging to be extended.

To this end, I will be starting a Trac network documentation project. Originally, it will be focused on managing a Windows environment with Dell machines, as that's what I'm dealing with. However, I will try to make it general enough to be used in a different network. Some of the features I'm planning are:

• Automatically pull system information and populate wiki pages. This will include the Dell Service Tag, machine specs, IP information, etc.
• Association of Asset numbers with wiki pages such that one can reference a machine via asset tag, or search via asset tag and get the relevant info
• Security for the wiki such that user accessible pages can be created for HOWTOs and other organization wide information
• Ticket security such that a user can only see their own tickets
• Automatic tag creation such that each user/system has a unique tag that can be used across the site
• Aggregate other system info such as:
  • Mail logs
  • Backup logs
  • Anti-virus logs

Basically, the Trac site should be a one stop shop for any network info that is required, be is software licensing, network diagrams, system information, etc.

If this is a project that you'd be interested in, especially if interested in helping out, drop me a line. pacopablo AT pacopablo DOT com

I'll keep you updated.