Fujitsu ServerView Blade System Integration Pack

FUJITSU Software ServerView Blade System Integration Pack for Microsoft System Center Operation Manager. The product is released for:

• SCOM 2012 R2
• SCOM 2016

Supported Operating Systems:

• Microsoft Hyper-V Server 2016
• Windows Server 2008 R2 Enterprise (x64)
• Windows Server 2008 R2 Standard (x64)
• Windows Server 2012 Datacenter
• Windows Server 2012 Essentials
• Windows Server 2012 Foundation
• Windows Server 2012 R2 Datacenter
• Windows Server 2012 R2 Essentials
• Windows Server 2012 R2 Foundation
• Windows Server 2012 R2 Standard
• Windows Server 2012 Standard
• Windows Server 2016 Datacenter
• Windows Server 2016 Essentials
• Windows Server 2016 Standard
• Windows Storage Server 2016 Standard

HINTS and RESTRICTIONS

SNMP PDU error-status values are not mapped as problem to SCOM GUI.
If a SNMP request is responded by the MMB with a SNMP PDU with error-status this communication problem is not shown on the SCOM GUI. In such situations the shown health-state of the component and the monitoring state does not show the real current state. In such situation it may also happen that some monitoring monitor warnings arise for subsystems without real access problems.

The first valid DNS entry is used.
If more than one namespace provider returns information to the BSMA service during DNS-name resolution the first valid value is used

Uninstall of the FUITSU Software ServerView Blade System Monitoring Service does not delete temporary created files
In the installation directory of the FUITSU Software ServerView Blade System Monitoring Service many temporary files are created during runtime by the Service and the MP discovery / monitoring scripts. These files are still available after uninstall of the product. These files can be deleted manually after uninstall.

Unicode characters are not supported
While the MMB Web UI accepts unicode characters for communityname, system location and system name, the released SCOM integration product is restriced to ASCII strings only. Therefore Japanese strings for these values are not supported.

Product supports Alert suppression for all but two alerts
Multiple same alerts using the scom feature of alert suppression.
Only the two rules:

• Fujitsu.PRIMERGY.BladeSystem.DiscoveryCommunicationError
• Fujitsu.PRIMERGY.BladeSystem.SNMPTrapServiceStarted will be noted as new alert on each occurence.

Update installation does not show a warning dialog
If you update an exisiting installation of version 5 the installation / update does not show a warning about already installed version. The setup updates to a complete functional version 6 in a form like a new installation. Customer settings made in version 5 are saved and are reused in version 6 automatically.

Debug control file SVISCOM-BL.Log shall have value 19
If you need a trace file of the discovery or monitoring scipts for a service request please change the default value 15 in the SVISCOM-BL.Log.ini file to value 19 to get a complete trace file.

Duplicated Alerts will occur if the Blade System Integration Pack is installed together with any of the following Fujitsu ServerView Integration Packs:

• ServerView Windows Server Integration Pack for MS SCOM
• ServerView Linux Server Integration Pack for MS SCOM
• ServerView ESXi Server Integration Pack for MS SCOM
• ServerView Out-of-Band Integration Pack for MS SCOM

If you install this Management Pack together with the FUJITSU ServerView Integration Packs you should not configure the ServerView Event Manager to store MMB SNMP Traps in the Eventlog. If they are both configured then you will receive two Alerts for a single SNMP Trap in SCOM UI.

Blade Enclosure discovery and monitoring support IPv6 and DNS name for MMB address.

SNMPv1 support only
The communication between the SVISCOM Blade-Pack Software and the MMB only supports requests and Traps for  SNMPv1.

Avoid too many not accessible  Blade chassis as managed Blade Chassis If a MMB do not answer to a SNMP request the BSMA service and the VB-scripts inside the Blade-MP start retries and wait until timeouts. If you have many MMBs that are not accessible  but configured as managed Blade Chassis, without changing the monitoring intervals it may happen that the delay of the discovery script and monitoring script results in many event log entries with severity error, warning and information. By this you may see one error entry for each subsystem of each MMB (event ID 420 -428) and also  Warning like "the process will be dropped because it has been waiting in the queue for more than 10 minutes.

In some situations it may also happen that these delays impact the normal monitoring of existing managed MMBs.

