Operations Manager での UNIX/Linux エージェント検出のトラブルシューティング

  • [アーティクル]

この記事は、UNIX または Linux コンピューターの検出プロセス中に発生する可能性がある一般的なエラーのトラブルシューティングに役立ちます。

元の製品バージョン: System Center Operations Manager
元の KB 番号: 4490426

System Center Operations Manager (OpsMgr) で UNIX または Linux コンピューターを監視するには、まずコンピューターを検出し、OpsMgr エージェントをインストールする必要があります。 コンピューターとデバイス管理 ウィザードは、UNIX および Linux コンピューターにエージェントを検出してインストールするために使用されます。 ただし、構成の問題、資格情報または特権の問題、またはネットワークと名前の解決の問題により、検出プロセスが失敗する可能性があります。

証明書エラーまたは証明書署名エラー

署名された証明書の検証操作が成功しなかった

証明書の検証が失敗すると、通常、次のようなエラーが表示されます。

エージェントの検証に失敗しました。 エラーの詳細: 対象のコンピューター (lx1.contoso.com:1270) のサーバー証明書には、次のエラーがあります。
SSL 証明書の失効を確認できませんでした。 失効のチェックに使用されるサーバーに到達できない可能性があります。
SSL 証明書には、ホスト名と一致しない共通名 (CN) が含まれています。
次のことが可能です。

  1. 宛先証明書は、管理サーバーによって信頼されていない別の証明機関によって署名されます。
  2. 宛先に無効な証明書があります。たとえば、その共通名 (CN) が、接続に使用される完全修飾ドメイン名 (FQDN) と一致しません。 接続に使用される FQDN は、lx1.contoso.com です。
  3. リソース プール内のサーバーは、プール内の他のサーバーによって署名された証明書を信頼するように構成されていません。

  • 一般的な原因の 1 つは、エージェント証明書の共通名 (CN) 値が、指定または解決された完全修飾ドメイン名 (FQDN) と一致しないということです。

    これを確認するには、エージェント ホストのホスト名とドメイン名が DNS によって解決された FQDN と一致することを確認します。

    UNIX または Linux コンピューターで証明書の基本的な詳細を表示するには、次のコマンドを実行します。

    openssl x509 -noout -in /etc/opt/microsoft/scx/ssl/scx.pem -subject -issuer -dates

    これを行うと、次のような出力が表示されます。

    subject= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
    issuer= /DC=name/DC=newdomain/CN=newhostname/CN=newhostname.newdomain.name
    notBefore=Mar 25 05:21:18 2008 GMT
    notAfter=Mar 20 05:21:18 2029 GMT

    この情報を使用して、ホスト名と日付を検証し、Operations Manager 管理サーバーによって解決される名前と一致していることを確認します。

    ホスト名が一致しない場合は、次のいずれかのアクションを使用して問題を解決します。

    • UNIX または Linux のホスト名が正しく、Operations Manager 管理サーバーで正しく解決されていない場合は、正しい FQDN に一致するように DNS エントリを変更するか、Operations Manager サーバーの hosts ファイルにエントリを追加します。
    • UNIX または Linux のホスト名が正しくない場合は、次のいずれかの操作を行います。
      • UNIX または Linux ホストのホスト名を正しいものに変更し、新しい証明書を作成します。
      • 目的のホスト名を持つ新しい証明書を作成します。

    証明書の名前を変更するには:

    証明書が正しくない名前で作成された場合は、ホスト名を変更し、証明書と秘密キーを再作成できます。 これを行うには、UNIX または Linux コンピューターで次のコマンドを実行します。

    /opt/microsoft/scx/bin/tools/scxsslconfig -f -v

    オプションは -f 、/etc/opt/microsoft/scx/ssl 内のファイルを強制的に上書きします。

    次の例のように、 スイッチと スイッチを使用 -h して、証明書のホスト名と -d ドメイン名を変更することもできます。

    /opt/microsoft/scx/bin/tools/scxsslconfig -f -h <hostname> -d <domain.name>

    次のコマンドを実行して、エージェントを再起動します。

    /opt/microsoft/scx/bin/tools/scxadmin -restart

    hosts ファイルにエントリを追加するには:

    FQDN が逆引き DNS にない場合は、管理サーバーにある hosts ファイルにエントリを追加して、名前解決を提供できます。 hosts ファイルはフォルダーにあります \Windows\System32\Drivers\etc 。 hosts ファイル内のエントリは、IP アドレスと FQDN の組み合わせです。

    たとえば、ip アドレスが 192.168.1.1 の newhostname.newdomain.name という名前のホストのエントリを追加するには、hosts ファイルの末尾に次を追加します。

    192.168.1.1 newhostname.newdomain.name

  • このエラーのもう 1 つの一般的な原因は、複数の管理サーバーが検出に使用されるリソース プールのメンバーであるが、管理サーバー間で証明書の信頼が構成されていない場合など、信頼されていない機関によって証明書が署名されていることです。

    これを確認するには、検出に使用されるリソース プール内のすべての管理サーバーが、互いのサーバーの証明書を信頼していることを確認します。

    UNIX および Linux コンピューターのリソース プールを管理する方法の詳細については、「UNIX および Linux コンピューター のリソース プールの管理」を参照してください。

