ePO では、ePO システム ツリーに特定のシステムの複数のエントリがある場合があります。 これらのエントリは、一般に 重複 システムとして知られています。 この記事では、さまざまな種類の重複システム、それらがシステム ツリーで作成される方法、および問題のトラブルシューティング方法について説明します。


管理対象 vs 管理対象外（タイプ 1）
ePO で重複システムを処理する場合、最初に尋ねる質問は次のとおりです: すべての重複エントリは管理対象として表示されますか、それとも一部は管理対象外として表示されますか？

• 管理対象
  システムにエージェントがインストールされていて、ePO と少なくとも 1 回通信している場合、システムは ePO で管理対象としてのみ表示されます。
  
• 管理対象外

1 つのシステム ツリー エントリの複数の行（タイプ 2）
2 番目のタイプの複製システムは、厳密に言えば複製ではありません。 これは、ePO に実際のシステムが 1 つしかない場合でも、システム ツリーに同じシステムの複数の行が表示されるシナリオです。

このシナリオの現象は次のとおりです。

• エージェント GUID、およびすべてのエントリの最後の通信時間の列は同じです。
• いずれかのシステムのチェック ボックスを選択すると、他のシステムも自動的に選択されます。

この問題は、システムに同じ製品または製品ファミリの複数のバージョンがインストールされていると ePO が判断した場合に発生します。 システム ツリーには、インストールされている製品バージョンを示す列があります。



上記の場合、ePO は、システムにバージョン 8.8.0.2232 と 8.8.0.2233 の両方の VirusScan Enterprise がインストールされていると見なしますが、これは不可能です。 システム ツリー ビューから関連する列を削除することで、この問題を回避できます。 この場合、製品バージョン (VirusScan Enterprise)」列です。
注: 上記は表面的な修正にすぎず、根本的な問題に対処していません。 根本原因を正しく解決するには、 KB93129 - 単一のシステムに対して表示される重複した管理対象製品エントリ を参照してください。


作成してはいけないときに作成された新しいシステム ツリー エントリ（タイプ 3）
3 番目のタイプの重複システムは、診断が最も複雑です。 この問題は、管理対象システムのシステム ツリーにすでにエントリがあり、ePO と通信する場合に発生します。 ePO は、既存のエントリを更新するのではなく、それを新しいシステムと見なし、そのエントリを作成します。

このシナリオの giveaway の症状は次のとおりです。

• エージェント GUID、および最終通信時間は、エントリごとに異なります。
• いずれかのシステムのチェックボックスを選択すると、他のシステムは自動的に選択されません。
• エントリの 1 つだけがアクティブです。 たとえば、クライアント システムが通信する場合、最後の通信時刻は、重複するシステムの 1 つでのみ更新されます。

このシナリオの例は次のようになります。



注: 上の画像は最後の通信を示しており、エージェント GUID 値はすべて異なります。

このシナリオで重複するシステムを適切にトラブルシューティングするには、ePO がシステムの新しいエントリを作成する必要がある時期を決定する方法を理解する必要があります。

システムが ePO と通信するたびに、ePO には 2 つのアクション コースがあります。

• システムはすでに ePO に認識されています。 この場合、ePO はそのプロパティを更新し、新しいポリシーまたはタスクがあるかどうかを確認する必要があります。
  
• システムが ePO に認識されていません。 この場合、ePO はシステム ツリーに新しいエントリを作成する必要があります。

ePO は、システムが既知かどうかを判断するために、いくつかの質問を行います。

• 最初の質問は「このシステムは VDI モードのクライアントですか？」です。
  • 答えが「はい」の場合、ePO はシステムを異なる方法で扱います。 このトピックについては、この記事の後半で詳しく説明します。
    
• システムが VDI クライアントでない場合、次の最も重要な質問は「エージェント GUID はすでにデータベースにありますか？」です。
  • GUID がデータベースにある場合、システムはすでに ePO に認識されており、「プロパティの更新」の一連のアクションに従います。
  • GUID がデータベースにない場合は、新しいシステムである可能性があるため、ePO は「新しいエントリの作成」パスに従い始めます。

システムが GUID を変更する可能性があります。 最も一般的な原因は次のとおりです。

