ルールベースのCollector割り当て（クラシック）
概要
ルールベースのコレクター割り当てには、すべてのコレクターのためにNexthinkインスタンスの完全修飾ドメイン名 (FQDN) を使用する単一のインストーラーが必要です。 最初の接続時、各コレクターは割り当てられたNexthink V6エンジンのアドレスを受け取ります。 その後、コレクターは通常通りエンジンに情報を送信し始めることができます。 Nexthinkへの次回の接続時には、各コレクターは同じエンジンに割り当てられているか、別のエンジンに割り当てられているかを確認し、必要に応じてエンジンを切り替えます。
Nexthinkは、セットされたルールを使用して割り当てプロセスを管理します。 それらを調整することで、コレクターを異なるエンジンに動的に再割り当てすることができます。 ルールは、コレクターをエンジンにだけでなくエンティティにも割り当てる基準を定義します。 これらは、デバイスを階層的に整理するための基礎を形成します。 同じルールによって指定されたエンティティ割り当ては、WindowsおよびMacのコレクターのインストールのいかなるバージョンでも有効です。
ルールベースのコレクター割り当てのサポート
ルールベースの割り当ては、次のデバイスフィールドの条件を持つルールをサポートします。
最後のIPアドレス
最後のローカルIPアドレス
名前
コレクターによって報告された識別名
ADサイト
コレクタータグ番号
コレクター文字列タグ
エンジン間を移動するデバイスが存在せず、デバイスの最後のIPアドレスのみに基づいた割り当てであることを確認してください。 バージョン V6.24 以降、最後のローカルIPアドレスを使用することでこの問題を解決します。
条件がデバイスのIPアドレスに依存する場合、ローカルIPアドレスベータ機能は非推奨で V6.24 以降、最後のローカルIPアドレスフィールドに置き換えられたため、ルールベースのコレクター割り当てと互換性がありません。
割り当てルールの記述
CSVファイルを使用して、コレクターの割り当てルールを定義します。
あり
Engine-1
リヨン
ad_site
リヨン-?
dn
*OU=PROD*
いいえ
Engine-2
パリ
local_ip
192.168.212.0/24
名前
DESKTOP-FR*
あり
Engine-3
ロサンゼルス
collector_tag
212
いいえ
Engine-4
ニューヨーク
名前
DESKTOP-US*
ip
10.100.0.0/16
entity_rule (ケースセンス) 設定がnoの場合、ルールはデバイスをエンジンとエンティティの両方に割り当てます。 設定がyesの場合、ルールはエンジンでフィルタリングされたエンティティにデバイスを割り当てます。
Engine (ケースインセンシティブ) ターゲットエンジンのホスト名。
Entity (ケースセンス) ターゲットエンティティの名前。
Field1 割り当てに使用される最初のデバイスフィールドの名前。
Pattern1 指定されたエンジンとエンティティをデバイスに割り当てるために、最初に指定されたフィールドが一致しなければなりません。
Field2 割り当ての基準となる第2のデバイスフィールドの名前。
Pattern2 指定されたエンジンとエンティティをデバイスに割り当てるために、第2に指定されたフィールドが一致しなければなりません。
Field1およびField2列は、次の値をサポートします。
ip
デバイスの最後のIPアドレス。 フィールドのパターンとして、次のいずれかを指定します:
- ドット十進表記の単一IPアドレス、例：192.168.10.1
- CIDR表記のサブネット、例：192.168.10.0/24
local_ip
デバイスの最後のローカルIPアドレスは、ローカルネットワーク上のIPアドレスに対応します。 パターン指定は、ipフィールドの場合と同じ方法で行います。
name (ケースインセンシティブ)
デバイスのホスト名。
collector_tag
インストール時にコレクターに割り当てられるタグ番号。 正確な番号だけが一致します。
collector_string_tag
インストール時にコレクターに割り当てられるラベル。この値はパターンマッチングをサポートしています。
dn
コレクターによって報告されたデバイスの識別名。 デバイは、Active Directoryドメインの一部でなければなりません。
コレクターによって報告された識別名の形式は、最も具体的な属性から最も一般的な属性まで、カンマで接続されたattribute=value 要素の標準的なシーケンスです。 例： CN=ex01,OU=Computers,DC=example,DC=org
対照的に、Active Directoryから取得されるデバイス (またはユーザー) の識別名フィールドは、似たようなシーケンスを用いますが、逆順であり、要素はスラッシュで接続されます。 例：/DC=org/DC=example/OU=Computers/CN=ex01
ad_site
デバイスが配置されているActive Directoryサイト。 サイトは、一つ以上のTCP/IPサブネットを表します。
name, collector_string_tag, dn, および ad_site フィールドは、文字パターンマッチをサポートします。 関連する文字列パターンを定義するには、次のワイルドカードを使用します。
- ? 文字は一つの文字を置き換えます。
- * 文字は0個以上の文字を置き換えます。
ヘッダーの後に、各ルールを新しい行に記述してください。 各アイテムをダブルクォートで囲んで、システムが特殊文字を避けることを確認し、区切り文字としてセミコロンを使用してください。 たとえば、さまざまなタイムゾーンに支社がある小企業のCSVファイル:
ルールが満たされるためには、Field1およびField2の条件が満たされなければならず、両方のパターンが一致しなければなりません。 ルールの優先順位は上から下へと決まります。 エンティティのみのルールは、特に固定された、移動中のまたはVPNデバイスが空の - エンティティに割り当てられるのを防ぐ、デフォルトケースをキャッチするためのものです。
CSV ファイルをアップロードする方法:
中央管理者プロファイルを持つアカウントでNexthinkウェブインターフェースにログインします。
メインナビゲーションバーの システム構成 下の コレクター を選択し、 管理 メニューから 管理 タブを選択します。
新しいルールセットを追加 ボタンをクリックします。
ダイアログボックスのフィールドに記入してください。
RULESET NAME にルールの一意な名前を入力してください。
DESCRIPTION にルールの目的を説明してください。
CSV FILE の下で、新しいファイルをアップロード をクリックし、以前に作成したCSVファイルを選択します。
コレクター割り当てのシミュレーション
別のルールセットへのスムーズな移行のために、Nexthinkはまずルールをシミュレートすることを強く推奨します。 コレクター割り当てルールのシミュレーションにより、現在のエンジンとエンティティの割り当てを実際に変更することなく、ルール適用による効果を確認できます。
シミュレーションモードを有効にするには:
中央管理者プロファイルを持つアカウントでNexthinkウェブインターフェースにログインします。
メインナビゲーションバーの システム構成 下の コレクター を選択します。
シミュレート をクリックしてプロセスを開始します。
結果は、ウェブブラウザーが自動的にダウンロードするCSVファイルに保存されます。 インスタンスにリンクされたすべてのデバイスと、それらのプロパティの一部が列に整理されてリストされます。 最後の列にはシミュレーション値が含まれます。
device-36e68c7a
6.30.4.9
194.3.224.3
10.19.3.61
c40034
1000
ボストン
22.11.21 19:03
10.244.14.5:8443
-
ボストン
-
UNKNOWN（NOと見なされる）
engine-1
ボストン
assigned
engine-1
ボストン
device-938b6df4
22.2.1.22
194.3.224.3
10.18.6.2
c40034
1000
マドリード
24.02.22 12:07
10.244.14.5:8443
-
マドリッド
-
不明 (NOと見なされます)
エンジン-1
マドリッド
割り当て済み
エンジン-1
マドリッド
デバイス-8cfae42b
21.7.1.19
194.3.224.3
10.5.3.23
c40034
1000
ボストン
11.10.21 23:05
10.244.14.133:8443
-
ボストン
-
不明 (NOと見なされます)
エンジン-1
ボストン
割り当て済み
エンジン-1
ボストン
デバイス-1df8e1ce
21.7.1.19
194.3.224.3
10.29.2.4
1000
マドリッド
13.10.21 13:20
10.244.14.133:8443
-
マドリッド
-
不明 (NOと見なされます)
エンジン-1
マドリッド
割り当て済み
エンジン-1
マドリッド
デバイス-784c6e93
21.8.1.24
194.3.224.3
10.21.22.15
1000
ロンドン
14.10.21 16:16
10.244.14.133:8443
-
ロンドン
-
不明 (NOと見なされます)
エンジン-1
ロンドン
割り当て済み
エンジン-1
ロンドン
デバイス-51d1eb73
6.30.4.11
194.3.224.3
10.9.4.3
0
不明
01.11.21 11:32
10.244.14.133:8443
-
デフォルト
-
不明 (NOと見なされます)
エンジン-1
デフォルト
割り当て済み
エンジン-1
デフォルト
デバイス-a639e2f6
21.8.1.25
194.3.224.3
10.26.17.12
9c6a68
0
-
23.11.21 15:00
10.244.14.5:8443
-
デフォルト
-
不明 (NOと見なされます)
エンジン-1
デフォルト
割り当て済み
エンジン-1
デフォルト
デバイス-9acf29ca
6.30.4.9
194.3.224.3
10.5.19.6
c40034
1000
不明
24.11.21 18:53
10.244.14.5:8443
-
デフォルト
-
不明 (NOと見なされます)
エンジン-1
デフォルト
割り当て済み
エンジン-1
デフォルト
シミュレーションに続いてダウンロードされたCSVの一部の例。
収集機の発見
インスタンスに接続している収集機のリストを確認してください。
中央管理者プロフィールを持つアカウントでNexthinkウェブインターフェースにログインします。
メインナビゲーションバーの管理メニューから、システム設定の下の収集機を選択します。
インスタンスに関連付けられたデバイスのリストをデバイスの下で確認します。
すべてをエクスポート」をクリックして、リストを完全に取得します。
表の列は、収集機の割り当て状況に関する現在の情報を提供します。 これらの列には、以下のプロパティが含まれます:
デバイス名
コレクタバージョン
IPアドレス (最後のもの)
ADサイト
識別名
収集機タグ番号
さらに、以下の追加の列が見つかります:
最終確認 (UTC)
収集機から受信した最後の割り当てリクエストの時間。
最終確認場所
収集機が最後に確認されたアプライアンスのIPアドレスとポート。
割り当てエンジン
収集機がデータを送信するように設定されたエンジン。
割り当てエンティティ
収集機が現在所属するエンティティ。
ローミング開始 (UTC)
デバイスがローミングを開始した時間。
エラーメッセージ
収集機の割り当てで発生した最後のエラー。
再割り当て
Nexthinkインスタンスが収集機にエンジンを正常に割り当てた後、収集機は割り当てられたエンジンから新しい割り当て情報を受信し、それをNexthinkインスタンスから受け取ります。 収集機はTCP接続が中断されるたびに新しい割り当て情報を要求します。
さらに、収集機は割り当てルールが変更されるたびに別のエンジンに動的に再割り当てされます。 収集機への再割り当てメッセージの配布には最大60分かかることがあります。
一方で、望ましくないエンジンスイッチの回数を制限するために、プロパティが変更されたデバイスの再割り当ては、新しいルールが適用されてから10日後に遅延されます。 これは、特にサブネットを頻繁に変更するデバイス、たとえばローミングユーザーのラップトップにとって重要です。
割り当て失敗シナリオ
収集機が新しい割り当てを受け取ると、最初のFQDNを宛先として割り当てられたエンジンにTCP接続を確立しようとします。 収集機が3回再試行しても到達できない場合は、以前に割り当てられたエンジンを使用して失敗を報告します。 その後、新しい割り当てを待ちます。 待機中、収集機はトラフィックを送信しません。
割り当てが失敗したかどうかを確認するには:
中央管理者プロフィールを持つアカウントでNexthinkウェブインターフェースにログインします。
メインナビゲーションバーの管理メニューから、システム設定の下の収集機を選択します。
インスタンスに関連付けられたデバイスのリストをデバイスの下で確認します。
エラーメッセージ列で、以下のような値を持つリストエントリを探します: \n
Last assignment failed: engine [IP address] tcp port [number]: ...デフォルトで表示されるのは100台のデバイスのみです。 すべてをエクスポート」をクリックして、リストを完全に取得します。
Last updated
Was this helpful?