ユーザー名またはパスワードが正しくありません

UNIX/Linux エージェントを検出しようとすると、エラーが表示される場合があります。 このエラーは、UNIX/Linux マシンの検出中に証明書の検証手順中に発生する可能性があります。

考えられる原因

  • UNIX/Linux エージェントがドメインに参加していないため、Kerberos 認証を利用できない場合、UNIX/Linux リソース プール内の 1 つ以上の管理サーバーで基本認証が に設定 false されます。 現在の WinRM 設定を確認するには、次のコマンドを実行します。 winrm get winrm/config/client
  • ユーザー名またはパスワードが正しくありません。

解決策

UNIX/Linux リソース プール内の管理サーバーの WinRM 構成を更新して、次のコマンドを実行して基本認証を許可するか、グループ ポリシーを使用して構成を設定できます。

winrm set winrm/config/client/auth @{Basic="true"}

注:

上記のコマンドは、次のレジストリ キーに DWORD (32 ビット) レジストリ値 (AllowBasic) を設定します。

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WinRM\Client

AllowBasic では、(有効) または 0 (無効) の 10 進値を1使用できます。

証明書の署名操作が成功しなかった

考えられる原因

  • 検出に指定されたユーザー アカウントには、署名に関連するファイル操作を実行するための十分な権限がありません。
  • 検出用に指定されたユーザー アカウントの sudo 昇格特権が正しく構成されていません。

解決策

この問題を解決するには、エラーの詳細にある StdErr 出力を調べて、エラーの原因を特定して、ユーザー アカウントを確認します。 また、証明書の署名に使用されるアカウントの sudo 特権の構成も確認します。

ネットワーク名解決エラー

ターゲット アドレスが解決できない

これらの問題は、通常、次のいずれかのカテゴリに分類されます。

  • エラーの説明

    IP アドレスの IP アドレス<>を名前に解決できませんでした

    原因

    このエラーは、ホストの IP アドレスが検出のために入力されたが、IP アドレスが DNS の名前 (逆引き参照) に解決できない場合に発生します。

    解決策

    この問題を解決するには、逆引き参照ゾーンの名前解決 (DNS) 構成を正しく行い、影響を受けるホストに対して名前マッピングへの IP アドレスが存在することを確認します。

  • エラーの説明

    名前 の server.contoso.com を IP アドレスに解決できませんでした

    原因

    このエラーは、ホストの FQDN が検出のために入力されたが、名前が DNS の IP アドレス (前方参照) に解決できない場合に発生します。

    解決策

    この問題を解決するには、前方参照用の正しい名前解決 (DNS) 構成を、ホストに対してホスト名から IP アドレスへのマッピングが存在することを確認します。

DNS 構成: 転送 DNS 解決が逆引き DNS 解決と一致しない