• エージェントをアンインストールして再インストールするか、コマンド オプション /forceinstall を使用して再インストールします。
• システムはイメージから再構築されました。
• システムのハードウェアが変更されました。 たとえば、ハードドライブは 1 つのラップトップから取り出され、別のシャーシに配置されました。 このアクションにより、エージェントが次に起動したときに SMBiosUUID が異なります。 その結果、エージェントは新しいエージェント GUID を作成します。

ePO が GUID が既知であることを確認しただけの場合、システムが合法的に新しい GUID を取得すると、ePO はその GUID の新しいエントリを作成します。
注: この事実は、以前のバージョンの ePO がどのように機能していたかを示しています。 システムが頻繁に再構築されていた環境では、この動作により、許容できない数の重複エントリが作成されました。 そのため、ePO の動作が変更されました。

「新しいエントリの作成」パスの最初のステップとして、別のチェックが追加されました。 システムが ePO と通信するとき、システムが送信する最初のメッセージには（とりわけ）次のものが含まれます。

• エージェント GUID。
• エージェントによって検出された MAC アドレス。

ePO がエージェント GUID を認識していない場合、同じ MAC アドレスを持つエントリがデータベースにあるかどうかを確認します。 答えが「はい」の場合、ePO は、ePO とすでに通信していて、エージェント GUID を変更したシステムであると見なします。 そのため、「プロパティの更新」パスに戻り、新しいエージェント GUID を使用して同じ MAC アドレスで既存のエントリを更新します。

上記は重要なポイントです。 MAC アドレス チェックは、クライアントによって報告された特定の MAC アドレスがデータベース内の他の場所に存在するかどうかを確認するだけです。 ePO は、特定のシステムに対して 1 つの MAC アドレスのみを保存し、システムが通信するたびにそれを更新します。 ePO によって保存された MAC アドレスは、クライアントが最後に通信したときに報告されたアドレスです。

複数のシステムが同じ MAC アドレスを持つことができる特定のシナリオがあります。 一般的な例は次のとおりです。

• 仮想プライベート ネットワーク（VPN）コンセントレーターを介して接続するシステム
• チーム化されたネットワーク インターフェイス カード（NIC）を使用して、サーバー クラスターなどの仮想 MAC アドレスを提示するシステム。

上記のシナリオでは、追加の MAC アドレス チェックが問題を引き起こします。 具体的には、重複システムの正反対です。 代わりに、ePO に単一のエントリが作成され、最後に通信したシステムの詳細で継続的に更新されます。 これにより、システムが表示され、ツリーから消えるように見えます。 この問題に対処するには、MAC アドレスを上書きして、いくつかの方法で確認できます。

• まず、レジストリキーを設定し、ePO サービスを再起動することで、ePO で MAC チェックをグローバルに一時的に無効にすることができます。 この方法は、チーム化された NIC シナリオで最も一般的に使用されます。MAC アドレス チェックが無効になり、チーム化された NIC クラスターの両方のノードが ePO と通信できるようになります。 GUID が異なるため、各ノードにはシステム ツリーに作成されたエントリがあります。 次に、MAC アドレス チェックが再度有効になり、GUID を変更する他のシステムが重複エントリを作成しないようにします。
  MAC アドレス チェックを無効にするには、 KB57886 - MAC アドレスを共有している場合、ePolicy Orchestrator ディレクトリ内のクラスターの両方のノードを表示できません を参照してください。
  
• VPN 経由で接続するシステムの場合、Organization Unique Identifier（OUI）に基づいて MAC チェックを選択的にスキップするように ePO を構成できます。
  注: OUI は、MAC アドレスの最初の 6 文字であり、ネットワーク デバイスのベンダーを識別するために使用されます。
  
  複数の OUI を ePO に追加できます。不明な GUID を持つシステムが ePO と通信すると、システムの OUI がデータベース内のリストと比較されます。 一致するものが見つかった場合、ePO は MAC チェックをスキップし、システムの新しいエントリを作成します。 詳細については、ePO 製品ガイドの仮想 MAC ベンダーの追加 を参照してください。

MAC アドレス チェックが無効になっておらず、システムの OUI が ePO に認識されているリストに含まれていないと想定します。 次に、MAC アドレス チェックの答えが「いいえ」の場合、ePO はコンピューターが新しいシステムであると判断し、「新しいエントリの作成」パスを完了します。 システムが実際にシステム ツリーにエントリを持っている場合は、複製が作成されるポイントです。

