既知の問題

uim203
UIM に存在する既知の問題を以下に示します。
2
アプリケーションにセキュアではない通信の脆弱性がある
現象:
ユーザ固有の機密性の高い認証データは、クリア テキストで送信されるため、攻撃者がスニッフィングして、ユーザ ID が漏洩し、アプリケーションへの不正なアクセスにつながる可能性があります。
解決策:
すべての認証接続で、または機密データを送信する場合は、SSL を使用します。すべての認証接続、または認証情報、クレジット カードの詳細、健康情報、およびその他個人情報などの機密データまたは重要データを送信するすべて接続で、SSL を使用します。Web サーバとデータベース システム間など、インフラストラクチャ要素間の通信は、認証情報や固有のデータに対してトランスポート レイヤ セキュリティまたはプロトコル レベルの暗号化を使用して、適切に保護します。
オペレータ コンソール(OC)および LDAP アカウント名で特殊文字を使用すると CABI のインストールに失敗する
特殊文字(\、|、[ ]、`、"、'、~、!、#、$、%、^、&、[,]、*、+、=、;、* :、?、<、>、}、{、)、(、]、[、/、@)をオペレータ コンソール(OC)または LDAP アカウント名に使用すると、CABI とのアカウント同期に失敗し、インストールが失敗します。
拡張テンプレートを使用するとデフォルト以外の QoS メトリクスを収集できない
現象:
拡張テンプレートを使用する場合、QoS メトリクス情報を使用して、プローブ設定ファイルが更新できません。
解決策:
デフォルトのメトリクスの QoS 収集は、レガシー テンプレートの場合に正常に機能します。ただし、拡張テンプレートの場合は、デフォルト以外の QoS 収集のテンプレートにマッピングが存在しないため、プローブ設定ファイルが更新されません。
モニタ対象のデバイスが共有ファイル システムを使用している場合、CDM プローブ設定が discovery_server のパフォーマンスに影響する
現象:
デフォルトでは、CDM プローブ設定は、Setup/allow_remote_disk_info が Yes に設定されています。これにより、CDM プローブで、共有ファイル システムを使用しているモニタ対象デバイス上のすべての共有ドライブに対して、デバイス ID を生成できます。このような状況では、cdm は、同じ共有ファイル システムに対して重複する観点を作成します。これは、discovery_server のパフォーマンスに影響します。
解決策:
この問題を修正するには、[RAW 設定]を使用して、cdm の Setup/allow_remote_disk_info の設定を No に変更します。UIM データベースを確認し、重複する観点を削除します。これにより、discovery_server のパフォーマンスが通常の稼働レベルに戻ります。
デュアル スタック モード(IPv4 および IPv6)でのプローブの展開はサポートされない
現象:
Nimsoft ローダ(nimldr)ユーティリティを実行して、IPv6 アドレスを使用してプライマリ ハブを設定し、デュアル スタック モードを実行していると、以下のいずれかが発生します。
  • IPv4 アドレスをプライマリ ハブに指定すると、インストールに失敗します。
  • IPv6 アドレスをプライマリ ハブに指定すると、ロボットはインストールされますが、ロボットにプローブを展開できないか、設定できません。
解決策:
デュアル スタック モードは、UIM 環境のプライマリ ハブがデュアル スタック IPv6 にあり、robot.cfg 内で使用される IP アドレスがデュアル スタック IPv4 の場合、機能しません。
ダッシュボード デザイナ権限にバス ユーザ権限が必要
アカウント アドミニストレーションで、アカウント コンタクト ユーザの ACL に、そのユーザがカスタム ダッシュボードの作成を希望している場合、ダッシュボード デザイナ権限を追加できます。ただし、権限はバス ユーザに対してのみ機能します。アカウント コンタクト ユーザに適用されたダッシュボード デザイナ権限は無視されます。
Exchange モニタのセットアップ テンプレートのローカライズに関する問題
CA UIM 9.0.2 では、デフォルトのプロファイル名は Exchange モニタのセットアップ MCS テンプレートではローカライズされていません。
フレンドリ名に特殊文字を使用するとスキーマの展開に失敗する
現象:
ファイル名に無効な文字があるスキーマを展開すると、「Error occurred while creating/deploying schema probe package, Failed to deploy the probe package for the schema, <friendly_name> ScaleIO97db5264cdf49dbadf1de5928b0d9c98 :: <friendly_name>_schema.json. (スキーマ プローブ パッケージの作成または展開中にエラーが発生しました。スキーマ <friendly_name> ScaleIO97db5264cdf49dbadf1de5928b0d9c98 :: <friendly_name>_schema.json のプローブ パッケージの展開に失敗しました。)」というエラーでスキーマの展開に失敗します。
解決策:
ファイル名に有効な文字を使用してフレンドリ名を定義します。
Isilon スキーマのアップロードに失敗する
現象:
次のエラーが発生して、Isilon スキーマのアップロードに失敗します。「There was a problem while importing. Please contact administrator. (インポート中に問題が発生しました。管理者にお問い合わせください)」。[OK]をクリックして続行します。
解決策:
このエラーは一般にスキーマ サイズが 1 MB より大きい場合に発生します。アップロード可能な Isilon スキーマのファイル サイズは最大 1 MB です。
インターフェース グループがモバイル アプリでサポートされていない
現在、Android または iOS デバイスのいずれでもインターフェース グループがサポートされていません。
RHEL 7.4 でインストールに失敗する
現象:
RHEL 7.4 マシンへの UIM のインストールが失敗します。
解決策:
RHEL 7.4 を使用している場合は、フォント local.conf ファイルが設定されているか、または dejavu-serif-fonts パッケージがインストールされていることを確認します。詳細については、RHEL のドキュメントを参照してください。
オプション 1:
フォント local.conf ファイルが設定されています。以下の内容で /etc/fonts/local.conf ファイルを作成します。
<?xml version='1.0'?> <!DOCTYPE fontconfig SYSTEM 'fonts.dtd'> <fontconfig> <alias> <family>serif</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>sans-serif</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>monospace</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>dialog</family> <prefer><family>Utopia</family></prefer> </alias> <alias> <family>dialoginput</family> <prefer><family>Utopia</family></prefer> </alias> </fontconfig>
オプション 2:
yum インストール コマンドを実行して dejavu-serif-fonts パッケージをインストールします。
yum install dejavu-serif-fonts
セカンダリ ロボットの展開で Java ベースのプローブが起動できない場合がある
CA Unified Infrastructure Manager v8.51 以降は、Java 8 と共にインストールされます。CA UIM v8.51 以降にアップグレードする際、ロボットに事前に展開された Java ベースのプローブで Java の古いバージョン(Java 7 など)が使用されている場合、プローブが起動しない場合があります。これを解決するには、java_jre バージョン 1.7 をロボットに再展開して、ロボットを再起動します。
Java SDK 環境変数の要件
Java SDK を使用して UIM にメッセージを送信する場合は、ローカル ロボットに接続するループバック IP アドレスを指定するために、以下の環境変数を設定します。例:
NIM_ROBOT_IP=127.0.0.1
JSON スキーマの検証に失敗する
現象: サブシステム
JSON スキーマをアップロードすると、検証に失敗して以下のエラーが発生します。
[<schema_name>.json] is/are missing UIM metric definitions syntax. ([<schema_name>.json] に UIM メトリクス定義構文がありません)。
解決策:
このエラーは通常、UIM
メトリクス
定義セクションが JSON ファイルにないか、
operator
および
severity
属性に不正な値が含まれている場合に発生します。
このエラーを解決するには、スキーマ ファイルを編集し、以下のアクションのいずれかを実行します。
  • スキーマの[
    メトリクス
    ]セクションで、
    operator
    および
    severity
    属性に値を 1 つのみ定義します。これらの属性では、配列の値はサポートされません。
    または
  • スキーマの[
    メトリクス
    ]セクションから属性
    thresholdenabled
    operator
    severity
    custom_message
    custom_clear_message
    を削除します。
外部 CABI のセキュリティ証明書の手動でのコピー(セカンダリ ロボット)
CABI の外部バージョンを展開して TLS v1.2 を有効にする前に、セキュリティ証明書をプライマリ ロボットからセカンダリ ロボットに手動でコピーする必要があります。
データベースとして Microsoft SQL Server を使用する場合は、トラスト ストア ファイル(jks)をプライマリ ロボットからセカンダリ ロボットに手動でコピーする必要があります。ファイルは、<Nimsoft>\security フォルダに配置されます。
データベースとして Oracle を使用する場合、ウォレット ファイル(SSO/PKCS12)をプライマリ ロボットからセカンダリ ロボットに手動でコピーする必要があります。ファイルは、<Nimsoft>\security フォルダに配置されます。
MCS 設定プロファイルが大規模な動的グループのすべてのメンバに適用されない場合がある
動的グループは、デフォルトで 5 分ごとに更新されます。大規模な CA UIM 環境では、動的グループにメンバが 1000 以上含まれている場合があります。モニタリング設定サービスが 5 分の間隔以内に大規模な動的グループのすべてのメンバに対して設定プロファイルを展開または更新できる可能性は低いと考えられます。この問題を解決するには、設定された間隔を増加させることができます。間隔は、nis_server 上の group_maintenance_interval で設定されています。nis_server 上の group_maintenance_interval の変更の詳細については、「グループの作成および管理」の「
自動グループの更新間隔の設定
」を参照してください。
MCS MySQL、Oracle、または SQL Server デバイス レベルの設定プロファイルのオーバーライドがアスタリスクでマークされない場合がある
モニタリング設定サービスを使用して、グループ レベルの MySQL、Oracle、または SQL Server の設定プロファイルを作成できます。MCS がグループのすべてのメンバにグループ設定プロファイルを適用した後、デバイス レベルでオーバーライドを行うことができます。MCS は、デバイス設定プロファイル上の、デバイス レベルのオーバーライドを含む各フィールドをアスタリスクでマークします。以下の条件では、オーバーライドを含むデバイス レベルの一部の[
アラーム
]フィールドでアスタリスクが表示されない場合があります。
  • チェックポイントに対するグループ レベルのプロファイルが
    [None]
    または
    [QoS]
    をパブリッシュするように設定されている、および、
  • 同じチェックポイントのデバイス レベルのオーバーライドが[
    アラーム
    ]または[
    QoS およびアラーム
    ]に設定されている
mon_config_service が再起動後にアクティブにならない
現象:
アドミン コンソールまたは IM から、mon_config_service プローブを再起動すると、このプローブがアクティブになりません。
解決策:
mon_config_service プローブが再起動後も非アクティブの場合は、アドミン コンソールまたは IM に移動して、[アクティブ化]をクリックします。
mon_config_service.log のファイル ローテーションが正しく動作しない
log4j と NimLog の両方が現在 mon_config_service.log に書き込み中であり、これによりログ ファイル エントリが正しくロールされません。この問題を修正するには、log4j.properties ファイルを変更し、mon_config_service.log ファイルに対して適切なファイル サイズを追加する必要があります。この問題を回避するには、以下の手順に従います。
  1. リモート デスクトップで、テキスト エディタを使用して <uim>\Nimsoft\probes\service\mon_config_service にある log4j.properties ファイルを開きます。
  2. ファイルの最初の行の「log4j.rootCategory=ERROR, FILE, CONSOLE」ステートメントから「FILE」を削除します。
    ステートメントは「log4j.rootCategory=ERROR, CONSOLE」になります。
  3. ファイルを保存します。
  4. mon_config_service.log ファイルに対して適切なファイル サイズを指定します。デフォルトのファイル サイズは 1024 KB です。
    1. アドミン コンソールにアクセスします。
    2. ロボット
      ]タブ上のハブを選択し、[
      プローブ
      ]タブをクリックします。
    3. mon_config_service.log ファイルのインライン メニュー ボタンをクリックし、[
      RAW 設定
      ]を選択します。
    4. セットアップ
      ]セクションを選択します。
    5. 右上の「
      +
      」をクリックして、新しいキーを作成します。
    6. [キー]フィールドに、
      ログ サイズ
      を入力します。
    7. [値]フィールドで、mon_config_service.log ファイルに対して適切なファイル サイズ(KB)を指定します。
    8. 作成
      ]をクリックし、ログ サイズのキーと値を追加します。
    9. [更新]をクリックして、変更を保存します。
モニタリング設定サービスのプロファイル タイプのフィールド名
特定のプローブに対する MCS プロファイル タイプと関連プローブ設定 GUI (アドミン コンソールまたはインフラストラクチャ マネージャ)の設定オプションは同じですが、それらの個々のフィールド名が一致するとは限りません。各プローブ GUI の使用可能なフィールドの詳細については、「プローブ」サイトの各プローブのドキュメントを参照してください。
デバイスの最後の子テンプレート(オーバーライド)を削除してもモニタが削除されない
現象:
グループを作成し、このグループにデバイスを追加します。また、デバイスで他のオーバーライド テンプレートが定義されていないことも確認します。次に、このグループ内のテンプレートをオーバーライドし、オーバーライド テンプレートが適用されていることを確認します(モニタはパブリッシュされます)。ここで、オーバーライド テンプレートを削除します。オーバーライド テンプレートを削除しても、デバイスのテンプレートから作成されたモニタは削除されません。
解決策:
デバイスに関連付けられているすべての子テンプレート プロファイルが削除されると、デバイスのエントリはプローブ設定ファイルから削除されます。プローブは設定ファイル内で検出されたすべてのデバイスを処理します。そのため、ファイルで過去に検出されていたが現在は検出されないデバイスは処理されません。つまり、過去に作成したモニタは削除されません。
現在の実装では、設定ファイルから削除されたデバイスを管理する方法がありません。これを回避するには、この状況が発生した場合にプローブを常に再起動します。
Debian システムで名前解決が automated_deployment_engine プローブと競合する
デフォルトでは、Debian v6 は名前解決アドレスとしてアドレス 127.0.1.1 を使用します。automated_deployment_engine を使用してロボットを Debian 7 または 8 のシステムに展開した場合、システムの再起動後にロボットは使用可能なアドレスとして 127.0.1.1 にバインドしようとします。Debian システム上での 127.0.1.1 の競合を回避するには、以下の回避策を実行します。
  • ロボットを手動でまたは automated_deployment_engine を使用してインストールする場合は、インストール後にターゲット システムに移動して、robot.cfg ファイルに以下の行を追加する必要があります。
robotip = ip_address
ここで、
ip_address
は、ターゲット システム上でロボットがバインドする必要がある目的の IP アドレスです。
  • XML を使用して Debian 6.0.5 に展開する場合は、
    <robotip>ip_address</robotip>
    オプションを定義する必要があります。ここで、
    ip_address
    は、ターゲット システム上でロボットがバインドする必要がある IP アドレスです。
Oracle Instant Client 12.2 が機能しない
現象:
CA UIM 9.0.2 は Oracle Instant Client 12.2 では機能しません。
解決策:
これを回避するには、Oracle Instant Client 12.1 を使用します。
Windows クラスタ環境でプローブ管理によって「不明なエラー」が返される
Windows クラスタ環境でプローブを設定しようとすると、プローブ管理によって「不明なエラー
」メッセージが返されることがあります。この問題は特に ems プローブで発生していましたが、その他のプローブでも発生する可能性があります。この問題を回避するには、以下の手順に従います。
  1. インフラストラクチャ マネージャに管理者としてログインします。
  2. [セキュリティ]タブで[
    Probe Administration (プローブ管理)
    ]を選択します。
  3. New Probe (新しいプローブ)
    ]をクリックして、ems プローブのエントリを追加します。
    1. プローブ
      ]ドロップダウン リストで[ems]を選択します。
    2. [アクセス]
      ドロップダウン リストで[管理]を選択します。
    3. IP マスク
      ]フィールドにアスタリスク(*)を入力し、[
      OK
      ]をクリックして変更を保存します。
モニタリング設定サービスから削除されたプロファイル調整機能
調整機能は、mon_config_service プローブから新しい MCS ユーティリティ ツールに移動されました。MCS ユーティリティ ツールでは、より柔軟に調整をスケジュールでき、検出された相違点のより詳しいレポートを提供し、mon_config_service プローブのパフォーマンスを向上させることができます。モニタリング設定サービスによって管理される設定プロファイルの相違点を修正するには MCS ユーティリティ ツールを使用します。
ロボット名を変更して、ロボットを再起動した後、プローブが動作を停止する
現象:
ロボット名を変更して再起動すると、プローブは機能しません。
解決策:
ロボット名の変更後にプローブを検証する必要があります。検証は、インフラストラクチャ マネージャ インターフェースから実行できます。
UNIX でロボットのインストールに失敗する
現象:
UNIX でロボットのインストールに失敗するか、インストール直後にロボットの起動に失敗します。
解決策:
オペレータ コンソール(OC)からのロボットのインストールは正常に機能します。ただし、Nimsoft ローダ(nimldr)ユーティリティを使用したサイレント インストールでエラーが発生します。以下のエラー メッセージが表示された場合は、2 度目のインストールを再試行します。
./niminit stop Failed to stop nimbus.service: Unit nimbus.service not loaded.
./niminit start Failed to start nimbus.service: Unit nimbus.service failed to load: No such file or directory.
ロボットが起動しない場合、ロボットを停止して再起動します。
サブテナンシーが CABI 可用性レポートでサポートされない
現象:
CABI 可用性レポートでは現在、サブテナンシー機能はサポートされていません。すべての発生元のデータは、CABI 可用性レポートでユーザに表示されます。
解決策:
この問題の回避策はありません。
パスにスペースが含まれていると nas AO(Auto Operator)コマンド アクションが実行されない(サポート ケース 246133、315782)
パスにスペースが含まれている場合、コマンド アクションを解析できません。AO コマンドのパスにスペースは使用しないでください。
UIM 8.5.1 から UIM 9.0.2 へのアップグレード後に、既存のプロファイルを拡張プロファイルに移行できない
現象:
UIM 8.5.1 から UIM 9.0.2 にアップグレードした後に、拡張プロファイルの MCS パッケージが展開後であっても、既存のプロファイルに対応する拡張プロファイルがオペレータ コンソール(OC)に表示されません。
解決策:
既存のプロファイルを拡張プロファイルに移行する前に、最新の(非拡張) MCS テンプレート パッケージへアップグレードする必要があります。詳細については、「MCS でのアラームしきい値の設定」ページの「
既存のプロファイルの移行と変換
」を参照してください。
data_engine の UI で「クライアント認証が必要」に変更できない
現象:
この問題は、TLS v1.2 が Oracle (UIM データベース)に対して有効で、[
クライアント認証が必要
]オプションを変更しようとすると発生します。data_engine IM インターフェースで、[
クライアント認証が必要
]オプションを変更しようとしても、このオプションの適切な値が sqlnet.ora ファイルに設定されません。sqlnet.ora ファイルは、UIM サーバ コンピュータ上の
<
Nimsoft>\security
フォルダで利用可能です。
解決策:
これを回避するには、SSL_CLIENT_AUTHENTICATION パラメータの値を手動で更新する必要があります。このためには、以下の手順に従います。
  1. UIM サーバ コンピュータで、
    <
    Nimsoft>\security
    フォルダに移動します。
  2. sqlnet.ora ファイルを検索して開きます。
  3. クライアント認証が必要
    ]オプションが(data_engine IM インターフェースで)選択されているかどうかに基づいて、sqlnet.ora ファイルの SSL_CLIENT_AUTHENTICATION パラメータを更新します。
    たとえば、このオプションが IM インターフェースで選択されている場合は、パラメータを以下のように設定する必要があります。
    SSL_CLIENT_AUTHENTICATION = TRUE
    オプションが選択されていない場合は、パラメータを以下のように設定する必要があります。
    SSL_CLIENT_AUTHENTICATION = FALSE
  4. data_engine プローブを再起動します。
IPv6 環境でセカンダリ ロボットをアンインストールできない
現象:
純粋な IPv6 環境で、ハブからセカンダリ ロボットを削除しようとすると、セカンダリ ロボットの IP アドレスを入力した後に[
OK
]ボタンが無効になります。
解決策:
最初にハブからロボットを解除してアンインストールし、セカンダリ ロボットを正常に削除します。
cdm 非拡張プロファイル(レガシー)を作成できない
現象:
cdm 非拡張プロファイル(レガシー プロファイル)の作成に失敗します。
解決策:
cdm 非拡張(レガシー)テンプレートでは、cdm 6.30-MC はローカル アーカイブに存在する必要があります。デフォルトでは、cdm 6.30-MC はローカル アーカイブに存在しません。そのため、cdm レガシー テンプレート プロファイルを作成する場合は、cdm 6.30-MC がローカル アーカイブで利用可能なことを確認します。
アドミン コンソールを使用してプローブ設定が開けない
現象:
アドミン コンソールで任意のプローブの[設定]オプションを選択すると、[設定]ウィンドウが開きません。
解決策:
この問題は、ブラウザでポップアップがブロックされていると発生します。アドミン コンソールのポップアップがブロックされていないことを確認し、[設定]オプションを選択します。
自己署名証明書のアップグレード
Java のバージョンが Java 8 に更新されました。CA UIM の以前のバージョンで生成されたすべての自己署名証明書をアップグレードする必要があります。Java 1.8 ではセキュリティ暗号化レベルが変更されたため、既存の証明書をアップグレードしない場合、CABI サーバへの HTTPS 接続は動作しなくなります。詳細については、「アドミン コンソールまたはオペレータ コンソール(OC)での HTTPS の設定」を参照してください。
プロファイル名で変数の使用をサポート(Salesforce ケース 418533)
モニタリング設定サービスでは、プロファイル名に変数({device.ip} や {device.name} など)を入力できるようになりました。
(9.0.2 以降) mon_config_service_cli を使用したプロファイルの差異の検出および修正
プロファイルの相違点の見つけて修正するための以下の手順は適用されません。
  1. Find-Profile-Diffs コマンドを発行して、設定プロファイルの差異があるロボットを検出します。
  2. Fix-Profile-Diffs コマンドを発行して、プロファイルの差異を修正します。
  3. プロファイルの差異があるロボットがリストされたファイルで Find-Profile-Diffs コマンドを再発行し、プロファイルの差異がなくなったことを確認します。
wasp が webapps を抽出しない
現象:
wasp が webapps を抽出せず、以下のようなエントリが wasp.log に記録されます。
Feb 24 17:18:41:028 INFO [Catalina-utility-1, org.apache.catalina.core.ContainerBase.[wasp-engine].[localhost].[/]] No Spring WebApplicationInitializer types detected on classpath Feb 24 17:18:44:050 ERROR [Catalina-utility-1, org.apache.catalina.core.ContainerBase] startInternal() A child container failed during start Feb 24 17:18:44:051 ERROR [Catalina-utility-1, org.apache.catalina.core.ContainerBase] java.util.concurrent.ExecutionException: org.apache.catalina.LifecycleException: Failed to start component [[email protected]] at java.util.concurrent.FutureTask.report(FutureTask.java:122) at java.util.concurrent.FutureTask.get(FutureTask.java:192) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:916) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:841) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1384) at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1374)
解決策:
  1. レジストリ
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NimbusWatcherService
    を開きます。キー「ImagePath」で、Windows エクスプローラに表示されるように値をパス(同じ場合)に変更します(例: "C:\Program Files\Nimsoft\bin\nimbus.exe")。
  2. 「Nimsoft Robot Watcher」サービスを再起動します。
ハブ プローブでの発生元の更新とコントローラ プローブ機能でハブによって設定された発生元のオーバーライドが正しく動作しない
発生元がハブまたはコントローラ上で更新された場合、アラームを手動でクリアするか、ロボットを手動で再起動するまで、発生元名がアラーム上で更新されません。
NAS では、発生元を含めてキーが作成されます。その後、既存のキーと比較され、新しいエントリまたは必須フィールドが更新されるとデータベースが更新されます。発生元が更新された後、すべての受信抑制されたアラームについて、アラーム クリアの問題を回避するために新しいエントリが作成されます。
[レポートのスケジュール]メニューでオプションの編集および削除が正しく機能しない
現象:
OC の UI で CABI レポートをスケジュールするときに、[スケジュール]メニューの[編集]および[削除]オプションが正しく機能しません。
解決策:
この問題を回避するには、KB 記事で説明しているように「overrides_custom.css」ファイルが適用された CABI 内でスケジュールを使用します。
[UIM 20.3.0]オペレータ コンソールのグループ ビューとインベントリ ビューにデバイス ビューの列が表示されない
新しいオペレータ コンソールでは、UMP 20.1 のグループ ビューとインベントリ ビューにデバイス ビューの列が表示されません。
グループ デバイスの列: エイリアス、キャプション、説明、OS タイプ、OS バージョン、OS 説明、発生元、MAC アドレス、ユーザ タグ 1、ユーザ タグ 2、削除、バス タイプ。
インベントリ デバイスの列: エイリアス、変更日時、発生元、ディスカバリ認証情報。
[UIM 20.3.0]オペレータ コンソールのグループ ビューで、インターフェース グループがデバイス レベルにリダイレクトされない
オペレータ コンソールのグループ ビューで、インターフェース グループがデバイス レベルにリダイレクトされません。インターフェース グループ ビューをクリックすると、グループ リスト ビューにリダイレクトされます。
[UIM 20.3.0][アラーム]テーブルの[すべて選択]チェック ボックスが正常に動作しない
現象:
オペレータ コンソールで、[アラーム]テーブルの[すべて選択]チェック ボックスが正常に動作しません。[すべて選択]オプションを使用しても、すべてのアラームがクリアされず、ページに表示されているアラームのみがクリアされます。また、アラームがクリアされているときに、既存のアラームを再度選択して[すべて選択]チェック ボックスをオンにしてもアラームが選択されません。
解決策
: [すべて選択]の機能を正常に動作させるには、別のページに移動してアラーム ページに戻る必要があります。
[UIM 20.3.0]ダッシュボードで生成された PDF にチャートのグラフが表示されない
オペレータ コンソールで、ダッシュボードで生成された PDF にチャートのグラフが表示されません。この問題は、既存のダッシュボードで発生します。
[UIM 20.3.0] MCS オプション:[グループ外のデバイスを含める]と[プローブなしのデバイスを含める]が正常に動作しない
[グループ外のデバイスを含める]および[プローブなしのデバイスを含める]オプションで、これらの条件に該当するすべてのデバイスが返されません。MCS の[グループ プロファイル設定]でこれらの設定を選択しても、グループ外の参照デバイスとプローブなしのデバイスが表示されません。
[UIM 20.3.0]オペレータ コンソールのアラーム ビューにポリシー名の代わりにポリシー ID が表示される
オペレータ コンソールのアラーム ビューでアラーム ポリシーを作成後、ポリシー名の代わりにポリシー ID が表示されます。
この問題は、OC 20.3.2 パッチ リリースの一部として修正されています。
[UIM 20.3.0]ユーザのタイム ゾーンまたはターゲット スケジュールのタイム ゾーンとサーバのタイム ゾーンが異なる場合、月の N 日目のメンテナンス スケジュールが機能しない
UIM 20.3.0 では、月の N 日目のメンテナンス スケジュールが機能しません。メンテナンス スケジュールはスケジュールされた日時に開始されず、非アクティブのままです。この問題は、ユーザのタイム ゾーンまたはターゲット スケジュールのタイム ゾーンとサーバのタイム ゾーンが異なる場合に発生します。タイム ゾーンの違いによりスケジュール日付とサーバの日付が異なる場合、スケジュールされた日時にメンテナンス スケジュールが開始されません。
この問題は、UIM 20.3.3 リリースの一部として修正されました。
[UIM 20.3.0]自己認定が展開されている ump からアップグレードするときに wasp がオンライン状態にならない
UIM 20.3.0 では、UMP から OC にアップグレードする際に、既存の UMP に自己認定が展開されている場合、wasp がオンライン状態になりません。
この問題は、UIM 20.3.0 以前のバージョンからアップグレードする場合にのみ適用されます。
[UIM 20.3.0][アラーム]ページで、アラーム ポリシーによってアラームが生成されたときに、新しく作成されたアラーム ポリシーの場合、そのポリシーへのリンクが有効にならない
オペレータ コンソールの[アラーム]ページでアラーム ポリシーによってアラームが生成されたときに、新しく作成されたアラーム ポリシーの場合、そのアラーム ポリシーへのリンクが有効になりません。wasp を再起動すると、ポリシーのリンクが有効になります。再起動後に新しいアラーム ポリシーによって新しいアラームが生成されると、同じ問題が発生します。
この問題は、OC 20.3.2 パッチ リリースの一部として修正されています。
[UIM 20.3.0] Ad_server MCS テンプレート内の「AD サーバ サービス」プロファイルに QoS メトリクスが存在しない
UIM 20.3.0 では、Ad_server MCS テンプレート内の「AD サーバ サービス」プロファイルに QoS メトリクスが存在しません。
[UIM 20.3.0]アカウント アドミニストレーションで手動で追加されたアカウント ユーザに[パスワードの変更]を使用できない
UIM 20.3.0 では、アカウント アドミニストレーションで手動で追加された新規ユーザに[パスワードの変更]オプションを使用できません。ユーザはオペレータ コンソールを使用してパスワードを変更できません。
この問題は、UIM 20.3.3 リリースで修正されました。
[UIM 20.3.0]アラーム ポリシーの検索フィルタで正確な結果が返されない
UIM 20.3.0 では、アラーム ポリシーの検索フィルタで正確な結果が返されません。検索文字列が 3 文字以上の場合、検索文字列の一部の検索結果が表示されます。また、検索結果にアラーム ポリシーが表示されるまで時間がかかります。
[UIM 20.3.0]オペレータ コンソールがタイムアウトしない
UIM 20.3.0 では、オペレータ コンソールはタイムアウトせず、セッションが 72 時間アイドル状態であってもセッションはアクティブなままです。
この問題は、OC 20.3.2 パッチ リリースの一部として修正されています。
その他の既知の問題
  • UIM 20.3.1 リリースの新しい既知の問題については、UIM 20.3.1 記事の「既知の問題」を参照してください。
  • OC 20.3.2 リリースの新しい既知の問題については、OC 20.3.2 パッチ記事の「既知の問題」を参照してください。
  • UIM 20.3.3 リリースの新しい既知の問題については、UIM 20.3.3 の記事の「既知の問題」を参照してください。