製品構成

デバイスの位置と組織

製品構成はデバイス管理の2つのカテゴリに対応します。

位置

ロケーションカテゴリにより、リモート従業員のデジタルエクスペリエンス（DEX）をより動的に洞察することができます。 イベント時にデバイスがどこにあるかを知ることで、問題を効果的にトラブルシューティングし、従業員にロケーションに関係なく同じレベルのデジタルエクスペリエンスを提供することができます。

Nexthinkはイベントを追跡するための次の方法を提供します：

• ルールベースの位置タイプ：IPアドレスやその他の識別子に基づいてカスタムルールを作成できます。

• 地理的な位置：デバイスの公開IPアドレスとGeoIPデータベースに依存します。

Nexthinkは可能な限りルールベースの位置を使用することを推奨しています。これにより精度が高く、柔軟性があります。 しかし、システムがルールベースの位置を割り当てられない場合、GeoIPを代替として使用します。

組織

組織カテゴリは、デバイスと組織構造との関係を定義することを可能にします。

• ユーザーに対して、任意の詳細度でのアクセス権や管理権限を指定する。例えば、ITサポートユーザーの権利を担当する地域や部門に割り当てる。

• 適切なユーザーにコンプライアンス責任とパッチ適用の責任を割り当てる。

• ハードウェア更新の必要性を適切なレベルで追跡する。

あるデバイスの組織は比較的静的である一方、その位置は頻繁に変わる可能性があります。 以下の例は、スイスのエンティティが所有するデバイスの可能な位置のいくつかを示しています。

• デバイスはスイスのローザンヌのオフィスにあります。

• デバイスは米国のボストンオフィスにあります。

• 社員はローザンヌの自宅でリモートワークをしています。

• 社員はボストンのホテルで仕事をしています。

製品構成へアクセスする

• メインメニューから Administration を選択します。

• ナビゲーションパネルのシステム構成セクションで製品構成をクリックします。 この機能を見るには管理者権限が必要です。 詳細については、役割 ドキュメントを参照してください。

デバイスのロケーションを設定

ジオロケーションを有効にする

Nexthink は、GeoIP データベースと Collector を実行しているシステムのパブリック IP アドレスを参照して、インターネット上のデバイスの位置を特定することができます。

ジオロケーション機能はデフォルトで無効になっており（"位置データを一切取得しない"）、ドロップダウンメニューで利用可能なオプションのいずれかにロケーションの粒度を設定して有効にできます。

• 位置データを取得しない

• パブリック IP のみ

• パブリック IP と国

• 公開IP、国、州

• 公開IP、国、州、市

仮想プライベートネットワーク (VPN) を使用すると、Collector によって報告されたパブリック IP アドレスに影響を与えます。 ジオロケーションの精度を高めるためには、CollectorとNexthinkインスタンスの間でVPNを経由してトラフィックをルーティングしない方が良いです。 この機能は Collector のいかなるバージョンでも動作し、情報は Nexthink プラットフォームを離れることはありません。 Nexthink は、独自のジオロケーションデータベースを持ち、内部的にジオロケーションの照会を行います。

ルールベースの位置の割り当てを設定

Nexthink プラットフォームには、デバイスの位置を判断できるルールベースの割り当てプロセスが含まれています。 この機能は高度に構成可能で、ルールを変更して調整できます。

表形式の CSV ファイルを使用して割り当てを設定します。 表の各行には、2つのパターンと位置の割り当てが含まれています。

CSV ファイルの例

コンマで区切られた割り当てテキストファイルの例:

Field1,Pattern1,Field2,Pattern2,Location Type,Site,State,Country
primary_local_ip,10.0.0.0/8,name,NXT*,Onsite,Lausanne,VD,CH
primary_local_ip,172.16.0.0/16,,,Onsite,Boston,MA,US
name,*,,,Remote

上記のテキストファイルからの割り当てルールを示す表:

• 最初のルールは、名前が NXT で始まるローカルサブネット 10.0.0.0/8 に属するすべてのデバイスに Onsite をタグ付けし、ロケーションサイトを Lausanne に割り当てます。

• 二番目のルールは、ローカルサブネット 172.16.0.0/16 に属するすべてのデバイスに Onsite をタグ付けし、ロケーションサイトを Boston に割り当てます。

• 三番目のルールは、その他すべてのデバイスに Remote をタグ付けします。

ルールを満たすためには、対応するフィールドとパターンが一致しなければなりません。 システムは、テーブルの上から下にかけてルールの優先順位を確立します。 テーブルの上により具体的なデバイスの割り当てを行い、下に向かうほど一般的にします。

