製品設定

製品設定 の デバイスとユーザーの分類 タブを使用すると、システムがNexthinkテナント内でデバイスとユーザーをどのように分類するかを決定することができます。

Nexthinkの製品と機能全体でデバイスとユーザーの分類を使用します：

• データのクエリと調査の実行には、NQLデータモデルの表—device.organization, device.location, user.organizationを活用します。

• 組み込みのダッシュボードや特定のカスタム可視化を並べ替えるためのフィルターと分析基準を定義します。 カスタムフィルターのユースケース例については、[AIツールの設定] (../../ai-tools/configuring-ai-tools.md#configuring-custom-filters-for-ai-tools-dashboards) ドキュメントを参照してください。

システムは3つの主要な分類構成を提供します：

• デバイスの場所 はルールベースのロジックおよび/または公開IPに基づいたGeoIPを使用します。システムはGeoIPをフォールバックとして使用します。 デバイスの場所は、イベント時にデバイスがどこにあるかを把握し、問題解決と一貫したサポートを可能にします。 デバイスの場所は頻繁に変更されることが予想されます。

• デバイスの組織 は、組織的なエンティティとデバイスをマッピングするためのカスタムルールセットを使用し、組織構造または支社（例：米国支社、スイスオフィスなど）でのアクセス、コンプライアンス、ハードウェアのライフサイクルを管理できるようにします。 デバイスの場所とは異なり、デバイスの組織は時間とともにかなり安定しています。

• ユーザーの組織 は、最上位から一番下までの6レベルまでの組織の階層を定義し、それらを従業員にマッピングします - HR管理ツールからのデータに一致させます。

管理 > 製品設定 > デバイスとユーザーの分類 へのアクセスには、管理者権限が必要です。

---

デバイスの位置を設定する

デバイスの位置によってイベント発生時にデバイスがどこにいるかを把握できるため、遠隔地での問題をトラブルシューティングし、安定したデジタルエクスペリエンス (DEX) を保証します。 イベントは地理的な場所と、オンサイトまたはリモートの場所タイプで追跡されます。

Nexthink は、ルールベースのロジック (正確性を重視) または公衆 IP に基づく GeoIP を使用して位置を決定し、ルールベースの場所の割り当てができない場合にフォールバックとして GeoIP を使用します。 デバイスの位置は頻繁に変わると予想されます。

管理 > 製品設定 > デバイスとユーザーの分類 タブの下の デバイスの位置:

1. 位置の詳細度を設定する

2. ルールベースの位置を定義する

位置の詳細度の設定

Nexthink は、GeoIP データベースと Collector を実行しているシステムの公衆 IP アドレスを参照して、インターネット上のデバイスの場所を特定できます。

ジオロケーション機能はデフォルトで無効になっています（「位置データをキャプチャしない」）、ただし、ドロップダウンメニューで利用可能なオプションに位置の詳細度を設定することで有効にできます。

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

• 公開IPのみ

• 公開IPと国

• 公衆 IP、国、州

• 公衆 IP、国、州、市

ジオロケーション機能を有効にすると、細かい粒度を選択したかどうかにかかわらず、Nexthink プラットフォームはインターネットサービスプロバイダー (ISP) の名前を記録します。

仮想プライベートネットワーク (VPN) を使用すると Collector が報告する公衆 IP アドレスに影響を与えます。 ジオロケーションの精度を向上させるには、Collector と Nexthink インスタンス間のトラフィックを VPN でルーティングすることを避けるのが最善です。 この機能は、どの Collector バージョンでも動作し、Nexthink プラットフォーム外には情報は送信されません。 Nexthink は独自のジオロケーションデータベースインスタンスを持ち、社内でジオロケーション検索を実行します。

ルールベースの場所の定義

Nexthink プラットフォームは、デバイスの位置を決定するためにシステムが使うルールベースの割り当てプロセスを特徴としています。 この機能は高い設定可能性を備えており、ルールを変更して調整することができます。

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

ルールベースのロケーションルールでCIDR表記を使用するIPアドレスフィールドを使用する場合、CIDR形式の要件はデバイス組織ルールと同じです。 製品設定 を参照してください。

ルールベースの位置情報のための CSV ファイルの例

カンマ区切りの割り当てテキストファイルの例:

Field1,Pattern1,Field2,Pattern2,Location Type,Site,State,Country
primary_local_ip,10.0.0.0/8,name,NXT*,現地,Lausanne,VD,CH
primary_local_ip,172.16.0.0/16,,,現地,Boston,MA,US
name,*,,,リモート,,,

このページの Field1 および Field2 のサポートされている値 を参照してください以降の詳細については、このページでご覧ください。

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

Field1	Pattern1	Field2	Pattern2	ロケーションタイプ	サイト	地域	国
primary_local_ip	10.0.0.0/8	名前	NXT*	オンサイト	ローザンヌ	VD	CH
primary_local_ip	172.16.0.0/16			オンサイト	ボストン	MA	US
名前	*			リモート

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

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

• 3 番目のルールは、その他すべてのデバイスに リモート とタグ付けします。

ルールを満たすためには、パターンが対応するフィールドと一致する必要があります。 システムは表の上から下に向かってルールの優先順位を設定します。 表の上部ではデバイスの割り当てをより具体的にし、下部ではより一般的にすることができます。

• Field1: 割り当てに使用される最初のフィールドのデータ (このページ内の Field1 および Field2 のサポートされている値 を参照してください)

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

• Field2: 割り当てに使用される 2 番目のフィールドのデータ (このページ内の Field1 および Field2 のサポートされている値 を参照してください)

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

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

  • オンサイト

  • リモート

  • 不明

• サイト: デバイスが存在するサイトのカスタム名称。

• 州: デバイスがある ISO 3166-2 の区分コード。 州、州、領州などを示すためにこのフィールドを使用します。 例えば、スイスのヴォー州の場合: VD

• 国: デバイスが存在する ISO 3166-1 alpha-2 国コード。 例えば、スイスの場合: CH

州フィールドに国コードを重複させないこと。 例えば、ISO 3166-2 によると、バ=rin フランス県の州フィールドは 67 であり、FR-67 ではない。

この場合、ルールベースの位置は次のように見える必要があります:

primary_local_ip,55.XXX.XX.X/20, Onsite, Illkirch,67, FR

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 フィールドは文字パターン一致をサポートしています。 関連する文字列パターンを定義するには、次のワイルドカードを使用します:

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

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

• ip: デバイスの最後の公衆 IP アドレス。 このフィールドは、devices テーブルの public_ip.ip_address NQL フィールド にマップされます。\n フィールドのパターンには、次を指定します:

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

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

CIDR表記を使用してサブネットを指定する場合、IPがサブネットのネットワークアドレスを表していることを確認してください。 製品設定 を参照してください。

• primary_local_ip: primary 物理ネットワークアダプターの最後のローカル IP。 このフィールドは、devices テーブルの connectivity.last_local_ip NQL フィールド にマップされます。 パターンを指定する際は ip フィールドと同様に指定してください。

• collector_local_ip: エンドポイントと Nexthink インスタンス間のトラフィックに使用されるローカル IP。 このフィールドは、devices テーブルの collector.local_ip NQL フィールド にマップされます。 パターンを指定するには、 ip フィールドでの指定方法に従ってください。

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

公衆 IP アドレスに基づくルールを作成する前にジオロケーションを有効にしてください。

wifi_ssid タグを使用するには、次の Collector パラメータ を無効にします: ANONYMIZE_WIFI_NETWORK

ルールベースの位置情報用 CSV ファイルの考察

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

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

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

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

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

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

• 一意のサイトの最大数は 2,000 です。

• 表の最後の行には、Field1=name と Pattern1=* のキャッチオールルールを入力してください。

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

保存時にプログラムが自動的に余分な文字を追加するのを防ぐために、Notepad++ や Sublime Text のようなプレーンテキストエディターを使用して CSV ファイルを編集してください。

---

デバイスの組織を設定する

従来の階層を使用している組織は、デバイスの組織 カスタムルールセットに移行する必要があります。

移行ステップに関しては、エンティティと階層のルールベースの組織化への移行 ドキュメンテーションを確認してください。

デバイスの組織は、組織ルールセットを使用して組織的なエンティティでデバイスをマッピングし、エンティティを組織構造に沿ってグループ化します。 これにより、組織構造や支店 (米国支部、スイスのオフィスなど) により、アクセス、サポート、コンプライアンス、およびハードウェアのライフサイクルを管理できます。

頻繁に変わるデバイスの位置情報とは異なり、デバイスの組織はかなり安定しています。 例えば、スイス所有のデバイスは複数の国で使用される場合があります。

管理 > 製品設定 > デバイスとユーザーの分類 タブの下の デバイスの組織:

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

デバイス組織ルールでCIDR表記を使用してIPアドレスフィールドを使用する場合、IP値はサブネットのネットワークアドレスを表している必要があります。

初めてルールセットをアップロードする際、CSVファイルのサイズに応じてデータの入力に20分から60分の遅延があります。

クラスレスインタードメインルーティング（CIDR）形式に基づいたルールの要件

サブネット内のホストIPアドレスを使用して定義されたCIDR範囲は、デバイス組織ルールではサポートされていません。 IPの部分は、ホストビットがすべてゼロに設定されたCIDRプレフィックスと一致する必要があります。

たとえば：

• 有効: 10.136.16.0/21

• 無効: 10.136.16.1/21

CIDR範囲がネットワークアドレスで始まらない場合、CSVファイルはアップロード時に受け入れられますが、デバイスはエンティティと一致しません。

デバイス組織ルールセットのための 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

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

フィールド1	パターン1	フィールド2	パターン2	エンティティ	地域
					グローバル地域
名前	デバイス-d*			フランス	ヨーロッパ
名前	デバイス-1*			カナダ	アメリカ大陸
コレクターストリングタグ	CH*			スイス	ヨーロッパ
コレクターストリングタグ	US*			アメリカ合衆国	アメリカ大陸
名前	*			未割り当て	未割り当て

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

たとえば、name が device-d100 で、collector_string_tag が CH10 であるデバイスがあるとします。 このデバイスは、最初のルールと第3のルールの両方に一致します。 システムは最初に device-d100 ルールを評価するため、デバイスはエンティティ フランス とグローバル地域 ヨーロッパ に割り当てられます。

最初の5列は必須です:

• フィールド1: 割り当てに使用される最初のフィールドのデータ（このページの フィールド1およびフィールド2のサポートされる値 を参照）。

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

• フィールド2: 割り当てに使用される2番目のフィールドのデータ（このページの フィールド1およびフィールド2のサポートされる値 を参照）。

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

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

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

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

1. #region は NQL ID です。

2. グローバル地域 は分類の NQL ID の表示名です。

サポートされる フィールド1およびフィールド2 の値:

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

• コレクタ_タグ: インストール中にコレクタに割り当てられるタグ番号。 システムは正確な番号のみを一致させます。

• コレクタ_ストリング_タグ: インストール中にコレクタに割り当てられるラベル。 この値はパターンマッチングをサポートします。

• 構成_タグ: デバイスのグループを識別する構成可能なラベル。 このフィールドの値は、Enrichment API を使用して設定します。 この値はパターンマッチングをサポートします。

• dn: コレクタによって報告されたデバイスの識別名。 デバイスは Active Directory ドメインの一部でなければなりません。 コレクタによって報告される識別名の形式は、最も特定の属性から最も一般的な属性まで、コンマで接続された 属性=値 要素の標準シーケンスです。 例えば、CN=ex01,OU=コンピュータ,DC=example,DC=org。

• ad_サイト: デバイスが配置されている Active Directory サイト。 名前、コレクタ_ストリング_タグ、dn、および ad_サイト フィールドは文字パターンマッチングをサポートします。 関連する文字列パターンを定義するには、次のワイルドカードを使用します:

  • ? 文字は単一の文字を代替します。

  • * 文字はゼロ以上の文字を代替します。

• ip: デバイスの最後の公開 IP アドレス（NQLデータモデル の public_ip.ip_address を参照）。 フィールドのパターンとして、次のいずれかを指定します:

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

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

• プライマリー_ローカル_IP: プライマリ物理ネットワークアダプタ用のデバイスの最後のローカル IP（NQLデータモデル の connectivity.last_local_ip を参照）。 プライマリー_ローカル_IP: フィールドの ip と同じ方法でパターンを指定してください。

• コレクタ_ローカル_IP: エンドポイントと Nexthink インスタンス間のトラフィックに使用されるローカル IP（NQLデータモデル の collector.local_ip を参照）。 コレクタ_ローカル_IP: フィールドの ip と同じ方法でパターンを指定してください。

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

公開 IP アドレスに基づくルールを作成する前に、ジオロケーションを有効にします。

wifi_ssid タグを使用するために、次の コレクタパラメータ: ANONYMIZE_WIFI_NETWORK を無効にしてください。

デバイス組織ルールセットの CSV ファイルに関する考慮事項

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

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

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

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

• フィールドデリミタは省略可能であり、引用符 " のみが許可されるデリミタの種類です。

• エンティティ値や分類値に空の文字列や - は含まれていません。

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

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

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

• カスタム分類列の合計は6を超えてはいけません。

• テーブルの最終行に フィールド1=名前 および パターン1=* でキャッチオールルールが入力されます。

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

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

フィールド1	パターン1	フィールド2	パターン2	エンティティ	地域
					グローバル地域
名前	デバイス-d*			フランス	ヨーロッパ
名前	デバイス-e*			フランス	アメリカ大陸

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

保存時にプログラムが自動的に追加の文字を追加するのを防ぐために、Notepad++やSublime Textのようなテキストエディタを使用してCSVファイルを編集してください。

カスタム分類の更新

組織構造を最も反映している修正版のCSVファイルをアップロードしてカスタム分類を更新します。 以下を行うことができます:

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

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

新しいCSVがアップロードされると、古いカスタム分類はデータモデルから削除され、オートコンプリートによって提案されなくなります。

カスタム分類の更新は、組織データに依存する既存のNQLクエリの結果に影響を与える可能性があります。 カスタム分類の変更後、これらのNQLクエリを確認し、更新してください。

ドメインの表示 権限は、カスタム分類を含む組織データに依存します。 割り当てルールを変更すると、限定的なドメイン表示権限を持つユーザーに利用可能なデータの範囲に影響を与える可能性があります。

カスタム分類の変更後、限定的なドメイン表示アクセスを持つプロファイルを改訂することを確認してください。

---

ユーザー組織の設定

ユーザー組織は、HR 管理ツールからの値を一致させて、会社の階層またはホラクラシーによって定義された組織の従業員グループにユーザーをマップします。

ユーザー組織フィールドを定義するには、管理 > 製品構成 > デバイスおよびユーザー分類 タブで、ユーザー組織 の下から次のようにします。

1

ユーザー組織フィールドを作成する

HR階層またはグループを表す最大6つのユーザー組織フィールドを追加します:

• 新しいユーザー組織フィールドを追加し、その説明を含めます。例: ビジネスユニット。

  • システムは、作成されたフィールドに対して NQL ID を自動的に生成します: business_unit。

• 作成されたユーザー組織フィールド項目をドラッグアンドドロップして、会社の階層に従って順序付けします。

使用ケースの例: ユーザー組織フィールドは、特定の従業員グループごとの AI ツールの使用状況を監視する際のカスタムフィルタとして機能します。

境界に新しいフィールドが存在するが、値がない場合はユーザー組織フィールドを製品設定する必要があります。

Nexthink のデータエンリッチメント用のインバウンドコネクタを使用する場合、可能な限り早期の時点でコネクタを実行するようスケジュールを設定します。 これにより、コネクタのスケジュールされた再発によって引き起こされる遅延を最小限に抑えることができます。

2

ユーザー組織フィールドを集約する

ユーザー組織フィールドをデータで豊かにするには、次のオプションのいずれかを使用します:

• インバウンドコネクタを使用してフィールドマッピングを行い、Workday や Salesforce のような従業員管理アプリケーションにアクセスし、従業員属性をユーザー組織フィールドにマッピングします。

  • 遅延を最小限に抑えるために、データエンリッチメントがコネクタのスケジュールされた再発を依存するため、インバウンドコネクタを可能な限り早期に実行するよう構成します。

• Nexthink Enrichment API を使用して、外部ソースからの属性でユーザー組織フィールドの値を更新します。

• カスタムフィールド管理 を使用して、CSVファイルをアップロードしてユーザー組織フィールドを更新します。

• 調査からの カスタムフィールドの編集 を使用して、手動でユーザー組織フィールドをユーザー情報で更新します。

次の例では、Entra ID 用のインバウンドコネクタを使用して、ユーザー組織フィールド—ビジネスユニット—を選択した Entra ID フィールド にマップしています。

Microsoft Entra ID (Azure AD) コネクタのフィールドマッピング手順詳細を参照してください。

3

ユーザー組織フィールドを検証する

調査から NQL クエリを実行してユーザー組織カスタムフィールドを検証し、特定の HR 階層と一致するユーザーグループを集約します。この例では、business_unitは、EMEA 財務です。

ユーザー
| where user.organization.#business_unit == "EMEA フィナンス"

---

NQL フィールドとサンプル

位置と所有権フィールドは、データモデルで2つのレベルで利用可能です:

• デバイスまたはユーザーのプロパティとして: フィールドは現在のユーザーまたはデバイス組織ユニットとデバイスの位置を返します。

• イベントコンテキストとして: コンテキストフィールドは、イベント時に組織ユニットと位置を返します。

次の表は、対応するフィールドをまとめたものです。

	オブジェクトプロパティ	イベントコンテキスト
パブリックIPジオロケーション	device.public_ip.country device.public_ip.state device.public_ip.city	–
ルールベースのデバイス位置 * テーブルの下に説明を参照	device.location.type device.location.site device.location.state device.location.country	context.location.type context.location.site context.location.state context.location.country
ルールベースのデバイス組織	device.organization.entity device.organization.#customClassification	context.organization.entity context.organization.#customClassification
ユーザー組織	user.organization.#customClassification	–

説明:

各デバイスに対して、システムはCSVファイル内からルールを見つけようとします。 デバイスがルールに一致した場合、システムは次のいずれかの方法で位置データを取得します:

• ルールに場所の種類(Location Type)と1つ以上のサイト,州,国のフィールドにデータがある場合、システムは該当するフィールドから位置データを取得します。 これらのフィールドのいずれかにデータが含まれている場合、システムはルールベースの位置データを使用し、空のフィールドはクエリで空の値として表示されます。

• ルールが場所の種類フィールドのデータにのみ含まれ、サイト,州,国フィールドが空の場合、システムは位置データのためにジオロケーションを使用します。

さらなる説明については、次のテーブルを参照してください:

	データ 場所の種類 データ サイト, 州, または 国、または全て	データ 場所の種類 無し データ サイト, 州, または 国
ルールベースの位置情報	✓
位置情報		✓

ユースケース: 製品設定フィールドをクエリする

次の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フィールドからデータを取得します:

過去3日の接続イベント
| where (connectivity.event.wifi.signal_strength.avg.rating !in [よい, 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を使用します:

過去1時間の接続イベント
| 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でフィルターします:

デバイス 
| where organization.entity == "SWITZERLAND"

組織単位によるユーザーのフィルタリング

特定の組織の部分内でユーザーをターゲットとするために#チームでフィルターします:

ユーザー
| where organization.#team== "プロダクト"

カスタム地域と場所タイプごとにDEXスコアを比較

デジタル体験の一貫性を確保するために、#地域と場所タイプごとにDEXスコアを分解します。

過去7日間のdexスコア
| summarize c1 = value.avg() by context.organization.#Region, context.location.type