次の方法で共有

Microsoft Connected Cache for Enterprise and Education のトラブルシューティング

この記事では、接続キャッシュの使用中に発生する可能性があるさまざまな問題のトラブルシューティング方法について説明します。 これらの問題は、発生する可能性があるタスクによって分類されます。

既知の問題

このセクションでは、Microsoft Connected Cache for Enterprise and Education の最新リリースに関する既知の問題について説明します。 最新リリースに含まれる修正プログラムの詳細については、「 リリース ノート」ページ を参照してください。

[メトリック] タブの [スコープ] の選択に、接続されたキャッシュ Azure リソースがありません

接続キャッシュ Azure portalでカスタム グラフを作成する場合は、接続キャッシュ Azure リソースの [監視] セクションの [メトリック] タブを選択します。 接続キャッシュ Azure リソースは、既定ではスコープとして正しく選択されていますが、選択したスコープを変更した場合、接続キャッシュ Azure リソースを再選択できないため、後続のカスタム グラフの作成が妨げられます。

一時的な回避策として、[ メトリック] タブから移動し、それに戻ることができます。 接続済みキャッシュ Azure リソースが、スコープとして再び正しく選択されます。

importCert.ps1 の制限事項

importCert.ps1 スクリプトは、Windows ホスト型キャッシュ ノードの HTTPS 構成プロセスの一環として、Windows 証明書ストアに証明書をインポートするために使用されます。 このスクリプトは現在、gMSA 接続キャッシュ ランタイム アカウントを使用して、Windows Server 2022 または Windows Server 2025 にデプロイされたキャッシュ ノードをサポートしていません。

接続キャッシュ Windows インストーラー アプリケーションの制限事項

Connected Cache Windows インストーラー アプリケーションは、接続キャッシュを Windows ホスト マシンに展開するために使用される MSIX パッケージです。 インストーラー アプリケーションは現在、Windows Server Core をサポートしていません。

最新リリースで修正プログラムが適用されました

GA リリース: 2025 年 7 月 23 日

  • Windows ホスト コンピューターが EN 以外のロケールで構成されている場合、接続されたキャッシュのインストールが失敗します。
  • Windows ホスト型の接続キャッシュ ノードは、構成されたキャッシュ ドライブ のサイズを超えて拡張できます。

Azure サブスクリプション ID を取得する手順

  1. Azure portal にサインインします。
  2. [ サブスクリプション] を選択します。 [ サブスクリプション] が表示されない場合は、検索バーに「 サブスクリプション」 と入力します。 入力を開始すると、入力に基づいてリストがフィルター処理されます。
  3. 既にAzure サブスクリプションがある場合は、手順 5 に進みます。 Azure サブスクリプションがない場合は、左上の [+ 追加] を選択します。
  4. 従量課金制サブスクリプションを選択します。 クレジットカード情報の入力を求められますが、Microsoft Connected Cache サービスを使用した場合は課金されません。
  5. [ サブスクリプション ] ページには、現在のサブスクリプションに関する詳細が表示されます。 サブスクリプション名を選択します。
  6. サブスクリプション名を選択すると、[ 概要 ] タブにサブスクリプション ID が表示されます。[サブスクリプション ID] の横にある [クリップボードにコピー ] アイコンを選択して、値をコピーします。

リソースの作成Azureトラブルシューティング

接続されたキャッシュ Azure リソースの作成は、Azure portal ユーザー インターフェイスまたは Azure CLI コマンド セットを使用して開始できます。

リソースの作成時にエラーが発生した場合は、サブスクリプションの下にAzureリソースを作成するために必要なアクセス許可があり、リソース作成プロセス中にすべての必須フィールドを入力していることをチェックします。

キャッシュ ノード構成のトラブルシューティング

接続キャッシュ ノードの構成は、Azure portal ユーザー インターフェイスまたは Azure CLI コマンド セットを使用して行うことができます。

検証エラーが発生した場合は、必要なすべての構成フィールドに入力したことをチェックします。

