HP DDMi – poking under the hood

Currently working with DDMi 9.3 or, PDI version 7.6

Delivering license compliance using HP DDMi : Getting the raw data

I’ve worked with what is now HP DDMi since 2001, not long after Peregrine bought it from FPrint. It was IDD back then, then PDI, now it’s in DDMi.

From a tech perspective, the resulting scan files are a goldmine of information and is perfect for supplying raw data for the purpose of license management. It’s probably the best inventory tool out there but the software recognition is dated and cumbersome. HP license compliance is no good beyond the desktop either so you need something more aligned to delivering license management than asset management such as Aspera SmartTrack, which DDMi feeds nicely into. I’ve repackaged it so it scans Oracle databases for options. I’ve hacked the file format so you can inventory legacy equipment and bring the results back for enriching into HP Asset Center. Clients can now scan any hardware or create scan files from spreadsheets etc.. I’ve secured it on Unix platforms ‘cos admins tend to freak when you tell them it needs root access to work properly!!!

Most of my work with DDMi is now post install or helping HP, working with the data to help clients quickly get to compliance reporting. Anyone out there involved in an implementation and rollout of DDMi with a view of using it for license management with HP technology? You need to speak to me, or see you in a couple of years when you find it doesn’t work!!!! Especially complex license models around cloud, VM and data centres.

For compliance sake

Currently, I have a need to process the raw scan files out of the native XSF and into any system the client has. This allows your process to hook into the data flow and supply whatever process or tool you have that needs raw hardware, OS installed applications or file information, straight from the XSF file rather than the DDMi server after it has processed the data. You can load the XSF inventory straight into any SQL server or flat files making it really easy to integrate.

Why? because HP software recognition is a little bit pants. BTW you can automagically generate software recognition files for Unix by using the host packaging commands to tie the files to applications into an SAI file. You can recognise Unix applications quickly rather than use the manual Analysis Workbench approach.

If you didn’t know, the DDMi scanner produces a scan file with the results of a hardware and software audit of the device you scan, one file per device. This file has the file extension XSF which is in fact a gzipped XML file which can be uncompressed in Windows using 7-Zip. This is really handy data which is easy to uncompress and work with. The problem is the Windows scan and the Unix scan have different schemas. This is understandable as they’re different platforms. I use the DTD for writing applications to handle DDMi XSF files

Unix

<hwOsData type="shell">
 <hwHostOS type="attrib">Solaris 10</hwHostOS>
 <hwOSServiceLevel type="attrib">11/06</hwOSServiceLevel>
 <hwOSHostOsCategory type="attrib" value="3">Unix</hwOSHostOsCategory>
 <hwOSHostUnixType type="attrib" value="0">Solaris</hwOSHostUnixType>
 <hwOSHostVersion type="attrib">10</hwOSHostVersion>

Windows

<hwOsData type="shell">
 <hwHostOS type="attrib">Windows 2003 Server Enterprise Edition </hwHostOS>
 <hwOSBaseDir type="attrib">C:\WINNT</hwOSBaseDir>
 <hwOSServiceLevel type="attrib">Service Pack 2</hwOSServiceLevel>
 <hwOSBuildLevel type="attrib">3790</hwOSBuildLevel>
 <hwOSHostOsCategory type="attrib" value="2">Microsoft Windows</hwOSHostOsCategory>
 <hwOSHostWindowsName type="attrib" value="12">Windows 2003</hwOSHostWindowsName>
 <hwOSHostWindowsNTMode type="attrib" value="9">Server Enterprise Edition</hwOSHostWindowsNTMode>

The DTD’s

So here are the DTD’s (old skool I know) for both platforms I created to auto transform the inventory into CSV files or SQL for hardware, ARP and file data feeds into better recognition processes for compliance reporting.

DDMi_Unix_DTD

DDMi_Windows_DTD

And if you don’t want them in seperate files, I’ve combined both platforms into a single DTD so you can process both platforms from the same file, here is the file with both schema combined into a single DTD. These are not HP files in anyway, I’ve built them from XML data I receive, so they might be missing elements which are not on the hardware I’ve scanned. The Unix DTD does include “Solaris Zones” so you can see which zone is hosted on which server and if the zone is up or down. My process also creates a relationship feed so VM compliance can be achieved easily.

DDMi_DTD << old file, use the latest DTD in the update part of this post.

Next step is to process the XFS files to get the data out using either Windows or Unix/Linux.

Why use Document Type Definition (DTD)?

I have clients that have legacy equipment they want to include in their IT Asset Management processes. The new inventory tools don’t take into consideration old devices so they get left behind, waiting to be updated. However, the cost of updating legacy equipment is prohibitive. Using HP DDMi you can read scan files and create scan files from pretty much any data source.

This is how I used my DTD to create XSF’s.

  1. Create a database for legacy equipment and publish a web interface to it.
  2. Populate the database with hardware and software from any source you want such as text files or physical audits.
  3. Using the DTD, output the data into XSF files.
  4. Process the XSF files as if they were created by a scanner.

And to get data out of the XSF

  1. Uncompress the XSF to clear text XML
  2. Using the DTD, write a script to extract the data (some logic required I’ll cover later)
  3. Format the data or load into you solution (I compiled into an executable that extracts to CSV, very fast and efficient)

Update 21/11/2011

Thanks to a few people sending me their XSF’s to examine (one was 104Mb !!!!) I have added a lot of missing elements. Also, I’ve made the ‘inventory’ attribute ‘locale’ optional by changing the #REQUIRED to #IMPLIED, also made optional the ‘accessed’ attribute in ‘file’ as the UNIX scans don’t have this attribute.

Update 23/11/2011

Some people have issues with having so many elements and attributes that are required. The problem with DDMi scan files is that they’re all different depending on what platform is being scanned and what information is being found and inventoried. I’ll go through how I get the data out as it will vary between scan files and platforms. If you have a scan file that you can’t process with my DTD, drop me a message and I’ll take a looksee.

Updated DTD here DDMi-111122

4 Responses to “HP DDMi – poking under the hood”

  • Aja Strizich:

    What’s up, after reading this awesome piece of writing i am too delighted to share my knowledge here with colleagues.

  • A Brave New World:

    Only the best….

    Hi there, after reading this amazing paragraph i am too cheerful to share my know-how here with mates….

  • Peter:

    Just curious as to how you secured it on a Unix platform?

  • Sim:

    Hi Peter,

    The scanner is required to run with root privileges to execute properly and gather all the inventory it can. On Windows you’ll see some odd behaviour with the agent and scanner if it doesn’t have admin privileges. Every customer I’ve worked with doesn’t allow root access for security reasons.

    Also, deploying to 15,000 Unix servers is not something you want to do manually. To get around this, you need to repackage the agent and scanner, so when the agent is deployed from a deployment tool, it uses a local user account to install the agent, but the scanner is run with sudo so it executes with root privileges, and only from a set location which is set in the sudoers file. These restrictions normally keep the security teams happy.

    No need for an admin type user account to deploy, no root passwords or access required to scan.
    It’s a shame the ability is not included with DDMi.

Leave a Reply