I recently had a situation working with a client where the root discovery in the Dell Server Management Pack 4.0 failed silently…very silently. So silently in fact that no script failure was generated, no alert logged. Nothing but the quiet hum of crickets and tree frogs outside my window. So I did what anyone would do…I dismantled the Dell management pack and started digging in to see how this MP really works. And I found an undocumented discovery logging function you may be interested in.
I exported an unsealed copy of all the Dell 4.0 MPs to a workstation with the necessary tools for a deep probe into the pack: The MP Authoring Console, MP Resource Kit Tools, an MP Viewer and an XML editor.
Identifying the Chain of Discovery
Here are the packs in the Dell 4.0 Management Pack Suite you need to look through to find the base discovery.
HINT: It’s in the Dell.WindowsServer.Scalable MP.
Dell Windows Server Overrides MP provides enabling of all informational alerts.
|Dell.OutOfBand.CMC||Enables SC Operations Manager and Essentials to more accurately depict the status of Dell CMCs and Dell Modular Chassis Remote Access Controllers on a defined network segment.|
|Dell.OutOfBand.DRAC||Enables SC Operations Manager and Essentials to more accurately depict the status of Dell Remote Accesss Controllers on a defined network segment.|
|Dell.WindowsServer.Detailed||Imports over the Dell Windows Server Scalable Edition MP to provide detailed management by including even instances of the hardware components. Builds on the scalable pack with additional class definitions, discoveries, rules and monitors for detailed hardware monitoring.|
|Dell Server MP v4.0 Scalable edition provides bare critical management and is scalable in large deployments. Contains class definitions, discoveries, rules and monitors for basic hardware monitoring|
|Dell.Connections.HardwareLibrary||provides the high level hierarchy of view folder structure and root group for the Dell Management Packs to rollup hierarchy and health. Just the folders|
The Root Discovery
The root discovery is called Dell Server Discovery and it is targeted to the Windows Computer class….so it’s going to run on clients and servers. It’s a script-based discovery. Fortunately, it only runs once a day by default.
You’ll notice you can actually set the minimum OMSA version in this script. OMSA 5.3 – 6.1 are supported, but I have seen some 10th generation blades for which OMSA 5.5 revealed nothing, but OMSA 6.1 identified the hardware components as expected. The more interesting setting here is the LogLevel parameter. This apparently undocumented parameter is contained in the DellServerDiscovery.vbs discovery script located within a custom data source module.
While the the LogLevel parameter is undocumented, within the discovery script we can see that setting this parameter to any non-zero numeric value enables discovery logging to the Discovery_DellServer.log file in the %windir%\temp directory. Setting LogLevel to 1 will suffice in order to start logging. You can see from my example that for testing purposes I also turned discovery down to a very low level. Don’t mess with this setting in production!
This is the output on a system on which the script runs successfully but on which OMSA is not installed.
6/3/2010 11:34:46 PM —- ——————————————————
6/3/2010 11:34:46 PM —- INFO: Script – Dell Server Discovery : Start()
6/3/2010 11:34:46 PM —- INFO: Script – Arguments: Computer, minOMSAVersion = 6422-Hyper-V.Contoso.com, 5.3
6/3/2010 11:34:46 PM —- INFO: HardwareManufacturerName Name retrieved successfully
6/3/2010 11:34:46 PM —- Hardware Manufacturer Name query : Dell Inc.
6/3/2010 11:34:46 PM —- INFO: System model type object retrieved successfully
6/3/2010 11:34:46 PM —- INFO: Function: Dell System Model : Latitude E6500
6/3/2010 11:34:46 PM —- Hardware Model query : latitude e6500
6/3/2010 11:34:46 PM —- INFO : Script – Dell Server Discovery : End()
6/3/2010 11:34:46 PM —- ——————————————————
Soon, I’ll be diving into this process on a set of servers for which discovery is failing, at which point we’ll have another look at the output under failure conditions…And then we’ll move through a few more layers of discovery, monitoring, tuning, etc.
To be continued….