Warning: My brain is thoroughly fried from two consecutive days in a shopping mall, bad weather, an annoying former cell plan provider, and a busted tooth. I may tend to ramble. Just drink something and it’ll be over soon.
In part 1 of this endeavor, I covered a bit of the pre-staging side of inventory data collection. I didn’t go that deep obviously, and I’m certainly not going to dive into the realm of I/O Differential or any financial stuff. But I do need to revisit something I mentioned earlier, just for a bit, in the area of basic data structures, and how WMI fits within it. I will pick back up on the final leg of this in part 3 (importing the data into a database).
Some aspects of a computer device involve multiple instances of a given class instance, while other are ultimately a single instance with multiple attributes (not that each instance of a multiple result doesn’t also have multiple attributes, but please, keep drinking and I’ll keep blabbering, trust me…). For example, when gathering Windows Services (Win32_Service), you’re looking for rows of instances (each being a service), and compiling the Name, PathName, StartMode, Status, and so on.
However, for Operating System (Win32_OperatingSystem), you’re almost always looking for one instance per device. Granted, a physical host can potentially be associated with multiple virtual guest machines, but even in such a scenario, the guest machines will likely have distinctly different hostnames than the physical host. So, in this class instance, you’re likely going to collect one instance (pardon the redundancy for a bit), and grab a ton of its attributes (Name, InstallDate, SystemType, OperatingSystemSKU, CSDVersion, etc.)
For that reason, I decided to treat such classes as I would other collectives such as Win32_Product, Win32_LogicalDisks, and so on. So, rather than go nuts with building in an abstraction layer of configuration settings (another XML file with names of which attributes to gather), I’m going with the shotgun+liquor+ATV+explosives approach and just grab it all.
In other words, my database table structure will contain all of the attributes for the respective class, and tack on a unique row ID column and datestamp column. For entertainment value, I also tacked on a “ComputerName” column. I’d use “DeviceID” but it’s used by the Win32_DiskDrive class already, so I’d rather stay out of it’s way. For storage and index efficiency I’d recommend converting Boolean values into integers, and larger integers (like TotalPhysicalMemory) into BigInt or something like that, or just pre-chew them like momaa birds do and crunch 434234234234 into 4096 or something less bloaty. Precision should be your guide, so don’t let me tell you which is best.
At this point, my client data collection script (dpms_inventory.vbs) reads from a configuration XML file for items which are single-instance oriented, like Win32_OperatingSystem, Win32_BIOS, and Win32_SystemEnclosure. The others, like Win32_NetworkAdapter, Win32_LogicalDisk, Win32_Product, and Win32_Service, will just suck it all in like a drunk Senator at a Vegas strip club.
The other XML configuration files I will use are for controlling collecting Registry and File instances, and another for data collection beyond WMI, such as special Folders, Shortcuts, and so on.
Boiling this all down…
When pulling inventory, I would start with a basic footprint and build on as needed. No need to go to the extent of what Microsoft System Center Configuration Manager collects, at least not initially. Some of what is technically identified as “hardware” related (see link) I questionable, such as Disk Partitions, which are not physical, hence “hard” in “hardware” and well, whatever. I decided to “normalize” the relations by splitting those things out as “system” rather than “hardware”. And even “shares” seem to fall on the fence a bit (see link). Call me nit-picky.
- Hardware Inventory:
- System Inventory:
- Software Inventory:
And you thought all this techy nerdy geeky stuff was going to be all techy, nerdy and geeky. Pfffft! Anyhow, I know this is dry, so I’ll wrap it up.
In the end, as my script churns on a given device, it will eventually dump multiple inventory output files. Each will be in XML form (DOM-style, with fries and ketchup). Each will be uploaded to a central share, and from there, will be picked by another process like those nasty-looking bots in the Matrix, which unplugged Neo and flushed his ass down the toilet of reality.
Why the Two-Step?
Why don’t large arenas just open every portal and let everyone rush in as they please? Why don’t movie theaters and night clubs do the same? Because humans need some order in a chaotic world. It also helps with insuring things flow in a predictable manner and therefore provide a more manageable “model” which can be maintained and optimized based on predictive analysis. Big words go with beer like peas and shovels. Or is it carrots and hammers? I can never get those right.
Cheers. I will wrap up part 3 soon.