• Field1: 割り当てに使用する最初のフィールドのデータ

• Pattern1: 最初のフィールドのパターン

• Field2: 割り当てに使用する第二のフィールドのデータ

• Pattern2: 第二のフィールドのパターン

• ロケーションタイプ: ターゲットロケーションタイプの名前。 許可されるロケーションタイプ値は以下のものがあります:

  • Onsite

  • Remote

  • Unknown

• サイト: デバイスまたはデバイスがある場所のカスタム名。

• 州: デバイスまたはデバイスがある場所の ISO 3166-2 サブディビジョンコード。 このフィールドを使用して州、県、カントンなどを示します。 例として、スイスのヴォー州の場合: VD

• 国: デバイスまたはデバイスがある場所の ISO 3166-1 アルファ-2 国コード。 例として、スイスの場合: CH

Field1 と Field2 のサポートされている値:

• name: デバイスのホスト名。

• collector_tag: Collector のインストール時に割り当てられたタグ番号。 正確な番号のみが一致します。

• collector_string_tag: Collector のインストール時に割り当てられたラベル。 この値はパターンマッチングをサポートします。

• configuration_tag: デバイスのグループを特定するための設定可能なラベル。 このフィールドの値は、Enrichment APIを使って設定します。 この値はパターンマッチングをサポートしています。

• dn: Collector が報告するデバイスの識別名。 デバイスはアクティブディレクトリドメインの一部である必要があります。 Collector によって報告される識別名の形式は、最も特定的な属性から最も一般的な属性への 属性=値 要素の標準シーケンスです。 例: CN=ex01,OU=Computers,DC=example,DC=org

• ad_site: デバイスがあるアクティブディレクトリサイト。 name, collector_string_tag, dn, ad_site フィールドは文字パターンの一致をサポートします。 関連付けられた文字列パターンを定義するために、次のワイルドカードを使用してください。

  • ? 文字は1文字を代替します。

  • * 文字は0文字以上を代替します。

• ip: デバイスの最後のパブリック IP アドレス。 フィールドのパターンとしては、次のいずれかを指定します:

  • ドット10進表記の単一の IP アドレス、例: 192.168.10.1

  • CIDR 表記のサブネット、例: 192.168.10.0/24

• primary_local_ip: 主な物理ネットワークアダプタのためのデバイスの最後のローカル IP。 ip フィールドと同じ方法でパターンを指定してください。

• collector_local_ip: エンドポイントと Nexthink インスタンス間のトラフィックに使用されたローカル IP。 ipフィールドと同じようにパターンを指定してください。

• wifi_ssid: プライマリネットワークアダプタに関連付けられたWiFiネットワーク名（SSID）。 この値はパターンマッチをサポートします。

考慮事項

CSV 設定ファイルが以下の条件を満たしていることを確認してください。

• ファイルサイズが5MB未満です。

• ファイルのエンコーディングは UTF-8 です。

• カンマがフィールドセパレータです。

• フィールドデリミタはオプションであり、引用符 " のみが許可されるデリミタタイプです。

• ルールまたは行の合計数が40,000未満です。

• ユニークなサイトの最大数は2,000です。

• テーブルの最後の行に Field1=name と Pattern1=* を持つキャッチオールルールが入力されます。

これらのチェックのいずれかが失敗すると、ファイル選択は以前にアップロードされたファイルに戻ります。 エラーを修正した場合のみ、アップロードのブロックを解除することができます。

CSV ファイルのアップロード

CSV ファイルのアップロード手順については、右側のパネルの製品内ドキュメントを参照してください。

デバイス組織の設定

Nexthink プラットフォームには、デバイスの組織エンティティを動的に再割り当てできるルールベースの割り当てプロセスが含まれています。 さらに、エンティティをグローバルリージョンなどの上位の組織単位に分類することができます。

この機能は非常に設定可能であり、ルールを変更したり、組織のニーズに応じて独自のエンティティの分類を追加することで、割り当てを調整できます。

表形式の CSV ファイルを使用して割り当てを設定します。 表の各行には、2つのパターンとエンティティ名が含まれています。 オプションとして、エンティティのカスタム分類を含めることもできます。

CSV ファイルの例

コンマで区切られた割り当てテキストファイルの例:

Field1,Pattern1,Field2,Pattern2,Entity,region
,,,,,Global Region
name,device-d*,,,FRANCE,EUROPE
name,device-1*,,,CANADA,AMERICAS
collector_string_tag,CH*,,,SWITZERLAND,EUROPE
collector_string_tag,US*,,,UNITED STATES,AMERICAS
name,*,,,Unassigned,Unassigned