エラーの説明

この状況では、通常、次のようなエラーが発生します。

指定されたホスト名 ServerName は、10.137.216.x の IP アドレスに解決されました。 IP アドレス 192.168.x.x の逆引き参照によって返されたホスト名 ServerName.contoso.com、指定されたホスト名と一致しませんでした。 DNS 構成を確認し、要求をもう一度試します。

原因

最も一般的な原因は、前方 DNS 参照ゾーンと逆引き DNS 参照ゾーン内のホストのレコードが一致しないということです。

解決策

この問題を解決するには、DNS の前方参照ゾーンと逆引き参照ゾーンのレコードを修正して、ホスト名と IP アドレスが一致するようにします。

ターゲット アドレスに到達できない

エラーの説明

この状況では、通常、次のようなエラーが発生します。

WinRM クライアントは、指定した時間内に操作を完了できません。 マシン名が有効で、ネットワーク経由で到達可能であり、Windows リモート管理サービスのファイアウォール例外が有効になっていることを確認します。

考えられる原因

  • 名前解決、ネットワークの停止、またはホストの停止が正しくないため、ホストに到達できません。
  • ネットワークまたはホスト ベースのファイアウォールが、ターゲット ホストへの TCP ポート 1270 接続をブロックしています。

解決策

この問題を解決するには、管理サーバーが FQDN を使用してエージェント ホストに ping を実行できることを確認します。 また、ネットワーク ファイアウォールまたはホスト ファイアウォールが TCP ポート 1270 をブロックしていないことも確認します。

予期しない検出Result.ErrorData 型。 バグ レポートを提出してください - パラメーター名: s

エラーの説明

予期しない DiscoveryResult.ErrorData 型。 バグ レポートを提出してください。
ErrorData: System.ArgumentNullException
値を null にすることはできません。
パラメーター名: s
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager 拡張機能, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager 拡張機能)
at Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

原因

このエラーは、WinHTTP プロキシ設定が UNIX または Linux リソース プールの管理サーバーで構成されており、検出しようとしている UNIX または Linux エージェントの FQDN が WinHTTP プロキシ バイパス リストに含まれていないために発生します。

解決策

この問題を解決するには、UNIX または Linux FQDN を WinHTTP プロキシ バイパス リストに追加します。

UNIX または Linux リソース プール内の管理サーバーで、管理者特権のコマンド プロンプトで次のコマンドを実行して、現在のプロキシ構成を確認します。

netsh winhttp show proxy

WinHTTP プロキシ サーバーが構成されている場合は、次のコマンドを実行して、検出しようとしているサーバーの FQDN をバイパス リストに追加します。

netsh winhttp set proxy proxy-server="<proxyserver:port>" bypass-list="*.ourdomain.com;*.yourdomain.com*;<serverFQDN>"

バイパス リストが構成されたら、エージェントの検出が成功したかどうかをチェックします。

注:

コマンドを netsh winhttp reset proxy 実行して、WinHTTP プロキシを無効にすることができます。 このコマンドを実行すると、プロキシ サーバーが削除され、直接アクセスが構成されます。

予期しない検出Result.ErrorData 型。 バグ レポートを提出してください - パラメーター名: lhs

エラーの説明

