If you've done any scripting to customize your Service-now instance, you've probably run into a system identifier (sys_id) or two – those funny-looking values like “46e2fee9a9fe19810049b49dee0daf58”. That's a unique 128-bit number expressed in hexadecimal, otherwise known as a GUID (and I'm not talking about the Guid Sisters!). If I'm speaking gobbledegook, read on for an explanation...

I've written about serial numbers before, and even mentioned the invalid serial number table (Discovery Definition → Invalid Serial Numbers). Like the soldiers at right take care of the bad guys to keep us safe, the invalid serial number table takes care of the bad serial numbers in your environment to keep your CMDB clean. Here I'll show you how to add your own entries to this table, to handle the bad serial numbers you find.

You've probably heard that astronomers have changed Pluto's classification from “planet” to a mere “solar system body”. Though this happened a couple years ago, there's still considerable debate about how to classify Pluto. But unless you're a scientist working in astronomy, you don't have any say about it.

Discovery lets you completely control how processes get classified. This may not have the romance of classifying a rock twirling around our local star, but at least it's something you can control!

Many folks use Discovery as the sole means of populating their CMDB in Service-now. But if you're one of those who also imports items into your CMDB, or who manually enters CIs into your CMDB, CI Consolidation is for you. It can also help in situations where equipment is frequently repurposed, is given new IP addresses, or when you identify your equipment in some way differently than Discovery normally works.

Have you wondered how Discovery can figure out that one system (perhaps an accounting application) is related to another (such as the database used by the accounting application)? I've been asked this question many times. It isn't magic...

There's an old saying with several variations, most of which are about like this:

For instance, I'm pretty certain the fellow at right is related to someone who rues their inability to choose.

I got into a little debate with an HP partner on the NetworkWorld community about what HP means when they use the term 'SaaS'. From talking to their former customers and by reading between the lines, we know that what they are really selling is the same old legacy applications served up by an application service provider.

Port probes… Doesn't this sound like something unpleasant, possibly involving rectal thermometers? Don't worry, they're not as bad as all that. In fact, they're pretty darned useful – and quite fundamental to Discovery.

The basic idea behind a port probe is to take some simple steps to see what kind of a device might be lurking at a particular IP address. This is the second step in discovery for any particular IP address, right after ping detects that an IP address is in use. The port probe gets its name from the fact that it checks ports (specifically, TCP and UDP ports) to see if the device at a particular IP address is listening on them. From the results, Discovery makes an educated guess about what kind of device is at that IP address.

Frankly, we've been quite surprised just how much NetWare is still running around enterprises. Quite a few of you have asked if it might be possible for us to support NetWare – even if all we did was to detect that it existed. Well, you've got your wish: Discovery now (starting with the Winter 2009 release) supports NetWare, pretty much just like any other server.