Warning event in FujitsuBladeSystemMMB event log with event ID 608 may occur On some installation we saw event ID 608 in the event log FujitsuBladeSystemMMB. This shows a temporarly synchronization problem between the BSMA service and the Blade-MP VB-Scripts. The problem is fixed automaticall on next monitoring cycle.

Alert only shows the IP of the Blade-Enclosure MMB
If a Trap based Alert is shown in SCOM Alert-View  you will see the string "Blade System Enclosure Monitoring Service" of the system where the BSMA is running as Alert-source and in Alert Context.  In the Custom1 field you can determine the IP address of the origin MMB for this Alert. You have to map this IP to the right Blade-Enclosure name yourself.

Repeated informational eventlog entries in Operations Manager event log in case of temporary communication problem
In situations where a remote MMB cannot be accessed by the BSMA service the discovery VB-Scripts generate eventlog entry with event ID = 430 and text "PYBladeSystemEnclosureDiscovery.vbs : File lost" entries repeatedly. This happens on each discovery cycle while the remote MMB is not accessible.

Check both the health state and monitoring state for a component in case of problems
The state values provided by the MMB S31.mib implementation contain health state as well as configuration or availability state values. Because the Blade-MP provides a subsystem monitoring and not a single component monitoring you should always check both the health monitor and the monitoring monitor for a subsystem. In some situations  it could be possible that only the monitoring monitor shows a warning even if a health problem for a compent exists. This can happen e.g. if the S31.mib state value  of a component changes from "error" to "present" or "standby".

Health state for Serverblade, Storageblade and KVM may not reflect the real health state on the very first discovery
If a Blade or KVM switch has the state=standby on the very first discovery the very first monitoring will show the health state in SCOM as "healthy". As soon as the first state change happened,  e.g. you switch on the serverblade the real health state is shown in SCOM.

Eventlog entry 536879913 means  BSMA service has terminated You may see an error entry in the system eventlog with number 536879913. This message is generated by Windows and has the meaning  "BSMA service has terminated". Exit code cannot be string and therefore this number is shown.

Exported override pack from Version 4.0.4.7 cannot be imported for this version
The structure of the monitor attributes have changed in last version 5.0.12.0. Therefore you cannot use an override pack from the version 4.0.4.7  by reimporting it  into SCOM. The changes belong to the monitor interval. It was named "PeriodInSeconds in the last version. In this version it has been replacedby with the property name "IntervalSeconds".

Problem on single Communication switch may be not shown in some situations
If you have two or more communication switches of same technology (like two FC switches or two Ethernet switches) the overall state for this subsystem will not show a detected problem in following situation: If one switch stays the whole time in a healthy state while the second switch changes to a warning or critical state, this warning/critical state is shown. If now this switch with the problem changes its value in the S31.mib of the MMB to one of the values (unknown, not present, standby) the overall state is calculated only by the value of the first switch, which will result in a health-state with value "healthy".
In this situation only the monitoring monitor will show a communication problem for the subsystem.

Task "ServerView Operations Manager" only works after restart of SCOM Console
To get the SCOM Task "ServerView Operations Manager " in the section working the following steps must be done:

• The product  "Serverview Integration in SCOM for Blade" must be installed locally on the system where the SCOM console is running
• Restart the SCOM Console after product installation to get the right environment settings

Health state detail view for Storage and Server Blades shows additional states
SCOM monitors are restricted to health-state values "healthy", "warning" and "critical". In the Health-State view in tab "State-change Events view" you can also see health states "unknown", "degraded" or "error" for a single Blade. This provides you additional value by showing a more detailed   health-state mapping based on  the  SNMP modeling in S31.mib. It shows the mapping values used inside the VB-Script of the Blade-MP.

Components and Enclosure may be shown as warning even if they do not exist (only in special situation)
If you configure a Blade Enclosure as new managed one with the configuration tool AddBladeEnclosureToSCOM.exe but the Blade Enclosure can’t be connected at the moment the first SCOM Discovery will add the new managed Blade in SCOM GUI but shows all possible subsystems with warning state and the note "not connected". As soon as the new Blade Enclosure can be accessed the health states are set to the current state and not existing subsystems e.g. KVM or StorageBlade will be removed on next discovery cycle.
This may also happen on further discovery cycles where the Blade Enclosure is not accessible.