構成が有効になっていないように見える場合は、Azure portal ユーザー インターフェイスの構成ページの上部にある [保存] オプションを選択チェック。

プロキシ構成を変更した場合は、プロキシ構成を有効にするために、接続済みキャッシュ ソフトウェアをホスト コンピューターに再デプロイする必要があります。

Windows ホスト コンピューターへのキャッシュ ノードの展開のトラブルシューティング

Windows でホストされるインストール ログの収集

接続キャッシュ ノードを Windows ホスト コンピューターに展開 するには、接続キャッシュ Windows アプリケーションに含まれる一連の PowerShell スクリプトを実行する必要があります。 これらのスクリプトは、 deliveryoptimization-cli mcc-get-scripts-pathによって指定された接続キャッシュ アプリケーションのスクリプト ディレクトリにログ ファイルを書き込もうとします。

インストール ログ ファイルには、次の 3 種類があります。

  1. WSL_Mcc_Install_Transcript: このログ ファイルは、インストール スクリプトの実行時に PowerShell ウィンドウに出力された行を記録します
  2. WSL_Mcc_Install_FromRegisteredTask_Status: このログ ファイルは、登録されたタスクのインストール中に書き込まれた高レベルの状態を記録します
  3. WSL_Mcc_Install_FromRegisteredTask_Transcript: このログ ファイルは、登録されたタスクのインストール中に書き込まれた詳細な状態を記録します

通常、インストールの問題を診断するには、登録済みタスクトランスクリプトが最も役立ちます。

他の Windows でホストされているログの収集

キャッシュ ノードが Windows ホスト コンピューターに正常にインストールされると、ログ ファイルは定期的にインストール ディレクトリに書き込まれます (既定ではC:\mccwsl01\ )。

次の種類のログ ファイルが表示されます。

  1. WSL_Mcc_Monitor_FromRegisteredTask_Transcript: このログ ファイルには、接続されたキャッシュの実行を確実に行う "MCC_Monitor_Task" スケジュールされたタスクの出力が記録されます。
  2. WSL_Mcc_UserUninstall_Transcript: このログ ファイルには、ユーザーがホスト コンピューターから接続済みキャッシュ ソフトウェアをアンインストールするために実行できる "uninstallmcconwsl.ps1" スクリプトの出力が記録されます。
  3. WSL_Mcc_Uninstall_FromRegisteredTask_Transcript: このログ ファイルは、"uninstallmcconwsl.ps1" スクリプトによって呼び出されたときに、ホスト コンピューターから接続キャッシュ ソフトウェアをアンインストールする "MCC_Uninstall_Task" スケジュールされたタスクの出力を記録します。

接続キャッシュ ランタイム アカウントとしての PowerShell プロセスの実行

Windows ホスト コンピューター上の接続キャッシュ ソフトウェアに関する問題のトラブルシューティングを行うには、接続キャッシュ ランタイム アカウントとしてコマンドを実行する必要がある場合があります。 これを行うには、接続キャッシュのインストール中に指定されたランタイム アカウントとして PowerShell プロセスを起動します。

  • ランタイム アカウントがローカル アカウントの場合は、管理者特権の PowerShell ウィンドウで次のコマンドを実行することで、ランタイム アカウントとして PowerShell プロセスを起動できます。

    Start-Process powershell.exe -Credential (Get-Credential "<RuntimeAccountName>") -ArgumentList '-NoExit'

  • ランタイム アカウントがドメインまたはサービス アカウントの場合は、管理者特権の PowerShell ウィンドウで次のコマンドを実行することで、ランタイム アカウントとして PowerShell プロセスを起動できます。

    Start-Process powershell.exe -Credential (Get-Credential "<Domain>\<RuntimeAccountName>") -ArgumentList '-NoExit'

  • ランタイム アカウントがグループ管理サービス アカウント (gMSA) の場合は、 PsExec を使用して、管理者特権の PowerShell ウィンドウで次のコマンドを実行して、ランタイム アカウントとして PowerShell プロセスを起動する必要があります。

    psexec.exe -i -u <DOMAIN\GmsaAccountName$> -p ~ powershell.exe