検出が成功しない
メッセージ: 指定されていないエラー
詳細: 予期しない DiscoveryResult.ErrorData 型。 バグ レポートを提出してください。
ErrorData: System.ArgumentNullException
値を null にすることはできません。
パラメーター名: lhs
at System.Activities.WorkflowApplication.Invoke(Activity activity, IDictionary'2 inputs, WorkflowInstanceExtensionManager 拡張機能, TimeSpan timeout)
at System.Activities.WorkflowInvoker.Invoke(Activity workflow, IDictionary'2 inputs, TimeSpan timeout, WorkflowInstanceExtensionManager 拡張機能)
at Microsoft.SystemCenter.CrossPlatform.ClientActions.DefaultDiscovery.InvokeWorkflow(IManagedObject managementActionPoint, DiscoveryTargetEndpoint criteria, IInstallableAgents installableAgents)

原因

このエラーは、インストールされている kits フォルダー内の omsagent シェル ファイルが原因で発生します。

解決策

エクスプローラーの次のディレクトリに移動します。

C:\Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits

omsagent ファイルが一覧表示されている場合は、System Center Operations Manager (SCOM) ファイルの外部の一時ディレクトリに移動します。

例については、次のスクリーンショットを参照してください。

DownloadedKits フォルダー内の omsagent ファイルを示すスクリーンショット。

ダウンロードしたKits フォルダーから移動した後、検出を再試行します。 これで検出が成功します。

注:

検出が別のエラーで失敗する可能性があります。 このエラーは、sudoers、接続など、より多くのトラブルシューティングが必要であることを示します。

SSH 接続エラー

SSH 検出中に失敗しました。 終了コード: -1073479162

エラーの説明

標準出力:
標準エラー:
例外メッセージ:例外 (-1073479162) によって SSH コマンドが失敗しました。ターゲット マシンがアクティブに拒否したため、接続できませんでした。

考えられる原因

  • SSH デーモンがターゲット システムで実行されていません。
  • ネットワークまたはホスト ベースのファイアウォールが、TCP ポート 22 での SSH 接続を妨げている。

解決策

  • SSH デーモンが実行されていることを確認します。
  • ネットワーク ファイアウォールまたはホスト ファイアウォールで TCP ポート 22 がブロックされていないことを確認します。

SSH 検出中に失敗しました。 終了コード: -1073479118

エラーの説明

SSH 検出中に失敗しました。 終了コード: -1073479118
標準出力:
標準エラー:
例外メッセージ:例外 (-1073479118) によって SSH コマンドが失敗しました - サーバーが切断メッセージを送信しました: タイプ 2 (プロトコル エラー: ルートに対する認証エラーが多すぎます)

考えられる原因

  • 検出用に指定されたユーザー アカウントは、SSH 経由でのサインインを許可されていません。
  • 検出用に指定されたユーザー アカウントが、無効なユーザー名またはパスワードで入力されました

解決策

  • ユーザーが SSH 経由でサインインすることを許可されていることを確認します。
  • 入力資格情報と、ユーザーがターゲット ホストで定義されていることを確認します。

SSH 検出中に失敗しました。 終了コード: 1

エラーの説明

SSH 検出中に失敗しました。 終了コード: 1
標準出力: Sudo パス: /usr/bin/
標準エラー: sudo: 申し訳ありませんが、sudo を実行するには tty が必要です
例外メッセージ:

原因

ユーザー資格情報入力で sudo 昇格が選択されましたが requiretty 、 sudoers のユーザーに対してオプションが無効になっていませんでした。

解決策

コマンドを使用してターゲット ホスト上の sudoers ファイルを visudo 編集し、次の行を追加します。

既定値: <username>!requiretty

詳細については、「 sudo 昇格キーと SSH キーを構成する方法」を参照してください。

SU パスワードが無効です

エラーの説明

.[?1034hopsuser@lx1:~> su - root -c 'sh /tmp/scx-opsuser/GetOSVersion.sh;EC=$?;rm -rf /tmp/scx-opsuser;exit $EC'
パスワード：
終了
su: 正しくないパスワード
opsuser@lx1:~> 終了
ログアウト

考えられる原因

ユーザー資格情報の入力で Su 昇格が選択されましたが、su 昇格に無効なルート パスワードが指定されました。

解決策

[昇格] 構成ダイアログで、ルートのパスワード入力を確認します。

SSH 検出中に失敗しました。 終了コード: -2147221248

  • エラーの説明

    SSH 検出中に失敗しました。 終了コード: -2147221248
    標準出力:
    標準エラー: ホーム ディレクトリ /home/username に chdir できませんでした:そのようなファイルまたはディレクトリがありません

    原因

    検出用に指定されたユーザー アカウントにホーム ディレクトリがありません。

    解決策

    ユーザーのホーム ディレクトリが /home/ にあり、ユーザーがこのディレクトリに書き込めるかどうかを確認します。

  • エラーの説明

    SSH 検出中に失敗しました。 終了コード: -2147221248
    標準出力:
    標準エラー: ルートのパスワード:
    例外メッセージ:操作がタイムアウトしました

    原因

    ユーザー資格情報の入力で sudo 昇格が選択されました。 ただし、検出用に指定されたユーザー アカウントが、パスワードレス sudo 昇格を使用するように正しく構成されていないか、検出で使用されるユーザー アカウントに必要な sudo 昇格特権が付与されていません。

    解決策

    sudo 昇格構成のドキュメントを確認し、sudo のユーザー構成を確認します。 パスワードレス sudo を構成する必要があることに注意してください。

WSMan 接続エラー

エージェントが要求に応答したが、WSMan 接続が失敗した原因: アクセスが拒否されました

考えられる原因

  • エージェントがインストールされ、エージェント証明書が署名されています。 ただし、エージェントの検証用に指定されたユーザー資格情報が無効です。
  • 検出用に指定されたユーザー アカウントが SSH キーで認証されるように構成されましたが、エージェントの検証用に指定されたユーザー資格情報が無効です。
  • UNIX 側でアクセス許可の問題または PAM 構成が正しくありません。

解決策

この問題を解決するには、次の手順を実行します。

  1. エージェント検証のユーザー名とパスワードが正しく入力されていること、およびユーザーがターゲット ホスト上の有効なユーザーであることを確認します。

  2. 問題が解決しない場合は、sudo 昇格が正しく構成されていることを確認します。

  3. UNIX/Linux コンピューター上のメッセージ ログもチェックします。 たとえば、AIX では、 の下 /var/adm/messagesにログを見つけることができます。 その他のオペレーティング システムでは、場所が異なる場合があります。

    次のような行を探します。

    9 月 3 日 14:49:07 サーバー auth|security:debug /opt/microsoft/scx/bin/omiserver PAM: pam_authenticate: エラー認証に失敗しました。

    メッセージ ログに同様の行が表示される場合は、PAM 構成ファイルに OMIServer に関する情報が欠落していることを意味します。 PAM 構成ファイルは、ディレクトリまたはファイルにあります/etc/pam.d//etc/pam.conf。

    OMIServer に関する情報を PAM 構成ファイルに追加する最も簡単な方法は、そのコンピューターに SCX エージェントをゼロから再インストールすることです。 それが容易に不可能な場合は、OMI に関連する行を作業コンピューターから非稼働コンピューターにコピーできます。

WSMan のみの検出が 192.168.x.x で失敗しました

考えられる原因

  • [ 検出の種類] オプションが [ インストールされているエージェントと署名済み証明書を持つコンピューターのみ ] に設定され、ターゲット ホストにエージェントがインストールされています。 ただし、ターゲット ホスト証明書は署名されていません。 WSMan 専用検出オプションを使用するには、エージェントをインストールし、証明書を手動で署名する必要があります。
  • [ 検出の種類] オプションが [ インストールされているエージェントと署名済み証明書を持つコンピューターのみ] に設定されましたが、ターゲット ホストには UNIX/Linux エージェントが現在インストールされていません。
  • [ 検出の種類] オプションが [ インストールされているエージェントと署名済み証明書を持つコンピューターのみ] に設定されましたが、UNIX/Linux エージェントは現在実行されていません。
  • [ 検出の種類] オプションが [ インストールされているエージェントと署名済み証明書を持つコンピューターのみ] に設定されましたが、ターゲット ホストに到達できません。ネットワークまたはホスト ベースのファイアウォールによって接続が妨げられるか、UNIX/Linux エージェントが現在停止しています。

解決策

  • 証明書に手動で署名します。
  • UNIX/Linux エージェントがインストールされていることを確認します。
  • [ すべてのコンピューターを検出 する] オプションを変更して、探索ウィザードで証明書の署名を実行できるようにします。
  • UNIX/Linux エージェントが実行されていること、およびターゲット ホストに到達可能であることを確認します。
  • TCP ポート 1270 でのアクセスを妨げているネットワーク ファイアウォールまたはホスト ファイアウォールがないことを確認します。

その他のエラー

タスクのターゲットがオブジェクトのどのクラスにも一致しないため、オブジェクトに対してタスクを実行できません

原因

System Center 2012 Operations Manager 管理グループでは、インポートされた UNIX/Linux 管理パックが Operations Manager 2007 R2 バージョンである場合に発生する可能性があります。

解決策

UNIX/Linux オペレーティング システム管理パックの System Center 2012 バージョンをインポートします。

エージェントがインストールされ、コンピューターは Operations Manager によって既に監視されています

原因

ターゲット ホストは、この管理グループで既に検出されています。

Resolution

何もする必要はありません。 エージェントのアップグレードまたは代替リソース プールへの移行は、オペレーション コンソールの [管理] ウィンドウの [UNIX/Linux サーバー] ビューから実行できます。

インポートされた管理パックでサポートされている一致するエージェント インスタンスが見つかりません

エラーの説明

インポートされた管理パックで、サポートされている一致するエージェント インスタンスを見つけることができませんでした。 このコンピューターを検出するには、このプラットフォームの管理パックをインポートします。

考えられる原因

  • ターゲット ホストで、サポートされていないオペレーティング システムが実行されています。
  • ターゲット ホストのオペレーティング システムの正しい管理パックがインポートされていません。
  • オペレーティング システムの正しい管理パックは最近インポートされましたが、まだ完全には読み込まれていません。

解決策

  • ターゲット ホストがサポートされているオペレーティング システムを実行していることを確認します。
  • ターゲット ホストのオペレーティング システムとバージョンの管理パックをインポートします。
  • 管理パックがインポートされた場合は、まだ読み込まれている可能性があります。 数分待ってから、検出を再実行します。

インストール可能なエージェントの種類を列挙できません。 関連付けられているリソース プールがまだ初期化中である可能性があります

エラーの説明

インストール可能なエージェントの種類を列挙できません。 関連付けられているリソース プールがまだ初期化中である可能性があります。 新しく作成したリソース プールを選択した場合は、数分待ってから使用してください。

考えられる原因

  • 検出で使用されるリソース プールは正常ではありません。たとえば、メンバー サーバーの大半がオフラインです。
  • 検出で使用されるリソース プールは最近作成されましたが、完全には初期化されていません。

解決策

検出で使用されたリソース プールが最近作成された場合は、数分後に検出を再試行して、プールの初期化を許可します。 それ以外の場合は、問題の原因を示す検出に使用されるリソース プールのメンバーであるサーバー上の Operations Manager イベント ログをチェックします。

このコンピューターに新しいエージェントをコピーできません

エラーの説明

メッセージ: このコンピューターに新しいエージェントをコピーできません
詳細：
キットのコピーに失敗しました。 終了コード: -1073479144
標準出力:
標準エラー:
例外メッセージ: SSH コマンドが失敗する原因となった例外 (-1073479144)

原因

ファイル エージェントのバージョンがデータベースとエージェント リポジトリの間で一致しません。

解決策

  • バージョンの不一致が原因で、失敗したエージェントがすべて失敗していることを確認します。 それ以外の場合は、他のトラブルシューティング手順を適用します。
  • 失敗したエージェントをもう一度更新してみてください。 通常、失敗したエージェントの一覧は、更新の繰り返しごとに短くなります。
  • Unix または Linux マシンを管理するために、Linux リソース プールまたはその他のプールのすべてのメンバーで Health Service を再起動します。 ファイル名が %ProgramFiles%\Microsoft System Center 2012 R2\Operations Manager\Server\AgentManagement\UnixAgents\DownloadedKits 正しいかどうかを確認します。 探索ウィザードを閉じてもう一度開きます。

詳細

詳細については、TechNet サポート フォーラムを参照するか、Microsoft サポートにお問い合わせください。