上記の状況を示す例:

• エージェントがインストールされたラップトップがあると想像してください。 エージェントは問題なく ePO と通信しています。
• 1111111111 のエージェント GUID があります。
• 11:11:11:11:11:11 の MAC アドレスで Wi-Fi 経由でネットワークに接続されています。 Eこの時点で、ePO データベースでは、このシステムの GUID は 1111111111 です。 前回通信したため、ワイヤレス NIC を使用していました。ePO はこのシステムの MAC アドレスを 11:11:11:11:11:11 として記録しました。
• 突然、致命的なソフトウェア クラッシュが発生し、IT 部門がイメージを再作成する必要があります。
• IT エンジニアは、ラップトップの有線 NIC を使用してラップトップをネットワークに接続します。 NIC の MAC アドレスは 22:22:22:22:22:22 です。 エンジニアはオペレーティング システムとエージェントを再インストールします。
• エージェントが初めて起動するときは、まったく新しいインストールであるため、2222222222 の新しいエージェント GUID を生成し、ePO と通信します。
• ePO は、最初に GUID が 2222222222 のエントリをデータベースで検索します。 エントリが見つからないため、MAC チェックを続行します。
• 次に、ePO はデータベースを検索して、MAC アドレスが 22:22:22:22:22:22 のエントリを探します。 また、見つからないため、ePO は GUID 2222222222 と MAC アドレス 22:22:22:22:22:22 で新しいエントリを作成します。 これで、エントリが重複しました。 同じシステムの 2 つのエントリで、そのうちの 1 つだけがアクティブです。

注: IT エンジニアが Wi-Fi を使用してネットワークに接続している場合、重複するエントリは作成されません。 新しい GUID がデータベースに存在しないため、最初の GUID チェックは失敗します。 ただし、MAC アドレスのチェックは成功するため、ePO は「プロパティの更新」パスに戻り、既存のエントリを新しい GUID で更新します。
上記は注意すべき重要なポイントです。 複製を作成するために、システムは新しい MAC アドレスを報告する必要はありません。 前回 ePO と通信したときとはまったく異なります。

VDI モード クライアントの特殊なケース
非永続的な VDI 環境の場合、エージェントは VDI モードと呼ばれる特別なモードで動作できます。 このモードにより、ePO は、VDI クライアントが常に同じ GUID を使用することを確認できます。 これにより、ePO はプロビジョニング解除とプロビジョニングのサイクルを通じて特定のクライアントを追跡できます。
VDI モードの詳細については、 KB87654 McAfee Agent のプロビジョニングと仮想デスクトップ インフラストラクチャ システムへの配備 を参照してください。

概要:

• VDI クライアントがシャットダウンすると、エージェントは特定のメッセージを ePO に送信します。
• 次に、ePO は、そのシステムをデータベースでプロビジョニング解除されたものとしてタグ付けします。
• VDI モード エージェントが ePO と通信するとき、通信の開始時に VDI モードであることを ePO に通知します。
• ePO は、データベースに同じ完全修飾ドメイン名を持つエントリがあるかどうか、およびプロビジョニング解除としてタグ付けされているかどうかを確認します。
• 見つからない場合、ePO はシステムの新しいエントリを作成します。
• ePO は、GUID または MAC アドレスが存在するかどうかを確認しません。 非永続的な VDI 環境では、両方は関係ありません。

上記の意味は、VDI 環境でのことです。

• ePO がプロビジョニング解除メッセージを受信できない場合は、次にそのクライアントがプロビジョニングされたときに、ePO が重複するエントリを作成することが保証されます。
• 最も一般的な原因は、VDI クライアントが正常にシャットダウンされていない場合です。 たとえば、クラッシュしたり、ホストがシステムを強制的にシャットダウンしたりした場合です。

以下のフローチャートは、システムが ePO と通信するたびに ePO が従うディシジョン ツリーを示しています。



トラブルシューティング
これで、ePO が新しいエントリを作成するタイミングを決定する方法がわかったので、エントリが作成される理由をトラブルシューティングできます。

ご存知のように、ePO が新しいエントリの作成を決定するには、GUID を認識していてはなりません。 したがって、最初の質問は、「クライアント GUID が変更されたのはなぜですか？」です。

クライアントが新しい GUID を作成する最も一般的な方法は次のとおりです。