接続済みキャッシュ コンテナーが実行されているかどうかを確認する

接続済みキャッシュ ソフトウェアが Windows ホスト コンピューターに正常に展開されたら、Windows ホスト コンピューターで次の手順を実行して、キャッシュ ノードが正常に実行されているかどうかをチェックできます。

  1. 接続キャッシュのインストール中にランタイム アカウントとして指定されたアカウントとして PowerShell プロセスを起動する
  2. wsl -d Ubuntu-24.04-Mccを実行して、接続済みキャッシュ コンテナーをホストする Linux ディストリビューションにアクセスする
  3. sudo iotedge listを実行して、IoT Edge ランタイム内で実行されているコンテナーを表示します

edgeAgent コンテナーと edgeHub コンテナーが表示されていても MCC が表示されない場合は、sudo iotedge system logs -- -fを使用してIoT Edge セキュリティ マネージャーの状態を表示できます。

sudo systemctl restart iotedgeを使用して、IoT Edge ランタイムを再起動することもできます。

キャッシュ ノードの登録中に接続済みキャッシュのインストールが失敗する

Windows ホスト マシン上のインストール プロセスの一環として、Connected Cache は登録エンドポイント geomcc.prod.do.dsp.mp.microsoft.comを呼び出すことによって配信最適化サービスに自身を登録しようとします。 この呼び出しは、接続済みキャッシュ コンテナーをホストする WSL2 ディストリビューション内から発信され、キャッシュ ノードをインストールするには成功している必要があります。

接続のトラブルシューティングを行うには、管理者特権の PowerShell ウィンドウから接続キャッシュ ランタイム アカウントとして次のコマンドを実行してみてください。

まず、接続キャッシュ コンテナーをホストする WSL2 ディストリビューションにアクセスします。

wsl -d Ubuntu-24.04-Mcc

次に、次の bash コマンドを実行して、登録エンドポイントの DNS 解決をチェックします。

nslookup geomcc.prod.do.dsp.mp.microsoft.com

登録エンドポイントへの TCP 接続 (HTTPS の場合はポート 443) を確認します。

nc -vz geomcc.prod.do.dsp.mp.microsoft.com 443

登録エンドポイントからの HTTPS 応答を確認します。

curl -v https://geomcc.prod.do.dsp.mp.microsoft.com

スケジュールされたタスクMCC_Install_Task実行に失敗する

Windows ホスト マシンへの接続キャッシュのインストールは、指定された接続キャッシュ ランタイム アカウントとしてインストール アクションを実行するために、"MCC_Install_Task" スケジュールされたタスクに依存します。 このタスクの実行に失敗した場合は、次のいずれかの理由が原因である可能性があります。

グループ ポリシー オブジェクトがスケジュールされたタスク登録と競合する

グループ ポリシー オブジェクトの有効化: ネットワーク アクセス: ネットワーク認証のパスワードと資格情報の保存を許可しないと、接続キャッシュ ソフトウェアがキャッシュ ノードの登録と操作を成功させるために必要なスケジュールされたタスクを登録できなくなります。

MCC ランタイム アカウントには、バッチ ジョブとしてログオンするためのアクセス許可がありません

接続キャッシュ ランタイム アカウントに "バッチ ジョブとしてログオンする" アクセス許可が付与されていることを確認します。 このアクセス許可は、Connected Cache ランタイム アカウントがスケジュールされたタスクを実行するために必要です。

エンタープライズ セキュリティ ポリシーを使用すると、PowerShell スクリプトの実行が禁止されます

Windows ホスト コンピューターの PowerShell 実行ポリシーでスクリプトの実行が許可されていることを確認します。 現在の実行ポリシーをチェックするには、管理者特権の PowerShell ウィンドウで次のコマンドを実行します。

Get-ExecutionPolicy

WSL2 が "指定されたログオン セッションが存在しません" というメッセージでインストールに失敗する

