After upgrading Operations Manager to SP1 some changes to the Windows Media Services 9 Management Pack were required. The updated version is 18.104.22.168. If you downloaded the original release, I strongly recommend updating or you may see error messages in the Operations Manager event log of your Windows Media servers.
The features have remained unchanged. Download the current version from the link in the original WMS MP post.
Update (Mar 12th, 2008)
While I was posting this, HP has released a totally new set of management packs for ProLiant and BladeSystem. You can get them from here:
HP ProLiant Server MP V1.1
HewlettPackard.Servers.Library.mp (22.214.171.124) – unchanged
HewlettPackard.Servers.ProLiant.mp (126.96.36.199) – unchanged
HewlettPackard.Servers.ProLiant.SNMP.mp (188.8.131.52) – updated
HP BladeSystem MP V1.6.20
The latter is much more feature rich than my simple approach. So I am retyring it.
Moving onward we are installing more of our servers as blade systems. This saves rack space and brings down power consumption but introduces a new single point of failure. All blades (servers) are dependant on their enclosure. So here is a simple management pack, that alerts if the hardware condition of a Hewlett-Packard ProLiant Blade enclosure changes to degraded. The management pack defines a SNMP MIB probe, which polls the ‘Compaq Rack Info MIB’. Whatever hardware condition exists, a generic alert message will be created. Upon receiving them it is recommended to log onto the enclosure’s management interface to determine the cause of the alert (fan, temperature or the like).
Note that this management pack does not deal the the blades themselves. The free HP Server management pack takes care of them very well. My management pack is solely about the enclosure.
Download HP Blade Enclosure Management Pack Guide
Download HP Blade Enclosure Management Pack (sealed) (rename after downloading – it is a zip file)
Just import the management packs and discover your enclosures as network devices, using OpsMgr’s discovery wizard. If your enclosures have multiple management interfaces, consider discovering only one of them or disabling the monitor of this management pack for all but one. This will avoid receiving double alerts upon a hardware issue.
After they’ve been running nicely for a long time our DTS jobs began failing, writing the notoriously long error event 81. Having a closer look at the event description it became obvious that they failed at different steps every time. The description however, did not change:
Step ‘[any step here]’ failed
Step Error Source: Microsoft OLE DB Provider for SQL Server
Step Error Description:[DBNETLIB][ConnectionRead (recv()).]General network error. Check your network documentation.
After much investigating and checking the usual suspects (client connection timeout setting on the SQL server), I stumbled over KB article 899599 which refers to BizTalk but helped. It turned out that the server’s TCP/IP stack had been hardened using a group policy. So the SynAttackProtect flag was activated and killed off the DTS job’s sessions when there was a lot of data to transfer.
Locate and check the following registry key:
If you are seeing the above problem and it is set to 1, change it to 0 on MOM’s data-warehouse server (or have the group policy altered).
More information about the SYN flooding attack protection feature can be found in the Windows Server 2003 Resource Kit Registry Reference.