Monitoring a Windows system using SNMP is a way to retrieve information about the system from a non-Windows system. You might run into a small problem with the HP Proliant Support Pack agents and the SNMP agent of Windows however.

We assume you have sucesfully configured the SNMP community string and allowed remote hosts on your system. Just to be sure, you could confirm this by snmpwalk-ing your own system. If the SNMP service is configured properly, you should get your operating systems information.

However, if you are not able to query the HP specific information, which is of course the most interesting part of your system, you might have run into some sort of bug in the HP Proliant Support Pack.

To be able to monitor this information, you need at least to have the HP monitoring agents - you can easily check this using PowerShell:

PS C:\> Get-Service -Include ("CpqNic*","Cq*","Cim*")

Status   Name               DisplayName
------   ----               -----------
Running  CpqNicMgmt         HP Insight NIC Agents
Running  CqMgHost           HP Insight Foundation Agents
Running  CqMgServ           HP Insight Server Agents
Running  CqMgStor           HP Insight Storage Agents

After you have made sure these services are installed and running it is likely the SNMP extension agents have not been properly registered on your system. To fix this, just add your the HP extension agents to the registry, the following registry export was done on an Proliant Support Pack 8.25 installation:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SNMP\Parameters\ExtensionAgents]
"CPQHOSTSNMP"="System\\CurrentControlSet\\Services\\CqMgHost\\CPQSNMP"
"CPQMIB1K"="System\\CurrentControlSet\\Services\\CqMgHost\\Parameters\\CPQMIB1K"
"CPQNISNMP"="System\\CurrentControlSet\\Services\\CpqNicMgmt\\CPQNISNMP"
"CPQNICS"="System\\CurrentControlSet\\Services\\CpqNicMgmt\\Parameters\\NICMIB"
"CPQSERVSNMP"="System\\CurrentControlSet\\Services\\CqMgServ\\CPQSNMP"
"CPQSTORSNMP"="System\\CurrentControlSet\\Services\\CqMgStor\\CPQSNMP"
"CPQISCSI"="System\\CurrentControlSet\\Services\\CqMgStor\\CPQISCSI"

Restart your SNMP service after adding these registry entries and you should be able to query the HP SNMP agent information.

Windows has the ability to take snapshots of a filesystem - an exact representation of the filesystem at a certain point in time. Snapshots are handled by the Volume Shadow Service and are called 'volume shadow copies'. The Volume Shadow Copy system allows, with the help of several plugins, for such Windows features as "System Restore", "Previous versions" and consistent backups of for example an MS SQL Server database. Also a lot of fileservers are setup to create a shadow copy of the volume each several hours to allow for easier recovery of a single file.

Because most backup programs utilize volume shadow copies most Windows servers will actually use this feature in the background even though you might have never actually configured it on purpose. For each shadow copy which is made, this also creates an hidden device in the device manager. Hidden devices are visible by selecting the 'View' menu and then enabling 'Show hidden devices'.

However, sometimes you might end up in a situation where the original disks are not recognized anymore but you still have the volume shadow copy devices in your device manager, a situation which could happen when you perform an P2V conversion of a Windows system and decide to change the disk layout.

You might not notice anything strange because the devices will go "missing" and hence will not be visible in the default view. To show the devices, use the "devmgr_show_non_present_devices" environment variable as documented in Microsoft's KB article 315539, if you do you might see something like this:

And it might even keep going and going (the worst offender I have seen contained over 600 of these hidden, missing devices). Of course you want to clean them up, but as you will soon notice Device Manager is not the right tool for this. Fortunately, devcon is an console version of the device manager which can be used to do all sort of nice things, including cleaning up this mess.

Please note that you will be mass deleting devices from your system - do not proceed without understanding what below snippets actually do and without having a full and working backup.

First we run a command to list all of our shadow copy volume devices - we redirect to a temporary file so we can manually inspect the contents before massdeleting it:

for /f %i in ('devcon findall *VolumeSnapshot* ^| findstr /i VolumeSnapshot') do @ECHO %i >>vss.txt

Now, open the "vss.txt" file and make sure only VolumeSnapshot entries you want to delete are in this file - if you do not care about any of the volume snapshots and you have taken the precautions given earlier, you can proceed to delete all volume shadow snapshot devices.

for /f %i in (vss.txt) do @devcon remove @%i

Refresh the device manager MMC to make sure all volume shadow devices are actually removed.

Microsoft introduced something called "IO Prioritization" in Windows Vista and later operating systems. To quote Microsoft from I/O Prioritization in Windows Vista:

I/O prioritization improves the responsiveness of the system without significantly decreasing the throughput of the system.

I/O prioritization

This feature allows for any process, thread or individual file access to set an I/O prioritization hint. Five different I/O priorities are available in Windows but only three are usable for regular programs:

The default priority level is 'Normal' - any program which doesn't request a different I/O priority will use the normal I/O priority level. I/O priority levels above 'Normal' are reserved for system components and are not usable for a regular application. When a process requests a 'very low' (or idle) I/O priority, Windows ensures that the process' I/O is only processed after no other I/O is pending.

Running an application with very low I/O priority will make sure other applications will get their I/O handled before the I/O requests of the idle priority process is handled, this would lessen or even prevent I/O impact of the application on other applications and is perfectly suited for programs like 'Disk defragmenter' or the 'Windows Search'-indexer service because they should run in the background without affecting performance.

There are several ways to check what kind of priority a process runs as, for example you might use ProcessExplorer to view a program's performance properties to see what kind of I/O process priority a process uses:

or you could use PowerShell to find processes running with a non-normal priorityclass like this:

Setting up our tests

So, lets' find out if setting the I/O priority of a process to idle while keeping another process with a default I/O priority actually prevents the idle-priority process from impacting system performance.

To be able to test this, I have written a very small C# program which accepts several parameters and can generate the I/O pattern with the given I/O priority. We run up to two combinations simultaneously in order to measure the impact of background I/O on normal-prioritized I/O. For write tests we perform 300.000 operations, for read tests we perform 10.000 operations. All tests are performed on a non-virtualized Intel Core2 Duo CPU E6550 at 2.33GHz running Windows Vista. The files reads and writes were performed on were a 20 GByte random-filled file on actual spinning harddisks (Maxtor 6L300S0) to make sure caching should have a minimal effect.

If we look at the information listed in the above table, it shows that the idle-priority I/O feature of Windows Vista and later prevents processes very well from idle-priority I/O to impact other I/O. However idle-priority I/O does seem to have a very small (in the 1.5% range) impact on I/O although the difference is negligible. 

Impact is slightly more noticeable for read operations which might be explained by the fact that hardware can easily cache a write while a read always has to be performed if it is not in the cache already but this is pure an hypothesis.