Windows ホスト コンピューターで PowerShell コマンド wsl.exe --install --no-distribution を実行しようとすると、このエラー メッセージが表示される場合は、ローカル管理者としてログオンし、管理者特権の PowerShell ウィンドウからコマンドを実行していることを確認します。

WSL2 カーネルの更新

WSL 関連の問題が原因で接続済みキャッシュのインストールが失敗している場合は、 wsl.exe --update を実行して最新バージョンの WSL カーネルを取得してみてください。

スケジュールされたタスクMCC_Monitor_Task実行に失敗する

Connected Cache コンテナーが実行されると、MCC_Monitor_Taskスケジュールされたタスクは、接続キャッシュ ランタイム アカウントで定期的に実行され、WSL が接続キャッシュ WSL ディストリビューションを停止しないようにします。 キャッシュ ノードがユーザー操作なしでオフラインになった場合は、スケジュールされた "MCC_Monitor_Task" タスクが正常に実行されていないことが原因である可能性があります。

ホスト コンピューターでタスク スケジューラを使用して、このスケジュールされたタスクの状態をチェックできます。

  1. ホスト コンピューターでタスク スケジューラを開く
  2. [アクティブタスク] セクションに移動し、MCC_Monitor_Taskをダブルクリックします
  3. [ 最終実行時刻 ] 列と [最終実行結果 ] 列を確認して、操作が正常に完了したかどうかを確認します。
  4. [トリガー] タブを選択し、[状態] が [有効] になっていることを確認します
  5. [履歴] タブを選択し、タスクの実行に関連するエラーまたは警告をチェックします。

MCC_Monitor_Taskが正常に実行できない場合は、接続キャッシュ ランタイム アカウントの資格情報の有効期限が切れている可能性があります。 この場合は、 updatetaskpasswords.ps1 スクリプトを使用して資格情報を更新できます。

  1. 管理者として PowerShell プロセスを開きます。

  2. ディレクトリをスクリプト ディレクトリに変更し、 updatetaskpasswords.ps1が存在することを確認します。

    • パブリック プレビュー展開パッケージを使用して接続キャッシュをインストールした場合、スクリプト ディレクトリは、元のデプロイ コマンド (既定では "C:\mccwsl01\MccScripts") で指定された installationFolder 内にあります。
    • 接続キャッシュ Windows アプリケーションを使用して接続キャッシュをインストールした場合、スクリプト ディレクトリは、 deliveryoptimization-cli mcc-get-scripts-pathによって返されるディレクトリ内にあります。

  3. 新しいパスワードで接続キャッシュ ランタイム アカウントを表す $myLocalAccountCredential という名前の PSCredential オブジェクトを作成します。

  4. 次のコマンドを使用して、 updatetaskpasswords.ps1 スクリプトを実行します。

    .\updatetaskpasswords.ps1 -Credential $myLocalAccountCredential

キャッシュ ノードは正常にデプロイされましたが、要求を提供していません

キャッシュ ノードが localhost の外部の要求に応答していない場合は、接続キャッシュのインストール中にホスト マシンのポート転送規則が正しく設定されなかった可能性があります。 WSL2 は既定で仮想化イーサネット アダプターを使用するため、トラフィックが LAN から WSL2 インスタンスに到達できるようにするには、ポート転送規則が必要です。 詳細については、「 WSL を使用したネットワーク アプリケーションへのアクセス」を参照してください。

ホスト マシンのポート転送規則をチェックするには、次の PowerShell コマンドを使用します。

netsh interface portproxy show v4tov4

ポート 80 から 0.0.0.0 へのポート転送規則が表示されない場合は、管理者特権の PowerShell インスタンスから次のコマンドを実行して、WSL への適切な転送を設定できます。

netsh interface portproxy add v4tov4 listenport=80 listenaddress=0.0.0.0 connectport=80 connectaddress=<WSL IP Address>

接続キャッシュ アプリケーションのインストール ディレクトリ (既定ではC:\mccwsl01) に存在する必要があるwslip.txt ファイルから WSL IP アドレスを取得できます。