• エージェントがアンインストールされ、再インストールされました。
• エージェントは /forceinstall スイッチを使用してアップグレードされたか、Force installation over existing version オプションが選択された状態で ePO からデプロイされました。
• エージェントは、ハードウェアの変更を示す新しい SMBiosUUID を検出しました。 たとえば、ハード ドライブをあるラップトップから別のラップトップに移動しました。
• エージェントのヘルス チェックに失敗しました。 これにより、データベース ファイルが再生成され、新しいエージェント GUID が作成されました。

最初のトラブルシューティングの質問は、「この GUID の変更は予想されますか？」です。
たとえば、システムが再構築されていることがわかっている場合、またはエージェントがアンインストールされて再インストールされている場合は、新しい GUID が発生することがわかります。

新しい GUID が予期されていなかった場合、最初のステップは、GUID が変更された理由を調査することです。

• エージェントのインストール ログ (frminst.log) を確認します。
  • エージェントは最近 /forceinstall オプションでインストールされましたか？
  • その場合、マカフィーはこのオプションの一般的な使用を推奨していません。 特特定の状況でのみ使用する必要があります。 たとえば、 /instdir スイッチを使用してエージェントを新しい場所にアップグレードしようとしている場合などです。
• mascvc log ログファイルを調べます。
  • GUID が変更された証拠を探します。
  • たとえば、MA healthcheck が失敗した場合です。 「maconfig.Error: MA databases integrity check failed」というエラーメッセージが表示されます。

GUID が変更された理由を特定したら、次のトラブルシューティング手順は、ePO が MAC アドレスをデータベース内の前のエントリと一致させなかった理由を特定することです。

最初に行うことは、ePO が MAC チェックをスキップするように構成されていないことを確認することです。

1. エージェントが誤って VDI モードでインストールされていないことを確認してください。
2. ePO でシステムのシステム プロパティを表示します。 プロパティのリストの下部を見てください。VDI プロパティが配置されている場所です。 エージェントが VDI モードでインストールされている場合は、「はい」である必要があります。
3. エージェントが VDI モードであることが想定されていない場合は、 /EnableVDIMode スイッチを使用せずに、エージェントをアンインストールしてから再インストールします。
4. MAC 検索がグローバルに無効になっていないことを確認してください。 KB57886 - MAC アドレスを共有している場合、ePolicy Orchestrator ディレクトリ内のクラスターの両方のノードを表示できません を参照してください。
   注: 上記の設定は、エージェント ハンドラーごとに適用されます。 したがって、複数のエージェント ハンドラーがある場合は、それらすべてをチェックし、MAC 検索が無効になっていないことを確認してください。
5. システムが VPN 経由で接続していない場合は、エージェントの MAC アドレスの OUI が誤って ePO の仮想 MAC ベンダー リストに追加されていることを確認してください。 存在する場合は、関連する OUI を削除します。

上記のいずれにも当てはまらないと仮定すると、クライアント システムによって提供された MAC アドレスが ePO データベースに見つかりませんでした。 これにより、ePO は新しいエントリを作成します。

1. ePO 監査ログを調べて、クイック検索フィルターにクライアント システム名を入力します。 ePO がエントリを作成すると、「ASCI - New System」イベントが表示されます。 表示されるイベントの詳細は、クライアントが報告した MAC アドレスです。
2. 最新の重複エントリの詳細をシステム プロパティの MAC アドレスと比較します。 このエントリは、複製が作成される前にシステムによって使用された MAC アドレスです。
   
   上記は、ePO が MAC アドレスと一致しなかった理由を説明するのに役立つ場合があります。 たとえば、前のエントリにはワイヤレス アダプタの MAC アドレスが含まれ、監査ログ エントリにはドッキング ステーション アダプタのアドレスが含まれている場合があります。

概要

• 結論として、ePO でエントリが重複する最も一般的な原因は、クライアント システムでの新しい GUID の不要な作成です。
• 次に、この問題の最も一般的な原因は、 /forceinstall スイッチを使用してエージェントを再インストールするようなものです。 スケジュールされたサーバー タスクまたはログオン スクリプトの一部として表示されます。
• 重複エントリがどこから来ているのかを理解するための鍵は、最初に GUID が変更されている理由を発見することです。 理由がわかれば、問題の原因を特定するのは非常に簡単です。