上記のテキストファイルからの割り当てルールを示す表:

テーブルの各行には2つのパターン、エンティティ名、およびオプションの追加カスタム分類が含まれています。 規則を満たすためには、パターンが対応するフィールドに一致しなければなりません。 システムは、テーブルの上から下に向かって規則の優先順位を決定します。 これにより、テーブルの上部でより具体的なデバイスの割り当てが必要になり、下部ではより一般的になります。

デバイスのnameがdevice-d100、collector_string_tagがCH10というデバイスがあると仮定します。 このデバイスは、最初および３番目の規則に一致します。 システムが最初にdevice-d100を評価するため、このデバイスはエンティティ「FRANCE」およびグローバル地域「EUROPE」に割り当てられます。

最初の5列は必須です：

• Field1: 割り当てに使用される最初のフィールドのデータ

• Pattern1: 最初のフィールドのパターン

• Field2: 割り当てに使用される2番目のフィールドのデータ

• Pattern2: 2番目のフィールドのパターン

• Entity: ターゲットエンティティの名前

必須の列に加えて、分類のために最大6つのカスタム列を追加します。

システムはヘッダー行を使用して分類のNQL IDを作成します。 これらの値にはスペースや特殊文字を含めることはできません。 2行目の値は表示名に対応しています。

1. #region はNQL IDです。

2. Global Region は分類のNQL IDの表示名です。

Field1 と Field2 のサポートされている値:

• name: デバイスのホスト名。

• collector_tag: Collectorのインストール時に割り当てられたタグ番号。 システムは正確な番号のみを一致させます。

• collector_string_tag: Collectorのインストール時に割り当てられたラベル。 この値はパターンマッチをサポートします。

• configuration_tag: デバイスのグループを特定するための設定可能なラベル。 このフィールドの値は、Enrichment APIを使って設定します。 この値はパターンマッチングをサポートしています。

• dn: Collectorによって報告される、デバイスの識別名。 デバイスはActive Directoryドメインの一部である必要があります。 Collectorによって報告される識別名の形式は、属性から一般的な属性までカンマで繋がれた属性=値要素の標準シーケンスです。 例として、CN=ex01,OU=Computers,DC=example,DC=org

• ad_site: デバイスが位置するActive Directoryサイト。 name, collector_string_tag, dnおよびad_siteフィールドは、文字パターンマッチングをサポートしています。 関連付けられた文字列パターンを定義するには、次のワイルドカードを使用します：

  • ?文字は単一の文字を置き換えます。

  • *文字は0個以上の文字を置き換えます。

• ip: デバイスの最後のパブリックIPアドレス。 フィールドのパターンとして、次のいずれかを指定します：

  • 例えば、192.168.10.1のようなドットデシマル表記の単一のIPアドレス

  • 例えば、192.168.10.0/24のようなCIDR表記のサブネット

• primary_local_ip: 主な物理ネットワークアダプタ用のデバイスの最後のローカルIP。 パターンをipフィールドで指定したのと同じ方法で指定します。

• collector_local_ip: エンドポイントとNexthinkインスタンスの間のトラフィックに使用されるローカルIP。 パターンをipフィールドで指定したのと同じ方法で指定します。

• wifi_ssid: プライマリネットワークアダプタに関連付けられたWiFiネットワーク名（SSID）。 この値はパターンマッチングをサポートしています。

考慮事項

CSV設定ファイルが次の基準を満たしていることを確認してください：

• ファイルサイズは5MB未満です。

• ファイルのエンコーディングはUTF-8です。

• カンマはフィールドセパレーターです。

• フィールドデリミターは任意で、引用符 " は許可された唯一のデリミタ型です。

• 空白の文字列や-を持つエンティティ値および分類値がない。

• エンティティ値と分類値の最大長は50文字です。

• ルールまたは行の総数は40,000未満です。

• ファイル全体で異なるエンティティの総数は2,000未満です。

• カスタム分類列の総数は6未満です。

• テーブルの最後の行にField1=nameおよびPattern1=*でキャッチオールルールを入力します。

• 同じエンティティを複数のカスタム分類に属させることはできません。 エンティティ値が複数の行に現れる場合、その分類はすべての行で同じでなければなりません。

例: システムは、エンティティFRANCEが異なる2つの行でEUROPEとAMERICASの両方に誤って割り当てられているため、次の割り当てルールを拒否します。