WSL ポート転送規則がありません (443,5000)

HTTPS をサポートするように Windows ホスト型キャッシュ ノードを正常に構成するには、ホスト コンピューターのポート 443 から接続キャッシュ コンテナーをホストする WSL2 ディストリビューションのポート 443 にトラフィックを転送するポート転送規則を作成する必要があります。

Windows ホスト型キャッシュ ノードの Terse Summary ページにリモート アクセスするには、ホスト マシンのポート 5000 から接続キャッシュ コンテナーをホストする WSL2 ディストリビューションのポート 5000 にトラフィックを転送するポート転送規則を作成する必要があります。

これらのポート転送規則を作成するには、キャッシュ ノードのデプロイが完了した後、管理者特権の PowerShell ウィンドウで次のコマンドを実行します。

$ipFilePath = Join-Path ([System.Environment]::GetEnvironmentVariable("MCC_INSTALLATION_FOLDER", "Machine")) "wslIp.txt"

$ipAddress = (Get-Content $ipFilePath | Select-Object -First 1).Trim()

netsh interface portproxy add v4tov4 listenport=443 listenaddress=0.0.0.0 connectport=443 connectaddress=$ipAddress
netsh interface portproxy add v4tov4 listenport=5000 listenaddress=0.0.0.0 connectport=5000 connectaddress=$ipAddress

また、ホスト マシンのファイアウォールでポート 443 と 5000 の受信トラフィックが許可されるようにする必要もあります。 これを行うには、管理者特権の PowerShell ウィンドウで次のコマンドを実行します。

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (HTTPS)" -Direction Outbound -Action Allow -Protocol TCP -LocalPort "443")

[void](New-NetFirewallRule -DisplayName "WSL2 Port Bridge (MCC SUMMARY)" -Direction Inbound -Action Allow -Protocol TCP -LocalPort "5000")

Windows へのキャッシュ ノードのデプロイが "ERROR: 証明書を確認できません" で失敗する

キャッシュ ノードのデプロイ中に "ERROR: 証明書を確認できません" というエラーが発生した場合は、ネットワークの TLS 検査プロキシ (ZScaler など) が接続キャッシュ ソフトウェアと配信最適化サービス間の通信を傍受している可能性があります。 このインターセプトによって証明書チェーンが切断され、接続キャッシュが正常にデプロイされなくなります。

この問題を解決するには、TLS 検査プロキシを バイパス するために、"*.prod.do.dsp.mp.microsoft.com" との間の呼び出しを許可するようにネットワーク環境を構成する必要があります。

また、キャッシュ ノード のプロキシ設定を構成 してから、目的の installationFolder パスにプロキシ証明書ファイル (.pem) を配置し、デプロイ コマンドに -proxyTlsCertificatePemFileName "mycert.pem" を追加する必要があります。 たとえば、.pem ファイルを C:\mccwsl01\mycert.pem に配置し、deployment コマンドに -proxyTlsCertificatePemFileName "mycert.pem" を追加します。

Linux ホスト マシンへのキャッシュ ノードのデプロイのトラブルシューティング

接続キャッシュ ノードを Linux ホスト マシンにデプロイ するには、Linux デプロイ パッケージに含まれる一連の Bash スクリプトを実行する必要があります。

接続済みキャッシュ ソフトウェアが Linux ホスト コンピューターに正常にデプロイされたら、Linux ホスト コンピューターで次の手順を実行して、キャッシュ ノードが正常に実行されているかどうかをチェックできます。

  1. sudo iotedge listを実行して、IoT Edge ランタイム内で実行されているコンテナーを表示します

edgeAgent コンテナーと edgeHub コンテナーが表示されていても MCC が表示されない場合は、sudo iotedge system logs -- -fを使用してIoT Edge セキュリティ マネージャーの状態を表示できます。

sudo systemctl restart iotedgeを使用して、IoT Edge ランタイムを再起動することもできます。

注

