A hardware inventory extension for HALs

pthomsen — Mon, 07 Apr 2008 01:52:00 GMT

Summary: here's a technique for collecting details about the HAL used by your computers. Do you need to know which Hardware Abstraction Layer (HAL) your clients are using? For example, you may wish to ensure you're using all features (such as multiprocessors).

This solution is from a couple of years ago, and I don’t know if I had the optimal method (or whether it’s still optimal), but research at that time indicated that the following was necessary, and I don't have reason to think there's a better solution:

1. Do a binary file open of %windir%\system32\hal.dll
2. Find the original HAL name in the file
3. (optionally) translate that into a meaningful name (if I remember right, there were only a couple that were common, and of course things may have changed over the last couple of years) (code snippet below)
4. Write the results to a custom WMI data class (or a registry entry)
5. Collect the results using typical SMS/ConfigMgr hardware inventory extension methods

Tricky, but not bad.

                'HAL descriptive name
                if HALname="halmacpi.dll" then HALdescr = "ACPI Multiprocessor PC"
                if HALname="halaacpi.dll" then HALdescr = "ACPI Uniprocessor PC"
                if HALname="halacpi.dll" then HALdescr = "Advanced Configuration and Power Interface (ACPI) PC"
                if HALname="halsp.dll"    then HALdescr = "Compaq SystemPro Multiprocessor or 100% Compatible"
                if HALname="halapic.dll" then HALdescr = "MPS Uniprocessor PC"
                if HALname="halmps.dll"   then HALdescr = "MPS Multiprocessor PC"
                if HALname="hal.dll"      then HALdescr = "Standard PC"
                if HALname="halborg.dll" then HALdescr = "SGI mp"

p.s. Here’s some resources on the topic:

• http://support.microsoft.com/default.aspx?scid=http://support.microsoft.com:80/support/kb/articles/Q237/5/56.ASP&NoWebContent=1
• A script class to read file version information: http://www.jsware.net/jsware/scripts.php3 (under File Version Information Class) (I don’t know if there are licensing issues)
• http://www.microsoft.com/resources/documentation/WindowsServ/2003/all/deployguide/en-us/Default.asp?url=/resources/documentation/WindowsServ/2003/all/deployguide/en-us/acicc_ris_jfxo.asp (you’ll have to dig a bit)

A hardware inventory extension for ActiveX controls

pthomsen — Thu, 06 Mar 2008 03:55:00 GMT

Summary: here's a technique for collecting details about ActiveX controls on your computers.

Do you have a need to inventory the ActiveX controls on your computers? Collecting details about ActiveX controls is not trivial. Many have a .OCX extension, but not all of them. And even if you find them on disk, are you confident they've been installed for use? So a simple software inventory rule won't do the trick.

I built an SMS / ConfigMgr hardware inventory extension for ActiveX controls a few years ago, and a little research today didn't reveal a better solution. If you have one, I'd be pleased to hear about it (as would others, I'm sure).

The solution basically involves sending a script like this via software distribution to your clients:

set fso = CreateObject("Scripting.FileSystemObject")
Set Appshell = WScript.CreateObject("Shell.Application")
Set folder = Appshell.NameSpace( windir & “\Downloaded Program Files")
Set items = folder.Items
For Each item in items
version="" : if item.path<>"" then version = fso.getfileversion(item.path)
wscript.echo item.name, version
Next

The "Downloaded Program Files" can look like an ordinary folder (depending on how you look), but it's actually a special object that is used to manage installed Active X controls.

The script for your hardware inventory extension will be a little more complex than the code sample above. Rather than displaying the control name and version, you'll need to write it to a custom WMI class, and get SMS or ConfigMgr hardware inventory to collect that WMI class. That's a bit of an art in itself, but I hope it's well described in this chapter of the SMS 2003 Operations Guide:

http://www.microsoft.com/technet/prodtechnol/sms/sms2003/opsguide/ops_0351.mspx?mfr=true

One concern with the solution I suggest is whether all ActiveX controls end up in that "Downloaded Program Files" object. Maybe only Internet Explorer ActiveX controls make it there. I really can't confirm that either way. If that's an important scenario for you, and you have non-IE ActiveX controls, it would be worth testing (and let us know).

BONUS MATERIAL: do you need to run scripts that use 32-bit objects on 64-bit computers. That's the case here, where "Shell.Application" is 32-bit only. It doesn't error out, but it doesn't return any results on 64-bit computers. When that's the case, you should run the script using the 32-bit version of cscript.exe, like so:

%SystemRoot%\syswow64\cscript.exe script.vbs

p.s. An alternate solution for this hardware inventory extension is to use the MicrosoftIE_Object class from the root\cimv2\Applications\MicrosoftIE WMI namespace. Even “the Scripting Guy” suggests it: http://www.microsoft.com/technet/scriptcenter/resources/qanda/dec04/hey1220.mspx. But that namespace doesn't seem to exist on Windows Vista or Windows Server 2008 computers, so it no longer seems to be a viable option.

Paul Thomsen at myITforum.com : hardware inventory extensions

A hardware inventory extension for HALs

A hardware inventory extension for ActiveX controls