> For the complete documentation index, see [llms.txt](https://docs.scepman.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.scepman.com/ja/sono/troubleshooting/general.md).

# よくある問題

## SCEPman の起動に関する問題

### GitHub から SCEPman をデプロイして以前は動作していましたが、今は Web App が起動しなくなりました

エラーが '503 Cannot download ZIP' の場合、Web App は、アプリ設定 WEBSITE\_RUN\_FROM\_PACKAGE に構成された URL からアプリケーションバイナリを含む ZIP をダウンロードできません（参照 [アプリケーション構成](/ja/scepman-gou-cheng/application-artifacts.md#change-artifacts)).

URL *<https://github.com/glueckkanja/gk-scepman/raw/master/dist/Artifacts.zip>* 以前のバージョンのこのドキュメントで GitHub デプロイメント向けに推奨していたものは、別の URL にリダイレクトされます。Microsoft は一部の Web Apps の動作を変更したため、現在では一部のバージョンで WEBSITE\_RUN\_FROM\_PACKAGE とリダイレクトの併用がサポートされません。したがって、URL を次のものに変更する必要があります `https://raw.githubusercontent.com/scepman/install/master/dist/Artifacts.zip`.

### SCEPman Azure Web App が実行されていません

Azure リソースが稼働しているか確認してください。

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-fa1f838cc58fdfc0443c4d1e663643b3df01dd4e%2Fevent32_2%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(2\).png?alt=media)

### 自分の App Service が間違った .NET バージョンを使用しています

SCEPman または Certificate Master の App Service リソースでは、Settings -> Configuration -> General settings -> Stack settings の下で、その App Service にどの Stack とバージョンが構成されているか確認できます。Stack は .NET ですが、.NET バージョンは、SCEPman のバージョンに対して期待しているものと一致しない場合があります。たとえば、SCEPman 2.8 では .NET 8 です。

これは、いくつかの一般的な .NET バージョンが、設定でどの .NET バージョンを選択していても、すべての Windows App Services で自動的に利用可能だからです。SCEPman を新しい .NET バージョンに引き上げるのは、そのバージョンが自動インストールされる .NET バージョンのセットに含まれている場合のみです。これは、以下を介した更新メカニズムが [WEBSITE\_RUN\_FROM\_PACKAGE ](/ja/scepman-gou-cheng/application-settings/basics.md#website_run_from_package)では .NET バージョン設定を一切制御できないためです。したがって、実際には .NET バージョンとして何が構成されているかは重要ではありません。

### 私の SCEPman App Service は 2024-11-27 に動作せず、何年も問題なく動作していたにもかかわらず、2024-12-16 以降は完全に動作しなくなりました

非推奨の SCEPman アーティファクト リポジトリを終了しています <https://github.com/glueckkanja/gk-scepman> アーティファクトを新しい場所へ移行してから 3 年以上が経過した後 <https://github.com/scepman/install>。2024-11-27 水曜日に、2024-12-16 月曜日の完全終了をユーザーに知らせるため、旧ロケーションを一時的に無効化しました。

影響を受けている場合は、WEBSITE\_RUN\_FROM\_PACKAGE 設定を確認し、 [値を更新してください](/ja/scepman-gou-cheng/application-artifacts.md) 新しいパッケージの場所に変更してください。これにより SCEPman のバージョンも 1.8 から最新バージョンに更新され、 [多くの改善が](/ja/changelog.md) 完全な後方互換性を保ったまま適用されます。

最新のリポジトリを使用しているか不明な場合は、SCEPman のスプラッシュページを開いてください。まだ旧リポジトリに設定されている場合は、次のような警告が表示されます（この警告は過去 3 年間すでに表示されていました）。

<figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FbX4ATqv8O0f3cXCdqwLy%2Fimage.png?alt=media&amp;token=b9ed1f6f-ce4f-4745-b30b-9b01c518997c" alt=""><figcaption><p>WEBSITE_RUN_FROM_PACKAGE に古いパッケージの場所を使用している SCEPman</p></figcaption></figure>

## 証明書の発行に関する問題

### Trusted Root Certificate はデプロイされているのに、SCEP プロファイル経由の Device Certificate がエラーになります

証明書のデプロイが成功しなかった場合、SCEP プロファイルはエラーになります。エラーにはいくつかの原因があります。

### SCEP 証明書プロファイルにエラーがある構成になっています

これは、SCEP 証明書プロファイルで誤った trusted root certificate が選択されている場合に発生する可能性があります。これはイベントログにも表示されます。

1. Windows イベント アプリケーションを開く
2. クリック **Applications and Services Logs**
3. 次に、クリックします **Microsoft**
4. 次に、クリックします **Windows**
5. 下にスクロールして次を検索します **DeviceManagement-Enterprise-Diagnostics-Provider** をクリックします。
6. 表示されるウィンドウで、次をクリックします **Admin**
7. 一覧をスクロールしてイベント ID を検索します **32**
8. 短いエラーレポートが含まれています
   * SCEP: 証明書の登録に失敗しました。結果（ハッシュ値が正しくありません）。

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-4e964c4cda9f70b7c0a4c24a293f0bf7133844c3%2Fevent32_1%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(11\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(12\).png?alt=media)

Intermediate CA を使用している場合は、次の点に注意してください。 [Intermediate CA 証明書を選択する必要があります](/ja/scepman-nodepuroi/intermediate-certificate.md#intermediate-cas-and-intune-scep-profiles) SCEP 構成プロファイルでは Root CA 証明書ではなくそれを選択してください。これは Windows プラットフォーム固有であり、たとえば Android では SCEP 構成プロファイルで Root CA 証明書を選択する必要があります。

### 自分の証明書に正しい OCSP URL エントリがありません

{% hint style="info" %}
これはバージョン 1.2 より前の問題にすぎません
{% endhint %}

証明書内の OCSP エントリに localhost URL が設定されたデバイス証明書が次のようになっている場合:

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-13206c885994d08c4ec6e5996ea261b2d3ee5912%2Fevent32_7%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media)

App Service に次の名前の重要なアプリ設定がありません **AppConfig:BaseUrl** が azurewebsite URL に設定されています。これを修正するには、変数を追加して App Service の構成を保存してください。

```
AppConfig:BaseUrl
https://scepman-XXXXX.azurewebsites.net
```

この証明書をデバイスから削除し、MDM 同期を実行してください。そうすれば、OCSP エントリに適切な URL が表示されます。

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-7729e8388eaa003c5561f926e7f26c54972fd5b2%2Fevent32_8%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media)

### 自分の SCEP 構成プロファイルが保留中と表示され、適用されません

SCEP 構成プロファイルは Trusted Root certificate プロファイルに依存しています。ユーザーまたはデバイスが重複し、両方のプロファイルがデバイスを対象にしていることを確認するため、両方のプロファイルを同じ Azure Active Directory のユーザー グループまたはデバイス グループに割り当ててください。ユーザー グループとデバイス グループを混在させないでください。Intune で構成プロファイルの状態が長時間 pending のままの場合、割り当てが間違っている可能性があります。

### 一部の Windows マシンは証明書を登録または更新できません

SCEPman 側とクライアント側の両方から確認できます。事前には分からないことが多い問題の内容によって、根本原因は 2 つの側のうち片方にしか表示されません。

次のいずれかがあるか確認してください `[ERROR]` という項目が SCEPman ログにあるか。必要に応じて、検索語 `[WARN`も検索してください。ただし、誤検出が発生する場合があります。

Oliver Kieselbach と Christoph Hannebauer が [証明書要求または更新の問題の分析に関するブログ記事を執筆しました](https://oliverkieselbach.com/2022/09/21/deep-dive-of-scep-certificate-request-renewal-on-intune-managed-windows-clients/) これにより、クライアント側の登録問題を追跡できます。

Windows SCEP クライアントは TLS 1.2 までしかサポートしていません。SCEPman App Service で受信側の最小 TLS バージョンを 1.3 に設定すると、次の中に特定のエラー エントリが発生します。 `DeviceManagement-Enterprise-Diagnostics-Provider` イベントログ。以下は Windows 11 マシンの例です。

{% code overflow="wrap" fullWidth="false" %}

```
TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 32
Message      : SCEP: 証明書の登録に失敗しました。結果: (不明な Win32 エラー コード: 0x80072f8f)。

TimeCreated  : 7/2/2025 12:51:06 PM
ProviderName : Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider
Id           : 307
Message      : SCEP: LogError に失敗しました Message : (SCEPInstallCertificateWithScepHelper: 初期化に失敗
               NDES Server を使用した SCEP 登録
               'https://scepman.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe'、CA 証明書のサムプリント
               '24C45EF4284A5093A9C3886A6466C1D6D84EE058' およびサーバー証明書 ''。LogError 0x80)
```

{% endcode %}

### Windows 10 デバイスは AutoPilot で登録できません

現在、一部の Windows 10 デバイスでは OOBE 体験中の時刻が正しくありません。画面に時計が表示されないため、これを確認するのは簡単ではありません。これは新しく発行された証明書に問題を引き起こします。なぜなら、それらは *まだ* 有効ではないからです。Windows はその「無効な」証明書を破棄し、エラーを表示します。小さな時計のずれに対処するため、証明書は既定で 10 分過去の時刻で発行されますが、最近では最大 9 時間遅れている Windows 10 デバイスも確認しています。

登録を続行してかまいません。完了すると、その時点では時計が正しいため、デバイスは正常に証明書を取得できます。新しいオプションも使用できます [**AppConfig:ValidityClockSkewMinutes**](/ja/scepman-gou-cheng/application-settings/certificates.md#appconfig-validityclockskewminutes) これを使うと、証明書を 10 分を超えて過去日付にできます。1 日分過去日付にするには 1440 分を使用してください。これは、この問題に対処するための新しい SCEPman インストールの既定値になります。

### 今日証明書を発行したのに、発行日が昨日になっています

これは、時計が遅れているデバイスの問題に対処するため、SCEPman が証明書の日付を 1 日さかのぼらせているためです。参照 [Windows 10 デバイスは AutoPilot で登録できません](#windows-10-devices-cannot-enroll-with-autopilot).

## 証明書の有効性に関する問題

### ローカル証明書を確認

#### Windows マシン

まず、デバイス証明書の有効性を確認する必要があります。そのため、管理者としてコマンド プロンプトを開き、次のコマンドを入力してください。

```
certutil -verifyStore MY
```

SCEPman-Device-Root-CA-V1 によって発行されたデバイス ID 付きの証明書を確認し、その証明書が有効かどうかを検証してください（最後の行を参照）。

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-cb549f4e3708565d2455a9f459c2e54254ee26e8%2Fscepman_revocation1%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\).png?alt=media)

OCSP responder が機能していることを確認するには、次のコマンドで OCSP URL キャッシュを確認できます。

```
certutil -urlcache OCSP
```

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-6c46d2b65ee1277d01b26b0f496975a577d35f21%2Fscepman_revocation2%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media)

#### macOS マシン

macOS マシンで OCSP を使用して証明書の有効性を確認するには、次の手順に従ってください。

1. SCEPman Root CA 証明書を次からエクスポートします **Keychain Access** (**System Keychains > System Roots**を \*.cer ファイルとしてエクスポートし、フォルダーに配置します（代わりに、SCEPman インスタンスの Web サイトからダウンロードすることもできます）。
2. 検証したいクライアント認証証明書を次からエクスポートします **Keychain Access** (**System Keychains > System > My Certificates**を \*.cer ファイルとして同じフォルダーに保存します。
3. クライアント認証証明書の **Authority Information Access** (AIA) プロパティから OCSP responder URL を抽出します。

   <figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FaJqT97xxEUx1py2f0xbT%2Fimage.png?alt=media&amp;token=3c0ca083-8cb9-471f-a7ab-4a314337b585" alt=""><figcaption></figcaption></figure>
4. 次のものを開きます **Terminal** セッションを開き、 `cd` エクスポートした証明書が含まれるフォルダーに移動します。
5. 次のコマンドを実行します。

```
openssl ocsp -issuer <filename-scepman-root-ca-certificate> -cert <filename-certificate-to-be-verified> -text -url <ocsp-responder-url>
```

6. 応答の終わり近くで、失効状態が表示されます:\\

   <figure><img src="https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2FRXQI4xRp0NRt5vBwDY89%2Fimage.png?alt=media&amp;token=ee8e2761-e249-4bd1-ae82-0eac933363d2" alt=""><figcaption></figcaption></figure>

### 他のマシンの証明書を確認する

代替として、デバイス証明書をエクスポートして `certutil` Windows マシンで使用して、OSCP チェック用の小さな certutil UI を表示できます。

```
certutil -url <path-to-exported-device-certificate>
```

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-d3dffe20c2939eddc1ea08c0e4164440e9c7a3c3%2Fscepman_revocation4%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(1\)%20\(5\).png?alt=media)

### ユーザーを失効させる

次を失効させたい場合は、 **ユーザー** 証明書には 2 つの選択肢があります:

1. Microsoft Entra ID (Azure AD) からユーザーを削除する、または
2. ユーザーのサインインをブロックする

次を失効させたい場合は、 **デバイス** 証明書には、次に応じて複数の選択肢があります。 [Intune 検証](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-devicedirectory):

1. Microsoft Entra ID (Azure AD): デバイスを削除または無効化する（[Microsoft Entra ID (Azure AD) Portal](https://aad.portal.azure.com/)：「Devices」-「All devices」）。
2. **Intune**：デバイスを削除するか、リモート操作を実行します（「WipePending」などのいくつかの管理状態では、次の項目で述べられているように証明書が自動的に失効します [Intune 検証](/ja/scepman-gou-cheng/application-settings/scep-endpoints/intune-validation.md#appconfig-intunevalidation-revokecertificatesonwipe)).
3. **両方のディレクトリ**：Microsoft Entra ID (Azure AD) に対する操作を実行します **および** を Intune で実行します。

{% hint style="info" %}
デバイス ディレクトリの詳細については、記事をお読みください [デバイス ディレクトリ](/ja/scepman-gou-cheng/device-directories.md).
{% endhint %}

次の例では、Microsoft Entra ID (Azure AD) を介してデバイス証明書を失効させます。

1. へ移動する **Devices - All devices** あなたの Microsoft Entra ID (Azure AD) で
2. デバイスを選択します
3. クリック **無効化**

次に、次のコマンドを再度入力します。

```
certutil -verifyStore MY
```

最後の行から分かるように、 **証明書は REVOKED です**

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-42dfe633eca8d878a1bce1a117ef10e83ec46734%2Fscepman_revocation3%20\(2\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(3\)%20\(2\).png?alt=media)

Microsoft Entra ID (Azure AD) でデバイスを再度有効にし、上記のコマンドをもう一度入力すると、証明書は有効としてマークされるはずです。

{% hint style="info" %}
プロンプト 'Marked as valid' が表示されるまで、最大 5 分かかることがあります。
{% endhint %}

### Access Point は SCEPman が発行した認証証明書を検証できません

*症状*：Cisco ISE に OCSP 到達不能エラーが表示されます。Aruba ClearPass でも同じ問題があります。サーバーは、おそらく SCEPman で、OCSP 要求に対して TCP reset パケットで応答します。

*原因*：Cisco ISE も Aruba ClearPass も、OCSP の参照時に HTTP 1.1 をサポートせず、OCSP 要求で host ヘッダーを送信しません。そのため、Azure App Services 上で実行されている一般的な SCEPman インスタンスに接続できません。エラーメッセージは次のようになります。

![](https://114237723-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LoGejQeUQcw7lqnQ3WX%2Fuploads%2Fgit-blob-73190ac3e2e77c25974776ffa48e74b2c33f96da%2Fcisco-ocsp-error%20\(2\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(4\)%20\(2\)%20\(1\).jpg?alt=media)

*解決策*：こちらをご覧ください [こちら](/ja/sono/troubleshooting/cisco-ise-host-header-limitation.md).

### 自分の Android (dedicated) システム上の Device Certificates が有効ではありません

Android (dedicated) システムでは、SCEP 構成プロファイルで変数を構成していても、Intune または Android がランダムに AAD Device ID の代わりに Intune Device ID を証明書に入れてしまうことがあります。すると SCEPman は AAD でこの ID を持つデバイスを見つけられず、そのため証明書を失効済みと見なします。

これは、企業所有の専用デバイスの登録方法として、既定モードではなく Microsoft Entra ID (Azure AD) の共有モードを使用した場合にのみ発生します。トークンの種類に対して既定モードを使用している場合は `Corporate-owned dedicated device`、この問題の影響は受けません。Intune は引き続き AAD Device ID の代わりに Intune Device ID を証明書に入れますが、既定モードでは両者は同じなので問題ありません。登録モードを変更するには、次へ移動します [Microsoft Endpoint Manager admin center の Android enrollment settings](https://endpoint.microsoft.com/#blade/Microsoft_Intune_DeviceSettings/DevicesAndroidMenu/androidEnrollment) を選択し、 `Corporate-owned dedicated device (default)` の代わりに `Azure AD shared mode を使用する Corporate-owned dedicated device`。次を参照してください [Microsoft documentation](https://docs.microsoft.com/en-us/mem/intune/enrollment/android-kiosk-enroll) で、この選択の影響について確認してください。

現在、この問題をすべての構成で解決するために Microsoft と協力しています。あなたも影響を受けている場合は、サポートまでご連絡ください。

### 自分の Storage Account には Not Connected と表示されます

SCEPman のホームページで Storage Account 接続に赤いタグ「Not Connected」が表示される場合、SCEPman App Service（および場合によっては SCEPman Certificate Master）の Managed Identity に Storage Account 上の権限がない可能性があります。この場合、SCEPman は証明書が手動で失効されているかどうかを確認できず、そのため OCSP 要求に応答できません。これは通常、Storage Account を別のサブスクリプションまたはリソース グループに移動したときに発生します。Community Edition から Enterprise Edition にアップグレードした後にも発生することがあります。この場合、権限の問題は以前からありましたが、Community Edition では検出されていませんでした。

これを修正するには、SCEPman App Service と SCEPman Certificate Master の Managed Identity に、Storage Account 上でロール「Storage Table Data Contributor」を付与する必要があります。ロールの割り当ては、Storage Account の「Access Control (IAM)」で Azure Portal から手動で行うことができます。あるいは、単に [SCEPman PowerShell モジュールから SCEPman Installation CMDlet をもう一度実行してください](/ja/scepman-nodepuroi/permissions/post-installation-config.md#running-the-scepman-installation-cmdlet).

## SCEPman は Client Authentication 以外の EKU を持つ証明書を発行しません

SCEPman の Environment Variables を確認して、次に対して何が構成されているかを見てください [AppConfig:UseRequestedKeyUsages](/ja/scepman-gou-cheng/application-settings/certificates.md#appconfig-userequestedkeyusages)。設定されていない場合、既定値は「false」です。

新規インストールではこれが自動的に「true」に設定されますが、古い SCEPman インストールでは false に設定されています。SCEPman の更新では、いかなる場合でも不利にならない修正や変更以外、動作は変わりません。これが false に設定されている場合、要求された EKU と Key Usage は無視されます。<br>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.scepman.com/ja/sono/troubleshooting/general.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
