Suppose that your organization had a mouse crisis: your human resources folks declared that all users must have one of three ergonomic pointing devices on their computers. So now you need to know just what kind of mice are on all the Windows workstations and laptops. This is not part of the out-of-the-box information that Discovery finds, so how could you add it? Read on and see...
To get that information, here's what we're going to need to do:
- Determine what information is available: Since we're going to look for mouse information on Windows computers, that means we'll be using WMI to find the information. Therefore we need to do some research into what information WMI has about mice.
- Add mouse information to the computer record: The CMDB, out-of-the-box, doesn't have a place for mouse information in the computer record. So we'll add it!
- Create a mouse probe: To get the mouse information, the first step is to ask for it. Our new probe will demand the mouse information from a Windows computer.
- Create a mouse sensor: Once we have the mouse information, we need to put it into our computer record. Our new sensor will read the mouse information supplied by the probe and use it to update the computer record in the CMDB.
- Tell Discovery to use the new probe and sensor: Discovery won't start using our new probe just because we created it. So we'll tell Discovery exactly when to use the new probe.
- Run a test Discovery to see if our new probe and sensor work: Always test!
Microsoft's MSDN site documents the Win32_PointingDevice WMI class (along with all the other WMI classes). After looking at the Win32_PointingDevice class and thinking about our requirements, we decided we'd look for these pieces of information:
- Win32_PointingDevice.Name
- Win32_PointingDevice.Manufacturer
- Win32_PointingDevice.DeviceInterface
- Win32_PointingDevice.PointingType
These are arbitrary choices on our part; we could have chosen any of the information available from WMI.
To add the mouse information to the computer record, just navigate to any computer form, personalize the form, and add the fields you want. The example at right is what our new form looks like. Two of the fields we added have numeric values (as reported by WMI) that correspond to human-readable values (as documented in the Win32_PointingDevice class). We created these new fields as choice lists, entering all the possible numeric values that WMI reports — and then we customized the labels to show the human-readable values. Perfect!
Next we added a new probe. This is very straightforward, as you can see in the image at left. Just navigate to Discovery Definition→Probes, click the "New" button, gave it a name, filled in the WMI class and properties we need to query, and we're done!
The sensor is only a bit more challenging (see ours at right). First we navigated to Discovery Definition→Sensors and clicked the "New" button. Then we gave our brandy-new sensor a name, and (very important!) selected the probe that this sensor should respond to (Windows - Mouse). The most interesting part is the script. The way JavaScript sensors work is quite simple: the process (highlighted in green) function gets called for each result returned by the probe. In the case of our probe, it's actually possible to get multiple entries (if the computer has more than one pointing device), but they are returned as multiple entries within a single result. For example, laptops often have a touchpad built in, but might optionally have a USB mouse attached. Such a system will return a single result tag, with two Win32_PointingDevice tags contained within it. We decided to keep things simple with our sensor, and just take the first result, whatever it was. The code highlighted in red does exactly this: it first calls the g_array_util.ensureArray() method to convert the result to an array of individual mice, and then takes the first one as the mouse that we will store in the computer record. This logic could easily be modified to (for example) take a mouse over a touchpad. Finally, the code highlighted in blue simply pulls the data out of our selected mouse and stuffs it into the current record, which is the CMDB record for the computer being explored. That's it for the sensor...
Now we had to tell Discovery that we actually wanted to use the new probe and sensor. First we navigated to Discovery Definition→Windows (in the Classification section). This showed the list at left. 
Then for each of the entries in that list (except for the Windows Cluster entry), we drilled in and added our new probe to the list (see example at right). We did this by clicking on the "Edit..." button and double clicking on the Windows - Mouse entry on the left (which moves it over to the right). With that, we've now told Discovery to use the new probe and sensor.Finally, we ran a test discovery. In the case of this simple little probe and sensor, it all ran correctly the first time. For most of our Windows CIs, we could see mouse information. In some cases we didn't get any information; these turned out to be servers that truly didn't have any pointing devices attached. One little surprise we got was that many of the CIs (like the example toward the top of this post) reported "Microsoft" as the manufacturer and "PS/2 Mouse" as the name, even when this wasn't true. It turns out these were generic mice that just used the standard out-of-the-box drivers, and they all get reported the same way.
In talking with our customers, we've found that the needs people have for additional information are as diverse as our customers are. It's actually quite rare for us to hear two customers asking for the same thing. Some of our customers have already dreamed up some interesting probes and sensors that are proving useful in their environments — and the more success they have, the more ideas they come up with.
Now it's your turn! What information would you like Discovery to find?
1 Comment