LINUX キャッシュ ノードを再デプロイして GA リリース コンテナーに移行した後、ユーザーは chmod 777 -R /cachedrivepath を実行し、接続済みキャッシュ コンテナー sudo iotedge restart MCCを再起動する必要があります。 そうしないと、再デプロイされたノードが起動して実行されますが、コンテンツの要求は失敗します。

Linux へのキャッシュ ノードのデプロイが "ERROR: 証明書を確認できません" で失敗する

キャッシュ ノードのデプロイ中に "ERROR: 証明書を確認できません" というエラーが発生した場合は、ネットワークの TLS 検査プロキシ (ZScaler など) が接続キャッシュ ソフトウェアと配信最適化サービス間の通信を傍受している可能性があります。 このインターセプトによって証明書チェーンが切断され、接続キャッシュが正常にデプロイされなくなります。

この問題を解決するには、TLS 検査プロキシを バイパス するために、"*.prod.do.dsp.mp.microsoft.com" との間の呼び出しを許可するようにネットワーク環境を構成する必要があります。

また、キャッシュ ノード のプロキシ設定を構成 してから、抽出されたデプロイ パッケージ ディレクトリにプロキシ証明書ファイル (.pem) を配置し、 proxytlscertificatepath="/path/to/pem/file" をデプロイ コマンドに追加する必要があります。

キャッシュ ノード診断サポート バンドルの生成

インストール パッケージに含まれる collectMccDiagnostics.sh スクリプトを実行することで、詳細な診断情報を含むサポート バンドルを生成できます。

Windows ホスト マシンの場合は、次の操作を行う必要があります。

  1. 接続キャッシュのインストール中にランタイム アカウントとして指定されたアカウントとして PowerShell プロセスを起動する

  2. 接続キャッシュ アプリケーションのインストール ディレクトリ ( deliveryoptimization-cli mcc-get-scripts-pathで指定) 内の "MccScripts" ディレクトリにディレクトリを変更し、 collectmccdiagnostics.sh

  3. wsl bash collectmccdiagnostics.shを実行して診断サポート バンドルを生成する

  4. スクリプトが完了したら、診断サポート バンドルの場所を説明するコンソール出力を書き留めます

    たとえば、"パッケージが正常に圧縮されました。/etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz で作成されたファイルを送信してください"

  5. wsl cp コマンドを実行して、Ubuntu ディストリビューション内の場所から Windows ホスト OS にサポート バンドルをコピーします

    例えば wsl cp /etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz /mnt/c/mccwsl01/SupportBundles/

Linux ホスト マシンの場合は、次の操作を行う必要があります。

  1. ディレクトリを、抽出された Connected Cache デプロイ パッケージ内の "MccScripts" ディレクトリに変更し、 collectmccdiagnostics.sh

  2. collectmccdiagnostics.shを実行して診断サポート バンドルを生成する

  3. スクリプトが完了したら、診断サポート バンドルの場所を説明するコンソール出力を書き留めます

    たとえば、"パッケージが正常に圧縮されました。/etc/mccdiagnostics/support_bundle_2024_12_03__11_05_39__AM.tar.gz で作成されたファイルを送信してください"

HTTPS 構成のトラブルシューティング

証明機関 (CA) が .pem 形式または.cer形式でのみ署名済み証明書を生成できる場合は、ファイルが Base64 エンコードの場合は、証明書ファイルのファイル拡張子を .crt に変更できます。

キャッシュ ノードの監視のトラブルシューティング

接続されたキャッシュ ノードの状態とパフォーマンスは、Azure portal ユーザー インターフェイスを使用して監視できます。

[概要] タブの 基本的な監視 ビジュアルに予期しない値または誤った値が表示されている場合は、ブラウザー ウィンドウを更新します。

問題が解決しない場合は、必要に応じて Timespan および Cache ノード フィルターを構成したことをチェックします。

診断と解決

Azure portal インターフェイスによって提供される問題の診断と解決機能を使用することもできます。 Microsoft Connected Cache Azure リソース内のこのタブでは、問題の解決策を絞り込むのに役立ついくつかのプロンプトが表示されます。

  • Last updated on