これらのチェックのいずれかが失敗した場合、ファイルの選択は以前にアップロードされたファイルに戻ります。 エラーを修正することで、アップロードを解除できるようになります。

CSVファイルのアップロード

CSVファイルをアップロードする方法については、右側のパネルにあるプロダクト内ドキュメントを参照してください。

カスタム分類を編集

組織の構造を最もよく反映した更新されたCSVファイルをアップロードすることで、カスタム分類を編集します。 次のことができます：

• 既存のカスタム分類を削除するには、列全体を削除します。

• 新しいカスタム分類を追加するには、新しい列を追加します。

新しいCSVがアップロードされると、古いカスタム分類はデータモデルから削除され、自動補完で提案されなくなります。

NQLフィールドと例

場所と所有権のフィールドはデータモデル内で2つのレベルで利用可能です：

• デバイスプロパティとして：フィールドはデバイスの現在の所有権と位置を返します。

• イベントコンテキストとして：コンテキストフィールドはイベント時の所有権と位置を返します。

次の表は、対応するフィールドを要約したものです。

説明:

各デバイスに対して、システムはCSVファイルでルールを見つけようとします。 デバイスがルールに一致すると、システムは次の方法で場所データを取得します：

• ルールがLocation Typeと1つ以上のSite、State、Countryフィールドにデータを持っている場合、システムは関連するフィールドから場所データを取得します。 これらのフィールドのいずれかにデータが含まれている場合、システムはルールベースの位置データを使用し、空のフィールドはクエリで空の値として表示されます。

• ルールがLocation Typeフィールドのみにデータを持ち、Site、State、Countryフィールドが空の場合、システムはジオロケーションを使用して場所データを取得します。

詳細については次の表を参照してください：

例

以下のNQL例では、製品構成機能が使用されています。

Salesforceユーザーの地理的分布

Salesforceユーザーの地理的分布を見つける：

web.events
| where application.name == "Salesforce*"
| summarize Number_of_users = user.count() by context.location.country, context.location.state, context.location.site
| sort Number_of_users desc

イベント時のデバイスの場所を使用して実行クラッシュを調査する

過去7日間のすべてのデバイスでの実行クラッシュの数を調査し、潜在的な地理的傾向を発見します。 実行クラッシュ時のデバイスの位置を確認するには、context.locationを使用します。 クエリは、イベント発生時のデバイスの場所情報を保存しているcontext.locationフィールドからデータを取得します。

過去7日の実行クラッシュ
| summarize total_crashes=number_of_crashes.sum() by context.location.country, context.location.state, context.location.site

イベントコンテキストと現在のデバイスの位置を使用してWiFiネットワークの質を調査する

1. 過去の悪い接続性イベントがあったサイトをcontext.locationを使用した以下のクエリで参照します。 次のクエリは、イベント発生時のデバイスの位置を保存するcontext.locationフィールドからデータを取得します：

connectivity.events during past 3d
| where (connectivity.event.wifi.signal_strength.avg.rating !in [good, null] and context.location.site != null)
| summarize n_devices = count() by connectivity.event.wifi.signal_strength.avg.rating, context.location.site

1. これで、特定のサイトが悪い接続性に陥りやすいかどうかがわかります。 その場所でWiFiの質をアダプタータイプごとに分解して、潜在的な根本原因を探します。 これを行うために、次のクエリで使用されるのはdevice.locationです：

connectivity.events during past 1h
| where device.location.site == "site_with_bad_history"
| summarize n_devices = count() by connectivity.event.wifi.signal_strength.avg.rating, connectivity.event.primary_physical_adapter.type

組織エンティティでデバイスをフィルターする

特定の組織内の部分をターゲットにするために、entity を使用してデバイスをフィルターします：

devices 
| where organization.entity == "SWITZERLAND"

カスタム地域と位置タイプ別にDEXスコアを比較する

組織全体でデジタルエクスペリエンスの一貫性を確保するために、#regionおよびlocation.type別にDEXスコアを分解します。

dex.scores during past 7d
| summarize c1 = value.avg() by device.organization.#region, context.location.type

権限

製品構成機能にアクセスするには、管理者権限が必要です。

適切な権限を有効にするには：

• メインメニューからAdministrationを選択します。

• ナビゲーションパネルからRoleをクリックします。

• 新しいロールを作成するにはNew Roleボタンをクリックし、既存のロールを編集するにはホバーして編集アイコンをクリックし、ロールの設定を変更します。

• 権限セクションでスクロールダウンし、Administrationセクションに移動してロールに適切な権限を有効にします。

ロールのドキュメントを参照して、権限オプションの詳細な説明を確認してください。