Troubleshooting

The following table lists some typical problems that you might encounter, along with the possible solution for each problem.

Note:

For additional up-to-date troubleshooting information, refer to the Known Issues section in the latest release notes.
Check the SCOM event log to obtain any relevant information that might help in troubleshooting. Check for event ID 700 to trace any fatal error.

Table 1. Typical problems and possible solutions
Problem	Possible solution
During the installation, the following error message may appear: `The installation package is not supported by the processor type.` This problem might occur when you are installing a 32-bit package on a 64-bit operating system, or vice versa.	Check which bit version of the operating system you are using, and run the matching installation package.
No storage system is listed under Systems or Clusters.	Use the scomu.cmd --list command to check the list of monitored storage systems. Use the scomu.cmd --test command to check the connection to each storage system.
The connection to DS8000® storage systems fails.	Make sure that the web address of the DS CIM agent is correct. The protocol is usually HTTPS and not HTTP. By default, the embedded DS CIM agent communicates through port 6989, and the proxy agent communicates through port 5989.
Event information is not synchronized with System information. In some cases, the information displayed under Events is not immediately synchronized with the information under Systems. For example, the creation of a new volume may be registered as an event, but may not be displayed under Systems, or vice-versa.	This occurs due to a default data refresh interval in Events is 10 minutes (DS8000 is 20 minutes), and in Systems it is 30 minutes. Accordingly, wait until the next refresh interval for the synchronization to occur. In addition, if numerous events are generated within a short time, only the last 300 events are reported (fewer events are reported for SAN Volume Controller with microcode 5.1.0 or later). This is an intended restriction that is imposed due to performance considerations.
IBM® management packs still appear in Microsoft SCOM after uninstallation.	IBM management pack entries may remain in Microsoft SCOM after uninstallation. This occurs when installed management packs are not manually deleted from SCOM prior to uninstalling the IBM Storage Management pack via the Windows Control Panel. Accordingly, you must manually remove the IBM management packs from the Administration pane of Microsoft SCOM (before or after you use the Windows Control Panel to uninstall the IBM Storage Management Pack). For more information, refer to the Microsoft SCOM documentation.
Delay in storage systems display.	After you import a management pack to Microsoft SCOM, it might take several minutes before the relevant storage systems are displayed, and it might take several minutes more before all health state icons are correctly presented. You can encounter this delay depending on the following circumstances: Network traffic The number of monitored storage systems The performance of the Microsoft SCOM database.
Reset to default has no effect on the order of columns.	Under Alerts or Systems, columns cannot be restored to their default order after it is manually changed, and the Reset to Default option in Personalize View has not effect on the order of columns. Due to this limitation of Microsoft SCOM, you need to re-order the columns manually.
Status icon of newly discovered systems displays a wrong status.	Immediately after the storage systems are discovered, the status icon (Healthy, Warning or Critical) does not indicate the actual state of the system. This may occur due to data refresh timing in Microsoft SCOM. Press F5 to manually refresh the displayed status information.
Modified sticky views are kept after re-importing management packs.	Microsoft SCOM allows you to use modifiable sticky views that are kept across sessions even after removing the IBM management packs from the Administration pane and re-importing them. To resolve this, use the Reset to Default option in Personalize View.
Management packs cannot be removed due to a dependency. When attempting to delete an IBM management pack, a message appears and states that due to a dependency on the Default Management Pack, you must first remove the Default Management Pack.	This message, which is normal in Microsoft SCOM, appears whenever one or more manual overrides were defined for the rules or monitors in the IBM management pack. Such overrides are saved in either the default management pack, or in the IBM management pack. To resolve this, save the overrides in a custom management pack, and then delete the existing overrides or import new ones if necessary.
When the IBM Storage Management Pack is installed on a SCOM agent and the connected storage system has a large amount of volumes (about 300 volumes per storage system), the discovery data package may exceed the SCOM size limit (4MB). In such a case, a relevant alert message (event ID: 2015) is added to the SCOM event log.	Consider installing the IBM System Storage® Management Pack on the SCOM management server.
While adding IBM storage, the following error message may appear: `The Monitor Computer object required by the storage system is not found in the management server.`	Delete the management pack and re-import the management pack in the Operation Manager control panel, and then wait for the Monitor Computer to be discovered. Alternatively, shorten the Monitor Computer discovery time. Click the Microsoft SCOM Authoring pane, select ObjectDiscoveries for the relevant storage system type, then in the Actions pane, select Overrides > Override the Rule > For all objects of class: Window Computer.
The following error massage may appear when configuring IBM storage after upgrade from version 1.1.0 to a newer version: `Fail to parse C:\PROGRA~1\IBM\Storage\Host\IBMSTO~1\ config\DeviceConfig.xml.`	Run upgrade_config.cmd from IBM standalone command-line interface (CLI) utility, as explained in First-time installation vs. upgrade.
The following error may appear in C:\Program Files\IBM\Storage\Host\IBMStorageSCOM\log\scsdk.log: `2013-05-30 09:33:39,595 ERROR 724# do_discovery fail. Traceback (most recent call last): File "scsdk", line 39, in _call_ File "scsdk", line 158, in do_discovery Exception: The Configuration "9.115.246.54" of the MonitorComputer "scom-167.scom145.cn.ibm.com" does not exist. Fail to save its discovery data. 2013-05-30 09:33:39,830 INFO 724# SDK CLI end`	The OpsMgr configuration service failed to send the dirty state notifications to the dirty OpsMgr Health Services. This may occur because the root OpsMgr health service is not running. Restart the healthy service on the SCOM management server.