Alert View is not always sorted correctly, and will not display the newest alert first
In some situations the default sorting order of the Alerts does not sort the newest on top in the default configuration. This only relates to the default order just after importing the MP.

Check and change the order in the alert view of the product to correct this.

Sometimes data retrieval problems are not shown as monitoring monitor state warning
In very rare situation it can happen that the SNMP request made by BSMA service gets SNMP error values back that do not allow to distinguish whether a component is not available at all or only a processing error during data retrieval. In this situation a data retrieval problem may not be shown by the health state of the monitoring monitor for the subsystem. This can only happen for Connection Units.

If in one monitoring cycle a single SNMP-GET returns with SNMP-PDU error-status "genError (5)" this data retrieval problem will also not be shown as monitoring monitor state change.

Sometimes an Error occurred during  import or deleting the MP from SCOM
If you delete the MP from SCOM you may face the error message on the SCOM Console:
"The selected management pack cannot be deleted. This might be because it is currently being deleted or it has already been deleted. If you think this message is in error, try again later."
The possible reason could be that SCOM database becomes full.
To fix the problem the initial size of Database file MOM_LOG file should be increased and / or set to "autogrowth"

You can solve the problem by changing the file size of the LOG file of the DB in the SQL Manager Studio.

1. Start the SQL Server Management Studio
2. Navigate to the Operations Manager Database -> press right mouse -> select properties in the opening dialog select the page "Files" on the left top corner.
3. Increase the initial Size (MB) for the Database file MOM_LOG and/or set it to autogrowth.

E.g.:
By default SCOM installed a size of 500 MB and no autogrowth.
Changed it to Initial Size 1000 MB and  Autogrowth = "By 10 percent, Unlimited".
After this the Management Pack can be deleted.

See also: Check Size Of Databases

Alerts based on rules checking eventlog for eventID 400 – 428 are not FUJITSU specific and could generate false alerts
In the VB-scripts running on the SCOM Agent the product generates eventlog entries in the Operations Manager event log with ID 400 – 420. The rules in the MP only checks for these eventIDs. Therefore there is the risk that another MP generates the same event log ID with event-source "Health Service Script" which will fire a wrong Alert in SCOM about the Blade-monitoring.

Column order of monitoring views may not reset to default value
SCOM stores the order of the columns of its views in the registry in the section for the SCOM Console.

If the order shown on our SCOM Console does not fit to your preferences and a personalization on the SCOM GUI does not change the order persitant you have to remove the SCOM registry keys.

1. Navigate in registry to the key HKEY_CURRENT_USER\Software\Microsoft\Microsoft Operations Manager\3.0\Console
2. Delete the four entries for the FUJITSU.PRIMERGY.BladeSystem.Enclosure.xxx.StateView
3. Restart the SCOM Console

Restricted support of NAT
MMBs sending SNMP Traps over a NAT-server translation show the translated address as Trap-source in the Custom Field and not the IP assigned on the physical MMB.

Communication problems between Monitor Service and Trap Service are not fully monitored
The Monitoring Service uses the Windows SNMP Trap service to receive traps from the MMB.

A stop of the  Trap service will be monitored in the SCOM "Monitor Service State". If the Trap service is restarted the Monitoring Service will be restarted automatically to create a new binding to the trap service.

In very rare situations a problem to attach to the Trap Service or lost communication between the two components are not monitored. By this the receipt of SNMP traps will not be possible without notification on the SCOM GUI.

Eventlog FujitsuBladeSystemMMB not deleted during uninstall
Uninstalling the Monitor Service package will delete the entry in the EventViewer left pane (tree-view) but does not delete the Eventlog entries. After reinstalling the Monitor Service Package you will see the old eventlog entries again.

Please clear the eventlog FujitsuBladeSystemMMB before uninstalling the Monitor Service package.

Manual will only be released on ServerView Documentation DVD
The manual is not part of the released Software package and will only be released on the ServerView Documentation DVD.

Software Dependencies where Blade System Monitoring Service shall be installed
Microsoft SNMP Service from Windows shall be installed and running before Fujitsu PRIMERGY Blade System Monitor service is installed.